project-tiny-context-harness 0.7.7 → 0.7.9

package/assets/skills/design-resource-authoring/references/downstream-handoff.md

@@ -1,70 +1,31 @@
-# Design Resource Handoff
+# Design Resource Handoff And Proposal Reconciliation
 
-Generated resources remain ordinary external Source. This reference preserves enough identity and meaning for later work without creating a Tiny Context-specific pack, registry or authority lifecycle.
+Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry or authority lifecycle.
 
 ## Candidate, selection and authority are separate
 
-- **Candidate:** provider output proposed for review. It authorizes no fidelity.
-- **Human selection:** an explicit user/team choice with a stated basis. It permits selected-source preparation, not automatic durable adoption.
-- **Authority adoption:** a downstream workflow reconciles the selected Source with product/surface Context and `DESIGN.md`, records durable ownership where required and binds implementation/verification to declared conditions.
+- **Candidate:** provider output proposed for review; it authorizes no fidelity.
+- **Selection:** an explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
+- **Authority adoption:** a downstream development workflow reconciles selected Source with product/surface Context and `DESIGN.md` and binds implementation/verification to declared conditions.
 
-The Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to `exact-target`. Unknown coverage remains unknown.
+This Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to one. Unknown coverage remains unknown.
 
 ## Development-scope coverage
 
-An implementation-facing handoff is complete at the authoring layer only for the user's explicit development scope. Record the in-scope surfaces/flows/regions/component families/unique controls, the minimum surrounding context needed to place them and the explicit exclusions. Broader product Source remains background and does not authorize generating detailed resources for unaffected areas.
+For every material in-scope surface/flow/region/component/control condition, record selected existing Source, newly generated Source, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. Include only necessary surrounding context and explicit exclusions. One larger addressable artifact may cover several items; a static frame covers only conditions it actually shows.
 
-Map every material in-scope UI/UX item to selected existing Source, a newly generated resource, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. The mapping may be concise prose or a task-local structured block; it is not a required pack, persistent coverage authority or acceptance record.
+Design resources may show user-visible triggers, transitions, states, feedback and product-rule presentation. Business, data, permission and algorithmic rules remain owned by product/technical Source and must not be invented by visuals.
 
-A page target, interactive prototype, component-family workbench or one larger addressable design board may each cover several items. Do not require a separate file per control. Reuse selected component variants for repeated controls and commission dedicated resources only for unique or complex uncovered meaning. A static frame covers only the conditions it actually shows; it does not silently cover dynamic states, interaction, motion, responsiveness or accessibility.
+## Final proposal reconciliation
 
-The handoff may specify user-visible triggers, transitions, states, feedback, recovery and the presentation of product rules. Business, data, permission and algorithmic rules remain owned by product/technical Source and must be referenced rather than invented or made authoritative only in visuals.
-
-## Intent-sized response
-
-### Exploration
-
-Return promptly:
-
-- requested scope and intent;
-- visible candidate/preview;
-- resource dispositions and obvious limitations;
-- provider/artifact qualifier when execution is not clean;
-- minimal sanity review actually performed.
-
-Do not require files, schemas, packs, hashes or validator runs for a throwaway unselected preview unless they are needed to retrieve/show it reliably.
-
-### Handoff
-
-Add only the fields needed for another person or workflow to consume it:
-
-- explicit output/development scope, necessary surrounding context and exclusions;
-- stable resource key plus surface/control/state/target keys when known;
-- classification: candidate, inspiration, constraint or pre-existing exact target;
-- provider version, project/run, selected capability/template, agent/model and design-system provenance as reported live;
-- explicit source entry or preview locator and immutable hash/snapshot when available;
-- declared platform, viewport, mode, state, content and interaction coverage;
-- for an implementation handoff, a stable-key mapping from each material surface/flow/region/component/control condition to its owning existing/generated resource or unresolved disposition;
-- selection basis if a human selection already exists;
-- unresolved decisions, known limitations and forbidden inferences;
-- outer review performed and provider status qualifier.
-
-No dedicated Markdown/YAML file or directory is mandatory. Use concise prose for simple work and a task-local structured block when fields would otherwise become ambiguous.
-
-### Selected-source preparation
-
-Require explicit human selection and record who/what supplied the selection basis. Preserve the exact artifact by hash or a user-approved durable snapshot. Do not rely on a mutable preview URL. Do not choose a repository destination, edit authority files or start implementation without separate authorization.
-
-## Accepted-design-decision delta
-
-When raw-draft exploration leads to an explicit selection, report a delta for the separately owned proposal-revision step:
+Keep a task-local buffer during candidate iteration:
 
 ```yaml
-selection_basis: explicit user/team decision
+selection_basis: explicit user/team choice | explicit delegated selection
 selected_resources:
-  - resource key, explicit locator and immutable hash/snapshot
+  - stable key, provider/project/run/entry, declared conditions, immutable digest/snapshot
 accepted:
-  - decision and rationale
+  - decision, rationale and affected proposal section/stable keys
 rejected:
   - alternative and reason
 unresolved:
@@ -77,62 +38,71 @@ impacts:
   state_keys: []
   interaction_rules: []
   visual_constraints: []
-forbidden_inference:
-  - candidate iteration did not itself revise the proposal or establish Design Authority
 ```
 
