project-tiny-context-harness 0.2.83 → 0.2.85

package/README.md

@@ -94,13 +94,13 @@ 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 Composite Long-Task Workflow path uses `/composite-long-task-workflow` 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-backed composite 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 technical realization plan must already satisfy the required Superpowers-ready Markdown implementation plan fields. When it does, the Skill freezes the package-managed workflow into `workflow-protocol.md`, writes task-local `execution-binding.md`, and renders `goal-objective.txt` as a thin Codex Goal objective instead of packing the full workflow into goal text. This is intentional: the Goal objective stays small enough to preserve the persistent completion contract, while the complete executable workflow lives in the protocol snapshot and the task-specific binding. The expected runtime effect is explicit fusion rather than agent improvisation: Tiny Context Workflow Contract first, then three-input authority, state compilation, Superpowers implementation slices, canonical evidence/state updates, generated views, slice/epoch gates and final-gate completion. The workflow is Tiny Context's composite adapter layer, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned schema; it is not the Tiny Context Workflow Contract itself, not a business fact source, not a generic prompt generator and not a Superpowers fork. It may wrap Superpowers with Tiny Context authority, conformance and acceptance gates, but it must not redefine or fork Superpowers execution mechanics. It requires parent-level `Product Context Delta` and `Technical Context Delta` checks before implementation and uses a canonical state kernel under `tmp/ty-context/plan-acceptance/<plan-slug>/`: `task-state.json` is the only execution state source, `events.ndjson` is append-only and `derived/**` contains generated local audit, plan-conformance matrix, final acceptance verdict, progress ledger, evidence index, context alignment and final summary views. Complete acceptance rows are externally reviewable evidence claims derived from `task-state.evidence[]`: the checklist supplies the proof chain, fresh reviewable evidence must satisfy every required layer, and machine-verifiable layers such as UI/browser/runtime/API/data/integration/test require passed assertion results, zero command/assertion exit codes, target AC/layer coverage, passed positive and negative assertions and no negative evidence contradiction. Screenshot-only proof, component screenshots, viewmodels, diagnostic pages, API-only proof for a UI Path AC, final cards, matrix/verdict rows, validator passes and prose summaries are invalid as completion proof for those layers. Material drift, missing layers, failed/stale assertion reports, failed negative evidence scans or unapproved sibling substitution prevent `complete`. Goal-mode wording separates `audit_task_complete`, `acceptance_target_status` and computed `product_goal_complete`: implementation / execution goals complete only when `ty-context composite-long-task final-gate` computes `product_goal_complete=true`; read-only audit goals may end at `audit_task_complete`, but a non-accepted verdict says `Audit workflow completed; acceptance target not complete.` and does not use unqualified `Goal achieved` or `update_goal(status="complete")` as acceptance of the user target.
+The Composite Long-Task Workflow path uses `/composite-long-task-workflow` 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-backed composite 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 technical realization plan must already satisfy the required Superpowers-ready Markdown implementation plan fields. When it does, the Skill freezes the package-managed workflow into `workflow-protocol.md`, writes task-local `execution-binding.md`, and renders `goal-objective.txt` as a thin Codex Goal objective instead of packing the full workflow into goal text. This is intentional: the Goal objective stays small enough to preserve the persistent completion contract, while the complete executable workflow lives in the protocol snapshot and the task-specific binding. The expected runtime effect is explicit fusion rather than agent improvisation: Tiny Context Workflow Contract first, then three-input authority, state compilation, Superpowers implementation slices, canonical evidence/state updates, generated views, slice/epoch gates and final-gate completion. The workflow is Tiny Context's composite adapter layer, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned schema; it is not the Tiny Context Workflow Contract itself, not a business fact source, not a generic prompt generator and not a Superpowers fork. It may wrap Superpowers with Tiny Context authority, conformance and acceptance gates, but it must not redefine or fork Superpowers execution mechanics. It requires parent-level `Product Context Delta` and `Technical Context Delta` checks before implementation and uses a canonical state kernel under `tmp/ty-context/plan-acceptance/<plan-slug>/`: `task-state.json` is the only execution state source, `events.ndjson` is append-only and `derived/**` contains generated local audit, plan-conformance matrix, final acceptance verdict, progress ledger, evidence index, context alignment, final summary and final card views. Complete acceptance rows are externally reviewable evidence claims derived from `task-state.evidence[]`: the checklist supplies the proof chain, fresh reviewable evidence must satisfy every required layer, and machine-verifiable layers such as UI/browser/runtime/API/data/integration/test require passed assertion results, zero command/assertion exit codes, target AC/layer coverage, passed positive and negative assertions and no negative evidence contradiction. Screenshot-only proof, component screenshots, viewmodels, diagnostic pages, API-only proof for a UI Path AC, final cards, matrix/verdict rows, validator passes and prose summaries are invalid as completion proof for those layers. Material drift, missing layers, failed/stale assertion reports, failed negative evidence scans or unapproved sibling substitution prevent `complete`. Goal-mode wording separates `audit_task_complete`, `acceptance_target_status`, computed `product_goal_complete` and resolver-owned `completion_output_status`: implementation / execution goals complete only when `ty-context composite-long-task final-gate` computes `product_goal_complete=true` and `completion_output_status=accept`; read-only audit goals may end at `audit_task_complete`, but a non-accepted verdict says `Audit workflow completed; acceptance target not complete.` and does not use unqualified `Goal achieved` or `update_goal(status="complete")` as acceptance of the user target. Non-accepting final-gate output also carries `blocker_triage` category and next action; transient bookkeeping or regenerable generated-output mismatch can self-recover once, while real evidence, environment, contract and harness-drift blockers remain explicit.
 
-Strict completion is current-attempt-only and runs through one Trusted Evidence Kernel. `compile` derives required command specs from each machine-blocking AC's `assertion_command`, `assertion_artifacts`, proof layers, required tests, positive/negative assertions, invalid completion signals and expected final evidence; `start-attempt --mode product_task|harness_task` records the current execution identity; `run-assertion` records assertion command runs; `record-evidence` registers artifacts as canonical EvidenceRecordV2; and `final-gate` recomputes from current records. EvidenceRecordV2 must carry attempt/source/product/plan/checklist hashes, git head, worktree fingerprint, command spec/run ids, command line and exit code, artifact path/SHA/mtime, target AC ids, target PI ids, target proof layers, assertion status/exit code, positive assertions, negative assertions, invalid completion signals, negative evidence scan and required test ids. Legacy v1 evidence, historical `events.ndjson` complete events, stale `derived/**` views, validator passes, final cards, auditor prose, AC summary-only proof and unregistered temporary JSON cannot complete machine-blocking ACs. Newer failed command runs, Playwright/JUnit/test result failures, owner DOM forbidden states, source/worktree drift, task-state false/partial status and derived/state mismatches invalidate older passed evidence for the same AC/layer.
+Strict completion is current-attempt-only and runs through one Trusted Evidence Kernel shared by final gate, `validate-superpowers-state`, state-backed `validate-plan-acceptance` and derived completion views, then through one completion-output resolver. `compile` derives required command specs from each machine-blocking AC's `assertion_command`, `assertion_artifacts`, proof layers, required tests, positive/negative assertions, invalid completion signals and expected final evidence; `start-attempt --mode product_task|harness_task` records the current execution identity; `run-assertion` records assertion command runs; `record-evidence` registers artifacts as canonical EvidenceRecordV2; and `final-gate` recomputes from current records. EvidenceRecordV2 must carry attempt/source/product/plan/checklist hashes, git head, worktree fingerprint, command spec/run ids, command line and exit code, artifact path/SHA/mtime, target AC ids, target PI ids, target proof layers, assertion status/exit code, positive assertions, negative assertions, invalid completion signals, negative evidence scan and required test ids. Legacy v1 evidence, historical `events.ndjson` complete events, stale `derived/**` views, matrix/verdict/evidence-index/final-summary rows, validator passes, final cards, auditor prose, AC summary-only proof, unregistered temporary JSON and hand-written status files cannot complete machine-blocking ACs or authorize generated final-answer `accept`. Newer failed command runs, Playwright/JUnit/test result failures, owner DOM forbidden states, source/worktree drift, task-state false/partial status and derived/state mismatches invalidate older passed evidence for the same AC/layer.
 
-The final-gate order is fixed inside the kernel: load the three inputs, recompute source hashes, load task state, load current attempt, load command-run records, load registered EvidenceRecords, discard stale evidence, scan contradictions, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, regenerate `derived/**` and append an event. A machine-blocking AC with missing assertion command/artifacts/assertions/invalid signals, UI proof without browser/e2e/smoke/trace evidence, generated-only final evidence, manual-only test cases or no possible `assertion_result` is `under_specified`; its PI is blocked and `product_goal_complete=false`. AC-010/final-gate summary evidence cannot bootstrap other ACs: if a summary AC passes while another required AC is missing, failed or stale, the summary AC is invalidated with `final_gate_cannot_bootstrap_from_summary_only`.
+The final-gate order is fixed inside the kernel and output resolver: load the three inputs, recompute source hashes, load task state, snapshot previous final/gates/meta transient bookkeeping as audit-only, resolve the current attempt, load required command specs, load command-run records, load registered EvidenceRecords, discard stale evidence, scan unregistered assertion JSON, scan contradictions, run AC-010 bootstrap prevention, run under-specified AC checks, run Harness Drift Lock, run protected baseline guard, validate scope conflicts, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, build current candidate state, resolve candidate `completion_output_status`, regenerate current `derived/**`, scan generated output in current-candidate mode, classify `blocker_triage`, self-recover once when allowed and append an event. A machine-blocking AC with missing assertion command/artifacts/assertions/invalid signals, UI proof without browser/e2e/smoke/trace evidence, generated-only final evidence, manual-only test cases or no possible `assertion_result` is `under_specified`; its PI is blocked and `product_goal_complete=false`. AC-010/final-gate summary evidence cannot bootstrap other ACs: if a summary AC passes while another required AC is missing, failed or stale, the summary AC is invalidated with `final_gate_cannot_bootstrap_from_summary_only`.
 
