project-tiny-context-harness 0.2.71 → 0.2.72

package/README.md

@@ -94,9 +94,9 @@ For ordinary target-mode preparation, a two-document upstream input remains enou
 
 The ordinary long-task path uses `/normal-long-task`. It is the non-Superpowers acceptance pass: it can generate or reuse the full acceptance checklist and can produce a generic target-mode prompt.
 
-The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires `Product Context Delta` and `Technical Context Delta` checks before implementation, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion.
-
-The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`, and completion claims should use `superpowers:verification-before-completion` against both the plan-conformance matrix and final acceptance verdict, followed by `ty-context validate-plan-acceptance <dir>`.
+The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires `Product Context Delta` and `Technical Context Delta` checks before implementation, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion. Complete acceptance rows are treated as externally reviewable evidence claims: the checklist supplies the proof chain, fresh evidence must satisfy every required layer, and material drift, missing layers or unapproved sibling substitution prevent `complete`.
+
+The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`, and completion claims should use `superpowers:verification-before-completion` against both the plan-conformance matrix and final acceptance verdict, followed by `ty-context validate-plan-acceptance <dir>`. When subagents are available, the target prompt asks for a read-only auditor pass after self-evidence and validator checks; the auditor finds gaps but does not become proof.
 
 The reason is drift control. The workflow contract plus Context layer is intentionally a soft constraint. It works well for short tasks, and Context can still capture the expected facts for long tasks, but long execution makes the Context-to-code step drift as the context window grows, work is handed off, subagents split scope or validation loops multiply. A product/architecture source, technical realization plan, acceptance checklist, explicit long-task Skill invocation, target-mode prompt, plan-conformance matrix, final acceptance verdict and optional Superpowers execution layer make implementation conformance and completion evidence recoverable without restoring a phase-gated workflow.
 
@@ -153,7 +153,7 @@ npm ci
 npm run smoke:quickstart
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.71.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.72.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -268,7 +268,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | Full project context export Skill | `<harnessRoot>/skills/context_full_project_export/SKILL.md` | Handles explicit full-project, project-overall, Source Pack or code-level export requests and uses `export-context --source-pack`, `--code-index`, `--task-context`, `--all`, `--full` or `--code` to create temporary artifacts under `tmp/ty-context/context-exports/**`. |
 | Harness upgrade Skill | `<harnessRoot>/skills/context_harness_upgrade/SKILL.md` | Handles explicit Tiny Context / Project Tiny Context Harness upgrade requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project”; it runs the canonical `upgrade` path, handles only migration-scoped `manual_required` / `blocked` follow-up, then runs diagnostics. |
 | Ordinary long-task Skill | `<harnessRoot>/skills/normal-long-task/SKILL.md` | Invoke as `/normal-long-task` to turn a referenced plan, RFC, implementation proposal or two-document upstream input into a falsifiable acceptance checklist and optional generic paste-ready goal/target-mode prompt under `tmp/ty-context/plan-acceptance/**`; if the plan already contains an explicit concrete checklist, the Skill reuses it verbatim in the separate full-checklist file; compact summaries are only navigation/priority, but the Skill does not execute the plan or prove completion. |
