project-tiny-context-harness 0.2.70 → 0.2.72

package/assets/skills/context_development_engineer/SKILL.md

@@ -20,7 +20,7 @@ Project-specific engineering rules belong in a separate project-local Skill unde
 1. 先读取 `project_context/global.md`、`project_context/architecture.md` 和 `project_context/context.toml`，按 default area、triggers、read_when 选择相关 context。
 2. 先确认用户目标、约束、成功标准、影响产品域、现有验证 / 部署关键路径和风险；能从代码或 Context 发现的事实不要反复询问用户。
 3. `project_context/**` 决定“应该是什么”：模块职责、归属、架构边界、接口方向、契约语义和禁止依赖；代码决定“现在实现到了哪里”。代码不能静默重定义 Context。
-4. 第一处代码编辑前，若任务影响 durable architecture boundary、module ownership、API / Schema / data contract、state / runtime semantics、dependency direction、verification / deployment semantics 或 durable rationale / tradeoff，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 完成唯一正式长期事实判断，再写本次 `Task Contract`，并显式写 `Architecture Context Hit` 和 `Decision Rationale Hit: existing|required|none`。
+4. 第一处代码编辑前，若任务影响 durable architecture boundary、module ownership、API / Schema / data contract、state / runtime semantics、dependency direction、verification / deployment semantics 或 durable rationale / tradeoff，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 完成唯一正式长期事实判断，再写本次 `Task Contract`，并显式写 `Architecture Context Hit` 和 `Decision Rationale Hit: existing|required|none`。如果输入包含产品方案、架构方案、技术方案、实现方案或验收方案，先在 `plan.md` 或等价临时计划面做 Source-to-Context Coverage，确认方案中的 durable architecture / ownership / API / runtime / verification constraints 已被现有 Context 覆盖、需要更新、仅属 task-local、显式 out-of-scope、需要用户决策或仍 under-scoped。
 5. 普通 bug fix、局部样式、局部实现漂移修复、小重构、package/release 处理、测试修复或探索性 spike 不强制编译架构 / rationale 任务契约，也不更新 Context；一旦形成长期工程结论，继续对齐或交付前必须回写 Context。不要把 Context 机械补成代码改动摘要。
 6. 如果代码、搜索结果或相邻实现与 Context 冲突，显式标记为实现漂移、缺失工作或 Context 过期，不要用当前代码形态反推模块归属。
 7. 涉及已有 Context 的实现判断，先做轻量对齐：
@@ -45,13 +45,13 @@ Project-specific engineering rules belong in a separate project-local Skill unde
    - 默认只实施高收益、低风险、语义稳定的候选项。
    - 不为一次性代码、不稳定语义或纯粹好看的架构做抽象。
 13. 当人工流程呈现重复、确定性、容易漏步骤或顺序影响正确性时，主动评估是否应沉淀为 repo-local tool/script。脚本应放在 owning module 的工具目录并配测试；可恢复的执行入口、参数约束和适用边界写入对应 verification / deployment Context。Skill 只记录这类脚本化机会识别原则，不承载具体模块命令、provider id、artifact 路径或一次性运行结果。
-14. 需要沉淀长期事实时，只更新 `project_context/**`：
+14. 需要沉淀长期事实时，只更新 `project_context/**`：
    - 全局工程取舍、跨产品域索引或当前状态写入 `global.md`。
    - 产品域 API、数据契约、关键约束、入口和风险写入对应 area / subdomain Context。
    - 跨域接口语义写入 `context_role: contract` 或 manifest role 为 `contract` 的 Context；关键重复验证路径写入 `verification`；关键部署、运行拓扑或云端初始化路径写入 `deployment`；代码入口索引用 `implementation-index`；底层理论源用 `foundation`；历史归档索引用 `archive`。
    - 新 context unit 可新增 `project_context/areas/<unit>.md`，并更新 `global.md#Context Index`；复杂项目同时更新 `project_context/context.toml`。
    - 如果 `upgrade` 自动把深层 `.md` 注册成 area，但语义上更像 foundation / contract / archive，后续应显式调整 manifest role；不要依赖自动迁移判断语义。
-15. 实现收尾时做 `Contract Conformance` 和 Context drift check：确认代码没有引入未沉淀的长期事实，且 Context 没有退化成普通实现摘要；交付说明只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和验证入口；一次性证据、截图结果、测试日志、任务契约和实现摘要不写入 Context。
+15. 实现收尾时做 `Contract Conformance` 和 Context drift check：确认代码没有引入未沉淀的长期事实，且 Context 没有退化成普通实现摘要；若存在 `plan.md` / 等价临时计划面，必须反查 Source-to-Context Coverage、Context-to-Implementation Binding 和 Task Contract，确认没有未处理的 `under_scoped` / `new_context_required` / `needs_user_decision`，也没有 non-bound implementation rows。交付说明只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和验证入口；一次性证据、截图结果、测试日志、任务契约和实现摘要不写入 Context。
 16. Context 只能声明验证 / 部署关键路径或验收信号，不能伪造“测试已通过”或“部署已成功”。
 17. Verification / Deployment Role Context 只记录长期可复用的重复执行路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id 或 raw payload。
 
@@ -76,13 +76,18 @@ Project-specific engineering rules belong in a separate project-local Skill unde
   - `none`：没有超限计划 / touched 手写源码文件，或本次没有向超限文件增加新职责。
   - `required`：拆分是本次验收条件，应按 abstraction / decomposition scan 的职责边界完成。
   - `exception`：本次触碰超限文件但暂不拆；只有默认 `modularity.policy: scoped_waivers` 允许此路径，且必须已有或同步新增 `<harnessRoot>/config.yaml` `modularity.waivers` 记录文件、收窄分类、原因和后续拆分边界。若项目设置 `modularity.policy: strict_except_generated`，不得用 legacy waiver 绕过超限手写源码，交付说明只记录本次是否新增职责以及为什么没有拆。
-- `Applicable Module Design` 是高风险任务的前置字段：列出命中的 Context / Skill 来源、适用的 Principles、Design Logic 和 Design Rationale，以及它们控制的当前实现或验证选择。
+- `Applicable Module Design` 是高风险任务的前置字段：列出命中的 Context / Skill 来源、适用的 Principles、Design Logic 和 Design Rationale，以及它们控制的当前实现或验证选择。
 - `Principle Decision Gate` 要写明首选执行路径、fallback / degraded path 的进入条件，以及什么证据不能证明本次目标。涉及 capability、metric 或 acceptance claim 时，先声明要证明的 claim，再选择命令或 probe。