-This is an explanatory shape, not a required schema. Include only known changes. Do not emit or apply a delta after every iteration: interim observations remain task-local and may be returned once as a consolidated delta when the direction is final. The Skill does not write back the proposal, decide when a separately authorized owner rewrites it, or invoke `source-plan-authoring`.
+This is an explanatory shape, not a schema or required file. Do not write during iteration. Once the direction is final:
 
-## Initial proposal and Source Plan routing
+1. confirm the selection basis and immutable resource identity;
+2. consolidate duplicate/intermediate notes;
+3. apply accepted decisions once while preserving all unaffected original requirements and source provenance;
+4. exclude rejected and unresolved choices from requirements, keeping unresolved items visibly unresolved;
+5. record selected resource keys, conditions, locators and digests in the proposal where downstream consumers can recover them;
+6. make reruns idempotent—update the existing decision/reference instead of appending it again;
+7. if the initial proposal has an authorized writable path, edit that file; otherwise return the full revised proposal in the response.
 
-The components are independent and composable:
+Never mutate a Source Plan, `project_context/**`, `DESIGN.md`, Delivery Contract, production code or tests. A small request may generate, select and reconcile in one turn; “once” describes final semantic writeback, not a required waiting phase.
 
-```text
-raw draft -> design-resource-authoring -> candidates -> explicit selection
-raw draft -> source-plan-authoring -> Source Plan
-revised raw draft + selected design resources -> source-plan-authoring -> richer Source Plan
-selected design resources -> default Workflow or Long-Task Source
-```
+If no selection occurs, return candidates plus a consolidated pending delta and leave the proposal unchanged.
+
+## Intent-sized handoff
+
+### Exploration
+
+Return scope/intent, visible candidates, resource dispositions, obvious limitations, provider/artifact qualifiers and the sanity review performed. Do not require a pack, hash or validator for a throwaway unselected preview unless retrieval needs it.
+
+### Implementation handoff
 
-The recommended design-first loop for substantial new Web/App work is:
+Add:
 
-1. explore from the initial proposal;
-2. iterate inside the requested scope;
-3. obtain explicit human selection;
-4. when requested, return one consolidated accepted-design-decision delta;
-5. let a separately authorized plan owner revise the proposal;
-6. if requested, pass both the revised proposal and selected immutable resources to `source-plan-authoring`.
+- output/development scope, necessary context and exclusions;
+- stable resource, surface/control/state/target keys;
+- candidate/inspiration/constraint/pre-existing-exact-target classification;
+- provider version, project/run, capability/template, agent/model and live design-system binding;
+- exact entry/preview locator plus SHA-256 or approved snapshot;
+- declared platform, viewport, mode, state, content, interaction, accessibility and motion coverage;
+- stable-key coverage mapping and unresolved dispositions;
+- selection basis, proposal reconciliation path/status and known limitations;
+- outer review and separate provider/artifact/design qualifiers.
 