-| Superpowers long-task Skill | `<harnessRoot>/skills/superpowers-long-task/SKILL.md` | Invoke as `/superpowers-long-task` when Product / Architecture Source, Technical Realization Plan and Acceptance Checklist exist and Superpowers execution is needed. It emits a Superpowers-specific prompt with Context Delta checks and the official workflow skill names, requires a plan-conformance matrix and final acceptance verdict during execution, and stops when required input fields are missing. It is not a Superpowers official schema and does not generate the technical plan, checklist or execute the plan. |
+| Superpowers long-task Skill | `<harnessRoot>/skills/superpowers-long-task/SKILL.md` | Invoke as `/superpowers-long-task` when Product / Architecture Source, Technical Realization Plan and Acceptance Checklist exist and Superpowers execution is needed. It emits a Superpowers-specific prompt with Context Delta checks and the official workflow skill names, requires a plan-conformance matrix, final acceptance verdict and externally reviewable evidence discipline during execution, and stops when required input fields are missing. It is not a Superpowers official schema and does not generate the technical plan, checklist or execute the plan. |
 | Project-local Skills | `<harnessRoot>/skills/<role>/SKILL.md` | Optional local product/design/development Skills created by the project, such as `product_plan`, `uiux_design` or `development_engineer`. They supersede package-managed default Skills when more specific, are not overwritten by `sync`, and should keep front matter trigger keywords aligned with the project `AGENTS.md` role-trigger rule. |
 | Managed file sync | `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes package-managed guidance, default Skills, Makefile include, context templates, tools and workflow YAML. It does not run migrations or perform semantic Context generation; it may block only direct asset-refresh safety issues such as invalid managed blocks or deprecated managed Skill overrides. |
 | Upgrade | `make ty-context-upgrade` or `npx --yes --package project-tiny-context-harness@latest ty-context upgrade` | Use for releases marked `upgrade-required` or `manual-required`. Builds an upgrade plan, stops before writes when `blocked` items exist, otherwise applies `safe_pending` migrations, runs `sync` and `doctor`, and exits non-zero when manual follow-up or diagnostics remain. |
@@ -284,7 +284,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | Harness validation | `make validate-harness` | Composite gate for `validate-context` and `validate-code-modularity`. |
 | Context validation | `npx --yes --package project-tiny-context-harness@latest ty-context validate-context`, `make validate-context` | Checks required project recovery fields, Context graph metadata, declared paths/roles and fake test-execution claims. |
 | Plan contract validation | `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-contract <plan.md\|dir>` | Checks Source-to-Context Coverage and Context-to-Implementation Binding for structural consistency, referenced path existence and weak-proof complete/bound contradictions. |
-| Plan acceptance validation | `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-acceptance <dir>` | Checks long-task plan-conformance matrix and final verdict JSON for contradictory complete claims, dangling evidence references, weak-proof complete rows, missing plan/AC cross-references and declared surface/architecture binding gaps. |
+| Plan acceptance validation | `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-acceptance <dir>` | Checks long-task plan-conformance matrix and final verdict JSON for contradictory complete claims, dangling evidence references, weak-proof complete rows, missing proof layers, material/critical drift, unapproved sibling substitution, blocking auditor findings, missing plan/AC cross-references and declared surface/architecture binding gaps. |
 | Diagnostics | `make ty-context-doctor` or `npx --yes --package project-tiny-context-harness@latest ty-context doctor` | Reports Harness root, package version, schema version and required Minimal Context paths. |
 | Package source checks | `ty-context package sync-source`, `ty-context package check-source` | Maintainer-only commands for keeping package canonical assets aligned with the source workspace. |
 
@@ -294,7 +294,7 @@ Technical architecture support is a Minimal Context capability: use restrained `
 
 For long-running plans, RFCs or implementation proposals, invoke `/normal-long-task` to turn a plan plus relevant Context into a falsifiable acceptance checklist and an optional generic paste-ready goal/target-mode prompt. It also supports a two-document upstream input from Web GPT or another external planner: `Development Plan` for execution direction and `Acceptance and Tests` for target-mode acceptance input. If the plan already contains an explicit concrete acceptance checklist, the Skill copies that checklist verbatim into a separate full-checklist file instead of generating a competing checklist. The two-document packet path is strict mode: when required fields cannot be fully parsed from both documents, the Skill preserves the inputs, reports the missing fields, and stops without generating a checklist or goal/target-mode prompt. It is one pre-execution acceptance pass, not a task planner or workflow engine: it stores temporary inputs under `tmp/ty-context/plan-acceptance/**`, asks for confirmation when durable assumptions are unclear, and leaves execution evidence to the future executor, tests, CI, review or human acceptance. The generated prompt may require a local audit under the same temporary directory so future sessions can recover acceptance progress; that audit is not Context, not a quality proof and not a replacement for the project's Tiny Context workflow contract. When the prompt references a full checklist, that checklist is the acceptance authority; compact prompt text is only navigation, priority and recovery guidance.
 