-- 对长任务、多模块、多 agent、容易发生 `Context Delta` 调头或多轮验证的任务，可以用 `plan.md` 或等价临时计划面暂存 `Context Delta`、`Task Contract`、`Implementation Steps` 和 `Contract Conformance`；它只是临时执行缓存。
-- `plan.md` 中出现的长期工程事实必须提炼回 `project_context/**`；否则不要把临时计划当作事实源、交付产物或后续引用依据。
-- `Context Delta: required` 时先更新 `project_context/**`，再继续实现；`none` 时直接按 Task Contract 实现。
-- `Contract Conformance` 是交付前的软检查：实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失回 `Context Delta` 并先更新 Context。
-- 不为普通代码修改、bug fix、小重构、package/release 处理、测试修复、探索性 spike 或仅因 touched file 过大强制编译架构 / rationale 任务契约；大文件只走 `Modularity Check` 的拆分 / exception 判断。
+- 对长任务、多模块、多 agent、外部产品/架构/技术/实现/验收方案输入、容易发生 `Context Delta` 调头或多轮验证的任务，使用 `plan.md` 或等价临时计划面暂存 `Source-to-Context Coverage`、`Context-to-Implementation Binding`、`Context Delta`、`Task Contract`、`Implementation Steps` 和 `Contract Conformance`；它只是临时执行缓存。
+- small code task 指现有 Context 已足够、且不改变 durable product / architecture / API-schema / runtime-state / verification-deployment / security-redaction / surface ownership 事实的局部实现任务；它按语义风险判断，不按代码行数判断，不应创建 `plan.md`、完整 trace tables、Source-to-Context Coverage 或 Context-to-Implementation Binding，除非它发现长期事实变化或扩展成高风险工作。
+- `Source-to-Context Coverage` 表使用字段：`Source item | Durable constraint | Type | Existing Context Hit | Context action | Owning Context | Coverage status`。这张表只回答 source 约束是否进入或命中 Context，不写实现路径。
+- `Coverage status` 取值：`covered`、`new_context_required`、`context_updated`、`task_local_only`、`out_of_scope_explicit`、`needs_user_decision`、`under_scoped`。存在 `under_scoped` 或未处理的 `new_context_required` / `needs_user_decision` 时，不能声称已按方案完整实现。
+- `Context-to-Implementation Binding` 表使用字段：`Context fact | Implementation obligation | Expected surfaces | Implemented paths | Forbidden shortcuts | Verification path | Binding status`。
+- `Binding status` 取值：`bound`、`partial`、`missing`、`blocked`、`out_of_scope_explicit`、`needs_user_decision`、`contradicted_by_current_state`。runtime/API/worker 项不能只用测试名或 browser checked path 冒充 `bound`。
+- `plan.md` 中出现的长期工程事实必须提炼回 `project_context/**`；否则不要把临时计划当作事实源、交付产物或后续引用依据。
+- `Context Delta: required` 时先更新 `project_context/**`，再继续实现；`none` 时直接按 Task Contract 实现。
+- `Contract Conformance` 是交付前的软检查：实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失或 source coverage under-scoped 回 `Context Delta` 并先更新 Context。
+- 不为 small code task、普通代码修改、bug fix、小重构、package/release 处理、测试修复、探索性 spike 或仅因 touched file 过大强制编译架构 / rationale 任务契约；大文件只走 `Modularity Check` 的拆分 / exception 判断。
 
 ## 模块设计上下文写法
 

package/assets/skills/context_product_plan/SKILL.md

@@ -25,7 +25,7 @@ Project-specific product planning rules belong in a separate project-local Skill
 4. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件任务框架”重新理解用户任务和产品反馈；这只是通用判断框架，不是业务处方库。
 5. 当一个产品对象、能力或接口的增删改需要跨多个页面、模块、Context 或产品域同步调整时，将该影响范围视为产品边界复核信号；先判断它是否应沉淀为独立能力、subdomain 或 area，并明确对外契约、所有权和消费方边界，避免通过手工清单长期维护各消费面的重复映射。
 6. 产品意图、模块职责、边界和验收口径以 `project_context/**` 为准；代码和搜索结果只说明当前实现状态。Context 决定“应该是什么”，代码揭示“现在是什么”，代码不能静默重定义 Context。
-7. 输出产品判断或第一处实现编辑前，若任务涉及产品方案、页面/模块边界、信息架构、API / Schema、验收口径、跨域契约、状态或调度语义，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 完成唯一正式长期事实判断，再写本次 `Task Contract`。
+7. 输出产品判断或第一处实现编辑前，若任务涉及产品方案、页面/模块边界、信息架构、API / Schema、验收口径、跨域契约、状态或调度语义，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 完成唯一正式长期事实判断，再写本次 `Task Contract`。如果输入包含产品方案、架构方案、技术方案或验收方案，先在 `plan.md` 或等价临时计划面做 Source-to-Context Coverage，确认方案中的 durable product / surface / IA / acceptance constraints 已被现有 Context 覆盖、需要更新、仅属 task-local、显式 out-of-scope、需要用户决策或仍 under-scoped。
 8. 普通 bug fix、局部样式、局部实现漂移、测试修复或探索性 spike 不更新 Context；如果过程中形成长期产品结论，应在继续对齐或交付前回写 Context。不要把 Context 机械补成代码改动摘要。
 9. 如果代码与 Context 冲突，显式标记为实现漂移、缺失工作或 Context 过期。
 10. 输出产品判断时保持短而具体，避免长篇 PRD 模板。
@@ -45,13 +45,18 @@ Project-specific product planning rules belong in a separate project-local Skill
 - `Context Delta` 必须先出现，取值为 `none` 或 `required`：
   - `none`：本次只是按既有 Context / 原则落地，不新增长期事实。
   - `required`：说明长期事实类型、应写入的 Context / role、需要沉淀的事实，以及明确不写入 Context 的一次性内容。
