project-tiny-context-harness 0.8.13 → 0.8.17

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

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

@@ -21,6 +21,8 @@ Discover rather than remember:
 - 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.
@@ -56,6 +58,12 @@ Prefer, in order:
 
 Never vendor a fallback template catalogue or guess a template ID from prior runs. Do not implement a transport helper unless the live host truly lacks a safe structured path; any helper may normalize metadata and transport only.
 
+### 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.
@@ -73,11 +81,26 @@ For configured style-bearing work:
 
 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. Start a run with the product-specific commission envelope, provider-native capability identifier and—when the intent is a formal Web/App implementation handoff—the complete prederived authoring obligation universe. That universe is based on requested scope, product semantics, adopted design system and target environments; it must not be inferred only from provider output.
+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.
@@ -96,10 +119,23 @@ Examples: missing, partial, corrupt, retrievable, rendered or snapshot-preserved
 
 ### Design suitability
 
-Examples: unreviewed, scope-sane, handoff-checked, human-selected or rejected.
+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;
@@ -122,6 +158,8 @@ Open Design has demonstrated that a complex Web page can emit a machine-readable
 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.
@@ -140,15 +178,15 @@ A preview URL is mutable navigation, not immutable identity. It may be reported
 
 ## 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.
+- **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 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.
+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. 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.
+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
 

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

@@ -6,6 +6,10 @@ Load this reference only for a material generation/revision loop which needs com
 
 A simple scoped preview creates zero recovery files and persisted recovery bytes, adds no user pause or Provider generation beyond the one requested commission, runs no formal handoff/preflight, performs no Proposal writeback and opens no helper write transaction. Its ordinary requested preview is the commission itself; recovery adds and reports zero tool actions. Keep its temporary reasoning in the current turn.
 
+Ordinary conversational review and selection remains legal outside this deterministic path. It creates no approval record or persistent selection state and must be reconfirmed if lost before authorized materialization. Deterministic cross-interruption selection uses only the existing raw-digest-bound marked Source, `ty-dra-authority-v1`, selected-resource binding and conditional checkpoint below; do not invent `review_set_id`, approval status or another checkpoint kind.
+
+Without the complete bindings below, an ordinary loop may report only conservative impact analysis from readable Source, identify unverified scope and regenerate conservatively within the hard ceiling or return `decision-required`. It cannot claim that only identified resources are affected. When this recoverable path has a complete current catalog, change and preservation claims remain bounded to its exact Requirements-to-Resource, Resource-to-Requirements, explicitly unchanged, blast-radius and inactive-leakage universes.
+
 Use a recovery checkpoint only when interruption would otherwise lose material accepted/rejected/unresolved semantics, immutable Provider identity or a pending CAS writeback. It is versioned, ignored, task-local, non-authoritative and deletable. It is not Source, Context, a Contract, Authority, Evidence, Receipt, Gate, Provider registry, scheduler, acceptance state or completion conclusion. There is no global session registry, event log, heartbeat, polling loop or state-machine service.
 
 For deterministic classification, apply four fail-closed invariants before details: validate every semantic key independently; retain every valid accepted/rejected/unresolved decision and its authority row even when a later patch, audit or owner fails; reject deterministic checkpoint input whose claimed Source authority is invalid; and report a requested or pending unsafe reconciliation/writeback as blocked rather than as no action. Provider/resource selection never fills a missing authority row, and one key's authority never covers another key.
@@ -80,6 +84,8 @@ Never use a prior Agent summary or generated resource as the next Base. Missing
 
 Prepare one disclosure-reviewed JSON input using schema `design-resource-recovery-input-v4`, including session identity, Base, `authority_sources`, delegations/Deltas, exact accepted/rejected/unresolved sets, current Design Authority identity, immutable Provider project/run/resource references, `selected_resource_bindings`, one frozen `audit_expectations` catalog and optional writeback. The catalog owns the exact changed, unchanged, resource-decision, blast-radius and inactive-leakage row expectations, including Delta/resource/condition/basis/binding identities. Every resource-decision binding freezes one and only one `final_disposition`: `proposal-written` with its exact operation ID, `resource-owned-exact-visual` with its selected resource/conditions/structured owner, `not-adopted` for rejected or superseded meaning, or `unresolved` for unresolved meaning. Audit observes and verifies this owner; it never selects it. Changing an owner requires checkpoint `update` with digest CAS. The catalog is the only checkpoint audit-universe/owner owner; current audit rows must be set-equal to it rather than merely non-empty. Selected resource bindings declare one unique resource key, generic `repository-snapshot` or `external-immutable` identity, locator, raw-byte digest and exact condition identities. Arbitrary condition strings and duplicate identities fail closed.
 
