tk-drive

Drive 실행

사용자가 /tk-drive, $tk-drive 또는 소스가 포함된 호스트 스킬 선택기를 명시적으로 선택했을 때만 시작한다. 소스 없이 다시 호출하면, 같은 대화에서 현재 소스, 장부, Git, 저장소 근거가 하나의 승인 또는 대기 중인 실행을 명확히 가리킬 때만 재개한다. 일반 요청, 산출물, 새 세션은 Drive를 시작하거나 재개하지 않는다.

권한과 불변식

승인된 계획 하나로 준비, direct 또는 delegated 단위 실행, 필수 검증, 승인된 단위마다 하나의 검증된 현재 브랜치 커밋, 최대 세 번의 수정 라운드, 종합 검증, 최종화를 수행할 수 있다. push, PR, merge, tag, release, 발행, 이력 재작성은 포함하지 않는다.

Drive는 컨트롤러다. Delegated strategy에서는 제품, 테스트, 설정 변경을 직접 작성하지 않고 범위가 한정된 단위를 새 작업자에게 보낸다. Direct strategy에서는 현재 컨텍스트가 컨트롤러 역할을 잠시 내려놓고 승인된 단 하나의 단위 실행자가 되며, 동결된 소유 경로만 수정한다. 이것은 컨트롤러의 대체 경로가 아니다. 이 스킬은 사용자가 호출하므로, 명시적인 /tk-drive 또는 $tk-drive 호출 자체가 호스트의 사용자 요청 AgentTool 조건을 충족한다. Mechanical Git bookkeeping은 최종 후보가 통과한 뒤에만 컨트롤러가 맡을 수 있다. 호스트가 사용할 수 있는 작업자를 delegated strategy로 디스패치하지 못하면 Blocked로 중단한다. Direct strategy는 승인된 계획 기록 뒤 변경을 시작하며, 작업자를 사용할 수 없을 때의 암묵적 대체 경로가 아니다. 실행자는 다른 사용자가 소유한 TigerKit 워크플로를 오케스트레이션하거나 호출하지 않는다.

생명주기(Lifecycle)

Prepare -> Execute -> Close gaps -> Finalize

Drive가 이 생명주기를 소유한다. 자식 영수증은 내부 자료이며 continue, /clear, 모델 전환, 두 번째 호출을 요구하지 않는다. 호스트/프로세스 경계를 지난 뒤에는 커서나 생명주기 주장이 아니라 새로운 근거에서 다음 행동을 도출한다.

원천 우선순위

현재 대화의 명시적 사용자 요구와 같은 대화에서 확정된 결정은 가장 최신의 정본 원천이다. 우선순위는 다음과 같다.

현재 대화의 명시적 요구
> 같은 대화의 확정 결정
> 승인된 활성 run
> 현재 source와 일치하는 Ready 작업 문서
> 과거 terminal 문서와 durable prior-art

과거의 Status: Pass 장부나 완료 문서는 현재 요청을 덮어쓰지 못한다. 현재 대화가 완전한 원천이고 목표·범위·R/AC·검증 의무를 도출할 수 있으면, 과거 문서가 낡았거나 계보가 달라도 supersedes 근거를 기록하고 현재 작업 문서 세 개를 새 계보로 발급한다. 현재 원천이 불완전하거나 모순되거나 위험하거나 사용자 결정이 필요한 경우에만 Blocked다.

작업자에게는 대화 자체가 아니라 현재 원천을 반영한 자체 완결형 작업 문서를 전달한다. 따라서 과거 문서를 읽었다는 이유만으로 현재 요구를 누락하지 않으며, 현재 원천이 대화 안에 있다는 이유만으로 작업 문서의 완전성 검사를 생략하지 않는다.

준비(Prepare)