-This is a useful path, not a universal required lifecycle. `source-plan-authoring` remains optional upstream synthesis and does not generate design resources.
+No dedicated Markdown/YAML file or directory is mandatory.
 
-## Default Workflow Contract consumption
+## Recommended downstream routing
+
+```text
+initial proposal
+  -> design-resource-authoring
+  -> selected immutable resources + reconciled initial proposal
+  -> long-task-workflow (explicit long delivery)
+     OR current native Goal + default Workflow Contract (non-long delivery)
+```
 
-When the user later authorizes concrete development:
+`source-plan-authoring` is not an intermediate stage. A legacy Source Plan remains valid ordinary Source if supplied, but design-resource authoring never creates or edits one.
 
-1. bring the selected generated resource as ordinary Source;
-2. perform UI Authority Closure against product/surface Context, `DESIGN.md`, tokens and declared targets;
-3. classify the resource and confirm selection basis/coverage;
-4. decide `Context Delta` and adopt durable facts only through their existing owners;
-5. implement and run project-owned verification.
+### Default Workflow consumption
 
-Open Design run success, a candidate screenshot or this handoff cannot authorize fidelity or acceptance.
+The consuming Goal brings the revised proposal and selected resources as ordinary Source, performs UI Authority Closure, classifies coverage, decides `Context Delta`, adopts durable facts through existing owners, implements and runs project-owned verification.
 
-## Long-Task consumption
+### Long-Task consumption
 
-- A selected resource and an optional Source Plan are parallel ordinary Source inputs to Contract authoring.
-- Contract `source_paths`, bindings, verification inputs, check input paths and artifact globs should name only the stable locators/conditions they actually consume.
-- Surface/control/state/target keys should connect product meaning, source targets, implementation and checks where applicable.
-- Authority Lock, protected Authority Revision and Final Gate remain the only Long-Task authority lifecycle.
-- This Skill creates no Contract Draft, outcome, receipt, Check result or Gate.
-- A later Open Design rerun does not silently revise locked Source; the downstream workflow uses its normal revision rules.
+The same revised proposal and selected resources enter `long-task-workflow`. Its integrated Source-quality authoring makes the delivery self-contained, then Contract `source_paths`, Bindings, `verification_inputs`, Check `input_paths` and `artifact_globs` name only stable locators and conditions actually consumed. Authority Lock, protected revision and Final Gate remain the sole lifecycle. This Skill creates no Contract Draft, Outcome, Receipt, Check result or Gate.
 
 ## Forbidden inferences
 
 Unless independently proven downstream, never infer that a generated resource:
 
 - is selected, authoritative or accepted;
-- covers unlisted states, viewports, modes, platforms or accessibility behavior;
-- is a native implementation because an HTML/image preview renders;
-- is editable in Figma because a Figma capability was listed;
-- changed the initial proposal, Source Plan, Context, `DESIGN.md`, code or Contract;
-- proves production fidelity, product correctness, test completion or release readiness.
+- covers unlisted states, viewports, modes, platforms or accessibility;
+- is native implementation because an HTML/image preview renders;
+- is editable in Figma because a capability was listed;
+- changed Context, `DESIGN.md`, a Source Plan, code or Contract;
+- proves production fidelity, correctness, test completion or release readiness.

package/assets/skills/design-resource-authoring/references/open-design-provider.md

@@ -37,10 +37,27 @@ Prefer, in order:
 
 Never vendor a fallback template catalogue or guess a template ID from prior runs. Do not implement a transport helper unless the live host truly lacks a safe structured path; any helper may normalize metadata and transport only.
 