-- `Task Contract` 用短列表说明本次产品实现必须满足的目标、用户任务、信息 / 动作 / 状态 / 反馈、边界、非目标和验收信号。
-- 触及 Product Surface 时，`Task Contract` 同时说明 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification；业务特定答案进入项目 Context 或项目本地 Skill，不写进 package-managed Skill。
-- 对长任务、多模块、多 agent、容易发生 `Context Delta` 调头或多轮验证的任务，可以用 `plan.md` 或等价临时计划面暂存 `Context Delta`、`Task Contract`、`Implementation Steps` 和 `Contract Conformance`；它只是临时执行缓存。
-- `plan.md` 中出现的长期事实必须提炼回 `project_context/**`；否则不要把临时计划当作事实源、交付产物或后续引用依据。
-- `Context Delta: required` 时先更新 `project_context/**`，再继续实现；`none` 时直接按 Task Contract 实现。
-- `Contract Conformance` 是交付前的软检查：实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失回 `Context Delta` 并先更新 Context。
-- 不为普通 bug fix、局部样式、小重构、局部实现漂移、测试修复或探索性 spike 强制编译任务契约。
+- `Task Contract` 用短列表说明本次产品实现必须满足的目标、用户任务、信息 / 动作 / 状态 / 反馈、边界、非目标和验收信号。
+- 触及 Product Surface 时，`Task Contract` 同时说明 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification；业务特定答案进入项目 Context 或项目本地 Skill，不写进 package-managed Skill。
+- 对长任务、多模块、多 agent、外部产品/架构/技术/验收方案输入、容易发生 `Context Delta` 调头或多轮验证的任务，使用 `plan.md` 或等价临时计划面暂存 `Source-to-Context Coverage`、`Context-to-Implementation Binding`、`Context Delta`、`Task Contract`、`Implementation Steps` 和 `Contract Conformance`；它只是临时执行缓存。
+- small code task 指现有 Context 已足够、且不改变 durable product / architecture / API-schema / runtime-state / verification-deployment / security-redaction / surface ownership 事实的局部实现任务；它按语义风险判断，不按代码行数判断，不应创建 `plan.md`、完整 trace tables、Source-to-Context Coverage 或 Context-to-Implementation Binding，除非它发现长期事实变化或扩展成高风险工作。
+- `Source-to-Context Coverage` 表使用字段：`Source item | Durable constraint | Type | Existing Context Hit | Context action | Owning Context | Coverage status`。这张表只回答 source 约束是否进入或命中 Context，不写实现路径。
+- `Coverage status` 取值：`covered`、`new_context_required`、`context_updated`、`task_local_only`、`out_of_scope_explicit`、`needs_user_decision`、`under_scoped`。存在 `under_scoped` 或未处理的 `new_context_required` / `needs_user_decision` 时，不能声称已按方案完整实现。
+- `Context-to-Implementation Binding` 表使用字段：`Context fact | Implementation obligation | Expected surfaces | Implemented paths | Forbidden shortcuts | Verification path | Binding status`。
+- `Binding status` 取值：`bound`、`partial`、`missing`、`blocked`、`out_of_scope_explicit`、`needs_user_decision`、`contradicted_by_current_state`。存在 non-bound 项时，不能声称已按 Context 完整落地。
+- `plan.md` 中出现的长期事实必须提炼回 `project_context/**`；否则不要把临时计划当作事实源、交付产物或后续引用依据。
+- `Context Delta: required` 时先更新 `project_context/**`，再继续实现；`none` 时直接按 Task Contract 实现。
+- `Contract Conformance` 是交付前的软检查：实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失或 source coverage under-scoped 回 `Context Delta` 并先更新 Context。
+- 不为 small code task、普通 bug fix、局部样式、小重构、局部实现漂移、测试修复或探索性 spike 强制编译任务契约。
 
 ## 产品体验校准
 

package/assets/skills/context_surface_contract/SKILL.md

@@ -67,12 +67,13 @@ Use when turning audit findings or user decisions into Context candidates.
 
 Output:
 
-- Project-level Product Surface Contract candidate when responsibilities cross surfaces or areas.
-- Area-level Screen Contract candidate when ownership belongs inside one domain.
-- `context.toml` candidate registration with `role = "contract"` when durable registration is needed.
-- `global.md#Context Index` candidate entry when a new Context file is added.
-- Verification candidate for repeatable surface checks.
-- Repo-local Skill task-block candidate when the user wants project-specific enforcement.
+- Project-level Product Surface Contract candidate when responsibilities cross surfaces or areas.
+- Area-level Screen Contract candidate when ownership belongs inside one domain.
+- `context.toml` candidate registration with `role = "contract"` when durable registration is needed.
+- `global.md#Context Index` candidate entry when a new Context file is added.
+- Verification candidate for repeatable surface checks.
+- Source-to-Context Coverage candidate when an external product, architecture, technical or acceptance source changes durable surface responsibility.
+- Repo-local Skill task-block candidate when the user wants project-specific enforcement.
 
 Do not assume business responsibilities from current code shape alone. Ask for confirmation if the candidate would silently choose between competing product or information-architecture meanings.
 
@@ -104,11 +105,13 @@ Use after implementation or during review.
 
 Output:
 
-- Surface Contract Conformance.
-- Remaining Drift.
-- Missing Context.
-- Implementation Drift.
-- Verification run / not_run / failed.
+- Surface Contract Conformance.
+- Source-to-Context Coverage status when a plan surface exists.
+- Context-to-Implementation Binding status when a plan surface exists.
+- Remaining Drift.
+- Missing Context.
+- Implementation Drift.
+- Verification run / not_run / failed.
 
 Do not store one-off evidence, screenshots, logs, raw outputs or implementation summaries in Context.
 
@@ -123,7 +126,8 @@ For each touched surface, answer only what is relevant:
 - What must move to drilldown, diagnostics, operations, evidence or technical detail?
 - Which long-running or mutating actions require task id, progress, retry, import, recovery or history?
 - Which empty, loading, stale, unavailable, fixture or fallback states matter?
-- What validation path can prove conformance?
+- What validation path can prove conformance?
+- If this came from an external plan/source, which source constraints are covered by existing Context, require new Context, are task-local only, are explicitly out of scope, need user decision or remain under-scoped?
 
 ## Repo-Local Task Block Candidate
 
@@ -143,11 +147,13 @@ For any task touching user-facing surfaces, information placement, forms, filter
 - Main Surface Forbids: `<backend fields, raw payloads, diagnostics, debug ids, fake states, etc.>`
 - Drilldown Ownership: `<details / evidence / operations / diagnostics / technical details>`
 - Long Task State Requirement: `<run id, progress, retry, recovery, import, history, or none>`
-- Context Delta: `<none | required>`
-- Verification: `<view-model test / component test / browser smoke / CLI smoke / manual check>`
-```
-
-Do not add this task block to package-managed default Skills as a universal gate. Projects opt in through separate project-local Skills.
+- Context Delta: `<none | required>`
+- Verification: `<view-model test / component test / browser smoke / CLI smoke / manual check>`
+- Source-to-Context Coverage: `<covered | new_context_required | context_updated | task_local_only | out_of_scope_explicit | needs_user_decision | under_scoped>`
+- Context-to-Implementation Binding: `<bound | partial | missing | blocked | out_of_scope_explicit | needs_user_decision | contradicted_by_current_state>`
+```
+
+Do not add this task block to package-managed default Skills as a universal gate. Projects opt in through separate project-local Skills.
 
 ## Implementation Alignment
 
@@ -159,7 +165,9 @@ When implementation is also requested, align code with the Product Surface Contr
 - Tests should assert user-facing state semantics, not only backend field plumbing.
 - Browser, app, CLI or game smoke checks should validate actual surface behavior when feasible.
 
