project-tiny-context-harness 0.2.65 → 0.2.67

package/README.md

@@ -77,20 +77,25 @@ For short tasks, use the workflow contract and Context layer directly:
 workflow contract + project_context/** -> implementation -> verification -> drift check
 ```
 
-For long-running tasks, externalize the target first:
+For long-running tasks, externalize the target first. Use explicit Skill invocation instead of broad keyword triggering:
 
 ```text
 Web GPT or another external planning model produces a two-document upstream input
--> plan acceptance checklist Skill produces a goal/target-mode prompt
+-> /normal-long-task produces the full checklist and optional generic target-mode prompt
+-> /superpowers-long-task produces the Superpowers target-mode prompt when Superpowers execution is needed
 -> Superpowers derives concrete implementation slices
 -> each slice follows the workflow contract + project_context/**
 ```
 
 For best target-mode results, the two-document upstream input should be a `Development Plan` for execution direction and an `Acceptance and Tests` packet for acceptance authority. The development plan preserves the original requirement source and implementation direction; the acceptance packet supplies ACs, required evidence, tests, real product/core paths, evidence layers, invalid evidence, state-machine rules, local audit requirements and blockers. Source Pack exports are temporary upload material for external planning, not durable Context.
 
-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`.
+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 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 Web GPT plan, target-mode prompt, full acceptance checklist and Superpowers execution layer make the completion target recoverable without restoring a phase-gated workflow.
+The Superpowers long-task path uses `/superpowers-long-task` only after the full checklist exists. It consumes the complete packet from `/normal-long-task`, emits a Superpowers-specific target-mode prompt and cannot generate or repair the checklist. That prompt is Tiny Context's adapter layer, not a Superpowers official schema.
+
+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 the full checklist and fresh evidence.
+
+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 Web GPT plan, explicit long-task Skill invocation, target-mode prompt, full acceptance checklist and optional Superpowers execution layer make the completion target recoverable without restoring a phase-gated workflow.
 
 ## Positioning
 
@@ -141,7 +146,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.65.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.67.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -210,7 +215,7 @@ For existing projects:
 npx --yes --package project-tiny-context-harness@latest ty-context init --adopt
 ```
 
-`init` creates `project_context/context.toml`, `project_context/global.md`, `project_context/architecture.md`, `project_context/areas/main.md`, `project_context/areas/main/verification.md`, agent guidance, Context authoring Skills, a Product Surface Contract Skill, a full-project export Skill, a Harness upgrade Skill, a plan acceptance checklist Skill, managed templates/tools, a Makefile include and `.github/workflows/harness.yml`. The generated workflow runs only the selected Harness gate: `validate-context`, `validate-code-modularity` or the composite `validate-harness`; maintainer-only package tests and source-drift checks are intentionally kept out of consumer projects. It does not create business Product Surface Contract files, stage work-product trees, lifecycle state or stage skills by default.
+`init` creates `project_context/context.toml`, `project_context/global.md`, `project_context/architecture.md`, `project_context/areas/main.md`, `project_context/areas/main/verification.md`, agent guidance, Context authoring Skills, a Product Surface Contract Skill, a full-project export Skill, a Harness upgrade Skill, the `/normal-long-task` and `/superpowers-long-task` Skills, managed templates/tools, a Makefile include and `.github/workflows/harness.yml`. The generated workflow runs only the selected Harness gate: `validate-context`, `validate-code-modularity` or the composite `validate-harness`; maintainer-only package tests and source-drift checks are intentionally kept out of consumer projects. It does not create business Product Surface Contract files, stage work-product trees, lifecycle state or stage skills by default.
 
 ## FAQ
 
@@ -253,14 +258,15 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | UI/UX design Skill | `<harnessRoot>/skills/context_uiux_design/SKILL.md` | Handles explicit UI/UX design requests, writes screen/interaction conclusions to `project_context/**`, updates root `DESIGN.md` visual tokens with Google `@google/design.md`, and includes compact visual-quality calibration for product/page positioning, user needs, information density, brand/product UI and common AI-design anti-patterns. |
 | Development engineer Skill | `<harnessRoot>/skills/context_development_engineer/SKILL.md` | Handles explicit development-engineering requests and writes durable engineering conclusions to `project_context/**`. |
 | Product Surface Contract Skill | `<harnessRoot>/skills/context_surface_contract/SKILL.md` | Handles explicit Product Surface Contract, Screen Contract, surface responsibility and main/drilldown ownership work; it compiles project-owned surface contracts into `project_context/**` without adding a new context role or gate. |
-| Full project context export Skill | `<harnessRoot>/skills/context_full_project_export/SKILL.md` | Handles explicit full-project, 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/**`. |
+| Full project context export Skill | `<harnessRoot>/skills/context_full_project_export/SKILL.md` | Handles explicit full-project, project-overall, Source Pack or code-level export requests and uses `export-context --source-pack`, `--code-index`, `--task-context`, `--all`, `--full` or `--code` to create temporary artifacts under `tmp/ty-context/context-exports/**`. |
 | Harness upgrade Skill | `<harnessRoot>/skills/context_harness_upgrade/SKILL.md` | Handles explicit Tiny Context / Project Tiny Context Harness upgrade requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project”; it runs the canonical `upgrade` path, handles only migration-scoped `manual_required` / `blocked` follow-up, then runs diagnostics. |
-| Plan acceptance checklist Skill | `<harnessRoot>/skills/plan_acceptance_checklist_compiler/SKILL.md` | Handles explicit requests to turn a referenced plan, RFC, implementation proposal or two-document upstream input into a falsifiable acceptance checklist and 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; generated prompts may reference a full checklist as the authoritative acceptance standard and use compact summaries only for navigation/priority, but the Skill does not execute the plan or prove completion. |
+| Ordinary long-task Skill | `<harnessRoot>/skills/normal-long-task/SKILL.md` | Invoke as `/normal-long-task` to turn a referenced plan, RFC, implementation proposal or two-document upstream input into a falsifiable acceptance checklist and optional generic paste-ready goal/target-mode prompt under `tmp/ty-context/plan-acceptance/**`; if the plan already contains an explicit concrete checklist, the Skill reuses it verbatim in the separate full-checklist file; compact summaries are only navigation/priority, but the Skill does not execute the plan or prove completion. |
+| Superpowers long-task Skill | `<harnessRoot>/skills/superpowers-long-task/SKILL.md` | Invoke as `/superpowers-long-task` after the full checklist exists. It consumes the implementation/source plan, full checklist and local audit path, emits a Superpowers-specific prompt with the official workflow skill names, and stops when required input fields are missing. It is not a Superpowers official schema and does not generate the checklist or execute the plan. |
 | Project-local Skills | `<harnessRoot>/skills/<role>/SKILL.md` | Optional local product/design/development Skills created by the project, such as `product_plan`, `uiux_design` or `development_engineer`. They supersede package-managed default Skills when more specific, are not overwritten by `sync`, and should keep front matter trigger keywords aligned with the project `AGENTS.md` role-trigger rule. |
 | Managed file sync | `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes package-managed guidance, default Skills, Makefile include, context templates, tools and workflow YAML. It does not run migrations or perform semantic Context generation; it may block only direct asset-refresh safety issues such as invalid managed blocks or deprecated managed Skill overrides. |
 | Upgrade | `make ty-context-upgrade` or `npx --yes --package project-tiny-context-harness@latest ty-context upgrade` | Use for releases marked `upgrade-required` or `manual-required`. Builds an upgrade plan, stops before writes when `blocked` items exist, otherwise applies `safe_pending` migrations, runs `sync` and `doctor`, and exits non-zero when manual follow-up or diagnostics remain. |
 | Upgrade check | `npx --yes --package project-tiny-context-harness@latest ty-context upgrade --check [--json]` | Checks the upgrade plan without writing files. Reports `safe_pending`, `manual_required` and `blocked`; exits non-zero when any work remains. |
-| Source Pack export | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack [--check]` | Creates a bounded Source Pack under `tmp/ty-context/context-exports/<timestamp>/` and rewrites `latest/` with upload-ready Context, code index and optional bundles. |
+| Source Pack export | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack [--check]` | Creates a bounded Source Pack under `tmp/ty-context/context-exports/latest/` with upload-ready Context, code index and optional bundles, removing old timestamped rounds. |
 | Code index export | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index [--check]` | Creates a temporary implementation navigation index and manifest without complete source bodies. |
 | Task context export | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> [--profile <id>] [--check]` | Creates a bounded focused task handoff pack from profile or explicit include selectors. |
 | Combined project export | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all [--check]` | Creates both default temporary exports under `tmp/ty-context/context-exports/**`. |
@@ -277,7 +283,9 @@ For high-risk product, UI/UX and engineering tasks that affect durable architect
 
 Technical architecture support is a Minimal Context capability: use restrained `architecture.md`, area Module Design Capsules and existing `contract` / `decision-rationale` roles when durable architecture or rationale matters. Do not invent rationale; store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface when they will affect future implementation or verification choices.
 
-For long-running plans, RFCs or implementation proposals, the plan acceptance checklist Skill can turn a plan plus relevant Context into a falsifiable acceptance checklist and a 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. When the acceptance packet is incomplete, the compiler treats it as source material and generates AC rows with required evidence, verification methods, fail conditions, invalid evidence and state-machine rules. 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.
+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 completed packet from `/normal-long-task`. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion` and local audit. This is Tiny Context's adapter layer, not a Superpowers official schema, and it cannot replace `/normal-long-task` for missing checklist fields.
 
 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, does not create business surface contracts during `init` or `upgrade`, and does not turn surface conformance into a validator gate. 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.
 
@@ -396,7 +404,7 @@ npx --yes --package project-tiny-context-harness@latest ty-context export-contex
 npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack --check
 ```
 
-It writes `tmp/ty-context/context-exports/<timestamp>/` and rewrites `tmp/ty-context/context-exports/latest/` as ordinary files/directories. A standard Source Pack is capped at 5 files: `source-pack-manifest.json`, `full-project-context.md`, `code-index.md`, and at most `code-bundle-core.md` plus `code-bundle-extended.md`; small projects may omit bundles. The `source-pack-v1` manifest uses repo-relative artifact paths and hashes, aggregates warnings and omitted files, and recommends upload sets for daily planning, cross-module review and full fallback.
+It writes `tmp/ty-context/context-exports/latest/` as ordinary files/directories and removes old timestamped export rounds. A standard Source Pack is capped at 5 files: `source-pack-manifest.json`, `full-project-context.md`, `code-index.md`, and at most `code-bundle-core.md` plus `code-bundle-extended.md`; small projects may omit bundles. The `source-pack-v1` manifest uses repo-relative artifact paths and hashes, aggregates warnings and omitted files, and recommends upload sets for daily planning, cross-module review and full fallback.
 
 `export-context --code-index` creates the navigation index and manifest without complete source bodies:
 
@@ -413,7 +421,7 @@ npx --yes --package project-tiny-context-harness@latest ty-context export-contex
 npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context demo --include-context project_context/areas/main.md --include-code 'src/demo/**'
 ```
 
-Profiles live in `<harnessRoot>/config.yaml` under `source_packs`; they are export selectors only, not durable facts, and their `verification` entries are listed without being executed. Source Pack modes keep secret redaction enabled across indexes, bundles, task contexts and manifests. `--redaction-strict` exits non-zero if redaction was required, `--max-pack-files` defaults to 5 and cannot exceed 5, and `--prune <count>` keeps `latest/` while removing older timestamped rounds beyond the requested retention count.
+Profiles live in `<harnessRoot>/config.yaml` under `source_packs`; they are export selectors only, not durable facts, and their `verification` entries are listed without being executed. Source Pack modes keep secret redaction enabled across indexes, bundles, task contexts and manifests. `--redaction-strict` exits non-zero if redaction was required, `--max-pack-files` defaults to 5 and cannot exceed 5, and `--prune <count>` is accepted for older scripts while latest-only retention is applied by default.
 
 Legacy exports remain for compatibility and full fallback.
 
@@ -489,7 +497,7 @@ $EDITOR <harnessRoot>/skills/uiux_design/SKILL.md
 
 When a project-local Skill and a package-managed default Skill both apply, agents should use the more specific project-local Skill first. The local Skill should keep durable conclusions in `project_context/**` and `DESIGN.md`. Its front matter `description` should stay aligned with the matching default `context_*` Skill and the project `AGENTS.md` role-trigger rule; update both the local Skill and agent guidance when adding or narrowing product/design/development trigger terms. `sync` does not merge Skill overrides and does not overwrite separate project-local Skills. Existing `<harnessRoot>/ty-context-managed/override_skills/*.md` files should be migrated into standalone project-local Skills before running `sync`.
 
-Do not customize the package-managed Surface Contract, Harness upgrade or plan acceptance checklist Skills directly. Project-specific surface responsibilities, upgrade facts and acceptance semantics belong in `project_context/**`; recurring project-local procedures belong in separate project-local Skills.
+Do not customize the package-managed Surface Contract, Harness upgrade, `/normal-long-task` or `/superpowers-long-task` Skills directly. Project-specific surface responsibilities, upgrade facts and acceptance semantics belong in `project_context/**`; recurring project-local procedures belong in separate project-local Skills.
 
 ## Sync And Upgrade Boundary
 

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.65.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.67.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -121,20 +121,25 @@ For short tasks, use the workflow contract and Context layer directly:
 workflow contract + project_context/** -> implementation -> verification -> drift check
 ```
 
-For long-running tasks, externalize the target first:
+For long-running tasks, externalize the target first. Use explicit Skill invocation instead of broad keyword triggering:
 
 ```text
 Web GPT or another external planning model produces a two-document upstream input
--> plan acceptance checklist Skill produces a goal/target-mode prompt
+-> /normal-long-task produces the full checklist and optional generic target-mode prompt
+-> /superpowers-long-task produces the Superpowers target-mode prompt when Superpowers execution is needed
 -> Superpowers derives concrete implementation slices
 -> each slice follows the workflow contract + project_context/**
 ```
 
 For best target-mode results, the two-document upstream input should be a `Development Plan` for execution direction and an `Acceptance and Tests` packet for acceptance authority. The development plan summarizes the original requirement source and implementation direction; the acceptance packet supplies ACs, required evidence, tests, real product/core paths, evidence layers, invalid evidence, state-machine rules, local audit requirements and blockers. Source Pack exports are temporary upload material for external planning, not durable Context.
 
-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`.
+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 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 Web GPT plan, target-mode prompt, full acceptance checklist and Superpowers execution layer make the completion target recoverable without restoring a phase-gated workflow.
+The Superpowers long-task path uses `/superpowers-long-task` only after the full checklist exists. It consumes the complete packet from `/normal-long-task`, emits a Superpowers-specific target-mode prompt and cannot generate or repair the checklist. That prompt is Tiny Context's adapter layer, not a Superpowers official schema.
+
+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 the full checklist and fresh evidence.
+
+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 Web GPT plan, explicit long-task Skill invocation, target-mode prompt, full acceptance checklist and optional Superpowers execution layer make the completion target recoverable without restoring a phase-gated workflow.
 
 ## Positioning
 
@@ -255,9 +260,10 @@ npx --yes --package project-tiny-context-harness@latest ty-context init --adopt
 - `<harnessRoot>/skills/context_uiux_design/SKILL.md`
 - `<harnessRoot>/skills/context_development_engineer/SKILL.md`
 - `<harnessRoot>/skills/context_surface_contract/SKILL.md`
-- `<harnessRoot>/skills/context_full_project_export/SKILL.md`
-- `<harnessRoot>/skills/context_harness_upgrade/SKILL.md`
-- `<harnessRoot>/skills/plan_acceptance_checklist_compiler/SKILL.md`
+- `<harnessRoot>/skills/context_full_project_export/SKILL.md`
+- `<harnessRoot>/skills/context_harness_upgrade/SKILL.md`
+- `<harnessRoot>/skills/normal-long-task/SKILL.md`
+- `<harnessRoot>/skills/superpowers-long-task/SKILL.md`
 - `<harnessRoot>/ty-context-managed/context_templates/**`
 - `<harnessRoot>/ty-context-managed/make/ty-context.mk`
 - `tools/**`
@@ -292,7 +298,7 @@ No. It checks that recovery facts exist and avoids fake test-result claims. Prod
 
 It should stay smaller than a full process. Ordinary bug fixes and local refactors do not update Context unless they produce durable product, architecture, API, state or validation facts.
 
-The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and plan-acceptance-checklist 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. Plan acceptance artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria for a referenced plan but do not execute it or prove acceptance. If the plan already contains an explicit concrete checklist, the Skill 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; the compiler preserves both source roles and turns them into the full checklist plus 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 Harness upgrade Skill handles requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project” by following the release update mode, using `upgrade` for migration-bearing releases, and limiting manual cleanup to migration-scoped follow-up.
+The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and explicit long-task requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Long-task artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria for a referenced plan but do not execute it or prove acceptance. 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 the complete packet and emits the Superpowers-specific target-mode prompt; it is not a Superpowers official schema and stops if required fields are missing. The Harness upgrade Skill handles requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project” by following the release update mode, using `upgrade` for migration-bearing releases, and limiting manual cleanup to migration-scoped follow-up.
 
 Multilingual trigger phrases are compatibility details. Public README, npm and launch copy stay English-first, and public/package-managed surfaces must remain English-complete; literal non-English examples are documented only where they explain generated Skill matching and must not be the sole activation path.
 
@@ -300,9 +306,11 @@ For high-risk product, UI/UX and engineering tasks that affect durable architect
 
 Technical architecture support is a Minimal Context capability: use restrained `architecture.md`, area Module Design Capsules and existing `contract` / `decision-rationale` roles when durable architecture or rationale matters. Do not invent rationale; store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface when they will affect future implementation or verification choices.
 
-For long-running plans, RFCs or implementation proposals, the plan acceptance checklist compiler can turn a plan plus relevant Context into a falsifiable acceptance checklist and a 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. When the acceptance packet is incomplete, the compiler treats it as source material and generates AC rows with required evidence, verification methods, fail conditions, invalid evidence and state-machine rules. 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.
+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 completed packet from `/normal-long-task`. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion` and local audit. This is Tiny Context's adapter layer, not a Superpowers official schema, and it cannot replace `/normal-long-task` for missing checklist fields.
 
-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 the completion target is externalized. Use the plan acceptance checklist compiler before long-running execution when there is a plan-like source; treat the full checklist as the acceptance target, and treat the local audit only as temporary progress/recovery state.
+Important usage note: Minimal Context intentionally keeps Context read order, Context/code priority and drift checks as agent-level soft constraints rather than machine-enforced gates. That tradeoff works well for short tasks, but long tasks with large context windows, multiple handoffs or many verification loops are expected to drift unless the completion target is externalized. Use `/normal-long-task` before long-running execution when there is a plan-like source; treat the full checklist as the acceptance target, and treat the local audit only as temporary progress/recovery state.
 
 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, does not create business surface contracts during `init` or `upgrade`, and does not turn surface conformance into a validator gate. 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.
 
@@ -355,7 +363,7 @@ The expected Context Priority Ladder is: read Context first, run the product/pag
 
 Managed `AGENTS.md` guidance is intentionally a startup router, not a full manual. It should contain fact-source entry points, hard boundaries, key triggers and shortest validation commands; package consumers default long design reasoning to Context unless they already have a local spec/design convention. In this source workspace, `PROJECT_SPEC.md` holds stable Harness workflow rationale. Role procedures belong in Skills and human usage guidance in README. The recommended 40-70 line range is a soft budget, not a validator gate.
 
-The default `context_*` Skills and package-managed utility Skills are generated files. `sync` overwrites them, so project-specific product/design/development/surface-contract rules should live in separate project-local Skills such as `.codex/skills/product_plan/SKILL.md`, `.codex/skills/uiux_design/SKILL.md`, `.codex/skills/development_engineer/SKILL.md` or `.codex/skills/surface_contract/SKILL.md`. When a project-local Skill and a default Skill both apply, agents should use the more specific project-local Skill first while keeping durable conclusions in `project_context/**` and `DESIGN.md`. Keep the project-local Skill front matter `description` triggers aligned with the matching default `context_*` Skill and the project `AGENTS.md` role-trigger rule; if a project adds or narrows product/design/development/surface keywords, update both the local Skill and the agent guidance together. The Surface Contract, Harness upgrade and plan acceptance checklist Skills are also package-managed; customize project semantics in Context or separate project-local Skills, not by editing those generated Skills.
+The default `context_*` Skills and package-managed utility Skills are generated files. `sync` overwrites them, so project-specific product/design/development/surface-contract rules should live in separate project-local Skills such as `.codex/skills/product_plan/SKILL.md`, `.codex/skills/uiux_design/SKILL.md`, `.codex/skills/development_engineer/SKILL.md` or `.codex/skills/surface_contract/SKILL.md`. When a project-local Skill and a default Skill both apply, agents should use the more specific project-local Skill first while keeping durable conclusions in `project_context/**` and `DESIGN.md`. Keep the project-local Skill front matter `description` triggers aligned with the matching default `context_*` Skill and the project `AGENTS.md` role-trigger rule; if a project adds or narrows product/design/development/surface keywords, update both the local Skill and the agent guidance together. The Surface Contract, Harness upgrade, `/normal-long-task` and `/superpowers-long-task` Skills are also package-managed; customize project semantics in Context or separate project-local Skills, not by editing those generated Skills.
 
 ## CLI Entry Safety
 
@@ -371,7 +379,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
 | `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes managed guidance, default Skills, Makefile include, tools and templates. It does not run migrations or generate project semantics; it may block only direct asset-refresh safety issues such as invalid managed blocks or deprecated managed Skill overrides. |
 | `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. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context upgrade --check [--json]` | Checks the upgrade plan without writing files. Reports `safe_pending`, `manual_required` and `blocked`; exits non-zero when any work remains. |
-| `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack [--check]` | Creates a bounded Source Pack under `tmp/ty-context/context-exports/<timestamp>/` and rewrites `latest/` with upload-ready Context, code index and optional bundles. |
+| `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack [--check]` | Creates a bounded Source Pack under `tmp/ty-context/context-exports/latest/` with upload-ready Context, code index and optional bundles, removing old timestamped rounds. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index [--check]` | Creates a temporary implementation navigation index and manifest without full source bodies. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> [--profile <id>] [--check]` | Creates a bounded focused task handoff pack from profile or explicit include selectors. |
 | `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all [--check]` | Creates both default temporary exports under `tmp/ty-context/context-exports/**`. |
@@ -503,7 +511,7 @@ npx --yes --package project-tiny-context-harness@latest ty-context export-contex
 npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack --check
 ```
 
-This writes a timestamped directory and rewrites `tmp/ty-context/context-exports/latest/` as ordinary files/directories for Windows compatibility. A standard Source Pack is capped at 5 files: `source-pack-manifest.json`, `full-project-context.md`, `code-index.md`, and at most `code-bundle-core.md` plus `code-bundle-extended.md`; small projects may omit bundle files. The manifest schema is `source-pack-v1`, uses repo-relative artifact paths and hashes, records warnings/omitted files, and recommends upload sets.
+This writes `tmp/ty-context/context-exports/latest/` as ordinary files/directories for Windows compatibility and removes old timestamped export rounds. A standard Source Pack is capped at 5 files: `source-pack-manifest.json`, `full-project-context.md`, `code-index.md`, and at most `code-bundle-core.md` plus `code-bundle-extended.md`; small projects may omit bundle files. The manifest schema is `source-pack-v1`, uses repo-relative artifact paths and hashes, records warnings/omitted files, and recommends upload sets.
 
 Recommended upload sets:
 
@@ -527,7 +535,7 @@ npx --yes --package project-tiny-context-harness@latest ty-context export-contex
 npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context demo --include-context project_context/areas/main.md --include-code 'src/demo/**'
 ```
 
-Source Pack modes always keep secret redaction enabled. `--redaction-strict` exits non-zero if any secret/token/cookie/password/api_key/credential/bearer/authorization assignment required redaction. `--max-pack-files` defaults to 5 and cannot exceed 5 for Source Pack or task packs. `--prune <count>` keeps `latest/` and removes old timestamped export rounds beyond the requested retention count.
+Source Pack modes always keep secret redaction enabled. `--redaction-strict` exits non-zero if any secret/token/cookie/password/api_key/credential/bearer/authorization assignment required redaction. `--max-pack-files` defaults to 5 and cannot exceed 5 for Source Pack or task packs. `--prune <count>` is accepted for older scripts, but Source Pack modes now keep only `latest/` by default.
 
 Legacy exports remain for compatibility and full fallback.
 

package/assets/README.zh-CN.md

@@ -50,9 +50,11 @@ Fresh agent 先读这些文件，再开始改代码。
 
 一个典型失败场景是 ABCD 模块链：A/B/C 是上游，D 是下游。现在做 D 的需求时发现能力缺口；如果没有 Context 和优先级约束，agent 很容易为了让 D 完成而去改上游 A/B，因为当前代码让这条路可行。但真正需要判断的是：D 是否有权改 A/B？缺口是不是属于 C 的契约？是否必须先声明 `Context Delta`，让项目意图变化被确认后再实现？代码能说明“现在怎么改得动”，不能说明“项目意图是否允许这样改”。Tiny Context 要补的就是这一层 repo 内长期事实和优先级契约。
 
-对于长程任务，Harness 也提供一个轻量的计划验收清单 Skill：当用户明确给出或引用某份方案 / 计划 / RFC / implementation plan，并要求生成验收清单、完成定义或 goal/target 模式提示词时，它会把计划和验收清单临时放到 `tmp/ty-context/plan-acceptance/**`。如果外部规划模型参与，推荐仍然只给两份产物：`《开发方案》` 作为执行方向，`《验收清单和测试用例》` 作为 Codex target-mode acceptance input packet。第二份应包含 AC、required evidence、测试命令、真实产品路径 / core path、证据分层、无效证据、状态机、local audit 和 blocker。Source Pack 只是临时上传材料，不是 durable Context。如果方案里已经有明确、具体的“验收清单”，Skill 会直接复用那份清单并单独写入完整验收清单文件；如果第二份缺少 required evidence、verification method、fail condition、状态机或无效证据规则，Skill 会把它作为来源生成或补齐验收项，而不是把它当完成证明。这只是执行前的一次验收标准梳理，不执行计划、不证明完成，也不会把临时清单注册成 `project_context/**`。
+对于长程任务，Harness 提供两个显式调用的长程任务 Skill。普通长程任务用 `/normal-long-task`：它把方案和验收输入临时放到 `tmp/ty-context/plan-acceptance/**`，生成或复用完整验收清单，并可输出普通目标模式文本。如果外部规划模型参与，推荐仍然只给两份产物：`《开发方案》` 作为执行方向，`《验收清单和测试用例》` 作为 Codex target-mode acceptance input packet。第二份应包含 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 会停止并列出缺失项，不生成完整验收清单或目标模式文本。
 
-重要使用提示：Minimal Context 有意把 Context 读取顺序、Context / 代码优先级和漂移检查保持为 agent 级软约束，而不是机器强制 gate。这个取舍适合短任务，但长任务、大上下文、多次交接或多轮验证时预期会漂移。遇到这类任务且已有方案/计划来源时，应先用计划验收清单 Skill 外化一个可证伪完成目标；完整验收清单才是验收标准，local audit 只是临时进度/恢复状态。
+Superpowers 长程任务 Skill 用 `/superpowers-long-task`。如果下一步明确要 Superpowers 目标模式文本，则在完整验收清单已经存在后调用 `/superpowers-long-task`。它消费完整方案/清单/audit 包，显式输出 `Superpowers 输入包` 和执行绑定，让未来 executor 清楚哪些输入进入 `superpowers:writing-plans`、subagent/inline execution、TDD、`superpowers:verification-before-completion` 和 local audit。这个 prompt 是 Tiny Context 的适配层，不是 Superpowers 官方 schema；它不生成或修补验收清单、不执行计划、不证明完成，也不会把临时清单注册成 `project_context/**`。
+
+重要使用提示：Minimal Context 有意把 Context 读取顺序、Context / 代码优先级和漂移检查保持为 agent 级软约束，而不是机器强制 gate。这个取舍适合短任务，但长任务、大上下文、多次交接或多轮验证时预期会漂移。遇到这类任务且已有方案/计划来源时，应先调用 `/normal-long-task` 外化一个可证伪完成目标；完整验收清单才是验收标准，local audit 只是临时进度/恢复状态。
 
 ## 当前最佳实践
 
@@ -66,14 +68,15 @@ Fresh agent 先读这些文件，再开始改代码。
 
 ```text
 Web GPT 或其他外部规划模型产出两份产物：《开发方案》+《验收清单和测试用例》
--> 计划验收清单 Skill 生成目标模式文本
+-> /normal-long-task 生成完整验收清单和可选普通目标模式文本
+-> 需要 Superpowers 时，/superpowers-long-task 生成 Superpowers 专用目标模式文本
 -> Superpowers 得出具体落地执行片段
 -> 每个执行片段都回到流程契约 + project_context/**
 ```
 
 这里的 Superpowers 指具体的 [obra/Superpowers](https://github.com/obra/superpowers) 插件/开源工作流，不是泛化的执行规划替代品。如果目标模式文本或原方案还不够可执行，用 `superpowers:writing-plans` 转成 bite-sized implementation plan；有 subagent 支持时优先用 `superpowers:subagent-driven-development`，否则用 `superpowers:executing-plans`；涉及行为变更时用 `superpowers:test-driven-development`；完成声明前用 `superpowers:verification-before-completion` 对完整验收清单和 fresh evidence 做 gate。
 
-原因是漂移控制。流程契约 + Context 层是软约束，短任务里通常能让 agent 按预期执行；长程任务里，Context 仍然能记录符合预期的事实，但 Context 到代码 的实现步骤会随着上下文窗口变大、多次交接、subagent 拆分和多轮验证而漂移。Web GPT 方案、目标模式文本、完整验收清单和 Superpowers 执行层，把完成目标外化成可恢复、可审计的临时执行标准，同时不恢复阶段式 gate。
+原因是漂移控制。流程契约 + Context 层是软约束，短任务里通常能让 agent 按预期执行；长程任务里，Context 仍然能记录符合预期的事实，但 Context 到代码 的实现步骤会随着上下文窗口变大、多次交接、subagent 拆分和多轮验证而漂移。Web GPT 方案、显式长程任务 Skill 调用、目标模式文本、完整验收清单和可选 Superpowers 执行层，把完成目标外化成可恢复、可审计的临时执行标准，同时不恢复阶段式 gate。
 
 ## 适合谁
 

package/assets/agents/AGENTS_CORE.md

@@ -38,10 +38,10 @@
 9. 每个有意义的方案或实现变更收尾时做 Contract Conformance 和 Context drift check：对照 Task Contract 区分实现偏差、契约遗漏或长期事实缺失；实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失回 `Context Delta` 并先更新 Context。交付说明只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`；Conformance 证据属于本次交付，不写入 `project_context/**`。
 10. 长期事实只写入 `project_context/**`；不要默认创建 PRD、tech plan、ADR、implementation doc、review/test/release 文档。
 11. 用户明确要求“产品方案 / 产品经理 / 产品专家 / product plan / product manager / product spec”、“设计稿 / UI/UX 设计方案 / 视觉专家 / UX designer / UI designer / visual polish / design system spec”或“开发工程师 / 技术方案 / 开发方案 / 实现 / 实现方案 / 实施计划 / 技术专家 / software engineer / development plan / technical implementation plan / 多开agent / subagent”这类角色或强产物名时，使用对应 Context authoring Skill，把长期结论写回 `project_context/**`。
-12. 用户明确要求“导出尽可能详细的项目全量上下文 / 全量上下文导出 / full project context export / export full project context / project context export / 当前项目代码实现 / 代码级实现导出 / code-level implementation export / Source Pack export / source-pack export / task context export / code index export”时，使用 `context_full_project_export` Skill；默认优先运行 `ty-context export-context --source-pack` 生成最多 5 个临时上传文件；只需要导航索引用 `--code-index`，聚焦交接用 `--task-context <name>`，需要 legacy 单文件完整代码快照时再用 `--code`，需要 legacy Context+代码双导出时可用 `--all`；导出产物只放 `tmp/ty-context/context-exports/**`，不得放入或注册到 `project_context/**` / `project_context/context.toml`。用户明确要求“upgrade Tiny Context / update Tiny Context / Project Tiny Context Harness upgrade / 用 Tiny Context upgrade skill 升级这个项目 / 升级 tiny context”时，使用 `context_harness_upgrade` Skill，先走 `upgrade`，不要先单独运行 `sync`。
-13. 用户提供或引用某份方案 / 计划 / RFC / implementation plan / milestone plan，并明确要求生成验收清单、完成定义、goal-mode prompt 或 target-mode prompt 时，使用 `plan_acceptance_checklist_compiler` Skill；输出只放 `tmp/ty-context/plan-acceptance/**`，它只定义验收标准，不执行计划、不证明完成、不把结果注册到 `project_context/**` / `project_context/context.toml`。
+12. 用户明确要求“导出尽可能详细的项目全量上下文 / 全量上下文导出 / 项目整体上下文 / full project context export / export full project context / project context export / project overall context / 当前项目代码实现 / 代码级实现导出 / code-level implementation export / Source Pack export / source-pack export / task context export / code index export”时，使用 `context_full_project_export` Skill；默认优先运行 `ty-context export-context --source-pack` 生成最多 5 个临时上传文件到 `tmp/ty-context/context-exports/latest/`，且只保留 `latest/` 导出轮次；只需要导航索引用 `--code-index`，聚焦交接用 `--task-context <name>`，需要 legacy 单文件完整代码快照时再用 `--code`，需要 legacy Context+代码双导出时可用 `--all`；导出产物只放 `tmp/ty-context/context-exports/**`，不得放入或注册到 `project_context/**` / `project_context/context.toml`。用户明确要求“upgrade Tiny Context / update Tiny Context / Project Tiny Context Harness upgrade / 用 Tiny Context upgrade skill 升级这个项目 / 升级 tiny context”时，使用 `context_harness_upgrade` Skill，先走 `upgrade`，不要先单独运行 `sync`。
+13. 长程任务不要靠宽泛关键词自动触发临时验收流程；需要普通长程任务包时，建议用户直接调用 `/normal-long-task`，需要 Superpowers 长程任务包时，建议直接调用 `/superpowers-long-task`，且通常先用 `/normal-long-task` 形成完整验收清单。输出只放 `tmp/ty-context/plan-acceptance/**`，它们只定义验收标准或执行提示词，不执行计划、不证明完成、不把结果注册到 `project_context/**` / `project_context/context.toml`。
 14. 当任务涉及设计稿、重做设计、视觉方案、设计系统、visual polish、frontend redesign 或 frontend styling，且存在可扫描的 UI 代码、页面文件、构建产物目录或本地/远程 URL 时，默认运行 `npx impeccable detect <target>` 做 Impeccable 视觉审查；没有可扫描目标、命令不可用或扫描失败时，说明原因并继续。Impeccable 不是 `validate-context` gate，也不替代截图检查、项目测试或人工判断。
-15. Tiny Context / Harness managed surfaces 是生成资产：`AGENTS.md` managed block、`.agent/ty-context-managed/**`、`.agent/skills/context_product_plan/**`、`.agent/skills/context_uiux_design/**`、`.agent/skills/context_development_engineer/**`、`.agent/skills/context_surface_contract/**`、`.agent/skills/context_full_project_export/**`、`.agent/skills/context_harness_upgrade/**` 和 `.agent/skills/plan_acceptance_checklist_compiler/**` 禁止承载项目特定规则；直接编辑会在 `sync` 时被覆盖或产生漂移。项目本地产品 / UIUX / 开发 / surface contract 规则必须新建独立 Skill，例如 `.agent/skills/product_plan/SKILL.md`、`.agent/skills/uiux_design/SKILL.md`、`.agent/skills/development_engineer/SKILL.md` 或 `.agent/skills/surface_contract/SKILL.md`；当项目本地 Skill 与默认 Skill 同时适用时，优先使用更具体的项目本地 Skill。项目本地 Skill 的 front matter `description` 触发词应与本文件中的角色触发规则和对应默认 `context_*` Skill 保持一致；新增或收窄关键词时，同步更新本地 Skill 描述和项目级 agent 指引，避免 Skill 触发条件与 Tiny Context 工作规则漂移。
+15. Tiny Context / Harness managed surfaces 是生成资产：`AGENTS.md` managed block、`.agent/ty-context-managed/**`、`.agent/skills/context_product_plan/**`、`.agent/skills/context_uiux_design/**`、`.agent/skills/context_development_engineer/**`、`.agent/skills/context_surface_contract/**`、`.agent/skills/context_full_project_export/**`、`.agent/skills/context_harness_upgrade/**`、`.agent/skills/normal-long-task/**` 和 `.agent/skills/superpowers-long-task/**` 禁止承载项目特定规则；直接编辑会在 `sync` 时被覆盖或产生漂移。项目本地产品 / UIUX / 开发 / surface contract 规则必须新建独立 Skill，例如 `.agent/skills/product_plan/SKILL.md`、`.agent/skills/uiux_design/SKILL.md`、`.agent/skills/development_engineer/SKILL.md` 或 `.agent/skills/surface_contract/SKILL.md`；当项目本地 Skill 与默认 Skill 同时适用时，优先使用更具体的项目本地 Skill。项目本地 Skill 的 front matter `description` 触发词应与本文件中的角色触发规则和对应默认 `context_*` Skill 保持一致；新增或收窄关键词时，同步更新本地 Skill 描述和项目级 agent 指引，避免 Skill 触发条件与 Tiny Context 工作规则漂移。
 16. ADR 降级为 Context 中的 `Design Rationale`；实现说明优先写成代码注释、测试名或模块 Context 中的关键约束。
 17. Harness workflow gate 只运行 `validate-context`，用于检查上下文是否可恢复；不检查 context/code 修改顺序。自动化最多提示 context-first 风险，不做阻断。
 18. 产品质量由项目自己的验证入口证明；Context 只能声明验证 / 部署关键路径，不能伪造“测试已通过”或“部署已成功”。
@@ -53,7 +53,7 @@
 
 - `make validate-context`：检查 `project_context/**` 是否足够支持 agent 恢复上下文。
 - `make ty-context-sync`：刷新 managed guidance、Context template、默认 Skill 和工具。
-- `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack`：导出最多 5 个临时 Source Pack 上传文件到 `tmp/ty-context/context-exports/**`，并刷新 `latest/`。
+- `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack`：导出最多 5 个临时 Source Pack 上传文件到 `tmp/ty-context/context-exports/latest/`，并移除旧时间戳导出轮次。
 - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index`：导出不含完整源码正文的临时代码索引和 manifest。
 - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name>`：导出最多 5 个临时聚焦任务交接文件。
 - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all`：同时导出临时项目级 Context 汇总和代码级实现 Markdown 到 `tmp/ty-context/context-exports/**`。

package/assets/skills/context_full_project_export/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: context_full_project_export
-description: Use when the user explicitly asks to 导出尽可能详细的项目全量上下文, 全量上下文导出, 项目上下文全量导出, full project context export, export full project context, project context export, Source Pack export, source-pack export, code index export, task context export, 当前项目代码实现, 代码级实现导出, or code-level implementation export in a Minimal Context Harness project.
+description: Use when the user explicitly asks to 导出尽可能详细的项目全量上下文, 全量上下文导出, 项目上下文全量导出, 项目整体上下文, full project context export, export full project context, project context export, project overall context, Source Pack export, source-pack export, code index export, task context export, 当前项目代码实现, 代码级实现导出, or code-level implementation export in a Minimal Context Harness project.
 ---
 
 # Context Full Project Export
@@ -13,13 +13,13 @@ This Skill creates a temporary export artifact only. It does not author durable
 
 ## Purpose
 
-When the user needs a full project context export or external LLM handoff, create temporary export artifacts that collect project Context, key agent guidance, architecture/module facts, code navigation and bounded source support for copying into an external tool or one-off discussion.
+When the user needs a full project context export, project overall context export or external LLM handoff, create temporary export artifacts that collect project Context, key agent guidance, architecture/module facts, code navigation and bounded source support for copying into an external tool or one-off discussion.
 
 When the user needs a code-level implementation export, create one temporary Markdown snapshot of current source and engineering configuration files for upload to Web GPT or another external model.
 
 ## Workflow
 
-1. Prefer the bounded Source Pack for external LLM / Web GPT planning. It writes at most 5 files plus a manifest under `tmp/ty-context/context-exports/<timestamp>/` and rewrites `latest/`:
+1. Prefer the bounded Source Pack for external LLM / Web GPT planning. It writes at most 5 files total under `tmp/ty-context/context-exports/latest/` and removes old timestamped export rounds:
    - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack`
 2. Use `--code-index` when implementation navigation is enough and full source bodies are not needed:
    - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index`
@@ -47,7 +47,7 @@ When the user needs a code-level implementation export, create one temporary Mar
 ## Output Boundaries
 
 - Export artifacts must remain temporary export artifacts, not Context.
-- `--source-pack` defaults to `tmp/ty-context/context-exports/<timestamp>/` and `latest/`, with `source-pack-manifest.json`, `full-project-context.md`, `code-index.md` and optional `code-bundle-core.md` / `code-bundle-extended.md`.
+- `--source-pack` defaults to `tmp/ty-context/context-exports/latest/`, with `source-pack-manifest.json`, `full-project-context.md`, `code-index.md` and optional `code-bundle-core.md` / `code-bundle-extended.md`.
 - `--source-pack` and `--task-context` are capped at 5 output files. `--max-pack-files` cannot exceed 5.
 - `--code-index` creates a navigation index and manifest without complete source bodies.
 - `--task-context <name>` creates `task-contexts/task-context-<name>.md` plus optional support bundle; profile verification entries are listed, not executed.