| 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 授权。V0/V1 命中高风险或控制面时，只能扩张到可证明的 V2 边界；无法安全推导时输出 BLOCK、缺失边界和下一步，不得 silent full。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；节点回执摘要向下游级联，不能用未变的 stdout 掩盖上游输入漂移，也不得绑定整个 candidateId 造成无关重跑。执行前必须重新核对 manifest identity、candidate identity 与 plan digest；任一绑定变化只重跑失效前沿。V3 禁止复用节点 cache，必须执行冻结候选的完整节点集合。
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 精确一致时执行 exact-scope 根滚动；其他创建/替换 root 需要当前 fresh control。pause/stop/scope reduction 立即递增 revocation epoch 并撤销 pending/child/lease；cold/terminal 状态不得恢复执行 authority。
ConvergenceFirstValidationV1
多 finding / 多批次 / 发布收口必须先冻结完整问题集，再批量实施，最后统一验证。issue-set、repair generation、implementation-complete、统一 affected run 与 final freeze 由工作流编排及项目证据 Owner 持有；validation runner 不自行发明或覆盖这些状态。编排 Owner 未证明全部 repair batch 完成时不得启动资格级 V1/V2/V3；语法/schema/materialization 检查不产生 ValidationEvidence。批次完成后，编排 Owner 只允许为同一冻结问题集、候选与 dirty scope 创建一张统一 affected V2 计划。Runner 继续执行独立节点并在 receipt 的 failedNodes 中一次收集全部失败，durable terminal projection 有界保留完整失败节点集合与紧凑摘要，只把依赖失败/依赖阻断节点写入 abortedNodes + abortedNodeReasons；首个失败不得触发逐项修测。affected 收敛并冻结候选后，发布管线只能创建一次 V3/full root。
新增关联 P0/P1 会使工作流 Owner 持有的 issue-set generation 单调递增，并使已建但未执行的计划 stale。验证计划和回执只绑定 exact candidate/HEAD/dirty scope、节点与授权；issue-set/freeze 证据由发布编排在启动 runner 前对账并随正式任务产物留存，不能把这些尚未进入 ValidationPlanV3 schema 的字段宣称为 runner 原生输出。
路由选择
| selector | 触发边界 | 最小证据 |
|---|
static | 源码或契约变化 | command、exitCode |
unit-integration | 行为或跨模块变化 | suite、result、coverageDecision |
api | HTTP 或 public API 边界 | endpointMatrix、双 API 产物、result |
runtime-e2e | 用户路径或运行时状态变化 | target、stateMatrix、result |
package-release | package candidate 或 release 声明 | candidateDiff、pack、install、registry |
profile-deploy | Profile、宿主或分发面变化 | profileValidation、deploymentParity |
先按变化事实选择所有适用 selector，再用风险扩大 V0～V2 内的影响边界。风险本身不得升级到 V3。不得仅因“已有单测”跳过跨边界、真实 runtime、package candidate、Profile 或部署副本验证；不适用的 selector 必须形成结构化跳过记录。
brandVisualQuality 是 brand-visual-quality gateGroup 的领域绑定，不新增顶层 selector：至少选择 static，并用 Owner Skill 的同画布渲染、微尺寸/单色预览和人工视觉结论补充 evidence；涉及网站或产品运行态采用资产时再叠加 runtime-e2e。若任务只改 token/component 而不生产品牌资产，写结构化 skipReason 并交给设计系统 Owner。
localObservability 是 local-observability-contract gateGroup 的领域绑定：CLI JSON/human/error/exit 选择 unit-integration + runtime-e2e；typed local probe 追加 dependency/error/zero-write fixture；进入 package/公开文档时叠加 package-release / profile-deploy。
turnLiveness 是 agent-turn-liveness gateGroup 的领域绑定，不新增顶层 selector：至少选择 unit-integration + runtime-e2e，执行 fixed-clock 状态机、Hook direct replay、no-continuation、active lease、restart rehydrate 与 duplicate recovery；CheckpointValidationResultV1 必须覆盖 response-time/post-execution、缺证据与 timeout；LocalTaskTraceV1 必须覆盖 sequence/duplicate/terminal/restart、payload 不执行和 source state zero-write。触达 Profile/部署或 gray sidecar package 时再叠加 profile-deploy / package-release。Hook 无事件自唤醒能力未由宿主或 sidecar 实证时，coverageClaim 必须降级并保留 residualRisk。
context-acquisition 是同名 gateGroup 的领域绑定，不新增顶层 selector：契约、Profile/Memory MCP 或 Hook receipt 变化至少选择 unit-integration + runtime-e2e；规范、Prompt、README/website 或部署面变化叠加 static，触达 Profile/宿主分发时再叠加 profile-deploy。Owner evidence 至少链接 IntentSeed/plan/receipt correlation、ContextReadBindingV1（request-bound；legacy-unbound 不得 claim complete）、ProfilePlanNoHiddenFullReadProbe、bounded memory query、failed-Pre/false-complete 负例、legacy compatibility 与 V99。ValidationExecutionReceipt 须携带 testRouteDigest 与可选 intentExpansionDigest（PF-149），使 TestRoute 选择与上下文绑定可对账。性能证据记录 bytes/chars/latency/cache/escalation；input tokens 不可观测时必须标 N/A，不能用 chars 冒充。staged consumer 只允许精确列出 missing consumer 与后续 Owner batch，不得把 known-red 泛化为通过。
executionChainOptimization 是执行链性能与稳定演进的领域绑定：至少选择 static + unit-integration + runtime-e2e，执行 manifest 节点 execution-chain-evolution、V101、任务/Context/Profile/Skill/knowledge 的 full-only 负例，并逐一验证 ExecutionOptimizationFeatureDecisionV1 在 off / shadow / rolled-back / sunset 下真实阻断六类优化消费者。validation 的关闭路径必须是保留显式 intent/route 且禁用 cache/reuse 的 direct-validation-plan，不得转成 full；其余消费者走各自完整读取 fallback。触达 Profile/部署叠加 profile-deploy，公开 package/benchmark 脚本叠加 package-release smoke，网站说明变化追加 website build/link。只有安全 fallback、correctness oracle 和可比 benchmark 都通过才可声明 accepted；否则状态保持 provisional，但 full-only 正确路径必须继续为 green。
derivedArtifactFreshness 绑定 skill-lifecycle 或对应派生资产 Owner，不新增顶层 selector：至少选择 static + unit-integration + runtime-e2e，覆盖确定性生成、先生成后 stage 的负例、精确 staged/index candidate check 与 post-commit clean-tree replay；触达 Profile/部署副本叠加 profile-deploy，触达 package/release candidate 叠加 package-release。working-tree check、staged check 与 post-commit replay 必须分别记录 candidateState，不能复用一次结果冒充三种状态。
repairPreventionAssessment 绑定 active repair-prevention-assessment，不新增顶层 selector：所有 repair 至少选择 static + unit-integration，分别绑定当前 defect 的 regression/negative evidence 与 prevention decision 的 prospective/rollback evidence。高风险、repeat escape、emergency-active、控制面或公共契约再叠加 runtime-e2e 和适用的 package/profile 路线；当前修复重跑只能进入 immediate closure，不得填充 prospective effectiveness。返工指标或长期效果验证才额外绑定 gray rework-prevention-engineering。
baseAdmissionGovernance 绑定 spec-absorption / skill-lifecycle-governance，不新增顶层 selector：新增或晋级规范、Skill、Prompt、流程、验证器或部署消费者至少选择 static + unit-integration，并记录 BaseImpactAssessmentV1、ComplexityDeltaBudgetV1、UnaffectedIntentRegression、replacementOrRetirementCredit、回滚和退役/删除条件。base-changing 叠加 runtime-e2e + profile-deploy，且必须有单独确认和未受影响意图负样本；普通 chat/dev/fix 不因此增加默认验证路径。V96 负责正负向分类器证据。
visibleOutputContract 绑定 user-visible-output-contract，不新增顶层 selector：任何 ArtifactDeliveryManifestV1、UserFacingArtifactSetV1、PostCompletionActionSetV1、EntryCheckModelV3、DevCodexVisibleEnvelopeV3、HostLinkCapabilityDecisionV2、ArtifactDeliveryAttemptV1、V1/V2 兼容 parser、renderer 或 visible-reply Hook 变化至少选择 static + unit-integration + runtime-e2e，覆盖 planned/observed/internalDelivered 对账、required hidden=0、计数守恒、六 message kinds、完成态 requiredNow=0、动作适用性与授权负例、V1/V2 只读/V3 只写、PC0~PC10、presentationSurface 主选 renderer、renderer-only、action/readback、missing target、absolute fallback、compact eligibility、legacy/unobserved ceiling、semanticDigest 和 rich/portable/plain 等价性。触达 README/website/Profile/部署副本时叠加 profile-deploy，进入 package public surface 时叠加 package-release。宿主 capability 未 direct replay 时必须保持 ready/fallback 或 unverified；未同时观察 action 与 readback 成功不得声明 opened。
evidenceFreshness 绑定 report / analyze-default / audit-report / review-checklist，不新增顶层 selector：强主张新鲜度、summary-only 降级、外部 finding 采纳、artifact anchor 或 final validation summary 绑定变化至少选择 static + unit-integration，执行 npm run test:evidence-freshness 并在控制面或当前消费者同步时叠加 node scripts/validate.js 与 profile-deploy。若只是普通报告没有 strong claim，写 N/A + skipReason=no-strong-claims。
expertOutputQuality 绑定 expert-output-quality / V84，不新增顶层 selector：代码、文档、示例、fixture、技术方案或报告命中专家型质量时，至少选择 static（并优先 node scripts/test-spec-governance.js + 控制面变更时 npm run test:core），证据链覆盖 ExpertOutputQualityGate、生产推荐路径、fixture 边界与 MeasuredVerificationStandard（生产入口命令 + exitCode；隔离 harness 不得冒充 V84 成败）。Owner 字段与完整门禁见 skills/expert-output-quality/SKILL.md 与 gate-registry expert-output-quality。
requirementParallelOrchestration 绑定 requirement-parallel-orchestration，不新增顶层 selector：新增或修改多需求并行判定、SharedSurfaceLockMapV1、ParallelLaunchCardV1、IntegrationMergeProtocolV1 或相关消费者时，至少选择 static + unit-integration，执行 npm run test:requirement-parallel-orchestration。触达 Skill portfolio、validation manifest、package/plugin、README/website/Profile 或部署副本时叠加 control-plane / profile-deploy 对应命令；缺负向探针不得声明可并行。
capabilitySurfaceDecision 只接受中央 decisionRef / status / identity / preferredSurface / validationRoute 的只读投影，不复制判定矩阵。新增或改变 Rule/Skill、Prompt、MCP Resource/Resource Template/Tool、Task 增强 Tool、CLI 或 Hook 时，至少选择 static + unit-integration 并执行 npm run test:capability-surface-decision；触达 MCP runtime、宿主 adapter、package、Profile、public docs 或部署副本时按 decision 的 validationRoute 叠加 runtime-e2e / package-release / profile-deploy。decision 缺失、stale、blocked 或 identity 不匹配时不得降级为 skipped。
发布候选验证
package-release selector 可在 V2 只表示 package compatibility 边界；它不会执行 tag、publish 或 registry mutation。只有 release-pipeline 在当前发布授权下取得 purpose=release、level=V3 的 LeaseV2，才必须调用 release-verification，并把 npm run test:audit、package completeness gate、publish dry-run、ExactReleaseArtifactV1 和远端 CI 作为独立证据记录。publish dry-run 只验证发布通道、registry 与候选元数据，不等价于真实 publish，也不能替代 exact artifact、远端 CI 或发布后 registry 对账。pack 或本地 install 通过不能替代远端 CI，也不能替代发布前的 package completeness gate；未形成真实发布候选时必须记录 skipReason，不得把普通开发验证写成发布完成。
CI 影响面执行
远端 CI 必须从 scripts/validation-manifest.json 的同一 ValidationImpactGraphV2 生成 CiValidationPlanV1，不得在 workflow 内维护第二套路经分类。普通 push/PR/手动 affected 只执行计划选中的节点；package/installer/host activation 变更才追加 package boundary。nightly、release、用户手动 full，以及 changed-file 截断、impact graph 不完整或 planner blocker 才进入 full。planner 异常必须使 aggregate BLOCK 并公开原因，禁止静默改成无条件 full。
CiValidationAggregateReceiptV1 必须对账 planner digest、目标 HEAD、required node receipt 与各条件 job 结果。同一 SHA 已有可信 receipt 时，本地不得机械重复等价 full、pack 或 install；修复 CI 失败时默认只重跑失败节点及其失效依赖，除非实际边界或候选身份已经改变。
TestRoute 输出
输出固定为 verificationIntent / validationPlan / budgetCard / verificationExecutionLease / validationExecutionReceipt / selectedRoutes / commands / evidence / skipped / residualRisk / coverageClaim。推荐使用以下最小结构：
workflow: fix
changeTypes: [control-plane, documentation]
risk: high
verificationIntent:
schemaVersion: VerificationIntentV2
requesterClass: ai
requestedLevel: V2
requestedPurpose: boundary
affectedBoundaries: [validation-control-plane]
riskClass: high
requestSourceRef: confirmed-CP3
project: devcodex
candidateId: <candidate-id>
changedScopeDigest: <sha256>
claimCeiling: boundary-qualified
requestDigest: <sha256>
validationPlan:
schemaVersion: ValidationPlanV3
executionState: ready
budgetCard:
schemaVersion: BudgetCardV1
confirmationRequired: false
verificationExecutionLease:
schemaVersion: VerificationExecutionLeaseV2
runIdentitySchema: ValidationRunIdentityV1
runId: <stable-run-id>
hardDeadlineAt: <iso-time>
validationExecutionReceipt:
[ ]
[{ , }]
[ ]
[{ , }]
跳过规则
每条跳过记录必须包含 route / reason / authority / residualRisk / upgradeCondition。缺少任一字段、用“暂不需要”作理由、或目标声明需要该路线却没有可替代证据时，TestRoute 不得标记完整。
高风险、公共契约、控制面、发布候选和跨宿主分发变更至少要求两类独立证据；若无法执行，结果必须降级为 partial/blocked，并把升级条件带入报告与 ContextHandoffCard。
报告要求
dev/fix/optimization/scenario-test 报告应包含 TestRoute 或明确 N/A，ECR-3/ECR-4 应引用实际执行结果。若命中宿主验证，还应同时引用 host-contract-verification 的 HostContractRoute 结果，包括适用时的 mcpFallback=used；若命中用户可见输出，必须引用 manifest/visible set/envelope/capability/attempt 的同一 semanticDigest、action/readback/fallback 与 renderer parity 结果。
