project-tiny-context-harness 0.2.72 → 0.2.73

package/README.md

@@ -94,7 +94,7 @@ For ordinary target-mode preparation, a two-document upstream input remains enou
 
 The ordinary long-task path uses `/normal-long-task`. It is the non-Superpowers acceptance pass: it can generate or reuse the full acceptance checklist and can produce a generic target-mode prompt.
 
-The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires `Product Context Delta` and `Technical Context Delta` checks before implementation, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion. Complete acceptance rows are treated as externally reviewable evidence claims: the checklist supplies the proof chain, fresh evidence must satisfy every required layer, and material drift, missing layers or unapproved sibling substitution prevent `complete`.
+The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires `Product Context Delta` and `Technical Context Delta` checks before implementation, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion. Complete acceptance rows are treated as externally reviewable evidence claims: the checklist supplies the proof chain, fresh evidence must satisfy every required layer, and material drift, missing layers or unapproved sibling substitution prevent `complete`. Goal-mode wording separates `audit_task_complete`, `acceptance_target_status` and `product_goal_complete`: implementation / execution goals complete only at `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 recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`, and completion claims should use `superpowers:verification-before-completion` against both the plan-conformance matrix and final acceptance verdict, followed by `ty-context validate-plan-acceptance <dir>`. When subagents are available, the target prompt asks for a read-only auditor pass after self-evidence and validator checks; the auditor finds gaps but does not become proof.
 