-Harness Drift Lock separates product proof from harness proof. A `product_task` that changes Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, composite workflow Skill/protocol or related Makefile/package test targets is blocked with `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and the message "本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。" A `harness_task` may change harness files only with adversarial fixtures whose expected final-gate outcomes include stale evidence, historical complete, derived contradiction, AC010 summary-only, target mismatch, API-only-for-UI, negative evidence after pass, source hash mismatch, dirty worktree mismatch, missing assertion_result, test weakening and a happy path; it proves the harness, not product completion. `protected-harness-baseline.json` protects the final gate, validator, derive, evidence registration, assertion schema, fixture expectations, workflow protocol, Skill markdown and test runner scripts; product tasks changing that baseline are blocked, and harness tasks need a baseline reason plus fixture verification.
+Harness Drift Lock separates product proof from harness proof. A `product_task` that changes Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, composite workflow Skill/protocol or related Makefile/package test targets is blocked with `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and the message "本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。" A `harness_task` may change harness files only with adversarial fixtures whose expected final-gate outcomes include stale evidence, historical complete, derived contradiction, AC010 summary-only, target mismatch, API-only-for-UI, negative evidence after pass, source hash mismatch, dirty worktree mismatch, missing assertion_result, test weakening, scope leakage, missing UI/browser owner-surface proof, missing negative semantic proof and a happy path; it proves the harness, not product completion. `protected-harness-baseline.json` protects the final gate, validator, derive, evidence registration, assertion schema, fixture expectations, workflow protocol, Skill markdown and test runner scripts; product tasks changing that baseline are blocked, and harness tasks need a baseline reason plus fixture verification. HFC-003 is the durable false-completion regression suite: 35 committed mini workdirs plus one runner cover the Trusted Evidence Kernel, completion-output resolver, generated-output scanner, selected CLI smoke paths and one happy path, and are package release blockers for harness changes.
 
 The three inputs also carry capability-first delivery boundaries. Product / Architecture Source declares `delivery_scope`, `full_population_required`, samples that validate the claim, samples that do not validate it and out-of-scope backlog. Each Technical Realization Plan item declares delivery scope, capability target, representative samples, full-population boundary and non-required population. Each Acceptance Checklist item declares acceptance scope, what it validates and does not validate, sample boundary and full-population requirement. `scope_conflict_requires_decision` blocks completion when source, plan and checklist disagree between system capability build, representative sample validation and full-population operation. Sample evidence or framework-only implementation cannot prove all-provider, all-interface, all-platform or full-population completion unless the AC explicitly allows it; when full population is not explicitly required, generated views report it as `not_in_scope`.
 