+## Conditional Design Authority gate and binding
+
+Before any style-bearing commission, read project `DESIGN.md` and its declared authored exact-value token source/generation direction. Style-bearing means the resource materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Low-fidelity structure, IA/flow topology and semantics-only behavior/state studies are non-fidelity and do not require the gate.
+
+If authority is absent, explicitly `unconfigured`, still a starter, style-only/inspiration-only, or lacks one authored token source/generation direction, stop before creating a project or run. Direct the user to explicitly invoke `$design-system-authoring`; never auto-run it. A combined explicit request authorizes the sequence.
+
+For configured style-bearing work:
+
+1. read the adopted Open Design design-system ID and digest/provenance from project Design Authority;
+2. confirm `od://design-systems/<id>/DESIGN.md` is readable through MCP;
+3. pass that ID as `designSystem` to `create_project`;
+4. immediately call `get_project` and require `designSystemId` to match;
+5. when reusing a project, check its binding before every new style-bearing run;
+6. on missing/mismatch, prefer a new bounded project with the correct binding when MCP has no safe update method; otherwise feature-detect and verify the provider's structured update.
+
+Never silently use the provider's default or a different system. A provider-side mismatch is a synchronization/rebinding issue; it does not erase the canonical project `DESIGN.md`.
+
 ## Structured commission sequence
 
-1. Record provider version, selected agent/model, functional capability, rendering template, design system and relevant plugin/export readiness as reported live.
-2. Reuse an existing task-local project only when its scope and prior inputs match; otherwise create a bounded project.
+1. Record provider version, selected agent/model, functional capability, rendering template, adopted design system and relevant plugin/export readiness as reported live.
+2. Reuse an existing task-local project only when its scope, prior inputs and required design-system binding match; otherwise create a bounded project. For style-bearing work, pass `designSystem` and verify `get_project.designSystemId` before the run.
 3. Start a run with the product-specific commission envelope and the provider-native capability identifier.
 4. Poll with a bounded cadence. During a long run, report meaningful progress at least once per minute without flooding the user.
 5. Preserve run IDs and the latest provider diagnostic. Support cancellation when the user requests it and the provider exposes it.

package/assets/skills/design-resource-authoring/references/resource-selection.md

@@ -23,7 +23,14 @@ Rich background improves a bounded artifact. It never authorizes more artifacts.
 | `handoff` | “Can another designer/developer reliably consume this without inventing material in-scope UI/UX decisions?” | Minimum sufficient project-native resources plus scope-bound coverage, provenance, limitations and relevant checks |
 | `selected-source-preparation` | “Preserve this explicitly selected direction for later use.” | Immutable identity or approved snapshot, explicit selection basis and downstream notes |
 
-Intent is task-local and need not be persisted. Selected-source preparation does not itself adopt Design Authority.
+Intent and style dependency are task-local and need not be persisted. Selected-source preparation does not itself adopt Design Authority.
+
+Classify each commission before capability selection:
+
+- `style-bearing`: high-fidelity/branded output, visual-direction candidate, typography/color/density treatment, component visual specification or production-style prototype;
+- `non-fidelity`: low-fidelity hierarchy, IA/flow topology, semantics-only interaction/state study or explicitly non-fidelity prototype.
+
+Mixed work is style-bearing unless it can be split into a genuinely independent non-fidelity commission. Style-bearing work requires configured project Design Authority and an Open Design project bound to the adopted system. Missing authority stops and points to the explicitly invoked `$design-system-authoring`; it never triggers that Skill automatically.
 
 ## 3. Inventory relevant input roles
 
@@ -152,15 +159,15 @@ This is an explanatory shape, not a required file or schema. Never paste or para
 - For exploration, stop as soon as the requested decision is supported.
 - For an implementation handoff, stop only when every material in-scope coverage item has an explicit disposition and the resource mapping leaves no material user-visible design decision for the implementer to invent. Honest `decision-required` or `unavailable` items may stop generation but remain visible blockers/limitations; this does not claim Design Authority or implementation acceptance.
 
-When a human explicitly selects or rejects a direction, return an accepted-design-decision delta when requested rather than editing the initial proposal. Include accepted, rejected and unresolved choices; product, information, control/state and visual implications; affected stable keys; and selected artifact locators/hashes. Do not require a delta after every iteration. Interim observations remain task-local and may be returned once as a consolidated delta after the design direction is final. A separate plan owner decides whether, when and what to revise.
+During iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. After explicit human selection or explicitly delegated selection, consolidate the buffer once and reconcile only accepted decisions into the initial proposal. If it is a writable file, update it in place while preserving original intent/provenance; otherwise return one complete revised proposal. The operation must be idempotent, name selected artifact locators/hashes and affected stable keys, and exclude rejected/unresolved choices. Never write a Source Plan, Context, `DESIGN.md`, code, tests or Contract.
 
 ## Worked scope examples
 
 - **Large draft, one filter control:** select a control-state study if anatomy and states are uncertain; omit page/flow resources.
