dev-manager-tauri/docs/tasks/2026-10-03-coordination.md

# 统筹推进文档：P8 一键接入与并行事项（2026-10-03 起）

> 本文件是执行会话的**单一入口**：领卡前先读完 §1–§3。卡片的范围与验收以蓝图卡片为准
> （`.blueprint/modules/agent-client-parity.md` 等），本文件不复制 acceptance，只管「谁做、按什么顺序、怎么交接」。
> 统筹会话负责维护本文件（§4、§5 随派单与合并更新）。

## 0. 方针与本阶段终点

- **方针**（AGENTS.md「项目定位」「管家准入与退出」）：炼境是 agent 开发子项目的管家；每个子项目都能在
  Claude Code、Codex、DSH 三端开发，重复配置尽量消除；不过度建设，能力按实测收益保留或撤销。
- **本阶段终点**：P8「一键接入」——新建或添加子项目后，一次确认即三端可用（P8 卡的 acceptance）。
  设计：`docs/tasks/2026-10-03-p8-onboarding-oneclick-design.md`；任务卡：agent-client-parity 的 P8-0、P8a–P8g、P4-0、P4a–P4e。

## 1. 角色与协议

> 执行方式（2026-10-03 调整）：任务卡片需要用户手动点开，统筹会话无法代点；改为统筹会话用后台工作流（Workflow）自动执行每张卡——子 agent 各自独立上下文、在固定 worktree 里干活，只把结论交回统筹会话。工作流与新会话一样计入账号用量。统筹会话设有每 30 分钟一次的会话内巡检（CronCreate，7 天自动失效）。

### 授权规则（用户 2026-10-03 立，持续有效直到 P8 acceptance 全部达成）

1. 每 30 分钟检查一次工作流与 PR 进度（统筹会话的会话内巡检）。
2. 独立审查通过（结论为可合并，或发现已全部处置）且 CI 为 passed 的 PR，由统筹会话按完整 head SHA 自行合并，合并后在运行中的炼境上做卡片要求的实测，然后派下一张卡。
3. §3 队列内的 Feature 卡视为用户已确认（提交带 ），不再逐张出确认卡。
4. 同一张卡自验或修复累计失败 3 次：卡片标 🔴、写明原因，跳过该卡继续队列（不再停下来等人）。
5. 只有三类事项找用户：写运行中的 DB、删除操作、human_verify。
6. 终点：P8「一键接入」卡的 acceptance 全部达成（agent_verify 由统筹会话实测；human_verify 汇总给用户终验）。

| 角色 | 是谁 | 做什么 |
|---|---|---|
| 统筹会话 | `local_ab7498e2-8aff-4e59-b45b-134636d12d9c`（「dev-manager-tauri 开发环境验证」） | 维护本文件、派卡、复核、合并 PR、处理上报；每 30 分钟检查一次执行会话 |
| 执行会话 | 每张卡一个新会话 | 按卡片实现与自验，做一次独立审查，开 PR，然后上报；不合并 PR |

- **上报**：用 SendMessage（`to` 填统筹会话的 session id）发三条——已完成 / 待验证 / 约束继承（AGENTS.md「多 AI CLI 协作」格式），附 PR 编号与**完整 head SHA**。
- **求助**：同一问题自修失败 2 次（AGENTS.md「自验失败降级约定」）就停下，上报失败原因、已尝试路径、需要决策的问题；不要绕过权限或安全分类器的拦截。
- **合并**：只由统筹会话核对 CI 与审查结论后合并（`merge_pull_request` 需要完整 head SHA）。
- **卡片状态**：开工把卡改 🔵、验收后改 ✅（两阶段提交），在自己的分支里改；需要在合并后实测的验收项，由统筹会话合并、实测后补标 ✅。

## 2. 执行环境铁律（都是踩过的坑）

- **主仓库工作区不碰**：`E:\code-project\dev-manager-tauri` 是用户日常运行 `pnpm tauri dev` 的地方。每张卡在自己的 git worktree 里做（如 `E:/code-project/dev-manager-tauri-wt-<卡号>`），M 级开 `feat/<模块>-<卡号>` 分支走 PR；S 级的纯文档可直推 master。
- **enterprise-system 主工作区不碰**：`E:\code-project\enterprise-system` 有其他会话的在制品，禁止 stash / reset / checkout / `add -A`；要改 enterprise 就从 origin/main 开临时 worktree，用 PR 交付。
- **cargo 热缓存**：`cd <worktree>/src-tauri && export CARGO_TARGET_DIR=E:/code-project/dev-manager-tauri-parity/src-tauri/target && cargo test`；长命令放后台运行。
- **rustfmt 只格式化改动的文件**：`rustfmt --edition 2021 --config skip_children=true <文件…>`。不加 `skip_children` 格式化 `lib.rs` 会改写全部子模块。
- **用户 deny 规则**：`rm`、`kill`、`pkill`、`git reset --hard`、npm/npx 等禁用，**也不能写进脚本文件再执行**（统筹会话踩过）。需要删除的临时目录列给用户；探针桩服务设成到时自动退出。
- **Git Bash**：`git show rev:path` 要加 `MSYS_NO_PATHCONV=1`；含反斜杠的文件用 Write 工具写；含中文的 HTTP 请求用 node `fetch`，不用 curl。
- **MCP**：一律 `http://127.0.0.1:27190`（不用 localhost）。会话里 lian-jing 没连上时，可用 node `fetch` 直接 POST `http://127.0.0.1:27190/mcp`（全局路由，`tools/call`），结果在 `result.structuredContent` 或 `result.content[0].text`。
- **变异验证**：先 `git add` 暂存，再改源码做变异、跑测试，最后 `git checkout -- <文件>` 从暂存区还原。没暂存就 checkout 会丢掉改动（统筹会话踩过）。
- **真实客户端**：`claude -p`、`codex exec`、DSH headless 可能跑 3 分钟以上，只在会话主线程或后台 bash 里跑，不交给 Workflow 子 agent（超过 180 秒会被判卡死）。嵌套 claude 前先 `unset CLAUDECODE CLAUDE_CODE_ENTRYPOINT CLAUDE_CODE_SSE_PORT`，stdin 重定向自 `/dev/null`。
- **凭据**：不读、不打印任何 token、凭据、`.env` 值；不对真实 Windows Credential Manager 做并发压力实验。
- **运行中的炼境 DB 写入**：自动模式下会被安全分类器拦截，这是对的。需要写 DB 的数据修复准备好脚本、备份和空跑结果，交用户执行。
- **提交**：Conventional Commits；`feat:` 带 `Feature-Confirmed: true`；末尾带 `Co-Authored-By` 署名行。PR 描述按自验报告纪律写，含「没验什么」一节。M 级卡开 PR 前用一个只读子代理做独立审查，审查处置写进卡片。