@@ -171,7 +171,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.83.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.85.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```

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.83.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.85.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -138,13 +138,13 @@ 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 Composite Long-Task Workflow path uses `/composite-long-task-workflow` 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-backed composite 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 technical realization plan must already satisfy the required Superpowers-ready Markdown implementation plan fields. When it does, the Skill freezes the package-managed workflow into `workflow-protocol.md`, writes task-local `execution-binding.md`, and renders `goal-objective.txt` as a thin Codex Goal objective instead of packing the full workflow into goal text. This is intentional: the Goal objective stays small enough to preserve the persistent completion contract, while the complete executable workflow lives in the protocol snapshot and the task-specific binding. The expected runtime effect is explicit fusion rather than agent improvisation: Tiny Context Workflow Contract first, then three-input authority, state compilation, Superpowers implementation slices, canonical evidence/state updates, generated views, slice/epoch gates and final-gate completion. The workflow is Tiny Context's composite adapter layer, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned schema; it is not the Tiny Context Workflow Contract itself, not a business fact source, not a generic prompt generator and not a Superpowers fork. It may wrap Superpowers with Tiny Context authority, conformance and acceptance gates, but it must not redefine or fork Superpowers execution mechanics. It requires parent-level `Product Context Delta` and `Technical Context Delta` checks before implementation and uses a canonical state kernel under `tmp/ty-context/plan-acceptance/<plan-slug>/`: `task-state.json` is the only execution state source, `events.ndjson` is append-only and `derived/**` contains generated local audit, plan-conformance matrix, final acceptance verdict, progress ledger, evidence index, context alignment and final summary views. Complete acceptance rows are externally reviewable evidence claims derived from `task-state.evidence[]`: the checklist supplies the proof chain, fresh reviewable evidence must satisfy every required layer, and machine-verifiable layers such as UI/browser/runtime/API/data/integration/test require passed assertion results, zero command/assertion exit codes, target AC/layer coverage, passed positive and negative assertions and no negative evidence contradiction. Screenshot-only proof, component screenshots, viewmodels, diagnostic pages, API-only proof for a UI Path AC, final cards, matrix/verdict rows, validator passes and prose summaries are invalid as completion proof for those layers. Material drift, missing layers, failed/stale assertion reports, failed negative evidence scans or unapproved sibling substitution prevent `complete`. Goal-mode wording separates `audit_task_complete`, `acceptance_target_status` and computed `product_goal_complete`: implementation / execution goals complete only when `ty-context composite-long-task final-gate` computes `product_goal_complete=true`; read-only audit goals may end at `audit_task_complete`, but a non-accepted verdict says `Audit workflow completed; acceptance target not complete.` and does not use unqualified `Goal achieved` or `update_goal(status="complete")` as acceptance of the user target.
+The Composite Long-Task Workflow path uses `/composite-long-task-workflow` 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-backed composite 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 technical realization plan must already satisfy the required Superpowers-ready Markdown implementation plan fields. When it does, the Skill freezes the package-managed workflow into `workflow-protocol.md`, writes task-local `execution-binding.md`, and renders `goal-objective.txt` as a thin Codex Goal objective instead of packing the full workflow into goal text. This is intentional: the Goal objective stays small enough to preserve the persistent completion contract, while the complete executable workflow lives in the protocol snapshot and the task-specific binding. The expected runtime effect is explicit fusion rather than agent improvisation: Tiny Context Workflow Contract first, then three-input authority, state compilation, Superpowers implementation slices, canonical evidence/state updates, generated views, slice/epoch gates and final-gate completion. The workflow is Tiny Context's composite adapter layer, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned schema; it is not the Tiny Context Workflow Contract itself, not a business fact source, not a generic prompt generator and not a Superpowers fork. It may wrap Superpowers with Tiny Context authority, conformance and acceptance gates, but it must not redefine or fork Superpowers execution mechanics. It requires parent-level `Product Context Delta` and `Technical Context Delta` checks before implementation and uses a canonical state kernel under `tmp/ty-context/plan-acceptance/<plan-slug>/`: `task-state.json` is the only execution state source, `events.ndjson` is append-only and `derived/**` contains generated local audit, plan-conformance matrix, final acceptance verdict, progress ledger, evidence index, context alignment, final summary and final card views. Complete acceptance rows are externally reviewable evidence claims derived from `task-state.evidence[]`: the checklist supplies the proof chain, fresh reviewable evidence must satisfy every required layer, and machine-verifiable layers such as UI/browser/runtime/API/data/integration/test require passed assertion results, zero command/assertion exit codes, target AC/layer coverage, passed positive and negative assertions and no negative evidence contradiction. Screenshot-only proof, component screenshots, viewmodels, diagnostic pages, API-only proof for a UI Path AC, final cards, matrix/verdict rows, validator passes and prose summaries are invalid as completion proof for those layers. Material drift, missing layers, failed/stale assertion reports, failed negative evidence scans or unapproved sibling substitution prevent `complete`. Goal-mode wording separates `audit_task_complete`, `acceptance_target_status`, computed `product_goal_complete` and resolver-owned `completion_output_status`: implementation / execution goals complete only when `ty-context composite-long-task final-gate` computes `product_goal_complete=true` and `completion_output_status=accept`; read-only audit goals may end at `audit_task_complete`, but a non-accepted verdict says `Audit workflow completed; acceptance target not complete.` and does not use unqualified `Goal achieved` or `update_goal(status="complete")` as acceptance of the user target.
 
-Strict completion is current-attempt-only and runs through one Trusted Evidence Kernel. `compile` derives required command specs from each machine-blocking AC's `assertion_command`, `assertion_artifacts`, proof layers, required tests, positive/negative assertions, invalid completion signals and expected final evidence; `start-attempt --mode product_task|harness_task` records the current execution identity; `run-assertion` records assertion command runs; `record-evidence` registers artifacts as canonical EvidenceRecordV2; and `final-gate` recomputes from current records. EvidenceRecordV2 must carry attempt/source/product/plan/checklist hashes, git head, worktree fingerprint, command spec/run ids, command line and exit code, artifact path/SHA/mtime, target AC ids, target PI ids, target proof layers, assertion status/exit code, positive assertions, negative assertions, invalid completion signals, negative evidence scan and required test ids. Legacy v1 evidence, historical `events.ndjson` complete events, stale `derived/**` views, validator passes, final cards, auditor prose, AC summary-only proof and unregistered temporary JSON cannot complete machine-blocking ACs. Newer failed command runs, Playwright/JUnit/test result failures, owner DOM forbidden states, source/worktree drift, task-state false/partial status and derived/state mismatches invalidate older passed evidence for the same AC/layer.
+Strict completion is current-attempt-only and runs through one Trusted Evidence Kernel shared by final gate, `validate-superpowers-state`, state-backed `validate-plan-acceptance` and derived completion views, then through one completion-output resolver. `compile` derives required command specs from each machine-blocking AC's `assertion_command`, `assertion_artifacts`, proof layers, required tests, positive/negative assertions, invalid completion signals and expected final evidence; `start-attempt --mode product_task|harness_task` records the current execution identity; `run-assertion` records assertion command runs; `record-evidence` registers artifacts as canonical EvidenceRecordV2; and `final-gate` recomputes from current records. EvidenceRecordV2 must carry attempt/source/product/plan/checklist hashes, git head, worktree fingerprint, command spec/run ids, command line and exit code, artifact path/SHA/mtime, target AC ids, target PI ids, target proof layers, assertion status/exit code, positive assertions, negative assertions, invalid completion signals, negative evidence scan and required test ids. Legacy v1 evidence, historical `events.ndjson` complete events, stale `derived/**` views, matrix/verdict/evidence-index/final-summary rows, validator passes, final cards, auditor prose, AC summary-only proof, unregistered temporary JSON and hand-written status files cannot complete machine-blocking ACs or authorize generated final-answer `accept`. Newer failed command runs, Playwright/JUnit/test result failures, owner DOM forbidden states, source/worktree drift, task-state false/partial status and derived/state mismatches invalidate older passed evidence for the same AC/layer.
 
-The final-gate order is fixed inside the kernel: load the three inputs, recompute source hashes, load task state, load current attempt, load command-run records, load registered EvidenceRecords, discard stale evidence, scan contradictions, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, regenerate `derived/**` and append an event. A machine-blocking AC with missing assertion command/artifacts/assertions/invalid signals, UI proof without browser/e2e/smoke/trace evidence, generated-only final evidence, manual-only test cases or no possible `assertion_result` is `under_specified`; its PI is blocked and `product_goal_complete=false`. AC-010/final-gate summary evidence cannot bootstrap other ACs: if a summary AC passes while another required AC is missing, failed or stale, the summary AC is invalidated with `final_gate_cannot_bootstrap_from_summary_only`.
+The final-gate order is fixed inside the kernel and output resolver: load the three inputs, recompute source hashes, load task state, resolve the current attempt, load required command specs, load command-run records, load registered EvidenceRecords, discard stale evidence, scan unregistered assertion JSON, scan contradictions, run AC-010 bootstrap prevention, run under-specified AC checks, run Harness Drift Lock, run protected baseline guard, validate scope conflicts, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, resolve `completion_output_status`, regenerate `derived/**` and append an event. A machine-blocking AC with missing assertion command/artifacts/assertions/invalid signals, UI proof without browser/e2e/smoke/trace evidence, generated-only final evidence, manual-only test cases or no possible `assertion_result` is `under_specified`; its PI is blocked and `product_goal_complete=false`. AC-010/final-gate summary evidence cannot bootstrap other ACs: if a summary AC passes while another required AC is missing, failed or stale, the summary AC is invalidated with `final_gate_cannot_bootstrap_from_summary_only`.
 
-Harness Drift Lock separates product proof from harness proof. A `product_task` that changes Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, composite workflow Skill/protocol or related Makefile/package test targets is blocked with `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and the message "本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。" A `harness_task` may change harness files only with adversarial fixtures whose expected final-gate outcomes include stale evidence, historical complete, derived contradiction, AC010 summary-only, target mismatch, API-only-for-UI, negative evidence after pass, source hash mismatch, dirty worktree mismatch, missing assertion_result, test weakening and a happy path; it proves the harness, not product completion. `protected-harness-baseline.json` protects the final gate, validator, derive, evidence registration, assertion schema, fixture expectations, workflow protocol, Skill markdown and test runner scripts; product tasks changing that baseline are blocked, and harness tasks need a baseline reason plus fixture verification.
+Harness Drift Lock separates product proof from harness proof. A `product_task` that changes Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, composite workflow Skill/protocol or related Makefile/package test targets is blocked with `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and the message "本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。" A `harness_task` may change harness files only with adversarial fixtures whose expected final-gate outcomes include stale evidence, historical complete, derived contradiction, AC010 summary-only, target mismatch, API-only-for-UI, negative evidence after pass, source hash mismatch, dirty worktree mismatch, missing assertion_result, test weakening, scope leakage, missing UI/browser owner-surface proof, missing negative semantic proof and a happy path; it proves the harness, not product completion. `protected-harness-baseline.json` protects the final gate, validator, derive, evidence registration, assertion schema, fixture expectations, workflow protocol, Skill markdown and test runner scripts; product tasks changing that baseline are blocked, and harness tasks need a baseline reason plus fixture verification. HFC-003 is the durable false-completion regression suite: 35 committed mini workdirs plus one runner cover the Trusted Evidence Kernel, completion-output resolver, generated-output scanner, selected CLI smoke paths and one happy path, and are package release blockers for harness changes.
 
 The three inputs also carry capability-first delivery boundaries. Product / Architecture Source declares `delivery_scope`, `full_population_required`, samples that validate the claim, samples that do not validate it and out-of-scope backlog. Each Technical Realization Plan item declares delivery scope, capability target, representative samples, full-population boundary and non-required population. Each Acceptance Checklist item declares acceptance scope, what it validates and does not validate, sample boundary and full-population requirement. `scope_conflict_requires_decision` blocks completion when source, plan and checklist disagree between system capability build, representative sample validation and full-population operation. Sample evidence or framework-only implementation cannot prove all-provider, all-interface, all-platform or full-population completion unless the AC explicitly allows it; when full population is not explicitly required, generated views report it as `not_in_scope`.
 
@@ -331,11 +331,11 @@ 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-backed long-task execution, invoke `/composite-long-task-workflow` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits `workflow-protocol.md`, `execution-binding.md` and `goal-objective.txt` so the future executor sees which inputs feed Context Delta assessment, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, canonical `task-state.json`, append-only `events.ndjson`, generated `derived/**` views, proof-chain evidence and optional auditor review. This is Tiny Context's composite adapter layer for Superpowers-backed workflows, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned schema. It may wrap Superpowers with authority, conformance and acceptance gates, but it must not redefine, duplicate or fork Superpowers execution mechanics; if a future Tiny Context-added step would conflict with, duplicate or override a Superpowers responsibility, stop and surface the boundary conflict instead of silently merging workflows. 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; the Technical Realization Plan must already be a Superpowers-ready Markdown implementation plan or the Skill stops before rendering entry artifacts. 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 state/derived views/validator/auditor artifacts cannot rewrite them. Capability-first delivery scope stays inside those same three inputs: source, plan items and ACs must explicitly distinguish reusable system capability build, representative sample validation, full population operation and out-of-scope backlog; `scope_conflict_requires_decision` blocks completion, and sample/framework evidence cannot prove full population unless the AC says so. The generated Goal objective also disambiguates `audit_task_complete`, `acceptance_target_status` and computed `product_goal_complete`; implementation / execution goals finish only when `product_goal_complete=true`, while a read-only audit goal can end at `audit_task_complete` only with a non-accepted verdict reported as `Audit workflow completed; acceptance target not complete.`, not as `Goal achieved`.
+When the next step explicitly needs Superpowers-backed long-task execution, invoke `/composite-long-task-workflow` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits `workflow-protocol.md`, `execution-binding.md` and `goal-objective.txt` so the future executor sees which inputs feed Context Delta assessment, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, canonical `task-state.json`, append-only `events.ndjson`, generated `derived/**` views, proof-chain evidence and optional auditor review. This is Tiny Context's composite adapter layer for Superpowers-backed workflows, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned schema. It may wrap Superpowers with authority, conformance and acceptance gates, but it must not redefine, duplicate or fork Superpowers execution mechanics; if a future Tiny Context-added step would conflict with, duplicate or override a Superpowers responsibility, stop and surface the boundary conflict instead of silently merging workflows. 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; the Technical Realization Plan must already be a Superpowers-ready Markdown implementation plan or the Skill stops before rendering entry artifacts. 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 state/derived views/validator/auditor artifacts cannot rewrite them. Capability-first delivery scope stays inside those same three inputs: source, plan items and ACs must explicitly distinguish reusable system capability build, representative sample validation, full population operation and out-of-scope backlog; `scope_conflict_requires_decision` blocks completion, and sample/framework evidence cannot prove full population unless the AC says so. The generated Goal objective also disambiguates `audit_task_complete`, `acceptance_target_status`, computed `product_goal_complete` and resolver-owned `completion_output_status`; implementation / execution goals finish only when `product_goal_complete=true` and `completion_output_status=accept`, while a read-only audit goal can end at `audit_task_complete` only with a non-accepted verdict reported as `Audit workflow completed; acceptance target not complete.`, not as `Goal achieved`. When final-gate does not accept, generated output includes `blocker_triage` category and next action; self-recoverable transient bookkeeping or generated-output mismatch can be regenerated once, but missing evidence, environment, contract and harness-drift blockers remain explicit.
 
-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. Superpowers alone can still drift under this pressure: it strengthens execution discipline, but it does not by itself preserve source authority, prevent scope shrinkage, prove full conformance to the Technical Realization Plan or enforce AC-by-AC evidence against the Acceptance Checklist. Use `/normal-long-task` before long-running execution when ordinary checklist preparation is needed; use `/composite-long-task-workflow` when the three upstream inputs already exist and Superpowers-backed execution is desired. Treat `task-state.json` as the only execution state source, `events.ndjson` as append-only, `derived/**` as generated reading views and `task-state.evidence[]` as the canonical evidence ledger. `validate-superpowers-state` and state-backed `validate-plan-acceptance` are still artifact/state-consistency validators, not product-quality proof; they now also reject missing/failed assertion-backed evidence for machine-verifiable layers and negative evidence contradictions. A subagent auditor is an extra gap-finding pass on top of executor self-evidence and validator checks, not a replacement for either. Passing Superpowers review or verification does not bypass incomplete state rows, weak evidence, missing proof layers, failed assertion gates or blocking auditor findings.
+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. Superpowers alone can still drift under this pressure: it strengthens execution discipline, but it does not by itself preserve source authority, prevent scope shrinkage, prove full conformance to the Technical Realization Plan or enforce AC-by-AC evidence against the Acceptance Checklist. Use `/normal-long-task` before long-running execution when ordinary checklist preparation is needed; use `/composite-long-task-workflow` when the three upstream inputs already exist and Superpowers-backed execution is desired. Treat `task-state.json` as the only execution state source, `events.ndjson` as append-only, `derived/**` as generated reading views and `task-state.evidence[]` as the canonical evidence ledger. `validate-superpowers-state` and state-backed `validate-plan-acceptance` are still artifact/state-consistency validators, not product-quality proof; they now also reject missing/failed assertion-backed evidence for machine-verifiable layers, negative evidence contradictions, generated-output mismatch and false-completion wording under non-accept resolver status, and they surface state-backed blocker triage when final-gate has written it. A subagent auditor is an extra gap-finding pass on top of executor self-evidence and validator checks, not a replacement for either. Passing Superpowers review or verification does not bypass incomplete state rows, weak evidence, missing proof layers, failed assertion gates or blocking auditor findings.
 
-Hallucination guard: do not register `workflow-protocol.md` in `project_context/context.toml`, treat it as business Context, let `derived/**` rewrite Product / Plan / Checklist, use local audit or Superpowers review as quality proof, use screenshots/final cards/matrix/verdict/validator pass/prose as machine-verifiable proof, use sample evidence as full-population proof, claim full alignment while Source-to-Context Coverage or Context-to-Implementation Binding has unresolved required gaps, handwrite `product_goal_complete`, or complete an implementation Goal before final-gate passes.
+Hallucination guard: do not register `workflow-protocol.md` in `project_context/context.toml`, treat it as business Context, let `derived/**` rewrite Product / Plan / Checklist, use local audit or Superpowers review as quality proof, use screenshots/final cards/matrix/verdict/validator pass/prose as machine-verifiable proof, use sample evidence as full-population proof, claim full alignment while Source-to-Context Coverage or Context-to-Implementation Binding has unresolved required gaps, handwrite `product_goal_complete` or `completion_output_status`, or complete an implementation Goal before final-gate passes and resolver status is `accept`.
 
 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.zh-CN.md

@@ -54,7 +54,7 @@ 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 会停止并列出缺失项，不生成完整验收清单或目标模式文本。
 
-Composite Long-Task Workflow Skill 用 `/composite-long-task-workflow`。如果下一步明确要 Superpowers-backed 目标模式执行，推荐在三份输入都存在后调用：`Product / Architecture Source`（产品/架构原始意图源）、`Technical Realization Plan`（具体技术实现方案）和 `Acceptance Checklist`（验收清单）。它不做复杂度分流；调用它表示上游已经决定使用 composite long-task execution。它不要求先跑 `/normal-long-task`，但也不会把产品方案现场翻译成技术方案；如果只有产品/架构方案和验收清单，Skill 会用 Missing Fields Report 停止并报告缺少 `Technical Realization Plan`。两份输入兼容只限第一份明确包含产品/架构源和技术实现方案两个章节。`Technical Realization Plan` 必须已经满足 Superpowers-ready Markdown implementation plan 的必填字段；满足时它跳过方案生成，直接绑定 Superpowers 执行，不满足时直接中断并报告缺失字段，不生成 prompt。它输出 `workflow-protocol.md`、`execution-binding.md` 和可直接用于 Codex Goal mode 的薄 `goal-objective.txt`，不是把完整 workflow 塞进 4000 字 Goal：Goal 只保留持续完成契约，完整可执行流程放在 protocol snapshot 和 task-specific binding。预期运行效果是显式融合而不是让 agent 自行发挥：先 Tiny Context 流程契约，再三份输入权威，再编译 task-state，再进入 Superpowers implementation slice，每个 slice 更新 canonical state/evidence，derive 出阅读视图，经过 slice/epoch gate，最后 final-gate 计算完成。这个 workflow 是面向 Superpowers execution 的 Tiny Context 适配层，对齐官方 Superpowers skills，但不是上游维护的 schema；它不是 Tiny Context 流程契约本身、不是业务事实源、不是普通 prompt generator、也不是 Superpowers fork。它可以在 Superpowers 外层增加 Tiny Context 的权威、对图纸和验收门禁，但不能重新定义、重复或分叉 Superpowers 执行机制。如果未来改动让 Tiny Context 新增步骤和官方 Superpowers 职责冲突、重复或覆盖，应停止修改并提示边界冲突，不要静默合并两套流程。它不生成技术方案或验收清单、不执行计划、不证明完成，也不会把临时 state、derived views 或 verdict 注册成 `project_context/**`。三输入是上游权威，state / derived views / validator / auditor 不能改写它们。`task-state.json` 是唯一执行状态源，`events.ndjson` 追加记录状态变更，`derived/**` 只生成 local audit、plan-conformance matrix、final acceptance verdict、progress ledger、evidence index、context alignment 和 final summary 等阅读视图。完整验收行按外部审计证据处理：proof chain 来自验收清单，fresh evidence 必须通过 `task-state.evidence[]` 满足每个 required layer，存在 material drift、缺 required layer 或未批准 sibling substitution 时不能标 `complete`。Goal mode 表述必须区分 `audit_task_complete`、`acceptance_target_status` 和 computed `product_goal_complete`：实现/执行目标只在 `ty-context composite-long-task final-gate` 计算出 `product_goal_complete=true` 时完成；只读审计目标可在 `audit_task_complete` 时结束，但 verdict 不是 accepted/complete 时，回复写 `Audit workflow completed; acceptance target not complete.`，不能用未限定的 `Goal achieved` 或 `update_goal(status="complete")` 表示用户验收目标已完成。
+Composite Long-Task Workflow Skill 用 `/composite-long-task-workflow`。如果下一步明确要 Superpowers-backed 目标模式执行，推荐在三份输入都存在后调用：`Product / Architecture Source`（产品/架构原始意图源）、`Technical Realization Plan`（具体技术实现方案）和 `Acceptance Checklist`（验收清单）。它不做复杂度分流；调用它表示上游已经决定使用 composite long-task execution。它不要求先跑 `/normal-long-task`，但也不会把产品方案现场翻译成技术方案；如果只有产品/架构方案和验收清单，Skill 会用 Missing Fields Report 停止并报告缺少 `Technical Realization Plan`。两份输入兼容只限第一份明确包含产品/架构源和技术实现方案两个章节。`Technical Realization Plan` 必须已经满足 Superpowers-ready Markdown implementation plan 的必填字段；满足时它跳过方案生成，直接绑定 Superpowers 执行，不满足时直接中断并报告缺失字段，不生成 prompt。它输出 `workflow-protocol.md`、`execution-binding.md` 和可直接用于 Codex Goal mode 的薄 `goal-objective.txt`，不是把完整 workflow 塞进 4000 字 Goal：Goal 只保留持续完成契约，完整可执行流程放在 protocol snapshot 和 task-specific binding。预期运行效果是显式融合而不是让 agent 自行发挥：先 Tiny Context 流程契约，再三份输入权威，再编译 task-state，再进入 Superpowers implementation slice，每个 slice 更新 canonical state/evidence，derive 出阅读视图，经过 slice/epoch gate，最后 final-gate 计算完成。这个 workflow 是面向 Superpowers execution 的 Tiny Context 适配层，对齐官方 Superpowers skills，但不是上游维护的 schema；它不是 Tiny Context 流程契约本身、不是业务事实源、不是普通 prompt generator、也不是 Superpowers fork。它可以在 Superpowers 外层增加 Tiny Context 的权威、对图纸和验收门禁，但不能重新定义、重复或分叉 Superpowers 执行机制。如果未来改动让 Tiny Context 新增步骤和官方 Superpowers 职责冲突、重复或覆盖，应停止修改并提示边界冲突，不要静默合并两套流程。它不生成技术方案或验收清单、不执行计划、不证明完成，也不会把临时 state、derived views 或 verdict 注册成 `project_context/**`。三输入是上游权威，state / derived views / validator / auditor 不能改写它们。`task-state.json` 是唯一执行状态源，`events.ndjson` 追加记录状态变更，`derived/**` 只生成 local audit、plan-conformance matrix、final acceptance verdict、progress ledger、evidence index、context alignment、final summary 和 final card 等阅读视图。完整验收行按外部审计证据处理：proof chain 来自验收清单，fresh evidence 必须通过 `task-state.evidence[]` 满足每个 required layer，存在 material drift、缺 required layer 或未批准 sibling substitution 时不能标 `complete`。Goal mode 表述必须区分 `audit_task_complete`、`acceptance_target_status`、computed `product_goal_complete` 和 resolver-owned `completion_output_status`：实现/执行目标只在 `ty-context composite-long-task final-gate` 计算出 `product_goal_complete=true` 且 `completion_output_status=accept` 时完成；只读审计目标可在 `audit_task_complete` 时结束，但 verdict 不是 accepted/complete 时，回复写 `Audit workflow completed; acceptance target not complete.`，不能用未限定的 `Goal achieved` 或 `update_goal(status="complete")` 表示用户验收目标已完成。final-gate 未 accept 时，输出必须带 `blocker_triage` category 和 next action；旧 transient bookkeeping 或可重新生成的 generated-output mismatch 最多自愈重跑一次，真实证据、环境、契约和 harness drift blocker 仍保持 blocked/reject。
 
 Machine-verifiable proof layer（如 UI/browser、runtime、API/schema、data artifact、integration、test）不能靠截图、final card、validator pass、matrix/verdict 行或 prose evidence 完成；必须有 `assertion_result.status=passed`、命令和 assertion exit code 为 0、target AC/layer 匹配、positive/negative assertions 通过、reviewable artifacts，且没有 failed/stale `negative_evidence_scan`。UI Path AC 不能用 component screenshot、storybook、viewmodel、mock/unit、diagnostic page 或 API-only evidence 替代 owner page/browser 主路径；`未验证`、`不可用`、`暂不可用`、`页面无明显变化` 等 owner-surface forbidden state 会使 AC/layer 失效。
 
@@ -68,11 +68,11 @@ Strict V2 输入还要求 canonical Product / PI / AC 字段组。Product Source
 
 当 slice 声称关闭 machine-verifiable layer 时，`slice-delta.json` 的 evidence record 还应包含 `command_exit_code`、`assertion_result`，UI/browser 等需要时还应包含 `negative_evidence_scan`；derived matrix/verdict 只展示 assertion status 和 blocker，不能替代 assertion 执行。
 
-严格完成判定只看 current attempt，并且统一经过 Trusted Evidence Kernel。`compile` 从每个 machine-blocking AC 的 `assertion_command`、`assertion_artifacts`、proof layers、required tests、positive/negative assertions、invalid completion signals 和 final evidence expectation 生成 required command specs；`start-attempt --mode product_task|harness_task` 创建当前执行身份；`run-assertion` 记录 assertion command run；`record-evidence` 把 artifact 注册成 canonical EvidenceRecordV2；`final-gate` 只从当前记录重算。EvidenceRecordV2 必须包含 attempt/source/product/plan/checklist hash、git head、worktree fingerprint、command spec/run id、command line / exit code、artifact path/SHA/mtime、target AC ids、target PI ids、target proof layers、assertion status / exit code、positive assertions、negative assertions、invalid completion signals、negative evidence scan 和 required test ids。legacy v1 evidence、历史 `events.ndjson` complete 事件、旧 `derived/**` complete 视图、validator pass、final card、auditor prose、AC summary-only proof 和未注册临时 JSON 都不能完成 machine-blocking AC；更新的 failed command、Playwright/JUnit/test result 失败、owner DOM forbidden state、source/worktree drift、当前 task-state false/partial 或 derived/state mismatch 会让同 AC/layer 的旧 passed evidence 失效。
+严格完成判定只看 current attempt，并且统一经过 Trusted Evidence Kernel，再经过 completion-output resolver；final-gate、`validate-superpowers-state`、state-backed `validate-plan-acceptance` 和 derived completion views 使用同一个 kernel result。`compile` 从每个 machine-blocking AC 的 `assertion_command`、`assertion_artifacts`、proof layers、required tests、positive/negative assertions、invalid completion signals 和 final evidence expectation 生成 required command specs；`start-attempt --mode product_task|harness_task` 创建当前执行身份；`run-assertion` 记录 assertion command run；`record-evidence` 把 artifact 注册成 canonical EvidenceRecordV2；`final-gate` 只从当前记录重算。EvidenceRecordV2 必须包含 attempt/source/product/plan/checklist hash、git head、worktree fingerprint、command spec/run id、command line / exit code、artifact path/SHA/mtime、target AC ids、target PI ids、target proof layers、assertion status / exit code、positive assertions、negative assertions、invalid completion signals、negative evidence scan 和 required test ids。legacy v1 evidence、历史 `events.ndjson` complete 事件、旧 `derived/**` complete 视图、matrix/verdict/evidence-index/final-summary 行、validator pass、final card、auditor prose、AC summary-only proof、未注册临时 JSON 和手写 status 文件都不能完成 machine-blocking AC，也不能把 generated final answer 升级为 `accept`；更新的 failed command、Playwright/JUnit/test result 失败、owner DOM forbidden state、source/worktree drift、当前 task-state false/partial 或 derived/state mismatch 会让同 AC/layer 的旧 passed evidence 失效。
 
-final-gate 在 kernel 内部固定执行：load 三输入、重算 source hashes、load task-state、load current attempt、load command-run records、load registered EvidenceRecords、discard stale evidence、contradiction scan、重算每个 AC、重算每个 PI、重算 `acceptance_target_status`、重算 `product_goal_complete`、regenerate `derived/**`、append event。machine-blocking AC 缺 assertion command/artifacts/assertions/invalid signals，UI proof 缺 browser/e2e/smoke/trace，final evidence 只指向 generated view，test cases 只有人工查看，或无法产出 `assertion_result` 时，AC 是 `under_specified`，PI blocked，`product_goal_complete=false`。AC-010 / final-gate summary 不能反向证明其它 AC：如果 summary AC passed 但其它 required AC missing / failed / stale，则 summary AC invalidated，reason 是 `final_gate_cannot_bootstrap_from_summary_only`。
+final-gate 在 kernel、output resolver 和 triage 内部固定执行：load 三输入、重算 source hashes、load task-state、把旧 final/gates/meta transient bookkeeping snapshot 成 audit-only、resolve current attempt、load required command specs、load command-run records、load registered EvidenceRecords、discard stale evidence、scan unregistered assertion JSON、contradiction scan、AC-010 bootstrap prevention、under-specified AC checks、Harness Drift Lock、protected baseline guard、validate scope conflicts、重算每个 AC、重算每个 PI、重算 `acceptance_target_status`、重算 `product_goal_complete`、build current candidate state、resolve candidate `completion_output_status`、regenerate current `derived/**`、按 current candidate mode 扫 generated output、分类 `blocker_triage`、允许 transient/generated-output 自愈一次、append event。旧 `completion_output_status=blocked` 或旧 `generated_output_mismatch=true` 不能把 current kernel accept 拖回 blocked；当前 user-visible false completion claim 仍会 blocked。machine-blocking AC 缺 assertion command/artifacts/assertions/invalid signals，UI proof 缺 browser/e2e/smoke/trace，final evidence 只指向 generated view，test cases 只有人工查看，或无法产出 `assertion_result` 时，AC 是 `under_specified`，PI blocked，`product_goal_complete=false`。AC-010 / final-gate summary 不能反向证明其它 AC：如果 summary AC passed 但其它 required AC missing / failed / stale，则 summary AC invalidated，reason 是 `final_gate_cannot_bootstrap_from_summary_only`。
 
-Harness Drift Lock 把产品证明和验收工具链证明拆开。`product_task` 修改 Playwright spec、测试、assertion generator、AC010 helper、evidence writer、final-gate、validator、derive、task-state reducer、composite workflow Skill/protocol 或相关 Makefile/package test target 时，直接输出 `harness_drift_detected`、`acceptance_target_status=blocked`、`product_goal_complete=false`，并使用文案“本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。”`harness_task` 可以修改 harness，但必须有 stale evidence、historical complete、derived contradiction、AC010 summary-only、target mismatch、API-only-for-UI、negative evidence after pass、source hash mismatch、dirty worktree mismatch、missing assertion_result、test weakening 和 happy path fixtures；它只证明 harness 修对，不证明产品任务完成。`protected-harness-baseline.json` 保护 final-gate、validator、derive、evidence registration、assertion schema、fixture expected outcomes、workflow protocol、Skill markdown 和 test runner scripts；product task 改 baseline blocked，harness task 改 baseline 必须写 reason 并跑 fixtures。
+Harness Drift Lock 把产品证明和验收工具链证明拆开。`product_task` 修改 Playwright spec、测试、assertion generator、AC010 helper、evidence writer、final-gate、validator、derive、task-state reducer、composite workflow Skill/protocol 或相关 Makefile/package test target 时，直接输出 `harness_drift_detected`、`acceptance_target_status=blocked`、`product_goal_complete=false`，并使用文案“本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。”`harness_task` 可以修改 harness，但必须有 stale evidence、historical complete、derived contradiction、AC010 summary-only、target mismatch、API-only-for-UI、negative evidence after pass、source hash mismatch、dirty worktree mismatch、missing assertion_result、test weakening、scope leakage、missing UI/browser owner-surface proof、missing negative semantic proof 和 happy path fixtures；它只证明 harness 修对，不证明产品任务完成。`protected-harness-baseline.json` 保护 final-gate、validator、derive、evidence registration、assertion schema、fixture expected outcomes、workflow protocol、Skill markdown 和 test runner scripts；product task 改 baseline blocked，harness task 改 baseline 必须写 reason 并跑 fixtures。HFC-003 是持久 false-completion regression suite；HFC-004 是持久 final-gate blocker triage suite，覆盖旧 transient 自锁、candidate-driven scanner、blocker category/next action 和 one-pass self-recovery，并作为 harness 改动的 package release blocker。
 
 生成的 composite workflow prompt 使用 Slice Gate / Epoch Gate / Final Gate 分层节奏，而不是每个 slice 后都跑完整 final gate。Progress Accounting 在 state 和 generated `derived/progress-ledger.*` 中记录 AC acceptance completion、engineering implementation progress、runtime/proof progress、system capability progress、representative sample progress、real object coverage、full population operation progress、artifact budget 和 workflow overhead。每个 slice 需要声明 artifact budget、proof-layer milestone 状态和 cleanup expectation。workflow overhead backpressure 要求 executor 批处理共享的 provider/browser/runtime/security epoch proof environment，清理 stale artifact，并选择 Next 3-5 high-value clusters 来优先关闭最多阻塞 AC / proof-layer gap。
 

package/assets/protected-harness-baseline.json

@@ -3,13 +3,15 @@
   "purpose": "Protect composite-long-task final completion mechanics from product-task self-validation drift.",
   "baseline_reason": "Trusted Evidence Kernel and Harness Drift Lock define the canonical completion proof surface.",
   "protected_categories": {
-    "final_gate_implementation": ["packages/ty-context/src/lib/superpowers-task-gates.ts", "packages/ty-context/src/lib/superpowers-task-evidence-kernel.ts"],
-    "validator_implementation": ["packages/ty-context/src/lib/superpowers-task-validator.ts"],
+    "final_gate_implementation": ["packages/ty-context/src/commands/composite-long-task.ts", "packages/ty-context/src/lib/superpowers-task-gates.ts", "packages/ty-context/src/lib/superpowers-task-evidence-kernel.ts", "packages/ty-context/src/lib/superpowers-task-command-run-correlation.ts", "packages/ty-context/src/lib/superpowers-task-unregistered-evidence.ts", "packages/ty-context/src/lib/superpowers-task-ac010.ts"],
+    "completion_output_implementation": ["packages/ty-context/src/lib/superpowers-task-completion-output.ts", "packages/ty-context/src/lib/superpowers-task-final-card.ts"],
+    "validator_implementation": ["packages/ty-context/src/lib/superpowers-task-validator.ts", "packages/ty-context/src/lib/plan-acceptance-validator.ts"],
     "derive_implementation": ["packages/ty-context/src/lib/superpowers-task-derive.ts"],
     "evidence_registration_implementation": ["packages/ty-context/src/lib/superpowers-task-evidence.ts", "packages/ty-context/src/lib/superpowers-task-current-evidence.ts"],
+    "harness_protection_implementation": ["packages/ty-context/src/lib/superpowers-task-harness-drift.ts", "packages/ty-context/src/lib/superpowers-task-protected-baseline.ts"],
     "assertion_result_schema": ["packages/ty-context/src/lib/superpowers-task-state-schema.ts", "packages/ty-context/src/lib/superpowers-task-assertion-normalizers.ts"],
-    "fixture_expected_outcomes": ["tests/ty-context/superpowers-task-evidence-kernel.test.mjs", "tests/ty-context/composite-long-task-assertion-gate.test.mjs", "tests/ty-context/composite-long-task-expanded-assertion-gate.test.mjs"],
-    "workflow_protocol": [".codex/ty-context-managed/skills/composite-long-task-workflow/references/composite-long-task-workflow-protocol.md"],
+    "fixture_expected_outcomes": ["tests/ty-context/superpowers-task-evidence-kernel.test.mjs", "tests/ty-context/composite-long-task-assertion-gate.test.mjs", "tests/ty-context/composite-long-task-expanded-assertion-gate.test.mjs", "tests/ty-context/composite-long-task-trusted-evidence-kernel.test.mjs", "tests/ty-context/composite-long-task-completion-output-gate.test.mjs", "tests/ty-context/fixtures/composite-long-task/completion-output-gate/expected-outcomes.json", "tests/ty-context/composite-long-task-false-completion-regression.test.mjs", "tests/ty-context/fixtures/composite-long-task/false-completion-regression/manifest.json", "tests/ty-context/composite-long-task-final-gate-triage.test.mjs", "tests/ty-context/fixtures/composite-long-task/final-gate-triage/manifest.json"],
+    "workflow_protocol": [".codex/ty-context-managed/skills/composite-long-task-workflow/references/composite-long-task-workflow-protocol.md", ".codex/ty-context-managed/skills/composite-long-task-workflow/assets/goal-objective.template.md", ".codex/ty-context-managed/skills/composite-long-task-workflow/assets/execution-binding.template.md"],
     "skill_markdown": [".codex/ty-context-managed/skills/composite-long-task-workflow/SKILL.md"],
     "test_runner_scripts": ["packages/ty-context/package.json", "package.json", "Makefile"]
   },

package/assets/skills/composite-long-task-workflow/SKILL.md

@@ -53,6 +53,7 @@ Tiny Context Workflow Contract
 -> generated derived/** views
 -> slice / epoch gates
 -> final-gate computes product_goal_complete
+-> completion-output resolver emits accept / reject / blocked
 ```
 
 The runtime effect is one temporary Codex Goal workflow that combines:
@@ -174,6 +175,8 @@ Superpowers review and verification remain useful execution checks, but they can
 - `workflow-protocol.md` as detailed workflow.
 - `execution-binding.md` as task binding.
 - `product_goal_complete` only by final gate.
+- `completion_output_status` only by final-gate completion-output resolver.
+- `blocker_triage` category and next action when final gate fails.
 - `audit_task_complete` not equal to product acceptance.
 - assertion-backed machine-verifiable proof layers and negative evidence scan.
 - forbidden shortcuts.
@@ -181,17 +184,17 @@ Superpowers review and verification remain useful execution checks, but they can
 
 ## Completion State
 
-Agents must not hand-set `product_goal_complete`. Implementation / execution goals complete only when final gate computes `product_goal_complete=true`.
+Agents must not hand-set `product_goal_complete` or `completion_output_status`. Implementation / execution goals may use an unqualified accept/completion answer only when final gate computes `product_goal_complete=true` and the completion-output resolver emits `completion_output_status=accept`.
 
-Final completion is current-attempt-only and owned by the Trusted Evidence Kernel. Legacy v1 evidence, old attempt evidence, stale passed assertion JSON, historical `events.ndjson` completion events, stale `derived/**` views, matrix/verdict/evidence-index/final-summary rows, validator passes, final cards, auditor prose and AC summary-only proof are audit material only. They cannot complete machine-blocking ACs. Current failed command runs, Playwright/JUnit/test-result artifacts, owner DOM forbidden states, source/worktree drift, task-state false/partial status or derived/state mismatch invalidate older positive proof for the same AC/layer.
+Final completion is current-attempt-only and owned by the Trusted Evidence Kernel shared by final gate, `validate-superpowers-state`, state-backed `validate-plan-acceptance` and derived completion views. Legacy v1 evidence, old attempt evidence, stale passed assertion JSON, historical `events.ndjson` completion events, stale `derived/**` views, matrix/verdict/evidence-index/final-summary rows, validator passes, final cards, auditor prose, AC summary-only proof, unregistered temporary JSON and hand-written status files are audit material only. They cannot complete machine-blocking ACs. Current failed command runs, Playwright/JUnit/test-result artifacts, owner DOM forbidden states, source/worktree drift, task-state false/partial status or derived/state mismatch invalidate older positive proof for the same AC/layer.
 
-The final gate recomputes in this order: load the three inputs, recompute source hashes, load task state, load current attempt, load command-run records, load registered EvidenceRecords, discard stale evidence, run contradiction scan, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, regenerate `derived/**` and append an event.
+The final gate recomputes in this order: load the three inputs, recompute source hashes, load task state, snapshot previous final/gates/meta transient bookkeeping as audit-only, resolve the current attempt, load required command specs, load command-run records, load registered EvidenceRecords, discard stale evidence, scan unregistered assertion JSON, run contradiction scan, run AC-010 bootstrap prevention, run under-specified AC checks, run Harness Drift Lock, run protected baseline guard, validate scope conflicts, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, build the current candidate state, resolve candidate `completion_output_status`, regenerate current `derived/**`, scan generated output in the current candidate mode, classify blockers with `blocker_triage`, perform at most one self-recovery pass for transient bookkeeping or regenerable generated-output mismatch, then write current final state and append an event.
 
 Canonical proof layers are `code`, `api_schema`, `worker_runtime`, `data_artifact`, `integration`, `ui_browser`, `security_redaction`, `all_provider_all_runner`, `cleanup_stale_scan` and `test`; legacy source aliases map `runtime -> worker_runtime`, `browser -> ui_browser`, `api -> api_schema`, `data -> data_artifact` and `security -> security_redaction`. `code` cannot complete a machine-backed AC by itself. For UI/browser/API/worker/data/integration/security/test/all-provider/cleanup proof layers, do not mark ACs complete from screenshots, final cards, validator passes, matrix/verdict rows or prose evidence. Required machine-verifiable layers need passed `assertion_result`, zero command/assertion exit codes, target AC/PI/layer coverage, passed positive and negative assertions, no invalid completion signal, reviewable artifacts and passed `negative_evidence_scan` with matching target proof layers. Machine-blocking ACs with missing assertion command/artifacts/assertions/invalid signals, manual-only tests, generated-only final evidence, impossible assertion results or UI proof without browser/e2e/smoke/trace evidence are `under_specified`, block the related PI and force `product_goal_complete=false`.
 
 AC-010 / final-gate summary ACs can only summarize fresh EvidenceRecordV2 proof for the other ACs. If AC-010 passes while another required AC is missing, failed, stale or under-specified, invalidate AC-010 with `final_gate_cannot_bootstrap_from_summary_only`.
 
-Harness Drift Lock: `product_task` cannot complete if it changed Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, this workflow Skill/protocol or related Makefile/package test targets. Report `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and exactly: `本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。` A `harness_task` must have adversarial fixtures with expected final-gate outcomes and a happy-path fixture; it proves harness behavior only and must not declare product completion. `protected-harness-baseline.json` protects final-gate, validator, derive, evidence registration, assertion schema, fixture expected outcomes, workflow protocol, Skill markdown and test runner scripts; product task baseline changes are blocked, harness task baseline changes require a reason and fixture verification.
+Harness Drift Lock: `product_task` cannot complete if it changed Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, this workflow Skill/protocol or related Makefile/package test targets. Report `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and exactly: `本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。` A `harness_task` must have adversarial fixtures with expected final-gate outcomes and a happy-path fixture; it proves harness behavior only and must not declare product completion. HFC-003 is the durable false-completion regression suite, and HFC-004 is the durable final-gate blocker-triage suite covering old transient self-lock, candidate-driven scanner mode, blocker categories, next actions and one-pass self-recovery. `protected-harness-baseline.json` protects final-gate, validator, derive, evidence registration, assertion schema, fixture expected outcomes, workflow protocol, Skill markdown and test runner scripts; product task baseline changes are blocked, harness task baseline changes require a reason and fixture verification.
 
 If `audit_task_complete` is true but `acceptance_target_status` is not complete, report:
 
@@ -201,6 +204,8 @@ Audit workflow completed; acceptance target not complete.
 
 Do not use unqualified `Goal achieved` or `update_goal(status="complete")` as product acceptance in that case.
 
+If final-gate has not run, the required final answer is `blocked`. If final-gate runs but `product_goal_complete=false` or `acceptance_target_status` is not accepted, the required final answer is `reject` or `blocked` and must include blocker triage category plus next action. Validator pass, matrix/verdict row completion, final cards, local audit or stale generated text must never promote the final answer to `accept`.
+
 ## Forbidden Behaviors
 
 Do not execute the generated workflow inside this Skill.
@@ -227,7 +232,9 @@ Do not claim full alignment while Source-to-Context Coverage or Context-to-Imple
 
 Do not hand-write `product_goal_complete`.
 
-Do not call an implementation / execution Goal complete before final-gate computes `product_goal_complete=true`.
+Do not hand-write `completion_output_status`.
+
+Do not call an implementation / execution Goal complete before final-gate computes `product_goal_complete=true` and `completion_output_status=accept`.
 
 Do not generate, derive, or infer the Technical Realization Plan.
 

package/assets/skills/composite-long-task-workflow/assets/execution-binding.template.md

@@ -31,7 +31,26 @@ required_commands:
 
 completion_gate:
   product_goal_complete_source: final_gate
+  completion_output_status_source: final_gate_completion_output_resolver
+  allowed_final_answers:
+    - accept
+    - reject
+    - blocked
+  final_answer_accept_requires_product_goal_complete_true: true
+  final_answer_accept_requires_completion_output_status_accept: true
+  final_gate_not_run_outputs_blocked: true
+  final_gate_false_outputs_reject_or_blocked: true
+  validator_pass_never_authorizes_accept: true
+  matrix_verdict_final_card_never_authorizes_accept: true
+  audit_task_complete_never_authorizes_accept: true
+  generated_output_mismatch_blocks_accept: true
+  final_gate_uses_current_candidate_before_scanner: true
+  old_transient_bookkeeping_is_audit_only: true
+  blocker_triage_category_required_on_failure: true
+  blocker_triage_next_action_required_on_failure: true
+  self_recoverable_generated_output_mismatch_retries_once: true
   cannot_hand_set_product_goal_complete: true
+  cannot_hand_set_completion_output_status: true
   includes_ac_evidence_assertion_gate: true
   includes_negative_evidence_scan_gate: true
   current_attempt_only: true

package/assets/skills/composite-long-task-workflow/assets/goal-objective.template.md

@@ -11,7 +11,7 @@ Forbidden shortcuts:
 Do not mark UI/worker/API/data/integration/test ACs complete from screenshots, final cards, validator passes, derived rows, historical complete events, auditor prose, AC summary proof, unregistered JSON or stale attempts. Required machine proof needs current-attempt EvidenceRecordV2, assertion_result.status=passed, zero command/assertion exit codes, target AC/layer coverage, passed positive and negative assertions, reviewable artifacts and no failed/stale negative_evidence_scan with matching target proof layers. Tests alone do not prove plan conformance. Superpowers review does not override Tiny Context gates. Sample evidence does not prove full population unless AC allows. Local audit cannot mark final completion. Do not claim full implementation while Context Delta is required but Context is not updated, or while Source-to-Context Coverage / Context-to-Implementation Binding has unresolved required gaps.
 
 Completion:
-Do not hand-set product_goal_complete. Only final-gate computes it through the Trusted Evidence Kernel after current attempt command runs and EvidenceRecordV2 are registered, stale evidence is discarded, contradictions are scanned and every AC/PI is recomputed. Machine-blocking ACs with missing assertion command/artifacts/assertions/invalid signals, manual-only proof, generated-only final evidence, impossible assertion_result or UI proof without browser/e2e/smoke/trace are under_specified and block completion. AC-010 cannot bootstrap missing, failed or stale ACs. product_task changing tests/harness/final-gate/validator/assertion generators/workflow protocol is harness_drift_detected and must split to harness_task; harness_task proves harness behavior only. Run AC Evidence Assertion Gate, Negative Evidence Scan Gate, then final-gate compute product_goal_complete=true before treating implementation as complete. If audit_task_complete is true but acceptance_target_status is not complete, report "Audit workflow completed; acceptance target not complete." If historical complete conflicts with current recompute, report "Historical stale completion event detected and ignored." and "Current recomputed product_goal_complete=false." Do not say Goal achieved unless current recompute is true.
+Do not hand-set product_goal_complete or completion_output_status. Only final-gate computes product_goal_complete through the Trusted Evidence Kernel; resolver writes completion_output_status as accept, reject or blocked. Machine-blocking ACs missing assertion command/artifacts/assertions/invalid signals, manual-only proof, generated-only final evidence, impossible assertion_result or UI proof without browser/e2e/smoke/trace are under_specified and block completion. AC-010 cannot bootstrap missing, failed or stale ACs. product_task changing tests/harness/final-gate/validator/assertion generators/workflow protocol is harness_drift_detected and must split to harness_task; harness_task proves harness behavior only. Run AC Evidence Assertion Gate, Negative Evidence Scan Gate, validators, then final-gate. Require final-gate compute product_goal_complete=true and completion_output_status=accept before treating implementation as complete. If final-gate fails, use blocker_triage category/next_action; self-recoverable transient/generated-output mismatch may recover once, then rerun. Reject/blocked answers must not say Goal achieved, completed, accepted, done or call update_goal(status="complete"). If audit_task_complete is true but acceptance_target_status is not complete, report "Audit workflow completed; acceptance target not complete."
 
 Blocked:
-Maximize safe autonomous progress with repo tools, local app/browser sessions, CLI auth and authorized elevation. Stop only for MFA, missing permission, external approval or unavailable credentials, then return the minimal user action list plus next agent step.
+Use repo tools, local app/browser sessions, CLI auth and authorized elevation. Stop only for MFA, missing permission, external approval or unavailable credentials, then return minimal user action plus next agent step.

package/assets/skills/composite-long-task-workflow/references/composite-long-task-workflow-protocol.md

@@ -18,7 +18,7 @@ Tiny Context Workflow Contract
 -> each slice updates canonical state and evidence
 -> derive local audit / matrix / verdict / progress / evidence views
 -> run gates
--> final-gate computes product_goal_complete
+-> final-gate computes product_goal_complete and blocker triage
 ```
 
 ## Workflow Identity
@@ -65,23 +65,23 @@ Superpowers remains the execution layer: prefer `superpowers:subagent-driven-dev
 
 ## Final Gate Protocol
 
-Final completion always runs through the Trusted Evidence Kernel. Superpowers verification, validators, auditor checks and generated views are useful execution checks, but they are not proof authority. The AC Evidence Assertion Gate and Negative Evidence Scan Gate are enforced inside the kernel, not by trusting generated matrix or verdict text. The final gate itself runs in fixed order: load the three inputs, recompute source hashes, load task state, load current attempt, load command-run records, load registered EvidenceRecords, discard stale evidence, run contradiction scan, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, regenerate `derived/**` and append an event.
+Final completion always runs through the Trusted Evidence Kernel, then through the completion-output resolver and blocker triage. Final gate, `validate-superpowers-state`, state-backed `validate-plan-acceptance` and derived completion views use the same kernel and resolver result. Superpowers verification, validators, auditor checks and generated views are useful execution checks, but they are not proof authority or completion-output authority. The AC Evidence Assertion Gate and Negative Evidence Scan Gate are enforced inside the kernel, not by trusting generated matrix or verdict text. The final gate itself runs in fixed order: load the three inputs, recompute source hashes, load task state, snapshot previous final/gates/meta transient bookkeeping as audit-only, resolve the current attempt, load required command specs, load command-run records, load registered EvidenceRecords, discard stale evidence, scan unregistered assertion JSON, run contradiction scan, run AC-010 bootstrap prevention, run under-specified AC checks, run Harness Drift Lock, run protected baseline guard, validate scope conflicts, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, build the current candidate state, resolve candidate `completion_output_status`, regenerate current `derived/**`, scan generated output in the current candidate mode, classify blockers with `blocker_triage`, perform at most one self-recovery pass for transient bookkeeping or regenerable generated-output mismatch, write current final state and append an event.
 
-The final gate recomputes from current source hashes, current attempt, required command specs/runs, registered EvidenceRecordV2 records, contradiction scan, Harness Drift Lock and protected baseline state. It ignores stale passed artifacts, historical complete events, stale derived complete views, validator passes and AC summary-only proof as proof. Newer failed commands, Playwright `.last-run.json`, `test-results/**/error-context.md`, JUnit/JSON reporter failures, negative evidence artifacts, owner DOM forbidden states, task-state false/partial values and derived/state mismatch block completion for the affected AC/layer. If historical completion conflicts with current recompute, report `Historical stale completion event detected and ignored.` and `Current recomputed product_goal_complete=false.`
+The final gate recomputes from current source hashes, current attempt, required command specs/runs, registered EvidenceRecordV2 records, contradiction scan, Harness Drift Lock and protected baseline state. It ignores stale passed artifacts, historical complete events, stale derived complete views, old final/gates/meta transient findings, matrix/verdict/evidence-index/final-summary rows, validator passes, final cards, auditor prose, AC summary-only proof, unregistered temporary JSON and hand-written status files as proof. The completion-output resolver ignores those same surfaces as authority and emits only `accept`, `reject` or `blocked`. Generated-output scanning is current-candidate-driven: old `completion_output_status=blocked` or old `generated_output_mismatch=true` cannot drag a current kernel accept back to blocked, but current user-visible false completion claims still block. Newer failed commands, Playwright `.last-run.json`, `test-results/**/error-context.md`, JUnit/JSON reporter failures, negative evidence artifacts, owner DOM forbidden states, task-state false/partial values and derived/state mismatch block completion for the affected AC/layer. If historical completion conflicts with current recompute, report `Historical stale completion event detected and ignored.` and `Current recomputed product_goal_complete=false.`
 
-Harness Drift Lock: `product_task` is blocked when the current attempt changed Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, this workflow Skill/protocol or related Makefile/package test targets. The output must include `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and `本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。` A `harness_task` must include adversarial fixtures with expected final-gate outcomes for stale evidence, historical complete, derived contradiction, AC010 summary-only, target mismatch, API-only-for-UI, negative evidence after pass, source hash mismatch, dirty worktree mismatch, missing assertion_result, test weakening and one happy path; it never proves product completion. `protected-harness-baseline.json` blocks product-task changes to protected harness surfaces and requires a baseline reason plus fixtures for harness-task changes.
+Harness Drift Lock: `product_task` is blocked when the current attempt changed Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, this workflow Skill/protocol or related Makefile/package test targets. The output must include `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and `本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。` A `harness_task` must include adversarial fixtures with expected final-gate outcomes for stale evidence, historical complete, derived contradiction, AC010 summary-only, target mismatch, API-only-for-UI, negative evidence after pass, source hash mismatch, dirty worktree mismatch, missing assertion_result, test weakening, scope leakage, missing UI/browser owner-surface proof, missing negative semantic proof and one happy path; it never proves product completion. HFC-003 is the durable false-completion regression suite; HFC-004 is the durable final-gate blocker-triage suite for old transient self-lock, candidate-driven scanner mode, blocker categories, next actions and one-pass self-recovery. `protected-harness-baseline.json` blocks product-task changes to protected harness surfaces and requires a baseline reason plus fixtures for harness-task changes.
 
 ## Completion State Machine
 
-`audit_task_complete` means the workflow or audit pass finished. `acceptance_target_status` is the acceptance verdict. `product_goal_complete` is computed only by final-gate and is the only implementation/execution Goal completion condition. A read-only audit goal may finish at audit completion only while saying `Audit workflow completed; acceptance target not complete.` for non-accepted targets.
+`audit_task_complete` means the workflow or audit pass finished. `acceptance_target_status` is the acceptance verdict. `product_goal_complete` is computed only by final-gate. `completion_output_status` is computed only by the final-gate completion-output resolver and is the only official generated final-answer status. Implementation/execution Goal completion requires both `product_goal_complete=true` and `completion_output_status=accept`. A read-only audit goal may finish at audit completion only while saying `Audit workflow completed; acceptance target not complete.` for non-accepted targets.
 
 ## Forbidden Shortcuts
 
-Tests alone do not prove plan conformance. Superpowers review does not prove AC acceptance. Sample evidence does not prove full population unless the AC allows it. Browser screenshots, final cards, validator passes, matrix/verdict rows and prose evidence are auxiliary only for machine-verifiable ACs unless a passed assertion report is bound to the target AC/layer. Derived files, local audit, validator output and auditor reports cannot rewrite Product / Plan / Checklist. Local audit cannot mark product completion. Agents must not handwrite `product_goal_complete`.
+Tests alone do not prove plan conformance. Superpowers review does not prove AC acceptance. Sample evidence does not prove full population unless the AC allows it. Browser screenshots, final cards, validator passes, matrix/verdict rows, evidence-index/final-summary rows, unregistered JSON and prose evidence are auxiliary only for machine-verifiable ACs unless a passed assertion report is bound to the target AC/layer. Derived files, local audit, validator output and auditor reports cannot rewrite Product / Plan / Checklist. Local audit cannot mark product completion. Agents must not handwrite `product_goal_complete`.
 
 ## Hallucination Guard
 
-The protocol must prevent false fusion: do not interpret the composite workflow as the Tiny Context Workflow Contract itself; do not register `workflow-protocol.md` in `project_context/context.toml`; do not treat it as a business fact source; do not use local audit, tests, Superpowers review, sampled evidence, screenshots, final cards, matrix/verdict rows, validator passes or final-gate failure as product completion; do not claim full alignment with unresolved Source-to-Context Coverage or Context-to-Implementation Binding gaps; and do not call a Codex implementation Goal complete before final-gate passes.
+The protocol must prevent false fusion: do not interpret the composite workflow as the Tiny Context Workflow Contract itself; do not register `workflow-protocol.md` in `project_context/context.toml`; do not treat it as a business fact source; do not use local audit, tests, Superpowers review, sampled evidence, screenshots, final cards, matrix/verdict rows, validator passes, stale generated output or final-gate failure as product completion; do not let those surfaces promote `completion_output_status` to `accept`; do not claim full alignment with unresolved Source-to-Context Coverage or Context-to-Implementation Binding gaps; and do not call a Codex implementation Goal complete before final-gate passes and resolver status is `accept`.
 
 ## Blocker Protocol
 
@@ -510,17 +510,28 @@ Before final completion, the kernel order is fixed:
 1. load product-architecture-source.md, technical-realization-plan.md, acceptance-checklist.md
 2. recompute source hashes
 3. load task-state.json
-4. load current_attempt
-5. load command-run records
-6. load registered EvidenceRecordV2 records
-7. discard stale evidence
-8. contradiction scan
-9. recompute every AC
-10. recompute every PI
-11. recompute acceptance_target_status
-12. recompute product_goal_complete
-13. regenerate derived/**
-14. append event
+4. snapshot previous final/gates/meta transient bookkeeping as audit-only
+5. resolve current_attempt
+6. load required command specs
+7. load command-run records
+8. load registered EvidenceRecordV2 records
+9. discard stale evidence
+10. scan unregistered assertion JSON
+11. contradiction scan
+12. run AC-010 bootstrap prevention
+13. run under-specified AC checks
+14. run Harness Drift Lock
+15. run protected baseline guard
+16. recompute every AC
+17. recompute every PI
+18. recompute acceptance_target_status
+19. recompute product_goal_complete
+20. build current candidate state
+21. resolve candidate completion_output_status
+22. regenerate current derived/**
+23. scan generated output in current candidate mode
+24. classify blocker_triage and self-recover once when allowed
+25. append event
 ```
 
 Legacy/internal compatibility may exist as:
