project-tiny-context-harness 0.8.17 → 0.12.0

package/assets/skills/context_uiux_design/references/task-uiux-analysis.md

@@ -1,82 +0,0 @@
-# Task-Level UI/UX Analysis
-
-Use this non-authoritative reference only for material UI/UX reasoning or audit. It helps the current Goal understand and compare candidates; it does not own product meaning, page duty, information/action/feedback placement, interaction topology, Design Authority, resources, implementation or acceptance. Product/Surface/Screen/Design Source remains controlling.
-
-## 1. Recover the user and operating context
-
-Read the available product and Surface/Screen Source before evaluating layout. Identify only what is authoritative or explicitly task-local:
-
-- target user or role and usage context;
-- primary task outcome and success feedback;
-- client/host/platform, input mode, viewport/size class and environmental constraints;
-- current page/surface duty and entry/exit context;
-- permissions, data/state, recovery and accessibility constraints; and
-- affected exact targets, constraints and inspirations.
-
-Do not infer a user, task priority or product rule from a feature list, screenshot or current component tree. Missing meaning that changes the candidate remains `decision-required` or belongs in the stale owning Source.
-
-## 2. Model the primary work object and task loop
-
-Name the object the user is inspecting, creating, editing, moving or deciding about. Trace the shortest meaningful loop:
-
-```text
-orient -> inspect/select the work object -> act -> see local feedback -> recover or continue -> finish
-```
-
-For each material action, keep operation, affected object and feedback spatially and temporally understandable. Record which context must remain visible while acting, what state commits, how cancellation/retry works and where focus/selection returns. Secondary diagnostics or configuration must not displace the primary work object without an explicit Surface decision.
-
-## 3. Test information hierarchy and topology
-
-Evaluate semantic priority before visual polish:
-
-- primary judgment, work object and action;
-- critical context that must remain visible;
-- supporting information and secondary actions;
-- drilldown/evidence/diagnostic ownership; and
-- loading, empty, partial, error, permission, offline and recovery states.
-
-Compare the smallest material topology candidates: fixed versus scrolling regions; inline versus overlay; sidebar, sheet, modal or popover; split view; map/canvas/editor viewport; and navigation versus contextual reveal. For each candidate, explain what remains visible, what scrolls, who owns focus/back/cancel and how the primary loop changes across size classes.
-
-Client-specific structure is allowed when host chrome, safe area, keyboard/input method, pointer/touch conventions, native navigation or viewport constraints materially differ. Do not treat a desktop layout shrunk to mobile width as mobile interaction design.
-
-## 4. Walk the task and its counterfactuals
-
-Run a concise cognitive walkthrough for the primary path and material failure/recovery path:
-
-1. Can the user identify the current work object and next useful action?
-2. Is the action discoverable and available at the moment it matters?
-3. Is the affected object unambiguous before commit?
-4. Is progress, success, failure or partial result visible near the action/object?
-5. Can the user cancel, retry, undo, navigate back or recover without losing unexplained state?
-6. Do keyboard, focus, touch target, screen-reader label/order, contrast and reduced-motion needs remain viable?
-
-Challenge the leading candidate with long content, empty/error/permission states, narrow and wide size classes, localization/text scaling, keyboard or IME display, interrupted work and returning to the prior selection. Apply only conditions material to Source; do not invent a universal matrix.
-
-## 5. Compare and select under authority
-
-For each material candidate, state:
-
-- which authoritative facts it satisfies;
-- the primary-loop advantage and cognitive cost;
-- repeated scroll, navigation or context-switch cost;
-- state/recovery/accessibility consequences;
-- client/size-class behavior; and
-- what evidence or decision would change the choice.
-
-The current Goal may select among implementation-equivalent candidates when Source delegates that freedom. If candidates change product meaning, page duty, main/drilldown placement or a durable interaction topology, update the smallest owning Product Surface/Screen Context only when writes are already authorized and `Context Delta: required`; otherwise return `decision-required`. If a candidate conflicts with an adopted exact target or Design Authority, repair/revise the owning authority first. Only then may explicit resource generation route to `design-resource-authoring`.
-
-## Failure sentinels
-
-Explicitly check for these common defects when relevant:
-
-- repeated scrolling or cross-surface switching to compare information needed for one decision;
-- a hidden, collapsed or displaced primary work object;
-- critical actions detached from the object or hidden behind unrelated navigation;
-- feedback that does not identify the operation and affected object;
-- a keyboard or IME obscuring the editable object, commit/cancel actions or validation feedback;
-- destructive, interrupted or failed work with no understandable recovery path; and
-- mobile behavior produced only by shrinking desktop regions, with no touch/navigation/keyboard adaptation.
-
-## Output
-
-Return a concise task model, authoritative inputs and gaps, primary work object/loop, operation-object-feedback relationship, hierarchy/topology candidates, walkthrough/counterfactual findings, selected candidate or decision gap, owner/Context effect and verification suggestions. Do not create a required UI plan, matrix, lifecycle, resource pack, acceptance result or durable task-level UI/UX authority.

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

