Trae/agent d r bdg4

.trae/documents/phase1_implementation_plan.md

@@ -0,0 +1,89 @@
+# 阶段一（单机底座）实施计划
+
+> 范围：F1 Profile 模型+卡片、F2 喂养管道（阈值触发+标签级 scope）、F3 P1/P2（技能点选、发布、导入导出、统计）
+> 验收标准（来自 AGENT-NETWORK-PLAN §6）：
+> 1. 新增 10 条同领域笔记后，身份卡专长标签无人工干预更新
+> 2. 未授权 scope 内容在喂养输入中不可达（fuzz 验证）
+> 3. 技能导出→删除→导入内容一致
+
+## 仓库调研结论
+
+- flowix-core：frontmatter 解析体系成熟（`extract_document_metadata`/`serialize_frontmatter`），note_index 投影走 `MemoIndexEntry.properties`，`normalize_tag_path` 可校验标签路径。
+- flowix-desktop：`AgentAccessEntry` 当前 kind 仅 `Notebook|Folder`；`memo_events::emit` 只发前端 Tauri 事件，无内部订阅；`document_derived.rs` 提供 coalescing worker 模式可复用；插件体系（catalog/run/import/export/integrity）已完整，F3 P1/P2 主要是聚合层与统计层。
+- DSH：subagent/goal/approval 运行时就绪（阶段二用）。
+- 构建：`cargo check -p flowix-core` 与 `cargo check -p flowix-desktop` 为主要验证手段；前端需 `pnpm` 构建（环境未确认，优先保证 Rust 编译）。
+
+## 文件与模块
+
+| 文件 | 变更 |
+| --- | --- |
+| `app/flowix-core/src/agent/mod.rs`（新建） | AgentProfile 结构、frontmatter 解析/序列化、校验、agentId 生成 |
+| `app/flowix-core/src/agent/profile.rs`（新建） | 解析实现 |
+| `app/flowix-core/src/lib.rs` | 导出 `agent` 模块 |
+| `app/flowix-desktop/src/config/access.rs` | `AgentAccessEntry.kind` 新增 `Tag` 变体 + 迁移兼容 |
+| `app/flowix-desktop/src/commands/agent_profile.rs`（新建） | `agent_profile_get/create/update/delete` IPC |
+| `app/flowix-desktop/src/commands/mod.rs` | 注册新 IPC |
+| `app/flowix-desktop/src/memo_events.rs` | `emit` 内增加内部 broadcast 分发 |
+| `app/flowix-desktop/src/nurture/mod.rs`（新建） | trigger + scheduler 骨架（N1） |
+| `app/flowix-desktop/src/agent_profile/`（新建） | profile 投影与 NoteService 写回辅助 |
+| `app/flowix-desktop/src/skill_registry.rs`（新建） | 技能注册表（plugin + DSH 聚合）、publish state、usage 统计 |
+| `app/flowix-desktop/src/commands/skill.rs`（新建） | `skill_*` IPC |
+| `app/flowix-desktop/src/plugin.rs` | 扩展 publishState 字段 + usage 事件埋点 |
+
+## 实施步骤（依赖序）
+
+### M1：F1 Profile 数据模型（flowix-core）
+1. 新建 `flowix-core/src/agent/` 模块：`AgentProfile` 结构（对应 AGENT-PROFILE-MODEL §3 frontmatter 字段，`flowix_` 前缀）、`parse_profile(content) -> Result<AgentProfile>`、`serialize_profile(profile, body) -> String`、`generate_agent_id() -> String`（8 字节 hex，`agt_` 前缀）、校验（expertise 每项过 `normalize_tag_path`，bio ≤ 500 字符，redactionLevel ∈ R1|R2|R3）。
+2. `lib.rs` 导出模块。
+3. 单元测试：解析合法 profile、非法 expertise 拒收、round-trip 保持正文。
+
+### M2：AgentAccessEntry 扩展 Tag 粒度（F6 scope 前置）
+1. `access.rs`：`AgentAccessKind` 加 `Tag`，`AgentAccessEntry` 加 `tag_path: Option<String>`。
+2. 迁移：读取旧 JSON（无 kind 时默认 Notebook/Folder 按 path 是否为根判断），向后兼容。
+3. 单元测试：旧配置可加载、Tag 条目存储正确。
+
+### M3：F1 Profile IPC 与投影（flowix-desktop）
+1. 新建 `agent_profile/`：从 `.agents/<id>/profile.md` 读写，走 NoteService 笔记锁。
+2. 新建 `commands/agent_profile.rs`：`agent_profile_list(notebookId)`、`agent_profile_get`、`agent_profile_create`、`agent_profile_update`、`agent_profile_delete`。
+3. `commands/mod.rs` 注册。
+4. note_index 侧：profile.md 的 `flowix_kind: agent-profile` 已随现有 frontmatter 投影进入 properties，无需改表。
+5. 验证：`cargo check -p flowix-desktop`。
+
+### M4：F2 N1 — 触发器 + 调度器骨架
+1. `memo_events.rs`：`emit` 内加 `tokio::sync::broadcast`（容量 256），前端事件不变。
+2. 新建 `nurture/mod.rs`：`NurtureTrigger` 订阅 broadcast，实现双过滤（`.agents/`/`.flowix/` 路径丢弃 + scope 过滤）+ 阈值计数 + 入队；`NurtureScheduler` coalescing worker（复用 `document_derived` 模式）+ skip 判断 + 留痕到 `.flowix/agents/<id>/nurture-log.jsonl`。
+3. 留痕与状态文件 `nurture.json` 读写。
+4. 单元测试：路径过滤、阈值触发、合并去重、skip 留痕。
+
+### M5：F3 P1/P2 — 技能注册表 + 导入导出 + 统计
+1. 新建 `skill_registry.rs`：聚合 plugin catalog（现有 `PluginCatalogSnapshot`）与 DSH skills（经 `skills/list`）为 `SkillDescriptor` 列表；publishState（private/shared）存 `~/.flowix/plugin/state.json`。
+2. 新建 `commands/skill.rs`：`skill_registry_list`、`skill_set_publish_state`、`skill_usage_summary`。
+3. `plugin.rs`：`plugin-run` 事件埋点写 `~/.flowix/plugin/skill-usage.jsonl`；复用现有 import/export（已存在，仅加 integrity 校验断言）。
+4. 验证：`cargo check -p flowix-desktop`。
+
+### M6：端到端冒烟验证
+1. 构建 flowix-core 与 flowix-desktop：`cargo check`（或 build）。
+2. 跑新增单元测试。
+3. 手工脚本验证验收标准 1/2/3 的后端路径（profile 创建→scope 过滤→技能 import/export 完整性）。
+
+## 依赖与考虑
+
+- M1 是 M3/M4 的前置（profile 结构 + scope Tag）。
+- M4 依赖 M2（scope 过滤需要 Tag 变体）。
+- DSH 侧技能聚合依赖 appserver 运行时方法可用；若构建环境无 Node，M5 的 DSH 聚合仅定义接口，运行时接线留作后续。
+- 前端 UI（卡片、点选器）不在本计划 Rust 实现范围内；IPC 契约已定义，前端可对接。
+- 不改动 flowix-core 的 note_index 表结构（取材新查询留待 F2 N2）。
+
+## 验证
+
+- `cargo check -p flowix-core`、`cargo check -p flowix-desktop` 通过。
+- 新增单元测试通过（profile 解析、scope 迁移、trigger 过滤、skill 聚合）。
+- 验收标准 2（scope 不可达）：fuzz 测试用 100 条 scope 外路径事件，断言 0 条计入计数。
+- 验收标准 3（技能导入导出一致性）：导出包 → 删除 → 导入，比对 integrity 哈希一致。
+
+## 风险
+
+- **编译面大**：flowix-desktop 依赖 Tauri，构建可能慢或环境缺依赖。对策：优先 `cargo check`，必要时只 check 改动 crate。
+- **DSH 聚合在纯 Rust 侧不可直连**：M5 的 DSH 部分通过 IPC 方法调用，定义接口即可，不阻塞 Rust 编译。
+- **前端未实现**：验收标准 1（专长自动更新）的完整闭环需 F2 N2（蒸馏）+ UI，本计划只做到后端骨架；蒸馏会话留作 F2 N2 后续。已在步骤中明示。
+- **scope 迁移破坏现有配置**：M2 采用向后兼容读取，旧配置缺 kind 时按 path 推断，不破坏现有 access。

