project-tiny-context-harness 0.11.0 → 0.12.0

package/assets/skills/design-resource-authoring/references/recovery-and-writeback.md

@@ -1,205 +0,0 @@
-# DRA Semantic Replay, Recovery And Proposal Writeback
-
-Load this reference only for a material generation/revision loop which needs complete semantic replay, a selected-Proposal writeback, current bidirectional audit or real recovery across interruption. It strengthens upstream Source quality and does not become Design Authority, implementation acceptance or Long-Task proof.
-
-## Simple path and admission
-
-A simple scoped preview creates zero recovery files and persisted recovery bytes, adds no user pause or Provider generation beyond the one requested commission, runs no formal handoff/preflight, performs no Proposal writeback and opens no helper write transaction. Its ordinary requested preview is the commission itself; recovery adds and reports zero tool actions. Keep its temporary reasoning in the current turn.
-
-Ordinary conversational review and selection remains legal outside this deterministic path. It creates no approval record or persistent selection state and must be reconfirmed if lost before authorized materialization. Deterministic cross-interruption selection uses only the existing raw-digest-bound marked Source, `ty-dra-authority-v1`, selected-resource binding and conditional checkpoint below; do not invent `review_set_id`, approval status or another checkpoint kind.
-
-Without the complete bindings below, an ordinary loop may report only conservative impact analysis from readable Source, identify unverified scope and regenerate conservatively within the hard ceiling or return `decision-required`. It cannot claim that only identified resources are affected. When this recoverable path has a complete current catalog, change and preservation claims remain bounded to its exact Requirements-to-Resource, Resource-to-Requirements, explicitly unchanged, blast-radius and inactive-leakage universes.
-
-Use a recovery checkpoint only when interruption would otherwise lose material accepted/rejected/unresolved semantics, immutable Provider identity or a pending CAS writeback. It is versioned, ignored, task-local, non-authoritative and deletable. It is not Source, Context, a Contract, Authority, Evidence, Receipt, Gate, Provider registry, scheduler, acceptance state or completion conclusion. There is no global session registry, event log, heartbeat, polling loop or state-machine service.
-
-For deterministic classification, apply four fail-closed invariants before details: validate every semantic key independently; retain every valid accepted/rejected/unresolved decision and its authority row even when a later patch, audit or owner fails; reject deterministic checkpoint input whose claimed Source authority is invalid; and report a requested or pending unsafe reconciliation/writeback as blocked rather than as no action. Provider/resource selection never fills a missing authority row, and one key's authority never covers another key.
-
-## Base and replayable Delta
-
-Freeze one current Base with:
-
-```yaml
-locator: repository/relative/file
-raw_byte_digest: sha256
-encoding: detected-by-helper
-eol_policy: detected-by-helper
-scope_ceiling: bounded-scope-key
-in_scope_keys: []
-explicitly_excluded_keys: []
-```
-
-The Base must be repository-readable and raw-digest verifiable: ordinary project Source, a materialized project-native Proposal, or an explicitly authorized disclosure-reviewed recovery snapshot. A Provider resource is recoverable only when its immutable identity can be fetched again and checked. Conversation-only input, expiring external documents, unavailable attachments and sensitive inputs are not recovered from locators. Materialize only with explicit user authorization. Never persist credentials, tokens, secrets, protected raw values or sensitive originals. Otherwise report exactly `cross-session deterministic recovery unavailable`; when no checkpoint exists, its checkpoint disposition is `none`, not rejection of a nonexistent file.
-
-Every Delta stores actual replay semantics, never only an ID:
-
-```yaml
-delta_id: stable-key
-sequence: 1
-supersedes: []
-proposes_replacement_of: []
-operation: add | replace | remove | preserve
-semantic_kind: exact-visual | product | business | permission | data | algorithm | commercial | safety-security | technical
-target_keys: []
-before_semantics: complete-value-or-null
-after_semantics: complete-value-or-null
-origin: user-direct | necessary-derived | repository-evidence-backed | provider-suggested
-decision_authority: explicit-user | delegated:<bounded-scope-key> | none
-evidence_refs: []
-source_refs: []
-explicitly_unchanged_keys: []
-status: accepted | rejected | unresolved
-```
-
-Retain all statuses, exact ordering, one-way supersession and explicit unchanged keys. Only an accepted Delta may supersede an earlier active accepted Delta, and it must replace the same target set, semantic kind and exact prior `after_semantics`; a rejected or unresolved Delta never deactivates accepted meaning. Use `proposes_replacement_of` for a rejected/unresolved proposal which may be decided later. Cross-target or semantic mismatch fails closed.
-
-After legal supersession, every stable semantic target key has at most one active accepted Delta owner. Two active accepted Deltas for one target without a legal replacement relationship fail closed. This version deliberately has no generic merge or composition DSL; a future need to compose one semantic key from several Deltas requires a separately admitted mechanism.
-
-Derive the complete inactive universe as rejected plus unresolved plus superseded accepted Delta IDs. The current audit supplies exactly one leakage row for every inactive ID with the matching reason and `leaked: false`; missing, extra, duplicate or active-ID rows fail closed. If an inactive meaning remains in the Proposal, selected-resource projection or resulting writeback, reconciliation is blocked.
-
-Status inventories contain stable target-key identities, never `key=value` strings; semantic values stay in the Delta rows. The same key can therefore remain in the accepted inventory while a later rejected or unresolved proposal for that key remains visible in its own inventory. A blocked audit or illegal final owner does not rewrite an independently authorized accepted Delta as unresolved.
-
-Each `source_ref` resolves through `authority_sources` to one repository-contained Source document, its current raw-byte digest, one actual marked Source item, the item kind and item-text digest. An arbitrary string or conversation-only locator cannot create authority or enter deterministic recovery. For deterministic accepted authority, that same marked Source Item also contains one strict, non-rendered, package-owned single-line `ty-dra-authority-v1` JSON projection covered by the Item text digest. Free text without this projection can continue through ordinary conversational DRA, but it cannot machine-close deterministic recovery authority or enter a checkpoint as accepted authority.
-
-An explicit projection uses `mode: explicit-user` and enumerates exact target keys, semantic kinds, allowed origins and the canonical `after_semantics` SHA-256. Its `target_keys` set must equal the bound Delta target set; a coupled `[A, B]` decision cannot be rebound as an independently authorized `[A]` meaning. A delegation projection uses `mode: delegation` and enumerates its stable delegation key plus exact allowed target keys, semantic kinds and origins. `delegated:<id>` names the matching task-local delegation row, and the accepted Delta binds that same decision Source. Delegation is deliberately a bounded superset: every Delta target must be a member of the delegation's allowed targets. Do not substitute an incidental target path for delegation identity. A hierarchical-looking key such as `checkout.confirmation` does not implicitly authorize `checkout.confirmation.fade_duration`, a sibling or a broader target.
-
-`origin` records where the meaning arose, not where its Source item happens to be stored. Materializing a direct user choice in the repository leaves it `user-direct`; use `repository-evidence-backed` only when repository evidence itself supplies the meaning. A separate decision Source can authorize a meaning without changing that meaning's origin.
-
-A selected resource is evidence and never authorizes itself. An accepted Provider suggestion requires explicit user authority or a delegation which covers its origin, semantic kind and every target. Delegation authorizes bounded choice; it is not automatically the Source for the chosen non-visual meaning. Product capability, business, permission, data, algorithm, commercial and safety/security meaning additionally binds an independent authoritative Source Item, separate from the delegation item, whose own projection simultaneously matches the exact target set, semantic kind, origin and canonical `after_semantics` digest. An unrelated requirement kind cannot fill that slot. A specific explicit-user decision item may carry both meaning and acceptance, but a general bounded-delegation decision alone is not the meaning. Exact visual values may remain exclusively resource-owned, but their adoption authority remains independently Source-bound. A visual-color delegation therefore cannot be rebound to product, business or permission meaning. Provider-added meaning lacking authority remains `unresolved` unless an authoritative decision explicitly rejects it. Rejected/unresolved meaning never enters accepted requirements or writeback.
-
-The helper proves consistency between Source-owned structured scope and Delta fields. Interpreting the higher-level semantics of arbitrary free text remains part of the Authoring TCB; the helper does not implement general natural-language entailment.
-
-Reconstruct each round only from:
-
-```text
-current Base@raw digest
-+ ordered active accepted Delta semantics
-+ current unresolved decisions
-+ current scope/exclusions
-+ current Design Authority identity
-```
-
-Never use a prior Agent summary or generated resource as the next Base. Missing semantics, stale Base, invalid sequence/supersession/delegation or an out-of-scope/excluded target fails closed.
-
-## Conditional checkpoint and helper
-
-Prepare one disclosure-reviewed JSON input using schema `design-resource-recovery-input-v4`, including session identity, Base, `authority_sources`, delegations/Deltas, exact accepted/rejected/unresolved sets, current Design Authority identity, immutable Provider project/run/resource references, `selected_resource_bindings`, one frozen `audit_expectations` catalog and optional writeback. The catalog owns the exact changed, unchanged, resource-decision, blast-radius and inactive-leakage row expectations, including Delta/resource/condition/basis/binding identities. Every resource-decision binding freezes one and only one `final_disposition`: `proposal-written` with its exact operation ID, `resource-owned-exact-visual` with its selected resource/conditions/structured owner, `not-adopted` for rejected or superseded meaning, or `unresolved` for unresolved meaning. Audit observes and verifies this owner; it never selects it. Changing an owner requires checkpoint `update` with digest CAS. The catalog is the only checkpoint audit-universe/owner owner; current audit rows must be set-equal to it rather than merely non-empty. Selected resource bindings declare one unique resource key, generic `repository-snapshot` or `external-immutable` identity, locator, raw-byte digest and exact condition identities. Arbitrary condition strings and duplicate identities fail closed.
-
-The existing selected-resource, condition, Design-Authority and authority-Source fields jointly bind deterministic selection to the canonical selected-source digest, target, declared conditions and controlling Source/Design-Authority identity; no new selection field or status is added. Preview URLs, names and exports are derived outputs. A proved equivalent export does not change the selection binding, while a visible or semantic difference requires a new user review/selection and, when retained here, the existing digest-CAS checkpoint update.
-
-Create/retain a checkpoint for a real interruption or pending CAS writeback; use `none` when neither exists, and `reject` when a requested new checkpoint, input, destination or existing checkpoint cannot be admitted. Never turn an invalid authority request into `none` merely because no file was written. Then explicitly create it when required:
-
-```text
-ty-context design-resource recovery create <session> --input <state.json>
-```
-
-When a real recovered loop changes Delta, resource or pending writeback inputs, replace the existing checkpoint only through digest CAS:
-
-```text
-ty-context design-resource recovery update <session> --input <state.json> --expected-sha256 <current-checkpoint-sha256>
-```
-
-The helper writes the next canonical checkpoint to an exclusive same-directory temporary file, rechecks the current digest, atomically replaces and rereads it. A mismatch retains the old checkpoint and fails closed. Repeated identical input is an idempotent no-write. This creates no session registry.
-
-The helper writes only:
-
-```text
-tmp/ty-context/design-resource-recovery/<session>/checkpoint.json
-```
-
-and requires the path to be ignored and untracked. It validates strict schema/version, canonical bytes, Base identity, complete Delta/delegation semantics, repository containment/no-follow parents, symlink/junction/hardlink and user collision boundaries. The checkpoint adds detected Base encoding/EOL and, when applicable, detected target encoding/EOL. It stores no current activity, live Provider execution, Artifact readiness, Design suitability, next action, readiness/completion or acceptance.
-
-Use `inspect` after interruption. It re-reads Base and repository Design Authority, validates raw identities, reconstructs ordered active accepted/rejected/unresolved semantics and derives writeback state. External Provider/resource and external Design Authority identities remain explicitly listed for current revalidation; the helper does not contact or manage Providers.
-
-```text
-ty-context design-resource recovery inspect <session> [--json]
-```
-
-Unknown schema, corrupt JSON, stale Base/authority or unavailable semantics fails closed. In particular, v3 input/checkpoint/audit and exact-patch-v3 are never silently interpreted as v4/exact-patch-v4; reconstruct current state from Source, Provider identities and Proposal instead of inferring missing bindings or establishing a migration registry. The helper's deterministic boundary is supported repository files and exact bytes; a locator alone is not proof of recoverability.
-
-## Current audits and status card
-
-Before selection/writeback and after every material revision, re-read current resources and perform three upstream audits:
-
-1. **Requirements → Resource:** every frozen active accepted changed key has the catalog's exact Delta, selected immutable resource and condition bindings. Every frozen explicit-unchanged key has exactly the catalog's resource, condition and authority-basis Source bindings. A referenced condition must belong to the selected resource's declared conditions. Missing, extra, duplicate, unresolved, distorted or falsely claimed coverage fails closed.
-2. **Resource → Requirements:** freeze every material resource-decision row and its one final disposition per binding in the checkpoint catalog. Each row binds exact Delta IDs and a separate stable binding ID plus requirement-key/Delta/origin/decision-authority/Source tuple for every key; authorization of one key never covers another. The global `(resource_ref, requirement_key, delta_id)` and `(delta_id, target_key)` identities are unique across all rows; duplicate arrays or cross-row bindings fail before any Map/Set normalization. Every active non-preserve `Delta × target` has exactly one final disposition. `proposal-written` binds one real patch operation ID. `resource-owned-exact-visual` is limited to exact visual meaning and binds one immutable selected resource, exact declared conditions and a structured `selected-source-record` or `external-immutable` owner. Rejected/superseded uses `not-adopted`; unresolved uses `unresolved` and blocks readiness. Provider success, audit choice or a selected file cannot create authority.
-3. **Unexpected Blast Radius and inactive leakage:** the catalog freezes the complete blast-radius universe, including every explicit Base exclusion, and every inactive Delta leakage row. Inspect every blast row for out-of-scope pages, controls, copy, layout, tokens and states, and every leakage row for reappearance of rejected, unresolved or superseded meaning. Missing, extra, duplicate, unexpected or unresolved rows fail closed.
-
-Provider execution, Artifact readiness and Design suitability are independent. Provider success, complete fields or repeated values never prove suitability; a valid shared Token or inherited component variant must not be rejected merely because a value repeats. Block direct/Design-Authority conflict, wrong target/condition, missing material state, placeholder-final content, unsupported added meaning, unresolved promotion, stale identity and incomplete formal closure.
-
-Derive—not restore—a status card containing Base identity; accepted/rejected/unresolved Delta; current changed and explicitly unchanged keys; Provider run identity; current live Provider execution; current Artifact readiness; freshly audited Design suitability; all three audit findings; current digest-derived writeback CAS state; and next action. A requested status card re-runs the current audits: an executing run or incomplete current resource is `blocked`, not a restored or `not-applicable` audit conclusion. The checkpoint contains none of those live conclusions.
-
-Derive status fields with one meaning each:
-
-- checkpoint: `none` when no checkpoint exists or is needed, `create` for a real interruption/pending CAS writeback, `retain` for an existing valid checkpoint, and `reject` for a proposed or existing invalid/unsupported checkpoint, input or unsafe destination;
-- write action: `none` when no Proposal writeback/promotion is pending or requested (including a recovery-availability inquiry), `preview` for a safe pending patch not yet approved for apply, `apply` only for pre-digest plus balanced audit, `idempotent-no-write` for expected-post bytes, and `block` when a requested/pending writeback is unauthorized, stale, conflicting or audit-blocked;
-- audit: `not-applicable` only when no current selected/resource surface is available to audit, `blocked` when any current audit cannot balance, and `balanced` only after all three current audits and leakage checks pass.
-
-An unauthorized meaning in a selected resource therefore blocks its Proposal promotion/writeback even if the file remains valid visual evidence; an unavailable conversation-only Base with no writeback request reports no write action.
-
-Project the decision inventory before projecting the action result. An independently Source-valid accepted Delta stays in the accepted inventory and keeps its authority row when a later patch, resource identity, condition/basis binding, audit row or final owner is invalid; those later defects block reconciliation, readiness and writeback but do not demote or erase the accepted meaning. When balanced reconciliation, promotion, handoff or writeback is requested or imminent, any duplicate identity/cross-row binding, condition/basis mismatch, illegal/multiple/unreadable final owner, inactive leakage or patch mismatch means a blocked result, blocked current audit and blocked write action—not `none` or `unavailable`—with every affected audit direction reported. If the authority Source/projection itself fails target, semantic kind, origin, meaning digest or repository identity, reject the deterministic input/checkpoint and do not accept that meaning. For a deterministic create/update input, this is checkpoint `reject` even when no prior checkpoint exists; normalizing the invalid claimed acceptance into rejected or unresolved meaning does not turn the invalid input into checkpoint `none`. Retain an existing valid checkpoint when an update/cleanup conflict or partial cleanup prevents the requested operation.
-
-Apply the table to imminent work, not only completed commands: a valid authorized Delta plus an immutable resource and a real interruption expected before writeback requires checkpoint `create` and write action `preview`; a handoff-ready request with any current audit/authority gap requires write action `block`; and frozen pre/post digests plus a balanced current audit are a pending CAS writeback requiring checkpoint `create` or `retain` and write action `apply`.
-
-## Safe writeback and reconciliation
-
-Create a writeback only when at least one frozen active binding is `proposal-written`. Freeze target locator, pre-write raw digest, exact `design-resource-exact-patch-v4`, canonical patch digest, expected post bytes/digest, selected resource identities and `proposal_written_delta_ids`. The immutable replay Base and mutable writeback target must be distinct locators; if the current Proposal itself must be updated, first use an explicitly authorized immutable Source/snapshot as Base. The exact patch universe is only the active accepted `Delta × target` bindings frozen as `proposal-written`; resource-owned exact values remain in effective requirements and audit but never enter or get copied into Proposal.
-
-Every patch operation has one unique ID, exactly one Delta, one target, one semantic binding and one `source_span` in `utf16-code-unit-v1` coordinates over the original decoded pre-write Proposal. Every non-null before/after semantics has exactly one JSON scalar leaf, and the declared local text projection must cover that leaf. Ordinary string scalars containing CR, LF, NUL or another control character are unsupported; never permit a value such as `red\npermission.admin: true` to escape its scalar carrier.
-
-For `replace`, split each local before/after text at its projected scalar. The complete prefix before the scalar and suffix after it must be character-for-character equal; only the projected scalar may change. Adding a permission line, renaming a label or deleting nearby prose inside the same operation is blocked and requires a separately authorized Delta rather than piggybacking on the scalar replacement.
-
-Free-text add/remove cannot establish non-interference. `add` requires null before semantics, preserves one exact nonempty insertion anchor and adds exactly one package-canonical single-line `ty-dra-proposal-scalar-v1` carrier plus the current uniform EOL. That carrier contains only `target_key`, `semantic_path` and the canonical JSON scalar value. `remove` projects one before leaf to null, requires empty `after_text` and deletes exactly one already canonical carrier whose target/path/value match the Delta; it cannot widen over an adjacent heading, requirement, explanation or other target. `disabled`, `removed`, `deprecated` or another non-empty substitute is new meaning requiring a separate Delta. If the current Proposal has no supported anchor/carrier, report exactly `deterministic Proposal writeback unavailable`; return a complete revised Proposal for user confirmation or retain the exact value as resource-owned instead of falling back to generic string replacement.
-
-Fail closed from the actual patch-v4 operation and Proposal bytes, not from omitted detail in a concise audit summary. A statement that an operation exactly projects its one leaf and that its anchor/carrier, preimage and expected post bytes are current is a positive claim of those named invariants unless another fact contradicts it; do not invent a missing carrier, malformed carrier or free-text fallback merely because the summary does not repeat the serialized carrier. Conversely, a claimed valid operation never overrides an observed parser, target/path/value, anchor, scaffold or span mismatch.
-
-For a decision-only review whose supplied facts are an invariant summary rather than the serialized operation, treat these as sufficient positive patch-v4 claims unless another supplied fact names a mismatch: an add with null before semantics, exactly one after scalar, `before_text` used only as a preserved structural anchor, exact after projection and current pre/post bytes; or a remove with exactly one before scalar, null after semantics, empty `after_text`, exact before projection and current post bytes in which the old `before_text` is absent. Such a positive summary is `allow`/balanced and does not itself reveal missing carrier bytes. This interpretation never relaxes create/update: when actual operation bytes are available, the helper must parse and verify the canonical carrier, anchor and source span and fail closed on any mismatch.
-
-A carrier, scaffold, projection or source-span defect is a downstream patch defect, not a new authority decision. When the Delta's Source and decision authority remain valid, preserve that Delta in `accepted_keys` and preserve its authority row while returning a blocked disposition/audit/write action and rejecting the invalid checkpoint input. Never erase or demote already accepted meaning merely to express that its proposed patch cannot be applied; only an actual Source/authority failure changes the accepted inventory.
-
-Checkpoint create/update resolves every source span against the same original Proposal before mutation. The frozen interval must equal `before_text` and both text digests, and all spans must be pairwise disjoint and non-nested; operations cannot share a character or insertion anchor. Apply sorts original spans by descending offset and replaces only those intervals, so a later operation cannot consume output generated by an earlier operation. Readback calculates each final interval from original offsets and length deltas, checks its exact output plus the whole-file expected digest and thereby conserves untouched prefix, suffix and inter-operation gaps. A source span cannot represent two independent meanings. Inactive, unknown or resource-owned bindings cannot enter the patch, and changing red semantics to purple text without changing the Delta is rejected during create/update. For an active superseder, the declared prior `before_text` projection must also be absent from the computed and reread post-write Proposal; its survival is inactive-meaning leakage. This is a bounded scalar-carrier projection proof, not general NLP entailment or arbitrary text-diff semantics. Preview before mutation:
-
-```text
-ty-context design-resource recovery preview <session> [--json]
-```
-
-Current target digest determines state:
-
-```text
-current == pre-write digest       => unapplied
-current == expected post digest   => already applied/idempotent
-otherwise                         => concurrent conflict; fail closed
-```
-
-Produce a fresh `design-resource-reconciliation-audit-v4` bound to the same Base, Design Authority, Provider run, selected resource digests, optional expected target digest, current decision sets and the checkpoint's complete audit-expectations catalog. Include Requirements→Resource, per-key Resource→Requirements, blast-radius and inactive-leakage rows. For a Proposal writeback, apply:
-
-```text
-ty-context design-resource recovery apply <session> --audit <audit.json>
-```
-
-The helper first requires a balanced fresh audit, validates checkpoint-frozen structured downstream owners and CAS, reapplies the exact patch from the frozen original spans in memory, preserves supported UTF-8/BOM or UTF-16 encoding and the existing non-mixed EOL policy, writes a same-directory exclusive temporary file, syncs it, rechecks the target, atomically renames, rereads expected bytes, verifies every operation's calculated final interval—or removed canonical carrier—plus whole-file digest, and reconciles again. An already-post state performs no write. A `selected-source-record` owner must be repository-readable at its bound digest; an external-only Provider locator stays revalidation-pending.
-
-When no binding is `proposal-written`, omit writeback and do not invent an empty patch or transaction. Re-read Source, selected resources and downstream owners and reconcile the complete catalog read-only:
-
-```text
-ty-context design-resource recovery reconcile <session> --audit <audit.json>
-```
-
-Recovery uses only generic repository snapshot/source-record identity. It does not accept a `formal-handoff-target` label, an implementation-feasibility-readiness label, duplicate either formal parser, or persist a selected production strategy. Formal Web/App input closure remains owned by `ty-context design-resource preflight`, while production ownership remains downstream.
-
-A valid resource-owned-only case may be `allow` plus `reconciliation-balanced` with `write_action: none`, but the helper-level `handoff_ready` projection remains false. Any later readiness claim waits for the Skill-owned composition of current Provider/resource revalidation, durable final ownership and applicable formal preflight; never infer readiness merely from a balanced read-only reconcile.
-
-The helper reports only `reconciliation-balanced`, `writeback-applied`, `writeback-idempotent`, `blocked` or `external-resource-revalidation-pending`. It does not report `handoff-ready`. Missing/extra/duplicate/unresolved/distorted/unsupported coverage, per-key authority mismatch, ambiguous/illegal final ownership, inactive leakage, changed explicit-unchanged meaning, unexpected blast radius or any identity mismatch returns `blocked`. A selected external resource which the helper cannot currently reread keeps external revalidation pending even after a valid Proposal writeback.
-
-Same-directory rename, filesystem durability and the remaining same-user pre-rename race are the named Windows/macOS filesystem TCB. This is not hostile-writer linearizability or crash-proof storage. Cleanup failure is explicit. The helper removes only an exact digest-matched valid checkpoint and its now-empty session directory:
-
-```text
-ty-context design-resource recovery remove <session> --expected-sha256 <sha256>
-```
-
-Before removal it inventories the session directory. It removes the checkpoint and directory only when the directory contains exactly the helper-owned digest-matched checkpoint. Any other entry returns an explicit `partial` result and preserves both the checkpoint and unowned content; a race after checkpoint removal also returns `partial` with the retained entries. It never scans or deletes unrelated `tmp`, `.work_products`, `artifacts` or reports.
-
-## Downstream boundary
-
-Proposal–Resource reconciliation is upstream diagnostic information. It never replaces the Proposal, selected immutable resources, formal handoff, downstream UI Authority Closure or project implementation checks. A later Long-Task can prove only final Source/Contract bindings, current implementation and current Evidence. Its sole Final Gate cannot prove historical Provider execution, and the checkpoint/audits/status card never enter Long-Task Source, Contract, Authority, Evidence or completion.
-
-Only the DRA Skill may derive final `handoff-ready`, and only from helper reconciliation balance plus current Provider/resource revalidation, one durable final owner per active binding, every applicable formal handoff/preflight and no unresolved blocker. This composition is not a new Gate and says nothing about Provider history, subjective optimality, arbitrary natural-language truth or completed product implementation.

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