@@ -153,7 +153,7 @@ npm ci
 npm run smoke:quickstart
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.72.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.73.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -294,7 +294,7 @@ Technical architecture support is a Minimal Context capability: use restrained `
 
 For long-running plans, RFCs or implementation proposals, invoke `/normal-long-task` to turn a plan plus relevant Context into a falsifiable acceptance checklist and an optional generic paste-ready goal/target-mode prompt. It also supports a two-document upstream input from Web GPT or another external planner: `Development Plan` for execution direction and `Acceptance and Tests` for target-mode acceptance input. If the plan already contains an explicit concrete acceptance checklist, the Skill copies that checklist verbatim into a separate full-checklist file instead of generating a competing checklist. The two-document packet path is strict mode: when required fields cannot be fully parsed from both documents, the Skill preserves the inputs, reports the missing fields, and stops without generating a checklist or goal/target-mode prompt. It is one pre-execution acceptance pass, not a task planner or workflow engine: it stores temporary inputs under `tmp/ty-context/plan-acceptance/**`, asks for confirmation when durable assumptions are unclear, and leaves execution evidence to the future executor, tests, CI, review or human acceptance. The generated prompt may require a local audit under the same temporary directory so future sessions can recover acceptance progress; that audit is not Context, not a quality proof and not a replacement for the project's Tiny Context workflow contract. When the prompt references a full checklist, that checklist is the acceptance authority; compact prompt text is only navigation, priority and recovery guidance.
 
-When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*`, `final-acceptance-verdict.*`, proof-chain evidence and optional auditor review. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, and it does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections. `validate-plan-acceptance` is still a structural validator, not a product-quality proof; a subagent auditor is an extra gap-finding pass on top of executor self-evidence and validator checks, not a replacement for either.
+When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*`, `final-acceptance-verdict.*`, proof-chain evidence and optional auditor review. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, and it does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections. `validate-plan-acceptance` is still a structural validator, not a product-quality proof; a subagent auditor is an extra gap-finding pass on top of executor self-evidence and validator checks, not a replacement for either. The generated prompt also disambiguates `audit_task_complete`, `acceptance_target_status` and `product_goal_complete`; implementation / execution goals finish only at `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`.
 
 For Product Surface work, `context_surface_contract` turns broad product/page/UI principles into project-owned surface responsibilities. A Product Surface can be a Web page, mobile screen, desktop window, game UI/HUD/menu, CLI/TUI output, extension UI or embedded/device interface. Cross-surface contracts use the existing `contract` role; area-owned screen facts stay in `area` or `subdomain`; repeatable validation paths use `verification`. The Harness does not add a new surface-specific role or create business surface contracts during `init` or `upgrade`. Product Surface Context authoring is not a default product-quality validator; plan validators only check declared temporary surface bindings for structural consistency. Projects that want mandatory task blocks should add a separate project-local Skill, while `product-surface-contract.md` is only a compact managed template for optional Context authoring.
 

package/assets/README.md

@@ -94,7 +94,7 @@ That smoke packs the local workspace, installs it into a disposable repo, runs `
 ```sh
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.72.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.73.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -138,7 +138,7 @@ For ordinary target-mode preparation, a two-document upstream input remains enou
 
 The ordinary long-task path uses `/normal-long-task`. It is the non-Superpowers acceptance pass: it can generate or reuse the full acceptance checklist and can produce a generic target-mode prompt.
 
-The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. The Skill does not perform complexity routing: invocation means Superpowers long-task execution was already selected. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops with a Missing Fields Report for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires parent-level `Product Context Delta` and `Technical Context Delta` checks before implementation, slice-level new durable fact checks, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion. Complete acceptance rows are treated as externally reviewable evidence claims: the checklist supplies the proof chain, fresh evidence must satisfy every required layer, and material drift, missing layers or unapproved sibling substitution prevent `complete`. An Evidence Ledger / proof index is optional, but complete rows must trace to fresh evidence directly or through an optional `evidence_id`.
+The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. The Skill does not perform complexity routing: invocation means Superpowers long-task execution was already selected. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops with a Missing Fields Report for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires parent-level `Product Context Delta` and `Technical Context Delta` checks before implementation, slice-level new durable fact checks, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion. Complete acceptance rows are treated as externally reviewable evidence claims: the checklist supplies the proof chain, fresh evidence must satisfy every required layer, and material drift, missing layers or unapproved sibling substitution prevent `complete`. An Evidence Ledger / proof index is optional, but complete rows must trace to fresh evidence directly or through an optional `evidence_id`. Goal-mode wording separates `audit_task_complete`, `acceptance_target_status` and `product_goal_complete`: implementation / execution goals complete only at `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 recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`. Final gate order is self-evidence, matrix update, verdict update, `ty-context validate-plan-acceptance <dir>`, read-only auditor when available, validator rerun if auditor fixes changed artifacts, then completion only when no blocking conflict remains. `superpowers:verification-before-completion` checks the matrix and verdict before the completion claim. The auditor reconstructs AC proof chains and finds gaps, but does not become proof.
 
@@ -315,7 +315,7 @@ Technical architecture support is a Minimal Context capability: use restrained `
 
 For long-running plans, RFCs or implementation proposals, invoke `/normal-long-task` to turn a plan plus relevant Context into a falsifiable acceptance checklist and an optional generic paste-ready goal/target-mode prompt. It also supports a two-document upstream input from Web GPT or another external planner: `Development Plan` for execution direction and `Acceptance and Tests` for target-mode acceptance input. If the plan already contains an explicit concrete acceptance checklist, the Skill copies that checklist verbatim into a separate full-checklist file instead of generating a competing checklist. The two-document packet path is strict mode: when required fields cannot be fully parsed from both documents, the Skill preserves the inputs, reports the missing fields, and stops without generating a checklist or goal/target-mode prompt. This is one pre-execution acceptance pass, not a task planner or workflow engine: it stores temporary inputs under `tmp/ty-context/plan-acceptance/**`, asks for confirmation when durable assumptions are unclear, and leaves execution evidence to the future executor, tests, CI, review or human acceptance. The generated prompt may require a local audit under the same temporary directory so future sessions can recover acceptance progress; that audit is not Context, not a quality proof and not a replacement for the project's Tiny Context workflow contract. The full checklist is the acceptance authority, while any compact prompt summary exists for navigation, priority and recovery after context compaction.
 
-When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*`, `final-acceptance-verdict.*`, proof-chain evidence and optional auditor review. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, does not route complexity, and does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections. Product / Architecture Source, Technical Realization Plan and Acceptance Checklist remain the upstream authorities, while audit/matrix/verdict/validator/auditor artifacts cannot rewrite them.
+When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*`, `final-acceptance-verdict.*`, proof-chain evidence and optional auditor review. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, does not route complexity, and does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections. Product / Architecture Source, Technical Realization Plan and Acceptance Checklist remain the upstream authorities, while audit/matrix/verdict/validator/auditor artifacts cannot rewrite them. The generated prompt also disambiguates `audit_task_complete`, `acceptance_target_status` and `product_goal_complete`; implementation / execution goals finish only at `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`.
 
 Important usage note: Minimal Context intentionally keeps Context read order, Context/code priority and drift checks as agent-level soft constraints rather than machine-enforced gates. That tradeoff works well for short tasks, but long tasks with large context windows, multiple handoffs or many verification loops are expected to drift unless product intent, technical implementation target and acceptance target are externalized. Use `/normal-long-task` before long-running execution when ordinary checklist preparation is needed; use `/superpowers-long-task` when the three upstream inputs already exist and Superpowers execution is desired. Treat the plan-conformance matrix as process trace, the final verdict as final AC-by-AC acceptance evidence, and the local audit only as temporary progress/recovery state. `validate-plan-acceptance` is still an artifact-consistency validator, not a product-quality proof; a subagent auditor is an extra gap-finding pass on top of executor self-evidence and validator checks, not a replacement for either.
 

package/assets/README.zh-CN.md

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

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

@@ -264,9 +264,11 @@ If only locally unsatisfiable hard blockers remain, pause for the user or extern
 
 ## Autonomous Progress Protocol
 
-The generated target-mode prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself.
-
-The generated target-mode prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
+The generated target-mode prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself.
+
+Before treating account, credential or app access as blocked, open the relevant app, browser page, CLI tool or system setting and try existing app sessions, browser cookies, CLI auth, OS credential helpers or other user-authorized local state. If the existing session is absent, expired, permission-denied or requires login/MFA/approval, then pause with the minimal user action list; do not ask the user to send passwords, tokens, cookies or full sensitive fields.
+
+The generated target-mode prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
 
 Pause only for locally unsatisfiable hard blockers such as missing accounts, credentials, production access, paid services, legal/security approval, user-only browser sessions or sensitive fields the executor cannot access safely.
 
@@ -443,10 +445,11 @@ Hard requirements:
 - The prompt must identify the full checklist path immediately after the plan path and say it is the complete acceptance standard. Chinese prompts must include this exact sentence: `该文件是完整验收标准，验收以这个为准。完成前必须逐项检查，不满足则继续实现。` English prompts must say the full checklist is the complete acceptance standard, acceptance is judged against it, and every item must be checked before completion.
 - The prompt must identify a local audit path, normally `tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md`, and require the future executor to read it before resuming, keep it current during execution, and use it only as target-mode acceptance progress state, not Context or proof.
 - If the prompt uses a compact checklist summary, say the full checklist owns details and acceptance authority; the compact summary owns direction, priority and recovery navigation; overlap with the full checklist is allowed; conflicts are resolved in favor of the full checklist.
-- The prompt must require local audit status to start from `unknown / not_run`; only fresh required evidence can mark an AC complete. If any fresh browser / API / runtime / data / test contradiction appears, downgrade the affected AC and overall status and record invalidating evidence.
-- The prompt must state that UI-facing acceptance requires a real page path and matching user-visible state; component / viewmodel / mock / unit test evidence is auxiliary unless the full checklist explicitly says otherwise.
-- The prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself. If pausing for a locally unsatisfiable hard blocker, provide the minimum user action list: exact page/system/command/owner, field or value location, redaction guidance, values not to send and what the executor will do next.
-- The prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
+- The prompt must require local audit status to start from `unknown / not_run`; only fresh required evidence can mark an AC complete. If any fresh browser / API / runtime / data / test contradiction appears, downgrade the affected AC and overall status and record invalidating evidence.
+- The prompt must state that UI-facing acceptance requires a real page path and matching user-visible state; component / viewmodel / mock / unit test evidence is auxiliary unless the full checklist explicitly says otherwise.
+- The prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself. If pausing for a locally unsatisfiable hard blocker, provide the minimum user action list: exact page/system/command/owner, field or value location, redaction guidance, values not to send and what the executor will do next.
+- The prompt must say existing local sessions, browser state, CLI auth and OS credential helpers are self-service resources: open the relevant app/page/tool/settings first, use existing local auth if present, and pause only after access is actually absent, expired, permission-denied or requires login/MFA/approval.
+- The prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
 - The prompt must preserve hard-blocker semantics: if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking the goal complete.
 - The prompt must say that local audit is not Context, not product-quality proof, not a global task manager, and not a replacement for project tests, CI, review, human acceptance, Task Contract or workflow-contract `plan.md`.
 - Do not include explanatory preface inside the prompt.

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

@@ -239,6 +239,20 @@ Final gate order is fixed:
 6. if auditor findings change matrix, verdict or evidence, fix the gap and rerun `ty-context validate-plan-acceptance`.
 7. make a final completion claim only when self-evidence, validator consistency and auditor review have no blocking conflict.
 
+## Goal And Acceptance Wording
+
+The Superpowers target prompt must keep three completion concepts separate:
+
+- `audit_task_complete`: the read-only audit, final-gate workflow or artifact-production task finished.
+- `acceptance_target_status`: the final verdict outcome for the checked plan or product target.
+- `product_goal_complete`: the checked plan or product target is accepted as complete.
+
+`product_goal_complete` may be true only when the final verdict overall status is `accepted` or `complete`, all required ACs are `complete` or explicit sourced `out_of_scope_NA`, `ty-context validate-plan-acceptance` passes, and any auditor has no blocking finding.
+
+When the generated prompt is used as an implementation or execution Goal mode objective, the active Codex goal is complete only when `product_goal_complete=true`. A non-accepted `acceptance_target_status` means continue implementation or report blockers / missing evidence; do not close the implementation goal as complete.
+
+A read-only audit / reporting Goal mode objective is different: when the explicit goal is only to produce an audit and verdict, `audit_task_complete` may complete that meta-goal even when `product_goal_complete=false`. In that case, if `acceptance_target_status` is `partial`, `blocked`, `invalidated`, `not_run`, `partial_not_accepted_as_complete_platform` or any other non-accepted status, the final response must say `Audit workflow completed; acceptance target not complete.` It should include complete / partial / blocked / not_run / invalidated counts when available. Do not write an unqualified `Goal achieved` and do not describe `update_goal(status="complete")` as user-target or product-goal completion in that case.
+
 ## Evidence Layer Separation
 
 Keep these layers separate in the prompt when relevant:
@@ -285,6 +299,8 @@ For UI-facing acceptance, the executor must open the real page path and confirm
 
 The Superpowers target prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself.
 
+Before treating account, credential or app access as blocked, open the relevant app, browser page, CLI tool or system setting and try existing app sessions, browser cookies, CLI auth, OS credential helpers or other user-authorized local state. If the existing session is absent, expired, permission-denied or requires login/MFA/approval, then pause with the minimal user action list; do not ask the user to send passwords, tokens, cookies or full sensitive fields.
+
 The Superpowers target prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
 
 Pause only for locally unsatisfiable hard blockers such as missing accounts, credentials, production access, paid services, legal/security approval, user-only browser sessions or sensitive fields the executor cannot access safely. When pausing, give the minimum user action list: exact page, system, command or owner to open/contact; exact field or value location; how to redact or avoid sending sensitive values; what the executor will do immediately after receiving the input.
@@ -332,8 +348,11 @@ The local audit is process recovery only. It must not contain completion judgmen
 - The prompt must use parent-level Context Delta plus slice-level new durable fact checks.
 - The prompt must state that Evidence Ledger / proof index is optional, but complete rows and ACs require evidence traceability to fresh evidence directly or through optional `evidence_id`.
 - The prompt must require the fixed final gate order and rerun `validate-plan-acceptance` if auditor-driven fixes change artifacts.
+- The prompt must state the Goal mode completion rule: implementation / execution goals complete only at `product_goal_complete=true`; read-only audit / reporting goals may end at `audit_task_complete` but must still report the acceptance target status.
+- The prompt must require the final response to say `Audit workflow completed; acceptance target not complete.` whenever the verdict is not accepted/complete, and must forbid unqualified `Goal achieved` or treating `update_goal(status="complete")` as product acceptance in that case.
 - The prompt must preserve hard-blocker semantics: if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking complete.
 - The prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries and must include the minimum user action list for locally unsatisfiable hard blockers.
+- The prompt must say existing app sessions, browser cookies, CLI auth and OS credential helpers are self-service resources: open the relevant app/page/tool/settings first, use existing local auth if present, and pause only after access is actually absent, expired, permission-denied or requires login/MFA/approval.
 - The prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
 - The prompt must include the resource lifecycle line: `可多开agent，agent名额不够了就关掉不用的。` or `You may use multiple agents; if agent slots run low, close idle or unnecessary agents.`
 - The prompt must fit 3850 characters including line breaks.
@@ -357,6 +376,7 @@ Superpowers 输入包：
 - local audit：只记 progress/candidate status/evidence/blocker/invalidating evidence，不能裁判完成
 - Context/tests/core paths：执行前读取，把 plan/AC gap 绑定到测试、API/UI/runtime/browser 证据
 权威：source 管 scope，plan 管施工，checklist 管验收；audit/matrix/verdict/validator/auditor 不能改写它们。Proof index/evidence ledger 文件可选，但 complete 行必须能直接或经 evidence_id 追溯 fresh evidence。
+Goal mode：实现/执行目标只在 product_goal_complete=true 时完成；只读审计目标可在 audit_task_complete 时结束，但若 verdict 非 accepted/complete，必须写“Audit workflow completed; acceptance target not complete.”并列数量；不得写 Goal achieved 或把 update_goal complete 当用户目标完成。
 
 执行顺序：
 1. 读三份输入和 Context。先写 Task Contract：Product Context Delta none|required；Technical Context Delta none|required；任一 required -> Context Delta required。这不是 validator gate。
@@ -370,41 +390,41 @@ Superpowers 输入包：
 9. 再跑 Acceptance Evidence Gate：按验收清单生成 final verdict；每 AC 写 required proof chain/fresh evidence/missing layers/drift/substitution。current contradiction 高于历史通过记录。
 10. Final gate 固定为 self-evidence -> matrix -> verdict -> validator -> read-only auditor；auditor summary 不是 proof。若审计后改 artifact/evidence，重跑 validator；完成前用 superpowers:verification-before-completion 检查 matrix/verdict，并运行 ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>。
 
-权限/卡点：在当前平台/仓库/工具/用户已授权权限内最大自主推进；已授权 sudo/gsudo/admin elevation 先尝试，不算用户阻塞。只有本地无法解决的账号/凭证/真实环境/人工审批/敏感字段等才暂停，并给最小用户执行清单（具体页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
+权限/卡点：在当前平台/仓库/工具/用户已授权权限内最大自主推进；先打开相关 app/浏览器页面/CLI/系统设置，复用已有登录态/授权会话/凭据链；已授权 sudo/gsudo/admin elevation 先尝试。只有实际未登录/会话失效/权限不足/需要 MFA 或人工审批、缺账号/真实环境/敏感字段时才暂停，并给最小用户执行清单（页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
 禁止完成于：local audit、subagent summary、final card、只改代码/计划、只跑部分测试、旧/部分/抽样证据、缺 required layer、material drift、未批准 sibling substitution、runtime 未演练、artifact 未 accepted、API/UI 未 reflected、未批准 scope narrowing、任何 API/UI/data/runtime/test 矛盾。
 ```
 
 Recommended compact English prompt shape:
 
 ```text
-Product / Architecture Source: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md (scope guard)
+Product / Architecture Source: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md (scope)
 Technical Realization Plan: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md (blueprint)
-Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (acceptance authority)
-Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (process log, not proof)
-Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (update during work)
-Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (final AC gate)
+Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (authority)
+Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (log, not proof)
+Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (work trace)
+Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (AC gate)
 You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
 This is not a Superpowers official schema / 不是 Superpowers 官方 schema.
 Superpowers input packet:
-- Source guards scope; plan controls matrix; checklist controls verdict.
-- Local audit is only progress/candidate status/evidence/blockers/invalidating evidence.
+- Source guards scope; plan controls matrix; checklist controls verdict; audit records progress only.
 - Read Context/tests/core paths first; map gaps to test/API/UI/runtime/browser evidence.
-Authority: source owns scope, plan owns construction, checklist owns acceptance; audit/matrix/verdict/validator/auditor cannot rewrite them. Proof index file optional; complete rows need fresh evidence or evidence_id.
+Authority: source/plan/checklist own scope/construction/acceptance; audit/matrix/verdict/validator/auditor cannot rewrite them. Proof index optional; complete rows need fresh evidence/evidence_id.
+Goal mode: implementation/execution goal complete only when product_goal_complete=true; read-only audit goal may end at audit_task_complete, but if verdict not accepted say "Audit workflow completed; acceptance target not complete." Include counts; no bare "Goal achieved" or update_goal complete as user target.
 
 Execution order:
-1. Read inputs and Context. Write Task Contract: Product Context Delta none|required; Technical Context Delta none|required; any required -> Context Delta required. Not a validator gate.
-2. Use Parent Context Delta once; slices inherit it and record only new durable fact yes/no. If required, update owning project_context/** or DESIGN.md; never store audit/matrix/verdict/logs/screenshots/sample evidence as Context.
-3. Check Technical Realization Plan covers Product / Architecture Source; if only product plan exists, stop with missing Technical Realization Plan, do not generate it.
+1. Read inputs and Context. Task Contract: Product Context Delta none|required; Technical Context Delta none|required; any required -> Context Delta required. Not a validator gate.
+2. Use Parent Context Delta once; slices inherit it and record new durable fact yes/no. If required, update owning project_context/** or DESIGN.md; never store audit/matrix/verdict/logs/screenshots/sample evidence as Context.
+3. Check Technical Realization Plan covers Product / Architecture Source; if only product plan exists, stop with missing Technical Realization Plan.
 4. Initialize plan-conformance matrix; use superpowers:writing-plans if the plan is not bite-sized.
 5. Prefer superpowers:subagent-driven-development with subagents; otherwise use superpowers:executing-plans.
 6. Plan/AC behavior gap -> superpowers:test-driven-development: write a failing test, observe failure, then implement minimally.
 7. After each slice, update matrix and audit.
 8. Plan Conformance Gate: tests do not prove conformance; sampled path is not full implementation; each behavior item needs code/API/UI/runtime/test/evidence trace.
-9. Acceptance Evidence Gate: verdict from checklist; each AC records proof chain, fresh evidence, missing layers, drift, substitution. Current contradictions override old passes.
-10. Final gate: self-evidence -> matrix -> verdict -> validator -> read-only auditor. Auditor summary is not proof. If audit changes artifact/evidence, rerun validator. Before completion run superpowers:verification-before-completion on matrix/verdict and ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>.
+9. Acceptance Evidence Gate: checklist controls verdict; each AC records proof chain, fresh evidence, missing layers, drift, substitution. Current contradictions override old passes.
+10. Final gate: self-evidence -> matrix -> verdict -> validator -> read-only auditor. Auditor summary is not proof. Rerun validator after evidence changes; before completion run superpowers:verification-before-completion and ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>.
 
-Autonomy/blockers: within current platform/repo/tool/user-authorized permissions, do all safe self-service discovery/execution/verification. Authorized sudo/gsudo/admin elevation is not a user blocker; try it first. Pause only for locally unsatisfiable account/credential/real-env/human-approval/sensitive-field needs; give exact page/system, field location, redaction/do-not-send values and next agent step.
-Never complete on: local audit, subagent summary, final card, code/plan-only work, partial tests, stale/partial/sampled evidence, missing required layer, material drift, unapproved sibling substitution, unexercised runtime, artifact not accepted, API/UI not reflected, missing validate-plan-acceptance pass, unapproved scope narrowing or any API/UI/data/runtime/test contradiction.
+Autonomy/blockers: self-serve under current permissions. Open app/browser/CLI/settings and reuse sessions/auth/helpers. Try authorized sudo/gsudo/admin. Pause only after missing login, expired session, denied permission, MFA/approval, unavailable env/account or sensitive field; give page/system, field, redaction/do-not-send values, next step.
+Never complete on: local audit, summary/final card, code/plan-only, partial tests, stale/partial/sampled evidence, missing layer, material drift, unapproved sibling substitution, unexercised runtime, artifact not accepted, API/UI not reflected, missing validator pass, unapproved scope narrowing or API/UI/data/runtime/test contradiction.
 ```
 
 Before final response, check the prompt length. If it exceeds 3850 characters, tighten wording while preserving paths, input roles, official Superpowers skill names, Product Context Delta, Technical Context Delta, plan-conformance matrix, final verdict, state machine, UI gate, blockers and invalid evidence.
@@ -420,6 +440,7 @@ When successful, return:
 - The plan-conformance matrix path.
 - The final acceptance verdict path.
 - Whether required input was complete.
+- The generated prompt's Goal mode completion rule for implementation / execution goals, and required final status wording for non-accepted read-only audit results: `Audit workflow completed; acceptance target not complete.`
 - The paste-ready Superpowers target-mode prompt in a code block.
 
 When blocked, return:

package/package.json

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