# 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.