-Final handoff should include concise `Surface Contract Conformance`: contract source, implementation alignment, remaining drift and verification status.
+Final handoff should include concise `Surface Contract Conformance`: contract source, implementation alignment, remaining drift and verification status.
+
+If a `plan.md` or equivalent temporary plan surface exists, conformance must also check its Source-to-Context Coverage and Context-to-Implementation Binding. Remaining `under_scoped` or unresolved `new_context_required` rows mean the implementation cannot be described as fully aligned to the source surface responsibilities. Non-bound surface implementation rows mean it cannot be described as fully aligned to Context; component, modal, viewmodel or unit evidence alone cannot prove main-surface ownership.
 
 ## Output Boundaries
 
@@ -167,5 +175,5 @@ Final handoff should include concise `Surface Contract Conformance`: contract so
 - Do not update Context for ordinary CSS tweaks, copy edits or one-off UI bug fixes unless durable surface responsibility changes.
 - Do not treat current backend fields, enums, JSON, screenshots or terminal output as product intent.
 - Do not invent rationale; rejected alternatives or tradeoffs belong in Context only when they are stable enough to affect future surface decisions.
-- Do not add a validator, edit-order gate or package-level mandatory Surface Contract gate.
+- Do not add a surface-specific validator, edit-order gate or package-level mandatory Surface Contract gate. The generic plan-contract validator may check declared surface binding consistency when a temporary plan surface exists.
 - Do not include business-domain examples in this package-managed Skill.

package/assets/skills/context_uiux_design/SKILL.md

@@ -25,7 +25,7 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
    - 若缺失且本任务改变 durable surface responsibility，输出 `Surface Contract Delta: required`，把界面职责写入 `project_context/**`；视觉 token、颜色、字体、间距、圆角和视觉 rationale 仍写入 `DESIGN.md`。
 5. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件交互框架”检查控件语义、反馈状态、校验、错误预防、可供性和信息密度；这只是通用判断框架，不是固定控件处方。
 6. 界面职责、流程归属和长期交互契约以 `project_context/**` 为准；`DESIGN.md` 负责视觉 token 和视觉 rationale；代码、截图和搜索结果只说明当前实现状态。Context 决定“应该是什么”，代码和截图揭示“现在是什么”，代码不能静默重定义 Context。
-7. 设计判断或第一处实现编辑前，若任务涉及页面职责、流程边界、信息架构、交互契约、状态或调度语义、可访问性约束、设计验证关键路径或部署关键路径，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 完成唯一正式长期事实判断，再写本次 `Task Contract`。
+7. 设计判断或第一处实现编辑前，若任务涉及页面职责、流程边界、信息架构、交互契约、状态或调度语义、可访问性约束、设计验证关键路径或部署关键路径，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 完成唯一正式长期事实判断，再写本次 `Task Contract`。如果输入包含产品方案、架构方案、技术方案、界面方案或验收方案，先在 `plan.md` 或等价临时计划面做 Source-to-Context Coverage，确认方案中的 durable surface / IA / interaction / verification constraints 已被现有 Context 或 `DESIGN.md` 覆盖、需要更新、仅属 task-local、显式 out-of-scope、需要用户决策或仍 under-scoped。
 8. 普通 UI bug、局部样式或 CSS 修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期交互或视觉结论，继续对齐或交付前必须回写 Context 或 `DESIGN.md`。不要把 Context 机械补成代码改动摘要。
 9. 如果二者冲突，显式标记为实现漂移、缺失工作或 Context 过期。
 10. 如果涉及已有 UI，优先结合代码入口、运行截图或用户提供的参考图来描述差异。
@@ -46,13 +46,18 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 - `Context Delta` 必须先出现，取值为 `none` 或 `required`：
   - `none`：本次只是按既有 Context / `DESIGN.md` / 设计原则落地，不新增长期事实。
   - `required`：说明长期事实类型、应写入的 Context / role 或 `DESIGN.md` 位置、需要沉淀的事实，以及明确不写入 Context 的一次性内容。
-- `Task Contract` 用短列表说明页面 / 组件任务、用户判断、主信息和辅助信息归属、动作层级、输入语义、loading / empty / no results / stale / error / degraded / success 状态、布局稳定性、非目标和验收入口。
-- 触及 Product Surface 时，`Task Contract` 同时说明 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification；代码字段、枚举、JSON 或截图只是实现证据，不是产品职责来源。
-- 对长任务、多页面/组件、多 agent、容易发生 `Context Delta` 调头或多轮截图 / 手动验证的任务，可以用 `plan.md` 或等价临时计划面暂存 `Context Delta`、`Task Contract`、`Implementation Steps` 和 `Contract Conformance`；它只是临时执行缓存。
-- `plan.md` 中出现的长期界面、交互或视觉事实必须提炼回 `project_context/**` 或 `DESIGN.md`；否则不要把临时计划当作事实源、交付产物或后续引用依据。
-- `Context Delta: required` 时先更新 `project_context/**` 或 `DESIGN.md`，再继续实现；`none` 时直接按 Task Contract 实现。
-- `Contract Conformance` 是交付前的软检查：实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失回 `Context Delta` 并先更新 Context / `DESIGN.md`。
-- 不为普通 UI bug、局部 CSS 修复、小重构、测试修复或探索性 spike 强制编译任务契约。
+- `Task Contract` 用短列表说明页面 / 组件任务、用户判断、主信息和辅助信息归属、动作层级、输入语义、loading / empty / no results / stale / error / degraded / success 状态、布局稳定性、非目标和验收入口。
+- 触及 Product Surface 时，`Task Contract` 同时说明 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification；代码字段、枚举、JSON 或截图只是实现证据，不是产品职责来源。
+- 对长任务、多页面/组件、多 agent、外部产品/架构/技术/界面/验收方案输入、容易发生 `Context Delta` 调头或多轮截图 / 手动验证的任务，使用 `plan.md` 或等价临时计划面暂存 `Source-to-Context Coverage`、`Context-to-Implementation Binding`、`Context Delta`、`Task Contract`、`Implementation Steps` 和 `Contract Conformance`；它只是临时执行缓存。
+- small code task 指现有 Context / `DESIGN.md` 已足够、且不改变 durable product / architecture / API-schema / runtime-state / verification-deployment / security-redaction / surface ownership 事实的局部实现任务；它按语义风险判断，不按代码行数判断，不应创建 `plan.md`、完整 trace tables、Source-to-Context Coverage 或 Context-to-Implementation Binding，除非它发现长期事实变化或扩展成高风险工作。
+- `Source-to-Context Coverage` 表使用字段：`Source item | Durable constraint | Type | Existing Context Hit | Context action | Owning Context | Coverage status`。这张表只回答 source 约束是否进入或命中 Context / `DESIGN.md`，不写实现路径。
+- `Coverage status` 取值：`covered`、`new_context_required`、`context_updated`、`task_local_only`、`out_of_scope_explicit`、`needs_user_decision`、`under_scoped`。存在 `under_scoped` 或未处理的 `new_context_required` / `needs_user_decision` 时，不能声称已按方案完整实现。
+- `Context-to-Implementation Binding` 表使用字段：`Context fact | Implementation obligation | Expected surfaces | Implemented paths | Forbidden shortcuts | Verification path | Binding status`。
+- `Binding status` 取值：`bound`、`partial`、`missing`、`blocked`、`out_of_scope_explicit`、`needs_user_decision`、`contradicted_by_current_state`。UI/surface 项不能只用 component / viewmodel / mock / unit evidence 冒充 `bound`。
+- `plan.md` 中出现的长期界面、交互或视觉事实必须提炼回 `project_context/**` 或 `DESIGN.md`；否则不要把临时计划当作事实源、交付产物或后续引用依据。
+- `Context Delta: required` 时先更新 `project_context/**` 或 `DESIGN.md`，再继续实现；`none` 时直接按 Task Contract 实现。
+- `Contract Conformance` 是交付前的软检查：实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失或 source coverage under-scoped 回 `Context Delta` 并先更新 Context / `DESIGN.md`。
+- 不为 small code task、普通 UI bug、局部 CSS 修复、小重构、测试修复或探索性 spike 强制编译任务契约。
 
 ## 信息呈现校准
 