1. 阅读完整源信息和适用的仓库说明。首先，在当前目标 checkout 中通过 git rev-parse --show-toplevel 确认仓库根目录，并将结果替换为 <repository-root>，由此派生并读取以下四个绝对路径： <repository-root>/.tigerkit/drive.md、<repository-root>/.tigerkit/spec.md、 <repository-root>/.tigerkit/tickets.md、<repository-root>/.tigerkit/implement.md。 如果存在可选文件 <repository-root>/.tigerkit/session.md，则将其作为模型路由来源读取；缺少该文件本身不构成阻止工作文档的理由。 drive.md 仅负责进度、审批和收据。详细要求和指示仅放在三份工作文档中。首先固定当前对话源的标识符和明确指示，并将过往已结束的文档归类为先行依据。 根据文档规则和 工作者来源规则，如果当前来源完整，则为缺失文档以及过时或谱系不匹配的已结束文档签发新的 Pending 工作文档，并记录 supersedes。用户批准展示的计划后，将该文档更新为 Ready。只有当前来源不完整、存在矛盾或风险，或文档处于 Pending 且未获批准时，才将其标为准确的 Blocked 状态；不得分配工作者或修改产品。记录分支、基线 HEAD、工作树、pre-existing 变更路径，以及最多七项相关的持久先行依据。
2. 根据依据和安全默认值解决可逆的歧义。记录所有重要的 controller 选择、依据和会改变行为的备选方案。只有当用户拥有的决策阻止安全执行计划时，才调用 tk-grill-me。问题处于 pending 状态期间，输出 🙋 drive > grill-me · 응답 필요，且不 dispatch 工作者。只有在有限比较能够解决该决策时，才使用 tk-prototype。
3. 编写 Ready 要求和验收标准，其中包括当前来源标识符和替代谱系、范围、排除项、冻结的用户可见字面内容以及验证义务。
4. 推导可独立验证的 1..N 单位、依赖关系图和 wave。将相互耦合或不确定的单位串行化。只有当宿主已提供隔离的 checkout/工作树时，才并行处理已证明相互独立的单位。不要创建调度器，也不要让工作者同时共享可变工作树。
5. 对测试/检查进行分类。如果存在 browser-visible AC，则规划准确的场景、目标、非敏感认证模式、前置条件和限制，并将验证以 handoff 交给 tk-browser-verify。如果该 AC 需要开发服务器，还须一并传递准确的 command/cwd/目标 URL/auth mode/readiness 条件。Drive/controller/worker/direct executor 不得直接启动、等待或终止浏览器工具或开发服务器。服务器的 PID/port/log/readiness 及清理由 tk-browser-verify 负责；收到 verifier 结果前不得 commit。其他情况记录为 not-required。如果无法使用必需的 headless auth，或没有 verifier handoff，则在进行 mutation 前标记为 Unverifiable。
6. 根据 worker-dispatch.md，为每个单位选择执行策略和最低模型。如果票据中已确定 model/effort，则将其作为计划 metadata 使用，不得悄然覆盖。对于无隔离且属于边界明确的已知模式，优先建议保留 session model 的 strategy=direct；对于需要新上下文、隔离、审查者 handoff 或以设计为核心的推理，则建议采用 delegated，并说明依据。对于 Delegated，根据 skills/tk-drive/references/worker-dispatch.md#session-model-routing 中的规范 schema，验证并使用 .tigerkit/session.md 中当前宿主的 section 所对应的 routing。如果文件或当前宿主的 section 不存在，且三个 class 的控制值均已确认，则自行在 .tigerkit/session.md 中起草准确的嵌套 block，并将其设为 Status: Pending。对于已有的不完整或冲突 block，不得覆盖，而应提出修正方案。记录 routing_state=review-required；在用户审阅并批准草案之前，不得修改文件以外的 worker、产品、Git 或 remote。只有获批后才能将 Status: Ready，并通过 reread 验证。可执行 delegated 单位的审批必须显示 model class、selector、effort 和 routing 来源；缺少任何一项均应标记为 Blocked。配对使用 general-purpose implementer 和新的任务审查者；返回标签不得用于判定层级。 Model class/selector/effort 选择仅适用于 delegated。Direct 审批和台账不得为任何 label 标注 cheapest | standard | strongest tier；应记录 model_class=n/a、requested_selector=n/a、宿主公开的会话 realized_model 或 unavailable，以及 reasoning_effort=inherited。
7. 根据 ledger.md，原子性地替换 .tigerkit/drive.md 中的当前进度状态，并重新读取；之后提供一个简洁的审批界面。Ledger 仅保留当前来源标识符、supersedes 对象、仓库状态、四份工作文档及可选会话路径和状态、文档 status/lineage check、审批 snapshot、单位/dispatch/验证 receipt。目标、范围、冻结字面内容、R/AC 和实现指示由三份工作文档负责；未知项记为 unavailable。👍 Recommendation: 中须包含 strategy、model class、selector、effort 和路由来源；用户批准该计划即表示明确批准 direct strategy。不另行询问 direct 确认。这是审批依据，不是单独的生命周期输出。 审批问题就是工作界面。显示 🙋 drive · 응답 필요 和且仅有一个 👍 Recommendation:。 审批仅适用于所显示的快照。如果重要源、范围、分支/head、 远程状态、verifier 前置条件、不可逆决策发生偏移，审批即失效，并返回 Prepare。如果计划未变，则不进行日常的第二次审批。