+The existing selected-resource, condition, Design-Authority and authority-Source fields jointly bind deterministic selection to the canonical selected-source digest, target, declared conditions and controlling Source/Design-Authority identity; no new selection field or status is added. Preview URLs, names and exports are derived outputs. A proved equivalent export does not change the selection binding, while a visible or semantic difference requires a new user review/selection and, when retained here, the existing digest-CAS checkpoint update.
+
 Create/retain a checkpoint for a real interruption or pending CAS writeback; use `none` when neither exists, and `reject` when a requested new checkpoint, input, destination or existing checkpoint cannot be admitted. Never turn an invalid authority request into `none` merely because no file was written. Then explicitly create it when required:
 
 ```text
@@ -178,7 +184,7 @@ When no binding is `proposal-written`, omit writeback and do not invent an empty
 ty-context design-resource recovery reconcile <session> --audit <audit.json>
 ```
 
-Recovery uses only generic repository snapshot/source-record identity. It does not accept a `formal-handoff-target` label or duplicate the formal handoff parser; formal Web/App handoff readiness remains owned by `ty-context design-resource preflight`.
+Recovery uses only generic repository snapshot/source-record identity. It does not accept a `formal-handoff-target` label, an implementation-feasibility-readiness label, duplicate either formal parser, or persist a selected production strategy. Formal Web/App input closure remains owned by `ty-context design-resource preflight`, while production ownership remains downstream.
 
 A valid resource-owned-only case may be `allow` plus `reconciliation-balanced` with `write_action: none`, but the helper-level `handoff_ready` projection remains false. Any later readiness claim waits for the Skill-owned composition of current Provider/resource revalidation, durable final ownership and applicable formal preflight; never infer readiness merely from a balanced read-only reconcile.
 

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

@@ -15,6 +15,21 @@ Extract the smallest explicit output or development boundary before interpreting
 
 Rich background improves a bounded artifact. It never authorizes more artifacts. Necessary surrounding context may show where a partial feature lives, but it does not place the rest of that page or product in scope. If the user supplies a complete app plan but asks to preview one button, generate at most the one-control resource. If the user asks for design resources for one development slice, cover that slice through its material controls and conditions, not the whole background product.
 
+When an in-scope decision exposes an outside-ceiling effect, assess and explain that effect without generating or revising the outside subjects. Return the existing `decision-required` disposition with `reason: scope-expansion-required`. The user may choose an in-scope alternative or explicitly expand scope; only then recompute the ceiling and coverage. The reason is not a new status, approval or workflow state.
+
+For page, flow or complex-control generation, recover the available authoritative constraints before deriving a commission:
+
+- target user/role and usage context reference;
+- client/host/platform, input method and relevant size classes;
+- owning Surface/Screen duty and main-versus-drilldown boundary;
+- primary task outcome, primary work object and shortest task loop;
+- material operation–affected-object–feedback relationships; and
+- critical context, state, recovery and accessibility constraints.
+
+These product and surface facts remain owned by controlling Product/Surface/Screen Source. The commission references them without becoming their owner. Separately consume `DESIGN.md` and selected exact-target/constraint Source for visual-system and selected-design conditions. Non-authoritative task-level UI/UX analysis may inform candidate comparison but cannot supply missing product or surface meaning. A feature list, screenshot, route tree, component inventory or analysis output cannot fill a missing product or surface fact; if the missing meaning materially changes the resource, return `decision-required` or request the owning Source update before Provider execution.
+
+If the desired candidate changes durable product goals/rules/capability, page duty, primary work object/task loop, information/action/feedback placement, interaction topology, Design Authority, tokens or component-family grammar, stop and route the change to the actual Product/Surface/Screen/Design owner. Reread the updated owner before resuming selection or generation. A candidate execution defect stays within DRA and does not by itself justify a durable owner change.
+
 ## 2. Choose the intent
 
 | Intent | User decision being supported | Default stopping point |
@@ -44,6 +59,35 @@ Preserve each supplied item's actual role:
 
 An optional pre-existing planning document is one possible input. Raw notes or an initial proposal are equally valid. Never require a special intermediary format merely to make another input usable.
 
