code-autonomous

Code Autonomous

具备 Harness 感知能力的执行引擎：决定规划深度、消除疑问、调度多 Agent 协作，并通过审核关卡完成闭环——既可作为独立流水线，也可作为其他技能的执行引擎。

隔离不变量（不可妥协）

除非人类明确指示本次运行“不要创建新分支／在当前分支上原地工作”，否则此技能绝不会在主产品检出目录中编写应用代码，也绝不会提交到 main／master（或任何基准分支／SOURCE_BRANCH）。

• 独立模式和引擎模式都必须先准备好隔离的 WORK_BRANCH 和 WORKTREE_ROOT，之后才能进行任何实现编辑。
• 如果创建工作树失败，或当前工作目录／分支仍是主检出目录／基准分支 → 停止。不要为了“解锁计划”而“继续在 main 上工作”。
• 沙箱限制（Operation not permitted、.cursor/ 下的 Cursor Agent 运行时路径）不构成违反此不变量的许可。

Harness 发现

参见 ../nextstage-harness/references/harness-discovery.md。

路由（先阅读）

1. 来源是 GitLab issue（ISSUE_URL 或 issue 引用）→ 从头到尾遵循 execution-gitlab-issue；此技能仅作为其第 2 阶段引擎运行（见下文“引擎模式”）。不要运行独立流水线，不要触碰 GitLab 状态，也不要创建工作树。
2. 其他情况（本地计划文件、粘贴的文本／计划、没有 issue 的临时自主请求）→ 运行独立流水线：自行管理工作树、状态和审核循环。

完整决策详情和引擎模式的输入／输出约定，请参见 references/routing.md。

引擎模式（由 execution-gitlab-issue 调用）

输入（已由调用方解析——此技能绝不创建这些内容）：issue 负载、{product_root}、WORKTREE_ROOT、WORK_BRANCH、SOURCE_BRANCH。

1. 自行决定规划深度——评估 issue 负载，并决定采用单个工作单元，还是在 docs/versions/{version_san}/ 下编写精简的 requirements.md、tasks/task-NNN-*.md 和 execution-plan.md。参见 references/planning-decision.md。
2. 疑问处理流程——自行提问，优先查阅文档，自行解答非破坏性疑问；将破坏性疑问作为结构化事件上报给调用方，而不是修改 GitLab 状态；依赖这些疑问的工作单元暂停，直至恢复。参见 references/doubt-resolution.md。
3. 多 Agent 调度——解析工作单元（或单个单元），并调度 code-coder 子 Agent；仅在单元之间没有 DAG 边且文件范围互不重叠时并行执行，否则按顺序执行。每个子 Agent 都必须在 WORKTREE_ROOT 内工作，绝不能在主检出目录中工作。参见 references/multi-agent-dispatch.md。
4. 检查点提交——每个已完成的顺序单元或每批已完成的并行任务提交一次；提交必须在工作树内进行，调用方会在交付时压缩提交。
5. 修复循环入口——收到 Rejected 结论后重新调用时，将审核者的发现视为新的工作单元（或多个单元），仅针对这些单元重复步骤 3。
6. 返回调用方：单元状态、变更文件、尚未解决的破坏性疑问，以及（仅在首次调用时）基于计划的时间估算，供 set_issue_estimate 使用。

独立流水线（非 GitLab 来源）

与 Engine 模式的内部机制相同，但此技能负责整个运行流程：

1. 解析描述符——本地计划路径或粘贴的文本。不调用 MCP。
2. 推断 change_kind（fix/feat），分配 {version_san}，创建 docs/versions/{version_san}/。
3. 创建自己的 worktree：从已解析的基分支创建 {product_root}/.worktrees/{version_san}/ + 分支 work/{version_san}，遵循 ../nextstage-harness/references/worktree-setup.md。路径位于产品根目录下，绝不能位于 .cursor/ 下。失败时 → 中止（不得回退到主检出目录）——请参阅 references/standalone-pipeline.md。
4. 规划深度自决、疑虑处理协议（破坏性疑虑 → 仅聊天的关卡，不提供 GitLab 操作）、多 Agent 调度——与 Engine 模式逻辑相同。
5. 内部审查循环——调用 code-reviewer（version-closure 模式），最多 3 轮：遇到 Rejected 时修复单元，遇到 Blocked 或轮次耗尽时停止。
6. 报告 {version_san}、worktree 路径、提交、审查结论及任何后续事项。不创建 GitLab 看板，也不创建 MR——除非 docs/context/gitlab-sync-config.md 存在且人工明确要求创建（不在 v1 范围内；否则独立模式仅限本地操作）。

完整流程请参阅 references/standalone-pipeline.md。

停止并询问人工

条件	操作
破坏性疑虑（Engine 模式）	向调用方返回升级事件——此处不暂停聊天
破坏性疑虑（独立模式）	暂停聊天并询问，将答案作为上下文继续
同一 {run_id} 的 worktree 冲突（独立模式）	除非明确要求恢复，否则停止
git worktree add 失败（权限/沙箱/路径）	中止——报告尝试过的路径；绝不回退到主检出目录或 .cursor/
即将编辑代码时仍处于 main/master/基分支	中止——缺少隔离；不要实施
人工明确表示“不要创建新分支／在当前分支中工作”	仅此时可编辑当前分支；仍绝不能自行创建 .cursor/ 路径
独立 worktree 的基分支未解析	停止——询问一次
审查结果为 Blocked 或 3 轮审查耗尽	停止并报告为受阻——不得捏造成功结果
使用了带 GitLab 来源的 Engine 模式，但未提供 worktree/分支	停止——这是调用方违反约定，而非疑虑

相关技能

技能	角色
execution-gitlab-issue	GitLab 流程负责人——在 Phase 2 调用此技能
code-coder	按工作单元实施时使用的子 Agent 模式
code-reviewer	审查关卡（调用方使用 issue 模式；独立模式使用 version-closure 模式）
nextstage-harness	工件布局、worktree 机制、发现

参考资料

文件	适用场景
references/routing.md	Issue 与独立任务的判定；Engine 模式下与 execution-gitlab-issue 的 I/O 约定
references/planning-decision.md	自我评估启发式：单个单元还是需求 + 任务 + 计划
references/doubt-resolution.md	自问、优先查阅文档、破坏性操作判定标准、升级处理方式
references/multi-agent-dispatch.md	DAG + 互不重叠范围的并行规则、子 Agent 提示词、检查点提交
references/standalone-pipeline.md	完整的非 GitLab 工作流：版本分配、自有工作树、审查循环