code-task

编码任务

--agent 取值见 .agents/rules/task-management.md「合作者 token 规范」。

若入口业务操作数包含 --orchestrated，绑定 {execution-flag} = --orchestrated 并原样转发给 completed 事件；否则绑定为空。不得从 orchestration.json、环境变量或历史产物推断该标记。

根据已批准的技术方案编码任务，并产出 code.md 或 code-r{N}.md。本技能支持初次实现、基于 review-code 反馈的修复，以及人工裁决驱动实现三种模式。

行为边界 / 关键规则

• 严格遵循最新方案产物：plan.md 或 plan-r{N}.md
• 实现前读取 .agents/rules/compatibility-policy.md；只实现方案明确批准的兼容预算，不以“稳妥”为由保留旧分支、旧结果契约或迁移 shim
• 修复模式逐条核实最新 review-code 的发现：成立则修复，判定为不成立/幻觉则在报告中反驳并记入 unresolved；不擅自扩大到审查未列出的问题；manual-validation 项不在修复范围
• 实现中遇到方案未覆盖的关键设计决策时，先调用 agent-infra-internal task-ledger {task-id} decision-next-id 取得 HD-N，按 .agents/rules/human-decision-context.md 写入实现报告的 ## 人工裁决待办 详情块并判断是否需要实现，再调用 decision-upsert --id {HD-N} --stage code --artifact {code-artifact} --needs-implementation {true|false}；不得扫描编号、手写账本行、中途提问或擅自扩范围
• 绝不自动执行 git add 或 git commit
• 每轮实现都创建新的实现产物，不覆盖旧文件
• 执行本技能后，你必须立即更新 task.md

版本戳规则：创建或更新 task.md frontmatter 时，先读取 .agents/rules/version-stamp.md，并写入或刷新 agent_infra_version。

常见违规借口与反驳

动手实现前，若冒出以下念头，先停下——它们都是违规借口：

借口	反驳
「代码太简单，不需要测试」	简单代码也会回归；没有"失败→通过"的用例就没有完成标志，先写验证业务行为的测试。
「先写代码再补测试更高效」	后补测试常沦为对实现的镜像；目标驱动应先定义可验证用例再让它通过。
「方案这里不合理，顺手改更好」	偏离 {plan-artifact} 必须在报告中记录原因；有异议先停下确认，不擅自改方向。
「测试过了，顺便提交一下」	本技能绝不执行 git add/git commit，提交是用户显式发起的独立步骤。
「审查既然写了，照着改就行」	审查可能基于错误 file:line 或幻觉；动手前先 Read/Grep 核实，成立才修，不成立就反驳并记入 unresolved，不盲从。
「保留旧入口更稳妥，反正只多一个分支」	未获批准的兼容是范围扩张和长期债务；没有对象、必要性、期限和退出条件就只实现当前契约。

第 0 步：状态核对（执行前硬约束）

在加载 workflow / skill / rules 指令之后、做任何任务状态判断或用户可见结论之前，必须先执行状态核对。指令类文件读取不算对外动作或结论。

运行以下命令，并把原文粘贴到回复正文和本轮产物的 ## 状态核对 段：

agent-infra-internal task-snapshot {task-id} --format text

状态核对完成前，禁止任何关于外部状态的断言（例如“代码没变”“测试已通过”“没有其他引用”），包括思考阶段。本门禁只提供结构下限；逐条证据配对和真实性仍需按报告模板与审查要求核对。

任务上下文解析

入口允许省略 task ref，也接受旧位置 task ref 或 --task <ref> / -t <ref>。先从完整参数中分离 task scope 并原样保留其他业务操作数，再调用 agent-infra-internal task-context resolve {task-scope}；{task-scope} 为空、位置 ref 或 task flag 之一。只读取结构化结果的 taskId，后续把 {task-id} 绑定为该完整 TASK-YYYYMMDD-HHMMSS。解析失败时透传非零退出码，不自行扫描任务。