.trae/skills/flowix-extension-design/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: "flowix-extension-design"
+description: "Guides creation of Flowix design documents (HLD/LLD) for new subsystems. Invoke when designing a module/feature to add to the Flowix codebase, extending an existing domain, or producing an architecture/design doc."
+---
+
+# Flowix Extension Design
+
+For producing a structured, code-grounded design document when adding a new module or feature to the Flowix workspace. The output is a Markdown design doc under `docs/` following the repository's `UPPERCASE-DASHED.md` naming convention (e.g. `docs/AGENT-PROFILE-MODEL.md`).
+
+## When to invoke
+
+- The user asks to "设计" (design) a Flowix subsystem, module, pipeline, or feature.
+- A previous planning document (e.g. an `*-PLAN.md`) identifies a domain needing detailed design.
+- The task is to turn a product requirement or domain mapping into an implementation-ready design doc.
+
+Do **not** use this skill for PRDs, competitive analyses, or user-facing manuals — those have different reference styles.
+
+## Workflow
+
+### 1. Verify code facts before writing
+
+Never design against assumptions. Before drafting, run targeted `Grep`/`Read` to confirm:
+
+- The actual public API signatures the design will call or extend.
+- The real enum variants / struct fields that affect filtering, routing, or validation.
+- Whether an existing facility already covers part of the need (this often raises the real completion %).
+- The exact path conventions (e.g. `.flowix/` is local-only vs synced Markdown notes).
+
+Record the verified facts; the design must cite real file paths with line anchors where it builds on existing code.
+
+### 2. Requirement traceability table
+
+Open with a table mapping each requirement `R1..N` to its source (upstream plan doc, a prior decision, or derived in this design), using evidence tags:
+
+- `[Data-backed]` — verifiable from an existing artifact or a user-confirmed decision.
+- `[Hypothesis]` — an assumption the design depends on; call out that it must be confirmed before implementation.
+- `[Expert judgment]` — a design choice you are making.
+
+Also list the explicit design decisions made to close open questions (e.g. `D-N1: expertise = full replacement`).
+
+### 3. Architecture diagram + structural explanation
+
+Include one Mermaid diagram showing components and data flow. After it, give **2–3 sentences** on the structural properties that make the design safe (e.g. "there is exactly one exit point past the confirmation gate", "write-back events are filtered by path so no feedback loop"). Avoid meta-narration.
+
+### 4. Component detailed design
+
+For each component, give: a one-sentence responsibility; input / output; boundary (what it does **not** do); a small pseudocode block for non-trivial logic; failure semantics. If a component reuses an existing module, state exactly what it reuses and what it adds.
+
+### 5. Interface contracts
+
+- Rust struct signatures and IPC command tables (command / params / return / error codes).
+- For JSON contracts, include one concrete example and a field constraint table.
+- Error codes should be small lowercase snake_case strings, matching the repo's stable machine-code style.
+
+### 6. Data plane
+
+Table of all new files: path, content, sync vs local, lifecycle. Justify why each lives where it does (local state under `<nb>/.flowix/`, synced identity as a real note, device-level config under `~/.flowix/`).
+
+### 7. Non-functional + integration impact
+
+Security/cost/concurrency/privacy as they apply. A change-point table listing every file touched and whether the change is invasive or additive.
+
+### 8. Implementation steps
+
+3–4 incremental milestones, each named (e.g. `N1`, `S-M2`) with a measurable acceptance sentence.
+
+### 9. Test anchors
+
+A table of ~10–12 integration test cases (input → expected outcome) covering the happy path, each failure path, adversarial/security cases, and compatibility cases (e.g. old manifest versions).
+
+### 10. Open items
+
+Remaining `[To be confirmed]` decisions and `[Hypothesis]` items that gate implementation.
+
+## Conventions
+
+- Doc header: `> 状态：设计稿 vX.Y（…，待评审）｜ YYYY-MM-DD`
+- Doc title: `<Domain> <title>设计（详细版）` for LLD; plain for HLD.
+- Headings end without punctuation. No emoji.
+- Bold for tool/command names and critical warnings only (≤ 3 per section).
+- No "确保" followed by an unverifiable goal — replace with a measurable criterion.
+- No "不是…而是…" rhetorical frames; state the decision directly.
+- Mermaid for diagrams; walk each diagram in prose immediately after it.
+- Evidence tags appear in the traceability table and at key design decisions, not scattered through prose.