project-tiny-context-harness 0.8.0 → 0.8.1

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

@@ -1,136 +1,136 @@
-# Design Resource Handoff And Proposal Reconciliation
-
-Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry or authority lifecycle.
-
-## Candidate, selection and authority are separate
-
-- **Candidate:** provider output proposed for review; it authorizes no fidelity.
-- **Selection:** an explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
-- **Authority adoption:** a downstream development workflow reconciles selected Source with product/surface Context and `DESIGN.md` and binds implementation/verification to declared conditions.
-
-This Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to one. Unknown coverage remains unknown.
-
-## Development-scope coverage
-
-For every material in-scope surface/flow/region/component/control condition, record selected existing Source, newly generated Source, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. Include only necessary surrounding context and explicit exclusions. One larger addressable artifact may cover several items; a static frame covers only conditions it actually shows.
-
-Design resources may show user-visible triggers, transitions, states, feedback and product-rule presentation. Business, data, permission and algorithmic rules remain owned by product/technical Source and must not be invented by visuals.
-
+# Design Resource Handoff And Proposal Reconciliation
+
+Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry or authority lifecycle.
+
+## Candidate, selection and authority are separate
+
+- **Candidate:** provider output proposed for review; it authorizes no fidelity.
+- **Selection:** an explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
+- **Authority adoption:** a downstream development workflow reconciles selected Source with product/surface Context and `DESIGN.md` and binds implementation/verification to declared conditions.
+
+This Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to one. Unknown coverage remains unknown.
+
+## Development-scope coverage
+
+For every material in-scope surface/flow/region/component/control condition, record selected existing Source, newly generated Source, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. Include only necessary surrounding context and explicit exclusions. One larger addressable artifact may cover several items; a static frame covers only conditions it actually shows.
+
+Design resources may show user-visible triggers, transitions, states, feedback and product-rule presentation. Business, data, permission and algorithmic rules remain owned by product/technical Source and must not be invented by visuals.
+
 Canonical implementation resources own exact code-expressible layout, visual, content, state, interaction, adaptation, motion, semantic and asset facts. The structured handoff is the residual semantic and index layer for scope, applicability and downstream binding: it indexes those facts through typed locators instead of manually duplicating their values, and it is not a second numeric/style source.