## 3. 派单队列

串行原因：P8 各卡集中改 `mcp_inject.rs`、`mcp_tools.rs`、`commands/onboarding.rs`，并行必然冲突。不碰这些文件的事项可以并行（标注「可并行」）。

| 序 | 事项 | 复杂度 | 起点 | 要点 |
|---|---|---|---|---|
| 1 | **P8c 收尾** | M | 分支 `feat/agent-client-parity-p8c` @ `ef2c7fd`（代码已完成，cargo test 307 passed） | 剩：独立审查与修复，卡片标 🔵 并记实现/验证，开 PR。PR #34 合并后先合并 master 再开 PR |
| 2 | P4a L1 零模型三端检查 | M | master（P4-0✅、P8b✅） | Claude 用不存在的模型名取 init（P4-0 H-P8-4，零额度）；Codex 用 `codex mcp get --json`（H-P8-1，未信任目录看不到项目配置）；DSH 解析白名单与插件哈希；认证链经稳定 shim 重放 |
| 3 | P8d onboard_project 编排本体 | M | P8c、P4a 合并后 | 复用 `onboard::plan::write_project_files` 与 `onboard::clients::registry()`；apply 前先重算计划并核对 digest |
| 4 | P8e 投影收口与契约同步 | S | P8d 后 | |
| 5 | P8f register_project 控制面投影 | S | P8e 后 | |
| 6 | P8g UI 一键接入 | M | P8e 后 | human_verify 交用户 |
| 并行 | 删除项目登记时一并解绑 Gitea 仓库 | S/M | master | 来自重复登记排查会话的推荐任务卡（轮询会继续往已删除的项目 ID 写数据），主要改 projects.rs / gitea.rs，可并行 |
| 后续 | P6（依赖 P8c）、P4c / P4d / P4e、A4→P4b、P5、beast-mode 重复登记 | | | P8 完成后再排 |

## 4. 派单与 PR 流水（统筹维护）

| 时间 | 事项 | 执行者 | 分支 / PR | 状态 |
|---|---|---|---|---|
| 10-03 | P8-0、P8a、P4-0、B2 | 统筹会话 | 直推 master | ✅ |
| 10-03 | P8b | 统筹会话 | PR #33（ddd729c） | ✅ |
| 10-03 | enterprise 接入包 1.9.0 | 统筹会话 | enterprise PR #183 | ✅ 已合并；enterprise 主工作区待其所有者同步 |
| 10-03 | P8c 收尾 | 工作流 wf_c121815d-6ea（实现→审查→修复→开 PR） | `feat/agent-client-parity-p8c`（起点 ef2c7fd） | 执行中 |
| 10-03 | 删除登记时解绑 Gitea | 工作流 wf_c121815d-6ea | `fix/gitea-unbind-on-unregister` | 执行中 |
| 10-03 | 重复登记修复 U1/U2 | 会话 `local_d2e1c156…`（「排查炼境 dev-manager-tauri 疑似重复登记」） | PR #34 → fc280db | ✅ 独立审查可合并、已合并，炼境已重编译；审查遗留 L1/L2 归 P8f（登记拒绝同路径），L3/L4/I1/I2 列入后续小修 |
| 10-03 | 重复登记数据合并 U3 | 同上 | 脚本 `/tmp/merge_dup.py`，已在线备份、空跑通过 | 等用户执行 DB 写入（见 §5） |

## 5. 待用户处理（统筹会话汇总，按时机）

- **重复登记数据合并（现在可以执行）**：PR #34 已合并、炼境已重编译。在「排查炼境 dev-manager-tauri 疑似重复登记」会话的输入框执行 `! python /tmp/merge_dup.py --apply`（写运行中的 DB；脚本带前置守卫与事务内断言，已备份）。跑完回复该会话「授权继续」，让它做 `unregister_project` 与验收。
- **Codex 信任**：Codex 只在目录受信任后加载项目 `.codex/config.toml`（P4-0 H-P8-1）。一键接入会把它列进 next_actions，炼境不改 Codex 的信任表。

## 6. 当前已知事实（易变，以工具自省为准）

- `verify_onboarding(enterprise)` 的 `clients` 三端均 converged。
- `list_all_projects`：除 enterprise 外，其余登记项目大多缺项目 token（历史接入早于 token 机制），这些正是一键接入要接的对象。
- 使者回传：0 条待处置。