-- **One page, style preview:** select one high-fidelity candidate; do not add a design-system pack or validator run.
+- **One page, style preview:** first require configured Design Authority and matching Open Design binding, then select one high-fidelity candidate; do not add a design-system pack or validator run.
 - **One page scheduled for development:** use a page/flow target for layout and context, map ordinary buttons/inputs to selected component variants, and add grouped component-state or dedicated complex-control studies only where relevant static/dynamic states, feedback, motion, responsiveness or accessibility remain uncovered.
 - **Local panel inside a large app:** include enough surrounding page context to place and size the panel, but generate detailed resources only for the panel, its in-scope controls and affected states.
 - **One comprehensive interactive artifact:** accept it as the minimum set when its sections and reachable states explicitly cover every material in-scope item; do not add duplicate control boards. If it exposes only a static/default view, commission the missing state/interaction coverage instead of inferring it.
 - **Three-screen interaction flow:** select a low-fi flow and an interactive high-fi prototype only if topology and interaction/visual behavior are independently unresolved.
 - **Local style fix with exact target:** select no new design resource and route to implementation.
-- **Raw draft before Source Plan:** iterate only requested candidates, optionally return one consolidated accepted-decision delta when requested after selection, and leave both draft revision and later Source Plan authoring separate.
+- **Initial proposal before execution:** iterate only requested candidates, keep one task-local delta buffer, then after selection reconcile accepted decisions once. Pass the revised proposal plus selected immutable resources directly to the default Goal or `long-task-workflow`.

