project-tiny-context-harness 0.2.82 → 0.2.83

package/README.md

@@ -96,6 +96,12 @@ The ordinary long-task path uses `/normal-long-task`. It is the non-Superpowers
 
 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.
 
+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.
+
+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`.
+
+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.
+
 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`.
 
 `ty-context composite-long-task compile` uses a strict heading-based grammar for that packet. Product / Architecture Source is one document-level object with fixed fields. Technical Realization Plan items are definitions only when written as Markdown headings such as `## PI-001: ...`; Acceptance Checklist items are definitions only when written as headings such as `## AC-001: ...`. Fields inside those sections must use fixed `key: value`, indented-list or `key: |` syntax. Plain prose, tables, mapping previews and ordinary lists that mention `PI-001` or `AC-001` are references, not definitions; old list-style definitions such as `- PI-001: ...` followed by delivery fields now fail at compile time with file and line guidance.
@@ -106,7 +112,7 @@ For non-trivial Superpowers-backed slices, the workflow protocol requires a stru
 
 The generated Superpowers prompt uses Slice Gate / Epoch Gate / Final Gate cadence instead of running a full final gate after every slice. Progress Accounting tracks AC acceptance completion, engineering implementation progress, runtime/proof progress, system capability progress, representative sample progress, real object coverage, full population operation progress, artifact budget, proof-layer milestone status and workflow overhead in state and generated `derived/progress-ledger.*`. Workflow overhead backpressure asks executors to batch shared provider/browser/runtime/security epoch proof environments, prune stale artifacts and choose the Next 3-5 high-value clusters that close the most blocking AC/proof-layer gaps.
 
-The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. After `/composite-long-task-workflow` accepts the input packet, prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`. Final gate order is derive all views, `superpowers:verification-before-completion`, `ty-context validate-superpowers-state <dir>`, `ty-context validate-plan-acceptance <dir>`, read-only auditor when available, rederive/revalidate if auditor fixes changed state or evidence, final stale/overclaim scan, AC Evidence Assertion Gate, Negative Evidence Scan Gate, then `ty-context composite-long-task final-gate <dir>` computes completion. The auditor reconstructs AC proof chains with a fixed auditor checklist and finds gaps, but does not become proof. Superpowers review and verification remain useful execution checks, but they cannot override Tiny Context gates: passing Superpowers review does not by itself prove plan conformance or checklist acceptance.
+The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. After `/composite-long-task-workflow` accepts the input packet, prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`; behavior proof still enters the Trusted Evidence Kernel through current-attempt command runs and EvidenceRecordV2 entries. Superpowers verification, state validators, plan-acceptance validators, auditor checks and generated views remain useful execution checks, but they cannot override Tiny Context gates or become product proof: passing Superpowers review, validators or final-summary prose does not by itself prove plan conformance or checklist acceptance.
 
 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.
 
@@ -165,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.82.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.83.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -298,7 +304,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | Plan contract validation | `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-contract <plan.md\|dir>` | Checks Source-to-Context Coverage and Context-to-Implementation Binding for structural consistency, referenced path existence and weak-proof complete/bound contradictions. |
 | Superpowers state validation | `npx --yes --package project-tiny-context-harness@latest ty-context validate-superpowers-state <dir>` | Checks canonical Superpowers-backed `task-state.json`, source hashes, graph references, delivery scope fields/conflicts, evidence/proof-layer consistency, assertion-backed machine-verifiable evidence, negative evidence contradictions, stale evidence, sibling substitution, auditor blockers, derived drift and final completion rules. |
 | Plan acceptance validation | `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-acceptance <dir>` | Checks legacy matrix/verdict artifacts when no state exists; when `task-state.json` exists, validates state-backed derived artifacts. It rejects contradictory complete claims, dangling evidence references, weak-proof complete rows, missing proof layers, missing/failed assertion-backed evidence for machine-verifiable layers, negative evidence contradictions, material/critical drift, unapproved sibling substitution, blocking auditor findings, raw secrets/tokens/cookies, generated active-count drift, missing plan/AC cross-references and declared surface/architecture binding gaps. `errors` block; `warnings` / `hygiene` report cleanup. |
-| Composite long-task state helpers | `npx --yes --package project-tiny-context-harness@latest ty-context composite-long-task <subcommand>` | Explicit `/composite-long-task-workflow` state helper for `init`, `compile`, `apply-slice-delta`, `derive`, `slice-gate`, `epoch-gate`, `final-gate`, `next-slices` and `render-goal` under `tmp/ty-context/plan-acceptance/**`. |
+| Composite long-task state helpers | `npx --yes --package project-tiny-context-harness@latest ty-context composite-long-task <subcommand>` | Explicit `/composite-long-task-workflow` state helper for `init`, `compile`, `start-attempt`, `run-assertion`, `record-evidence`, `apply-slice-delta`, `derive`, `slice-gate`, `epoch-gate`, `final-gate`, `next-slices` and `render-goal` under `tmp/ty-context/plan-acceptance/**`. |
 | Diagnostics | `make ty-context-doctor` or `npx --yes --package project-tiny-context-harness@latest ty-context doctor` | Reports Harness root, package version, schema version and required Minimal Context paths. |
 | Package source checks | `ty-context package sync-source`, `ty-context package check-source` | Maintainer-only commands for keeping package canonical assets aligned with the source workspace. |
 

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.82.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.83.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -140,6 +140,12 @@ The ordinary long-task path uses `/normal-long-task`. It is the non-Superpowers
 
 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.
 
