project-tiny-context-harness 0.11.0 → 0.12.0

package/assets/skills/design-resource-authoring/references/formal-selected-web-app-handoff.md

@@ -1,114 +0,0 @@
-# Formal Selected Web/App Implementation Handoff
-
-Read this reference only after a Web/App direction is final-selected for implementation and the user requests a formal handoff. It deliberately carries the high-cost exact closure that exploration must not load.
-
-## Admission and invariant
-
-The target needs one completely acquired machine-readable canonical entry, its exact locally resolvable dependency closure, one frozen-Inspector observable-Fact manifest and one separate real-substrate implementation-feasibility input. Derive the Expected Fact Universe and inspect current technical Source before generation; initially rendered output cannot define its own obligations or production architecture.
-
-For every selected target, establish:
-
-```text
-Expected Fact Universe
-  = Canonical Resource Facts enumerated by the frozen Inspector
-  = Handoff Indexed Facts
-```
-
-Product Controls and the eight reporting dimensions are roll-ups, not the Fact ceiling. Never sample, truncate, summarize a remainder, use pairwise coverage, infer an implicit default, broaden exclusions or let `all-states`/`complete` labels stand for atomic identities. File/model/parser/memory limits cannot weaken the universe; incompatible capacity fails closed.
-
-## Review-return boundary
-
-The prior direction selection authorizes formal preparation; it does not claim this closure is already complete. If complete universe derivation, canonical acquisition, dependency/Census inspection, implementation-feasibility inspection, manifest proof or preflight exposes a new state, component part, resource, condition, unavailable observation, visible/semantic design difference or `decision-required` choice, stop publication and return to the downstream `Design Resource Review & Selection Stop`. Re-run applicable Design suitability before asking for another selection. A technical choice among already allowed candidates stays with downstream Architecture Deliberation and does not force another visual selection. Only closure which introduces no new visible decision returns downstream for the one consolidated Proposal reconciliation.
-
-## Derive the complete universe
-
-Enumerate stable subjects and hierarchy for every in-scope Surface, flow, region, overlay/system UI, component family and instance, Control, Anatomy Part/slot, primitive, text, icon, media, asset and typed multi-subject relation. Preserve parent/instance/family/override/slot/portal/presence/population/Census lineage so a family or one instance cannot hide internal/repeated subjects.
-
-Explicitly disposition all 33 standard target-condition axes: platform, OS, device profile, form factor, exact viewport width/height, orientation, density/pixel ratio, Safe Area insets, window/fold/display/color modes, locale/language/script/direction/pseudo-localization, content/data stress, text scale/multiplier, input/assistive technology, motion/transparency/contrast/bold text/button shapes, system UI/IME, permission/capability/connectivity/lifecycle, plus scoped custom axes. Enumerate the complete applicable condition combination universe and exact Source/basis-backed exclusions. Continuous viewport/text pressure behavior exposes breakpoints, ranges, interpolation and reflow rules.
-
-For each subject enumerate `variant × state × interaction_phase × presence_phase × instance_case`, including compound precedence and conditional/lazy/virtualized/portal population. Apply the complete standard atomic property catalog across geometry, layout/scroll, typography/color/decoration/content/icon/media, interaction/navigation/motion/feedback, responsive, accessibility, assets/system and relations, plus frozen Inspector custom-property closure.
-
-The exact universe is every applicable `subject × target × condition × variation × atomic property` Fact Cell. Each cell is `covered`, source/basis-backed `not_applicable`/`excluded_by_scope`, or blocking `decision_required`/`unavailable`; every covered cell becomes one atomic Fact. Continuous motion exposes its timeline/rule rather than sampled frames.
-
-## Provider commission and acquisition
-
-Bind style-bearing work to the adopted design-system snapshot and verify the provider project reports the same identity. Commission the complete obligation universe through structured provider capability. If the provider cannot emit/read a required family, keep it blocking rather than narrowing scope.
-
-Acquire every selected file without truncation, preserve exact bytes/digests and record `implementation_web` or `implementation_app` with `acquisition: complete`. The canonical entry and all local source, token, SVG, font, image, media, worker and asset dependencies must resolve inside the frozen set. A screenshot, URL, preview or prose spec is insufficient. Technical Source and the feasibility document remain separate indexed inputs and never enter this canonical dependency set.
-
-The selected identity is the canonical source digest plus target, declared conditions and controlling Source/Design-Authority identity. A PNG, archive, renamed copy or wrapper is a derived artifact: verified equivalence to the canonical source under those bindings preserves selection, while a visible or semantic difference activates the review-return boundary above.
-
-The one per-target `design-resource-observable-fact-manifest-v1` freezes:
-
-- design-system identity and lineage;
-- Inspector identity/version/digest or named external TCB, exact capabilities, input paths/digests, complete-enumeration and dynamic-discovery policy;
-- addressable Census of every resource/node/declaration/token/asset/relation/custom property/variant/state/interaction/dynamic population item;
-- condition/variation axes, combinations and exclusions; subject hierarchy; property catalog;
-- Fact Cells/Facts, values/located digests, Source-item and design-system lineage;
-- evidence plus every Fact × property-required-method proof obligation;
-- `completeness: complete_explicit` and exactly one reporting dimension from `surface_flow`, `visual_content`, `component_control`, `state_interaction`, `motion`, `adaptation_input`, `accessibility` or `assets` for every Fact;
-- comparator, exact/tolerance parameters, optional narrow mask, Oracle and render environment;
-- asset bindings, target-local blockers and required capabilities;
-- contiguous generation chunks and exact count plus identity digest for every collection, proving non-sampling/non-truncation.
-
-Every Census item maps to exact Facts/Fact Cells or a source/basis-backed `non_material` disposition. Residual Source items index their exact Facts through `fact_refs`, while the manifest keeps separate `proof_obligations` for every Fact × required method. An Inspector `complete` Boolean, resource count or provider statement is not a Census.
-
-## Atomic Facts and proof methods
-
-Each covered Fact has exactly one subject/target/condition/variation/property, one reporting dimension, `subject|full_target` observation scope, `plain|protected` sensitivity, typed value, canonical located digest, same-condition evidence and lineage. Exact token/alias/platform/mode/state/instance overrides and resolved conflicts stay traceable. Critical values use typed locally resolvable locators for HTML/CSS/JS/JSON/Markdown/SVG or bounded whole-binary identity; they cannot live only in bitmap/prose. Exact values remain in canonical resources rather than being copied into another owner.
-
-Create a distinct proof obligation for every Fact × required verification method. Bind method-compatible evidence, comparator, exact/tolerance mode and parameters, optional mask located digest, a frozen executable or named external Oracle with the exact method capability, and a frozen render environment. A Fact needing token and pixel proof keeps both. Protected observations retain canonical ownership while downstream evidence is attributable digest-only/redacted and never persists raw sensitive values.
-
-For every `exact_target` condition include one `full_target` `layout_geometry` Fact and one `full_target` `visual_pixel` Fact with exact-target evidence. If complete visible fidelity cannot be extracted or compared, classify the resource as a constraint or blocker instead. Family feasibility coverage uses the complete transitive family subject closure, so nested Anatomy Parts, slot content, text, icons, media and assets cannot disappear merely because their own `family_ref` is null.
-
-Asset bindings identify asset subject, immutable resource, target/condition Facts, consumer subjects and density/platform/theme/mode/locale variants plus crop/focal/mask/placeholder/error/decode/fallback behavior.
-
-## Real-substrate implementation feasibility
-
-Read [implementation-feasibility.md](implementation-feasibility.md) and author one `design-resource-implementation-feasibility-v1` JSON document per target before publication. Freeze repository-relative technical Source records for platform, framework/runtime, UI system, token/theming adapter, component-owner roots and route-owner roots. Treat every unavailable or decision-required observation as target-wide across every material family × condition cell, and require observed non-empty component roots before authoring any candidate-bearing cell. Keep canonical design values exclusively in the design resources and manifest.
-
-For V1, partition the exact target condition set into non-overlapping explicit profiles. For V2, use reachable, pairwise-disjoint symbolic regions whose union equals the target's complete reachable region. Create exactly one cell for every material component family × condition profile, bind its matching V1 Facts or V2 Fact Rules, and supply at least one Source-backed feasible realization or an explicit Source-backed blocker. Every unresolved observation must be named by a blocker in every such cell; a target with no family carrier fails closed. Realizations may be composite and use several primitives; record ordered reuse/compose/extend/theme/create steps, existing or authorized planned owner candidates, supported customization surfaces, observed costs/risks and feasibility basis.
-
-Leave `required_realization` unset when more than one design-compatible implementation remains allowed. Selecting it, authorizing a planned owner or carrying a blocker requires the exact current marked technical Source Item and strict feasibility-decision projection described by the feasibility reference; a blocker and projection carry the identical unique sorted `substrate_observation_refs`, with `[]` reserved for blockers unrelated to unresolved substrate observations. A role label or same-file prose is insufficient. DRA preference, Provider output and preflight cannot create that authority. A formal `implementation_web` or `implementation_app` target cannot use descriptive `reference` mode.
-
-## Residual manifest-backed V1 publication
-
-Keep the canonical manifest as the sole complete collection index for design Facts. For each target, create one small project-native Markdown draft containing readable, uniquely keyed target-attributed `ty-source-item` facts and exactly one fenced `design-resource-handoff-v1` block with `representation: manifest_backed`. The block carries residual scope/provenance, resource identities, exactly one target/profile, `resource_fact_closure`, one `technical_feasibility_inputs` index entry, coverage and proposal binding; it never repeats manifest-owned arrays. A material resource cannot be hidden as `supporting_only`.
-
-Freeze the explicit manifest path set, target/scope identities, SHA-256 values and per-collection counts/identity digests. Choose a truthful UTF-8 byte ceiling before draft generation and ensure the authorized output parent exists. Then publish the entire target set:
-
-```text
-ty-context design-resource bundle <draft-dir> <new-output-dir> \
-  --manifest <facts.json> [--manifest <facts.json> ...] \
-  --max-handoff-bytes <bytes>
-```
-
-The command must reject embedded/full-array or multi-target drafts, over-budget descriptors, missing/extra/duplicate targets, manifest/SHA or collection-digest drift and every normalized preflight failure. It processes one target at a time in a same-volume exclusive temporary directory and atomically renames the complete set to a previously nonexistent final directory. Failure cleans only command-owned temporary data; drafts and existing/adopted handoffs remain unchanged. Validation checks an already compact representation; it never post-hoc splits a semantic target.
-
-Preflight hydrates omitted collections directly from the declared manifest bytes and runs the same full semantic validator. It also reads the indexed feasibility document and current technical Source without following links, verifies exact Source Items/projections/digests, real no-follow repository-directory owner roots, observation-kind/value rules, target-wide per-cell unresolved-observation blockers, exact blocker/projection observation-ref sets, non-vacuous family coverage, transitive family target/condition Fact or Rule coverage, owner existence/authorization and required-realization authority, and rejects any mixing with canonical resources or exact design values in feasibility prose. Visual timing values remain forbidden, while explicitly technical build/test/runtime duration prose is allowed. Unknown fields, missing/extra/duplicate Facts/proofs, unreadable resources, invalid locators, unresolved rows, stale digests, unsupported methods or unequal sets fail closed. Current blockers remain honest valid Source inputs and are reported rather than mislabeled as production readiness. `ty-context design-resource preflight <handoff.md>` remains available for inspection and older embedded-V1 read compatibility; an omitted feasibility index normalizes to `[]` and is reported as a limitation. New V1 bundle authoring requires exactly one valid feasibility input for each implementation target.
-
-## Optional symbolic V2
-
-V1 remains default. Only an explicit per-target opt-in may use `design-resource-observable-rule-manifest-v2`, `design-resource-handoff-v2` and `representation: symbolic_rules_v2`; never infer it from size/provider output/capacity.
-
-Preserve complete extensional denotation over `subject/relation × target × reachable condition/variation × applicable atomic property × population/quantifier`. Rules hold constant canonical located values, mutually exclusive exhaustive effective regions and separate Fact Rule, proof-obligation and set-valued certificate identities. Applicability may retain exact physical remainder partitions or use package-owned subject profiles plus frozen custom-property closure and explicit unique-instance exceptions; every logical point still has exactly one disposition.
-
-An omitted axis requires both Source-side and production-side proof using frozen closed-world static dependency closure, package-owned restricted-IR exact equivalence or finite complete-domain exhaustive equivalence. Dynamic/reflected/computed/unfrozen/external dependencies and representative sampling block.
-
-Each non-interference method binds a digest-identified frozen executable Oracle with exact `symbolic_noninterference.<side>.<method>` capability. Source uses one canonical non-executable `design-resource-symbolic-source-ir-v1` in complete Inspector inputs; package preflight reparses current bytes and derives and memoizes the static dependency DAG, predicate/axis-erased equivalence or complete finite evaluation. Submitted graph/predicate/evaluation/pass fields and proof artifacts are caches only and must agree with recomputation. JavaScript, CSS/implicit DOM, executable templates and dynamic/reflected/external Source block. Production is limited to package-parsed static HTML plus inert JSON. Both sides bind implementation closure/version/capability, environment, exact input paths/digests, side snapshot, scope, omitted axes, derived result, artifact and witness; Source and production proof digests are downstream certificate bindings. Extraction outside admitted representations is an explicit TCB boundary.
-
-The V1 bundle remains V1-only; directly preflight explicit V2 until a separately admitted publisher exists. V2 never lowers granularity, expands then deduplicates or proves production acceptance.
-
-## Downstream proof boundary
-
-Passing bundle/preflight proves input acquisition, integrity and exact declared-universe closure relative to the frozen Inspector/Oracle TCB—not production conformance. Its human wording is `preflight valid` / `Source bundle published`, with production conformance or readiness explicitly `not evaluated`; compatible JSON `status: ready` carries no broader meaning.
-
-The default Workflow opens actual resources, feasibility Source and conditions, routes design meaning through surface/Design Authority, chooses among allowed realization candidates in Architecture Deliberation, implements on the real production owner and performs attributable visual/interaction/accessibility/runtime checks on the final candidate. It reports blockers and unestablished conditions without reconstructing retained per-Fact result rows.
-
-An active Long-Task projects exact target Facts and Fact × method obligations into its existing Source/Claims/Assertions/bindings, `fact_expectations`, current typed `fact_results` and sole Final Gate; every result stores the actual observation and pass/fail verdict. Every marked handoff/resource/manifest is in `task.source_paths` and the applicable Check `verification_inputs`; each feasibility input follows the same existing source/check path closure. Source Items map through `source_claims` to a root conformance Assertion, and each method × condition evidence cell binds the exact handoff `fact_refs`. For every candidate-bearing cell, current component bindings must uniquely derive one allowed realization (and exactly the required one when selected). Every component binding is reverse-attributed across its complete surface to at least one allowing candidate-bearing cell. Every actual `file`/`path_glob` target and carrier, every `verified` carrier and every required planned carrier is proven path-by-path inside an observed component root; route bindings receive the same proof against observed route roots, and `not_subset`/`unknown` both fail.
-
-A standalone Contract still requires non-empty component refs. Only full activation may defer that one structural error, and Source-aware closure then admits empty refs solely when every target on the surface has all blocker-only cells, valid route closure and exact blocking authority. No feasibility, candidate/mixed/legacy targets or a fake component binding fails. Each selected planned-owner authorization, required-realization decision and blocker uses its exact current `path#source-item-key` Claim and digest rather than any same-file Claim. Blockers compile only as `decision_required` or an existing target-blocking External Confirmation covering an affected target Claim. Complete activation omits only the externally blocked design Assertions and matching Counterfactual members from machine execution; the original Contract and sole Final Gate remain authoritative, so an open confirmation reaches `blocked_external` and never `machine_accepted`. Missing, extra, ambiguous, unattributed, failed, stale or authority-drifted rows fail. This uses existing Contract fields and the sole Final Gate; it creates no feasibility Claim type, binding field or Gate.
-
-Selected resources remain Context-reachable through existing owners. Adoption never overwrites an accepted baseline: create a new immutable version and update its canonical record. This Skill creates no Contract Draft, Outcome, Progress, Evidence, Receipt, Check result or Gate.
-
-Passing closure does not itself reconcile the Proposal. Return the stable formal handoff, canonical resources and closure result to the downstream owner, which performs the sole consolidated idempotent reconciliation after confirming that no new visible decision remains.