@@ -533,9 +544,10 @@ Only final-gate computes:
 
 ```text
 product_goal_complete=true
+completion_output_status=accept
 ```
 
-Implementation / execution Goals complete only after that computed state.
+Implementation / execution Goals complete only after both computed values are present.
 
 ## 14. Completion Semantics
 
@@ -550,6 +562,9 @@ acceptance_target_status
 
 product_goal_complete
 = whether implementation/execution is truly complete.
+
+completion_output_status
+= official generated final-answer status: accept, reject or blocked.
 ```
 
 Rules:
@@ -557,15 +572,20 @@ Rules:
 ```text
 1. Do not handwrite product_goal_complete.
 2. product_goal_complete is computed only by final-gate.
-3. audit_task_complete=true is not product completion.
-4. If acceptance_target_status is not complete, do not say Goal achieved.
-5. A read-only audit task may end, but must say:
+3. Do not handwrite completion_output_status.
+4. completion_output_status=accept requires product_goal_complete=true and accepted target status.
+5. audit_task_complete=true is not product completion.
+6. If completion_output_status is reject or blocked, do not say Goal achieved, completed, accepted or done.
+7. A read-only audit task may end, but must say:
    Audit workflow completed; acceptance target not complete.
-6. Implementation / execution Goal mode can call update_goal complete only when product_goal_complete=true.
+8. Failed final-gate output includes blocker_triage category and next action.
+9. Implementation / execution Goal mode can call update_goal complete only when product_goal_complete=true and completion_output_status=accept.
 ```
 
 This must stay visible in Skill and Goal objective because Codex Goal mode can otherwise confuse "audit workflow ended" with "product target accepted."
 
+When final-gate does not accept, output must include `blocker_triage.category`, `blocker_triage.next_action`, whether it was self-recoverable and whether recovery was attempted. Categories distinguish product evidence failure, missing current evidence, stale or contradictory evidence, generated-output mismatch, self-recoverable generated-output mismatch, transient state bookkeeping, environment blocked, contract blocked and harness drift blocked.
+
 ## 15. Blocker Strategy
 
 The executor maximizes autonomous progress:
@@ -633,13 +653,13 @@ Final
   -> Acceptance Evidence Gate
   -> External Reviewer / stale-overclaim scan
   -> final-gate
-  -> product_goal_complete=true before Codex Goal completion
+  -> product_goal_complete=true and completion_output_status=accept before Codex Goal completion
 ```
 
 One-sentence definition:
 
 ```text
-The expected runtime effect of the composite long-task workflow is to make a Codex agent fuse Tiny Context fact/process constraints, three upstream task authorities, Superpowers long-task execution and a task-state evidence state machine in one context; execution goes Context first, then Plan, then Superpowers slices, and completion is judged by state-backed gates for plan conformance, AC evidence and product_goal_complete so long tasks do not drift in implementation, acceptance or completion claims.
+The expected runtime effect of the composite long-task workflow is to make a Codex agent fuse Tiny Context fact/process constraints, three upstream task authorities, Superpowers long-task execution and a task-state evidence state machine in one context; execution goes Context first, then Plan, then Superpowers slices, and completion is judged by state-backed gates for plan conformance, AC evidence, product_goal_complete and completion_output_status so long tasks do not drift in implementation, acceptance or completion claims.
 ```
 
 ## 17. Forbidden Wrong Fusion / 不允许的错误融合