package/assets/skills/superpowers-long-task/SKILL.md

@@ -21,6 +21,8 @@ Consumes three existing upstream inputs and emits a paste-ready Superpowers targ
 
 Use this Skill only after all three inputs already exist or are pasted in full. Two-document compatibility is allowed only when the first document explicitly contains both Product / Architecture Source and Technical Realization Plan sections; otherwise stop for a missing Technical Realization Plan. Do not generate, derive, or infer the Technical Realization Plan. Do not generate, derive, rewrite, strengthen, or repair the full checklist in this Skill. If plan items or ACs are too vague to trace, stop and ask for the missing fields. If only generic conformance or verdict rules are missing, inject this Skill's default rules into the generated prompt.
 
+This Skill does not perform task-complexity routing. Direct invocation means the user or upstream process has already selected Superpowers long-task execution. Ordinary checklist preparation, non-Superpowers target prompts or incomplete upstream packets should be handled before this Skill, normally with `/normal-long-task` or a revised upstream packet.
+
 ## Direct Invocation
 
 Use this Skill through explicit invocation:
@@ -68,6 +70,17 @@ The input must fully expose these fields:
 
 If any of these are missing required fields, stop. Do not generate the Superpowers target-mode prompt. Report whether each missing field belongs in Product / Architecture Source, Technical Realization Plan, Acceptance Checklist, blocker section or Context reference. If the user supplied only a product/architecture source plus checklist, report missing Technical Realization Plan.
 
+When blocked by missing input, return a structured Missing Fields Report with:
+
+- `missing_section`.
+- `missing_required_fields`.
+- `why_blocking`.
+- `cannot_infer_policy`.
+- `required_next_input`.
+- `suggested_upstream_action`.
+
+The report must state that this Skill cannot infer the execution blueprint from Product / Architecture Source and cannot repair the checklist. It may recommend supplying the missing Technical Realization Plan or using `/normal-long-task` before Superpowers execution when the upstream packet is not ready.
+
 ## Source Roles
 
 - Product / Architecture Source prevents scope shrinkage and drives Product Context Delta / architecture-intent checks; it is not the code construction plan.
@@ -79,6 +92,14 @@ If any of these are missing required fields, stop. Do not generate the Superpowe
 
 Do not let a compact target prompt override the product/architecture source, technical realization plan or full checklist. The compact prompt is direction, priority and recovery navigation only. The technical realization plan controls plan conformance; the product/architecture source prevents scope shrinkage; the full checklist controls acceptance.
 
+## Authority Model
+
+- Product / Architecture Source owns intent, scope, non-goals, product/architecture boundaries and acceptance semantics.
+- Technical Realization Plan owns plan items, execution blueprint, owner/forbidden surfaces, implementation paths and plan-conformance expectations.
+- Acceptance Checklist owns ACs, completion semantics, required proof layers, invalid evidence rules and final acceptance state.
+- local audit, plan-conformance matrix, final acceptance verdict, validator output, optional proof index and auditor report are execution/evidence artifacts. They cannot narrow, rewrite or replace the upstream sources.
+- When sources conflict, stop or report the conflict instead of letting a downstream artifact silently change scope, plan or acceptance.
+
 ## Context Delta Assessment
 
 The prompt must require the future executor to evaluate Context before implementation using:
@@ -97,6 +118,13 @@ Any required sub-delta makes overall Context Delta required. This is prompt-leve
 
 When overall `Context Delta: required`, the executor must update the smallest owning `project_context/**` or `DESIGN.md` fact before implementation continues. Use existing roles only: `area`, `subdomain`, `contract`, `foundation`, `verification`, `deployment`, `implementation-index` and `decision-rationale`. Do not write local audit, plan-conformance matrix, final acceptance verdict, temporary plan, sampled evidence, one-off logs, raw outputs, screenshots or PR notes into Context.
 
+For Superpowers execution, the generated prompt should use a parent/slice pattern:
+
+- Parent Context Delta: evaluate Product Context Delta, Technical Context Delta, overall Context Delta, owning Context files and whether required Context was updated before implementation.
+- Slice Context Delta: each implementation slice inherits the parent decision and only records whether it discovered a new durable fact.
+- If a slice discovers a new durable product or technical fact, it must identify the owning Context and update it before continuing.
+- Slice-level `none` cannot override a parent-level `required` decision.
+
 ## Plan Conformance Gate
 
 The prompt must require the future executor to create or initialize `tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md` and `.json` before substantial implementation, then update it after each meaningful implementation slice.