package/assets/skills/design-resource-authoring/references/implementation-feasibility.md

@@ -1,111 +0,0 @@
-# Implementation Feasibility Source
-
-Read this reference only when DRA will commission or publish a Web/App implementation handoff against a real repository substrate. It makes implementation intent concrete without turning DRA into production architecture authority.
-
-## Boundary
-
-The canonical design resources and observable-Fact manifest remain the sole owners of exact selected design values. A separate `design-resource-implementation-feasibility-v1` JSON document records only Source-backed implementation possibilities, costs, risks and blockers. It must not copy colors, geometry, typography, motion values, content or other canonical design facts.
-
-This document is ordinary technical Source:
-
-- DRA may observe the current substrate and enumerate feasible realizations;
-- DRA may not select a production owner or require one realization from preference alone;
-- a `required_realization` needs an exact current marked `technical_obligation` Source Item decision;
-- a planned logical owner needs an exact current marked `technical_obligation` Source Item authorization;
-- every blocker needs an exact current marked `decision` or `external_confirmation` Source Item decision;
-- Default Workflow chooses among still-allowed candidates in its Architecture Deliberation and implements through the real owner;
-- Long-Task projects the document only through existing `task.source_paths`, Source claims, technical/surface bindings, Checks and Assertions; and
-- preflight validates input closure only. It never proves that production uses the candidate, renders correctly or passes acceptance.
-
-Create no implementation registry, readiness flag, workflow state, second Design Authority, new Gate or production acceptance record.
-
-## Inspect real technical Source
-
-Read repository-owned Source and code/config owners before the formal Provider commission. Record safe repository-relative path, media type, SHA-256, a resolvable whole-resource/JSON-pointer/Markdown-anchor/source-anchor locator and one or more roles. Ordinary observations and capability bases may use those locators. Planned-owner authorization, required-realization authority and blocker authority must instead use `{"kind":"source_item","value":"<marked-item-key>","text_sha256":"<current-normalized-item-digest>"}`. One current file may expose several distinct bounded locators; those records share its media type and digest, while duplicate path-plus-locator identities fail closed. Inspect all six substrate questions:
-
-1. `platform`;
-2. `framework_runtime`;
-3. `ui_system`;
-4. `token_theming_adapter`;
-5. `component_owner_roots`; and
-6. `route_owner_roots`.
-
-For a native or mapped implementation, each question appears exactly once as `observed`, `not_applicable`, `decision_required` or `unavailable`. An observed value needs matching role-bearing Source and carries no reason; every non-observed disposition carries a concrete non-empty reason and no value. `platform`, `framework_runtime` and `ui_system` use `identifier`; `component_owner_roots` and `route_owner_roots` use `repository_paths`; `token_theming_adapter` may use either. Every repository path is repository-relative, currently exists without following a symlink/junction, remains inside the repository and is a directory. Existing component owners must fall within observed component roots, and downstream route bindings must fall within observed route roots.
-
-All six observations are target-wide. Every `decision_required` or `unavailable` observation must be named in `substrate_observation_refs` by at least one blocker in every material family × condition cell. Every non-empty blocker ref must still resolve to such a current unresolved observation; `not_applicable` cannot be cited. A target-wide unresolved observation with no component-family cell fails instead of passing vacuously. Any candidate-bearing cell requires `component_owner_roots` to be `observed` with at least one current valid directory; an unresolved component root forces the affected cell to be blocker-only. Missing or conflicting material Source stays unresolved; do not infer it from the visual resource or create a speculative owner.
-
-## Exact marked technical decisions
-
-Put each authoritative feasibility decision inside its real marked Source Item as strict JSON:
-
-```html
-<!-- ty-design-feasibility-decision-v1 {"schema_version":"design-resource-feasibility-decision-v1","mode":"required_realization","target_ref":"target.main","component_family_ref":"family.button","condition_scope_sha256":"<applicability-digest>","realization_ref":"reuse-project-button"} -->
-```
-
-The one schema has three modes. `required_realization` carries `realization_ref`; `planned_owner_authorization` carries `owner_locator`; `feasibility_blocker` carries `blocker_ref` plus the required unique canonically sorted `substrate_observation_refs`. The feasibility document's blocker and its exact marked-Source projection carry identical observation-ref sets; an ordinary technical blocker uses `[]`. Every projection also carries exactly `schema_version`, `mode`, `target_ref`, `component_family_ref` and `condition_scope_sha256`, with no unknown or duplicate JSON fields. V1 hashes canonical JSON of sorted condition refs. V2 uses the current canonical compiled SHA-256 of the symbolic profile region. That binds the decision to actual applicability rather than a renameable profile key.
-
-The projection is not a new Authority. Authority is the current marked Source Item, its admitted kind, current file digest, current normalized-text digest and—under Long-Task—its exact Source Claim. Multiple non-conflicting projections may share one item; each required match is unique. A role such as `technical_authority`, an unrelated item in the same file or an imprecise path-level claim cannot substitute.
-
-Keep the feasibility document and its technical Source outside the canonical design-resource dependency set. Preflight rejects either one when mixed into `resources` or the canonical manifest closure.
-
-## Realization modes and condition partition
-
-- `native_substrate`: realizations use the project's current UI substrate and owners.
-- `mapped_substrate`: realizations map the selected design to another already authorized project substrate or adapter boundary.
-- `reference`: descriptive only. Formal `implementation_web` and `implementation_app` targets cannot use it.
-
-Treat the observed target platform and the exact condition profile as hard candidate-applicability boundaries. Browser HTML/CSS capability alone cannot support a native-App or React Native realization. An independent HTML phone frame for such a target is at most a `mapped_substrate` candidate when current capability Source proves the complete mapping; otherwise the affected family cell carries a blocker. Never relabel a renderable Web artifact as `native_substrate`.
-
-Do not force one realization across platforms or profiles. Different platform/condition profiles for the same component family may carry different candidate sets, primitives, costs, risks or blockers, provided every cell remains exact and Source-backed.
-
-V1 uses `explicit_conditions_v1`: profiles are non-empty, non-overlapping sets whose union equals the target's declared conditions. V2 uses `symbolic_regions_v2`: profiles must be reachable, pairwise disjoint and exhaustive over the target's reachable region. Never sample representative conditions or silently collapse a remainder.
-
-## Complete family coverage
-
-For every material `component_family × target × condition_profile`, author exactly one cell. Derive the family subject closure from the family subject plus direct `family_ref`/`instance_of_ref` seeds, then repeatedly add subjects whose `parent_ref`, `instance_of_ref` or `override_of_ref` points into the set until stable. Use a visited set so malformed cycles terminate. This includes instances, variants/overrides, Anatomy Parts, slots, primitives, text, icons, media and assets even when their own `family_ref` is null. Bind the cell to the complete matching canonical V1 Fact set or intersecting V2 Fact Rule set for that closure × target × profile applicability; neither omissions nor extras are legal. V1 uses the profile conditions, while V2 includes every Rule whose region intersects the profile region. Each cell contains at least one feasible realization or at least one Source-backed blocker; both may be present when a partial candidate still has a known blocking dependency. A candidate cell is invalid unless component-owner roots are observed; a blocker-only cell may retain unresolved component roots honestly.
-
-A feasible realization records:
-
-- an ordered, non-empty strategy drawn from `reuse_existing`, `compose_existing`, `extend_shared_component`, `theme_with_tokens` and `create_shared_component`;
-- the actual primitive/component candidates it uses;
-- one or more existing repository owner paths, or explicitly authorized planned logical owners;
-- the supported customization surfaces from `theme_tokens`, `component_variant`, `primitive_props`, `composition`, `content_slot`, `icon_slot`, `behavior_slot` and `style_api`;
-- Source references carrying both feasibility-basis and substrate-capability evidence; and
-- observed costs and risks without invented scores or universal ranking.
-
-Do not force one primitive, owner or single-step strategy. Composition and multi-primitive realizations are valid. Reuse is preferred only when it is genuinely feasible; creating or extending a shared component remains allowed when Source and scope support it.
-
-A blocker names the exact family, target and condition profile, carries the required unique canonically sorted `substrate_observation_refs`, cites at least one exact `source_item` record with a matching `feasibility_blocker` projection whose observation-ref set is exactly equal, and explains why no complete realization is presently supported. `[]` is valid for an ordinary technical blocker. Every non-empty ref resolves only to a current `decision_required` or `unavailable` observation, and every such target-wide observation is covered in every material cell. The Source Item kind is `decision` or `external_confirmation`. Every blocker must be referenced by its cell and every cell without a candidate must reference a blocker. A partial candidate never cancels a blocker; resolution updates technical Source and feasibility before rerunning preflight rather than adding a passing result to stale blocker Source.
-
-Run one exact-value-carrier check over every human free-text field: each substrate-observation reason, each observed cost, each observed risk and each blocker description. Hex/RGB/HSL colors, visual dimensions/angles, CSS declarations/custom properties, typography, spacing, shadows and exact visual timing remain canonical-resource values and are forbidden here. A time literal is forbidden in motion/animation/transition/duration/delay/easing/timeline/keyframe/fade/spring/stagger/enter/exit/hover/press context and also when its context is ambiguous. It is allowed only in explicit technical build/compile/bundle/generation/CI/test/startup/initialization/latency/timeout/network/benchmark/runtime-cost/render-cost context. Digests, repository paths, Source Item keys, logical primitive IDs and JSON Pointers are identities rather than prose carriers.
-
-## Required realization authority
-
-Leave `required_realization.realization_ref` null when technical Source merely permits alternatives. If current technical authority requires a specific candidate, set the exact candidate key and cite the unique matching `required_realization` projection. Every referenced planned logical owner similarly cites its unique `planned_owner_authorization` projection. The downstream Default Workflow still performs Architecture Deliberation and conformance.
-
-An active Long-Task derives the actual selection without a new Contract field. Current component bindings must uniquely derive one allowed realization for each candidate-bearing cell. Match every candidate against current `surface_binding.component_binding_refs`: an existing owner matches an `existing` file binding target or carrier path; a planned owner matches a `planned` binding key or target and its exact authorization. A required cell must derive only its required candidate. An unrequired candidate-bearing cell must derive exactly one candidate; zero is missing and more than one is ambiguous. Every component binding ref must still be consumed by at least one current-target candidate-bearing cell, while sharing remains legal where every consuming target on that surface allows the owner.
-
-Prove the full path universe of every actual component and route Binding against observed owner roots with the shared repository-pattern subset theorem. For `file` and `path_glob`, prove the target and every carrier; for `verified`, prove every carrier but not its logical target. A `planned` Binding must declare at least one carrier and receives the same proof. Each path/pattern must be a `proven_subset` of at least one exact `<observed-root>/**`; `not_subset` and `unknown` fail, so an inside target or carrier cannot hide another outside or indeterminate path. Every Long-Task design surface requires observed non-empty route roots.
-
-The standalone Contract structure validator remains strict and rejects empty `component_binding_refs`. Full activation may defer only that one structural error inside the same complete Source-aware call. It closes only when every target on the surface is backed by a feasibility document whose cells are all blocker-only, there are no component Bindings to attribute, route closure is valid and every blocker reaches its exact existing completion boundary. No feasibility document, a candidate-bearing or legacy target, a mixed surface that leaves a component Binding unattributed, or a fake component Binding fails closed.
-
-Each selected planned-owner authorization and each required-realization decision has an exact current `path#source-item-key` Source Claim; its file is in `task.source_paths`, its item digest matches, and its disposition reaches the current Outcome Claim or a Global Constraint. Each blocker item maps either to `decision_required`, which blocks compile, or to its existing target-blocking External Confirmation whose impact claims include an affected current-target Claim. Complete activation projects only those externally blocked design Assertions and their matching Counterfactual members out of machine execution; the original Contract, Source Claims, confirmation and sole Final Gate remain unchanged. The open confirmation therefore reaches only external-pending/`blocked_external`, never `machine_accepted`. Same-file or path-only Claims never substitute.
-
-## Handoff index and validation
-
-Index one document per target in `technical_feasibility_inputs`:
-
-```yaml
-technical_feasibility_inputs:
-  - key: dashboard-web-feasibility
-    target_ref: dashboard-web
-    path: design/handoffs/dashboard-web.feasibility.json
-    media_type: application/json
-    sha256: <sha256-of-current-bytes>
-```
-
-The JSON root uses `schema_version: design-resource-implementation-feasibility-v1` and contains `key`, `target_ref`, `realization_mode`, `source_records`, `substrate_observations`, `condition_model`, `component_family_cells` and `blockers`. Unknown fields, stale digests, unresolved locators, unsafe or non-directory owner roots, duplicate identities, wrong target/family/condition/Fact bindings, incomplete partitions, unresolved-observation omissions, bad/duplicate/mismatched blocker observation refs, vacuous unresolved-observation coverage, unauthorized planned owners, unauthorized required realizations or unprojected blockers fail closed.
-
-New V1 bundle publication requires exactly one valid feasibility input for every `implementation_web` or `implementation_app` target. Direct preflight keeps older handoffs readable: a missing field normalizes to an empty array and reports the explicit limitation `technical feasibility not declared`. Explicit V2 remains direct-preflight only and validates the same feasibility semantics through symbolic regions.
-
-Passing bundle or preflight establishes only that the declared technical Source is current, internally complete and compatible with the formal input identities. Human preflight output says `Design resource handoff preflight valid`, reports input closure/input-cell-blocker counts and ends with `Production conformance: not evaluated`. Bundle output says `Design resource Source bundle published` and `Production readiness: not evaluated`. The compatible JSON `status: ready` means only that validation completed. Limitations or blockers do not create another status and do not by themselves change the zero exit code for structurally valid input. Report production-owner selection and production conformance separately.

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