+### Pre-generation style-application closure
+
+Before every style-bearing Provider generation or material revision—including a simple high-fidelity preview—evaluate every current-slice style-application dimension which can materially change the output. Reuse the Provider reference's existing material-revision definition; do not create another revision classification. This closure does not apply to non-fidelity work, pure IA/flow topology, low-fidelity structure, a semantics-only state study, a read which starts no new generation, or packaging, renaming or byte-only export proved equivalent to the same canonical source.
+
+At minimum evaluate `primary_content_priority`, `density`, `container_treatment`, `visible_vs_hit_geometry`, `preserve` and `prohibited_patterns`, plus any other obvious slice-specific style-application dimension which materially affects Provider output. These are task-local judgments, not a fixed visual-property matrix or a copy of the formal handoff Fact Universe. Every applicable dimension has exactly one of these dispositions:
+
+| Disposition | Legal condition | Commission representation | Provider effect |
+| --- | --- | --- | --- |
+| `existing-covered` | Current controlling Source or a selected `exact-target`/`constraint` completely governs the exact target, slice and declared conditions and reaches the Provider through an existing input binding | Keep that Source in its existing input binding; do not duplicate it in `style_application` | Contributes to a closed commission |
+| `projected` | Current controlling Source and Design Authority already determine the slice-specific application, but selected input does not directly and completely express it | Put only the necessary current-slice field in the existing `style_application` envelope | Contributes to a closed commission |
+| `not-applicable` | The dimension has no material effect on this resource and the task-local reason is explicit | Keep the reason task-local; emit no empty or placeholder field | Contributes to a closed commission |
+| `decision-required` | Source is missing, stale, conflicting or ambiguous; a user choice is needed; delegation is insufficient; or resolution requires a durable owner change | Give the concrete natural-language reason through the existing disposition; emit no invented application meaning | Blocks the Provider run |
+
+Use `existing-covered` only when all of the following hold:
+
+1. current controlling Source or a selected `exact-target`/`constraint` explicitly specifies the dimension;
+2. the specification applies to the exact target, slice and declared conditions;
+3. the Source remains current after any owner update;
+4. the Provider commission actually carries it through existing `inputs.exact_targets`, `inputs.constraints` or the corresponding current input binding; and
+5. the conclusion requires no Agent inference from a generic style, name or visual impression.
+
+Design System identity, generic Tokens, “follow the design system”, inspiration, background, an unselected candidate, Provider output, a default-only static screenshot and current-implementation evidence do not by themselves establish `existing-covered`. Current implementation may support `preserve` only when controlling Source explicitly makes the observed behavior or visual fact a preservation constraint. A Provider must not infer missing application meaning from any of these inputs, a feature list, route tree, component inventory or task-level UI/UX analysis.
+
+For `projected`, derive only meaning already authorized by current Source and Design Authority. Do not invent product, business, interaction or design-system semantics, paste complete Tokens, copy a Provider prompt or create a persistent Projection. The actual commission envelope contains exactly the `projected` fields: omit `existing-covered` fields, keep `not-applicable` reasons task-local and never encode `decision-required` as a placeholder.
+
+The Provider run is allowed if and only if every applicable dimension is `existing-covered`, `projected` or `not-applicable`. Any `decision-required`, undispositioned dimension or Source conflict blocks commission submission and Provider execution. When resolution changes durable Product/Surface/Screen/Design meaning, use the existing owner-first route above, reread current Source and repeat this closure before resuming DRA. Post-generation Design suitability cannot retroactively repair a commission which skipped this closure.
+
+This judgment occurs inside the existing Source read and commission-envelope action. For a simple high-fidelity preview it adds no Provider generation, tool action, file, checkpoint, persistent state, fixed user pause, required extra conversation turn, formal handoff, manifest, bundle, preflight or complete Fact Universe. When all dimensions close, the same turn may still generate, perform minimal sanity/suitability review, show the candidate and receive a user choice. “Closure required” never means “emit a closure record.”
+
 ## 4. Derive development-corresponding coverage
 
 For an implementation handoff, use this task-local equation:
@@ -56,6 +100,8 @@ resources to commission
 
 A decision is material when changing it would materially change what the user sees, understands, can do or receives as feedback. Pure code structure and non-user-visible implementation choices are not design gaps.
 
+For each selected existing mapping, also name the applicable target/conditions and the meaning that must be preserved. Preservation includes current product/surface meaning, exact resource-owned visual facts, state/condition coverage and component-family or Design-System lineage which the requested change does not authorize altering. Do not treat an unchanged-looking default frame as proof that its hidden states, responsive variants or inherited dependencies are preserved.
+
 Account for the applicable meaning at each level; do not require filler for non-applicable dimensions:
 
 | Coverage level | Material UI/UX meaning |
