tk-implement

实现 Ready 工单

仅在明确选择 /tk-implement 或 $tk-implement 时执行。 使用 git rev-parse --show-toplevel 确认当前检出的仓库根目录，然后读取 <repository-root>/.tigerkit/tickets.md 中恰好一个 Status: Ready 工单，以及 <repository-root>/.tigerkit/implement.md 中的指示。若没有输入或文档不存在， 则以 Status: Unverifiable 停止。 若状态为 Pending、状态过时、谱系不匹配，或 model/effort 未解决，则分别以 Status: Blocked 精确停止；不得创建更改、暂存内容、commit 或 receipt。

流程

1. 确认工单的最新谱系、准确的所有权路径、Scope、R/AC、Verification、符号化的 model 和 effort 均已解决。若为 delegated 执行，则在创建 worker 前确定 model，并按照 skills/tk-drive/references/worker-dispatch.md#session-model-routing 中规定的 schema 验证可选的 .tigerkit/session.md 主机路由，为 general-purpose 实现者 准备 brief/report 路径。若路由缺失或不完整，则提议按嵌套类别精确添加 model/effort Markdown，并设置 routing_state=decision-required，然后以 Status: Pending 停止。审批界面必须包含模型类别、选择器、努力程度和路由来源。 实施前，快照 git status --porcelain=v1 以及 .tigerkit/implement.md 的存在状态和字节内容；以字节为单位保留用户更改、索引和现有 receipt 的原始字节，并且仅在成功 commit 后追加内容。所有权路径之外的内容只能读取。
2. 对受限的低风险独立任务，建议使用 direct；若需要风险控制、范围隔离或新上下文，则使用 delegated。若必须使用 delegated，不得悄然改用 direct。任何 delegated 执行若无法调度必需的 worker，则以 Status: Blocked 精确结束，不得创建或修改更改、暂存内容、commit 或 receipt。 general-purpose label 表示预期的 worker 角色；不得根据返回的 label 事后判断 model/tier。direct 使用集中检查和自我审查，不使用 subagent。只有新的 general-purpose reviewer 确认 Spec compliance 和 Task quality 后，delegated 才能将 commit 视为成功。
3. 实现者仅修改准确的所有权路径，并优先运行针对性检查。
4. 仅在 delegated 执行，或用户/仓库策略要求独立审查时，才由能力高于 implementer 的 reviewer 检查 Spec/AC 和 Standards/Style。所有 direct 执行均不得创建此 reviewer。逐字内容或风格不一致均属 Blocking。
5. 若验证或审查发现差距，则每次都由新的、范围受限的 corrective worker 进行修正，并重新验证。若失败，则以 Status: Fail/Blocked 结束，不得暂存、commit 或创建成功的 receipt。
6. 仅当所有必需的验证和审查均成功时，才在当前 branch 上创建且只创建一个 commit；之后向 implement.md 追加 receipt，包含 unit/ticket、changed paths、check/review/gap evidence、commit/ancestry、delegated model_class/requested_selector/realized_model/reasoning_effort/worker_id/receipt_source，以及 unresolved: none。若主机未公开 realized model，则填写 unavailable。禁止 push、publish 或调用其他 workflow/skill。

输出仅简洁报告 receipt 的绝对路径，以及 Status: Pass/Status: Pending/Status: Blocked/Status: Fail/Status: Unverifiable。不要将 receipt 中的证据复制到聊天中。