@@ -1,60 +0,0 @@
----
-name: design-resource-authoring
-description: Use when the user explicitly asks to generate, author, commission, iterate or recover design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study or implementation handoff; or asks to 生成设计资源, 使用 Open Design, 生成原型图, 生成高保真/低保真设计, 为开发准备设计资源, 恢复设计资源任务, or 先看一个控件/页面效果 in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation, local CSS fixes, durable Design Authority adoption, initial product-proposal authoring or Long-Task execution.
----
-
-# Design Resource Authoring
-
-Commission the smallest sufficient resource set for the user's explicit output/development scope. “Smallest” limits artifact count and surrounding scope, never material information granularity. Open Design or another selected provider owns generation; this Skill owns task-local scoping, provider adaptation, iteration, selection reconciliation and handoff preparation—not provider prompts/runtime, Design Authority, product meaning or acceptance.
-
-## Hard boundaries
-
-- A raw proposal, plan, brief, screenshot or existing resource is valid input. Never require or create a special intermediary planning format, and never rewrite caller-owned Source except for the one explicitly selected proposal reconciliation.
-- The explicit output/development scope is a hard ceiling. Necessary surrounding context may orient the slice but cannot expand it. Report an outside-ceiling effect as existing `decision-required` with reason `scope-expansion-required`; only explicit user expansion changes the ceiling.
-- Candidates are ordinary external Source. They do not select themselves, become `exact-target`, update `DESIGN.md`/Context or prove implementation acceptance.
-- Keep candidate effects in a task-local buffer. Only after explicit selection or explicitly delegated selection may accepted decisions be reconciled once and idempotently into the initial proposal; never write rejected/unresolved meaning as accepted.
-- Never mutate `project_context/**`, `DESIGN.md`, a Delivery Contract, production code or tests as a resource-authoring side effect.
-- Do not require a prototype, fidelity pair, provider-native file, fixed directory, variant count, resource pack or one artifact per control. Reuse selected component families and group repeated controls.
-- Visual resources may express user-visible interaction/presentation but cannot invent or become sole owner of business, data, permission or algorithmic rules.
-- A Web/App implementation resource must be feasible on the real project substrate. DRA may enumerate Source-backed feasible realizations and blockers, but it cannot select a production owner or required realization unless an exact current marked technical Source Item already makes that choice. Role labels, same-file prose and path-only claims are not authority.
-- Before commissioning a page, flow or complex control, consume controlling Product/Surface/Screen Source for target user/context, client/host, page duty, primary task outcome, primary work object/task loop, operation-object-feedback and applicable state/recovery/accessibility meaning. Separately consume `DESIGN.md` and selected exact-target/constraint Source for visual-system and selected-design conditions. If the requested direction requires durable Product/Surface/Screen/Design meaning to change, route to and update the actual owner before resuming generation; do not design against stale Source.
-- Non-authoritative task-level UI/UX analysis may inform candidate comparison but cannot supply missing product or surface meaning. A Provider must not infer that meaning from a feature list, screenshot, route tree, component inventory or analysis output.
-- Do not install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Create no provider registry, global workflow state, authority lifecycle, scheduler or acceptance record.
-
-## Progressive references
-
-1. Always read [resource-selection.md](references/resource-selection.md) to fix the scope ceiling, authoritative product/surface inputs, intent, input roles, style dependency and minimum commission.
-2. Read [open-design-provider.md](references/open-design-provider.md) only before live capability discovery, provider execution, Design Authority binding, source acquisition or recovery.
-3. Read [downstream-handoff.md](references/downstream-handoff.md) only when selection, proposal reconciliation or downstream handoff is material. A simple unselected preview may stop without it.
-4. Read [implementation-feasibility.md](references/implementation-feasibility.md) before commissioning or publishing a Web/App implementation handoff against a real repository substrate. Reference-only and non-implementation resources never load it.
-5. Read [formal-selected-web-app-handoff.md](references/formal-selected-web-app-handoff.md) completely only for an explicitly final selected Web/App implementation handoff. Exploration, unselected previews, reference-only resources and non-Web/App commissions never load this reference.
-
-For simple-preview overhead accounting, the requested preview is neither additional Provider generation nor an added tool action.
-
-## Workflow
-
-1. Name in-scope surfaces/flows/regions/component families/unique controls, conditions, necessary context, exclusions and intent: `exploration`, `handoff` or `selected-source-preparation`. For a page, flow or complex control, first resolve controlling Product/Surface/Screen user/context, client/host, page-duty, primary-task, primary-work-object/task-loop, operation-object-feedback and applicable state/recovery/accessibility meaning; separately resolve `DESIGN.md` and selected-target visual conditions. Keep missing meaning unresolved, route a durable owner change before generation and keep outside-ceiling impact `decision-required` rather than filling it from task analysis or expanding scope.
-2. Inventory every input as `exact-target`, `constraint`, `inspiration`, current-implementation evidence or background. Report unreadable/unused material.
-3. Classify the commission `style-bearing` or `non-fidelity`. Style-bearing means high fidelity/brand/visual direction/typography/color/density/component treatment/production-style prototype. IA/flow topology, low-fidelity structure and semantics-only state studies are non-fidelity.
-4. For style-bearing work, read configured Design Authority and its exact-value token source. If unconfigured, stop before provider project/run creation and route the user to explicit `$design-system-authoring`; never invoke it automatically. Non-fidelity work remains allowed.
-   A combined explicit request authorizes running `$design-system-authoring` first and then resuming this Skill.
-   Before every style-bearing generation or material revision, use the always-read resource-selection reference to close every applicable current-slice style-application dimension as `existing-covered`, `projected`, `not-applicable` or the existing `decision-required`. No applicable dimension may be silently omitted; `decision-required`, an undispositioned dimension or Source conflict blocks the Provider run. Complete current input-bound coverage permits omitting `style_application`, while the actual envelope contains only `projected` fields; generic design-system identity or Tokens alone are not current-slice coverage. Repeat the judgment for each material revision. A simple preview performs it through the current Source/envelope action without another tool action, persistent state or fixed extra user turn.
-5. For a Web/App implementation handoff, inspect current technical Source for platform, framework/runtime, UI system, token/theming adapter, component-owner roots and route-owner roots. Owner roots are current no-follow repository directories, not arbitrary identifiers. Treat every unavailable or decision-required observation as target-wide: an exact Source-backed blocker naming that observation must reach every material component-family × condition cell, and a target with no family carrier cannot hide the unresolved observation. Cover every material component-family × target × condition profile, including the complete transitive family subject closure, with at least one Source-backed feasible realization or an explicit blocker. A candidate-bearing cell requires observed non-empty component-owner roots; unresolved roots force blocker-only coverage. Exact planned-owner authorization, required realization and blocker authority use the marked-Source decision projection defined by the feasibility reference. Keep canonical design values in design resources; never put them into any feasibility prose field, while explicit technical build/test/runtime costs may retain their time units.
-6. Discover only the live provider capabilities needed by the bounded commission. For a formal generation, major revision or critical regeneration, apply the provider reference's `highest_available_capability + highest_supported_reasoning_effort` policy and fail closed when eligible candidates cannot be authoritatively ranked; never infer rank from price, name, release date or list order, and never claim an effective model/effort the run cannot confirm. Give every considered resource one disposition—`selected`, `optional`, `not-needed`, `unavailable` or `decision-required`—with a reason. Ask only when a missing preference materially changes the result.
-7. Bind style-bearing provider work to the adopted design-system identity, send only the scoped product/resource commission and keep provider execution, model-selection verification, Artifact readiness, Design suitability, human selection and authority adoption distinct.
-8. Iterate within scope. Re-review applicable suitability checks after every material revision. A first render with no material Source, feasibility or suitability defect may be selected directly; never require a revision merely to satisfy process. Exploration returns a visible candidate after minimal sanity review. When direction review or selection is material, use the downstream owner's `Design Resource Review & Selection Stop`; it is not approval, acceptance, formal completeness or persistent state. Do not burden exploration with handoff schema, hashes, complete Fact closure or downstream validation.
-9. After direction selection, preserve canonical immutable identity and editable-upstream provenance. For a selected formal Web/App handoff, complete the formal reference's closure first and return to the review stop if it exposes a new visible decision. Reconcile accepted proposal effects once only after stable formal closure; non-formal small requests retain their one-turn option.
-
-## Conditional Design Authority stop
-
-Unconfigured includes a missing `DESIGN.md`, the starter/status `unconfigured`, style-only prose/inspiration or no authored exact-value token source/generation direction. Say:
-
-```text
-Style-bearing design resources require an adopted project design system. Explicitly invoke $design-system-authoring to generate/select/adopt one, then resume $design-resource-authoring. I will not initialize it automatically.
-```
-
-## Routing and output
-
-Route durable system adoption/repair to `context_uiux_design`, surface responsibility to `context_surface_contract`, ordinary implementation to the default Workflow Contract/current Goal, and machine-assurance delivery to an explicitly selected/resumed `long-task-workflow`.
-
-Report intent-sized results: scope/context/exclusions, style gate, input roles, resource dispositions, provider/binding status, visible artifacts/locators, selection basis, immutable/editable provenance, limitations/decision gaps and proposal-reconciliation status. A formal handoff additionally reports exactly what its dedicated reference requires. Never call a failing, unresolved, incomplete or unselected result ready.

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