+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.
+
+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`.
+
+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.
+
 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`.
 
 `ty-context composite-long-task compile` uses a strict heading-based grammar for that packet. Product / Architecture Source is one document-level object with fixed fields. Technical Realization Plan items are definitions only when written as Markdown headings such as `## PI-001: ...`; Acceptance Checklist items are definitions only when written as headings such as `## AC-001: ...`. Fields inside those sections must use fixed `key: value`, indented-list or `key: |` syntax. Plain prose, tables, mapping previews and ordinary lists that mention `PI-001` or `AC-001` are references, not definitions; old list-style definitions such as `- PI-001: ...` followed by delivery fields now fail at compile time with file and line guidance.
@@ -150,7 +156,7 @@ For non-trivial Superpowers-backed slices, the workflow protocol requires a stru
 
 The generated Superpowers prompt uses Slice Gate / Epoch Gate / Final Gate cadence instead of running a full final gate after every slice. Progress Accounting tracks AC acceptance completion, engineering implementation progress, runtime/proof progress, system capability progress, representative sample progress, real object coverage, full population operation progress, artifact budget, proof-layer milestone status and workflow overhead in state and generated `derived/progress-ledger.*`. Workflow overhead backpressure asks executors to batch shared provider/browser/runtime/security epoch proof environments, prune stale artifacts and choose the Next 3-5 high-value clusters that close the most blocking AC/proof-layer gaps.
 
-The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. After `/composite-long-task-workflow` accepts the input packet, prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`. Final gate order is derive all views, `superpowers:verification-before-completion`, `ty-context validate-superpowers-state <dir>`, `ty-context validate-plan-acceptance <dir>`, read-only auditor when available, rederive/revalidate if auditor fixes changed state or evidence, final stale/overclaim scan, AC Evidence Assertion Gate, Negative Evidence Scan Gate, then `ty-context composite-long-task final-gate <dir>` computes completion. The auditor reconstructs AC proof chains with a fixed auditor checklist and finds gaps, but does not become proof. Superpowers review and verification remain useful execution checks, but they cannot override Tiny Context gates: passing Superpowers review does not by itself prove plan conformance or checklist acceptance.
+The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. After `/composite-long-task-workflow` accepts the input packet, prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`; behavior proof still enters the Trusted Evidence Kernel through current-attempt command runs and EvidenceRecordV2 entries. Superpowers verification, state validators, plan-acceptance validators, auditor checks and generated views remain useful execution checks, but they cannot override Tiny Context gates or become product proof: passing Superpowers review, validators or final-summary prose does not by itself prove plan conformance or checklist acceptance.
 
 The reason is drift control. The workflow contract plus Context layer is intentionally a soft constraint. It works well for short tasks, and Context can still capture the expected facts for long tasks, but long execution makes the Context-to-code step drift as the context window grows, work is handed off, subagents split scope or validation loops multiply. The extra Tiny Context gates exist because Superpowers alone can still drift under long-running execution 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. A product/architecture source, technical realization plan, acceptance checklist, explicit long-task Skill invocation, target-mode prompt, canonical task state, generated derived views and optional Superpowers execution layer make implementation conformance and completion evidence recoverable without restoring a phase-gated workflow.
 