@@ -73,8 +119,12 @@ For every material in-scope item, record one task-local disposition: `existing-c
 
 Existing coverage is sufficient only for the conditions it explicitly specifies or demonstrates. Seeing a control in one default page frame does not cover its variants, dynamic states, feedback, motion, responsive behavior or accessibility. Conversely, a selected component source may cover many control instances, so do not commission duplicate designs merely because several stable control keys map to it.
 
+Impact assurance has two strengths. A material/recoverable loop may use the complete current `audit_expectations`, bidirectional resource bindings, explicitly unchanged universe, blast-radius universe and inactive-Delta leakage catalog owned by [recovery-and-writeback.md](recovery-and-writeback.md). An ordinary loop without those complete bindings performs only conservative impact analysis from readable Source: mark the unverified remainder, conservatively regenerate within the ceiling or return `decision-required`. Never claim that only identified resources are affected, and never expand outside the ceiling for safety.
+
 Design resources express user-visible interaction semantics and the presentation of product rules. Business, data, permission and algorithmic rules remain owned by product/technical Source; reference those rules and show their visible consequences without inventing them or making a visual artifact their sole owner.
 
+For a Web/App implementation handoff, visual coverage alone is insufficient. Read [implementation-feasibility.md](implementation-feasibility.md) and inspect the current platform, framework/runtime, UI system, token/theming adapter, component owners and route owners. Every material component-family × target × condition profile needs a Source-backed candidate realization or blocker before formal publication. This does not make implementation structure a design decision or put exact design values into technical Source.
+
 ### Formal selected Web/App handoff
 
 When—and only when—the direction is final-selected for a formal Web/App implementation handoff, load [formal-selected-web-app-handoff.md](formal-selected-web-app-handoff.md). That reference owns the complete atomic Expected Fact Universe, canonical acquisition, Inspector/Census, Fact × method proof and publication rules. Exploration never loads or approximates them.
@@ -138,15 +188,40 @@ coverage:
   material_needs: []
   observable_fact_families: []
   existing_mappings: []
+  preserve: []
   required_content_visual: []
   required_components_states: []
   required_interactions_motion: []
   required_adaptation_accessibility: []
 inputs:
+  product_surface_constraints: []
+  technical_sources: []
   exact_targets: []
   constraints: []
   inspiration: []
   background: []
+style_application:
+  primary_content_priority: results-table-is-primary-work-object
+  density: compact-working-density-for-results-table
+  container_treatment: one-flat-table-surface-without-card-wrapper
+  preserve: [selected-header-hierarchy]
+  prohibited_patterns: [nested-cards-around-the-primary-results-table]
+quality_commission:
+  artifact_archetype: dashboard-data-workbench
+  primary_design_challenges: [task-hierarchy, component-reuse, dense-data-legibility]
+  visual_character:
+    desired: [calm, precise, product-specific]
+    avoid: [generic-ai-gradient, excessive-cards, arbitrary-glow]
+  content:
+    real_copy_required: true
+    realistic_data_required: true
+    placeholder_final_content_forbidden: true
+  reference_roles:
+    - { ref: selected-density-reference, role: information-density }
+  component_authoring:
+    shared_families_required: true
+    repeated_instance_specific_styling_forbidden_by_design: true
+  substrate_input_refs: [dashboard-web-feasibility]
 selected_capability:
   kind: runtime-discovered-kind
   id: runtime-discovered-id
@@ -154,17 +229,19 @@ expected_entry: known-or-provider-native
 review_promise: minimal-sanity | handoff-checks | selected-source-snapshot
 ```
 
-This is an explanatory shape, not a required file or schema. Never paste or paraphrase the Open Design capability's own seed/template prompt into it.
+This is an explanatory shape, not a required file or schema; its concrete dashboard values illustrate Source-derived content and are not defaults. Include `style_application` only when material to a style-bearing commission and bind its actual values to current Design Authority, selected Source and the explicit slice. It is not a persisted Application Projection, Authority, state or acceptance record. For style-bearing generation, add an archetype-specific `quality_commission`: name the main design challenges, desired/avoided visual character, real-content obligations, the distinct role of each selected reference, design-side shared-family expectations and applicable feasibility Source. Omit irrelevant keys instead of emitting placeholders.
+
+`repeated_instance_specific_styling_forbidden_by_design` means repeated controls in the selected resource share one component-family grammar rather than being drawn as unrelated instances. It does not assert that later production code already reuses one component. `quality_commission` is Provider input, not a persisted quality score, Authority, Gate, routing record or acceptance result. A simple high-fidelity preview does not gain another tool action or persisted side effect from these fields. Never paste or paraphrase the Open Design capability's own seed/template prompt into it.
 
 ## 9. Iterate and stop
 
-- Keep each revision inside the original scope ceiling unless the user explicitly expands it.
+- Keep each revision inside the original scope ceiling unless the user explicitly expands it; otherwise use `decision-required` with reason `scope-expansion-required`.
 - Reuse the current Open Design project when that preserves context and provenance; preserve the prior artifact hash before overwriting a selected candidate.
 - Do not create low-fi, high-fi, component boards or native-platform copies merely because a process diagram lists them.
 - For exploration, stop as soon as the requested decision is supported.
 - For a final-selected formal Web/App implementation handoff, apply the dedicated formal reference's exact stop conditions. Honest `decision_required`, `unavailable` or capability gaps remain blocking; they cannot be called ready or authorize fidelity work.
 