@@ -1,63 +0,0 @@
-# Selection, Proposal Reconciliation And Downstream Handoff
-
-Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry, authority lifecycle or acceptance result.
-
-## Candidate, selection and adoption
-
-- **Candidate:** provider output proposed for review; it authorizes no fidelity.
-- **Selection:** explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
-- **Authority adoption:** later UI Authority Closure reconciles selected Source with surface/interaction Context and `DESIGN.md` and binds implementation/verification to declared conditions.
-
-This Skill may preserve an input already classified `exact-target`; it cannot promote its own candidate. Unknown coverage remains unknown. Resource hashes, provider success and previews establish neither selection nor production conformance.
-
-A selection binds the canonical selected-source digest, target identity, declared conditions and controlling Source/Design-Authority identity. Preview URLs, names, PNGs, export archives and wrappers are derived artifacts, not the selection identity. A derived artifact proved equivalent to that canonical source under the bound target/conditions preserves selection; a visible or semantic difference requires fresh Design suitability review and another user choice.
-
-## 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 context and explicit exclusions. One addressable artifact may cover several items; a static/default frame covers only what it actually shows.
-
-Design resources may show user-visible triggers, transitions, states, feedback and rule presentation. Product/technical Source still owns business, data, permission and algorithmic rules.
-
-For a Web/App implementation handoff, also return the separate implementation-feasibility Source described in [implementation-feasibility.md](implementation-feasibility.md): real substrate observations plus complete transitive component-family × target × condition candidates/blockers. Owner roots are current repository directories. Planned-owner authorization, required realization and blocker authority bind exact marked technical Source Items and strict decision projections. Exact selected design values remain canonical-resource owned and cannot appear in feasibility prose. Multiple feasible candidates remain allowed; DRA selects none unless current technical authority already requires one.
-
-## Design Resource Review & Selection Stop
-
-Use this explicit interaction point when direction review, correction or candidate selection is material. Show the addressable candidate plus the scope ceiling/necessary context/exclusions, selected existing and generated coverage, preservation obligations, Provider/Artifact qualifiers, Design suitability findings, unchecked conditions, outside-ceiling effects and unresolved choices.
-
-The user may correct design execution, change a requirement, select/reject a candidate, leave a choice unresolved, explicitly expand scope or request a durable Product/Surface/Screen/Design owner change. Route durable meaning to its actual owner and reread it before DRA resumes. Design suitability never performs selection.
-
-This stop is not an approval record, `review_set_id`, registry, persisted status, Gate, acceptance, readiness or formal-completeness claim. It is not a required extra turn when a small request can generate, review and select in one turn. Ordinary conversational selection creates no persistent state or deterministic cross-session promise and must be reconfirmed if lost. When deterministic cross-interruption recovery is required, load [recovery-and-writeback.md](recovery-and-writeback.md) and use only its existing marked-Source, authority, selected-source and conditional-checkpoint route.
-
-## Reconcile the initial proposal once
-
-During a simple iteration, keep a task-local buffer of selection basis, selected immutable/editable identities, accepted decisions, rejected alternatives, unresolved choices and affected product/surface/control/state/interaction/visual keys. This is reasoning, not a schema or required file. If the loop is material enough to require replayable Delta, a file writeback or interruption recovery, stop and read [recovery-and-writeback.md](recovery-and-writeback.md); do not approximate safe recovery/CAS from this lightweight reference.
-
-After selection—and, for a formal Web/App handoff, only after its complete closure produces no new visible decision:
-
-1. confirm the selection basis and immutable identity;
-2. consolidate duplicate/intermediate notes;
-3. apply accepted decisions once while preserving unaffected requirements and provenance;
-4. keep rejected choices out of requirements and unresolved choices visibly unresolved;
-5. record stable resource keys and conditions, the immutable provider/project/run/entry locator plus digest/snapshot, and the editable upstream owner, locator and update/export method;
-6. make reruns idempotent by updating the existing decision/reference;
-7. edit the authorized writable initial-proposal file, or return one complete revised proposal when it exists only in conversation.
-
-Never mutate other caller-owned Source, Context, `DESIGN.md`, Contract, production code or tests. If no selection occurs, return candidates and the pending delta without changing the proposal. If formal closure exposes a new state, resource, condition, visible/semantic change or `decision-required` choice, return to the Review & Selection Stop before reconciliation.
-
-Non-formal small requests may complete generation, selection and reconciliation in one turn; “once” describes the semantic writeback, not a required pause. Formal Web/App work defers its one reconciliation until direction selection plus stable formal closure.
-
-## Intent-sized handoff
-
-Exploration returns the visible candidate, scope, dispositions, obvious limitations and sanity review. It requires no schema, pack, hash or validator unless retrieval itself needs one.
-
-A non-formal selected-source handoff preserves target/resource classification, conditions, immutable identity, editable-upstream route, coverage/limitations and proposal identity in a project-native location authorized by the user. It remains ordinary Source.
-
-For an explicitly selected Web/App implementation handoff, stop here and read [implementation-feasibility.md](implementation-feasibility.md) followed by [formal-selected-web-app-handoff.md](formal-selected-web-app-handoff.md). UI symbolic V2 is explicit opt-in; V1 remains the default. Those references own the real-substrate feasibility Source, strict manifest-backed V1/symbolic V2, Census/Fact/method and bundle/preflight rules. If closure exposes a new visible decision, return here for suitability review and the Review & Selection Stop; only stable closure returns for the one Proposal reconciliation. Do not approximate formal rules from this lightweight reference.
-
-## Downstream routing
-
-The default Workflow opens every affected selected `exact-target` or `constraint` plus current feasibility Source, routes design meaning through owning surface/Design Authority, selects an allowed implementation strategy during Architecture Deliberation, implements through the real production entry, runs applicable current-candidate checks, and reports blockers or unestablished conditions. It does not require machine-unique binding selection. When no reliable project-native check observes a production claim, report it as `Unverified`; preflight or model judgment cannot promote it. It does not rebuild a per-Fact proof ledger.
-
-An active Long-Task uses its one Source/Contract/Authority/Final Gate lifecycle. Existing component bindings must uniquely derive an allowed realization for every candidate-bearing cell and must all be attributed back to an allowing candidate-bearing cell; shared bindings are attributed across the complete surface, not forced onto each target. A surface with empty component refs is admitted only by complete Source-aware activation when every target is all-blocker-only; standalone structure validation, candidate/mixed/legacy targets and fake component bindings remain strict failures. Every `file`/`path_glob` target and carrier, every `verified` carrier and every non-empty planned carrier must be a proven subset of an observed component or route root; partial or unknown containment fails. Exact `path#source-item-key` Claims carry selected planned-owner/required-realization decisions, while every blocker is either `decision_required` or an open/closed target-blocking External Confirmation over affected current-target Claims. An open confirmation may project only its externally blocked design Assertions from machine execution and reaches `blocked_external`, never `machine_accepted`; it does not mutate the Contract or create a second Gate. The resource handoff, feasibility document and controlling technical authority are Source and bind only through existing Contract surfaces; this Skill creates no Contract Draft, Outcome, Progress, Evidence, Receipt, Check result or Gate. Historical Provider, preflight, DRA-audit or project-check results never replace current-candidate evidence in the existing Final Gate.
-
-Never infer that a generated resource is selected/authoritative/accepted, covers undeclared states or targets, is native implementation because a preview renders, changed durable authority, or proves production fidelity, tests or release readiness.

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

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

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

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