@@ -409,7 +415,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-contract <plan.md\|dir>` | Checks Source-to-Context Coverage and Context-to-Implementation Binding for structural consistency, referenced path existence and weak-proof complete/bound contradictions. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context validate-superpowers-state <dir>` | Checks canonical Superpowers-backed `task-state.json`, source hashes, graph references, delivery scope fields/conflicts, evidence/proof-layer consistency, assertion-backed machine-verifiable evidence, negative evidence contradictions, stale evidence, sibling substitution, auditor blockers, derived drift and final completion rules. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context validate-plan-acceptance <dir>` | Checks legacy matrix/verdict artifacts when no state exists; when `task-state.json` exists, validates state-backed derived artifacts. It rejects contradictory complete claims, dangling evidence references, weak-proof complete rows, missing proof layers, material/critical drift, unapproved sibling substitution, blocking auditor findings, raw secrets/tokens/cookies, generated active-count drift, missing plan/AC cross-references and declared surface/architecture binding gaps. `errors` block; `warnings` / `hygiene` report cleanup. |
-| `npx --yes --package project-tiny-context-harness@latest ty-context composite-long-task <subcommand>` | Explicit `/composite-long-task-workflow` state helper for `init`, `compile`, `apply-slice-delta`, `derive`, `slice-gate`, `epoch-gate`, `final-gate`, `next-slices` and `render-goal` under `tmp/ty-context/plan-acceptance/**`. |
+| `npx --yes --package project-tiny-context-harness@latest ty-context composite-long-task <subcommand>` | Explicit `/composite-long-task-workflow` state helper for `init`, `compile`, `start-attempt`, `run-assertion`, `record-evidence`, `apply-slice-delta`, `derive`, `slice-gate`, `epoch-gate`, `final-gate`, `next-slices` and `render-goal` under `tmp/ty-context/plan-acceptance/**`. |
 | `make validate-context` | Makefile wrapper for `validate-context`. |
 | `make validate-code-modularity` | Hard gate for touched handwritten source modularity; CI can set `TY_CONTEXT_MODULARITY_BASE=<ref>` to audit PR/base changes. |
 | `make validate-harness` | Composite gate for `validate-context` and `validate-code-modularity`. |

package/assets/README.zh-CN.md

@@ -68,9 +68,15 @@ 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 失效。
+
+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`。
+
+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。
+
 生成的 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。
 
-重要使用提示：Minimal Context 有意把 Context 读取顺序、Context / 代码优先级和漂移检查保持为 agent 级软约束，而不是机器强制 edit-order gate。这个取舍适合短任务，但长任务、大上下文、多次交接或多轮验证时预期会漂移。单靠 Superpowers 在这类压力下仍可能漂移：它能增强执行纪律，但本身不负责保留上游 source authority、防止 scope shrinkage、证明完整符合 Technical Realization Plan，或按 Acceptance Checklist 逐 AC 强制证据成立。普通 checklist 准备需要 `/normal-long-task`；已有产品/架构原始意图源、具体技术实现方案和验收清单且需要 Superpowers-backed execution 时，可直接用 `/composite-long-task-workflow`。`Product Context Delta` 判断产品逻辑、页面职责、信息架构和验收语义是否需要写入 Context；`Technical Context Delta` 判断 API/schema、模块边界、runtime/state、验证/部署路径和稳定技术取舍是否需要写入 Context。`task-state.json` 是唯一执行状态源，`events.ndjson` 追加记录状态变化，`derived/**` 是生成阅读视图，`task-state.evidence[]` 是 canonical evidence ledger；local audit 只是 generated progress/recovery view，不能裁判完成；审计流程完成也不等于被验收目标完成。使用目标模式执行方案时，目标结束条件对齐 computed `product_goal_complete=true`，只读审计目标才可把 `audit_task_complete` 当元任务结束。最终顺序是 derive all views -> verification-before-completion -> `validate-superpowers-state` -> state-backed `validate-plan-acceptance` -> read-only auditor -> stale/overclaim scan -> `ty-context composite-long-task final-gate` 计算 completion；若审计后修改 state/evidence，需 rederive 并重跑两个 validator。`validate-plan-contract`、`validate-superpowers-state` 和 `validate-plan-acceptance` 只检查临时 artifact/state 自洽、引用存在、弱证据 complete 行、缺 required proof layer、material/critical drift、sibling substitution 和已声明的 surface/architecture binding 一致性，不证明产品质量。有 subagent 能力时，composite workflow prompt 会把 subagent 作为只读 auditor 加在主 agent 自证和 validator 之后；auditor 用固定 auditor checklist 找 gap，不是 proof source。Superpowers review 和 verification 仍然有价值，但不能覆盖 Tiny Context gates；通过 Superpowers review 不等于证明 plan conformance 或 checklist acceptance。
+重要使用提示：Minimal Context 有意把 Context 读取顺序、Context / 代码优先级和漂移检查保持为 agent 级软约束，而不是机器强制 edit-order gate。这个取舍适合短任务，但长任务、大上下文、多次交接或多轮验证时预期会漂移。单靠 Superpowers 在这类压力下仍可能漂移：它能增强执行纪律，但本身不负责保留上游 source authority、防止 scope shrinkage、证明完整符合 Technical Realization Plan，或按 Acceptance Checklist 逐 AC 强制证据成立。普通 checklist 准备需要 `/normal-long-task`；已有产品/架构原始意图源、具体技术实现方案和验收清单且需要 Superpowers-backed execution 时，可直接用 `/composite-long-task-workflow`。`Product Context Delta` 判断产品逻辑、页面职责、信息架构和验收语义是否需要写入 Context；`Technical Context Delta` 判断 API/schema、模块边界、runtime/state、验证/部署路径和稳定技术取舍是否需要写入 Context。`task-state.json` 是唯一执行状态源，`events.ndjson` 追加记录状态变化，`derived/**` 是生成阅读视图，`task-state.evidence[]` 是 canonical evidence ledger；local audit 只是 generated progress/recovery view，不能裁判完成；审计流程完成也不等于被验收目标完成。使用目标模式执行方案时，目标结束条件对齐 computed `product_goal_complete=true`；只读审计目标才可把 `audit_task_complete` 当元任务结束。validators、auditor、Superpowers verification 和 generated views 仍是有用的执行检查，但不能覆盖 Trusted Evidence Kernel，也不能成为 product proof。`validate-plan-contract`、`validate-superpowers-state` 和 `validate-plan-acceptance` 只检查临时 artifact/state 自洽、引用存在、弱证据 complete 行、缺 required proof layer、material/critical drift、sibling substitution 和已声明的 surface/architecture binding 一致性，不证明产品质量。有 subagent 能力时，composite workflow prompt 会把 subagent 作为只读 auditor 加在主 agent 自证和 validator 之后；auditor 用固定 auditor checklist 找 gap，不是 proof source。Superpowers review 和 verification 仍然有价值，但不能覆盖 Tiny Context gates；通过 Superpowers review 不等于证明 plan conformance 或 checklist acceptance。
 
 最终顺序中的 final-gate 还包含 AC Evidence Assertion Gate 和 Negative Evidence Scan Gate；`validate-superpowers-state` / state-backed `validate-plan-acceptance` 会拒绝缺少或失败的 assertion-backed machine proof、negative evidence contradiction、target AC/layer 不匹配和 stale assertion evidence。它们仍只验证 assertion report 与 proof layer 的绑定、freshness、reviewability、redaction、negative contradiction 和 state/derived consistency，不执行项目测试本身，也不证明产品质量。
 

package/assets/protected-harness-baseline.json

@@ -0,0 +1,18 @@
+{
+  "schema_version": "protected-harness-baseline-v1",
+  "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"],
+    "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"],
+    "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"],
+    "skill_markdown": [".codex/ty-context-managed/skills/composite-long-task-workflow/SKILL.md"],
+    "test_runner_scripts": ["packages/ty-context/package.json", "package.json", "Makefile"]
+  },
+  "product_task_rule": "Changing protected paths in product_task blocks product_goal_complete.",
+  "harness_task_rule": "Changing protected paths in harness_task requires a baseline reason, adversarial fixtures, a happy-path fixture and no product completion claim."
+}

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

@@ -142,6 +142,16 @@ ty-context validate-plan-acceptance <workdir>
 
 The validator name `validate-superpowers-state` remains valid because it checks the Superpowers-backed state schema.
 
+Strict completion also exposes current-attempt evidence commands:
+
+```text
+ty-context composite-long-task start-attempt <workdir> [--mode product_task|harness_task]
+ty-context composite-long-task run-assertion <workdir> --ac AC-001 --proof-layer ui_browser -- <command>
+ty-context composite-long-task record-evidence <workdir> --from <artifact> --command-run-id <id>
+```
+
+`compile [--mode product_task|harness_task]` derives required command specs from AC proof layers, assertion commands, assertion artifacts, required test ids, positive/negative assertions, invalid completion signals and final evidence expectation. `start-attempt` records the current source bundle, git/worktree identity, mode and changed files. `run-assertion` records command runs for the current attempt. `record-evidence` registers artifacts as EvidenceRecordV2 only when attempt/source/product/plan/checklist/worktree/command/artifact/assertion target fields are present.
+
 ## Official Superpowers Binding
 
 Bind to official Superpowers skills only after the full checklist and executable Technical Realization Plan exist:
@@ -173,7 +183,15 @@ Superpowers review and verification remain useful execution checks, but they can
 
 Agents must not hand-set `product_goal_complete`. Implementation / execution goals complete only when final gate computes `product_goal_complete=true`.
 
-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/layer coverage, passed positive and negative assertions, reviewable artifacts and no failed/stale `negative_evidence_scan` with matching target proof layers and checked invalid completion signals.
+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.
+
+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.
+
+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.
 
 If `audit_task_complete` is true but `acceptance_target_status` is not complete, report:
 

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

@@ -18,6 +18,9 @@ canonical_state:
 required_commands:
   init: ty-context composite-long-task init <workdir>
   compile: ty-context composite-long-task compile <workdir>
+  start_attempt: ty-context composite-long-task start-attempt <workdir>
+  run_assertion: ty-context composite-long-task run-assertion <workdir> --ac <AC-ID> --proof-layer <layer> -- <command>
+  record_evidence: ty-context composite-long-task record-evidence <workdir> --from <artifact> --command-run-id <id>
   derive: ty-context composite-long-task derive <workdir>
   apply_slice_delta: ty-context composite-long-task apply-slice-delta <workdir> <slice-delta.json>
   slice_gate: ty-context composite-long-task slice-gate <workdir> --slice <id>
@@ -31,3 +34,10 @@ completion_gate:
   cannot_hand_set_product_goal_complete: true
   includes_ac_evidence_assertion_gate: true
   includes_negative_evidence_scan_gate: true
+  current_attempt_only: true
+  trusted_evidence_kernel: true
+  harness_drift_lock: true
+  protected_harness_baseline: true
+  under_specified_machine_ac_blocks_completion: true
+  ac010_cannot_bootstrap_summary_only: true
+  derived_events_validators_never_proof: true

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

@@ -1,26 +1,17 @@
 /goal Execute the composite long-task workflow in {{workdir}}.
 
-First read and obey:
-- workflow-protocol.md
-- execution-binding.md
-- product-architecture-source.md
-- technical-realization-plan.md
-- acceptance-checklist.md
-- task-state.json and generated derived/** views
+Read and obey workflow-protocol.md, execution-binding.md, product-architecture-source.md, technical-realization-plan.md, acceptance-checklist.md, task-state.json and generated derived/** views.
 
 Persistent contract:
-Product / Architecture Source owns intent, scope, Scope Fit, owner boundaries and assertion policy. Technical Realization Plan owns PI implementation, plan conformance, trigger/state/observable contracts and required assertion commands. Acceptance Checklist owns AC completion semantics, proof layers, assertion_command/artifacts, positive/negative assertions, machine_blocking, invalid_completion_signals and assertion_result_required. task-state.json is the only execution state source; events.ndjson is append-only; derived/** is generated and must not be hand-edited as authority.
+Product / Architecture Source owns intent, scope, Scope Fit, owner boundaries and assertion policy. Technical Realization Plan owns PI implementation and plan conformance. Acceptance Checklist owns AC completion semantics and proof layers. task-state.json is the only execution state source; events.ndjson is append-only; derived/** is generated and must not be hand-edited as authority.
 
-Use workflow-protocol.md to combine Tiny Context gates with official Superpowers execution. It is not business Context and must not be registered in project_context/context.toml. Do not redefine, duplicate or fork Superpowers mechanics. Prefer superpowers:subagent-driven-development when subagents are available, otherwise use superpowers:executing-plans. Use TDD for behavior gaps and superpowers:verification-before-completion before completion claims.
-
-Work in slices. Each slice must update state through slice-delta.json, canonical evidence records, derive, and slice-gate. Run epoch-gate for shared provider/browser/runtime/security proof environments. Preserve Context Delta, plan conformance, acceptance proof layers, redaction, reviewability and sample/full-population boundaries.
+Use workflow-protocol.md to combine Tiny Context gates with official Superpowers execution. It is not business Context and must not be registered in project_context/context.toml. Prefer superpowers:subagent-driven-development when subagents are available; otherwise use superpowers:executing-plans. Use TDD for behavior gaps and superpowers:verification-before-completion before completion claims.
 
 Forbidden shortcuts:
-Do not mark UI/worker/API/data/integration/test ACs complete from screenshots, final cards, validator passes, matrix/verdict rows or prose. Canonical layers are code, api_schema, worker_runtime, data_artifact, integration, ui_browser, security_redaction, all_provider_all_runner, cleanup_stale_scan and test; code cannot complete a machine-backed AC alone. Required machine-verifiable layers need 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. Manual edits under derived/** are not authority. 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.
+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 complete after derive, verification-before-completion, validate-superpowers-state, validate-plan-acceptance, auditor/stale-overclaim checks when applicable, AC Evidence Assertion Gate, Negative Evidence Scan Gate, and final-gate compute product_goal_complete=true. If audit_task_complete is true but acceptance_target_status is not complete, report "Audit workflow completed; acceptance target not complete." and continue or stop with blockers; do not say Goal achieved.
+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.
 
 Blocked:
-Maximize safe autonomous progress using repo tools, local app/browser sessions, CLI auth and authorized elevation. Stop only for locally unsatisfiable blockers such as MFA, missing permission, external approval or unavailable credentials, and return the minimal user action list plus next agent step.
+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.

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

@@ -35,9 +35,11 @@ Implementation advances through coherent slices. Each slice selects related PI /
 
 ## Evidence Protocol
 
-Evidence is canonical state, not prose. Every proof record enters `task-state.evidence[]` with evidence id, slice id, type, command or artifact paths, command exit code when applicable, `proves`, `does_not_prove`, freshness, redaction, reviewability / reproduction data and, for machine-verifiable layers, an `assertion_result`. Evidence must be fresh, reviewable and free of secrets, raw credentials, tokens, cookies and long raw payloads.
+Evidence is canonical state, not prose. Every proof record enters `task-state.evidence[]` with evidence id, slice id, type, command or artifact paths, command exit code when applicable, `proves`, `does_not_prove`, freshness, redaction, reviewability / reproduction data and, for machine-verifiable layers, an `assertion_result`. Strict final completion uses EvidenceRecordV2 records bound to the current attempt, source bundle, product source hash, technical plan hash, acceptance 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 and required test ids. Evidence must be fresh, reviewable and free of secrets, raw credentials, tokens, cookies and long raw payloads.
 
-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 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. Machine-verifiable layers are not complete from descriptions, screenshots, final cards, validator passes, matrix rows or verdict rows. They require `assertion_result.schema_version=assertion-result-v1`, `assertion_result.status=passed`, assertion exit code `0`, command exit code `0` when present, target AC/layer coverage, passed positive and negative assertions and reviewable artifacts. UI/browser layers also require owner surface, route/path, user action, browser/playwright/UI assertion evidence and a passed `negative_evidence_scan` with matching target proof layers and checked invalid completion signals.
+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 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. Machine-verifiable layers are not complete from descriptions, screenshots, final cards, validator passes, matrix rows, verdict rows, evidence-index rows, final-summary text, historical `events.ndjson` complete events, auditor prose, summary-only AC proof or unregistered temporary JSON. They require current-attempt EvidenceRecordV2 plus `assertion_result.schema_version=assertion-result-v2`, `assertion_result.status=passed`, assertion exit code `0`, command exit code `0`, target AC/PI/layer coverage, passed positive and negative assertions, no invalid completion signal and reviewable artifacts. UI/browser layers also require owner surface, route/path, user action, browser/playwright/UI assertion evidence and a passed `negative_evidence_scan` with matching target proof layers and checked invalid completion signals.
+
+The Trusted Evidence Kernel marks a machine-blocking AC `under_specified` when it lacks an assertion command, assertion artifacts, positive assertions, negative assertions, invalid completion signals, required UI/browser proof, concrete assertion result production or any non-generated final evidence path. Under-specified ACs block related PIs and force `product_goal_complete=false`. AC-010 / final-gate summary proof only summarizes fresh current EvidenceRecordV2 proof for the other ACs; it cannot bootstrap missing, failed, stale or under-specified ACs and is invalidated with `final_gate_cannot_bootstrap_from_summary_only` when it tries.
 
 Strict V2 source fields are canonical. Product Source must carry Scope Fit, owner, primary capability and assertion policy fields. PI items must carry owner boundary, primary capability path, trigger/state/observable contracts, assertion support, required assertion commands and invalid implementation shortcuts. ACs must carry assertion command, artifacts, positive/negative assertions, machine-blocking flag, invalid completion signals and assertion-result requirement. Unknown, duplicate, table or missing canonical fields block compile; the workflow must not generate, infer, rewrite or repair the Technical Realization Plan or Acceptance Checklist.
 
@@ -63,7 +65,11 @@ Superpowers remains the execution layer: prefer `superpowers:subagent-driven-dev
 
 ## Final Gate Protocol
 
-Final completion always runs in fixed order: derive all views, run `superpowers:verification-before-completion`, validate canonical state, validate plan acceptance artifacts, run auditor and stale-overclaim checks when applicable, rederive/revalidate if fixes changed state or evidence, then let `ty-context composite-long-task final-gate <workdir>` compute `product_goal_complete`.
+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.
+
+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.`
+
+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.
 
 ## Completion State Machine
 
@@ -498,17 +504,23 @@ Completion is blocked until the source conflict is resolved. Validators inspect
 
 ## 13. Phase Twelve: Fixed Final Gate Order
 
-Before final completion, the order is fixed:
-
-```text
-1. derive all views
-2. superpowers:verification-before-completion
-3. ty-context validate-superpowers-state <workdir>
-4. ty-context validate-plan-acceptance <workdir>
-5. read-only auditor / stale-overclaim scan when applicable
-6. if auditor findings changed state/evidence, derive and validate again
-7. AC Evidence Assertion Gate and Negative Evidence Scan Gate
-8. ty-context composite-long-task final-gate <workdir>
+Before final completion, the kernel order is fixed:
+
+```text
+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
 ```
 
 Legacy/internal compatibility may exist as:

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

@@ -1,6 +1,8 @@
 import path from "node:path";
 import { applySliceDelta, initializeSuperpowersTask } from "../lib/superpowers-task-state.js";
 import { compileSuperpowersTask } from "../lib/superpowers-task-compile.js";
+import { startAndSaveSuperpowersAttempt } from "../lib/superpowers-task-attempt.js";
+import { recordSuperpowersEvidence, runSuperpowersAssertion } from "../lib/superpowers-task-evidence.js";
 import { deriveSuperpowersArtifacts } from "../lib/superpowers-task-derive.js";
 import { runEpochGate, runFinalGate, runSliceGate } from "../lib/superpowers-task-gates.js";
 import { nextSuperpowersSlices } from "../lib/superpowers-task-next-slices.js";
@@ -26,10 +28,37 @@ export async function runCompositeLongTaskCommand(args, options) {
         return;
     }
     if (subcommand === "compile") {
-        const state = await compileSuperpowersTask(workdir);
+        const state = await compileSuperpowersTask(workdir, { mode: attemptMode(args) });
         console.log(`compiled ${options.label} graph plan_items=${Object.keys(state.graph.plan_items).length} acs=${Object.keys(state.graph.acceptance_criteria).length}`);
         return;
     }
+    if (subcommand === "start-attempt") {
+        const attempt = await startAndSaveSuperpowersAttempt(workdir, attemptMode(args));
+        console.log(`started attempt ${attempt.task_attempt_id}`);
+        return;
+    }
+    if (subcommand === "run-assertion") {
+        const separator = args.indexOf("--");
+        const commandArgs = separator >= 0 ? args.slice(separator + 1) : [];
+        const run = await runSuperpowersAssertion(workdir, {
+            acId: optionValue(args, "--ac") ?? "",
+            proofLayer: optionValue(args, "--proof-layer") ?? "",
+            commandArgs
+        });
+        console.log(`recorded assertion command_run_id=${run.command_run_id} exit_code=${run.exit_code}`);
+        if (run.exit_code !== 0) {
+            process.exitCode = 1;
+        }
+        return;
+    }
+    if (subcommand === "record-evidence") {
+        const evidence = await recordSuperpowersEvidence(workdir, {
+            artifactPath: path.resolve(process.cwd(), optionValue(args, "--from") ?? ""),
+            commandRunId: optionValue(args, "--command-run-id") ?? ""
+        });
+        console.log(`registered evidence ${evidence.evidence_id}`);
+        return;
+    }
     if (subcommand === "apply-slice-delta") {
         const delta = args[2];
         if (!delta) {
@@ -89,7 +118,14 @@ function help(commandName, showRenderGoal) {
     const renderGoal = showRenderGoal ? "\n  render-goal <workdir>                  Render workflow-protocol.md, execution-binding.md and goal-objective.txt" : "";
     console.log(`${commandName} commands:
   init <workdir>                         Initialize task-state.json and events.ndjson
-  compile <workdir>                      Compile sources into task graph
+  compile <workdir> [--mode product_task|harness_task]
+                                         Compile sources into task graph
+  start-attempt <workdir> [--mode product_task|harness_task]
+                                         Start a fresh current attempt
+  run-assertion <workdir> --ac <id> --proof-layer <layer> -- <command>
+                                         Run and record an assertion command
+  record-evidence <workdir> --from <artifact> --command-run-id <id>
+                                         Register current-attempt EvidenceRecordV2
   apply-slice-delta <workdir> <delta>    Apply structured slice delta, evidence and derived views
   derive <workdir>                       Generate derived/** views
   slice-gate <workdir> --slice <id>      Validate one slice has real progress
@@ -101,3 +137,10 @@ function optionValue(args, name) {
     const index = args.indexOf(name);
     return index >= 0 ? args[index + 1] : undefined;
 }
+function attemptMode(args) {
+    const value = optionValue(args, "--mode");
+    if (value === "harness_task") {
+        return "harness_task";
+    }
+    return "product_task";
+}

package/dist/lib/superpowers-task-ac010.d.ts

@@ -0,0 +1,6 @@
+import type { SuperpowersTaskState } from "./superpowers-task-state-schema.js";
+export interface Ac010BootstrapResult {
+    invalidated_ac_ids: string[];
+    errors: string[];
+}
+export declare function evaluateAc010Bootstrap(state: SuperpowersTaskState, acStatuses: Record<string, string>): Ac010BootstrapResult;

package/dist/lib/superpowers-task-ac010.js

@@ -0,0 +1,26 @@
+const SUMMARY_ONLY = /\b(AC[-_ ]?010|final[-_ ]?gate|summary|final[-_ ]?acceptance[-_ ]?verdict|final[-_ ]?summary|matrix|validator)\b/i;
+export function evaluateAc010Bootstrap(state, acStatuses) {
+    const invalidated = [];
+    const errors = [];
+    for (const [acId, ac] of Object.entries(state.graph?.acceptance_criteria ?? {})) {
+        if (!isSummaryAc(acId, ac)) {
+            continue;
+        }
+        if (acStatuses[acId] !== "complete" && ac.status !== "complete") {
+            continue;
+        }
+        const incomplete = Object.keys(state.graph.acceptance_criteria).filter((otherId) => otherId !== acId && acIsRequired(otherId) && acStatuses[otherId] !== "complete" && acStatuses[otherId] !== "out_of_scope_NA");
+        if (incomplete.length === 0) {
+            continue;
+        }
+        invalidated.push(acId);
+        errors.push(`${acId} final_gate_cannot_bootstrap_from_summary_only: summary AC cannot prove incomplete ACs ${incomplete.join(", ")}`);
+    }
+    return { invalidated_ac_ids: invalidated, errors };
+}
+function isSummaryAc(acId, ac) {
+    return /^AC-?0?10$/i.test(acId) || SUMMARY_ONLY.test([ac.scope ?? "", ac.assertion_command ?? "", ...(ac.final_evidence_expected ?? [])].join("\n"));
+}
+function acIsRequired(acId) {
+    return !/^AC-?0?10$/i.test(acId);
+}

package/dist/lib/superpowers-task-assertion-normalizers.js

@@ -10,12 +10,16 @@ export function normalizeAssertionResult(value) {
         runner: String(value.runner ?? ""),
         exit_code: numberValue(value.exit_code),
         target_ac_ids: stringArray(value.target_ac_ids),
+        target_pi_ids: stringArray(value.target_pi_ids),
         target_proof_layers: stringArray(value.target_proof_layers).map(normalizeProofLayerId),
         owner_surface: value.owner_surface === undefined ? undefined : String(value.owner_surface),
         route: value.route === undefined ? undefined : String(value.route),
         action: value.action === undefined ? undefined : String(value.action),
         positive_assertions: checkArray(value.positive_assertions),
         negative_assertions: checkArray(value.negative_assertions),
+        invalid_completion_signals: checkArray(value.invalid_completion_signals),
+        negative_evidence_scan: normalizeNegativeEvidenceScan(value.negative_evidence_scan),
+        required_test_ids: stringArray(value.required_test_ids),
         artifacts: stringArray(value.artifacts)
     };
 }

package/dist/lib/superpowers-task-assertions.js

@@ -1,3 +1,4 @@
+import { evaluateCurrentAttemptEvidence } from "./superpowers-task-current-evidence.js";
 import { MACHINE_VERIFIABLE_LAYER_NAMES, normalizeProofLayerId, normalizeProofLayerName } from "./superpowers-task-fields.js";
 export { normalizeAssertionResult, normalizeNegativeEvidenceScan } from "./superpowers-task-assertion-normalizers.js";
 export const MACHINE_VERIFIABLE_PROOF_LAYERS = new Set(MACHINE_VERIFIABLE_LAYER_NAMES);
@@ -67,6 +68,13 @@ export function evaluateProofLayerAssertions(state, layerId) {
     if (!isMachineVerifiableLayer(layerId)) {
         return { assertion_status: "not_applicable", blocking_assertion_failures: [], negative_evidence_findings: [] };
     }
+    if (!state.current_attempt_id) {
+        return {
+            assertion_status: "missing",
+            blocking_assertion_failures: [`proof layer ${layerId} missing current attempt; current attempt is required for machine-backed completion`],
+            negative_evidence_findings: []
+        };
+    }
     const layer = state.graph.proof_layers[layerId];
     const evidenceById = new Map((state.evidence ?? []).map((item) => [item.evidence_id, item]));
     const evidenceRecords = (layer?.evidence_ids ?? []).map((id) => evidenceById.get(id)).filter((item) => Boolean(item));
@@ -80,6 +88,7 @@ export function evaluateProofLayerAssertions(state, layerId) {
     const blocking = [];
     const negative = [];
     for (const evidence of evidenceRecords) {
+        blocking.push(...evaluateCurrentAttemptEvidence(state, evidence, layerId));
         blocking.push(...evaluateAssertionEvidence(evidence, layerId));
         negative.push(...evaluateNegativeEvidence(evidence, layerId));
     }
@@ -115,8 +124,8 @@ export function evaluateAssertionEvidence(evidence, layerId) {
         failures.push(`${label} missing assertion result; ${layerName} proof not machine-backed`);
         return failures;
     }
-    if (assertion.schema_version !== "assertion-result-v1") {
-        failures.push(`${label} assertion_result.schema_version must be assertion-result-v1`);
+    if (assertion.schema_version !== "assertion-result-v1" && assertion.schema_version !== "assertion-result-v2") {
+        failures.push(`${label} assertion_result.schema_version must be assertion-result-v1 or assertion-result-v2`);
     }
     if (assertion.status !== "passed") {
         failures.push(`${label} assertion_result.status=${assertion.status}; expected passed`);
@@ -137,6 +146,11 @@ export function evaluateAssertionEvidence(evidence, layerId) {
     }
     failures.push(...checkAssertions(`${label} positive assertion`, assertion.positive_assertions));
     failures.push(...checkAssertions(`${label} negative assertion`, assertion.negative_assertions));
+    failures.push(...checkAssertions(`${label} invalid completion signal`, assertion.invalid_completion_signals ?? []));
+    const missingRequiredTests = (assertion.required_test_ids ?? []).filter((testId) => !testId);
+    if (missingRequiredTests.length > 0) {
+        failures.push(`${label} assertion_result.required_test_ids contains empty test ids`);
+    }
     if ((assertion.artifacts?.length ?? 0) === 0 && evidence.artifact_paths.length === 0) {
         failures.push(`${label} assertion-backed evidence must include artifacts`);
     }
@@ -182,9 +196,9 @@ function checkAssertions(prefix, checks) {
         .map((check) => `${prefix} ${check.id || "(unnamed)"} status=${check.status}; expected passed${check.forbidden_text ? ` forbidden_text=${check.forbidden_text}` : ""}`);
 }
 export function evaluateNegativeEvidence(evidence, layerId) {
-    const scan = evidence.negative_evidence_scan;
+    const scan = evidence.assertion_result?.negative_evidence_scan ?? evidence.negative_evidence_scan;
     if (!scan) {
-        return [];
+        return [`proof layer ${layerId} evidence ${evidence.evidence_id} missing negative_evidence_scan`];
     }
     const acId = proofLayerAcId(layerId);
     const label = `proof layer ${layerId} evidence ${evidence.evidence_id}`;

package/dist/lib/superpowers-task-attempt.d.ts

@@ -0,0 +1,4 @@
+import type { ExecutionAttempt, SuperpowersAttemptMode, SuperpowersTaskState } from "./superpowers-task-state-schema.js";
+export declare function startSuperpowersAttempt(workdir: string, state: SuperpowersTaskState, mode?: SuperpowersAttemptMode): Promise<ExecutionAttempt>;
+export declare function startAndSaveSuperpowersAttempt(workdir: string, mode?: SuperpowersAttemptMode): Promise<ExecutionAttempt>;
+export declare function computeSourceBundleHash(state: SuperpowersTaskState, specsHash?: string): string;