-During simple iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. If the loop requires durable semantic replay, a selected-Proposal file writeback or cross-interruption recovery, load [recovery-and-writeback.md](recovery-and-writeback.md) and use its independent origin/decision-authority/evidence/status model plus package helper; prompt prose alone cannot establish CAS or deterministic recovery. After explicit human selection or explicitly delegated selection, consolidate the buffer once and reconcile only accepted decisions into the initial proposal. If it exists only in conversation and safe materialization was not explicitly authorized, return one complete revised proposal and report cross-session deterministic recovery unavailable. Never create another intermediary planning document or mutate Context, `DESIGN.md`, code, tests or Contract.
+During simple iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. If the loop requires durable semantic replay, a selected-Proposal file writeback or cross-interruption recovery, load [recovery-and-writeback.md](recovery-and-writeback.md) and use its independent origin/decision-authority/evidence/status model plus package helper; prompt prose alone cannot establish CAS or deterministic recovery. Ordinary conversational selection creates no approval record or deterministic cross-session promise; if it is lost before authorized materialization, reconfirm it. For a non-formal small request, explicit human selection or explicitly delegated selection may be consolidated and reconciled once in the same turn. For a selected formal Web/App handoff, defer reconciliation until the formal owner completes canonical closure and no newly visible decision returns to review. Reconcile only accepted decisions. If the Proposal exists only in conversation and safe materialization was not explicitly authorized, return one complete revised proposal and report cross-session deterministic recovery unavailable. Never create another intermediary planning document or mutate Context, `DESIGN.md`, code, tests or Contract.
 
 ## Worked scope examples
 
@@ -176,3 +253,38 @@ During simple iteration, keep accepted, rejected and unresolved implications in
 - **Three-screen interaction flow:** select a low-fi flow and an interactive high-fi prototype only if topology and interaction/visual behavior are independently unresolved.
 - **Local style fix with exact target:** select no new design resource and route to implementation.
 - **Initial proposal before execution:** iterate only requested candidates, keep one task-local delta buffer, then after selection reconcile accepted decisions once. Pass the revised proposal plus selected immutable resources directly to the default Goal or `long-task-workflow`.
+
+### Style-application worked examples
+
+#### Example A — must block
+
+A one-page high-fidelity preview has configured Design Authority but only generic Tokens. No selected `exact-target` or `constraint` specifies the page's primary-content priority, density or container treatment, and the commission has no corresponding projected fields. Generic system binding cannot fill those application decisions. Result: use the existing `decision-required` with concrete missing-Source reasons; the Provider run must not start.
+
+#### Example B — complete existing coverage may omit projection
+
+A local style-bearing revision has a current selected `exact-target` which explicitly specifies every applicable style-application dimension for the exact target and conditions, and that Source is carried through the Provider's existing exact-target input binding. Every dimension is `existing-covered`. Result: omit `style_application` rather than copying the Source, and allow the Provider run.
+
+#### Example C — mixed closure projects only the gaps
+
+The task-local dispositions are:
+
+```text
+primary_content_priority: existing-covered
+density: projected
+container_treatment: projected
+visible_vs_hit_geometry: not-applicable
+preserve: existing-covered
+prohibited_patterns: projected
+```
+
+Assume current Screen Source says the results table is the page's primary work object, current Design Authority calls for compact working density, and an adopted constraint forbids nested cards. The illustrative actual envelope contains only those three Source-derived fields:
+
+```yaml
+style_application:
+  density: compact-working-density-for-results-table
+  container_treatment: one-flat-table-surface-without-card-wrapper
+  prohibited_patterns:
+    - nested-cards-around-the-primary-results-table
+```
+
+All applicable dimensions are closed, so the Provider run is allowed. If any one of them instead becomes unresolved, stale or conflicting, its disposition becomes `decision-required` and the run is blocked.

package/assets/skills/long-task-workflow/SKILL.md

@@ -13,9 +13,9 @@ That Goal is host/user-selected; Harness does not create, persist or reconnect a
 
 The host/user owns model selection. Exactly one unconditional terminal-turn checkpoint follows the first Authority Lock before implementation. Harness neither switches nor verifies the model, persists checkpoint/acknowledgement/route state, nor creates a model scheduler, automatic switch or native-Goal completion state. Do not otherwise pause a healthy Goal solely to change models.
 
