project-tiny-context-harness 0.7.7 → 0.7.8

package/README.md

@@ -79,13 +79,20 @@ npx --yes project-tiny-context-harness ty-context validate-context
 npx --yes project-tiny-context-harness ty-context doctor
 ```
 
-Default profiles are `core-portable` and `workflow-default`; the base managed set includes `/design-resource-authoring`. Explicitly enable long-task support:
+Default profiles are `core-portable` and `workflow-default`; the base managed set includes explicitly invoked `/design-system-authoring` and `/design-resource-authoring`. Explicitly enable long-task support:
 
 ```powershell
 ty-context enable long-task
 ```
 
-Enabling Long-Task additionally installs `/source-plan-authoring`, `/long-task-workflow` and the completion Hook. Disable only those Long-Task-owned surfaces with `ty-context disable long-task`; the base `/design-resource-authoring` remains. Tiny Context does not install Open Design or another design-generation runtime.
+Enabling Long-Task additionally installs `/long-task-workflow`, the retired `/source-plan-authoring` compatibility pointer and the completion Hook. Disable only those Long-Task-owned surfaces with `ty-context disable long-task`; both base design Skills remain. Tiny Context does not install Open Design or another design-generation runtime.
+
+## Recommended Usage
+
+- **Long delivery:** initial product intent or detailed external/Web GPT proposal → explicitly run `/design-system-authoring` if project Design Authority is absent → `/design-resource-authoring` selects resources and reconciles accepted decisions into the proposal once → pass the revised proposal plus selected immutable resources to `/long-task-workflow`, which performs integrated Source and Contract Draft authoring in the same Goal.
+- **Non-long delivery:** use the same proposal/design-resource path, then give the revised proposal plus resources directly to the current native Goal under the default Workflow Contract.
+
+The design-system Skill is normally used at cold start but never auto-runs. Only style-bearing resource work is gated; low-fidelity structure, IA/flow and semantics-only state studies remain available. A legacy Source Plan remains ordinary input, not a recommended intermediate service.
 
 ## Positioning
 
@@ -137,7 +144,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.7.7.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.8.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -193,7 +200,7 @@ For material UI, **UI Authority Closure** reconciles each stable surface/control
 
 ### Visual Delivery Guidance
 
-The default Workflow performs UI Authority Closure and a conditional Design Authority Check before material production UI. It reads the owning Surface/Screen/Control Context, `DESIGN.md`, one authored exact token source/generation direction and selected design references. Each reference is `exact-target`, `constraint` or `inspiration`; an unconfigured starter, candidate, style-only prose or inspiration does not authorize invented production layout, and a configured project visual system does not claim every page is implementation-ready. Explicit standalone resource generation routes to `/design-resource-authoring`, which commissions external Open Design capabilities without adopting authority; downstream durable adoption/repair routes through `context_uiux_design`. Ordinary implementation with sufficient authority, local style fixes and throwaway prototypes remain lightweight.
+The default Workflow performs UI Authority Closure and a conditional Design Authority Check before material production UI. It reads the owning Surface/Screen/Control Context, `DESIGN.md`, one authored exact token source/generation direction and selected design references. Each reference is `exact-target`, `constraint` or `inspiration`; an unconfigured starter, candidate, style-only prose or inspiration does not authorize invented production layout, and a configured project visual system does not claim every page is implementation-ready. Explicit project design-system initialization/adoption routes to `/design-system-authoring`; explicit standalone resource generation routes to `/design-resource-authoring`, which commissions external Open Design capabilities without adopting authority. The consuming workflow and `context_uiux_design` still own UI Authority Closure and later durable repairs outside design-system cold-start/adoption. Ordinary implementation with sufficient authority, local style fixes and throwaway prototypes remain lightweight.
 
 For material work, `context_uiux_design` keeps a task-local risk-proportional Visual Coverage Set; durable interaction facts remain in `project_context/**`, durable visual semantics and the design-reference registry remain in `DESIGN.md`, and versioned targets stay at project-native paths. `context_development_engineer` binds that intent to production routes and reports only combinations actually rendered and checked. An implementation screenshot cannot become its own target.
 
@@ -203,33 +210,35 @@ Combined design-and-implementation work may author candidates in ordinary Outcom
 
 `ty-context doctor` keeps its compatible `missing | unconfigured | configured` project-level status and adds advisory Design Authority Index, token-source and classified-reference signals. It explicitly does not infer surface implementation readiness; that requires the owning Screen/Control meaning, selected target/constraints and project-owned verification.
 
+### Explicit Design System Authoring
+
+Use `/design-system-authoring` only on an explicit request to initialize, generate, select, adopt, replace or repair the project design system/style. It discovers live Open Design MCP resources/tools and feature-detects lifecycle methods; because Open Design 0.15.1 exposes design systems as MCP resources but no creation tool, the documented compatibility path uses the same installed daemon's official generation/revision/accept API. Candidates require explicit human or explicitly delegated selection before adoption into canonical project `DESIGN.md`, one authored token source/direction and only owning Context. Provider ID/revision/digest and `get_project.designSystemId` are synchronization provenance, not another authority.
+
 ### Optional Design Resource Authoring
 
-Use `/design-resource-authoring` only for an explicit request to generate, iterate or prepare standalone design resources, prepare resources for a named development scope, or use Open Design. It accepts raw notes or an initial proposal, product/technical plans, a visual brief, screenshots, existing resources or an optional Source Plan. Source Plan authoring is not a prerequisite; both Skills consume raw inputs independently and neither invokes the other.
+Use `/design-resource-authoring` only for an explicit request to generate, iterate or prepare standalone design resources, prepare resources for a named development scope, or use Open Design. It accepts raw notes or an initial proposal, product/technical plans, a visual brief, screenshots, existing resources or a legacy Source Plan. A standalone Source Plan is neither prerequisite nor recommended middle stage.
 
 The Skill makes the explicit output or development content its hard ceiling; a local slice includes only necessary surrounding context. For an implementation handoff it accounts for material UI/UX meaning through relevant surfaces/flows/regions/components/controls and applicable visual/content, state, interaction/feedback/motion, responsive/platform/input, accessibility and asset conditions, then subtracts only explicit selected-source coverage. It discovers current Open Design capabilities and assigns every considered resource a reasoned `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` disposition.
 
+High-fidelity/branded output, visual direction, typography/color/density, component visual treatment and production-style prototypes are style-bearing. If Design Authority is unconfigured or lacks one authored token source/direction, the Skill stops before project/run creation and tells the user to explicitly invoke `/design-system-authoring`; it never auto-initializes. Low-fidelity structure, IA/flow and semantics-only state studies remain non-fidelity. Style-bearing Open Design projects pass the adopted ID through `create_project.designSystem` and verify `get_project.designSystemId`.
+
 It commissions only the smallest sufficient set through structured MCP with bounded fallback. Repeated controls may map to one component family, one inspectable artifact may cover several needs and only unique/complex uncovered controls need dedicated studies. Static/default views do not imply unseen behavior. No prototype, low/high-fidelity pair, component board, Figma handoff, one-file-per-control rule, artifact count or directory is mandatory, and Tiny Context copies no provider prompt/template or catalogue. Designs carry user-visible interaction semantics, not sole ownership of business/data/permission/algorithmic rules.
 
-Exploration returns a visible scoped candidate after minimal sanity review. An implementation handoff adds provenance, explicit entry, declared coverage, limitations and a concise stable-key mapping from every material in-scope item to existing/generated Source or an explicit non-applicable/excluded/unresolved disposition; it is sufficient only when implementation need not invent a material user-visible choice inside scope. This mapping creates no pack, registry or acceptance authority. Selected-source preparation requires explicit human selection and immutable identity. Iteration stays task-local. A final consolidated accepted/rejected/unresolved delta may inform a separately owned proposal revision, but the Skill never edits that proposal, Context, `DESIGN.md`, production code or a Delivery Contract and creates no Design Authority.
+Exploration returns a visible scoped candidate after minimal sanity review. An implementation handoff adds provenance, binding, explicit entry, declared coverage, limitations and a concise stable-key mapping. Iteration keeps accepted/rejected/unresolved effects task-local. After explicit or delegated final selection, the Skill performs one consolidated idempotent reconciliation of accepted decisions into a writable initial proposal, or returns a complete revised proposal when conversation-only; it excludes rejected/unresolved choices and never edits a Source Plan, Context, `DESIGN.md`, production code or a Delivery Contract.
 
 Actual generation remains with configured Open Design/Product Design, Figma, image-generation, prototype or human systems. Their outputs enter the default Workflow or Long-Task as ordinary external Source. Candidates and inspiration authorize no fidelity. A selected exact target controls only its declared conditions and needs stable immutable identity before it can affect a `verification_input`. `context_uiux_design` performs downstream UI Authority Closure; implementation renders and diffs remain evidence rather than self-authorizing targets.
 
 Maintainers may set `TY_CONTEXT_OPEN_DESIGN_MCP_COMMAND` plus optional `TY_CONTEXT_OPEN_DESIGN_MCP_ARGS_JSON` and run `npm run smoke:open-design` for an opt-in, read-only discovery smoke. Normal tests use a local mock MCP and do not depend on Open Design or nondeterministic output.
 
-### Optional Source Plan Authoring
-
-Use `/source-plan-authoring` for an explicitly requested initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. It accepts either one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments; a short instruction identifying their roles, the goal, reference authority and desired elaboration is sufficient.
-
-It produces one self-contained Markdown document with a complete input inventory, preserved direct requirements and traceable necessary derivations. Before comparative research or a material product, technical, architecture or provider selection, it asks a concise targeted question when an unknown user priority such as quality versus cost, speed, reliability, privacy, lock-in or operational burden could change the research scope, candidate set or recommendation; there is no fixed questionnaire and known preferences are not re-asked. Once that preference envelope is clear, it decides what research is needed and uses current authoritative or primary sources for external capability, price, quota, license, compatibility, region, security or support claims. A request to synthesize, refine, complete or use judgment then delegates plan-level authoring: each supported recommendation is recorded as `delegated` with its instruction, preference/evidence basis and exact meaning instead of triggering approval, including high-impact plan semantics. Real payment, contracting, production release, destructive production mutation, permission grants, sensitive-data transmission and required legal/security/human approval remain `EXT`; only conflicts, user-reserved choices, missing material preferences or cases with no defensible recommendation remain `DEC`/`decision_required`. Interactive products are expanded through every in-scope surface to material control level, including placement, behavior, validation, navigation, loading/empty/success/failure/recovery/permission feedback and accessibility. The plan retains semantic Outcome boundaries, stable keys/anchors, Runtime-exact Fact/Affected-Outcome `RISK` items, distinct `OBL`/`HINT` items and one observable scenario per `AC` with explicit accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys. Risk names are the ten Contract facts: use `data_migration`, split critical-path weak observability into `critical_user_path` plus `weak_observability`, and preserve `multi_repository_change` for Compiler rejection.
+### Retired Source Plan Compatibility
 
-It does not update Context, bind a repository, generate Delivery Contract YAML, execute implementation, create workflow state or claim completion. `HINT` is not a Material Source Item, and the Skill emits no `ty-source-item` markers. A Source Plan is Source, not a Contract Draft. The structure is optional; ordinary prose remains valid Long-Task Source.
+`/source-plan-authoring` is retained only as a compatibility pointer. `/long-task-workflow` now performs mixed-input inventory/synthesis, stable-key/control-level Source authoring, preference/research/delegation traceability and acceptance/risk completeness inside the same Goal before Contract mapping. Existing Source Plans remain ordinary Source; no standalone Source Plan handoff, schema, gate, state or second plan is created.
 
 ## Single-Goal Rolling Delivery
 
 The explicit Long-Task Workflow uses one platform-native Goal, one user-selected repository/workspace, one complete `long-task-delivery-v2` Contract and one Final Gate. Outcomes are independently decidable acceptance units; Delivery Set orchestration and top-level Contract splitting inside one selected delivery are retired.
 
-Contract authoring preserves stable Source keys/anchors where practical. If an unknown preference could materially change comparative research or selection, it asks before proceeding. Once the decision criteria are clear, a defensible recommended plan choice is recorded in real Source with its delegation, preference/evidence basis and exact meaning before Contract mapping; it is never added only in YAML. Plan delegation does not authorize a real high-risk external action, which remains an explicit external confirmation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue, while conflicting, user-reserved, missing-preference or unsupported new product semantics require `decision_required`. Missing recommended Source Plan structure alone never blocks authoring.
+Long-Task now makes raw/revised proposals, selected design resources and mixed attachments self-contained in real Source before Contract mapping, preserving complete input coverage, stable keys, control-level meaning, acceptance/risk and direct/derived/delegated/evidence-backed provenance. Unknown decision-changing preferences still trigger one targeted clarification; defensible recommendations are written into real Source rather than hidden in YAML, while high-risk actions remain external confirmations. Legacy Source Plan structure never blocks authoring.
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` revises the same Draft across repository/Context reads and Preflight repairs; a complete Contract need not fit one response. Integrated authoring keeps repository evidence and findings attached to the same object and avoids a second handoff, plan, authority or Receipt. There is no standalone Contract Draft Skill or Authoring State.
 
@@ -312,7 +321,7 @@ ty-context sync
 
 Version 0.6.0 retires V1 and the repo-local Hook. Development-period V2 Active Authority, Progress and Receipts are not migrated; doctor reports `manual_required`, and the operator upgrades the Contract before forming a new Authority Lock. Invalid JSON, marker/record mismatch or stale lock is never guessed from damaged record paths; doctor reports the explicit contained cleanup command `ty-context long-task abandon <workdir> --force-corrupt-state`.
 
-Version 0.6.0 keeps the `long-task-delivery-v2` name and physical `outcome_files` parser form while defining the first public V2 semantics; development-period Drafts receive explicit migration diagnostics. Optional Source Plan authoring and the additive execution-model checkpoint add no Schema, CLI, Preflight, Validator, Receipt, Authority or persisted model-routing state. Preflight and direct Compile share one activation-safety validator, so readable `criterion` text and all other completion-safety rules remain mandatory when Preflight is skipped.
+Version 0.6.0 keeps the `long-task-delivery-v2` name and physical `outcome_files` parser form while defining the first public V2 semantics; development-period Drafts receive explicit migration diagnostics. Its former optional Source Plan helper and the additive execution-model checkpoint added no Schema, CLI, Preflight, Validator, Receipt, Authority or persisted model-routing state. Current releases integrate Source authoring into `/long-task-workflow` and keep the old entry only as a pointer. Preflight and direct Compile share one activation-safety validator.
 
 After updating the package, run `ty-context upgrade`. Use `ty-context upgrade --check` first when you need a read-only plan.
 
@@ -340,7 +349,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-The synchronized local preview tarball is named `project-tiny-context-harness-0.7.7.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.7.8.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -77,7 +77,7 @@ It does not launch or switch models, spawn agents, create branches or worktrees,
 2. **Workflow Contract** — Context-first default engineering behavior using the platform's internal plan; no required plan artifact.
 3. **Long-Task Workflow** — explicit Single-Goal Rolling Delivery with `long-task-delivery-v2`, compiled Claim Coverage and a verifier-owned Live Final Gate.
 
-The base managed set also provides `/design-resource-authoring`, an explicitly triggered thin commissioner for task-local Open Design resources rather than a generation engine or authority layer. The opt-in long-task profile additionally provides `/source-plan-authoring`, an upstream Source-quality helper.
+The base managed set also provides two explicitly triggered Open Design adapters: `/design-system-authoring` generates/selects/adopts project Design Authority at cold start, while `/design-resource-authoring` commissions task-local resources. The opt-in long-task profile provides `/long-task-workflow`; `/source-plan-authoring` remains only as a retired compatibility pointer because Source-quality authoring now occurs inside the Long-Task lifecycle.
 
 Default profiles are `core-portable` and `workflow-default`. Enable the opt-in profile with:
 
@@ -85,7 +85,16 @@ Default profiles are `core-portable` and `workflow-default`. Enable the opt-in p
 ty-context enable long-task
 ```
 
-This additionally installs `/source-plan-authoring`, `/long-task-workflow` and the completion Hook. `/design-resource-authoring` is already in the base managed set. Tiny Context does not install Open Design, an agent runtime, model worker, scheduler, Git orchestration assets or another design-generation runtime.
+This additionally installs `/long-task-workflow`, the `/source-plan-authoring` compatibility pointer and the completion Hook. `/design-system-authoring` and `/design-resource-authoring` are already in the base managed set. Tiny Context does not install Open Design, an agent runtime, model worker, scheduler, Git orchestration assets or another design-generation runtime.
+
+## Recommended Usage
+
+Start from an initial proposal: either a concise product intent or a detailed proposal authored elsewhere, including Web GPT. For UI work that needs standalone design resources:
+
+- **Long delivery:** initial proposal → explicitly initialize/adopt a design system with `/design-system-authoring` when the project has none → `/design-resource-authoring` generates/selects resources and reconciles accepted decisions into the initial proposal once → pass the revised proposal plus selected immutable resources to `/long-task-workflow`. Its integrated Source authoring and Contract Draft authoring continue in the same native Goal.
+- **Non-long delivery:** the same initial-proposal/design-resource sequence → give the revised proposal plus selected immutable resources directly to Codex's current native Goal under the default Workflow Contract.
+
+The design-system step is user-invoked, normally at project cold start; no command or downstream Skill runs it automatically. `/design-resource-authoring` gates only style-bearing work when Design Authority is unconfigured. Low-fidelity structure, IA/flow and semantics-only state studies remain available without that gate. A legacy Source Plan is accepted as ordinary input, but it is no longer a recommended intermediate service.
 
 ## Try It In 60 Seconds
 
@@ -137,7 +146,7 @@ The smoke packs the local workspace, installs it into a disposable repo and vali
 
 ```sh
 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.7.7.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.8.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -214,7 +223,7 @@ For material UI, **UI Authority Closure** reconciles each stable surface/control
 
 ### Visual Delivery Guidance
 
-The default Workflow now performs UI Authority Closure and a conditional Design Authority Check before material production UI: new/redesigned screens, primary layout/navigation/theme/component-system work, high-fidelity implementation and substantial visual polish. It reads the owning Surface/Screen/Control Context, `DESIGN.md`, one authored exact token source/generation direction and selected design references. Each reference is `exact-target`, `constraint` or `inspiration`; an unconfigured starter, candidate, style-only prose or inspiration does not authorize invented production layout. A configured project visual system is not a claim that every page is implementation-ready. Explicit standalone resource generation routes to `/design-resource-authoring`, which commissions external Open Design capabilities without adopting authority; downstream durable adoption/repair routes through `context_uiux_design`. Ordinary implementation with sufficient authority, local style fixes and throwaway prototypes remain lightweight.
+The default Workflow now performs UI Authority Closure and a conditional Design Authority Check before material production UI: new/redesigned screens, primary layout/navigation/theme/component-system work, high-fidelity implementation and substantial visual polish. It reads the owning Surface/Screen/Control Context, `DESIGN.md`, one authored exact token source/generation direction and selected design references. Each reference is `exact-target`, `constraint` or `inspiration`; an unconfigured starter, candidate, style-only prose or inspiration does not authorize invented production layout. A configured project visual system is not a claim that every page is implementation-ready. Explicit project design-system initialization/adoption routes to `/design-system-authoring`; explicit standalone resource generation routes to `/design-resource-authoring`, which commissions external Open Design capabilities without adopting authority. The consuming workflow and `context_uiux_design` still own UI Authority Closure and later durable repairs outside design-system cold-start/adoption. Ordinary implementation with sufficient authority, local style fixes and throwaway prototypes remain lightweight.
 
 For material work, `context_uiux_design` keeps a task-local risk-proportional Visual Coverage Set across production surfaces/components, viewports, themes/modes, states, content stress and accessibility/motion conditions. Durable surface/interaction facts remain in `project_context/**`; durable visual semantics and the design-reference registry remain in `DESIGN.md`; versioned targets stay at project-native paths. `context_development_engineer` binds that intent to production routes and reports only combinations actually rendered and checked. An implementation screenshot cannot become its own target.
 
@@ -224,40 +233,31 @@ Combined design-and-implementation work may author candidates in ordinary Outcom
 
 `ty-context doctor` keeps its compatible `missing | unconfigured | configured` project-level status and adds advisory Design Authority Index, token-source and classified-reference signals. It explicitly does not infer surface implementation readiness; that requires the owning Screen/Control meaning, selected target/constraints and project-owned verification.
 
+### Explicit Design System Authoring
+
+Use `/design-system-authoring` only when the user explicitly asks to initialize, generate, select, adopt, replace or repair the project design system/design style. Installation makes the cold-start capability available but never runs it automatically. The Skill discovers live Open Design MCP resources/tools, feature-detects design-system lifecycle methods and, when the current MCP exposes design systems only as resources, uses the same installed Open Design daemon's official generation/revision/accept API. It never copies provider prompts or pretends daemon generation is an MCP tool.
+
+Generation produces candidates. Explicit human selection—or explicit delegated selection with known criteria—precedes adoption. The selected system is reconciled into canonical project `DESIGN.md`, exactly one authored exact-value token source/generation direction and only the owning durable surface/interaction Context. Open Design provider ID/revision/digest and project binding are synchronization provenance, not a second authority. Provider success, artifact readiness, selection, authority adoption and `get_project.designSystemId` binding verification are reported separately.
+
 ### Optional Design Resource Authoring
 
-Use `/design-resource-authoring` only when explicitly asking to generate, iterate or prepare standalone design resources, prepare the design resources for a named development scope, or use Open Design. Inputs may be raw notes or an initial proposal, product/technical plans, a specialized visual brief, screenshots, existing resources or an optional Source Plan. Source Plan authoring is not a prerequisite: both Skills can consume raw inputs independently and neither invokes the other.
+Use `/design-resource-authoring` only when explicitly asking to generate, iterate or prepare standalone design resources, prepare the design resources for a named development scope, or use Open Design. Inputs may be raw notes or an initial proposal, product/technical plans, a specialized visual brief, screenshots, existing resources or a legacy Source Plan. A standalone Source Plan is not a prerequisite or recommended middle stage.
 
 The Skill fixes the requested output or development content as a hard scope ceiling. A partial feature includes only the surrounding context needed to place it; broad background never expands generation to the rest of the page or product. For an implementation handoff, the Skill accounts for material UI/UX meaning from surface/flow structure through relevant regions and controls: visual/content treatment, component anatomy and variants, static/dynamic states, interaction/feedback/recovery/motion, responsive/platform/input behavior, accessibility and necessary assets. It subtracts only coverage explicitly supplied by selected existing Source, then discovers current Open Design agents/models, functional skills, rendering templates, design systems, plugins and export routes and gives every considered resource a reasoned `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` disposition.
 
+It first classifies the commission. High-fidelity/branded output, visual direction, typography/color/density, component visual treatment and production-style prototypes are style-bearing: if `DESIGN.md` is unconfigured or lacks one authored token source/direction, the Skill stops before provider project/run creation and tells the user to explicitly invoke `/design-system-authoring`; it never initializes authority itself. Low-fidelity structure, IA/flow topology and semantics-only behavior/state studies remain non-fidelity. For style-bearing work, the Open Design MCP project is created or checked with `create_project.designSystem`, and `get_project.designSystemId` must match the adopted provider ID.
+
 It commissions only the smallest sufficient set through structured MCP, with bounded CLI/daemon and UI fallback. One page/prototype or component-family workbench may cover many items when its conditions are addressable and inspectable; repeated controls map to shared variants, while unique or complex uncovered controls may need dedicated state/interaction studies. A static/default frame never silently covers unseen state, interaction, motion, responsiveness or accessibility. A prototype, low/high-fidelity pair, component board, Figma handoff, one-file-per-control rule, variant count or directory is never universally required, and Tiny Context never copies Open Design prompts/templates or vendors a provider catalogue. Designs may express user-visible interaction semantics and the presentation of product rules, but business/data/permission/algorithmic rules remain owned by product/technical Source.
 
-Exploration returns the requested visible candidate after minimal sanity review. An implementation handoff adds project/run/capability provenance, explicit entry, declared coverage, known limitations and a concise stable-key mapping from each material in-scope surface/flow/region/component/control condition to existing/generated Source or a non-applicable/excluded/unresolved disposition. The mapping is not a required pack, registry or acceptance result; handoff authoring is sufficient only when no material user-visible choice inside the explicit scope is silently left for implementation to invent. Selected-source preparation requires a real human selection basis and immutable hash or approved snapshot, but still creates no Design Authority. Candidate iterations stay task-local; the Skill may return one final consolidated accepted/rejected/unresolved delta for a separately owned proposal revision, but never edits the proposal, `project_context/**`, `DESIGN.md`, production code or a Delivery Contract.
+Exploration returns the requested visible candidate after minimal sanity review. An implementation handoff adds project/run/capability/design-system provenance, explicit entry, declared coverage, known limitations and a concise stable-key mapping from each material in-scope surface/flow/region/component/control condition to existing/generated Source or a non-applicable/excluded/unresolved disposition. The mapping is not a required pack, registry or acceptance result. During iteration, accepted/rejected/unresolved effects remain in a task-local delta buffer. After explicit or delegated final selection, the Skill performs one consolidated idempotent reconciliation of accepted decisions into the writable initial proposal—or returns the complete revised proposal when conversation-only—while excluding rejected/unresolved choices. It never edits a Source Plan, `project_context/**`, `DESIGN.md`, production code or a Delivery Contract.
 
 The actual generation remains with configured Open Design/Product Design, Figma, image-generation, prototype or human systems. Their outputs enter the default Workflow or Long-Task as ordinary external Source. Candidates and inspiration authorize no fidelity. A selected exact target controls only its declared surface/viewport/mode/state/content conditions and needs stable immutable identity before it can affect a `verification_input`. `context_uiux_design` performs downstream UI Authority Closure and adopts only durable facts into Context/`DESIGN.md`; implementation renders and diffs remain evidence artifacts rather than self-authorizing targets.
 
 Maintainers may set `TY_CONTEXT_OPEN_DESIGN_MCP_COMMAND` plus optional `TY_CONTEXT_OPEN_DESIGN_MCP_ARGS_JSON` and run `npm run smoke:open-design` for an opt-in, read-only discovery smoke. Normal tests use a local mock MCP and never require Open Design, login, paid access or nondeterministic design output.
 
-### Optional Source Plan Authoring
-
-Use `/source-plan-authoring` when explicitly asking for an initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. The input may be one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments. A short request that identifies the artifact roles, product goal, reference authority and desired elaboration is enough; no fixed intake questionnaire or pre-normalized outline is required.
-
-It outputs one self-contained Markdown Source Plan that:
-
-- inventories every supplied artifact, inspects all material pages/frames/screens and records coverage gaps instead of silently sampling;
-- preserves direct requirements and their qualifiers;
-- marks necessary derivations and cites what they derive from;
-- before comparative research or a material product, technical, architecture or provider selection, asks a concise targeted question when an unknown user priority such as quality versus cost, speed, reliability, privacy, lock-in or operational burden could change the research scope, candidate set or recommendation; it does not re-ask known preferences or interrupt minor reversible choices;
-- after the preference envelope is clear, decides what research is needed, uses current authoritative or primary sources for external capability/pricing/quota/license/compatibility/region/security/support claims, and treats a request to synthesize, refine, complete or use judgment as plan-level delegation: one supported recommendation is recorded as `delegated` with its instruction, preference/evidence basis and exact meaning instead of asking for approval, including high-impact plan semantics; real payment, contracting, production release, destructive production mutation, permission grants, sensitive-data transmission and required legal/security/human approval remain `EXT`, while only conflicts, user-reserved choices, missing material preferences or cases with no defensible recommendation remain `DEC`/`decision_required`;
-- splits Outcomes only by independently decidable observable results;
-- uses stable semantic keys and explicit anchors for important Source items;
-- separates mandatory `OBL` obligations from advisory `HINT` suggestions;
-- for interactive products, inventories every in-scope surface and material control, then independently records its surface/region/type/label, placement, task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility fields;
-- uses `NCOMP` for explicit results that must not count as completion;
-- states each `RISK` Fact, one Affected Outcome, Basis and Consequence, or emits `DEC` when the pair is unknown; Fact is exactly one of `public_api_or_schema_change`, `persistent_data_change`, `data_migration`, `security_boundary_change`, `permission_boundary_change`, `irreversible_external_effect`, `critical_user_path`, `full_population_operation`, `multi_repository_change` or `weak_observability`;
-- writes one Given/When/Then scenario per `AC`, names its accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys, hides no new requirement in AC text and reports whether the document is ready for Contract authoring.
+### Retired Source Plan Compatibility
 
-It does not update project Context, bind real repository owners/paths/runners, generate Delivery Contract YAML, run implementation, create workflow state or claim completion. `HINT` is not a Material Source Item, and Source Plan authoring emits no `ty-source-item` markers; repository-aware Long-Task authoring inserts markers later. A Source Plan is Source, not a Contract Draft. Its structure is an authoring fast path, not a required input protocol; ordinary prose plans remain valid Long-Task Source.
+`/source-plan-authoring` remains installed with the long-task profile only as a compatibility pointer. `/long-task-workflow` now performs complete input inventory, mixed-input synthesis/refinement, stable-key and control-level authoring, preference/research/delegation traceability and acceptance/risk completeness directly in the same Goal before Contract mapping. A legacy Source Plan remains valid ordinary Source, but no separate Source Plan handoff, schema, gate, state or second plan is created.
 
 ## Single-Goal Rolling Delivery
 
@@ -274,7 +274,7 @@ Use `/long-task-workflow` only when explicitly requested or when the current wor
 - a complete Final Gate on one current snapshot;
 - a Stop Hook that rejects stale completion.
 
-Long-Task Contract authoring preserves stable Source keys and anchors where practical. If an unknown preference could materially change comparative research or selection, it asks before proceeding. Once the decision criteria are clear, a defensible recommended plan choice is written into real Source with its delegation, preference/evidence basis and exact meaning before Contract mapping; it is never hidden only in YAML. That plan delegation does not authorize a real high-risk external action, which remains an explicit external confirmation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue; conflicting, user-reserved, missing-preference or unsupported new product semantics remain `decision_required`. Missing recommended Source Plan structure never blocks authoring, but the marker-only Material Source Item enumeration required for activation does.
+Long-Task first makes raw/revised proposals, selected design resources and mixed attachments self-contained in real Source: complete input inventory, stable keys, control-level meaning, acceptance/risk coverage and direct/derived/delegated/evidence-backed provenance now belong inside this workflow. If an unknown preference could materially change comparative research or selection, it asks before proceeding. Once criteria are clear, a defensible recommendation is written into real Source with its delegation, preference/evidence basis and exact meaning before Contract mapping; it is never hidden only in YAML. High-risk action remains an external confirmation. Legacy Source Plan structure never blocks authoring, but marker-only Material Source Item enumeration does.
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` keeps revising that same Draft across repository/Context reads and Preflight repair rounds; it does not require one response to produce a complete Contract. Draft authoring is integrated because repository bindings and verification inputs need real evidence, Preflight findings must feed back into the same object, and a separate handoff would risk lost meaning or a second plan/authority. No standalone Contract Draft Skill, Draft Receipt or Authoring State exists.
 
@@ -483,7 +483,7 @@ Final Gate may run only Contract-declared verification commands and never produc
 
 Version 0.6.0 retires the V1 schema/runtime and repo-local Hook. Enable, disable and upgrade remove only exact Tiny Context managed Hook entries. Relocated package-owned absolute commands are recognized only when known managed status and package layout match; similar-name user Hooks remain. Upgrade never imports V1 progress or Receipts into V2 authority. Delivery Set, `composite-campaign` and `composite-long-task` commands are non-executing tombstones.
 
-Version 0.6.0 defines the first public V2 semantics while retaining the `long-task-delivery-v2` schema name and physical `outcome_files` parser form. Optional Source Plan authoring adds no Schema, CLI, Preflight, Compile, Validator, Receipt, Authority or state. Preflight and direct Compile use one activation-safety kernel.
+Version 0.6.0 defined the first public V2 semantics while retaining the `long-task-delivery-v2` schema name and physical `outcome_files` parser form. It introduced the former optional Source Plan helper without adding Schema, CLI, Preflight, Compile, Validator, Receipt, Authority or state. Current releases integrate those Source-authoring semantics into `/long-task-workflow` and retain the old Skill only as a compatibility pointer. Preflight and direct Compile use one activation-safety kernel.
 
 Version 0.7.2 strengthens that same V2 authority with ordered Stages, bounded required targets/root entrypoints, explicit success/degradation journeys and scenarios, typed Evidence Capabilities, typed external impact, risk-proportional Product Conformance and terminal target/Stage projections. An older V2 Contract missing those fields reports the indexed manual migration `long-task-v2-semantic-drift-authority`; re-author the missing meaning from Source. Upgrade never infers those semantics or imports old Progress/Receipts as passing evidence.
 
@@ -518,7 +518,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.7.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.8.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -38,13 +38,22 @@ npx --yes project-tiny-context-harness ty-context sync
 
 `upgrade` 先执行安全迁移再同步；资产刷新不会推断或覆盖用户编写的 Context、Source、Delivery Contract 或历史文件。
 
-默认 Profile 是 `core-portable` 与 `workflow-default`，基础 managed set 已包含 `/design-resource-authoring`。显式启用长程能力：
+默认 Profile 是 `core-portable` 与 `workflow-default`，基础 managed set 已包含显式调用的 `/design-system-authoring` 与 `/design-resource-authoring`。显式启用长程能力：
 
 ```powershell
 ty-context enable long-task
 ```
 
-启用长程能力会额外安装 `/source-plan-authoring`、`/long-task-workflow` 与完成 Hook；`ty-context disable long-task` 只移除这些 Long-Task-owned surfaces，并保留基础 `/design-resource-authoring`。Tiny Context 不安装 Open Design、模型 Worker、Agent runtime、调度器、Git 编排资产或其他设计生成 runtime。
+启用长程能力会额外安装 `/long-task-workflow`、退役兼容指引 `/source-plan-authoring` 与完成 Hook；`ty-context disable long-task` 只移除这些 Long-Task-owned surfaces，并保留两个基础设计 Skill。Tiny Context 不安装 Open Design、模型 Worker、Agent runtime、调度器、Git 编排资产或其他设计生成 runtime。
+
+## 推荐用法
+
+初始输入可以是一段产品意图，也可以是 Web GPT 等外部服务给出的详细初始方案。涉及独立设计资源时：
+
+- **长程任务：** 初始方案 → 项目尚无设计系统时由用户显式调用 `/design-system-authoring` 生成、选择并采纳 → `/design-resource-authoring` 生成/选择资源，并在方向定稿后把接受的变更一次性回改初始方案 → 把“修订后的初始方案 + 选定且身份稳定的设计资源”交给 `/long-task-workflow`；Source 补全与 Contract Draft Authoring 在同一个原生 Goal 内继续。
+- **非长程任务：** 使用同样的初始方案与设计资源步骤 → 把“修订后的初始方案 + 选定设计资源”直接交给 Codex 当前原生 Goal，按默认 Workflow Contract 执行。
+
+设计系统通常在项目冷启动时确定，但该 Skill 只由用户调用，`init`、`sync` 与下游 Skill 都不会自动执行。`/design-resource-authoring` 只对高保真、品牌化、视觉处理等 style-bearing 资源设门禁；低保真结构、IA/流程与纯语义状态研究不受此门禁。旧 Source Plan 仍可作为普通输入，但不再是推荐中间服务。
 
 ## Minimal Context 与默认工作流
 
@@ -111,7 +120,7 @@ material UI 在实现前执行 **UI Authority Closure**：每个稳定 surface/c
 
 ### 视觉交付指导
 
-默认 Workflow 现在会在 material production UI 前执行 UI Authority Closure 和条件式 Design Authority Check，包括新建/重做页面、主要布局/导航/主题/组件体系、高保真实现和大幅 visual polish。它读取 owning Surface/Screen/Control Context、`DESIGN.md`、唯一 authored token source/generation direction 和选定设计引用。引用分为 `exact-target`、`constraint`、`inspiration`；未配置 starter、候选稿、只有风格文字或灵感图都不能授权 agent 自行发明生产布局；全局视觉系统 configured 也不等于每个页面 implementation-ready。明确的独立设计资源生成请求路由到 `/design-resource-authoring`，由它委托外部 Open Design 能力但不采纳权威；进入开发流程后的耐久权威采纳/修复路由到 `context_uiux_design`。已有充分权威的普通实现、局部样式修复和 throwaway prototype 仍保持轻量。
+默认 Workflow 现在会在 material production UI 前执行 UI Authority Closure 和条件式 Design Authority Check，包括新建/重做页面、主要布局/导航/主题/组件体系、高保真实现和大幅 visual polish。它读取 owning Surface/Screen/Control Context、`DESIGN.md`、唯一 authored token source/generation direction 和选定设计引用。引用分为 `exact-target`、`constraint`、`inspiration`；未配置 starter、候选稿、只有风格文字或灵感图都不能授权 agent 自行发明生产布局；全局视觉系统 configured 也不等于每个页面 implementation-ready。明确的项目设计系统初始化/采纳请求路由到 `/design-system-authoring`；明确的独立设计资源生成请求路由到 `/design-resource-authoring`，由它委托外部 Open Design 能力但不采纳权威。消费这些输入的开发 Workflow 与 `context_uiux_design` 仍负责 UI Authority Closure，以及设计系统冷启动/采纳之外的后续耐久修复。已有充分权威的普通实现、局部样式修复和 throwaway prototype 仍保持轻量。
 
 对 material 工作，`context_uiux_design` 在任务内部维护风险比例化的 Visual Coverage Set；耐久 surface/interaction 事实属于 `project_context/**`，耐久视觉语义和设计引用 registry 属于 `DESIGN.md`，versioned target 保留在项目原生路径。`context_development_engineer` 把这些意图绑定到生产组件/真实 route，只报告真正渲染和检查过的组合；实现截图不能成为它自己的目标。
 
@@ -121,40 +130,31 @@ combined design-and-implementation 可以先用普通 Outcome/Stage 生成候选
 
 `ty-context doctor` 保留兼容的项目级 `missing | unconfigured | configured` 状态，并增加 Design Authority Index、token source 和已分类 reference 的 advisory 信号。它明确不推断页面实现就绪；material surface 仍需 owning Screen/Control meaning、selected target/constraints 与项目自己的验证路径。
 
+### 显式 Design System Authoring
+
+只有用户明确要求初始化、生成、选择、采纳、替换或修复项目设计系统/设计风格时，才使用 `/design-system-authoring`。安装只让冷启动能力可用，不会自动运行。Skill 会发现 Open Design 当前真实 MCP resource/tool；若当前版本只通过 MCP 读取设计系统而没有创建 tool，则使用同一个已安装 Open Design daemon 的官方 generation/revision/accept API，不复制 provider prompt，也不把 daemon 调用冒充 MCP。
+
+生成结果先是候选。必须有明确人工选择，或用户明确委托且选择标准已知，才会采纳到项目 canonical `DESIGN.md`、唯一 authored exact-value token source/generation direction，以及真正拥有 surface/interaction 耐久事实的 Context。Open Design provider ID、revision、digest 与 project binding 只是同步 provenance，不是第二权威。provider 执行成功、artifact ready、selected、authority adopted 与 `get_project.designSystemId` binding verified 会分开报告。
+
 ### 可选 Design Resource Authoring
 
-只有在用户明确要求生成、迭代、准备独立设计资源、为一段明确开发内容准备设计资源或使用 Open Design 时，才使用 `/design-resource-authoring`。输入可以是零散笔记或初版方案、产品/技术方案、专门视觉 brief、截图、已有资源或可选 Source Plan。Source Plan 不是前置项：两个 Skill 都可以独立读取原始输入，互不调用。
+只有在用户明确要求生成、迭代、准备独立设计资源、为一段明确开发内容准备设计资源或使用 Open Design 时，才使用 `/design-resource-authoring`。输入可以是零散笔记或初始方案、产品/技术方案、专门视觉 brief、截图、已有资源或历史 Source Plan。独立 Source Plan 不是前置项，也不再是推荐中间步骤。
 
 Skill 把明确输出或开发内容当作硬 scope ceiling。局部功能只可带上定位它所需的周边上下文；再丰富的背景也不能把生成范围扩成页面其余部分或整个产品。面向实现 handoff 时，Skill 要覆盖范围内所有材料性的 UI/UX 含义：surface/flow 与 region 结构、视觉和内容呈现、控件结构/尺寸/变体、静态与动态状态、交互/反馈/恢复/动效、响应式/平台/输入方式、可访问性及必要资产；先扣除已有 selected Source 明确覆盖的条件，再发现 Open Design 当前 agent/model、functional skill、rendering template、design system、plugin 与 export route，并把每种候选资源说明为 `selected`、`optional`、`not-needed`、`unavailable` 或 `decision-required`。
 
+Skill 会先分类 visual-style dependency。高保真/品牌化输出、视觉方向、字体/颜色/密度、组件视觉处理和 production-style prototype 属于 style-bearing：若 `DESIGN.md` 未配置或没有唯一 authored token source/direction，Skill 必须在创建 provider project/run 前停下，并提示用户显式调用 `/design-system-authoring`，绝不自动初始化。低保真结构、IA/flow topology 和纯语义 behavior/state study 属于 non-fidelity。style-bearing 工作必须把已采纳 provider ID 传给 MCP `create_project.designSystem`，并用 `get_project.designSystemId` 验证一致。
+
 Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）委托最小充分资源集。一个可定位、可检查的大页面稿、原型或组件族 workbench 可以覆盖多个事项；重复控件映射到共享变体，只有仍缺少材料性含义的独特/复杂控件才需要专门状态或交互稿。静态/default 页面不能自动代表没展示的动态状态、交互、动效、响应式或可访问性。原型、低/高保真组合、组件板、Figma handoff、逐控件一份稿、变体数量和目录都不是全局必选项。设计资源可以表达用户可感知的交互语义和产品规则的呈现方式，但业务、数据、权限和算法逻辑仍由产品/技术 Source 所有。Tiny Context 不复制 Open Design 的 prompt/template，也不内置 provider catalogue。
 
-探索模式只做最小完整性检查并尽快展示指定候选；面向实现的 handoff 还要增加 project/run/capability provenance、明确 entry、声明覆盖、已知限制，以及每个材料性 surface/flow/region/component/control 条件到已有/新资源或不适用/范围排除/未决项的简洁稳定 Key 映射。该映射不是必选 pack、registry 或验收结果；只有范围内不再有需要开发者自行发明的材料性用户可感知设计决策时，authoring handoff 才算充分。selected-source preparation 要求真实人工选择依据和不可变 hash 或已批准 snapshot，但仍不产生 Design Authority。候选迭代保持任务内；Skill 可以在方向最终确定后返回一份合并的 accepted/rejected/unresolved 差异供独立方案步骤处理，但不会修改初版方案、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
+探索模式只做最小完整性检查并尽快展示指定候选；面向实现的 handoff 还要增加 project/run/capability/design-system provenance、明确 entry、声明覆盖、已知限制，以及每个材料性 surface/flow/region/component/control 条件到已有/新资源或不适用/范围排除/未决项的简洁稳定 Key 映射。候选迭代期间，accepted/rejected/unresolved 影响只存在任务内 delta buffer。明确或受托最终选择后，Skill 只做一次合并、幂等的初始方案回改：有可写文件就更新该方案，只有对话输入就返回完整修订方案；拒绝和未决项不会写成需求。它不会修改 Source Plan、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
 
 实际生成仍由已配置的 Open Design/Product Design、Figma、图片生成、原型工具或人工设计流程负责。这些输出以普通 external Source 进入默认 Workflow 或 Long-Task。candidate 与 inspiration 不授权 fidelity；selected exact target 只控制其声明的 surface/viewport/mode/state/content 条件，并且需要稳定不可变身份后才能成为影响验收的 `verification_input`。`context_uiux_design` 在下游执行 UI Authority Closure，只把耐久事实采纳到 Context/`DESIGN.md`；实现截图与 diff 仍是证据 artifact，不能自我授权为目标。
 
 维护者可以设置 `TY_CONTEXT_OPEN_DESIGN_MCP_COMMAND` 与可选 `TY_CONTEXT_OPEN_DESIGN_MCP_ARGS_JSON`，运行 `npm run smoke:open-design` 做显式启用、只读的 discovery smoke。正常测试使用本地 mock MCP，不依赖 Open Design、登录、付费能力或不确定的设计输出。
 
-### 可选 Source Plan Authoring
-
-用户明确要求初版方案、源方案、方案源稿、Source Plan，或要求综合、细化、审计后续实现与 Contract Authoring 的 Source 时，使用 `/source-plan-authoring`。输入既可以是一份接近完成的方案，也可以只是目标，加上零散笔记、产品/技术文档、截图、图表等混合附件。用户只需说明附件角色、产品目标、参考资料是精确目标还是灵感，以及希望 Skill 细化即可；不需要先填固定问卷或整理统一大纲。
-
-它输出一份自包含 Markdown Source Plan：
-
-- 为每份附件建立 Input Inventory，完整检查有实质含义的页面、画面与屏幕，未读内容或覆盖缺口必须显式报告，不能静默抽样；
-- 保留直接要求及其限定条件；
-- 必要推导必须标记并写明 `Derived From`；
-- 在对比调研或实质性的产品、技术、架构、供应商选型前，先判断哪些用户取舍会改变调研范围、候选集或推荐；如果质量与性价比、交付速度、可靠性、隐私、供应商锁定、运维成本等关键偏好不明确，就先用简短、有针对性的问题询问用户，不重复询问已有偏好，也不打断推荐不会改变的局部可逆选择；
-- 偏好边界明确后，再决定是否以及如何调研；外部能力、价格、额度、许可、兼容性、区域、安全与支持等时效性事实使用当前权威或一手来源。用户要求综合、细化、补全或自行判断时，默认委托方案层决策：形成有依据的合理推荐后，直接标记为 `delegated` 并记录委托语句、偏好/证据依据和准确含义，高影响方案语义本身不再触发批准；真实付款/签约、生产发布、生产数据破坏性修改、实际授权、敏感数据外发及必要法务/安全/人工审批仍保留为 `EXT`，只有输入冲突、用户明确保留、关键偏好仍缺失或无法形成可靠推荐时才进入 `DEC`/`decision_required`；
-- Outcome 只按可独立判断的可观察结果拆分；
-- 重要 Source 项使用稳定语义 Key 与显式 Anchor；
-- 强制技术义务使用 `OBL`，非强制实现建议使用 `HINT`；
-- 对交互产品，先穷举范围内的 surface，再细化到每个实质控件，分别记录页面/区域/类型/文案、位置、任务、可见与可用条件、触发/输入/校验/默认值、交互/跳转，以及 Loading、Empty、Success、Failure、Recovery、Permission、Feedback 和 Accessibility；
-- 明确“不算完成”的 Source 含义使用 `NCOMP`；
-- 每个 `RISK` 明确 Fact、单个 Affected Outcome、Basis 与 Consequence，无法确定时进入 `DEC`；Fact 精确使用 Runtime 的十个名称：`public_api_or_schema_change`、`persistent_data_change`、`data_migration`、`security_boundary_change`、`permission_boundary_change`、`irreversible_external_effect`、`critical_user_path`、`full_population_operation`、`multi_repository_change`、`weak_observability`；
-- 每个 AC 只代表一个 Given/When/Then 可观察场景，显式列出对应 `REQ`/`CTRL`/`OBL`/`NCOMP` Key，不能首次偷渡新需求，并在文末报告是否已可交给 Contract Authoring。
+### 退役 Source Plan 兼容入口
 
-它不更新项目 Context，不绑定真实仓库 owner/path/runner，不生成 Delivery Contract YAML，不执行实现，不创建工作流状态，也不声明完成。`HINT` 不是 Material Source Item；Source Plan Skill 不输出 `ty-source-item` Marker，Marker 由后续 repository-aware Long-Task Authoring 插入。Source Plan 是 Source，不是 Contract Draft。推荐结构只是 Authoring Fast Path；普通 prose/Source Plan 或普通文本方案仍可直接作为 Long-Task Source。
+`/source-plan-authoring` 仅作为 long-task profile 的兼容指引保留。`/long-task-workflow` 已在同一个 Goal、同一个 Contract Draft 生命周期内负责完整 input inventory、混合输入综合/细化、稳定 Key、控件级语义、偏好/调研/委托溯源，以及 acceptance/risk 完整性。已有 Source Plan 仍是有效普通 Source，但不再创建独立 Source Plan handoff、Schema、Gate、State 或第二份计划。
 
 ## Single-Goal Rolling Delivery
 
@@ -171,7 +171,7 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 - Final Gate 在一个当前快照上重跑全部 Check；
 - Stop Hook 在结果 stale 时阻止完成。
 
-Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 Anchor。若未知偏好会实质改变对比调研或选型，必须先询问用户；决策标准明确后，有依据的推荐方案再把委托、偏好/证据依据和准确含义写入真实 Source，然后映射到 Contract，不能只藏在 YAML 中。这份方案委托不授权任何真实高危外部动作，高危动作继续作为显式 external confirmation。保持产品含义的结构分解和有真实证据的仓库绑定可以继续；输入冲突、用户明确保留、关键偏好缺失或没有可靠推荐的新产品语义仍进入 `decision_required`。缺少推荐 Source Plan 结构不构成阻塞，但激活前必须完成只插入标记、不改写原文的 Material Source Item 枚举。
+Long-Task 会先在同一流程内把原始/修订方案、选定设计资源和混合附件补成自包含真实 Source：完整 input inventory、稳定 Key、控件级含义、acceptance/risk，以及 direct/derived/delegated/evidence-backed 溯源都在 Contract 映射前完成。若未知偏好会实质改变调研或选型，必须先询问；标准明确后，有依据的推荐才写入真实 Source，不能只藏在 YAML。方案委托不授权真实高危外部动作；输入冲突、用户保留、偏好缺失或无可靠推荐仍为 `decision_required`。旧 Source Plan 结构不构成阻塞，但激活前必须完成 Material Source Item 标记。
 
 第一次正式 Compile 成功前，`delivery-contract.yaml` 是同一份非权威 Contract Draft。`/long-task-workflow` 可以跨多轮仓库/Context 读取和 Preflight 修复持续修改它，不要求一次响应生成完整 Contract。不存在单独 Contract Draft Skill、Draft Receipt 或 Authoring State。
 
@@ -191,7 +191,7 @@ Agent 此时在实现前只暂停一次，请用户选择：继续当前模型
 
 锁定后的修订分三类：机器可证明的单调证据增强和机械安全变化自动采用；如果唯一的受保护原因只是扩大 owner、expected-change 或 allowed-support path（可以同时带有安全的单调增强），就能用 `diagnose-revision` 在不切换 Authority 的前提下运行原 Active Authority 已有且未更换的 Check；产品/Source/Acceptance 语义变化、证明弱化、verifier 内容或 runner 变化、风险上升只给摘要，不运行候选，风险降级则直接拒绝。滚动实现遇阻本身不是 External Confirmation，也不允许删除机器可验证范围；真正的范围变化必须先成为 marked Source。诊断结果不是 Progress 或 acceptance，也不会写 pending/approval、cache、Receipt 或 marker。相关修改只在同一份 `delivery-contract.yaml` 中累计，最终由一次 `compile --revise` 生成精确 hash 与包含语义字段、Source/Product Claim 缩减、proof 缩减和 external-confirmation key 的短摘要；`status`/`resume` 投影同一个待批决策。批准并原子采用后返回 `delivery_completed_by_this_event: false`，旧证据失效并回到滚动实现或修复，完整 Final Gate 仍必须重跑。
 
-Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和阶段路由，Contract Authoring、Evidence Design 与 Authority Lifecycle 细节只在对应阶段读取一层 reference。这只是指令组织，不产生第二权威。
+Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和阶段路由；Source Authoring、Contract Authoring、Evidence Design 与 Authority Lifecycle 细节只在对应阶段读取一层 reference。这只是指令组织，不产生第二权威。
 
 Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察、判断、纵向闭环和定向验证的结果拆分，使当前 Goal 能缩小 dependency-ready 工作集、定向验证、定位失败、恢复 finding 并精确失效旧局部结果。`depends_on` 只表示 acceptance readiness。每个 Outcome 属于一个有序 Stage；Stage gate 传递依赖同 Stage 其余 Outcome，后续 Stage 依赖前置 gate。Rolling Frontier 和 Stage 状态都由普通 Outcome Progress 临时派生；Outcome 不是 Worker、scheduler task、queue 或并行单元，Stage 也没有 Receipt 或第二个 Gate。Outcome 拆分执行和诊断，不拆分完成权威，因此最终仍必须在当前最终快照运行一次完整 Final Gate。
 

package/assets/agents/AGENTS_CORE.md

@@ -10,14 +10,14 @@ Unless an active Long-Task binding exists:
 
 1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
 2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
-3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes; Product Surface Contracts own cross-surface interfaces and optional on-demand Screen Contracts use existing area/subdomain/contract/verification roles for deeper screen/control facts. Before material production UI implementation, reconcile each affected stable surface/control/target key as Context-covered, requiring a Context update, task-local, out of scope or decision-required, then read `DESIGN.md`, its token source and referenced design targets. An unconfigured starter, candidate, style-only guidance or inspiration does not authorize invented production layout; only a selected exact/constraint target with adequate declared coverage authorizes fidelity. For an explicit standalone request to generate or iterate design resources, `design-resource-authoring` keeps the requested output/development content as the hard ceiling and may commission the smallest sufficient set from live Open Design capabilities; an implementation handoff covers material in-scope UI/UX meaning through relevant controls without requiring one artifact per control or changing Context, code or Contract. Its output and other externally authored resources remain ordinary Source until this workflow uses `context_uiux_design` when needed to adopt or repair durable Design Authority. Local style fixes and explicit non-fidelity prototypes remain lightweight.
+3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes; Product Surface Contracts own cross-surface interfaces and optional on-demand Screen Contracts use existing area/subdomain/contract/verification roles for deeper screen/control facts. Before material production UI implementation, reconcile each affected stable surface/control/target key as Context-covered, requiring a Context update, task-local, out of scope or decision-required, then read `DESIGN.md`, its token source and referenced design targets. An unconfigured starter, candidate, style-only guidance or inspiration does not authorize invented production layout; only a selected exact/constraint target with adequate declared coverage authorizes fidelity. `design-system-authoring` is an explicit-only cold-start/repair capability that uses Open Design to generate/select/adopt project Design Authority; never infer or auto-run it. For an explicit standalone request to generate or iterate resources, `design-resource-authoring` keeps the requested output/development content as the hard ceiling. Style-bearing work stops on unconfigured Design Authority and points to the explicit design-system Skill; non-fidelity work remains lightweight. Configured style-bearing Open Design projects bind and verify the adopted provider design-system ID. After final selection, design-resource authoring may reconcile accepted decisions into the initial proposal exactly once, but it never changes Context, `DESIGN.md`, a Source Plan, code or Contract. Its resources remain ordinary Source until the consuming workflow adopts durable meaning.
 4. Decide exactly one `Context Delta: none|required`. Update owning Context before code when durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment changes. Local fixes preserving durable semantics are `none`.
 5. Use the agent/platform internal plan. For high-risk work keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing and maintenance questions, not artifacts or extra deltas.
 6. Implement precisely, run project-owned verification, perform Contract Conformance and a Context drift check, then report implementation, verification, Context status and blockers.
 
 The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or completion proof. The bounded Context search creates no index, cache, state or second authority.
 
-Externally authored design resources such as Figma frames, images, prototypes, token exports and component specifications are ordinary Source. Their authoring does not update `project_context/**` or `DESIGN.md`, edit production implementation, create a Delivery Contract or claim acceptance. The consuming workflow owns UI Authority Closure, `Context Delta`, durable adoption, implementation and project verification; candidates authorize no fidelity, while selected targets control only their declared surface/viewport/mode/state coverage.
+Externally authored design resources such as Figma frames, images, prototypes and component specifications are ordinary Source. Resource authoring may reconcile a selected direction into the initial proposal once, but it does not update `project_context/**` or `DESIGN.md`, edit a Source Plan/Contract/production implementation or claim acceptance. Explicit `design-system-authoring` separately adopts a selected Open Design system into canonical `DESIGN.md`, one token source/direction and owning Context. The consuming development workflow still owns UI Authority Closure, implementation and verification; candidates authorize no fidelity.
 
 For external product, architecture, technical or acceptance sources, internally classify every material constraint as covered by Context, requiring a Context update, task-local, explicitly out of scope or requiring a genuine user decision. Conformance must confirm controlling Context reached the correct modules, surfaces, APIs, state machines and verification paths without forbidden shortcuts or duplicate authority.
 
@@ -29,7 +29,7 @@ Do not infer long-task mode from duration, complexity, file count or agent prefe
 2. Explicit `/long-task-workflow` authors or resumes exactly one complete `long-task-delivery-v2` Contract for the selected delivery.
 3. `/normal-long-task` is a retirement pointer. Otherwise remain on the default Workflow Contract, even when work is long.
 
-Contract Draft authoring belongs inside `long-task-workflow`: continuously revise the same non-authoritative `delivery-contract.yaml` until the first successful formal Compile creates Authority Lock. An optional Source Plan and externally authored design resources are ordinary upstream Source guidance, not a Contract Draft or required input protocol. Candidate design resources authorize no fidelity Claim; selected targets and acceptance-affecting resources enter real marked Source and existing verification inputs, and after Authority Lock use protected revision.
+Source-quality authoring and Contract Draft authoring belong inside `long-task-workflow`: inventory and refine raw/revised proposals, selected design resources and mixed attachments into self-contained real Source, then continuously revise the same non-authoritative `delivery-contract.yaml` until formal Compile creates Authority Lock. No standalone Source Plan handoff is required; a legacy Source Plan remains ordinary input. Candidate resources authorize no fidelity Claim; selected targets enter marked Source and existing verification inputs, and after Authority Lock use protected revision.
 
 The workflow uses one native Goal, one selected workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. Target profiles name required product targets and root runtimes; Checks declare Given/When journeys and all-of Evidence Capabilities. Stage/frontier state is derived from ordinary Progress and creates no second Gate, Receipt, scheduler or completion authority.
 
@@ -39,7 +39,7 @@ Before authoring, proof design or authority lifecycle work, read the phase-speci
 
 Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Required targets cannot substitute for one another; presence cannot prove behavior; success and degradation remain distinct; typed boundary effects require an observer. Targeted verify is repair evidence only. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. An adopted Authority Revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit; machine acceptance reports target/stage qualification but cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
 
-Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Source Plan Authoring Skill, Long-Task Workflow Skill and package-owned completion Hook.
+Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Long-Task Workflow Skill, the retired Source Plan compatibility pointer and package-owned completion Hook.
 
 ## Durable Facts And Generated Surfaces
 

package/assets/skills/context_uiux_design/SKILL.md

@@ -24,10 +24,11 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 ## External Design Resource Consumption / 外部设计资源消费
 
 - `design-resource-authoring` 可以按明确请求在上游动态委托 Open Design 产生 flow、低保真、候选方向、组件族/独特复杂控件状态、交互原型或条件式 Figma handoff；它以明确输出/开发内容为上限，在范围内补齐材料性 UI/UX 含义但不要求逐控件一份稿，不复制 provider 的提示词/模板，也不把任何资源设为全局必选。
+- `design-system-authoring` 是另一个仅显式调用的冷启动/修复 Skill：它用 Open Design 生成或选择候选，经过明确或受托选择后，把结果采纳到 canonical `DESIGN.md`、唯一 token source/direction 与 owning Context。缺少设计系统不会让本 Skill 或 `design-resource-authoring` 自动调用它。
 - 本 Skill 不承担独立资源生产。只有进入默认开发流程或 Long-Task、需要采纳稳定结论时，本 Skill 才消费这些或其他外部设计 Source。
 - 候选、灵感和未选定输出不是 Context readiness 或实现权威，不能写入 selected registry；选定目标仍必须完成 UI Authority Closure 和 `Context Delta`。
 - 消费时核对产品 Source、Screen/Control Context、`DESIGN.md`、token owner、资源稳定身份及 exact-target 覆盖条件；只把长期稳定且无冲突的事实写入其唯一 owner，不要求统一 pack、目录或工具格式。
-- 设计资源生成本身不改 `project_context/**`、`DESIGN.md` 或 production code。下游采纳、实现与验证仍由当前 Workflow Contract 或 `long-task-workflow` 负责。
+- 设计资源生成本身不改 `project_context/**`、`DESIGN.md` 或 production code；定稿后只可一次性回改初始方案。设计系统采纳则由显式 `design-system-authoring` 完成。下游实现与验证仍由当前 Workflow Contract 或 `long-task-workflow` 负责。
 
 ## 工作方式
 
@@ -106,7 +107,7 @@ Configured is system-level visual authority only, not surface implementation-rea
 - Read the owning surface/interaction Context, `DESIGN.md`, the authored exact-value token source and generation direction, existing production components/routes and every material design reference.
 - Classify each reference as `exact-target`, `constraint` or `inspiration`. Record the affected surface/route/component, project path or URI and relevant viewport/theme/mode/state. Exact targets authorize fidelity comparison only for those conditions; constraints authorize only their named rule; inspiration proves no reproduction claim.
 - Treat a missing `DESIGN.md`, its package starter with Design authority status: `unconfigured`, style-only prose, an inspiration-only set or conflicting references as insufficient authority for invented production layout.
-- If the user explicitly delegates standalone design-resource generation, use `design-resource-authoring` to keep the explicit output/development scope as the ceiling and commission the smallest sufficient set from available Product Design/Open Design capabilities. An implementation handoff covers material in-scope UI/UX meaning through relevant controls, may reuse component families or one inspectable artifact and does not require one file per control. In this downstream Skill, adopt a selected target into durable Context/`DESIGN.md` only after UI Authority Closure. Ask only when an unknown material preference could change the result or the user reserves the choice.
+- If the user explicitly asks to initialize/generate/select/adopt the project design system, use the explicit-only `design-system-authoring`; never infer it from a missing starter. If the user explicitly delegates standalone resource generation, use `design-resource-authoring`. Style-bearing resources must stop on unconfigured authority and bind the adopted Open Design system; low-fidelity/IA/semantics-only resources remain lightweight. After final selection, resource authoring may reconcile accepted decisions into the initial proposal once, but this downstream Skill adopts durable target meaning only after UI Authority Closure.
 - Never use the implementation's own generated screenshot or diff as the target it claims to match. A target is selected Source; an implementation render is evidence. Baseline replacement requires deliberate review and cannot merely erase a failure.
 - Do not require Figma, a fixed `docs/design/**` tree, an image for every local change or universal pixel-perfect thresholds. Use project-native design assets and the smallest authority sufficient for the claimed fidelity.
 
@@ -125,7 +126,7 @@ For material design-system, redesign, high-fidelity implementation or visual-pol
 
 - 不默认创建 `.work_products/**`、UI/UX 独立文档、handoff matrix、review/test/release 文档。
 - 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
-- 如果用户明确要求独立设计稿、mock、线框图、原型或 Figma handoff，使用 `design-resource-authoring`；本 Skill 只在后续开发流程中采纳长期事实。
+- 如果用户明确要求初始化/生成/选择/采纳项目设计系统，使用仅显式调用的 `design-system-authoring`；如果明确要求独立设计稿、mock、线框图、原型或 Figma handoff，使用 `design-resource-authoring`。本 Skill 只在后续开发流程中采纳其他长期事实。
 - `DESIGN.md` 是视觉设计系统事实源；项目流程、模块契约和下一步动作仍以 `project_context/**` 为准。
 - 如果普通页面实现已经有充分 Design Authority，或用户只要求修复 UI bug、局部改 CSS、换颜色、明确的 throwaway prototype，或只是泛泛提到“设计 / design / user experience”，不需要触发本 Skill；durable 视觉体系/Context 采纳，或 material production UI 缺失/冲突的 Design Authority 才使用。明确要求设计资源产物但尚未进入采纳/实现流程时使用 `design-resource-authoring`。