@@ -1,290 +0,0 @@
-# Dynamic Resource Selection
-
-Use this reference to derive a bounded design-resource commission from the actual request. It is a decision model, not a fixed production sequence.
-
-## 1. Establish the scope ceiling
-
-Extract the smallest explicit output or development boundary before interpreting the background:
-
-- subject: one control/component, one region, one page, named pages, a flow or a reusable system;
-- development coverage when the resource is an implementation handoff: named surfaces/routes, regions, component families, unique controls and conditions that will actually be built;
-- platform and viewport when known;
-- modes, states and transitions explicitly requested;
-- fidelity or editability requested, if any;
-- exclusions such as “other pages not included,” “preview only,” “no Figma” or “do not update files.”
-
-Rich background improves a bounded artifact. It never authorizes more artifacts. Necessary surrounding context may show where a partial feature lives, but it does not place the rest of that page or product in scope. If the user supplies a complete app plan but asks to preview one button, generate at most the one-control resource. If the user asks for design resources for one development slice, cover that slice through its material controls and conditions, not the whole background product.
-
-When an in-scope decision exposes an outside-ceiling effect, assess and explain that effect without generating or revising the outside subjects. Return the existing `decision-required` disposition with `reason: scope-expansion-required`. The user may choose an in-scope alternative or explicitly expand scope; only then recompute the ceiling and coverage. The reason is not a new status, approval or workflow state.
-
-For page, flow or complex-control generation, recover the available authoritative constraints before deriving a commission:
-
-- target user/role and usage context reference;
-- client/host/platform, input method and relevant size classes;
-- owning Surface/Screen duty and main-versus-drilldown boundary;
-- primary task outcome, primary work object and shortest task loop;
-- material operation–affected-object–feedback relationships; and
-- critical context, state, recovery and accessibility constraints.
-
-These product and surface facts remain owned by controlling Product/Surface/Screen Source. The commission references them without becoming their owner. Separately consume `DESIGN.md` and selected exact-target/constraint Source for visual-system and selected-design conditions. Non-authoritative task-level UI/UX analysis may inform candidate comparison but cannot supply missing product or surface meaning. A feature list, screenshot, route tree, component inventory or analysis output cannot fill a missing product or surface fact; if the missing meaning materially changes the resource, return `decision-required` or request the owning Source update before Provider execution.
-
-If the desired candidate changes durable product goals/rules/capability, page duty, primary work object/task loop, information/action/feedback placement, interaction topology, Design Authority, tokens or component-family grammar, stop and route the change to the actual Product/Surface/Screen/Design owner. Reread the updated owner before resuming selection or generation. A candidate execution defect stays within DRA and does not by itself justify a durable owner change.
-
-## 2. Choose the intent
-
-| Intent | User decision being supported | Default stopping point |
-| --- | --- | --- |
-| `exploration` | “What might this look or feel like?” | Visible scoped candidate plus minimal sanity review |
-| `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 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
-
-Preserve each supplied item's actual role:
-
-- `exact-target`: already authoritative only for its declared conditions;
-- `constraint`: a rule that controls only its stated scope;
-- `inspiration`: directionally useful but not fidelity authority;
-- `current-implementation-evidence`: evidence of current behavior, not desired behavior by default;
-- `background`: product/technical context that informs but does not expand generation scope.
-
-An optional pre-existing planning document is one possible input. Raw notes or an initial proposal are equally valid. Never require a special intermediary format merely to make another input usable.
-
-### Pre-generation style-application closure
-
-Before every style-bearing Provider generation or material revision—including a simple high-fidelity preview—evaluate every current-slice style-application dimension which can materially change the output. Reuse the Provider reference's existing material-revision definition; do not create another revision classification. This closure does not apply to non-fidelity work, pure IA/flow topology, low-fidelity structure, a semantics-only state study, a read which starts no new generation, or packaging, renaming or byte-only export proved equivalent to the same canonical source.
-
-At minimum evaluate `primary_content_priority`, `density`, `container_treatment`, `visible_vs_hit_geometry`, `preserve` and `prohibited_patterns`, plus any other obvious slice-specific style-application dimension which materially affects Provider output. These are task-local judgments, not a fixed visual-property matrix or a copy of the formal handoff Fact Universe. Every applicable dimension has exactly one of these dispositions:
-
-| Disposition | Legal condition | Commission representation | Provider effect |
-| --- | --- | --- | --- |
-| `existing-covered` | Current controlling Source or a selected `exact-target`/`constraint` completely governs the exact target, slice and declared conditions and reaches the Provider through an existing input binding | Keep that Source in its existing input binding; do not duplicate it in `style_application` | Contributes to a closed commission |
-| `projected` | Current controlling Source and Design Authority already determine the slice-specific application, but selected input does not directly and completely express it | Put only the necessary current-slice field in the existing `style_application` envelope | Contributes to a closed commission |
-| `not-applicable` | The dimension has no material effect on this resource and the task-local reason is explicit | Keep the reason task-local; emit no empty or placeholder field | Contributes to a closed commission |
-| `decision-required` | Source is missing, stale, conflicting or ambiguous; a user choice is needed; delegation is insufficient; or resolution requires a durable owner change | Give the concrete natural-language reason through the existing disposition; emit no invented application meaning | Blocks the Provider run |
-
-Use `existing-covered` only when all of the following hold:
-
-1. current controlling Source or a selected `exact-target`/`constraint` explicitly specifies the dimension;
-2. the specification applies to the exact target, slice and declared conditions;
-3. the Source remains current after any owner update;
-4. the Provider commission actually carries it through existing `inputs.exact_targets`, `inputs.constraints` or the corresponding current input binding; and
-5. the conclusion requires no Agent inference from a generic style, name or visual impression.
-
-Design System identity, generic Tokens, “follow the design system”, inspiration, background, an unselected candidate, Provider output, a default-only static screenshot and current-implementation evidence do not by themselves establish `existing-covered`. Current implementation may support `preserve` only when controlling Source explicitly makes the observed behavior or visual fact a preservation constraint. A Provider must not infer missing application meaning from any of these inputs, a feature list, route tree, component inventory or task-level UI/UX analysis.
-
-For `projected`, derive only meaning already authorized by current Source and Design Authority. Do not invent product, business, interaction or design-system semantics, paste complete Tokens, copy a Provider prompt or create a persistent Projection. The actual commission envelope contains exactly the `projected` fields: omit `existing-covered` fields, keep `not-applicable` reasons task-local and never encode `decision-required` as a placeholder.
-
-The Provider run is allowed if and only if every applicable dimension is `existing-covered`, `projected` or `not-applicable`. Any `decision-required`, undispositioned dimension or Source conflict blocks commission submission and Provider execution. When resolution changes durable Product/Surface/Screen/Design meaning, use the existing owner-first route above, reread current Source and repeat this closure before resuming DRA. Post-generation Design suitability cannot retroactively repair a commission which skipped this closure.
-
-This judgment occurs inside the existing Source read and commission-envelope action. For a simple high-fidelity preview it adds no Provider generation, tool action, file, checkpoint, persistent state, fixed user pause, required extra conversation turn, formal handoff, manifest, bundle, preflight or complete Fact Universe. When all dimensions close, the same turn may still generate, perform minimal sanity/suitability review, show the candidate and receive a user choice. “Closure required” never means “emit a closure record.”
-
-## 4. Derive development-corresponding coverage
-
-For an implementation handoff, use this task-local equation:
-
-```text
-resources to commission
-  = material UI/UX decisions inside the explicit development scope
-  - decisions sufficiently covered by selected existing Source
-```
-
-A decision is material when changing it would materially change what the user sees, understands, can do or receives as feedback. Pure code structure and non-user-visible implementation choices are not design gaps.
-
-For each selected existing mapping, also name the applicable target/conditions and the meaning that must be preserved. Preservation includes current product/surface meaning, exact resource-owned visual facts, state/condition coverage and component-family or Design-System lineage which the requested change does not authorize altering. Do not treat an unchanged-looking default frame as proof that its hidden states, responsive variants or inherited dependencies are preserved.
-
-Account for the applicable meaning at each level; do not require filler for non-applicable dimensions:
-
-| Coverage level | Material UI/UX meaning |
-| --- | --- |
-| Surface/flow | information hierarchy, page/route composition, layout grid/constraints, region relationships, stacking/overlay, scrolling/overflow, navigation, branching and recovery context |
-| Visual treatment/content | typography, color, spacing, border, radius, elevation, iconography, imagery, density, exact copy/labels, formatting, localization and content presentation |
-| Component/control | anatomy, dimensions, hit area, variants, defaults, visibility/availability and mapping of repeated controls to an existing component family |
-| State/interaction | trigger/input, validation, loading/empty/success/failure/disabled/permission states, transitions, gestures, navigation result, focus/selection behavior, feedback and recovery |
-| Motion | animated property, start/end state, duration, easing, sequencing, interruption and reduced-motion behavior when motion matters |
-| Adaptation/input | viewport/breakpoint, safe area, theme/mode, platform convention, pointer/touch/keyboard behavior, orientation and content stress |
-| Accessibility | label/role, focus order/visibility, keyboard path, touch target, contrast and other applicable assistive behavior |
-| Assets | exact icons, illustrations, media, sound/haptic cues or other bespoke content whose appearance or feedback affects the result |
-
-For every material in-scope item, record one task-local disposition: `existing-covered`, `new-resource-needed`, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. This accounting is reasoning/handoff metadata, not a required file, persistent coverage registry, Design Authority or acceptance result.
-
-Existing coverage is sufficient only for the conditions it explicitly specifies or demonstrates. Seeing a control in one default page frame does not cover its variants, dynamic states, feedback, motion, responsive behavior or accessibility. Conversely, a selected component source may cover many control instances, so do not commission duplicate designs merely because several stable control keys map to it.
-
-Impact assurance has two strengths. A material/recoverable loop may use the complete current `audit_expectations`, bidirectional resource bindings, explicitly unchanged universe, blast-radius universe and inactive-Delta leakage catalog owned by [recovery-and-writeback.md](recovery-and-writeback.md). An ordinary loop without those complete bindings performs only conservative impact analysis from readable Source: mark the unverified remainder, conservatively regenerate within the ceiling or return `decision-required`. Never claim that only identified resources are affected, and never expand outside the ceiling for safety.
-
-Design resources express user-visible interaction semantics and the presentation of product rules. Business, data, permission and algorithmic rules remain owned by product/technical Source; reference those rules and show their visible consequences without inventing them or making a visual artifact their sole owner.
-
-For a Web/App implementation handoff, visual coverage alone is insufficient. Read [implementation-feasibility.md](implementation-feasibility.md) and inspect the current platform, framework/runtime, UI system, token/theming adapter, component owners and route owners. Every material component-family × target × condition profile needs a Source-backed candidate realization or blocker before formal publication. This does not make implementation structure a design decision or put exact design values into technical Source.
-
-### Formal selected Web/App handoff
-
-When—and only when—the direction is final-selected for a formal Web/App implementation handoff, load [formal-selected-web-app-handoff.md](formal-selected-web-app-handoff.md). That reference owns the complete atomic Expected Fact Universe, canonical acquisition, Inspector/Census, Fact × method proof and publication rules. Exploration never loads or approximates them.
-
-## 5. Identify independent gaps
-
-For exploration, ask what remains uncertain inside the scope. For a handoff, ask which material coverage items remain `new-resource-needed`:
-
-- **structure:** information hierarchy, layout regions or page relationships;
-- **flow:** navigation, branching, recovery or multi-step sequence;
-- **behavior:** control states, transitions, gestures, feedback, loading/error/empty/disabled cases;
-- **visual direction:** composition, typography, color, density, imagery or brand character;
-- **platform/responsiveness:** safe areas, breakpoints, input methods or viewport behavior;
-- **system reuse:** tokens, component variants or cross-surface rules needed by more than the requested artifact;
-- **team editability/native inspection:** a real need for collaborative editable frames/libraries, inspectable component/token facts or an organizational native-platform handoff.
-
-Do not manufacture a gap already resolved by selected Source.
-
-## 6. Consider resources conditionally
-
-| Resource | Select when it closes this gap | Usually omit when |
-| --- | --- | --- |
-| Control/component state study | A unique or complex control has uncovered anatomy, variants, feedback, motion or edge states | A selected page/prototype or component source explicitly specifies and demonstrates the applicable conditions |
-| Low-fidelity wireframe | Hierarchy, topology or flow must be judged without visual-style distraction | Structure is settled and only visual direction is unknown |
-| High-fidelity visual candidate | Visual hierarchy, tone or composition needs selection | Existing selected targets already govern the requested conditions |
-| Interactive prototype | Transitions, navigation, state retention or task feel must be experienced | A static decision is sufficient or the provider cannot produce genuine interaction |
-| Flow/journey board | Multiple surfaces, branches or recovery paths must be compared together | The request is one isolated surface/control |
-| Design-system slice | Several requested artifacts need shared tokens/components or reuse rules | One exploratory candidate does not justify a system |
-| Component inventory/specification | Development handoff needs explicit reusable families, variants, state behavior or mappings for several control instances | Exploration is visual only, or selected component sources already cover every mapped instance |
-| Collaborative native design input | Existing team authority, editable collaboration, native component/library reuse or organizational handoff is explicitly valuable and the connector/auth/read/export path is operational | Open Design/project-native implementation source is sufficient or the native path would create a second synchronized representation |
-| Image/illustration/icon/media study | Bespoke content materially defines the selected direction | Generic placeholders answer the present decision |
-
-A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions. One comprehensive, inspectable artifact may cover page composition and several component families; a static frame cannot claim unseen interaction or state coverage merely because all controls appear in it.
-
-Do not translate Product Control closure into one artifact per control. Artifact grouping is an authoring optimization, while the later implementation handoff still inventories every observable design fact inside those artifacts, including component parts and smaller primitives. Map ordinary controls to selected shared component variants, group related states in one component-family board or workbench, and reserve dedicated resources for unique or complex controls whose material meaning is otherwise uncovered.
-
-## 7. Assign a disposition to every considered resource
-
-- `selected`: required to close a current gap;
-- `optional`: useful, but not necessary for the current decision;
-- `not-needed`: redundant or outside the scope ceiling;
-- `unavailable`: justified but not currently supported/configured;
-- `decision-required`: a genuine unresolved preference changes the commission materially.
-
-Give one concrete reason. Do not turn `optional` into automatic extra work.
-
-## 8. Build the commission envelope
-
-The task-local envelope should contain only product-specific information:
-
-```yaml
-intent: exploration | handoff | selected-source-preparation
-scope:
-  subjects: [named surface/flow/region/component/control keys]
-  ceiling: one-control | one-region | one-page | named-pages | named-flow | system-slice
-  necessary_context: []
-  excluded: []
-  platform: known-or-unknown
-  viewports: []
-coverage:
-  material_needs: []
-  observable_fact_families: []
-  existing_mappings: []
-  preserve: []
-  required_content_visual: []
-  required_components_states: []
-  required_interactions_motion: []
-  required_adaptation_accessibility: []
-inputs:
-  product_surface_constraints: []
-  technical_sources: []
-  exact_targets: []
-  constraints: []
-  inspiration: []
-  background: []
-style_application:
-  primary_content_priority: results-table-is-primary-work-object
-  density: compact-working-density-for-results-table
-  container_treatment: one-flat-table-surface-without-card-wrapper
-  preserve: [selected-header-hierarchy]
-  prohibited_patterns: [nested-cards-around-the-primary-results-table]
-quality_commission:
-  artifact_archetype: dashboard-data-workbench
-  primary_design_challenges: [task-hierarchy, component-reuse, dense-data-legibility]
-  visual_character:
-    desired: [calm, precise, product-specific]
-    avoid: [generic-ai-gradient, excessive-cards, arbitrary-glow]
-  content:
-    real_copy_required: true
-    realistic_data_required: true
-    placeholder_final_content_forbidden: true
-  reference_roles:
-    - { ref: selected-density-reference, role: information-density }
-  component_authoring:
-    shared_families_required: true
-    repeated_instance_specific_styling_forbidden_by_design: true
-  substrate_input_refs: [dashboard-web-feasibility]
-selected_capability:
-  kind: runtime-discovered-kind
-  id: runtime-discovered-id
-expected_entry: known-or-provider-native
-review_promise: minimal-sanity | handoff-checks | selected-source-snapshot
-```
-
-This is an explanatory shape, not a required file or schema; its concrete dashboard values illustrate Source-derived content and are not defaults. Include `style_application` only when material to a style-bearing commission and bind its actual values to current Design Authority, selected Source and the explicit slice. It is not a persisted Application Projection, Authority, state or acceptance record. For style-bearing generation, add an archetype-specific `quality_commission`: name the main design challenges, desired/avoided visual character, real-content obligations, the distinct role of each selected reference, design-side shared-family expectations and applicable feasibility Source. Omit irrelevant keys instead of emitting placeholders.
-
-`repeated_instance_specific_styling_forbidden_by_design` means repeated controls in the selected resource share one component-family grammar rather than being drawn as unrelated instances. It does not assert that later production code already reuses one component. `quality_commission` is Provider input, not a persisted quality score, Authority, Gate, routing record or acceptance result. A simple high-fidelity preview does not gain another tool action or persisted side effect from these fields. Never paste or paraphrase the Open Design capability's own seed/template prompt into it.
-
-## 9. Iterate and stop
-
-- Keep each revision inside the original scope ceiling unless the user explicitly expands it; otherwise use `decision-required` with reason `scope-expansion-required`.
-- Reuse the current Open Design project when that preserves context and provenance; preserve the prior artifact hash before overwriting a selected candidate.
-- Do not create low-fi, high-fi, component boards or native-platform copies merely because a process diagram lists them.
-- For exploration, stop as soon as the requested decision is supported.
-- For a final-selected formal Web/App implementation handoff, apply the dedicated formal reference's exact stop conditions. Honest `decision_required`, `unavailable` or capability gaps remain blocking; they cannot be called ready or authorize fidelity work.
-
-During simple 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. If the loop requires durable semantic replay, a selected-Proposal file writeback or cross-interruption recovery, load [recovery-and-writeback.md](recovery-and-writeback.md) and use its independent origin/decision-authority/evidence/status model plus package helper; prompt prose alone cannot establish CAS or deterministic recovery. Ordinary conversational selection creates no approval record or deterministic cross-session promise; if it is lost before authorized materialization, reconfirm it. For a non-formal small request, explicit human selection or explicitly delegated selection may be consolidated and reconciled once in the same turn. For a selected formal Web/App handoff, defer reconciliation until the formal owner completes canonical closure and no newly visible decision returns to review. Reconcile only accepted decisions. If the Proposal exists only in conversation and safe materialization was not explicitly authorized, return one complete revised proposal and report cross-session deterministic recovery unavailable. Never create another intermediary planning document or mutate 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:** 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.
-- **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`.
-
-### Style-application worked examples
-
-#### Example A — must block
-
-A one-page high-fidelity preview has configured Design Authority but only generic Tokens. No selected `exact-target` or `constraint` specifies the page's primary-content priority, density or container treatment, and the commission has no corresponding projected fields. Generic system binding cannot fill those application decisions. Result: use the existing `decision-required` with concrete missing-Source reasons; the Provider run must not start.
-
-#### Example B — complete existing coverage may omit projection
-
-A local style-bearing revision has a current selected `exact-target` which explicitly specifies every applicable style-application dimension for the exact target and conditions, and that Source is carried through the Provider's existing exact-target input binding. Every dimension is `existing-covered`. Result: omit `style_application` rather than copying the Source, and allow the Provider run.
-
-#### Example C — mixed closure projects only the gaps
-
-The task-local dispositions are:
-
-```text
-primary_content_priority: existing-covered
-density: projected
-container_treatment: projected
-visible_vs_hit_geometry: not-applicable
-preserve: existing-covered
-prohibited_patterns: projected
-```
-
-Assume current Screen Source says the results table is the page's primary work object, current Design Authority calls for compact working density, and an adopted constraint forbids nested cards. The illustrative actual envelope contains only those three Source-derived fields:
-
-```yaml
-style_application:
-  density: compact-working-density-for-results-table
-  container_treatment: one-flat-table-surface-without-card-wrapper
-  prohibited_patterns:
-    - nested-cards-around-the-primary-results-table
-```
-
-All applicable dimensions are closed, so the Provider run is allowed. If any one of them instead becomes unresolved, stale or conflicting, its disposition becomes `decision-required` and the run is blocked.

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

