/test-router

name: test-router
description: 测试路由规范 — 根据变更类型、影响范围与风险选择静态、单元、集成、API、E2E、场景/负载、pack 或发布验证，并记录跳过理由

Test Router Skill

TestRoute 的稳定输入、route selector、固定输出与 skip 合同以同目录 `test-route-schema.json` 为唯一结构化事实源；领域专用证据保留在对应 Owner Skill，不再全部提升为 TestRoute 顶层字段。

职责

`test-router` 只负责选择验证路线和记录跳过理由，不替代 `dev-testing`、`api-verification`、`dev-scenario-test` 或项目自身测试规范。

输入

机器可读输入、selector、输出与跳过字段以同目录 `test-route-schema.json` 为唯一事实源。稳定输入只有：

`workflow / changeTypes / risk / publicSurface / runtimeBoundary / profileConstraints / candidateState / capabilitySurfaceDecision / requestedClaims / verificationIntent`

领域专属证据不得复制进 TestRoute 输入清单；先从 `../spec-governance/gate-registry.json` 解析适用 `gateGroup`，再由目标 Owner Skill 提供证据字段和阈值。

VerificationIntentV2 请求面与执行层级

必须先判断“本轮要证明什么”，再选择可执行节点。`VerificationIntentV2` 只表达请求，不授予执行权；固定包含 `requesterClass / requestedLevel / requestedPurpose / affectedBoundaries / riskClass / requestSourceRef / project / candidateId / changedScopeDigest / claimCeiling / requestDigest`。执行必须另行取得绑定 `ValidationRunIdentityV1`、候选/HEAD/dirty scope、计划、预算、actor/context 与 hard deadline 的 `VerificationExecutionLeaseV2`；V1 只允许兼容读取，不能产生新 authority：

| level | 默认 purpose | 允许的最大声明 | 典型入口 | |---|---|---|---| | V0 | `edit-loop` | 单点编辑证据 | `test:fast` 或精确单测 | | V1 | `delivery` | 当前变更影响闭包 | `test:changed` / `test:delivery` | | V2 | `boundary` | 已列明边界的资格结论 | `test:boundary -- --boundary <owner>`、profile/package 兼容边界 | | V3 | `full-audit` / `release` | 全审计或发布候选 | `npm test` / `test:full`；发布还需显式 release authorization |

`risk=high`、R3/R4、ECR、控制面命中、文件数、cache miss/stale、未知输入或消费者图不完整都不是 V3 授权。未知 executable input 在 V0～V2 必须升级到**当前等级允许的** full fallback closure，并显式排除更高等级、尤其 release consumer；这不是 V3，也不能提升 claim ceiling。V0/V1 命中高风险或控制面时，只能扩张到可证明的 V2 边界；无法安全推导时输出 BLOCK、缺失边界和下一步。V3 必须有明确 `full-audit` 请求，或 release-pipeline 在已有发布授权下请求 `release`，并取得匹配 `planDigest + budgetDigest` 的 BudgetCard 确认和 LeaseV2；请求对象本身不能启动执行。

消费者边必须区分 `runtimeConsumer / qualificationConsumer / releaseConsumer`。V1 只沿 runtime 边扩散，V2 可再沿 qualification 边扩散，release consumer 只在 V3 激活。`fast` 必须保持动态 V0；兼容入口 `profile-deploy` 与 `package-release` 分别固定为 profile/package V2 边界，不能因同一工作树还有其他变更而吸收其他边界或 V3 节点。V0～V2 的 `ValidationEvidenceV2` cache 身份绑定 `HEAD + 所有匹配节点声明输入的 dirty digest + node contract + node verification policy + dependency nodeReceiptDigest + runtime + cache policy`；缓存只写项目/工作区 `.tmp/devcodex/cache`，pack/install/security/real-host/time-sensitive/shared-write/delegated 节点永不命中。节点回执摘要向下游级联，不能用未变的 stdout 掩盖上游输入漂移，也不得绑定整个 candidateId 造成无关重跑。执行前必须重新核对 manifest identity、candidate identity 与 plan digest；任一绑定变化只重跑失效前沿。V3 禁止复用节点 cache，必须执行冻结候选的完整节点集合。

`ValidationExecutionScheduleV2` 只并发 normal 且无共享写域的节点；默认 `--max-concurrency 2`、上限 4，package/Profile/TaskRecovery/security/real-host 与无法证明隔离的节点保持 singleton。managed runner 始终独占 plan、cache、checkpoint、progress 和 terminal receipt 写权，node worker 只返回结果；`--max-concurrency 1` 必须与原串行 selected/result/failure/exit 语义等价。run scratch 使用 `.tmp/devcodex/runs/<operationId>` 并在成功、失败、超时后精确清理。ETA 来自 `.tmp` 下的有界成功历史和 wave critical path；不足 5 个可比样本只显示低置信范围，不把 timeout 当 ETA。