package/assets/skills/design-system-authoring/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: design-system-authoring
+description: Use only when the user explicitly asks to initialize, generate, choose, adopt, replace or repair a project design system or design style with Open Design; asks for “初始化设计系统”, “生成设计系统”, “确定设计风格”, “采纳 Open Design 设计系统”, or explicitly invokes design-system-authoring in a Minimal Context Harness project. This cold-start capability never runs merely because DESIGN.md is missing, a project is new, another Skill needs visual style, or ordinary UI work begins.
+---
+
+# Design System Authoring
+
+Generate or select an Open Design design system, obtain an explicit selection, and adopt that selection into the project's existing durable Design Authority. The user invokes this Skill at project cold start or later repair time; installation only makes it available.
+
+## Hard boundaries
+
+- Run only from an explicit user request. Never auto-run from `init`, `sync`, the default Workflow, `design-resource-authoring`, a missing/starter `DESIGN.md`, or a new-project inference.
+- A combined explicit user request to initialize the system and then generate resources authorizes that sequence; a resource gate alone does not.
+- Open Design owns generation, revision, previews and its catalogue. Use its live structured capabilities; do not copy its prompts, emulate its generator, vendor a catalogue or invent provider IDs.
+- Keep candidate generation, human/delegated selection and authority adoption distinct. A successful job or attractive preview is not selected and is not project authority.
+- Project `DESIGN.md` and its one declared authored exact-value token source or generation direction are canonical. An Open Design design-system record and project binding are provider synchronization, not a second authority.
+- Put durable surface, information-architecture and interaction facts in their owning `project_context/**`; put visual-system semantics, rationale, token direction and reference interpretation in `DESIGN.md`. Do not duplicate facts across owners.
+- Do not create a design registry, receipt, workflow state, Contract, acceptance gate or provider runtime inside Tiny Context.
+- Do not persistently install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Task-local use of an already available Open Design MCP/daemon is allowed.
+- Do not implement production UI or claim downstream fidelity, accessibility, product correctness or acceptance.
+
+## Read the references
+
+1. Always read [open-design-design-system-provider.md](references/open-design-design-system-provider.md) before discovery, generation, revision, selection or provider synchronization.
+2. Always read [authority-adoption.md](references/authority-adoption.md) before changing `DESIGN.md`, its token source, relevant Context or provider bindings.
+
+## Core workflow
+
+1. **Confirm explicit intent and scope.** Identify whether the user wants a new system, selection from existing systems, repair, or replacement; capture the product/brand purpose, supported surface/platform, accessibility needs, required modes and supplied references. Ask only when an unresolved aesthetic or brand choice materially changes the candidates and the user has not delegated selection.
+2. **Inspect current authority.** Read core Context, relevant surface/interaction Context, `DESIGN.md`, its declared token source/generation direction and any recorded Open Design provenance. Classify the project as `unconfigured`, `configured`, or `configured-but-inconsistent`; this is a task-local finding, not new state.
+3. **Discover live Open Design capabilities.** Prefer structured MCP. List/read `od://design-systems/<id>/DESIGN.md`, inspect tool schemas, and feature-detect design-system creation/revision/acceptance plus project binding. Record the live provider/MCP version and any fallback used.
+4. **Reuse or generate candidates.** Reuse an existing provider system only when its identity and meaning fit. If a live MCP creation capability exists, use it. Otherwise use the official daemon generation-job API described in the provider reference. Keep every output a candidate until selection.
+5. **Review and iterate.** Inspect `DESIGN.md`, generated token files, preview/showcase and relevant workspace files. Use provider revision jobs for scoped feedback, poll boundedly, preserve diagnostics and keep pending revisions non-authoritative.
+6. **Obtain selection.** Require an explicit user/team selection, or an explicit instruction delegating selection with known criteria. Record the selection basis, provider design-system ID, selected revision when applicable and immutable content digest/snapshot. Reject or leave other candidates unselected.
+7. **Adopt once.** Reconcile the selected system through the authority-adoption procedure. Update root `DESIGN.md`, establish exactly one authored token source/generation direction, update only owning Context facts, and record provider provenance without making it authoritative.
+8. **Synchronize Open Design.** Accept the selected pending revision when applicable. Confirm MCP can read the adopted provider system. For later style-bearing resource work, create or verify an Open Design project with `create_project.designSystem` equal to the adopted provider ID.
+9. **Validate and report.** Run project-owned Context/design lint and source/package checks appropriate to the repository. Separately report provider execution, artifact readiness, selection, authority adoption, provider synchronization, verification and unresolved issues.
+
+## Readiness classification
+
+Treat Design Authority as unconfigured when `DESIGN.md` is absent, explicitly says `Design authority status: unconfigured`, remains an unedited starter, contains only style adjectives/inspiration, or lacks one authored exact-value token source/generation direction. A configured visual system still does not make every surface implementation-ready; selected exact/constraint targets and declared coverage remain separate.
+
+If authority is already configured and the user did not ask to replace or repair it, prefer reuse and explain the current system. Never generate a competing system as filler.
+
+## Completion response
+
+Report:
+
+- requested operation and design-system scope;
+- Open Design transport/version and capabilities actually used;
+- candidate IDs and review performed;
+- explicit or delegated selection basis;
+- adopted `DESIGN.md`, token source and Context owners changed;
+- provider ID, revision/digest and project-binding verification;
+- validations run, limitations and decisions still required.
+
+Always distinguish `provider succeeded`, `artifact ready`, `selected`, `authority adopted` and `binding verified`; none implies the next.

package/assets/skills/design-system-authoring/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Design System Authoring"
+  short_description: "Generate and adopt a project design system"
+  default_prompt: "Use $design-system-authoring to generate, select, and adopt an Open Design design system for this project."
+policy:
+  allow_implicit_invocation: false

package/assets/skills/design-system-authoring/references/authority-adoption.md