-
-## Final proposal reconciliation
-
-Keep a task-local buffer during candidate iteration:
-
-```yaml
-selection_basis: explicit user/team choice | explicit delegated selection
-selected_resources:
-  - stable key, provider/project/run/entry, declared conditions, immutable digest/snapshot, editable upstream owner/locator/update method
-accepted:
-  - decision, rationale and affected proposal section/stable keys
-rejected:
-  - alternative and reason
-unresolved:
-  - genuine remaining choice
-impacts:
-  product_rules: []
-  information_hierarchy: []
-  surface_keys: []
-  control_keys: []
-  state_keys: []
-  interaction_rules: []
-  visual_constraints: []
-```
-
-This is an explanatory shape, not a schema or required file. Do not write during iteration. Once the direction is final:
-
-1. confirm the selection basis and immutable resource identity;
-2. consolidate duplicate/intermediate notes;
-3. apply accepted decisions once while preserving all unaffected original requirements and source provenance;
-4. exclude rejected and unresolved choices from requirements, keeping unresolved items visibly unresolved;
-5. record selected resource keys, conditions, immutable locators/digests and editable upstream owner/locator/update method in the proposal where downstream consumers can recover and later change them;
-6. make reruns idempotent—update the existing decision/reference instead of appending it again;
-7. if the initial proposal has an authorized writable path, edit that file; otherwise return the full revised proposal in the response.
-
-Never mutate a Source Plan, `project_context/**`, `DESIGN.md`, Delivery Contract, production code or tests. A small request may generate, select and reconcile in one turn; “once” describes final semantic writeback, not a required waiting phase.
-
-If no selection occurs, return candidates plus a consolidated pending delta and leave the proposal unchanged.
-
-## Intent-sized handoff
-
-### Exploration
-
-Return scope/intent, visible candidates, resource dispositions, obvious limitations, provider/artifact qualifiers and the sanity review performed. Do not require a pack, hash or validator for a throwaway unselected preview unless retrieval needs it.
-
-### Implementation handoff
-
+
+## Final proposal reconciliation
+
+Keep a task-local buffer during candidate iteration:
+
+```yaml
+selection_basis: explicit user/team choice | explicit delegated selection
+selected_resources:
+  - stable key, provider/project/run/entry, declared conditions, immutable digest/snapshot, editable upstream owner/locator/update method
+accepted:
+  - decision, rationale and affected proposal section/stable keys
+rejected:
+  - alternative and reason
+unresolved:
+  - genuine remaining choice
+impacts:
+  product_rules: []
+  information_hierarchy: []
+  surface_keys: []
+  control_keys: []
+  state_keys: []
+  interaction_rules: []
+  visual_constraints: []
+```
+
+This is an explanatory shape, not a schema or required file. Do not write during iteration. Once the direction is final:
+
+1. confirm the selection basis and immutable resource identity;
+2. consolidate duplicate/intermediate notes;
+3. apply accepted decisions once while preserving all unaffected original requirements and source provenance;
+4. exclude rejected and unresolved choices from requirements, keeping unresolved items visibly unresolved;
+5. record selected resource keys, conditions, immutable locators/digests and editable upstream owner/locator/update method in the proposal where downstream consumers can recover and later change them;
+6. make reruns idempotent—update the existing decision/reference instead of appending it again;
+7. if the initial proposal has an authorized writable path, edit that file; otherwise return the full revised proposal in the response.
+
+Never mutate a Source Plan, `project_context/**`, `DESIGN.md`, Delivery Contract, production code or tests. A small request may generate, select and reconcile in one turn; “once” describes final semantic writeback, not a required waiting phase.
+
+If no selection occurs, return candidates plus a consolidated pending delta and leave the proposal unchanged.
+
+## Intent-sized handoff
+
+### Exploration
+
+Return scope/intent, visible candidates, resource dispositions, obvious limitations, provider/artifact qualifiers and the sanity review performed. Do not require a pack, hash or validator for a throwaway unselected preview unless retrieval needs it.
+
+### Implementation handoff
+
 After final selection for implementation, add one project-native Markdown Source at an authorized repository path. It is ordinary Source, not a pack or Authority. Frozen canonical resources carry addressable implementation facts, while this residual handoff closes scope, applicability, uncovered meaning, product/technical semantics, blockers and downstream bindings. The file contains readable `ty-source-item:start/end` facts plus exactly one:
-
-````markdown
-```yaml design-resource-handoff-v1
-...
-```
-````
-
-The strict block includes:
-
-- output/development scope, necessary context and exclusions;
-- stable resource, subject, surface/control/state and target keys;
-- selected exact-target/constraint/supporting classification; candidates and inspiration do not enter covered implementation rows;
-- provider version, project/run, capability/template, agent/model and live design-system binding;
-- each repository-local immutable resource path, media type and exact SHA-256;
+
+````markdown
+```yaml design-resource-handoff-v1
+...
+```
+````
+
+The strict block includes:
+
+- output/development scope, necessary context and exclusions;
+- stable resource, subject, surface/control/state and target keys;
+- selected exact-target/constraint/supporting classification; candidates and inspiration do not enter covered implementation rows;
+- provider version, project/run, capability/template, agent/model and live design-system binding;
+- each repository-local immutable resource path, media type and exact SHA-256;
 - for implementation Web/App targets, a canonical entry, complete declared dependency set and `acquisition: complete`; non-Web resources use `reference` and are not forced into HTML;