-When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*` and `final-acceptance-verdict.*`. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, and it does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections.
+When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*`, `final-acceptance-verdict.*`, proof-chain evidence and optional auditor review. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, and it does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections. `validate-plan-acceptance` is still a structural validator, not a product-quality proof; a subagent auditor is an extra gap-finding pass on top of executor self-evidence and validator checks, not a replacement for either.
 
 For Product Surface work, `context_surface_contract` turns broad product/page/UI principles into project-owned surface responsibilities. A Product Surface can be a Web page, mobile screen, desktop window, game UI/HUD/menu, CLI/TUI output, extension UI or embedded/device interface. Cross-surface contracts use the existing `contract` role; area-owned screen facts stay in `area` or `subdomain`; repeatable validation paths use `verification`. The Harness does not add a new surface-specific role or create business surface contracts during `init` or `upgrade`. Product Surface Context authoring is not a default product-quality validator; plan validators only check declared temporary surface bindings for structural consistency. Projects that want mandatory task blocks should add a separate project-local Skill, while `product-surface-contract.md` is only a compact managed template for optional Context authoring.
 

package/assets/README.md

@@ -94,7 +94,7 @@ That smoke packs the local workspace, installs it into a disposable repo, runs `
 ```sh
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.71.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.72.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -138,9 +138,9 @@ For ordinary target-mode preparation, a two-document upstream input remains enou
 
 The ordinary long-task path uses `/normal-long-task`. It is the non-Superpowers acceptance pass: it can generate or reuse the full acceptance checklist and can produce a generic target-mode prompt.
 
-The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires `Product Context Delta` and `Technical Context Delta` checks before implementation, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion.
-
-The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`, and completion claims should use `superpowers:verification-before-completion` against both the plan-conformance matrix and final acceptance verdict, followed by `ty-context validate-plan-acceptance <dir>`.
+The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. The Skill does not perform complexity routing: invocation means Superpowers long-task execution was already selected. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops with a Missing Fields Report for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires parent-level `Product Context Delta` and `Technical Context Delta` checks before implementation, slice-level new durable fact checks, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion. Complete acceptance rows are treated as externally reviewable evidence claims: the checklist supplies the proof chain, fresh evidence must satisfy every required layer, and material drift, missing layers or unapproved sibling substitution prevent `complete`. An Evidence Ledger / proof index is optional, but complete rows must trace to fresh evidence directly or through an optional `evidence_id`.
+
+The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`. Final gate order is self-evidence, matrix update, verdict update, `ty-context validate-plan-acceptance <dir>`, read-only auditor when available, validator rerun if auditor fixes changed artifacts, then completion only when no blocking conflict remains. `superpowers:verification-before-completion` checks the matrix and verdict before the completion claim. The auditor reconstructs AC proof chains and finds gaps, but does not become proof.
 
 The reason is drift control. The workflow contract plus Context layer is intentionally a soft constraint. It works well for short tasks, and Context can still capture the expected facts for long tasks, but long execution makes the Context-to-code step drift as the context window grows, work is handed off, subagents split scope or validation loops multiply. A product/architecture source, technical realization plan, acceptance checklist, explicit long-task Skill invocation, target-mode prompt, plan-conformance matrix, final acceptance verdict and optional Superpowers execution layer make implementation conformance and completion evidence recoverable without restoring a phase-gated workflow.
 
@@ -305,7 +305,7 @@ No. It checks that recovery facts exist and avoids fake test-result claims. Prod
 
 It should stay smaller than a full process. Ordinary bug fixes and local refactors do not update Context unless they produce durable product, architecture, API, state or validation facts.
 
