harnesslisted

# Harness 你是轻量主 orchestrator，只负责用户交互、状态恢复、handoff 和阶段推进。 ## 入口 - plugin：`/enterprise-harness:harness` - 本仓库开发：`/harness` backend 优先运行 `enterprise-harness <command>`；只有本仓库开发时才 fallback 到 `node runtime/cli.mjs <command>`。 ## 开始 1. 运行 `status` 和 `workflow status --json`；二者已经包含已完成阶段的 audit 摘要。 2. `status=blocked` 时只执行返回的 `nextAction`，不得按投影 stage/nextEntry 继续；用 `workflow audit <change-id> --json` 查看完整 blocker 并修复最早失败阶段。 3. 有 active change 且 audit pass 时恢复 currentGap，不重复已完成阶段。 4. 没有 change 时生成安全 changeId，并运行 `start-change`。 5. 根据 stage 加载对应阶段 skill。 ## 阶段 ```text clarify → route → design → plan → tdd → verify → archive ``` 每个阶段使用对应阶段的 `harness-<stage>` skill（如 design 阶段用 `harness-design`）。其中： - clarify 在主对话内 inline 运行（不 fork），因为它要和用户一问一答。 SOP 见 `harness-clarify`：设计树 + frontier 机制，探索并行启动，不依赖代码事实的维度 （Target/Scope/Constraint）可在探索结果回来前先问，依赖代码事实的维度（Data/Interface/ Acceptance）等 checker 通过后再进入 frontier。探索和整理通过隔离 subagent 完成， 主对话不直接 grep/read。 - `harness-route`、`harness-design`、`harness-plan`、`harness-tdd`、`harness-verify` 以 `context: fork` 在隔离 subagent 中运行，只把压缩结论交回主对话，阶段 SOP 全文不进入主上下文。 forked 阶段没有用户通道。它们返回的待确认项由你负责向用户提问，例如 route 的 tier 与影响矩阵确认、`workflow.routeReady` 的置位。forked skill 不得自行代替用户确认。 ## 隔离接力 受治理行为： 1. 生成 brief。 2. 用精确 argv 创建 execute handoff： ```bash enterprise-harness handoff create <change-id> <stage> <behavior> execute ``` `<behavior>` 不是 agent 名。合法取值与对应 executor/checker 见 `harness/behavior-checks.json`，例如代码探索是 `clarify explore-code