-A Codex-root `long-task` install may expose optional fixed package-owned `long_task_implementation` with child multi-agent disabled. It is static, stateless, non-Authority and post-checkpoint—not a checkpoint option, model route or runtime. Install proves no discovery or selection. If unavailable/invalid/colliding or not exactly selectable, the parent implements; never substitute a generic child or add dynamic tiers, retry or scheduling.
+A Codex-root `long-task` install may expose fixed package-owned `long_task_implementation` with child agents disabled. It is static, stateless, non-Authority and post-checkpoint; install proves neither selection nor effective model/reasoning/tier. Profile and spawn never set `service_tier`. Exact-call or capability failure returns a packet to the parent; never infer it, use a generic child, or add tiers/retry/scheduling.
 
-`long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the one root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. Legacy split-delivery commands are non-executing.
+`long-task-delivery-v2` is the active Contract schema. `delivery-contract.yaml` is the root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are compatibility only. Legacy split-delivery commands are non-executing.
 
 ## Controlling Objective
 
@@ -25,9 +25,11 @@ Complete Source is not a prose or current-code ceiling. Material non-UI meaning
 
 Only fresh evidence from the complete current final snapshot may create machine acceptance. Exactly fresh `machine_accepted` with no pending External Confirmation is `AcceptedDeliveryTerminal`; `machine_accepted_external_pending` proves only declared machine scope. Progress is repair evidence only and never acceptance authority. Final Gate is the sole Long-Task Engineering Quality Conformance and Architecture Conformance carrier, and it proves only the declared, falsifiable, project-check-bound set—not overall code quality. This adds no quality Boolean, matrix, Source aspect, Claim/risk kind, Contract field, second Gate, state or Receipt, and no separate default Contract Conformance closure runs.
 
-Anti-Degradation Assurance preserves coverage, false-negative resistance, fail-closed Authority and final-snapshot proof before cost. Purpose/invariant replacement requires project-owner design-purpose decision and replacement proof. `F = Implementation Freedom Boundary` keeps order, methods and feedback Goal-owned within Source/Contract, architecture, safety, forbidden shortcuts and external actions. After the checkpoint, one ephemeral Delegation Suitability judgment may use one or more `long_task_implementation` instances only when the host explicitly selects that exact custom agent and independent benefit exceeds coordination cost. Generic/built-in/null/unknown roles, task names, prompt imitation and model-only selection never qualify. If unavailable or an exposed spawned type differs, never rely on/retry a generic child; the parent executes or independently redoes the packet. Prefer read-heavy exploration/entrypoint location, independent diagnosis and log/test analysis, disjoint-path implementation/targeted verification and bounded repetitive work. Parallel writes require disjoint owner/path/source-of-truth scope; shared Contract/Context/configuration and coupled work stays in the parent. Add no development phase/method Gate, fixed count/Outcome mapping, agent allocator/scheduler, retry, queue, DAG, registry, delegation proof or persistent delegation state.
+Anti-Degradation Assurance protects coverage, false-negative resistance, fail-closed Authority and final-snapshot proof before cost. Purpose replacement requires a project-owner design-purpose decision and replacement proof. `F = Implementation Freedom Boundary` leaves methods, feedback, packet decomposition and dynamic count Goal-owned within Source/Contract/safety. After the checkpoint, identify packets before profile/capacity. Each is `independently_safe`, has `positive_expected_parallel_benefit` and `bounded_input_and_output`, is `parent_integratable`, and the set is pairwise `owner_disjoint`, `path_disjoint` and `source_of_truth_disjoint`. Unless explicit user/host policy prohibits agents, make actual host calls for multiple exact workers with `agent_type: long_task_implementation`; intent is not delegation and only call or explicit capability results establish profile/capacity. Count stays dynamic.
 
-Each worker receives only its bounded packet. It may inspect named Source/Contract/Context and implement/check locally, but never author/revise Source, Contract, Authority or Context; create Progress/Evidence/Receipt/Final Gate; run lifecycle commands; choose models; spawn/retry/schedule; create branches/worktrees; or claim acceptance/completion. Active `PreToolUse` denies non-exact creation; exact `SubagentStart` reinforces it without proving trust or acceptance. The parent reviews and integrates every report (advisory only), resolves overlaps, writes Context and runs current-candidate/formal verification.
+Select one zero-start reason by the Workflow Contract's ordered first-match rule: policy prohibition -> insufficient base candidates -> disjointness conflict -> coordination cost -> actual exact-spawn capacity failure -> other exact-worker unavailability. Unknown capacity is not insufficiency. Once any exact worker starts, later profile/capacity failure is partial delegation rather than a parent-only reason: keep that worker, return the rest to the parent and report the cause; use no generic substitute or retry. A type mismatch returns its packet. Never override `service_tier` or claim unobservable inheritance. Add no development phase/method Gate, fixed count/Outcome mapping, allocator/scheduler, queue/DAG/registry/proof or persistent delegation state.
+
+Each worker gets one self-contained packet containing its goal, allowed owners and paths, forbidden paths, relevant Source, Contract and Context references, implementation entrypoints, checks, expected return format and known dependency/integration risk. Before dispatch, the parent reads `git status --short` and `git diff --name-only` non-persistently. Workers only implement/check; truth, Authority, spawning, worktrees and acceptance remain parent-owned. `PreToolUse` denies non-exact creation and freshly checks visible profile parity; `SubagentStart` reinforces type without proving trust, effective execution or load atomicity. After return, the parent inspects the actual diff and integrates results only after comparing actual changed paths and the final working-tree diff with the union of packet envelopes. This proves path-envelope conformance, not per-line actor attribution; unexplained/overlapping/out-of-envelope/shared-owner changes block integration and Final Gate.
 
 ## Progressive Reference Loading
 
@@ -53,14 +55,14 @@ A Draft Outcome is an Outcome before Authority Lock, not a new schema field or r
 1. Read the request, real Source, relevant Context, repository owners and selected design resources. Before formal Compile and the first implementation edit, surface one repository-bound `Architecture Deliberation`: owner/extension point/source of truth, dependencies and lifecycle, selected and rejected alternatives, future-change challenge, debt disposition, forbidden shortcuts, project-owned Checks and triggered quality attributes or concrete preservation. Put durable conclusions in owning Context and material falsifiable delivery conclusions in real marked Source plus existing Contract fields. Decide `Context Delta: none|required`.
 2. Open the one Contract Draft immediately. When inputs need Source repair, read Source authoring and Contract authoring together; preserve at least one real `source_path`, complete all required semantic/design closure and repair every `decision_required` item without inventing product meaning.
 3. Run read-only `ty-context long-task preflight <workdir>`, repair the same Draft, then run formal Compile only when Source, Context, Contract, repository scope and proof bindings are ready. Compile creates the first Authority Lock; Preflight creates no Authority, Progress, Receipt or state.
-4. When the first Compile returns `execution_model_checkpoint.required: true`, always obey its terminal-turn boundary. Do no product implementation, file edit, build or test after that result, regardless of any earlier textual model strategy. End the turn and tell a Chinese-speaking user exactly `处理好模型更换之后，请发送【继续】。`; use `After handling the model change, send [continue].` in English. Harness cannot observe or verify the model change. A later Compile returns `required: false` and never repeats the pause.
-5. After continuation, apply the Delegation Suitability judgment above and begin Goal-owned rolling implementation. Delegate independent bounded packets only through explicit exact `long_task_implementation`; otherwise the parent executes without a generic substitute or retry. Keep non-independent work in the parent. Re-evaluate Context Delta and Architecture Deliberation when durable facts, scope, ownership, dependency direction, selected design, quality applicability or debt disposition materially changes.
+4. On the first Compile result with `execution_model_checkpoint.required: true`, do no product implementation, edit, build or test; end the turn. Tell a Chinese-speaking user exactly `处理好模型更换后，请仅回复：模型切换卡点解除，继续`; in English use `After handling the model change, reply exactly: model checkpoint cleared, continue`. Generic continuation does not satisfy this managed prompt protocol. Harness observes neither the next host message nor the model change, so this is no machine unlock or attestation. Later Compile returns `required: false` without repeating the pause.
+5. After continuation, begin Goal-owned rolling implementation and apply Delegation Suitability above. Qualifying work gets actual multiple exact `long_task_implementation` calls; otherwise record one admitted solo reason. Keep coupled work in the parent. Refresh Context Delta and Architecture Deliberation when durable scope, ownership, dependency, design, quality or debt changes.
 6. Use targeted verification only when its expected localization value exceeds cost. If authority changes, keep the same Draft and follow protected revision; mechanically bounded repairs may auto-adopt, while semantic weakening or unknown change requires the exact user decision. Adoption returns to rolling implementation and is never completion.
 7. Complete Context, implementation and project tests, create the clean candidate required by the lifecycle reference, then run the one source-recompiled current-snapshot Final Gate. Stop/close and any native Goal completion remain subject to the exact lifecycle and veto rules in the Authority reference.
 
 ## Rolling Execution
 
-After Authority Lock and the one-time terminal-turn checkpoint, the parent Goal chooses implementation order, local planning, tools and repair hypotheses, then applies the bounded independence/benefit/coordination test above. Qualifying disjoint packets should be delegated proactively; a packet may cross Outcome or Stage boundaries when its code owner remains coherent, because those boundaries control acceptance readiness rather than edit permission. The profile is optional and can be absent. The parent retains every authority, architecture, Context, integration and formal-verification owner. Delegated reports are advisory, Harness stores no delegation state and all proof-bearing changes converge into the selected verification workspace.
+Apply packet-first above. Outcomes/Stages govern acceptance, not edits; coherent-owner packets may cross them. Parent retains Authority, packet selection, Context, integration and verification; proof-bearing changes converge into the selected verification workspace.
 
 The derived Frontier is only an acceptance/verification and diagnosis projection. Use `verify --explain [--outcome/--check]` for a read-only cost preview and targeted `verify --outcome/--check` for optional feedback. `progress_stale` is a freshness fact; refresh only before an intermediate decision relies on that Progress. Continuing implementation and entering Final Gate need no targeted refresh because Final Gate ignores Progress and reruns all required Checks. Do not add another model-switch pause, trigger queue, implementation gate, per-edit rebuild rule or per-platform progress state.
 

package/assets/skills/long-task-workflow/agents/openai.yaml

@@ -1,6 +1,6 @@
 interface:
   display_name: "Long-Task Workflow"
   short_description: "Run one Delivery Contract in the current native Goal"
-  default_prompt: "Use $long-task-workflow for one Canonical Delivery Contract. After the first-Authority-Lock checkpoint, proactively delegate independent bounded packets only to the exact custom agent long_task_implementation, using multiple instances for disjoint workstreams when beneficial. If the host cannot explicitly select that custom agent, do not spawn a generic substitute; execute in the parent. Keep Source, Contract, Authority, Context, integration and formal verification in the parent Goal."
+  default_prompt: "Use $long-task-workflow for one Canonical Delivery Contract. After the first-Authority-Lock checkpoint, identify qualifying bounded packets before profile/capacity; absent an explicit policy prohibition, make actual calls for multiple exact long_task_implementation workers and let host results determine zero-start or partial fallback. Never infer unavailability, use a generic substitute or fix the count. Keep Source, Contract, Authority, architecture, Context, packet selection, integration and formal verification in the parent Goal."
 policy:
   allow_implicit_invocation: false

package/assets/skills/long-task-workflow/references/authority-lifecycle.md

@@ -14,7 +14,7 @@ Preflight keeps every independently discovered diagnostic. When a structural dup
 
 The first successful `ty-context long-task compile <workdir>` is Authority Lock and freezes the immutable initial base and complete compiled authority snapshot in Git common-dir, bound to the worktree marker by task id, revision and compiled identity.
 
-Its JSON result includes `execution_model_checkpoint.required: true`, `action: change_model_in_host_then_continue`, `resume_token: continue`, `turn_boundary: end_current_turn`, the blocked implementation actions and explicit model non-observability. Always do no product implementation, file edit, build or test after that result, even when an earlier message stated a model strategy. End the turn and tell a Chinese-speaking user exactly `处理好模型更换之后，请发送【继续】。`; use `After handling the model change, send [continue].` in English. Harness cannot observe or verify the host model change, and the continuation is not an acknowledgement record. Later Compile revisions return `required: false`; no checkpoint file, acknowledgement state, model route or automatic model switch is created.
+Its JSON result includes `execution_model_checkpoint.required: true`, `action: change_model_in_host_then_continue`, `resume_token: model checkpoint cleared, continue`, `generic_continue_satisfies: false`, `turn_boundary: end_current_turn`, the blocked implementation actions and explicit model non-observability. Always do no product implementation, file edit, build or test after that result, even when an earlier message stated a model strategy. End the turn and tell a Chinese-speaking user exactly `处理好模型更换后，请仅回复：模型切换卡点解除，继续`; use `After handling the model change, reply exactly: model checkpoint cleared, continue` in English. Do not accept a generic continuation under this package-managed prompt protocol. Harness cannot observe the next host message or verify the host model change, and the continuation is neither a machine-enforced unlock nor an acknowledgement record. Later Compile revisions return `required: false`; no checkpoint file, acknowledgement state, model route or automatic model switch is created.
 
 The optional Codex `long_task_implementation` custom agent is available only as a post-checkpoint rolling implementation affordance. Its fixed package-owned configuration is not a checkpoint option and cannot acknowledge, satisfy or replace the host boundary. It writes no workflow state and owns no Source, Contract, Authority, Context writeback, Progress, Evidence, Receipt or Final Gate; if the exact profile selector or Codex custom-agent support is unavailable, the parent Goal continues directly without a generic substitute and formal acceptance is unchanged. The main Skill owns the complete Delegation Suitability and parent/worker policy.