-The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and explicit long-task requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Long-task artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria or execution evidence for a referenced plan but do not execute it or become durable Context. The ordinary long-task Skill is invoked as `/normal-long-task`: if the plan already contains an explicit concrete checklist, it reuses that checklist verbatim in the separate full-checklist file. For a two-document upstream input, the external planner should provide a `Development Plan` and an `Acceptance and Tests` packet; `/normal-long-task` preserves both source roles and, only when strict-mode required fields are fully parseable from both documents, turns them into the full checklist plus optional generic target prompt. When a generated prompt references a full checklist, that checklist is the authoritative acceptance standard; the compact prompt summary is only navigation and priority guidance. The Superpowers long-task Skill is invoked as `/superpowers-long-task`: it consumes `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`, emits the Superpowers-specific target-mode prompt, requires `Product Context Delta`, `Technical Context Delta`, `plan-conformance-matrix.*` and `final-acceptance-verdict.*` during future execution, is not a Superpowers official schema, and stops if required fields are missing. The Harness upgrade Skill handles requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project” by following the release update mode, using `upgrade` for migration-bearing releases, and limiting manual cleanup to migration-scoped follow-up.
+The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and explicit long-task requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Long-task artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria or execution evidence for a referenced plan but do not execute it or become durable Context. The ordinary long-task Skill is invoked as `/normal-long-task`: if the plan already contains an explicit concrete checklist, it reuses that checklist verbatim in the separate full-checklist file. For a two-document upstream input, the external planner should provide a `Development Plan` and an `Acceptance and Tests` packet; `/normal-long-task` preserves both source roles and, only when strict-mode required fields are fully parseable from both documents, turns them into the full checklist plus optional generic target prompt. When a generated prompt references a full checklist, that checklist is the authoritative acceptance standard; the compact prompt summary is only navigation and priority guidance. The Superpowers long-task Skill is invoked as `/superpowers-long-task`: it consumes `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`, emits the Superpowers-specific target-mode prompt, requires `Product Context Delta`, `Technical Context Delta`, `plan-conformance-matrix.*`, `final-acceptance-verdict.*` and externally reviewable proof-chain evidence during future execution, is not a Superpowers official schema, and stops if required fields are missing. The Harness upgrade Skill handles requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project” by following the release update mode, using `upgrade` for migration-bearing releases, and limiting manual cleanup to migration-scoped follow-up.
 
 Multilingual trigger phrases are compatibility details. Public README, npm and launch copy stay English-first, and public/package-managed surfaces must remain English-complete; literal non-English examples are documented only where they explain generated Skill matching and must not be the sole activation path.
 
