harness-planlisted

# Harness Plan 由 plugin 入口 `/enterprise-harness:harness`（本仓库开发为 `/harness`）按当前 stage 加载。 ## 上下文边界 你在 forked subagent 中运行，没有主会话历史，也没有和用户对话的通道。 - 权威输入只有 change 目录里的 durable artifact，不是聊天记录。 - 需要用户决策时在 blockers 里写明，交主 orchestrator 去问。 - 你仍可派 executor 和 checker subagent，这是本阶段的核心要求。 - 返回给主 orchestrator 的是压缩结论，不是 tasks 全文。 ## 输入 - approved design 和 digest - impact/reviewer requirements - project command policy ## 动作 1. 为每个 task 生成 task brief。 2. 对 `plan.produce` 创建 execute handoff，派 `plan-executor` 生成： - taskId 和目标 - touched files - test-first order - RED/GREEN evidence point - dependencies - acceptance 3. 在 `task-commands.json` 冻结每个 task 的 red/green/refactor 或 verify exact argv。 4. Maven argv 必须符合 `harness/command-policy.json`。 5. 等待 `plan.produce` 的 `result.json` 后，以其 runId 创建 check handoff，派 `plan-critic` 独立检查可执行性和遗漏；只有 `check.json` verdict 为 pass/advisory 才可 `freeze-plan`。 ## 产出 - `tasks.md` - task briefs - `task-commands.json` - plan checker verdict ## 阻断 - design 未 pass - task 无具体测试或 RED 点 - 命令只写自然语言 - task 太大或顺序不明确 - checker block ## 下一阶段 plan pass 后，主 orchestrator 必须依次执行： ```bash enterprise-harness workflow decide <change-id> freeze-plan enterprise-harness validate <change-id> ``` 第一条将 `planReady` 置 true 并推进到 tdd 阶段；第二条验证静态阶段链 （requirements/change/design/tasks/reviews 完整性）并落 `evidence/stage-gate.json` marker。 pre-write hook 只查这个 marker，不再每次写文件全量重算阶段链。若漏执行 validate， tdd 阶段第一次写受治理路径会被 pre-write block。 需要返工时用 `revise-plan`。