@@ -104,6 +132,7 @@ The prompt must require the future executor to create or initialize `tmp/ty-cont
 Each behavior-affecting Technical Realization Plan item must have a trace entry with:
 
 - plan item id and plan requirement.
+- acceptance ids covered by the plan item when applicable.
 - expected surfaces.
 - implemented paths.
 - missing paths.
@@ -112,6 +141,10 @@ Each behavior-affecting Technical Realization Plan item must have a trace entry
 - scope assessment.
 - status.
 - drift.
+- required proof layers, satisfied proof layers and missing required layers when the plan/checklist requires layered evidence.
+- substitute or sibling evidence use when any similar execution path, negative case, screenshot or artifact could be confused with the required evidence.
+- Context fact refs when Context Delta is required.
+- For Product Surface, IA or architecture-migration items: conformance type, owner surface, required user paths, forbidden primary surfaces, real page evidence, negative surface checks and default visibility requirement.
 
 Allowed plan-conformance statuses:
 
@@ -122,6 +155,7 @@ Allowed plan-conformance statuses:
 - `blocked`
 - `scope_changed_requires_user_approval`
 - `contradicted_by_current_state`
+- `out_of_scope_NA`
 
 Hard rules:
 
@@ -130,6 +164,8 @@ Hard rules:
 - A local audit cannot narrow plan scope or mark completion.
 - Scope correction requires explicit user approval or a revised product/architecture source, Technical Realization Plan and checklist.
 - Every behavior-affecting plan section must have an implementation trace entry.
+- Product Surface, IA or architecture-migration rows cannot be complete without owner surface, required user paths, real page evidence, negative surface checks for forbidden primary surfaces and Context fact refs when Context Delta is required.
+- A complete row cannot have unresolved `missing_required_layers`, material or critical `drift_severity`, unapproved `sibling_substitution_used`, summary-only evidence or blocking auditor findings.
 - Any `partial`, `sampled_only`, `not_implemented`, unresolved blocker, unapproved scope change or current contradiction prevents overall done.
 
 ## Acceptance Evidence Gate
@@ -139,10 +175,16 @@ The prompt must require the future executor to generate `tmp/ty-context/plan-acc
 Each AC verdict entry must include:
 
 - AC id or acceptance item.
+- related plan item ids when applicable.
 - status.
 - required evidence.
+- required proof chain when the checklist or plan requires multiple evidence layers.
 - fresh evidence.
 - missing evidence.
+- missing required layers.
+- drift severity.
+- sibling substitution used / approval source.
+- auditor status and findings when an auditor subagent was available.
 - contradictions.
 - decision.
 
@@ -153,14 +195,49 @@ Allowed AC statuses:
 - `blocked`
 - `not_run`
 - `invalidated`
+- `out_of_scope_NA`
 
 Hard rules:
 
 - Final completion requires an AC-by-AC final acceptance verdict.
+- Before any completion claim, run `ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>`; failure prevents final complete and must produce partial / blocker / missing-evidence output.
+- `validate-plan-acceptance` rejects contradictory matrix/verdict JSON, weak-proof complete rows, missing cross-references and declared surface/architecture binding gaps; it checks artifact consistency and references, not product quality.
 - Current API/UI/runtime/data/test contradictions override historical passing evidence.
 - local audit, subagent summaries, final result card text, passing test logs, stale artifacts, partial smoke, dry-run or sampled paths cannot prove completion by themselves.
 - Any current contradiction downgrades the affected AC and overall status.
 - Scope narrowing in audit does not modify acceptance unless the user approved a revised source/plan/checklist.
+- `out_of_scope_NA` requires explicit reason and source reference; arbitrary prose cannot waive missing evidence.
+- Complete AC rows cannot have unresolved `missing_required_layers`, material or critical `drift_severity`, unapproved `sibling_substitution_used`, blocking `auditor_status` or only self-certifying evidence such as local audit, matrix/verdict text, subagent summary, final card or validator pass.
+
+## External Reviewer Evidence Gate
+
+The final verdict is not completion proof unless every complete AC can be independently reviewed from fresh command, API, UI, runtime, artifact, browser or test evidence. Evidence index, matrix rows, local audit, validator pass and summaries can point to evidence, but cannot replace evidence.
+
+For every AC whose checklist implies multiple required layers, the final verdict must record `required_proof_chain`, `fresh_evidence`, `missing_required_layers`, `drift_severity`, `sibling_substitution_used`, `auditor_status` and `auditor_findings` when applicable. These are generic evidence protocol fields; concrete business layers must come from the Acceptance Checklist, Product / Architecture Source, Technical Realization Plan or project-local Context/Skills.
+
+Evidence Ledger / proof index is optional execution indexing, not a fourth input, not durable Context and not required as a separate file. Complete plan-conformance rows and complete AC verdicts must still be evidence-traceable: cite fresh, reviewable evidence directly in the row or through an optional `evidence_id` that points to command, API, UI, runtime, artifact, browser or test evidence with enough freshness context for a reviewer to reconstruct the proof chain.
+
+## Drift-to-Status
+
+Any plan item or AC with unresolved missing required layers, material / critical drift or a current API / UI / runtime / data / test contradiction cannot be `complete`. It must be `partial`, `blocked`, `invalidated` or `out_of_scope_NA` with explicit source reference.
+
+## No Sibling Substitution
+
+The same execution path, negative case, screenshot or artifact class cannot substitute for the required one unless the checklist explicitly allows that substitution or marks the required layer `out_of_scope_NA`. Similar evidence is auxiliary only.
+
+## Independent Reviewer Gate
+
+When subagents are available, add a read-only auditor after executor self-evidence and `validate-plan-acceptance`. The auditor is a gap detector, not a proof source: it must not edit code, repair artifacts or treat local audit, subagent summary, matrix/verdict text, validator pass or final card as proof. It reconstructs each AC proof chain from source/plan/checklist, checks freshness and raw evidence, rejects sibling substitution and returns `auditor_status` plus findings. Any `partial`, `blocked` or `invalidated` auditor result downgrades the affected AC unless fresh evidence closes the gap.
+
+Final gate order is fixed:
+
+1. executor self-evidence.
+2. update plan-conformance matrix.
+3. update final-acceptance verdict.
+4. run `ty-context validate-plan-acceptance`.
+5. run read-only auditor gap review when subagents are available.
+6. if auditor findings change matrix, verdict or evidence, fix the gap and rerun `ty-context validate-plan-acceptance`.
+7. make a final completion claim only when self-evidence, validator consistency and auditor review have no blocking conflict.
 
 ## Evidence Layer Separation
 
@@ -220,7 +297,7 @@ Bind the target prompt to the official Skill names and their documented roles:
 - Prefer `superpowers:subagent-driven-development` when subagents are available.
 - Use `superpowers:executing-plans` when executing a written plan without the same-session subagent workflow.
 - Plan or AC behavior gap -> TDD: each behavior gap uses `superpowers:test-driven-development` to write a failing test, observe failure, then implement minimally.
-- Before any completion claim, use `superpowers:verification-before-completion` against both `plan-conformance-matrix.*` and `final-acceptance-verdict.*` with fresh evidence.
+- Before any completion claim, use `superpowers:verification-before-completion` against both `plan-conformance-matrix.*` and `final-acceptance-verdict.*` with fresh evidence, then run `ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>`.
 - review / finish cannot override the plan-conformance matrix or full checklist; if either gate is unsatisfied, continue implementation or report blockers.
 
 If Superpowers is missing, install it through the current platform's official Superpowers installation path. If installation is blocked by permissions, network or platform limits, record the blocker in local audit and do not count it as complete.