@@ -315,9 +315,9 @@ Technical architecture support is a Minimal Context capability: use restrained `
 
 For long-running plans, RFCs or implementation proposals, invoke `/normal-long-task` to turn a plan plus relevant Context into a falsifiable acceptance checklist and an optional generic paste-ready goal/target-mode prompt. It also supports a two-document upstream input from Web GPT or another external planner: `Development Plan` for execution direction and `Acceptance and Tests` for target-mode acceptance input. If the plan already contains an explicit concrete acceptance checklist, the Skill copies that checklist verbatim into a separate full-checklist file instead of generating a competing checklist. The two-document packet path is strict mode: when required fields cannot be fully parsed from both documents, the Skill preserves the inputs, reports the missing fields, and stops without generating a checklist or goal/target-mode prompt. This is one pre-execution acceptance pass, not a task planner or workflow engine: it stores temporary inputs under `tmp/ty-context/plan-acceptance/**`, asks for confirmation when durable assumptions are unclear, and leaves execution evidence to the future executor, tests, CI, review or human acceptance. The generated prompt may require a local audit under the same temporary directory so future sessions can recover acceptance progress; that audit is not Context, not a quality proof and not a replacement for the project's Tiny Context workflow contract. The full checklist is the acceptance authority, while any compact prompt summary exists for navigation, priority and recovery after context compaction.
 
-When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*` and `final-acceptance-verdict.*`. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, and it does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections.
+When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*`, `final-acceptance-verdict.*`, proof-chain evidence and optional auditor review. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, does not route complexity, and does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections. Product / Architecture Source, Technical Realization Plan and Acceptance Checklist remain the upstream authorities, while audit/matrix/verdict/validator/auditor artifacts cannot rewrite them.
 
-Important usage note: Minimal Context intentionally keeps Context read order, Context/code priority and drift checks as agent-level soft constraints rather than machine-enforced gates. That tradeoff works well for short tasks, but long tasks with large context windows, multiple handoffs or many verification loops are expected to drift unless product intent, technical implementation target and acceptance target are externalized. Use `/normal-long-task` before long-running execution when ordinary checklist preparation is needed; use `/superpowers-long-task` when the three upstream inputs already exist and Superpowers execution is desired. Treat the plan-conformance matrix as process trace, the final verdict as final AC-by-AC acceptance evidence, and the local audit only as temporary progress/recovery state.
+Important usage note: Minimal Context intentionally keeps Context read order, Context/code priority and drift checks as agent-level soft constraints rather than machine-enforced gates. That tradeoff works well for short tasks, but long tasks with large context windows, multiple handoffs or many verification loops are expected to drift unless product intent, technical implementation target and acceptance target are externalized. Use `/normal-long-task` before long-running execution when ordinary checklist preparation is needed; use `/superpowers-long-task` when the three upstream inputs already exist and Superpowers execution is desired. Treat the plan-conformance matrix as process trace, the final verdict as final AC-by-AC acceptance evidence, and the local audit only as temporary progress/recovery state. `validate-plan-acceptance` is still an artifact-consistency validator, not a product-quality proof; a subagent auditor is an extra gap-finding pass on top of executor self-evidence and validator checks, not a replacement for either.
 
 For Product Surface work, `context_surface_contract` turns broad product/page/UI principles into project-owned surface responsibilities. A Product Surface can be a Web page, mobile screen, desktop window, game UI/HUD/menu, CLI/TUI output, extension UI or embedded/device interface. Cross-surface contracts use the existing `contract` role; area-owned screen facts stay in `area` or `subdomain`; repeatable validation paths use `verification`. The Harness does not add a new surface-specific role or create business surface contracts during `init` or `upgrade`. Product Surface Context authoring is not a default product-quality validator; plan validators only check declared temporary surface bindings for structural consistency. Projects that want mandatory task blocks should add a separate project-local Skill, while `product-surface-contract.md` is only a compact managed template for optional Context authoring.
 
@@ -395,7 +395,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | `npx --yes --package project-tiny-context-harness@latest ty-context check-modularity --touched [--limit 300] [--fail-on-warning]` | Reports selected handwritten source files over the physical line-count limit; `--file <path>` and `--base <ref>` select explicit files or branch changes, and config waivers are reported distinctly. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context validate-context` | Checks minimum project recovery fields, Context graph metadata, declared paths/roles and fake test-execution claims. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-contract <plan.md\|dir>` | Checks Source-to-Context Coverage and Context-to-Implementation Binding for structural consistency, referenced path existence and weak-proof complete/bound contradictions. |
-| `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-acceptance <dir>` | Checks long-task plan-conformance matrix and final verdict JSON for contradictory complete claims, dangling evidence references, weak-proof complete rows, missing plan/AC cross-references and declared surface/architecture binding gaps. |
+| `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-acceptance <dir>` | Checks long-task plan-conformance matrix and final verdict JSON for contradictory complete claims, dangling evidence references, weak-proof complete rows, missing proof layers, material/critical drift, unapproved sibling substitution, blocking auditor findings, missing plan/AC cross-references and declared surface/architecture binding gaps. |
 | `make validate-context` | Makefile wrapper for `validate-context`. |
 | `make validate-code-modularity` | Hard gate for touched handwritten source modularity; CI can set `TY_CONTEXT_MODULARITY_BASE=<ref>` to audit PR/base changes. |
 | `make validate-harness` | Composite gate for `validate-context` and `validate-code-modularity`. |

package/assets/README.zh-CN.md

@@ -54,9 +54,9 @@ Tiny Context 有两个核心层。Minimal Context 是长期事实源层：说明
 
 对于长程任务，Harness 提供两个显式调用的长程任务 Skill。普通长程任务用 `/normal-long-task`：它把方案和验收输入临时放到 `tmp/ty-context/plan-acceptance/**`，生成或复用完整验收清单，并可输出普通目标模式文本。如果外部规划模型参与，推荐仍然只给两份产物：`《开发方案》` 作为执行方向和 plan traceability source，`《验收清单和测试用例》` 作为 Codex target-mode acceptance input packet。第一份应包含可逐项追踪的 plan item、预期落点 surface、full scope 与 sampled/optional 边界；第二份应包含 AC、required evidence、测试命令、真实产品路径 / core path、证据分层、无效证据、状态机、local audit 和 blocker。Source Pack 只是临时上传材料，不是 durable Context。如果方案里已经有明确、具体的“验收清单”，`/normal-long-task` 会直接复用那份清单并单独写入完整验收清单文件；两份输入包走 strict mode，如果两份内容无法完整解析出 required fields，或第二份缺少 required evidence、verification method、fail condition、状态机、无效证据规则等必要字段，Skill 会停止并列出缺失项，不生成完整验收清单或目标模式文本。
 
-Superpowers 长程任务 Skill 用 `/superpowers-long-task`。如果下一步明确要 Superpowers 目标模式文本，推荐在三份输入都存在后调用：`Product / Architecture Source`（产品/架构原始意图源）、`Technical Realization Plan`（具体技术实现方案）和 `Acceptance Checklist`（验收清单）。它不要求先跑 `/normal-long-task`，但也不会把产品方案现场翻译成技术方案；如果只有产品/架构方案和验收清单，Skill 会停止并报告缺少 `Technical Realization Plan`。两份输入兼容只限第一份明确包含产品/架构源和技术实现方案两个章节。它显式输出 `Superpowers 输入包` 和执行绑定，让未来 executor 清楚哪些输入进入 Product Context Delta、Technical Context Delta、`superpowers:writing-plans`、subagent/inline execution、TDD、`superpowers:verification-before-completion`、local audit、`plan-conformance-matrix.*` 和 `final-acceptance-verdict.*`。这个 prompt 是 Tiny Context 的适配层，不是 Superpowers 官方 schema；它不生成技术方案或验收清单、不执行计划、不证明完成，也不会把临时清单、矩阵或 verdict 注册成 `project_context/**`。
+Superpowers 长程任务 Skill 用 `/superpowers-long-task`。如果下一步明确要 Superpowers 目标模式文本，推荐在三份输入都存在后调用：`Product / Architecture Source`（产品/架构原始意图源）、`Technical Realization Plan`（具体技术实现方案）和 `Acceptance Checklist`（验收清单）。它不做复杂度分流；调用它表示上游已经决定使用 Superpowers 长程执行。它不要求先跑 `/normal-long-task`，但也不会把产品方案现场翻译成技术方案；如果只有产品/架构方案和验收清单，Skill 会用 Missing Fields Report 停止并报告缺少 `Technical Realization Plan`。两份输入兼容只限第一份明确包含产品/架构源和技术实现方案两个章节。它显式输出 `Superpowers 输入包` 和执行绑定，让未来 executor 清楚哪些输入进入 parent-level Product Context Delta / Technical Context Delta、slice-level new durable fact check、`superpowers:writing-plans`、subagent/inline execution、TDD、`superpowers:verification-before-completion`、local audit、`plan-conformance-matrix.*` 和 `final-acceptance-verdict.*`。这个 prompt 是 Tiny Context 的适配层，不是 Superpowers 官方 schema；它不生成技术方案或验收清单、不执行计划、不证明完成，也不会把临时清单、矩阵或 verdict 注册成 `project_context/**`。三输入是上游权威，audit / matrix / verdict / validator / auditor 不能改写它们。完整验收行按外部审计证据处理：proof chain 来自验收清单，fresh evidence 必须满足每个 required layer，存在 material drift、缺 required layer 或未批准 sibling substitution 时不能标 `complete`。Evidence Ledger / proof index 文件可选，但 complete 行必须能直接或通过可选 `evidence_id` 追溯 fresh evidence。
 
-重要使用提示：Minimal Context 有意把 Context 读取顺序、Context / 代码优先级和漂移检查保持为 agent 级软约束，而不是机器强制 edit-order gate。这个取舍适合短任务，但长任务、大上下文、多次交接或多轮验证时预期会漂移。普通 checklist 准备需要 `/normal-long-task`；已有产品/架构原始意图源、具体技术实现方案和验收清单且需要 Superpowers 时，可直接用 `/superpowers-long-task`。`Product Context Delta` 判断产品逻辑、页面职责、信息架构和验收语义是否需要写入 Context；`Technical Context Delta` 判断 API/schema、模块边界、runtime/state、验证/部署路径和稳定技术取舍是否需要写入 Context。`plan-conformance-matrix.*` 是执行期“对图纸台账”，`final-acceptance-verdict.*` 是最后逐 AC 验收报告，local audit 只是临时进度/恢复状态，不能裁判完成。`validate-plan-contract` 和 `validate-plan-acceptance` 只检查临时 artifact 自洽、引用存在、弱证据 complete 行和已声明的 surface/architecture binding 一致性，不证明产品质量。
+重要使用提示：Minimal Context 有意把 Context 读取顺序、Context / 代码优先级和漂移检查保持为 agent 级软约束，而不是机器强制 edit-order gate。这个取舍适合短任务，但长任务、大上下文、多次交接或多轮验证时预期会漂移。普通 checklist 准备需要 `/normal-long-task`；已有产品/架构原始意图源、具体技术实现方案和验收清单且需要 Superpowers 时，可直接用 `/superpowers-long-task`。`Product Context Delta` 判断产品逻辑、页面职责、信息架构和验收语义是否需要写入 Context；`Technical Context Delta` 判断 API/schema、模块边界、runtime/state、验证/部署路径和稳定技术取舍是否需要写入 Context。`plan-conformance-matrix.*` 是执行期“对图纸台账”，`final-acceptance-verdict.*` 是最后逐 AC 验收报告，local audit 只是临时进度/恢复状态，不能裁判完成。最终顺序是 self-evidence -> matrix -> verdict -> validator -> read-only auditor；若审计后修改 artifact/evidence，需重跑 validator。`validate-plan-contract` 和 `validate-plan-acceptance` 只检查临时 artifact 自洽、引用存在、弱证据 complete 行、缺 required proof layer、material/critical drift、sibling substitution 和已声明的 surface/architecture binding 一致性，不证明产品质量。有 subagent 能力时，Superpowers 目标提示会把 subagent 作为只读 auditor 加在主 agent 自证和 validator 之后；auditor 负责找 gap，不是 proof source。
 
 ## 当前最佳实践
 

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.
@@ -113,6 +141,8 @@ 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.
 
@@ -135,6 +165,7 @@ Hard rules:
 - 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
@@ -147,8 +178,13 @@ Each AC verdict entry must include:
 - 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.
 
@@ -171,6 +207,37 @@ Hard rules:
 - 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
 
@@ -252,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.
@@ -283,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，并运行 ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>；失败就继续或报告 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, run superpowers:verification-before-completion on matrix/verdict and ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>; if either fails, continue/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, missing validate-plan-acceptance pass, 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.
@@ -351,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/lib/plan-acceptance-evidence.d.ts

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

package/dist/lib/plan-acceptance-evidence.js

@@ -0,0 +1,68 @@
+import { isOutOfScope } from "./plan-acceptance-json.js";
+import { isBlankish, primitiveText, valuesAsArray } from "./plan-validator-common.js";
+const BLOCKING_AUDITOR_STATUSES = new Set(["partial", "blocked", "invalidated"]);
+export function assertExternalReviewerFields(label, row, evidenceText, errors) {
+    if (hasUnresolvedMissingRequiredLayers(row)) {
+        errors.push(`${label} is complete but missing_required_layers is not empty`);
+    }
+    const driftSeverity = String(row.drift_severity ?? row.driftSeverity ?? "").trim().toLowerCase();
+    if (driftSeverity === "material" || driftSeverity === "critical") {
+        errors.push(`${label} is complete but drift_severity is ${driftSeverity}`);
+    }
+    if (siblingSubstitutionUsed(row) && !hasSiblingSubstitutionApproval(row)) {
+        errors.push(`${label} is complete but sibling_substitution_used without approval`);
+    }
+    const auditorStatus = String(row.auditor_status ?? row.auditorStatus ?? "").trim().toLowerCase();
+    if (BLOCKING_AUDITOR_STATUSES.has(auditorStatus)) {
+        errors.push(`${label} is complete but auditor_status is ${auditorStatus}`);
+    }
+    if (hasOnlySelfCertifyingEvidence(evidenceText)) {
+        errors.push(`${label} is complete but fresh_evidence contains only summary or self-certifying evidence`);
+    }
+}
+function hasUnresolvedMissingRequiredLayers(row) {
+    const value = row.missing_required_layers ?? row.missingRequiredLayers ?? row.missing_proof_layers;
+    if (isBlankish(value)) {
+        return false;
+    }
+    if (Array.isArray(value)) {
+        return value.some((item) => !isBlankish(item) && !isStructuredLayerNa(item));
+    }
+    return !isStructuredLayerNa(value);
+}
+function isStructuredLayerNa(value) {
+    if (!value || typeof value !== "object" || Array.isArray(value)) {
+        return false;
+    }
+    const object = value;
+    const text = primitiveText(object);
+    const hasNaStatus = isOutOfScope(object) || /\bout[_ -]?of[_ -]?scope[_ -]?NA\b/i.test(text);
+    const hasSource = !isBlankish(object.scope_source) ||
+        !isBlankish(object.approval_source) ||
+        !isBlankish(object.source_reference) ||
+        !isBlankish(object.sourceReference);
+    return hasNaStatus && hasSource;
+}
+function siblingSubstitutionUsed(row) {
+    const value = row.sibling_substitution_used ?? row.siblingSubstitutionUsed;
+    if (value === true) {
+        return true;
+    }
+    const text = primitiveText(value);
+    if (/\b(false|no|none|not used|not_used)\b/i.test(text)) {
+        return false;
+    }
+    return /\b(true|yes|used|present)\b/i.test(text);
+}
+function hasSiblingSubstitutionApproval(row) {
+    return (!isBlankish(row.sibling_substitution_approval_source) ||
+        !isBlankish(row.substitution_approval_source) ||
+        /\b(approved|explicitly allowed|out[_ -]?of[_ -]?scope[_ -]?NA)\b/i.test(primitiveText([row.sibling_substitution_approved, row.substitution_approval])));
+}
+function hasOnlySelfCertifyingEvidence(text) {
+    const entries = valuesAsArray(text);
+    return entries.length > 0 && entries.every(isSelfCertifyingEvidence);
+}
+function isSelfCertifyingEvidence(text) {
+    return /\b(local audit|audit says|plan[- ]conformance(?: matrix)?|matrix row|final[- ]acceptance[- ]verdict|final verdict|verdict row|subagent summary|agent summary|reviewer summary|validator pass|validate-plan-acceptance(?: passed| pass)?|green check|final result card)\b/i.test(text);
+}

package/dist/lib/plan-acceptance-validator.js

@@ -1,4 +1,5 @@
 import { pathExists } from "./fs.js";
+import { assertExternalReviewerFields } from "./plan-acceptance-evidence.js";
 import { AC_STATUSES, MATRIX_STATUSES, NON_COMPLETE_AC, NON_COMPLETE_MATRIX, assertStructuredNa, assertSurfaceConformance, contextDeltaRequired, findJsonFile, findRows, hasExplicitNoTestScope, isOutOfScope, isSurfaceConformanceRow, overallStatus, readJson, statusOf } from "./plan-acceptance-json.js";
 import { assertReferencedPathsExist, hasRealPageEvidence, isBlankish, isUiFacing, primitiveText, repoRelative, resolveInputDir, valuesAsArray, weakProofHit } from "./plan-validator-common.js";
 export async function validatePlanAcceptance(projectRoot, args = []) {
@@ -32,7 +33,7 @@ export async function validatePlanAcceptance(projectRoot, args = []) {
     validateContextFactReferences(matrix, verdict, matrixRows, verdictRows, errors);
     info.push(`checked plan acceptance ${repoRelative(projectRoot, targetDir)} matrix_rows=${matrixRows.length} verdict_rows=${verdictRows.length}`);
     if (errors.length === 0) {
-        info.push("Plan acceptance validation passed");
+        info.push("Plan acceptance artifact consistency passed");
     }
     return { info, errors };
 }
@@ -77,6 +78,7 @@ async function validateMatrixRows(projectRoot, rows, overall, errors) {
             if (isBlankish(row.drift)) {
                 errors.push(`${label} is complete but drift is empty`);
             }
+            assertExternalReviewerFields(label, row, primitiveText([row.runtime_evidence, row.artifact_evidence, row.real_page_evidence, row.fresh_evidence]), errors);
             const weak = weakProofHit(primitiveText(row));
             if (weak) {
                 errors.push(`${label} is complete but contains weak-proof language matching /${weak}/`);
@@ -141,6 +143,7 @@ async function validateVerdictRows(projectRoot, rows, overall, errors) {
         }
         if (status === "complete") {
             const text = primitiveText(row);
+            assertExternalReviewerFields(label, row, primitiveText(row.fresh_evidence), errors);
             const weak = weakProofHit(text);
             if (weak) {
                 errors.push(`${label} is complete but contains weak-proof language matching /${weak}/`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "project-tiny-context-harness",
-  "version": "0.2.71",
+  "version": "0.2.72",
   "description": "Minimal project memory and validation harness for AI coding agents.",
   "license": "MIT",
   "author": "Seven128",