project-tiny-context-harness 0.2.72 → 0.2.74
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md
CHANGED
|
@@ -94,9 +94,9 @@ For ordinary target-mode preparation, a two-document upstream input remains enou
|
|
|
94
94
|
|
|
95
95
|
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.
|
|
96
96
|
|
|
97
|
-
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,
|
|
97
|
+
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 technical realization plan must already satisfy the required Superpowers-ready Markdown implementation plan fields; if it does, the prompt binds it directly to Superpowers execution rather than regenerating the plan, and if it does not, the Skill stops before generating a prompt. The prompt is Tiny Context's adapter layer, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned 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.
|
|
98
98
|
|
|
99
|
-
The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute.
|
|
99
|
+
The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. After `/superpowers-long-task` 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`, 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.
|
|
100
100
|
|
|
101
101
|
The reason is drift control. The workflow contract plus Context layer is intentionally a soft constraint. It works well for short tasks, and Context can still capture the expected facts for long tasks, but long execution makes the Context-to-code step drift as the context window grows, work is handed off, subagents split scope or validation loops multiply. A product/architecture source, technical realization plan, acceptance checklist, explicit long-task Skill invocation, target-mode prompt, plan-conformance matrix, final acceptance verdict and optional Superpowers execution layer make implementation conformance and completion evidence recoverable without restoring a phase-gated workflow.
|
|
102
102
|
|
|
@@ -153,7 +153,7 @@ npm ci
|
|
|
153
153
|
npm run smoke:quickstart
|
|
154
154
|
npm run preview:pack
|
|
155
155
|
cd /path/to/your/test-repo
|
|
156
|
-
npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.
|
|
156
|
+
npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.74.tgz
|
|
157
157
|
npx --no-install ty-context init --adopt
|
|
158
158
|
make validate-context
|
|
159
159
|
```
|
|
@@ -268,7 +268,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
|
|
|
268
268
|
| Full project context export Skill | `<harnessRoot>/skills/context_full_project_export/SKILL.md` | Handles explicit full-project, project-overall, Source Pack or code-level export requests and uses `export-context --source-pack`, `--code-index`, `--task-context`, `--all`, `--full` or `--code` to create temporary artifacts under `tmp/ty-context/context-exports/**`. |
|
|
269
269
|
| Harness upgrade Skill | `<harnessRoot>/skills/context_harness_upgrade/SKILL.md` | Handles explicit Tiny Context / Project Tiny Context Harness upgrade requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project”; it runs the canonical `upgrade` path, handles only migration-scoped `manual_required` / `blocked` follow-up, then runs diagnostics. |
|
|
270
270
|
| Ordinary long-task Skill | `<harnessRoot>/skills/normal-long-task/SKILL.md` | Invoke as `/normal-long-task` to turn a referenced plan, RFC, implementation proposal or two-document upstream input into a falsifiable acceptance checklist and optional generic paste-ready goal/target-mode prompt under `tmp/ty-context/plan-acceptance/**`; if the plan already contains an explicit concrete checklist, the Skill reuses it verbatim in the separate full-checklist file; compact summaries are only navigation/priority, but the Skill does not execute the plan or prove completion. |
|
|
271
|
-
| Superpowers long-task Skill | `<harnessRoot>/skills/superpowers-long-task/SKILL.md` | Invoke as `/superpowers-long-task` when Product / Architecture Source, Technical Realization Plan and Acceptance Checklist exist and Superpowers execution is needed. It emits a Superpowers-specific prompt with Context Delta checks and the official workflow skill names, requires a plan-conformance matrix, final acceptance verdict and externally reviewable evidence discipline during execution, and stops when required input fields are missing. It
|
|
271
|
+
| Superpowers long-task Skill | `<harnessRoot>/skills/superpowers-long-task/SKILL.md` | Invoke as `/superpowers-long-task` when Product / Architecture Source, Technical Realization Plan and Acceptance Checklist exist and Superpowers execution is needed. It emits a Superpowers-specific prompt with Context Delta checks and the official workflow skill names, directly binds a Superpowers-ready external implementation plan when supplied, requires a plan-conformance matrix, final acceptance verdict and externally reviewable evidence discipline during execution, and stops when required input fields are missing. It does not generate the technical plan, checklist or execute the plan. |
|
|
272
272
|
| Project-local Skills | `<harnessRoot>/skills/<role>/SKILL.md` | Optional local product/design/development Skills created by the project, such as `product_plan`, `uiux_design` or `development_engineer`. They supersede package-managed default Skills when more specific, are not overwritten by `sync`, and should keep front matter trigger keywords aligned with the project `AGENTS.md` role-trigger rule. |
|
|
273
273
|
| Managed file sync | `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes package-managed guidance, default Skills, Makefile include, context templates, tools and workflow YAML. It does not run migrations or perform semantic Context generation; it may block only direct asset-refresh safety issues such as invalid managed blocks or deprecated managed Skill overrides. |
|
|
274
274
|
| Upgrade | `make ty-context-upgrade` or `npx --yes --package project-tiny-context-harness@latest ty-context upgrade` | Use for releases marked `upgrade-required` or `manual-required`. Builds an upgrade plan, stops before writes when `blocked` items exist, otherwise applies `safe_pending` migrations, runs `sync` and `doctor`, and exits non-zero when manual follow-up or diagnostics remain. |
|
|
@@ -294,7 +294,7 @@ Technical architecture support is a Minimal Context capability: use restrained `
|
|
|
294
294
|
|
|
295
295
|
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.
|
|
296
296
|
|
|
297
|
-
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:
|
|
297
|
+
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: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 for Superpowers workflows, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, and it does not derive a technical plan from a product plan; the Technical Realization Plan must already be a Superpowers-ready Markdown implementation plan or the Skill stops before generating a prompt. 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`.
|
|
298
298
|
|
|
299
299
|
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.
|
|
300
300
|
|
package/assets/README.md
CHANGED
|
@@ -94,7 +94,7 @@ That smoke packs the local workspace, installs it into a disposable repo, runs `
|
|
|
94
94
|
```sh
|
|
95
95
|
npm run preview:pack
|
|
96
96
|
cd /path/to/your/test-repo
|
|
97
|
-
npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.
|
|
97
|
+
npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.74.tgz
|
|
98
98
|
npx --no-install ty-context init --adopt
|
|
99
99
|
make validate-context
|
|
100
100
|
```
|
|
@@ -138,9 +138,9 @@ For ordinary target-mode preparation, a two-document upstream input remains enou
|
|
|
138
138
|
|
|
139
139
|
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.
|
|
140
140
|
|
|
141
|
-
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,
|
|
141
|
+
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 technical realization plan must already satisfy the required Superpowers-ready Markdown implementation plan fields; if it does, the prompt binds it directly to Superpowers execution rather than regenerating the plan, and if it does not, the Skill stops before generating a prompt. The prompt is Tiny Context's adapter layer, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned 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.
|
|
142
142
|
|
|
143
|
-
The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute.
|
|
143
|
+
The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. After `/superpowers-long-task` 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 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.
|
|
144
144
|
|
|
145
145
|
The reason is drift control. The workflow contract plus Context layer is intentionally a soft constraint. It works well for short tasks, and Context can still capture the expected facts for long tasks, but long execution makes the Context-to-code step drift as the context window grows, work is handed off, subagents split scope or validation loops multiply. A product/architecture source, technical realization plan, acceptance checklist, explicit long-task Skill invocation, target-mode prompt, plan-conformance matrix, final acceptance verdict and optional Superpowers execution layer make implementation conformance and completion evidence recoverable without restoring a phase-gated workflow.
|
|
146
146
|
|
|
@@ -305,7 +305,7 @@ No. It checks that recovery facts exist and avoids fake test-result claims. Prod
|
|
|
305
305
|
|
|
306
306
|
It should stay smaller than a full process. Ordinary bug fixes and local refactors do not update Context unless they produce durable product, architecture, API, state or validation facts.
|
|
307
307
|
|
|
308
|
-
The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and explicit long-task requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Long-task artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria or execution evidence for a referenced plan but do not execute it or become durable Context. The ordinary long-task Skill is invoked as `/normal-long-task`: if the plan already contains an explicit concrete checklist, it reuses that checklist verbatim in the separate full-checklist file. For a two-document upstream input, the external planner should provide a `Development Plan` and an `Acceptance and Tests` packet; `/normal-long-task` preserves both source roles and, only when strict-mode required fields are fully parseable from both documents, turns them into the full checklist plus optional generic target prompt. When a generated prompt references a full checklist, that checklist is the authoritative acceptance standard; the compact prompt summary is only navigation and priority guidance. The Superpowers long-task Skill is invoked as `/superpowers-long-task`: it consumes `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`, emits the Superpowers-specific target-mode prompt, requires `Product Context Delta`, `Technical Context Delta`, `plan-conformance-matrix.*`, `final-acceptance-verdict.*` and externally reviewable proof-chain evidence during future execution,
|
|
308
|
+
The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and explicit long-task requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Long-task artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria or execution evidence for a referenced plan but do not execute it or become durable Context. The ordinary long-task Skill is invoked as `/normal-long-task`: if the plan already contains an explicit concrete checklist, it reuses that checklist verbatim in the separate full-checklist file. For a two-document upstream input, the external planner should provide a `Development Plan` and an `Acceptance and Tests` packet; `/normal-long-task` preserves both source roles and, only when strict-mode required fields are fully parseable from both documents, turns them into the full checklist plus optional generic target prompt. When a generated prompt references a full checklist, that checklist is the authoritative acceptance standard; the compact prompt summary is only navigation and priority guidance. The Superpowers long-task Skill is invoked as `/superpowers-long-task`: it consumes `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`, emits the Superpowers-specific target-mode prompt, directly binds a Superpowers-ready external implementation plan when supplied, requires `Product Context Delta`, `Technical Context Delta`, `plan-conformance-matrix.*`, `final-acceptance-verdict.*` and externally reviewable proof-chain evidence during future execution, and stops if required fields are missing. The Harness upgrade Skill handles requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project” by following the release update mode, using `upgrade` for migration-bearing releases, and limiting manual cleanup to migration-scoped follow-up.
|
|
309
309
|
|
|
310
310
|
Multilingual trigger phrases are compatibility details. Public README, npm and launch copy stay English-first, and public/package-managed surfaces must remain English-complete; literal non-English examples are documented only where they explain generated Skill matching and must not be the sole activation path.
|
|
311
311
|
|
|
@@ -315,7 +315,7 @@ Technical architecture support is a Minimal Context capability: use restrained `
|
|
|
315
315
|
|
|
316
316
|
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.
|
|
317
317
|
|
|
318
|
-
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:
|
|
318
|
+
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: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 for Superpowers workflows, aligned to the official Superpowers skills while remaining a Tiny Context-owned adapter rather than an upstream-owned 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; the Technical Realization Plan must already be a Superpowers-ready Markdown implementation plan or the Skill stops before generating a prompt. 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`.
|
|
319
319
|
|
|
320
320
|
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.
|
|
321
321
|
|
package/assets/README.zh-CN.md
CHANGED
|
@@ -54,9 +54,9 @@ Tiny Context 有两个核心层。Minimal Context 是长期事实源层：说明
|
|
|
54
54
|
|
|
55
55
|
对于长程任务，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 会停止并列出缺失项，不生成完整验收清单或目标模式文本。
|
|
56
56
|
|
|
57
|
-
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
|
|
57
|
+
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`。两份输入兼容只限第一份明确包含产品/架构源和技术实现方案两个章节。`Technical Realization Plan` 必须已经满足 Superpowers-ready Markdown implementation plan 的必填字段；满足时它跳过方案生成，直接绑定 Superpowers 执行，不满足时直接中断并报告缺失字段，不生成 prompt。它显式输出 `Superpowers 输入包` 和执行绑定，让未来 executor 清楚哪些输入进入 parent-level Product Context Delta / Technical Context Delta、slice-level new durable fact check、subagent/inline execution、TDD、`superpowers:verification-before-completion`、local audit、`plan-conformance-matrix.*` 和 `final-acceptance-verdict.*`。这个 prompt 是面向 Superpowers workflow 的 Tiny Context 适配层，对齐官方 Superpowers skills，但不是上游维护的 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")` 表示用户验收目标已完成。
|
|
58
58
|
|
|
59
|
-
重要使用提示：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
|
|
59
|
+
重要使用提示：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。
|
|
60
60
|
|
|
61
61
|
## 当前最佳实践
|
|
62
62
|
|
|
@@ -77,7 +77,7 @@ Web GPT 或其他外部规划模型产出长任务源输入
|
|
|
77
77
|
-> 每个执行片段都回到流程契约 + project_context/**
|
|
78
78
|
```
|
|
79
79
|
|
|
80
|
-
这里的 Superpowers 指具体的 [obra/Superpowers](https://github.com/obra/superpowers)
|
|
80
|
+
这里的 Superpowers 指具体的 [obra/Superpowers](https://github.com/obra/superpowers) 插件/开源工作流，不是泛化的执行规划替代品。`/superpowers-long-task` 接受输入包后，有 subagent 支持时优先用 `superpowers:subagent-driven-development`，否则用 `superpowers:executing-plans`；涉及行为变更时用 `superpowers:test-driven-development`；完成声明前用 `superpowers:verification-before-completion` 同时检查 plan-conformance matrix 和 final acceptance verdict，然后运行 `ty-context validate-plan-acceptance <dir>`。
|
|
81
81
|
|
|
82
82
|
原因是漂移控制。流程契约 + Context 层是软约束，短任务里通常能让 agent 按预期执行；长程任务里，Context 仍然能记录符合预期的事实，但 Context 到代码 的实现步骤会随着上下文窗口变大、多次交接、subagent 拆分和多轮验证而漂移。产品/架构原始意图源、具体技术实现方案、验收清单、显式长程任务 Skill 调用、目标模式文本、plan-conformance matrix、final acceptance verdict 和可选 Superpowers 执行层，把“产品/技术 Context 有没有先对齐”“有没有按图纸实现”和“有没有按验收证据完成”都外化成可恢复、可审计的临时执行标准，同时不恢复阶段式 gate。
|
|
83
83
|
|
|
@@ -264,9 +264,11 @@ If only locally unsatisfiable hard blockers remain, pause for the user or extern
|
|
|
264
264
|
|
|
265
265
|
## Autonomous Progress Protocol
|
|
266
266
|
|
|
267
|
-
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.
|
|
268
|
-
|
|
269
|
-
|
|
267
|
+
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.
|
|
268
|
+
|
|
269
|
+
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.
|
|
270
|
+
|
|
271
|
+
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.
|
|
270
272
|
|
|
271
273
|
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.
|
|
272
274
|
|
|
@@ -443,10 +445,11 @@ Hard requirements:
|
|
|
443
445
|
- 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.
|
|
444
446
|
- 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.
|
|
445
447
|
- 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.
|
|
446
|
-
- 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.
|
|
447
|
-
- 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.
|
|
448
|
-
- 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.
|
|
449
|
-
- The prompt must
|
|
448
|
+
- 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.
|
|
449
|
+
- 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.
|
|
450
|
+
- 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.
|
|
451
|
+
- 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.
|
|
452
|
+
- 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.
|
|
450
453
|
- 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.
|
|
451
454
|
- 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`.
|
|
452
455
|
- Do not include explanatory preface inside the prompt.
|
|
@@ -9,7 +9,7 @@ description: Use when directly invoked for Superpowers long-running task target
|
|
|
9
9
|
|
|
10
10
|
This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `superpowers-long-task` Skill directly in a consumer project.
|
|
11
11
|
|
|
12
|
-
This is Tiny Context's adapter for feeding a recommended three-input long-task packet into the external Superpowers workflow. It is
|
|
12
|
+
This is Tiny Context's adapter for feeding a recommended three-input long-task packet into the external Superpowers workflow. It is aligned to the official Superpowers skills, while remaining a Tiny Context-owned adapter rather than an upstream-owned schema. It makes the target-mode prompt explicit enough that the official Superpowers skills can do their intended work without losing Tiny Context context-delta, plan-conformance and acceptance authority.
|
|
13
13
|
|
|
14
14
|
## Purpose
|
|
15
15
|
|
|
@@ -19,7 +19,7 @@ Consumes three existing upstream inputs and emits a paste-ready Superpowers targ
|
|
|
19
19
|
- Technical Realization Plan: the execution blueprint and plan-conformance source.
|
|
20
20
|
- Acceptance Checklist: the acceptance authority and final-verdict source.
|
|
21
21
|
|
|
22
|
-
Use this Skill only after all three inputs already exist or are pasted in full. Two-document compatibility is allowed only when the first document explicitly contains both Product / Architecture Source and Technical Realization Plan sections; otherwise stop for a missing Technical Realization Plan. Do not generate, derive, or infer the Technical Realization Plan. Do not generate, derive, rewrite, strengthen, or repair the full checklist in this Skill. If plan items or ACs are too vague to trace, stop and ask for the missing fields. If only generic conformance or verdict rules are missing, inject this Skill's default rules into the generated prompt.
|
|
22
|
+
Use this Skill only after all three inputs already exist or are pasted in full. The Technical Realization Plan must already be equivalent to a Superpowers-ready Markdown implementation plan; when it satisfies the required input fields, this Skill skips plan generation and produces the execution binding directly. Two-document compatibility is allowed only when the first document explicitly contains both Product / Architecture Source and Technical Realization Plan sections; otherwise stop for a missing Technical Realization Plan. Do not generate, derive, or infer the Technical Realization Plan. Do not generate, derive, rewrite, strengthen, or repair the full checklist in this Skill. If plan items or ACs are too vague to trace, stop and ask for the missing fields. If only generic conformance or verdict rules are missing, inject this Skill's default rules into the generated prompt.
|
|
23
23
|
|
|
24
24
|
This Skill does not perform task-complexity routing. Direct invocation means the user or upstream process has already selected Superpowers long-task execution. Ordinary checklist preparation, non-Superpowers target prompts or incomplete upstream packets should be handled before this Skill, normally with `/normal-long-task` or a revised upstream packet.
|
|
25
25
|
|
|
@@ -54,7 +54,7 @@ The input must fully expose these fields:
|
|
|
54
54
|
- durable product intent when applicable: product capability, user flow, business state/rule, page/surface responsibility, information architecture, product ownership, status meaning, operation boundary or acceptance semantics.
|
|
55
55
|
- durable architecture intent when applicable: module boundary, dependency direction, API/schema/data/event contract, worker/runtime/state-machine semantics, verification/deployment path or stable technical tradeoff.
|
|
56
56
|
- Technical Realization Plan path or pasted text.
|
|
57
|
-
- traceable plan items or sections that affect behavior.
|
|
57
|
+
- traceable plan items or sections that affect behavior and can be executed like a Superpowers Markdown implementation plan.
|
|
58
58
|
- expected implementation surfaces when applicable: code, API/schema, UI/page, worker/runtime, artifact, data, tests.
|
|
59
59
|
- required code/API/schema/UI/worker/runtime/data/test/evidence mapping when applicable.
|
|
60
60
|
- full-scope versus sample/optional boundaries.
|
|
@@ -79,7 +79,7 @@ When blocked by missing input, return a structured Missing Fields Report with:
|
|
|
79
79
|
- `required_next_input`.
|
|
80
80
|
- `suggested_upstream_action`.
|
|
81
81
|
|
|
82
|
-
The report must state that this Skill cannot infer the execution blueprint from Product / Architecture Source and cannot repair the checklist. It may recommend supplying
|
|
82
|
+
The report must state that this Skill cannot infer the execution blueprint from Product / Architecture Source and cannot repair the checklist. It may recommend supplying a complete Product / Architecture Source, Technical Realization Plan or Acceptance Checklist packet before Superpowers execution when the upstream packet is not ready.
|
|
83
83
|
|
|
84
84
|
## Source Roles
|
|
85
85
|
|
|
@@ -239,6 +239,20 @@ Final gate order is fixed:
|
|
|
239
239
|
6. if auditor findings change matrix, verdict or evidence, fix the gap and rerun `ty-context validate-plan-acceptance`.
|
|
240
240
|
7. make a final completion claim only when self-evidence, validator consistency and auditor review have no blocking conflict.
|
|
241
241
|
|
|
242
|
+
## Goal And Acceptance Wording
|
|
243
|
+
|
|
244
|
+
The Superpowers target prompt must keep three completion concepts separate:
|
|
245
|
+
|
|
246
|
+
- `audit_task_complete`: the read-only audit, final-gate workflow or artifact-production task finished.
|
|
247
|
+
- `acceptance_target_status`: the final verdict outcome for the checked plan or product target.
|
|
248
|
+
- `product_goal_complete`: the checked plan or product target is accepted as complete.
|
|
249
|
+
|
|
250
|
+
`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.
|
|
251
|
+
|
|
252
|
+
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.
|
|
253
|
+
|
|
254
|
+
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.
|
|
255
|
+
|
|
242
256
|
## Evidence Layer Separation
|
|
243
257
|
|
|
244
258
|
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
|
|
|
285
299
|
|
|
286
300
|
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.
|
|
287
301
|
|
|
302
|
+
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.
|
|
303
|
+
|
|
288
304
|
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.
|
|
289
305
|
|
|
290
306
|
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.
|
|
@@ -293,7 +309,6 @@ Pause only for locally unsatisfiable hard blockers such as missing accounts, cre
|
|
|
293
309
|
|
|
294
310
|
Bind the target prompt to the official Skill names and their documented roles:
|
|
295
311
|
|
|
296
|
-
- If the Technical Realization Plan is not bite-sized enough, use `superpowers:writing-plans`.
|
|
297
312
|
- Prefer `superpowers:subagent-driven-development` when subagents are available.
|
|
298
313
|
- Use `superpowers:executing-plans` when executing a written plan without the same-session subagent workflow.
|
|
299
314
|
- Plan or AC behavior gap -> TDD: each behavior gap uses `superpowers:test-driven-development` to write a failing test, observe failure, then implement minimally.
|
|
@@ -325,6 +340,7 @@ The local audit is process recovery only. It must not contain completion judgmen
|
|
|
325
340
|
|
|
326
341
|
- The prompt must visibly output `Superpowers 输入包` for Chinese prompts or `Superpowers input packet` for English prompts.
|
|
327
342
|
- The prompt must visibly output `Superpowers 执行绑定` for Chinese prompts or `Superpowers execution binding` for English prompts.
|
|
343
|
+
- The prompt must state that this is a Tiny Context adapter for Superpowers workflows, aligned to the official Superpowers skills, not an upstream-owned schema.
|
|
328
344
|
- The prompt must identify Product / Architecture Source, Technical Realization Plan, Acceptance Checklist, local audit, plan-conformance matrix and final verdict paths at the top.
|
|
329
345
|
- The prompt must state that the Technical Realization Plan controls plan conformance, the Product / Architecture Source prevents scope shrinkage and the full checklist controls acceptance.
|
|
330
346
|
- The prompt must state the Authority Model and that audit/matrix/verdict/validator/auditor artifacts cannot rewrite source, plan or checklist authority.
|
|
@@ -332,8 +348,11 @@ The local audit is process recovery only. It must not contain completion judgmen
|
|
|
332
348
|
- The prompt must use parent-level Context Delta plus slice-level new durable fact checks.
|
|
333
349
|
- 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`.
|
|
334
350
|
- The prompt must require the fixed final gate order and rerun `validate-plan-acceptance` if auditor-driven fixes change artifacts.
|
|
351
|
+
- 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.
|
|
352
|
+
- 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.
|
|
335
353
|
- 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.
|
|
336
354
|
- 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.
|
|
355
|
+
- 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.
|
|
337
356
|
- 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.
|
|
338
357
|
- 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.`
|
|
339
358
|
- The prompt must fit 3850 characters including line breaks.
|
|
@@ -349,7 +368,7 @@ Recommended compact Chinese prompt shape:
|
|
|
349
368
|
对图纸矩阵: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json（先建，边做边更新）
|
|
350
369
|
最终验收: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json（最后逐 AC 生成）
|
|
351
370
|
可多开agent，agent名额不够了就关掉不用的。
|
|
352
|
-
|
|
371
|
+
这是面向 Superpowers workflow 的 Tiny Context 适配输入包，对齐官方 Superpowers skills；不是上游维护的 schema。
|
|
353
372
|
Superpowers 输入包：
|
|
354
373
|
- Product/Architecture Source：原始产品/架构意图，防止 scope shrinkage，不是施工图
|
|
355
374
|
- Technical Realization Plan：施工图；每个行为 plan item 都要进 matrix
|
|
@@ -357,12 +376,13 @@ Superpowers 输入包：
|
|
|
357
376
|
- local audit：只记 progress/candidate status/evidence/blocker/invalidating evidence，不能裁判完成
|
|
358
377
|
- Context/tests/core paths：执行前读取，把 plan/AC gap 绑定到测试、API/UI/runtime/browser 证据
|
|
359
378
|
权威：source 管 scope，plan 管施工，checklist 管验收；audit/matrix/verdict/validator/auditor 不能改写它们。Proof index/evidence ledger 文件可选，但 complete 行必须能直接或经 evidence_id 追溯 fresh evidence。
|
|
379
|
+
Goal mode：实现/执行目标只在 product_goal_complete=true 时完成；只读审计目标可在 audit_task_complete 时结束，但若 verdict 非 accepted/complete，必须写“Audit workflow completed; acceptance target not complete.”并列数量；不得写 Goal achieved 或把 update_goal complete 当用户目标完成。
|
|
360
380
|
|
|
361
381
|
执行顺序：
|
|
362
382
|
1. 读三份输入和 Context。先写 Task Contract：Product Context Delta none|required；Technical Context Delta none|required；任一 required -> Context Delta required。这不是 validator gate。
|
|
363
383
|
2. 用 Parent Context Delta 统一判断；每个 slice 继承它，只记录 new durable fact yes/no。Context Delta required 时先最小更新 owning project_context/** 或 DESIGN.md；不要把 audit/matrix/verdict/日志/截图/sample evidence 写进 Context。
|
|
364
384
|
3. 检查技术实现方案覆盖产品/架构源关键要求；若只有产品方案没有技术实现方案，停止报告 missing Technical Realization Plan，不现场生成。
|
|
365
|
-
4. 初始化 plan-conformance matrix
|
|
385
|
+
4. 初始化 plan-conformance matrix；技术实现方案在本 Skill 输入校验阶段已确认可执行，直接绑定执行。
|
|
366
386
|
5. 有 subagent 支持时优先 superpowers:subagent-driven-development，否则 superpowers:executing-plans。
|
|
367
387
|
6. Plan/AC behavior gap -> superpowers:test-driven-development：先写 failing test 并 observe failure，再最小实现。
|
|
368
388
|
7. 每个实现 slice 后更新 matrix 和 audit。
|
|
@@ -370,41 +390,41 @@ Superpowers 输入包：
|
|
|
370
390
|
9. 再跑 Acceptance Evidence Gate：按验收清单生成 final verdict；每 AC 写 required proof chain/fresh evidence/missing layers/drift/substitution。current contradiction 高于历史通过记录。
|
|
371
391
|
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>。
|
|
372
392
|
|
|
373
|
-
|
|
393
|
+
权限/卡点：在当前平台/仓库/工具/用户已授权权限内最大自主推进；先打开相关 app/浏览器页面/CLI/系统设置，复用已有登录态/授权会话/凭据链；已授权 sudo/gsudo/admin elevation 先尝试。只有实际未登录/会话失效/权限不足/需要 MFA 或人工审批、缺账号/真实环境/敏感字段时才暂停，并给最小用户执行清单（页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
|
|
374
394
|
禁止完成于：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 矛盾。
|
|
375
395
|
```
|
|
376
396
|
|
|
377
397
|
Recommended compact English prompt shape:
|
|
378
398
|
|
|
379
399
|
```text
|
|
380
|
-
Product / Architecture Source: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md (scope
|
|
400
|
+
Product / Architecture Source: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md (scope)
|
|
381
401
|
Technical Realization Plan: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md (blueprint)
|
|
382
|
-
Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (
|
|
383
|
-
Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (
|
|
384
|
-
Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (
|
|
385
|
-
Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (
|
|
402
|
+
Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (authority)
|
|
403
|
+
Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (log, not proof)
|
|
404
|
+
Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (work trace)
|
|
405
|
+
Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (AC gate)
|
|
386
406
|
You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
|
|
387
|
-
|
|
407
|
+
Tiny Context adapter for Superpowers workflows; aligned to official skills, not upstream-owned schema.
|
|
388
408
|
Superpowers input packet:
|
|
389
|
-
- Source guards scope; plan controls matrix; checklist controls verdict.
|
|
390
|
-
- Local audit is only progress/candidate status/evidence/blockers/invalidating evidence.
|
|
409
|
+
- Source guards scope; plan controls matrix; checklist controls verdict; audit records progress only.
|
|
391
410
|
- Read Context/tests/core paths first; map gaps to test/API/UI/runtime/browser evidence.
|
|
392
|
-
Authority: source
|
|
411
|
+
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.
|
|
412
|
+
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.
|
|
393
413
|
|
|
394
414
|
Execution order:
|
|
395
|
-
1. Read inputs and Context.
|
|
396
|
-
2. Use Parent Context Delta once; slices inherit it and record
|
|
397
|
-
3. Check Technical Realization Plan covers Product / Architecture Source; if only product plan exists, stop with missing Technical Realization Plan
|
|
398
|
-
4.
|
|
415
|
+
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.
|
|
416
|
+
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.
|
|
417
|
+
3. Check Technical Realization Plan covers Product / Architecture Source; if only product plan exists, stop with missing Technical Realization Plan.
|
|
418
|
+
4. Init plan matrix; TRP was already validated as executable input, so bind it directly.
|
|
399
419
|
5. Prefer superpowers:subagent-driven-development with subagents; otherwise use superpowers:executing-plans.
|
|
400
420
|
6. Plan/AC behavior gap -> superpowers:test-driven-development: write a failing test, observe failure, then implement minimally.
|
|
401
421
|
7. After each slice, update matrix and audit.
|
|
402
422
|
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.
|
|
403
|
-
9. Acceptance Evidence Gate:
|
|
404
|
-
10. Final gate: self-evidence -> matrix -> verdict -> validator -> read-only auditor. Auditor summary is not proof.
|
|
423
|
+
9. Acceptance Evidence Gate: checklist controls verdict; each AC records proof chain, fresh evidence, missing layers, drift, substitution. Current contradictions override old passes.
|
|
424
|
+
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>.
|
|
405
425
|
|
|
406
|
-
Autonomy/blockers:
|
|
407
|
-
Never complete on: local audit,
|
|
426
|
+
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.
|
|
427
|
+
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.
|
|
408
428
|
```
|
|
409
429
|
|
|
410
430
|
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:
|
|
|
420
440
|
- The plan-conformance matrix path.
|
|
421
441
|
- The final acceptance verdict path.
|
|
422
442
|
- Whether required input was complete.
|
|
443
|
+
- 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.`
|
|
423
444
|
- The paste-ready Superpowers target-mode prompt in a code block.
|
|
424
445
|
|
|
425
446
|
When blocked, return:
|