@@ -657,5 +677,6 @@ Do not treat sample evidence as full-population proof.
 Do not claim full implementation when Context Delta is required but Context is not updated.
 Do not claim full alignment while Source-to-Context Coverage / Context-to-Implementation Binding has unresolved gaps.
 Do not handwrite product_goal_complete.
-Do not call update_goal complete before final-gate passes.
+Do not handwrite completion_output_status.
+Do not call update_goal complete before final-gate passes and completion_output_status=accept.
 ```

package/dist/commands/composite-long-task.js

@@ -92,8 +92,26 @@ export async function runCompositeLongTaskCommand(args, options) {
     if (subcommand === "final-gate") {
         const result = await runFinalGate(workdir);
         console.log(`final gate product_goal_complete=${result.product_goal_complete}`);
-        if (!result.product_goal_complete) {
-            process.exitCode = 1;
+        console.log(`acceptance_target_status=${result.acceptance_target_status}`);
+        console.log(`completion_output_status=${result.completion_output_status}`);
+        console.log(`final_answer_allowed=${result.final_answer_allowed}`);
+        console.log(`required_user_visible_status=${result.required_user_visible_status}`);
+        console.log(`exit_code=${result.exit_code}`);
+        console.log(`audit_task_complete=${result.audit_task_complete}`);
+        if (result.blocker_triage) {
+            console.log(`blocker_triage_category=${result.blocker_triage.category}`);
+            console.log(`blocker_triage_self_recoverable=${result.blocker_triage.self_recoverable}`);
+            console.log(`blocker_triage_recovery_attempted=${result.blocker_triage.recovery_attempted}`);
+            console.log(`blocker_triage_next_action=${result.blocker_triage.next_action}`);
+        }
+        if (result.blocked_reasons.length > 0) {
+            console.log(`blocked_reasons=${result.blocked_reasons.join("; ")}`);
+        }
+        if (result.rejection_reasons.length > 0) {
+            console.log(`rejection_reasons=${result.rejection_reasons.join("; ")}`);
+        }
+        if (!result.final_answer_allowed) {
+            process.exitCode = result.exit_code;
             for (const error of result.errors) {
                 console.error(`error: ${error}`);
             }
@@ -130,7 +148,7 @@ function help(commandName, showRenderGoal) {
   derive <workdir>                       Generate derived/** views
   slice-gate <workdir> --slice <id>      Validate one slice has real progress
   epoch-gate <workdir> --epoch <id>      Refresh shared epoch evidence views
-  final-gate <workdir>                   Compute product_goal_complete
+  final-gate <workdir>                   Compute product_goal_complete and completion_output_status
   next-slices <workdir> --limit 5        Recommend next proof clusters${renderGoal}`);
 }
 function optionValue(args, name) {