-- editable upstream owner, locator and update/export method, or an explicit manual/external-update boundary when unavailable;
-- declared platform, viewport, mode, state, content, input and full/reduced/not-applicable motion conditions;
+- editable upstream owner, locator and update/export method, or an explicit manual/external-update boundary when unavailable;
+- declared platform, viewport, mode, state, content, input and full/reduced/not-applicable motion conditions;
 - typed, locally resolvable evidence locators (`html_selector`, `markdown_anchor`, `json_pointer`, `css_selector`, `css_custom_property` or bounded `whole_resource`) whose kinds distinguish frame/component variant/prototype state or transition/motion/responsive/input/accessibility/semantic/token/asset/annotation meaning;
-- stable subjects grouped only when they truly share meaning;
-- every declared scope surface represented by one unambiguous surface subject, with no stable key owned by two subjects;
+- stable subjects grouped only when they truly share meaning;
+- every declared scope surface represented by one unambiguous surface subject, with no stable key owned by two subjects;
 - explicit target applicability for each subject and complete subject × target × condition × dimension coverage for `surface_flow`, `visual_content`, `component_control`, `state_interaction`, `motion`, `adaptation_input`, `accessibility` and `assets`;
 - exactly one disposition per applicable cell: `covered`, `not_applicable`, `excluded_by_scope`, `decision_required` or `unavailable`;
 - covered-cell same-target/same-condition evidence, Source-item refs and dimension-appropriate project verification methods; referenced design Source Items use `requirement`, `control` or `acceptance` markers;
-- source-backed rationales for non-applicable/excluded rows; unresolved rows remain visible and make preflight fail;
-- target-local acceptance blockers that downstream checks must bind rather than dismiss;
-- selection basis, proposal reconciliation path/status and known limitations;
-- outer review and separate provider/artifact/design qualifiers.
-
-Unknown fields fail closed. A static frame may support only visible layout/visual/component facts for its shown condition; it cannot cover unseen interaction, motion, adaptation/input or accessibility. Run:
-
-```text
-ty-context design-resource preflight <handoff.md>
-```
-
-Do not call the handoff ready until it passes. Exploration, candidates and unselected previews still require no file, schema, hash sequence or validator. There is no fixed directory or one-file-per-control requirement.
-
-## Recommended downstream routing
-
-```text
-initial proposal
-  -> design-resource-authoring
-  -> selected immutable resources
+- source-backed rationales for non-applicable/excluded rows; unresolved rows remain visible and make preflight fail;
+- target-local acceptance blockers that downstream checks must bind rather than dismiss;
+- selection basis, proposal reconciliation path/status and known limitations;
+- outer review and separate provider/artifact/design qualifiers.
+
+Unknown fields fail closed. A static frame may support only visible layout/visual/component facts for its shown condition; it cannot cover unseen interaction, motion, adaptation/input or accessibility. Run:
+
+```text
+ty-context design-resource preflight <handoff.md>
+```
+
+Do not call the handoff ready until it passes. Exploration, candidates and unselected previews still require no file, schema, hash sequence or validator. There is no fixed directory or one-file-per-control requirement.
+
+## Recommended downstream routing
+
+```text
+initial proposal
+  -> design-resource-authoring
+  -> selected immutable resources
      + complete canonical implementation resources
-     + reconciled initial proposal
-  -> validated residual design-resource-handoff-v1
-  -> long-task-workflow (explicit long delivery)
-     OR current native Goal + default Workflow Contract (non-long delivery)
-```
-
-`source-plan-authoring` is not an intermediate stage. A legacy Source Plan remains valid ordinary Source if supplied, but design-resource authoring never creates or edits one.
-
-### Default Workflow consumption
-
+     + reconciled initial proposal
+  -> validated residual design-resource-handoff-v1
+  -> long-task-workflow (explicit long delivery)
+     OR current native Goal + default Workflow Contract (non-long delivery)
+```
+
+`source-plan-authoring` is not an intermediate stage. A legacy Source Plan remains valid ordinary Source if supplied, but design-resource authoring never creates or edits one.
+
+### Default Workflow consumption
+
 The consuming Goal brings the revised proposal, selected resources and residual handoff as ordinary Source. It reruns shared preflight before UI Authority Closure, opens affected exact/constraint resources before deciding, classifies coverage, decides `Context Delta`, and makes every adopted decision-relevant target Context-reachable through existing owners. It routes every covered Source Item and verification method through the production owner and real-entry checks. A later update creates a new immutable version rather than overwriting the adopted baseline.