@@ -1,198 +0,0 @@
-# Open Design Provider Orchestration
-
-Use Open Design as the generation engine. This Skill supplies a bounded product commission and retrieves results; it does not recreate the provider's prompts, template logic or catalogue.
-
-## Execution priority
-
-1. **Structured Open Design MCP** for discovery, project/run control and artifact retrieval.
-2. **Open Design CLI or daemon API** when MCP is unavailable or cannot expose a required current capability but equivalent structured behavior is locally available.
-3. **Browser/desktop interaction** only for bootstrap, unavoidable UI-only selection, signed-in provider interaction, visual preview inspection or recovery. Prefer browser-specific control over general Computer Use when both can operate the page.
-
-Do not silently install an MCP server/plugin, alter the user's global Open Design/Codex configuration, sign in, create a paid-provider dependency or expand data disclosure. Explain the exact setup need and obtain separate authorization when persistence or a new disclosure path is required.
-
-## Live capability discovery
-
-Discover rather than remember:
-
-- configured agents and models, including whether Open Design's inner agent is Codex CLI;
-- functional skills and plugins;
-- rendering templates or project types;
-- design systems and their selected project binding;
-- specialist paths such as collaborative design platforms, image, video or 3D/WebGL;
-- supported project creation, run, cancellation, file and artifact operations.
-
-When live behavior or CLI/MCP semantics materially control the commission, retain the exact provider version and, when available, the released tag/commit plus authoritative documentation locator used for capability interpretation. A mutable default branch, remembered UI behavior or unpinned local checkout is not durable protocol evidence.
-
-Current structured tool names may include `list_agents`, `list_skills`, `list_plugins`, `create_project`, `get_project`, `get_active_context`, `start_run`, `get_run`, `cancel_run`, `list_files`, `get_file` and `get_artifact`. Feature-detect them; tool names and provider versions may evolve.
-
-Functional skills and rendering templates are different registries. Finding `frontend-design` does not prove that a `mobile-app` or `wireframe-mobile-flow` template is installed, and a remembered template ID is not live capability evidence.
-
-## Highest-performance generation selection
-
-Open Design quality takes precedence over model-call price for every formal first generation, every major revision and every final-candidate defect repair that requires material regeneration. A major revision changes the adopted visual direction or design system, cross-surface information architecture, primary interaction model, or enough of the selected canonical source/Fact manifest to invalidate the former candidate. Pure discovery, reads, resource enumeration, metadata queries and review of an already sufficient selected resource do not trigger this policy.
-
-The durable policy is `highest_available_capability + highest_supported_reasoning_effort`, not a permanent model name. Apply it immediately before each applicable run:
-
-1. Discover the live provider/tool schemas and returned agent/model metadata. Determine whether the actual run surface exposes model, reasoning-effort or service-tier inputs and which run/project/result fields can confirm their effective values. Never invent an input or result field that the provider does not expose.
-2. Filter to eligible models before ranking. Eligibility requires every tool, visual/multimodal capability, context capacity, authentication path and data-residency/disclosure boundary required by the commission. An ineligible model cannot win on nominal capability.
-3. Rank eligible models only by the provider's explicit capability order or documented recommended-replacement relation. If that is absent, the sole permitted fallback is one versioned, evidence-linked provider-local mapping owned in this reference; do not duplicate it in the main Skill, Context, README, tests or adapters. Price, model-name shape, publication date, apparent generation number and provider list order are not ranking evidence. This reference currently defines no fallback entries: when live provider evidence cannot order two or more eligible candidates, stop formal generation or major revision with `highest_performance_unverified` instead of guessing.
-4. For the selected model, use its actually declared ordered legal reasoning-effort values and select the highest supported value. Examples such as `max` or `xhigh` illustrate possible highest values; they are not a cross-provider ordering or permanent product vocabulary. If several advertised values cannot be authoritatively ordered, the highest effort is unverified and the applicable generation must fail closed.
-5. Keep service tier distinct from model capability and reasoning effort. Discover and report it when the provider exposes control or provenance, but never use price, latency tier or a service-tier label to rank model capability.
-6. When model selection is controllable, requesting anything below the proved highest eligible model is an invocation error. When reasoning is controllable, requesting anything below the proved highest supported effort is likewise an error. A missing remembered example model is not an error when live evidence selects a different actual highest model.
-7. Compare requested values with the effective model, reasoning effort and service tier reported by the completed run. A mismatch fails the run. If the provider accepts a request but does not expose effective provenance, keep the result `highest_performance_unverified`; do not claim the requested values were used.
-8. If the provider exposes reasoning control but no model control, request the proved highest effort and report that model selection could not be independently enforced. If it exposes neither control nor enough candidates to create an unresolved ranking choice, its current default generation path may be used, but the result remains `highest_performance_unverified`. If it explicitly exposes multiple eligible models and no authoritative order, rule 3 blocks the run.
-
-Capability discovery happens at call time so a provider's new highest model or effort can replace an older example without a Skill edit. This is a provider adapter policy, not a scheduler: create no persistent model registry, routing state, retry loop or cross-provider optimizer. Reduce cost by avoiding unnecessary generations, irrelevant resources and separable revisions, or by reusing a sufficient selected resource—never by lowering the generation model or effort.
-
-Repository tests can prove only that these branches remain distributed in the managed guidance. Only a normalized live provider trace that freezes provider/version, candidate and eligibility metadata, ranking authority, request fields and effective result provenance can prove the model and effort actually used. Without that trace, report the boundary as unverified.
-
-### Rendering-template discovery compatibility
-
-Prefer, in order:
-
-1. a live `list_design_templates`-style method/resource when the provider exposes one;
-2. an explicit template ID supplied by the current project/user and validated by the provider;
-3. a version-guarded structured daemon query that reads the provider's current registry;
-4. provider UI inspection when no structured registry is exposed;
-5. an honest `unavailable` or degraded-discovery result.
-
-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.
-
-### Resource-type capability matching
-
-Match the requested artifact archetype to demonstrated live capability rather than a Skill name. Distinguish at least landing/brand pages, dashboards/data workbenches, dense tables/filters/forms, mobile multi-screen flows, component workbenches, complex interaction, formal Web/App handoff and icon/illustration/media work. For every considered capability, establish the target resource type, platform, surface count, state/interaction support, real-render support, bounded revision support, canonical-source retrieval and formal-handoff coverage.
-
-A single-frame HTML phone mockup cannot claim a native mobile-App or multi-screen formal handoff. A visually strong capability without retrievable canonical Source may support exploration but not a formal implementation handoff. Give unsupported candidates `unavailable` or `not-needed`; do not wrap a partial output in a stronger profile. This matching is task-local provider adaptation, not a registry or durable ranking.
-
-## 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`.
-
-## Pre-run style-application closure
-
-Before submitting a commission or calling `start_run` for any style-bearing generation or material revision, require the task-local closure defined by [resource-selection.md](resource-selection.md). Every applicable current-slice dimension must be `existing-covered`, `projected` or `not-applicable`. A `decision-required`, undispositioned dimension or Source conflict blocks the run before Provider execution; preserve the concrete diagnostic instead of launching a speculative candidate.
-
-Validate each disposition at the adapter boundary:
-
-- `existing-covered` meaning must arrive through the current commission's existing `inputs.exact_targets`, `inputs.constraints` or corresponding input binding and must match the exact target, slice and declared conditions;
-- only `projected` meaning enters the existing `style_application` object;
-- `not-applicable` stays a reasoned task-local judgment and creates no empty field; and
-- `decision-required` stays unresolved and never becomes Provider-authored application meaning.
-
-A verified `designSystemId`, exact-value Token lineage or generic instruction to follow the system proves system binding only. It cannot prove that the current slice's hierarchy, density, container, visible-versus-hit geometry, preservation or prohibited-pattern meaning reached the Provider. The Provider must not complete missing application meaning from a feature list, route tree, generic system, component inventory, screenshot, inspiration, background or task-level UI/UX analysis.
-
-Repeat the closure immediately before each material-revision run, using the existing material-revision definition. After the resulting candidate is acquired, rerun the applicable Design suitability subchecks as the independent post-generation review. A packaging, rename or byte-only export proved equivalent to the same canonical source creates neither a new Provider run nor a new design decision. This is a fail-closed adapter precondition inside the existing commission action, not a schema, state, Authority, Gate, readiness result or Provider lifecycle.
-
-## Structured commission sequence
-
-1. Record provider version, selected agent/model, reasoning effort and service tier when exposed, functional capability, rendering template, adopted design system and relevant plugin/export readiness as reported live. For an applicable generation, retain the eligibility/ranking basis and the request-versus-effective comparison required by the highest-performance policy.
-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. Only after the pre-run style-application closure allows execution, start a run with the product-specific commission envelope, including exactly its Source-bound `projected` `style_application` fields, archetype-specific `quality_commission`, provider-native capability identifier and—when the intent is a formal Web/App implementation handoff—the complete prederived authoring obligation universe plus current implementation-substrate observations and allowed realization boundaries from [implementation-feasibility.md](implementation-feasibility.md). Fully current input-bound `existing-covered` meaning permits the style object to be omitted; `not-applicable` and `decision-required` never become empty or invented fields. The quality commission states real-copy/data needs, primary challenges, desired/avoided character, reference roles and design-side shared-family reuse without claiming production reuse. That universe is based on requested scope, product semantics, adopted design system, real technical Source and target environments; it must not be inferred only from provider output. Both application and quality fields are commission content, not a separate persistent Projection, Authority, state, routing record or Provider score.
-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.
-6. Resolve the actual entry explicitly, retrieve the artifact/source, inspect it according to intent and preserve its immutable identity before later iterations or handoff.
-
-Open Design may launch Codex CLI as its configured inner agent. That is provider execution, not recursive invocation of this outer Skill. Do not hardcode a remembered model when live discovery and authoritative ranking can select the current highest eligible model.
-
-## Separate three kinds of state
-
-### Provider execution state
-
-Examples: queued, running, succeeded, failed, cancelled, timed out or unknown.
-
-### Artifact readiness
-
-Examples: missing, partial, corrupt, retrievable, rendered or snapshot-preserved.
-
-### Design suitability
-
-Design suitability is one freshly derived umbrella review, not another state machine and never human selection. Review the applicable subchecks at intent-proportional depth:
-
-- **scope and Source suitability:** the candidate stays within the hard ceiling and follows current controlling Product/Surface/Screen/Design Source; an outside effect is reported, not generated;
-- **mechanical checks:** promised files/entries are readable, structurally usable and free of obvious corruption, broken references or intent-material runtime defects;
-- **Design-System application checks:** the verified adopted identity, exact-value/token lineage and applicable component-family rules are used rather than merely named;
-- **visual-language checks:** composition, hierarchy, typography, visual rhythm, density, container treatment, color, spacing, content realism, component treatment and other material relationships cohere with the selected Source-bound direction;
-- **distinctiveness and component-authoring checks:** the result answers the product-specific challenges without unsupported template mannerisms, and repeated controls use a coherent design-side component family rather than unrelated per-instance styling;
-- **state/condition coverage checks:** credit only demonstrated states, variations, interactions, viewports, input/accessibility conditions and assets; and
-- **preservation checks:** explicitly preserved Source meaning, exact visual facts and unaffected bindings remain unchanged.
-- **implementation-feasibility checks for formal Web/App handoff:** each material component-family × target × condition profile has at least one real-substrate realization or a Source-backed blocker, without copying exact design values into the technical feasibility document.
-
-Report applicable checked and unchecked conditions. A grounded conflict blocks; an ungrounded aesthetic preference is a candidate-comparison observation, not a fabricated Source rule. Examples of derived suitability outcomes may include `unreviewed`, `scope-source-conflict`, `revision-required` or `suitable-for-user-review`; none means selected, formally complete or handoff-ready.
-
-Never collapse these into one “success.” A provider success does not prove a good design; a complete artifact can exist even when a provider run later fails.
-
-After every material revision, rerun every applicable suitability subcheck against current Source and bytes. A material revision changes the selected visual direction or design system, cross-surface information architecture, primary interaction model, declared state/condition coverage, preservation obligation or enough canonical source/Fact meaning to invalidate the reviewed candidate. A byte-only packaging/export change proven equivalent to the same canonical source does not create a new design decision; a visible or semantic difference does. Always inspect the actual rendered candidate when the resource is renderable. If the first candidate has no material Source, feasibility, mechanical or suitability defect, it may proceed directly to user selection; never manufacture a revision quota. When repair is needed, request the smallest defect-localizing revision that preserves unaffected meaning, then reacquire and review the complete current candidate.
-
-Use these qualifiers when needed:
-
-- `artifact-ready/run-unreconciled`: a complete retrievable artifact exists, but the provider run remains nonterminal or inconsistent;
-- `artifact-ready/provider-failed`: the artifact remains complete and retrievable, but the provider later reports failure/timeout.
-
-In both cases preserve the exact run locator, last update, failure diagnostic and artifact hash. Do not claim provider success or downstream acceptance. Retry only when the promised resource is incomplete/corrupt or the user requests another attempt; do not discard a useful independently inspected artifact merely because the terminal state differs.
-
-## Implementation-level output profile
-
-Open Design has demonstrated that a complex Web page can emit a machine-readable implementation set such as `index.html`, component/design specifications, tokens and an asset manifest. Capability is not a per-run guarantee. When the selected resource will drive Web/App implementation, make this an explicit commission and retrieval invariant:
-
-1. send the complete Expected Fact Universe with the commission. It enumerates every scoped subject and hierarchy, each applicable target-condition axis/value combination, every subject-local `variant × state × interaction_phase × presence_phase × instance_case`, and every standard or justified custom atomic property. The provider must encode every applicable Fact Cell or return an exact non-applicable/excluded/unresolved disposition; `all-states`, one default render, representative samples and broad summaries are not atomic coverage;
-2. request a canonical machine-readable entry whose HTML/CSS/JS/JSON/SVG/tokens/assets or equivalent implementation sources contain the exact geometry, style, content, behavior, motion, accessibility, asset and system-condition values. One comprehensive source may carry many facts; no one-file-per-component rule is implied;
-3. require one machine-readable `design-resource-observable-fact-manifest-v1` inside the canonical dependency closure. It freezes the design-system snapshot; Inspector identity/version/digest or named external TCB and declared capabilities; exact input-resource paths/digests; complete resource/node/declaration/token/asset/relation/variant/state/interaction/dynamic-population Census; condition/variation universes and exclusions; subjects; property catalog; Fact Cells/Facts; typed value locators/digests and effective-value lineage; Fact × required-method proof obligations; evidence, comparator/tolerance/mask, Oracle and render-environment authority; assets, blockers and generation collection counts/digests;
-4. require `traversal: complete_enumeration`, fully enumerated dynamic/lazy/virtualized/portal population, `sampling: forbidden`, `truncation: forbidden` and exact deterministic chunk/count/digest closure. An Inspector `complete` Boolean or a provider claim is insufficient without its Census and identities;
-5. enumerate the complete output set and retrieve every selected entry/dependency without truncation. Preserve exact bytes, media types and SHA-256 digests in repository-local immutable files; include local source modules, styles, tokens, SVG, fonts, images, audio/video, workers and other referenced assets;
-6. record `implementation_web` or `implementation_app`, the canonical entry, every dependency, the Fact manifest and `acquisition: complete`. For Web/App output, require every locally referenced dependency discovered from the frozen source to be present in the declared target set;
-7. use stable IDs/data attributes, Markdown anchors, JSON Pointers, HTML/CSS/JS/SVG selectors, declarations, attributes or bounded whole-file binary locators that shared preflight can resolve. Critical values cannot live only in a bitmap, preview or prose summary;
-8. run the frozen Inspector and require `Expected Fact Universe = Canonical Resource Facts`. Every Census item must map to exact Fact/Fact Cell identities or a source/basis-backed `non_material` disposition. Preserve design-system token, alias, platform/mode/state/instance override and conflict-resolution lineage; exact condition profiles must include viewport geometry, pixel ratio, Safe Area insets and text-scale multiplier;
-9. exercise every property-required verification method against the canonical entry under each claimed condition. A Fact may require multiple independent methods—for example token plus pixel—and each obligation binds method-compatible evidence, comparator parameters, exact/tolerance mode, any narrow authoritative mask, Oracle identity/version/digest and frozen render environment. Compare repeated facts across code, specifications, tokens and asset manifests. Refine any mismatch; if it cannot be resolved, keep the exact Fact Cell `decision_required`/`unavailable` with a blocker;
-10. mark protected observations before downstream use. Sensitive raw UI values must not be persisted in Contract/runtime evidence: the canonical source remains the value owner while later evidence carries an attributable digest-only or redacted representation and policy reference.
-
-Alongside, author one separate `design-resource-implementation-feasibility-v1` input per target from real repository technical Source. It must use current no-follow repository directories for component/route owner roots, cover the complete transitive subject closure of every material component-family × condition profile with feasible multi-step/multi-primitive realizations or explicit blockers, and retain candidate costs/risks and customization surfaces without carrying any exact visual values in observation reasons, costs, risks or blocker prose. A decision-required/unavailable substrate observation reaches an affected cell through an exact Source-backed blocker. Leave the required realization unselected unless an exact current marked technical Source Item decision requires one; planned owners and blockers use their corresponding strict decision projections too. Provider output cannot invent any of those decisions. Never put this document or its technical Source records into the canonical resource closure.
-
-The authoring Skill then projects the exact manifest identities into the residual handoff and shared preflight enforces `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`. This is authoring source QA, never production acceptance. If the live Open Design capability cannot generate, expose or retrieve this profile, report the missing capability and keep the formal handoff blocked; provider success does not authorize a coarser replacement.
-
-A PNG may be a useful derived visual baseline, but it cannot be the sole source for implementation-level state, interaction, adaptation, accessibility or motion facts. Non-Web resources use the `reference` profile; do not manufacture HTML merely to satisfy this profile.
-
-## Explicit entry and immutable identity
-
-Provider project metadata may omit or stale its entry file. Resolve in this order:
-
-1. validate an explicit project entry path when present;
-2. enumerate project files;
-3. identify the intended provider-native entry from the current run/output rather than guessing;
-4. retrieve that exact file/artifact;
-5. preserve an SHA-256 digest or immutable snapshot before selection/handoff.
-
-A preview URL is mutable navigation, not immutable identity. It may be reported for convenience only beside project/run/entry provenance and a digest. If the user explicitly selects the resource for durable use, export or snapshot it to a user-approved location; never silently choose a repository path.
-
-## Review proportional to intent
-
-- **Exploration:** open/render the requested entry, confirm artifact count/scope and obvious corruption, perform only the decision-material suitability subchecks, then show it. Do not launch a packaging or validator sequence.
-- **Handoff:** additionally perform the method-proportional source QA above, including relevant structure, states/transitions, viewport behavior, accessibility semantics, assets, obvious console/runtime errors, requested interaction hooks, Design-System application, visual language, preservation and real-substrate implementation feasibility. State exactly what was and was not checked.
-- **Selected-source preparation:** require an independent explicit human selection basis, preserve identity/snapshot and prepare downstream metadata. Suitability informs that decision but never makes it, and still does not verify production behavior.
-
-Provider self-checks, outer artifact sanity review, user selection, formal source closure and downstream project verification are separate evidence layers. A visual-language or mechanical pass cannot independently establish Artifact readiness, selection, formal completeness, handoff readiness, native rendering, accessibility, responsive coverage, product correctness or acceptance.
-
-## Specialist paths
-
-Figma, Penpot, OpenPencil, image, video, 3D/WebGL and other providers are optional upstream producers. A Direct Agent authoring the resource is also a legal other Provider when current evidence shows that it satisfies the same bounded archetype, render, revision, canonical-source and formal-handoff capabilities; it receives no exemption from Source, Design suitability or handoff closure. Use any provider only when its collaboration/editability or native inspection value is material and its connector/auth/read/export path is operational. A listed plugin, URL, thumbnail or metadata response is not proof of usable native input. If a requested provider is unavailable, report the missing capability precisely, offer another artifact only when it preserves the requested design decision, and never relabel an export as native editable design. Every selected provider still emits repository-readable immutable resources through the same provider-neutral handoff.
-
-## Failure and recovery
-
-- Preserve provider diagnostics; do not replace failures with generated placeholders.
-- Avoid unbounded polling or repeated blind reruns.
-- Re-discover capability after provider upgrades or registry mismatches.
-- If structured paths fail but a UI artifact exists, UI inspection may recover it while retaining the degraded-provider qualifier.
-- If the provider is unavailable and no justified fallback exists, return `unavailable` with the minimum setup needed rather than generating with an unrelated image tool and calling it equivalent.
-- Provider recovery and DRA semantic recovery are separate: this reference may re-read the current run/resource identity, while [recovery-and-writeback.md](recovery-and-writeback.md) alone owns Base/Delta replay, the conditional checkpoint and Proposal CAS. Never restore a live Provider state or suitability conclusion from that checkpoint.