@@ -0,0 +1,47 @@
+# Design-System Authority Adoption
+
+Adopt one explicitly selected Open Design result through existing Minimal Context owners. This is a reconciliation step, not a new authority lifecycle.
+
+## Preconditions
+
+- Selection is explicit, or the user explicitly delegated selection and the stated criteria support one defensible choice.
+- The exact provider design-system ID and selected revision/body are readable.
+- `DESIGN.md`, generated token artifacts and relevant preview/workspace files have been inspected.
+- The selected content has a stable digest or user-approved snapshot.
+- Conflicts with product/surface Context are resolved or remain an explicit decision; provider output never silently overrides product meaning.
+
+## Single-owner writeback
+
+Use these owners:
+
+- `project_context/**`: durable surface responsibility, information hierarchy, navigation, stable interaction/state, product accessibility requirements and repeatable verification entrypoints;
+- root `DESIGN.md`: visual principles, typography, color, spacing, radius, elevation, motion rationale, component visual semantics, token-source declaration and interpretation of design references;
+- one project-native authored token source or one explicit generation direction: exact values consumed by implementation;
+- selected authored targets: concrete composition/condition coverage, kept as ordinary versioned project Source.
+
+Do not copy the same fact into several owners. Open Design metadata is provenance only.
+
+## Adoption procedure
+
+1. Read the project's `DESIGN.md` format and lint expectations. Preserve valid project-specific content unless the user explicitly authorized replacement.
+2. Reconcile selected provider semantics against controlling Context. Provider-invented business, permission, data or algorithmic rules are excluded unless independently authorized by product Source.
+3. Write the selected visual system into `DESIGN.md` and declare exactly one authored exact-value token source or generation direction. Avoid style-only adjectives without implementation meaning.
+4. Record provider provenance in a normal `DESIGN.md` section unless the format explicitly permits metadata fields. Include provider name/version, design-system ID, selected revision when applicable, selection basis, source/snapshot locator and SHA-256 digest. State that project files are canonical.
+5. Update only relevant Context when durable surface/interaction/verification facts changed. Use stable surface/control/target keys to connect owners without duplicating the visual prose.
+6. Put concrete selected targets/tokens in project-native versioned paths selected by the user or existing project convention. Never silently choose a repository directory merely because Open Design has a mutable workspace.
+7. Accept the selected provider revision if one exists, then re-read the MCP design-system resource and compare its identity/body or digest with the adopted selection.
+8. Verify downstream project binding by creating or reading a provider project with the selected ID. Provider mismatch is a synchronization problem, not evidence that project Design Authority is absent.
+
+## Validation
+
+Run the repository-owned Design Authority lint, Context validation and token generation/check paths. At minimum confirm:
+
+- `DESIGN.md` is no longer an unconfigured starter;
+- exactly one authored token source/generation direction is declared and resolvable;
+- provenance points to the selected provider ID/revision/digest;
+- no competing design-system authority or duplicate token owner was introduced;
+- MCP can read the provider design system;
+- a downstream Open Design project reports the matching `designSystemId`;
+- candidate resources remain candidates unless independently selected.
+
+Report changed owners and validation results. Do not claim production visual acceptance from these checks.

package/assets/skills/design-system-authoring/references/open-design-design-system-provider.md