-
-### Long-Task consumption
-
+
+### Long-Task consumption
+
 The same revised proposal, selected resources and validated residual handoff enter `long-task-workflow`'s Source-bound Contract Draft loop immediately. The marked handoff is `task.source_paths`; each Contract design target's frozen `source_paths` and Check `verification_inputs` equal that handoff plus every declared resource path and condition. Covered Source Items map through `source_claims` to the root conformance Assertion. Every verification method maps to an independently failing Assertion carrying its relevant Source Claims; every blocker preserves its Source-item/method lineage into a target-local machine Claim or target-blocking External Confirmation. Authority Lock, Authority Revision and Final Gate remain the sole lifecycle. This Skill creates no Contract Draft, Outcome, Receipt, Check result or Gate.
-
-## Forbidden inferences
-
-Unless independently proven downstream, never infer that a generated resource:
-
-- is selected, authoritative or accepted;
-- covers unlisted states, viewports, modes, platforms or accessibility;
-- is native implementation because an HTML/image preview renders;
+
+## Forbidden inferences
+
+Unless independently proven downstream, never infer that a generated resource:
+
+- is selected, authoritative or accepted;
+- covers unlisted states, viewports, modes, platforms or accessibility;
+- is native implementation because an HTML/image preview renders;
 - is complete because a preview, URL, metadata response, file hash or provider run exists; implementation handoff requires the declared entry/dependency closure and resolvable evidence;
-- changed Context, `DESIGN.md`, a Source Plan, code or Contract;
-- proves production fidelity, correctness, test completion or release readiness.
+- changed Context, `DESIGN.md`, a Source Plan, code or Contract;
+- proves production fidelity, correctness, test completion or release readiness.

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