@@ -242,13 +319,19 @@ The Superpowers target prompt must require the future executor to update local a
 
 The local audit is not Context, not proof, not a global task manager, and not a replacement for project tests, CI, review, human acceptance, Task Contract or workflow-contract `plan.md`. It must not contain `overall_status: done`, `status: done` or `final_gate: passed`; use `candidate_status: claims_done_but_unverified` when needed.
 
+The local audit is process recovery only. It must not contain completion judgment such as accepted, complete, done, final passed or product verified except as invalid evidence being rejected.
+
 ## Prompt Generation Rules
 
 - The prompt must visibly output `Superpowers 输入包` for Chinese prompts or `Superpowers input packet` for English prompts.
 - The prompt must visibly output `Superpowers 执行绑定` for Chinese prompts or `Superpowers execution binding` for English prompts.
 - The prompt must identify Product / Architecture Source, Technical Realization Plan, Acceptance Checklist, local audit, plan-conformance matrix and final verdict paths at the top.
 - The prompt must state that the Technical Realization Plan controls plan conformance, the Product / Architecture Source prevents scope shrinkage and the full checklist controls acceptance.
+- The prompt must state the Authority Model and that audit/matrix/verdict/validator/auditor artifacts cannot rewrite source, plan or checklist authority.
 - The prompt must require Product Context Delta and Technical Context Delta evaluation before implementation.
+- The prompt must use parent-level Context Delta plus slice-level new durable fact checks.
+- The prompt must state that Evidence Ledger / proof index is optional, but complete rows and ACs require evidence traceability to fresh evidence directly or through optional `evidence_id`.
+- The prompt must require the fixed final gate order and rerun `validate-plan-acceptance` if auditor-driven fixes change artifacts.
 - The prompt must preserve hard-blocker semantics: if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking complete.
 - The prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries and must include the minimum user action list for locally unsatisfiable hard blockers.
 - The prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
@@ -273,55 +356,55 @@ Superpowers 输入包：
 - Acceptance Checklist：最高验收标准；每个 AC 都要进 final verdict
 - local audit：只记 progress/candidate status/evidence/blocker/invalidating evidence，不能裁判完成
 - Context/tests/core paths：执行前读取，把 plan/AC gap 绑定到测试、API/UI/runtime/browser 证据
+权威：source 管 scope，plan 管施工，checklist 管验收；audit/matrix/verdict/validator/auditor 不能改写它们。Proof index/evidence ledger 文件可选，但 complete 行必须能直接或经 evidence_id 追溯 fresh evidence。
 
 执行顺序：
 1. 读三份输入和 Context。先写 Task Contract：Product Context Delta none|required；Technical Context Delta none|required；任一 required -> Context Delta required。这不是 validator gate。