@@ -1,63 +0,0 @@
----
-name: design-system-authoring
-description: Use only when the user explicitly asks to bootstrap, revise, reconcile, choose, adopt, replace or repair a project design system or design style with Open Design; asks for “初始化设计系统”, “生成设计系统”, “确定设计风格”, “采纳 Open Design 设计系统”, explicitly promotes a DRA Authority delta candidate, or invokes design-system-authoring in a Minimal Context Harness project. This capability never runs merely because DESIGN.md is missing, a project is new, DRA found a candidate delta, another Skill needs visual style, or ordinary UI work begins.
----
-
-# Design System Authoring
-
-Bootstrap, revise or reconcile an Open Design design-system candidate, obtain an explicit selection, then require a separate explicit adoption confirmation before changing the project's durable Design Authority. Installation only makes the Skill 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 DRA `authority_delta_candidate` is non-authoritative input, not permission to invoke this Skill or adopt anything. The user must explicitly start `reconcile` mode.
-- 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 the later explicit adoption confirmation distinct. A successful job, attractive preview, selected task resource or selected system candidate is not project authority.
-- Root `DESIGN.md` is the unique Authority entry and revision owner. In this bundle version its supported front matter remains the editable exact Token authority; `design_system/tokens.json` is deterministic generated output, and a sparse `design_system/authority.manifest.json` owns closure membership/digest only. Bundle adoption must insert the exact `<!-- ty-context-design-authority-format: bundle-v1 -->` line at the fixed first non-empty Markdown body position and create the manifest in the same adoption. None is a second independently editable Authority.
-- Create subordinate component/pattern/motion/platform owners only for real reusable durable rules. Never scaffold a mandatory full taxonomy.
-- 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. The package's local `@google/design.md` adapter and Authority codecs are deterministic lint/export/validation tools, not Open Design generation.
-- 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 mode and scope.** Use `bootstrap` for an unconfigured project, `revise` for an explicit current-system change, or `reconcile` for a user-promoted DRA Authority delta candidate. Capture product/brand purpose, supported surfaces/platforms, accessibility, modes, immutable constraints and supplied references. Ask only when an unresolved aesthetic or brand choice materially changes candidates and selection was not delegated.
-2. **Inspect the complete current authority.** Read core and relevant surface Context, root `DESIGN.md`, optional sparse manifest/subordinate owners, generated Tokens and provider provenance. Run read-only closure inspection. Classify `unconfigured`, `configured` or `configured-but-inconsistent` as a task-local finding, not state.
-3. **Validate reconcile input.** In `reconcile`, require the strict non-authoritative Authority Delta Assessment, validate that its `based_on` closure is still current, then use only its proposed changes, supporting resources, representative scenarios and immutable constraints. A stale packet returns to DRA reassessment.
-4. **Discover live Open Design capabilities.** Prefer structured MCP. List/read `od://design-systems/<id>/DESIGN.md`, inspect tool schemas, and feature-detect creation/revision/acceptance plus project binding. Record live provider/MCP version and fallback.
-5. **Reuse or generate candidates.** Reuse an existing provider system only when identity and meaning fit. Otherwise use a live structured creation/revision capability or the official daemon fallback. In `revise`/`reconcile`, generate bounded deltas against the current closure rather than an unrelated replacement. Keep every output a candidate.
-6. **Review representative scenarios and iterate.** Inspect candidate `DESIGN.md`, exact Token delta, sparse owner delta, preview/showcase and representative scenes. Preserve immutable constraints, migration impact, provider diagnostics and provenance. Pending revisions remain non-authoritative.
-7. **Obtain system-candidate selection.** Require explicit user/team selection, or explicit delegated selection with known criteria. Record basis, provider ID/revision and immutable digest/snapshot. Reject or leave other candidates unselected.
-8. **Stop for separate adoption confirmation.** Present the exact project-owner diff, migration impact, new/removed subordinate owners, generated Token change and affected DRA resources. Ask the user to explicitly confirm adoption of this selected system candidate. Candidate selection or an earlier page-resource approval does not satisfy this confirmation.
-9. **Adopt once after confirmation.** Follow the authority-adoption reference: update root `DESIGN.md`, insert/preserve the canonical body-leading `bundle-v1` marker, update only necessary sparse subordinate owners, deterministic generated Tokens, closure-only manifest/digest, owning Context and provider provenance. Create or remove marker and manifest only as one explicit Authority-format change. Do not copy revision or Token values into the manifest.
-10. **Rebind and synchronize.** Calculate the new complete closure identity. Rebind affected DRA resources/handoffs to it and rerun affected preflight/representative verification. Accept the selected provider revision when applicable, confirm it is readable, and verify downstream provider project binding.
-11. **Validate and report.** Run project-owned closure, Token, Context/design lint, source/package and affected DRA checks. Separately report mode, provider execution, artifact readiness, selection, explicit adoption confirmation, changed owners, old/new closure identities, rebinding, 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 supported authored exact Token values. 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;
-- `bootstrap`, `revise` or `reconcile` mode and the exact base closure identity;
-- Open Design transport/version and capabilities actually used;
-- candidate IDs and review performed;
-- explicit or delegated selection basis and separate adoption confirmation;
-- adopted `DESIGN.md`, sparse subordinate owners, generated Tokens, manifest and Context owners changed;
-- new closure identity and affected DRA rebinding/revalidation;
-- 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

@@ -1,6 +0,0 @@
-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