@@ -0,0 +1,110 @@
+# Open Design Design-System Provider
+
+Use Open Design's live structured surface. Do not assume the installed version matches this compatibility note; discover first and branch on actual tool/resource schemas.
+
+## Capability order
+
+1. Open Design MCP resources/tools.
+2. The same installed Open Design daemon's structured HTTP API when MCP lacks the required design-system lifecycle operation.
+3. Open Design UI/CLI only for bootstrap, preview inspection or a capability unavailable through structured paths.
+
+Never call a copied prompt or local imitation a provider result. Persistent MCP registration, plugin/auth changes and new disclosure paths require separate authorization.
+
+## Current verified MCP contract
+
+Open Design 0.15.1 exposed MCP server 0.2.0 using protocol `2025-06-18`. A live read-only smoke observed 152 concrete design-system resources through `resources/list`; `resources/read` returned their Markdown bodies. The URI families are:
+
+- `od://design-systems/<id>/DESIGN.md` for current design-system bodies;
+- `od://skills/<id>/SKILL.md` for functional skills;
+- `od://focus/active` for current focus.
+
+This version returns `-32601` for `resources/templates/list`. Treat template enumeration as optional protocol capability: use concrete `resources/list` results when present and never reject a readable design-system catalogue merely because the template-list method is absent.
+
+Its 18 observed tools included `list_projects`, `get_project`, `create_project`, `start_run`, `get_run`, file/artifact operations and capability discovery. `create_project` accepts optional `designSystem`; verify the result through `get_project.designSystemId`. This version exposes design systems as resources but no create/update design-system MCP tool.
+
+Feature-detect future structured methods before using the fallback. A tool name alone is insufficient: inspect its input schema and result.
+
+## Generation fallback for Open Design 0.15.1
+
+When MCP cannot create a design system, discover the running daemon and use its official API. Prefer install metadata supplied by Open Design rather than hardcoded paths. Confirm `/api/health` and the version first.
+
+Start generation:
+
+```http
+POST /api/design-systems/generation-jobs
+Content-Type: application/json
+```
+
+The body is the provider's current design-system input. Supported 0.15.1 fields observed in the installed provider include:
+
+```json
+{
+  "title": "Product design system",
+  "category": "Custom",
+  "surface": "web",
+  "summary": "Product and brand intent",
+  "sourceNotes": "Bounded design brief",
+  "provenance": {
+    "companyBlurb": "Product context",
+    "sourceUrls": [],
+    "githubUrls": [],
+    "localCodeFiles": [],
+    "figFiles": [],
+    "assetFiles": [],
+    "notes": "Selection constraints"
+  }
+}
+```
+
+Send only relevant, user-authorized sources. Do not transmit secrets or unrelated repository content. `surface` is provider-defined; validate the live accepted value. A supplied `body` creates a direct draft and must not be misrepresented as model generation.
+
+Poll `GET /api/design-systems/generation-jobs/<jobId>` at a bounded cadence until a terminal state. Preserve the job ID, step diagnostics and returned `designSystemId`. The observed pipeline explores resources, creates a draft, generates `DESIGN.md`/README/SKILL/tokens/previews/context files, registers files and prepares review.
+
+## Review and revision
+
+Read the system and inspect its assets through:
+
+- `GET /api/design-systems/<id>`;
+- `GET /api/design-systems/<id>/files` and `/file?path=<path>`;
+- `GET /api/design-systems/<id>/preview` or `/showcase`;
+- `POST /api/design-systems/<id>/workspace` when an editable review project is required.
+
+Create scoped feedback with:
+
+```http
+POST /api/design-systems/<id>/revision-jobs
+Content-Type: application/json
+
+{"feedback":"...","sectionTitle":"optional section"}
+```
+
+Poll the returned job through the generation-job endpoint. A succeeded revision job creates a pending revision; it does not alter project authority and must not be called accepted. Inspect revisions with `GET /api/design-systems/<id>/revisions`. After explicit selection, set exactly that revision to accepted:
+
+```http
+PATCH /api/design-systems/<id>/revisions/<revisionId>
+Content-Type: application/json
+
+{"status":"accepted"}
+```
+
+Reject explicitly discarded revisions when useful. Accepting a provider revision updates the provider copy only; the authority-adoption step still owns the project writeback.
+
+The provider also exposes `POST /api/design-systems/<id>/token-contract/rebuild-jobs`. Use it only when the live token-quality decision says a rebuild is available or the user explicitly requests a forced rebuild. A generated token contract still needs selection and project adoption.
+
+## Provider binding for downstream resources
+
+For a new Open Design resource project, call MCP `create_project` with the adopted provider ID in `designSystem`. Immediately call `get_project` and require `designSystemId` to match.
+
+For an existing project, inspect `get_project` first. When it is missing or mismatched, prefer a new bounded project with the correct binding if MCP offers no safe update. Use a live structured provider update only after feature-detecting it and preserving project identity. Never proceed with a style-bearing run while silently bound to another system.
+
+## Failure semantics
+
+Keep these states separate:
+
+- daemon/MCP execution: queued, running, succeeded, failed, cancelled or unknown;
+- candidate artifacts: missing, partial, retrievable, rendered or corrupt;
+- selection: unreviewed, selected, rejected or decision-required;
+- project adoption: unchanged, partially adopted, adopted or inconsistent;
+- provider binding: unverified, matched or mismatched.
+
+Preserve exact errors and stop bounded polling. Do not mark a candidate selected because generation succeeded, and do not mark project authority adopted because a provider revision was accepted.