-2. Context Delta required 时，先最小更新 owning project_context/** 或 DESIGN.md；不要把 audit/matrix/verdict/日志/截图/sample evidence 写进 Context。
+2. 用 Parent Context Delta 统一判断；每个 slice 继承它，只记录 new durable fact yes/no。Context Delta required 时先最小更新 owning project_context/** 或 DESIGN.md；不要把 audit/matrix/verdict/日志/截图/sample evidence 写进 Context。
 3. 检查技术实现方案覆盖产品/架构源关键要求；若只有产品方案没有技术实现方案，停止报告 missing Technical Realization Plan，不现场生成。
 4. 初始化 plan-conformance matrix；计划不够 bite-sized 时用 superpowers:writing-plans。
 5. 有 subagent 支持时优先 superpowers:subagent-driven-development，否则 superpowers:executing-plans。
 6. Plan/AC behavior gap -> superpowers:test-driven-development：先写 failing test 并 observe failure，再最小实现。
 7. 每个实现 slice 后更新 matrix 和 audit。
 8. Candidate done 前跑 Plan Conformance Gate：测试通过不等于按图纸完成；sampled path 不等于 full implementation；每个行为 plan item 必须有 code/API/UI/runtime/test/evidence trace。
-9. 再跑 Acceptance Evidence Gate：按验收清单生成 final verdict；current API/UI/runtime/data/test contradiction 高于历史通过记录。
-10. 完成声明前用 superpowers:verification-before-completion 同时检查 matrix 和 verdict；两关不过就继续或报告 blocker。
+9. 再跑 Acceptance Evidence Gate：按验收清单生成 final verdict；每 AC 写 required proof chain/fresh evidence/missing layers/drift/substitution。current contradiction 高于历史通过记录。
+10. Final gate 固定为 self-evidence -> matrix -> verdict -> validator -> read-only auditor；auditor summary 不是 proof。若审计后改 artifact/evidence，重跑 validator；完成前用 superpowers:verification-before-completion 检查 matrix/verdict，并运行 ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>。
 
 权限/卡点：在当前平台/仓库/工具/用户已授权权限内最大自主推进；已授权 sudo/gsudo/admin elevation 先尝试，不算用户阻塞。只有本地无法解决的账号/凭证/真实环境/人工审批/敏感字段等才暂停，并给最小用户执行清单（具体页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
-禁止完成于：local audit、subagent summary、final card、只改代码/计划、只跑部分测试、旧/部分/抽样证据、runtime 未演练、artifact 未被 validator accepted、API/UI 未 reflected、未批准 scope narrowing、任何 API/UI/data/runtime/test 矛盾。
+禁止完成于：local audit、subagent summary、final card、只改代码/计划、只跑部分测试、旧/部分/抽样证据、缺 required layer、material drift、未批准 sibling substitution、runtime 未演练、artifact 未 accepted、API/UI 未 reflected、未批准 scope narrowing、任何 API/UI/data/runtime/test 矛盾。
 ```
 
 Recommended compact English prompt shape:
 
 ```text
-Product / Architecture Source: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md (original intent / scope guard, not construction plan)
-Technical Realization Plan: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md (blueprint / plan-conformance source, not proof)
-Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (acceptance authority; final verdict is judged against it)
-Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (process log, not proof; must not write done/final_gate passed)
-Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (create early, update during work)
-Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (generate at final gate, AC by AC)
+Product / Architecture Source: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md (scope guard)
+Technical Realization Plan: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md (blueprint)
+Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (acceptance authority)
+Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (process log, not proof)
+Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (update during work)
+Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (final AC gate)
 You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
 This is not a Superpowers official schema / 不是 Superpowers 官方 schema.
 Superpowers input packet:
-- Product / Architecture Source: original intent; prevents scope shrinkage; not the construction plan.
-- Technical Realization Plan: execution blueprint; every behavior-affecting item needs a matrix trace.
-- Acceptance Checklist: acceptance authority; every AC needs a final verdict entry.
-- Local audit: progress/candidate status/evidence/blockers/invalidating evidence only; never final proof.
-- Context/tests/core paths: read before execution; map plan/AC gaps to test/API/UI/runtime/browser evidence.
+- Source guards scope; plan controls matrix; checklist controls verdict.
+- Local audit is only progress/candidate status/evidence/blockers/invalidating evidence.
+- Read Context/tests/core paths first; map gaps to test/API/UI/runtime/browser evidence.
+Authority: source owns scope, plan owns construction, checklist owns acceptance; audit/matrix/verdict/validator/auditor cannot rewrite them. Proof index file optional; complete rows need fresh evidence or evidence_id.
 
 Execution order:
-1. Read the three inputs and Context. Write Task Contract: Product Context Delta none|required; Technical Context Delta none|required; any required sub-delta makes overall Context Delta required. This is not a validator gate.
-2. If Context Delta required, minimally update the owning project_context/** or DESIGN.md; never store audit/matrix/verdict/logs/screenshots/sample evidence as Context.
-3. Check the Technical Realization Plan covers Product / Architecture Source requirements; if only a product plan exists, stop with missing Technical Realization Plan, do not generate it.
+1. Read inputs and Context. Write Task Contract: Product Context Delta none|required; Technical Context Delta none|required; any required -> Context Delta required. Not a validator gate.
+2. Use Parent Context Delta once; slices inherit it and record only new durable fact yes/no. If required, update owning project_context/** or DESIGN.md; never store audit/matrix/verdict/logs/screenshots/sample evidence as Context.
+3. Check Technical Realization Plan covers Product / Architecture Source; if only product plan exists, stop with missing Technical Realization Plan, do not generate it.
 4. Initialize plan-conformance matrix; use superpowers:writing-plans if the plan is not bite-sized.
 5. Prefer superpowers:subagent-driven-development with subagents; otherwise use superpowers:executing-plans.
 6. Plan/AC behavior gap -> superpowers:test-driven-development: write a failing test, observe failure, then implement minimally.
 7. After each slice, update matrix and audit.
-8. Before candidate done, run Plan Conformance Gate: passing tests does not prove plan conformance; sampled path does not prove full implementation; every behavior plan item needs code/API/UI/runtime/test/evidence trace.
-9. Then run Acceptance Evidence Gate: generate final verdict from the checklist; current API/UI/runtime/data/test contradictions override old passing evidence.
-10. Before completion, use superpowers:verification-before-completion against both matrix and verdict; if either gate fails, continue or report blockers.
+8. Plan Conformance Gate: tests do not prove conformance; sampled path is not full implementation; each behavior item needs code/API/UI/runtime/test/evidence trace.
+9. Acceptance Evidence Gate: verdict from checklist; each AC records proof chain, fresh evidence, missing layers, drift, substitution. Current contradictions override old passes.
+10. Final gate: self-evidence -> matrix -> verdict -> validator -> read-only auditor. Auditor summary is not proof. If audit changes artifact/evidence, rerun validator. Before completion run superpowers:verification-before-completion on matrix/verdict and ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>.
 
 Autonomy/blockers: within current platform/repo/tool/user-authorized permissions, do all safe self-service discovery/execution/verification. Authorized sudo/gsudo/admin elevation is not a user blocker; try it first. Pause only for locally unsatisfiable account/credential/real-env/human-approval/sensitive-field needs; give exact page/system, field location, redaction/do-not-send values and next agent step.
-Never complete on: local audit, subagent summary, final card, code-only/plan-only work, partial tests, stale/partial/sampled evidence, unexercised runtime, artifact not accepted by validator, API/UI not reflected, unapproved scope narrowing or any API/UI/data/runtime/test contradiction.
+Never complete on: local audit, subagent summary, final card, code/plan-only work, partial tests, stale/partial/sampled evidence, missing required layer, material drift, unapproved sibling substitution, unexercised runtime, artifact not accepted, API/UI not reflected, missing validate-plan-acceptance pass, unapproved scope narrowing or any API/UI/data/runtime/test contradiction.
 ```
 
 Before final response, check the prompt length. If it exceeds 3850 characters, tighten wording while preserving paths, input roles, official Superpowers skill names, Product Context Delta, Technical Context Delta, plan-conformance matrix, final verdict, state machine, UI gate, blockers and invalid evidence.
@@ -341,8 +424,13 @@ When successful, return:
 
 When blocked, return:
 
-- Missing required fields.
-- Which source should provide each missing field.
+- Missing Fields Report.
+- `missing_section`.
+- `missing_required_fields`.
+- `why_blocking`.
+- `cannot_infer_policy`.
+- `required_next_input`.
+- `suggested_upstream_action`.
 - A clear statement that no Superpowers target-mode prompt was generated.
 
 Do not claim any plan item or AC has passed unless the user explicitly asked for current completion audit and current evidence was inspected.

package/dist/commands/index.js

@@ -18,6 +18,8 @@ export const commands = {
     "validate-context": (args) => validate(["validate-context", ...args]),
     "validate-code-modularity": (args) => validate(["validate-code-modularity", ...args]),
     "validate-harness": (args) => validate(["validate-harness", ...args]),
+    "validate-plan-contract": (args) => validate(["validate-plan-contract", ...args]),
+    "validate-plan-acceptance": (args) => validate(["validate-plan-acceptance", ...args]),
     package: packageSource
 };
 export function help() {
@@ -34,8 +36,12 @@ export function help() {
                        Export temporary Context, code snapshot or bounded Source Pack artifacts
   validate <gate>      Run a Harness validation gate
   validate-context     Validate Minimal Context fact-source recoverability
-  validate-code-modularity
-                       Enforce touched handwritten source file modularity
-  validate-harness     Run validate-context and validate-code-modularity
+  validate-code-modularity
+                       Enforce touched handwritten source file modularity
+  validate-harness     Run validate-context and validate-code-modularity
+  validate-plan-contract <plan.md|dir>
+                       Validate workflow-contract plan surface consistency
+  validate-plan-acceptance <dir>
+                       Validate plan-conformance matrix and final verdict consistency
   package <subcommand> Maintain package canonical source`);
 }

package/dist/commands/validate.js

@@ -1,7 +1,7 @@
 import { runValidator } from "../lib/validators.js";
 export async function validate(args) {
     const gate = args[0] ?? "validate-harness";
-    const report = await runValidator(process.cwd(), gate);
+    const report = await runValidator(process.cwd(), gate, args.slice(1));
     for (const line of report.info) {
         console.log(line);
     }

package/dist/lib/plan-acceptance-evidence.d.ts

@@ -0,0 +1 @@
+export declare function assertExternalReviewerFields(label: string, row: Record<string, unknown>, evidenceText: string, errors: string[]): void;