@@ -1,91 +1,91 @@
-# 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;
+# 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.
-
-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.
-
-### 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.
-
-## Conditional Design Authority gate and binding
-
-Before any style-bearing commission, read project `DESIGN.md` and its declared authored exact-value token source/generation direction. Style-bearing means the resource materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Low-fidelity structure, IA/flow topology and semantics-only behavior/state studies are non-fidelity and do not require the gate.
-
-If authority is absent, explicitly `unconfigured`, still a starter, style-only/inspiration-only, or lacks one authored token source/generation direction, stop before creating a project or run. Direct the user to explicitly invoke `$design-system-authoring`; never auto-run it. A combined explicit request authorizes the sequence.
-
-For configured style-bearing work:
-
-1. read the adopted Open Design design-system ID and digest/provenance from project Design Authority;
-2. confirm `od://design-systems/<id>/DESIGN.md` is readable through MCP;
-3. pass that ID as `designSystem` to `create_project`;
-4. immediately call `get_project` and require `designSystemId` to match;
-5. when reusing a project, check its binding before every new style-bearing run;
-6. on missing/mismatch, prefer a new bounded project with the correct binding when MCP has no safe update method; otherwise feature-detect and verify the provider's structured update.
-
-Never silently use the provider's default or a different system. A provider-side mismatch is a synchronization/rebinding issue; it does not erase the canonical project `DESIGN.md`.
-
-## Structured commission sequence
-
-1. Record provider version, selected agent/model, functional capability, rendering template, adopted design system and relevant plugin/export readiness as reported live.
-2. Reuse an existing task-local project only when its scope, prior inputs and required design-system binding match; otherwise create a bounded project. For style-bearing work, pass `designSystem` and verify `get_project.designSystemId` before the run.
-3. Start a run with the product-specific commission envelope and the provider-native capability identifier.
-4. Poll with a bounded cadence. During a long run, report meaningful progress at least once per minute without flooding the user.
-5. Preserve run IDs and the latest provider diagnostic. Support cancellation when the user requests it and the provider exposes it.
-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 model when the provider can report the current configured 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
-
-Examples: unreviewed, scope-sane, handoff-checked, human-selected or rejected.
-
-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.
-
-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.
-
+- supported project creation, run, cancellation, file and artifact operations.
+
+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.
+
+### 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.
+
+## Conditional Design Authority gate and binding
+
+Before any style-bearing commission, read project `DESIGN.md` and its declared authored exact-value token source/generation direction. Style-bearing means the resource materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Low-fidelity structure, IA/flow topology and semantics-only behavior/state studies are non-fidelity and do not require the gate.
+
+If authority is absent, explicitly `unconfigured`, still a starter, style-only/inspiration-only, or lacks one authored token source/generation direction, stop before creating a project or run. Direct the user to explicitly invoke `$design-system-authoring`; never auto-run it. A combined explicit request authorizes the sequence.
+
+For configured style-bearing work:
+
+1. read the adopted Open Design design-system ID and digest/provenance from project Design Authority;
+2. confirm `od://design-systems/<id>/DESIGN.md` is readable through MCP;
+3. pass that ID as `designSystem` to `create_project`;
+4. immediately call `get_project` and require `designSystemId` to match;
+5. when reusing a project, check its binding before every new style-bearing run;
+6. on missing/mismatch, prefer a new bounded project with the correct binding when MCP has no safe update method; otherwise feature-detect and verify the provider's structured update.
+
+Never silently use the provider's default or a different system. A provider-side mismatch is a synchronization/rebinding issue; it does not erase the canonical project `DESIGN.md`.
+
+## Structured commission sequence
+
+1. Record provider version, selected agent/model, functional capability, rendering template, adopted design system and relevant plugin/export readiness as reported live.
+2. Reuse an existing task-local project only when its scope, prior inputs and required design-system binding match; otherwise create a bounded project. For style-bearing work, pass `designSystem` and verify `get_project.designSystemId` before the run.
+3. Start a run with the product-specific commission envelope and the provider-native capability identifier.
+4. Poll with a bounded cadence. During a long run, report meaningful progress at least once per minute without flooding the user.
+5. Preserve run IDs and the latest provider diagnostic. Support cancellation when the user requests it and the provider exposes it.
+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 model when the provider can report the current configured 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
+
+Examples: unreviewed, scope-sane, handoff-checked, human-selected or rejected.
+
+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.
+
+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
@@ -102,34 +102,34 @@ Open Design has demonstrated that a complex Web page can emit a machine-readable
 
 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, then show it. Do not launch a packaging or validator sequence.
+## 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, 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 and requested interaction hooks. State exactly what was and was not checked.
-- **Selected-source preparation:** require explicit human selection basis, preserve identity/snapshot, and prepare downstream metadata. It still does not verify production behavior.
-
-Provider self-checks, outer artifact sanity review and downstream project verification are separate evidence layers. Never claim native rendering, accessibility, responsive coverage, product correctness or acceptance unless the appropriate downstream project checks actually prove them.
-
+- **Selected-source preparation:** require explicit human selection basis, preserve identity/snapshot, and prepare downstream metadata. It still does not verify production behavior.
+
+Provider self-checks, outer artifact sanity review and downstream project verification are separate evidence layers. Never claim native rendering, accessibility, responsive coverage, product correctness or acceptance unless the appropriate downstream project checks actually prove them.
+
 ## Specialist paths
 
 Figma, Penpot, OpenPencil, image, video, 3D/WebGL and other providers are optional upstream producers. Use one 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.
+
+## 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.