执行（Execute）

对每个依赖波次应用冻结的 strategy。委派单元由新的 general-purpose implementer 负责，直接单元则由当前上下文作为唯一的 有界执行者负责。 向执行者提供 ID/goal、准确的 R/AC、源/工单范围、范围/exclusion、相关 路径，以及在当前目标 checkout 中解析的 <repository-root>/.tigerkit/ 下的四个 绝对路径、验证义务、分支/head/diff 所有权。 直接单元不得 spawn 子 Agent，并在完成 focused test 和自我审查后将候选结果交还给 controller。委派单元在 dispatch 前确认主机工作者 capability 和已批准的 session selector，并在 native model control 中明确指定。向 implementer 提供 task brief/report 路径，并在其完成提问、实现、focused test、自我审查和 commit 后，接收简短 report。随后向新的 general-purpose 审查者提供 diff package；在收到 Spec compliance 和 Task quality 两项 verdict 之前，不得将委派单元视为已完成。 每个委派工作者完成后，记录请求的 selector 和主机公开的实际 model receipt；未公开的值记为 unavailable。返回 general-purpose 本身不代表失败。遵守以下不变量。

candidate -> required tests/checks/browser verifier -> Close gaps
          -> bounded fresh correction when needed -> one verified unit commit

必需的 verifier 必须在 commit 前针对最终候选结果运行。仅 stage 已验证的所有权路径，并保留 pre-existing 用户更改。直接单元中隔离出的 gap 由当前执行者在同一冻结单元和所有权路径内弥补；委派 单元中的 gap 则通过 dispatch 新的 corrective 工作者来弥补，并重新 执行受影响的义务。优先最多进行三轮。补充缺失的上下文，不升级 model。 只有在存在已证实的推理失败时，才使用一次强一级的新 工作者。如果失败未改变、无法隔离原因、存在冲突或反复扩大范围，则停止 mutation。

集成冲突意味着独立性判断有误。将受影响的单元 串行化或重新 Prepare。工作者不得自行进行语义合并。 隔离、集成顺序、stale-base/conflict detection 和清理均由 Drive 负责。

补齐缺口（Close gaps）

对于每项已批准的 R/AC，根据观察到的证据将其分类为 satisfied、missing、partial、 unverifiable。只检查与验收相关的范围/exclusion、 单元、verifier、外部可见行为、commit/ancestry、dirty 路径 所有权和证据时效性。省略与该验收事实无关的 发现。

当无法仅凭证据做出有把握的判定时，最多 dispatch 一次使用相同精简 R/AC brief 的更强新非变更审查者。 只有当用户/存储库策略要求独立审查时，才使用可用的 内置或第三方审查者。如果无法进行必需的审查，则为 Unverifiable。 所有修正仍交由新的 corrective 工作者处理。

最终定稿（Finalize）

仅当至少存在一个委派单元，或已批准的计划要求独立的最终审查时，才 dispatch 一次新的 general-purpose 全分支审查者，以检查整个 diff 的 Spec/AC 和 质量。所有直接执行仅使用 aggregate checks 和自我审查。如果委派 审查发现问题，则仅进行一次新的 corrective 工作和一次范围限定的重新审查；将仍有关键影响的残留问题标记为 Blocked。 在所有已验证单元 commit 后，重新检查 aggregate R/AC 可追溯性、存储库检查、 ancestry、exclusion 和时效性。更新 .tigerkit/drive.md，纳入单元 commit、verifier/gap 证据、修正轮次、综合结果和恢复事实。如果未成功，则冻结 mutation，并 遵循 non-success-finalization.md。

成功时，输出简洁的操作结果、有用的单元 commit、一至四项综合验证，以及准确的 Status: Pass。活动执行的终端 响应只能由 Drive 输出。省略 Child receipt、原始日志、dispatch model 和进度标记。