SkillRoute、用户自定义 Skill 或分层解析变化必须选择 `static + unit-integration + runtime-e2e`，执行 manifest 节点 `skill-route-stage-b` 和既有 `skill-route-contracts/budget/state/lifecycle/closure` 链。证据至少覆盖 1/100/1000 Skill、未选正文读取为 0、`project > workspace > bundled/global`、`resolve_exact` 不经 catalog、完整依赖/正文分页、reserved/path/TOCTOU/超大/循环负例以及宿主个人 Skill 不重复注入；总 Skill 数或目录总页数不得成为主任务 deny。测试 scratch 只能进入项目/工作区 `.tmp` 并精确清理。

V3、非发布计划估算超过 600 秒或包含 heavy 节点时，先输出绑定 `planDigest + budgetDigest` 的 `BudgetCardV1`。`estimatedDurationMs` 必须使用 manifest estimate 或有上限的默认估算，并同时公开 `estimateConfidence`、独立的 `hardTimeoutUpperBoundMs`、`logBudgetBytes` 与 `waitReasons`；禁止把所有 timeout 简单相加冒充预计耗时。只有匹配摘要的确认才能签发 LeaseV2；确认不得复用于候选、计划或预算摘要已经变化的下一轮。执行由 `ManagedValidationRunnerV2` 消费 lease 并持久化 exactly-one terminal receipt，调用方不得用进程退出文字自行补写终态。

AI Hook 在生成 BudgetCard 前必须由当前宿主 session 解析出唯一、fresh、server-owned 的正式任务绑定，并把 `taskRecoveryKey + contextEpoch + authoritySourceRef` 纳入同一计划身份；缺任务、跨 session、任务键冲突或缺当前 ContextRead epoch 时直接 BLOCK，不得先让用户确认一个无法执行的摘要。确认后的执行还必须提交本次确认消息的 digest；TaskRecovery evidence store 必须重新读取同一 session 的任务身份并与 LeaseV2 对账，禁止仅凭 caller 提供的 task key、`sessionKey` 或“最近任务”落盘。

`BudgetCardV1` 永久不可变。confirm 模式把当前 exact card 先写成唯一 `PendingBudgetCardBindingV1`，用户只需确认当前卡，由服务端以 CAS 生成 `BudgetConfirmationReceiptV1`；有效 Sticky Auto 可为 V0～V2 签发同等精确的 server-owned receipt，但不能扩大到 V3/full/release。父运行失败后，`ValidationContinuationAuthorizationV1` 只接受三类证明：完整 `mutation-observation`；stable/clean candidate 的严格 Git 后继 `committed-repair-diff`（父 changed scope 未截断且为当前子集，完整 commit diff 被当前显式 changed scope 覆盖）；或同 HEAD、无新增 dirty 路径/节点/预算的 `same-scope-retry`。三类 child retry 合计最多两次且始终相对 root；禁止用同一旧 Auto authority 换根清零或 child-to-child 复利。前两类仍须满足 task/project/root/session/purpose/boundary/heavy/side-effect/revocation 一致或收窄，相对 root 新增节点不超过 `min(3,max(1,ceil(root*5%)))`，estimated/hard-timeout/log 增量分别不超过 `min(60000ms,ceil(root*5%))`、`min(600000ms,ceil(root*5%))`、`min(65536B,ceil(root*5%))`，且不得新增 release consumer；same-scope retry 的节点与全部预算增量必须为零。父运行已终态、无 live lease且父 candidate HEAD 为当前已提交 HEAD 的严格 Git 祖先时，root rollover 仍要求 task/project/root/session/revocation 一致；沿用原 context/AutoRef 时 level、purpose、节点、boundary、heavy、副作用、estimated/hard/log 必须与父根逐项完全相等并使用 `strict-descendant-same-scope`，当前 fresh server-owned Auto 的 exact scope 未变时可重绑 context/AutoRef 并使用 `strict-descendant-exact-scope-current-auto-rebind`。若一个晚于父终态的不同真实用户 Auto 指令形成 fresh control，且 source digest、AutoRef 与 context epoch 均更新，则它可用 `strict-descendant-current-auto-rescope` 为当前精确 V2 影响范围建立新 root；这不是 child continuation，不继承旧范围，也不得提升为 V3/full/release。三种 root rollover 都必须保留 `parentRootReceiptDigest + parentTerminalDigest`。已提交修复必须显式传入冻结 changed files；clean tree 不能偷偷收窄范围；同一或过期 Auto authority 的非续权扩大/收窄统一返回 `auto-root-rollover-scope-changed`。plan-only 与 execute 必须复用同一 continuation/root-rollover preflight；plan-only 只返回是否可续或滚动，不消费 authority。过期 Auto ingress 只允许继续既有 root，或在原 context/AutoRef 精确一致时执行 ex