dev-manager-tauri/.blueprint/modules/mvp-closure.md
lanrtop 7907793f19
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
docs: MVP 收口 M3/M4——常驻文档漂移五处修复,按钮清单收敛到 AGENTS.md,agents-meta-rules 对齐托管块 1.10.0 并附逐节对照
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 15:34:40 +09:00

6.3 KiB
Raw Blame History

MVP 收口(mvp-closure)

status: in_progress | created: 2026-10-04 | intent: INT-04 | 统筹:docs/tasks/2026-10-03-coordination.md §0 来源:2026-10-04 用户在 P8 达成后定下一阶段为「炼境 MVP 收口」,并定以 enterprise-system 真实开发作为验证场。

概述

把炼境收口到 MVP:agent 拿到子项目能开工、能自验、能交付,摩擦能闭环回传。炼境侧只做收拾(关账、清理、修文档漂移), 不开新能力;四条能力是否真的可用,在 enterprise-system 的真实开发中只读观察取证。

决策记录

  • 2026-10-04 用户定:扩展项(部署控制面、P4b–e、P5/P6、治理缺口②③、DSH 接管、Codex 模型切换、多维视图、架构演进、 intent-catalog Phase 4+、概念占位显式化、project-dev-variables V14–V16)冻结,MVP 达成后再排;清单在统筹文档 §3。
  • 2026-10-04 用户定:以 enterprise-system 真实开发验证四条能力(M5),原「开发变量人终验」(V13)并入 M5; intent-catalog 的 enterprise 试点继续冻结,先把四条跑稳。
  • 观察边界:enterprise 主工作区有在制品,炼境侧只经 MCP 只读查询取证;要改 enterprise 就开临时 worktree、走 PR。

任务卡

🔵 M2 — blueprint-buff 关账

  • status: in_progress
  • complexity: S
  • intent: INT-04@2.0
  • files: .blueprint/modules/blueprint-buff.md, .blueprint/manifest.yaml
  • acceptance: "agent_verify: [shell] grep -cE '^### (📋|🔵|💭|🔴)' .blueprint/modules/blueprint-buff.md → 0 且 grep -c '^### ✅' 同文件 → 8;git -C 主仓库 log 中 2026-10-04 的 ff 合并后 git status --porcelain -- .blueprint/modules 为空(零误标)并写入 B2 卡 human_verify 证据;manifest blueprint-buff 为 status: done、progress: 100,模块决策记录写明「剩余 14% 为未更新的进度数字,核心卡已全部完成」。"
  • 为什么:manifest 记 86%,但模块 8 张卡全 ✅;唯一缺 B2 终验记录,而 2026-10-04 主仓库 6 次快进合并后 .blueprint/modules 零误标,正是 B2 的终验现象。

✅ M3 — 本轮临时项目与 worktree 清理

  • status: done
  • complexity: S
  • intent: INT-04@2.0
  • files: docs/tasks/2026-10-03-coordination.md
  • acceptance: "agent_verify: [shell] git worktree list 不含 tmp-p7skill-review、tmp-delivery-status-review、tmp-p10-verify-mut、dev-manager-tauri-wt-p8、dev-manager-tauri-wt-intent、dev-manager-tauri-wt-p8g;[MCP] list_all_projects 不含路径带 lj-p8 的登记。human_verify: 用户手动删除统筹文档 §5「待你手动删除」所列目录与文件。"
  • verification: "2026-10-04(INT-04 goal):git worktree list 按六个已清理名称计数 → 0;全局 MCP list_all_projects 完整输出(29 个项目)中 lj-p8 → 0。human_verify(手动删除 §5 所列目录与文件)待用户。顺带发现:list_all_projects 中 dev-manager-tauri 出现两条(组 f2418a3b 与 ffa9e42d),超出本卡范围,未处理。"

✅ M4 — 常驻文档漂移修复

  • status: done
  • complexity: S
  • intent: INT-04@2.0
  • files: docs/ai-context/project-brief.md, AGENTS.md, docs/ai-context/agent-button-system.md, docs/templates/agents-meta-rules.md, docs/tasks/2026-09-30-dev-variables-materialize.md
  • acceptance: "agent_verify: [shell] ① grep -c 'onboard/' docs/ai-context/project-brief.md → ≥1;② grep -lE '^#+ 炼境自己的 Agent 按钮清单' AGENTS.md docs/ai-context/agent-button-system.md → 恰好 1 个文件,另一处改为指针;③ grep -c '1.10.0' docs/templates/agents-meta-rules.md → ≥1,且其规则正文与 src-tauri/resources/onboarding/AGENTS.md.tmpl 的 ONBOARDING_MANAGED 块逐节对照无缺漏(差异写进卡片);④ grep -c '未合入 master' docs/tasks/2026-09-30-dev-variables-materialize.md → 0;⑤ grep -c '\.agent/task\.md' docs/ai-context/agent-button-system.md → 0 或改为与现行做法一致的说明;pnpm typecheck exit 0。"
  • 说明:只改文档,不动 resources/onboarding/ 模板(模板改动会触发指纹测试与版本升级,超出本卡)。
  • verification: "2026-10-04(INT-04 goal):① project-brief 架构速查补 mcp_inject.rs 与 onboard/ 两行;② 按钮清单以 AGENTS.md 块外区为单一来源(并入 agent-button-system 版多出的 pnpm test 与一键接入两行),agent-button-system 原节改为「按钮清单的位置」指针;③ agents-meta-rules 头部改 version 1.10.0 + aligned_with,能力包五条同步为模板原文、T1/T3/T4/自查措辞同步;④ dev-variables 简报头部改为 frozen、模块已在 master;⑤ agent-button-system 持久层去掉不存在的最小接入文件,改为与单档接入一致。"
  • 差异清单(agents-meta-rules ↔ AGENTS.md.tmpl ONBOARDING_MANAGED 1.10.0,全文见 meta-rules「与分发模板的对照」节): "托管块 7 节中,核心开发约束、需求对齐协议、Git 工作流三节 meta-rules 无、以模板为准不复制;能力包一节已同步,Node/pnpm 工具链只留指针;agent 按钮与验证路径——meta-rules 缺载体就近选择表、完成的定义、侦察→驻军、agent_verify/human_verify 分层与三分定位启发式,多出分工原则、按钮清单模板、降级约定(已不在托管块内);多 AI CLI 协作与交接模板内容等价。托管块外四支柱、T1–T4、铁律、自查已同步。"

📋 M5 — enterprise-system 实战验证四条能力

  • status: todo
  • complexity: M
  • intent: INT-04@2.0
  • depends: M2, M3, M4
  • files: .blueprint/modules/mvp-closure.md
  • acceptance: "agent_verify: [MCP 只读,project_id 为 enterprise 的 canonical id] ① 能开工:verify_onboarding clients 三端 converged 且 probe_client_parity all_applicable_ready=true;② 能自验:炼境日志或会话证据中至少 1 次 read_project_test_account 成功;③ 能交付:get_delivery_status 至少 1 个 PR 的 CI passed 并已合并;④ 摩擦闭环:list_envoy_returns 中 enterprise 来源的回传均有处置回执。human_verify: 用户在 enterprise 开发中确认——新会话无需手工配置即可开工;需要登录时 agent 先查炼境不索要账号(原 V13);认可该次交付;回传内容是真问题。"
  • 说明:随用户开发进度积累证据,不进 M2–M4 的 /goal;证据攒够后统筹会话一次性核对并出终验清单。