project-tiny-context-harness 0.7.5 → 0.7.6

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

@@ -0,0 +1,65 @@
+---
+name: design-resource-authoring
+description: Use when the user explicitly asks to generate, author, plan, commission, or iterate design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study, or design handoff from raw drafts, product/technical plans, optional Source Plans, visual briefs, screenshots, or existing design resources; 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/Context adoption, Source Plan authoring itself, or Long-Task execution.
+---
+
+# Design Resource Authoring
+
+Commission the smallest sufficient set of design resources from the currently available Open Design capabilities. This Skill is a thin task-local planner, provider adapter, iteration guide and handoff layer. Open Design owns its generation logic; Tiny Context owns neither its prompts nor its runtime.
+
+## Hard boundaries
+
+- A raw draft is a valid input. Never require, invoke, regenerate or edit a Source Plan.
+- Never edit an initial proposal, `project_context/**`, `DESIGN.md`, a Delivery Contract, production code or tests as a side effect of design-resource work.
+- Never make a prototype, wireframe, high-fidelity candidate, design system, Figma file, variant count or directory layout universally mandatory.
+- Never let supplied background expand the user's explicit output scope. “One control,” “one page,” “these three pages” and “exploration only” are hard ceilings.
+- Generated candidates are ordinary external Source. They do not select themselves, become `exact-target`, create Design Authority or prove product acceptance.
+- Keep provider projects, runs and generated artifacts task-local until the user requests a handoff or explicitly selects a candidate.
+- Do not install or persistently configure MCP servers, plugins, authentication or new disclosure paths without separate user authorization.
+- Do not create a Tiny Context resource pack, provider registry, workflow state, Contract artifact, acceptance record or parallel authority lifecycle.
+
+## Read the references
+
+1. Always read [resource-selection.md](references/resource-selection.md) before deciding what to generate.
+2. Read [open-design-provider.md](references/open-design-provider.md) before capability discovery, provider execution, recovery or Figma routing.
+3. Read [downstream-handoff.md](references/downstream-handoff.md) before a handoff, selected-source preparation, accepted-decision summary or use by Source Plan/default/Long-Task workflows. A simple unselected preview may stop before this reference is needed.
+
+## Core workflow
+
+1. **Fix the requested-scope ceiling.** Separate background coverage from requested output coverage. Record explicit exclusions and whether the user wants exploration, handoff or selected-source preparation.
+2. **Inventory every supplied input.** Accept raw notes, an initial proposal, product and technical plans, an optional Source Plan, visual briefs, screenshots, references and existing artifacts. Preserve each input's role as existing exact target, constraint, inspiration, current-implementation evidence or background; report unreadable or intentionally unused material and do not invent missing authority.
+3. **Find the design gaps.** Identify only the uncertainties that block or materially improve the requested decision: information hierarchy, flow, control/state behavior, visual direction, responsive/platform behavior, reusable system detail or editable team handoff.
+4. **Discover live capabilities.** Inspect the current Open Design agent/model, functional skills, rendering templates, design systems, plugins and export routes. Treat absent or non-enumerable capabilities honestly; never substitute a remembered catalogue.
+5. **Choose the minimum sufficient commission.** Give every considered resource one disposition: `selected`, `optional`, `not-needed`, `unavailable` or `decision-required`, with one reason. Select multiple resources only when each closes an independent gap. Ask only when a genuine missing preference materially changes the commission; otherwise use traceable, reversible judgment.
+6. **Commission through Open Design.** Send a product-specific, bounded commission envelope around the selected provider capability. Do not copy, restate or simulate the provider's internal template prompt. Prefer structured MCP; use the bounded fallbacks in the provider reference only when needed.
+7. **Observe and inspect proportionally.** Keep provider execution state, artifact readiness and design suitability separate. Exploration needs only scope/corruption sanity and a visible result; handoff needs relevant structure/interaction inspection; downstream product verification remains downstream.
+8. **Iterate within scope.** Revise the candidate from user feedback without expanding coverage or continuously rewriting the source proposal. Stop when the requested design decision is supported, the user stops, or a genuine decision/provider blocker is reached.
+9. **Return the intent-sized result.** A simple exploration should show the artifact promptly. A handoff adds compact provenance, coverage and limitations. Selected-source preparation requires explicit selection basis and an immutable locator/hash or approved snapshot.
+
+## Raw-draft exploration loop
+
+An initial proposal may go directly through this Skill before `source-plan-authoring`:
+
+```text
+raw initial proposal
+  -> bounded design candidate
+  -> user feedback and iterations
+  -> explicit human selection/rejection
+  -> optional consolidated accepted-design-decision delta (when requested)
+  -> separately authorized revision of the initial proposal
+  -> optional source-plan-authoring(revised proposal + selected resources)
+```
+
+The Skill performs only the first four transitions and returns differences as output. It does not apply the proposal revision or invoke the optional final step. The delta distinguishes accepted, rejected and unresolved choices and identifies affected surface/control/state keys when available. Do not require or emit an interim delta after every iteration: keep those observations task-local and, when requested, return one consolidated delta after the direction is final. Never continuously synchronize or write back the proposal during candidate iteration.
+
+## Stop and route elsewhere
+
+- Route durable UI/UX authority adoption or repair to `context_uiux_design`.
+- Route synthesis of an implementation-ready Source Plan to `source-plan-authoring` only when the user explicitly requests that separate work.
+- Route ordinary implementation with sufficient design authority to the default Workflow Contract.
+- Route a complete explicit Single-Goal delivery to `long-task-workflow`.
+- If no new resource is justified, say so and route to the appropriate existing path instead of generating filler.
+
+## Completion response
+
+Report the requested scope and intent, selected/omitted/unavailable resources, visible artifacts or durable locators, provider/artifact status, review actually performed, provenance appropriate to intent, unresolved decisions and forbidden inferences. For an explicit selection after raw-draft iteration, return the accepted-design-decision delta when requested, without modifying any source document; it may be deferred until the end and consolidated once.

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

@@ -0,0 +1,126 @@
+# Design Resource Handoff
+
+Generated resources remain ordinary external Source. This reference preserves enough identity and meaning for later work without creating a Tiny Context-specific pack, registry or authority lifecycle.
+
+## Candidate, selection and authority are separate
+
+- **Candidate:** provider output proposed for review. It authorizes no fidelity.
+- **Human selection:** an explicit user/team choice with a stated basis. It permits selected-source preparation, not automatic durable adoption.
+- **Authority adoption:** a downstream workflow reconciles the selected Source with product/surface Context and `DESIGN.md`, records durable ownership where required and binds implementation/verification to declared conditions.
+
+The Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to `exact-target`. Unknown coverage remains unknown.
+
+## Intent-sized response
+
+### Exploration
+
+Return promptly:
+
+- requested scope and intent;
+- visible candidate/preview;
+- resource dispositions and obvious limitations;
+- provider/artifact qualifier when execution is not clean;
+- minimal sanity review actually performed.
+
+Do not require files, schemas, packs, hashes or validator runs for a throwaway unselected preview unless they are needed to retrieve/show it reliably.
+
+### Handoff
+
+Add only the fields needed for another person or workflow to consume it:
+
+- stable resource key plus surface/control/state/target keys when known;
+- classification: candidate, inspiration, constraint or pre-existing exact target;
+- provider version, project/run, selected capability/template, agent/model and design-system provenance as reported live;
+- explicit source entry or preview locator and immutable hash/snapshot when available;
+- declared platform, viewport, mode, state, content and interaction coverage;
+- selection basis if a human selection already exists;
+- unresolved decisions, known limitations and forbidden inferences;
+- outer review performed and provider status qualifier.
+
+No dedicated Markdown/YAML file or directory is mandatory. Use concise prose for simple work and a task-local structured block when fields would otherwise become ambiguous.
+
+### Selected-source preparation
+
+Require explicit human selection and record who/what supplied the selection basis. Preserve the exact artifact by hash or a user-approved durable snapshot. Do not rely on a mutable preview URL. Do not choose a repository destination, edit authority files or start implementation without separate authorization.
+
+## Accepted-design-decision delta
+
+When raw-draft exploration leads to an explicit selection, report a delta for the separately owned proposal-revision step:
+
+```yaml
+selection_basis: explicit user/team decision
+selected_resources:
+  - resource key, explicit locator and immutable hash/snapshot
+accepted:
+  - decision and rationale
+rejected:
+  - alternative and reason
+unresolved:
+  - genuine remaining choice
+impacts:
+  product_rules: []
+  information_hierarchy: []
+  surface_keys: []
+  control_keys: []
+  state_keys: []
+  interaction_rules: []
+  visual_constraints: []
+forbidden_inference:
+  - candidate iteration did not itself revise the proposal or establish Design Authority
+```
+
+This is an explanatory shape, not a required schema. Include only known changes. Do not emit or apply a delta after every iteration: interim observations remain task-local and may be returned once as a consolidated delta when the direction is final. The Skill does not write back the proposal, decide when a separately authorized owner rewrites it, or invoke `source-plan-authoring`.
+
+## Initial proposal and Source Plan routing
+
+The components are independent and composable:
+
+```text
+raw draft -> design-resource-authoring -> candidates -> explicit selection
+raw draft -> source-plan-authoring -> Source Plan
+revised raw draft + selected design resources -> source-plan-authoring -> richer Source Plan
+selected design resources -> default Workflow or Long-Task Source
+```
+
+The recommended design-first loop for substantial new Web/App work is:
+
+1. explore from the initial proposal;
+2. iterate inside the requested scope;
+3. obtain explicit human selection;
+4. when requested, return one consolidated accepted-design-decision delta;
+5. let a separately authorized plan owner revise the proposal;
+6. if requested, pass both the revised proposal and selected immutable resources to `source-plan-authoring`.
+
+This is a useful path, not a universal required lifecycle. `source-plan-authoring` remains optional upstream synthesis and does not generate design resources.
+
+## Default Workflow Contract consumption
+
+When the user later authorizes concrete development:
+
+1. bring the selected generated resource as ordinary Source;
+2. perform UI Authority Closure against product/surface Context, `DESIGN.md`, tokens and declared targets;
+3. classify the resource and confirm selection basis/coverage;
+4. decide `Context Delta` and adopt durable facts only through their existing owners;
+5. implement and run project-owned verification.
+
+Open Design run success, a candidate screenshot or this handoff cannot authorize fidelity or acceptance.
+
+## Long-Task consumption
+
+- A selected resource and an optional Source Plan are parallel ordinary Source inputs to Contract authoring.
+- Contract `source_paths`, bindings, verification inputs, check input paths and artifact globs should name only the stable locators/conditions they actually consume.
+- Surface/control/state/target keys should connect product meaning, source targets, implementation and checks where applicable.
+- Authority Lock, protected Authority Revision and Final Gate remain the only Long-Task authority lifecycle.
+- This Skill creates no Contract Draft, outcome, receipt, Check result or Gate.
+- A later Open Design rerun does not silently revise locked Source; the downstream workflow uses its normal revision rules.
+
+## Forbidden inferences
+
+Unless independently proven downstream, never infer that a generated resource:
+
+- is selected, authoritative or accepted;
+- covers unlisted states, viewports, modes, platforms or accessibility behavior;
+- is a native implementation because an HTML/image preview renders;
+- is editable in Figma because a Figma capability was listed;
+- changed the initial proposal, Source Plan, Context, `DESIGN.md`, code or Contract;
+- proves production fidelity, product correctness, test completion or release readiness.

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

@@ -0,0 +1,112 @@
+# Open Design Provider Orchestration
+
+Use Open Design as the generation engine. This Skill supplies a bounded product commission and retrieves results; it does not recreate the provider's prompts, template logic or catalogue.
+
+## Execution priority
+
+1. **Structured Open Design MCP** for discovery, project/run control and artifact retrieval.
+2. **Open Design CLI or daemon API** when MCP is unavailable or cannot expose a required current capability but equivalent structured behavior is locally available.
+3. **Browser/desktop interaction** only for bootstrap, unavoidable UI-only selection, signed-in provider interaction, visual preview inspection or recovery. Prefer browser-specific control over general Computer Use when both can operate the page.
+
+Do not silently install an MCP server/plugin, alter the user's global Open Design/Codex configuration, sign in, create a paid-provider dependency or expand data disclosure. Explain the exact setup need and obtain separate authorization when persistence or a new disclosure path is required.
+
+## Live capability discovery
+
+Discover rather than remember:
+
+- configured agents and models, including whether Open Design's inner agent is Codex CLI;
+- functional skills and plugins;
+- rendering templates or project types;
+- design systems and their selected project binding;
+- specialist paths such as Figma, image, video or 3D/WebGL;
+- supported project creation, run, cancellation, file and artifact operations.
+
+Current structured tool names may include `list_agents`, `list_skills`, `list_plugins`, `create_project`, `get_project`, `get_active_context`, `start_run`, `get_run`, `cancel_run`, `list_files`, `get_file` and `get_artifact`. Feature-detect them; tool names and provider versions may evolve.
+
+Functional skills and rendering templates are different registries. Finding `frontend-design` does not prove that a `mobile-app` or `wireframe-mobile-flow` template is installed, and a remembered template ID is not live capability evidence.
+
+### Rendering-template discovery compatibility
+
+Prefer, in order:
+
+1. a live `list_design_templates`-style method/resource when the provider exposes one;
+2. an explicit template ID supplied by the current project/user and validated by the provider;
+3. a version-guarded structured daemon query that reads the provider's current registry;
+4. provider UI inspection when no structured registry is exposed;
+5. an honest `unavailable` or degraded-discovery result.
+
+Never vendor a fallback template catalogue or guess a template ID from prior runs. Do not implement a transport helper unless the live host truly lacks a safe structured path; any helper may normalize metadata and transport only.
+
+## Structured commission sequence
+
+1. Record provider version, selected agent/model, functional capability, rendering template, design system and relevant plugin/export readiness as reported live.
+2. Reuse an existing task-local project only when its scope and prior inputs match; otherwise create a bounded project.
+3. Start a run with the product-specific commission envelope and the provider-native capability identifier.
+4. Poll with a bounded cadence. During a long run, report meaningful progress at least once per minute without flooding the user.
+5. Preserve run IDs and the latest provider diagnostic. Support cancellation when the user requests it and the provider exposes it.
+6. Resolve the actual entry explicitly, retrieve the artifact/source, inspect it according to intent and preserve its immutable identity before later iterations or handoff.
+
+Open Design may launch Codex CLI as its configured inner agent. That is provider execution, not recursive invocation of this outer Skill. Do not hardcode a model when the provider can report the current configured model.
+
+## Separate three kinds of state
+
+### Provider execution state
+
+Examples: queued, running, succeeded, failed, cancelled, timed out or unknown.
+
+### Artifact readiness
+
+Examples: missing, partial, corrupt, retrievable, rendered or snapshot-preserved.
+
+### Design suitability
+
+Examples: unreviewed, scope-sane, handoff-checked, human-selected or rejected.
+
+Never collapse these into one “success.” A provider success does not prove a good design; a complete artifact can exist even when a provider run later fails.
+
+Use these qualifiers when needed:
+
+- `artifact-ready/run-unreconciled`: a complete retrievable artifact exists, but the provider run remains nonterminal or inconsistent;
+- `artifact-ready/provider-failed`: the artifact remains complete and retrievable, but the provider later reports failure/timeout.
+
+In both cases preserve the exact run locator, last update, failure diagnostic and artifact hash. Do not claim provider success or downstream acceptance. Retry only when the promised resource is incomplete/corrupt or the user requests another attempt; do not discard a useful independently inspected artifact merely because the terminal state differs.
+
+## Explicit entry and immutable identity
+
+Provider project metadata may omit or stale its entry file. Resolve in this order:
+
+1. validate an explicit project entry path when present;
+2. enumerate project files;
+3. identify the intended provider-native entry from the current run/output rather than guessing;
+4. retrieve that exact file/artifact;
+5. preserve an SHA-256 digest or immutable snapshot before selection/handoff.
+
+A preview URL is mutable navigation, not immutable identity. It may be reported for convenience only beside project/run/entry provenance and a digest. If the user explicitly selects the resource for durable use, export or snapshot it to a user-approved location; never silently choose a repository path.
+
+## Review proportional to intent
+
+- **Exploration:** open/render the requested entry, confirm artifact count/scope and obvious corruption, then show it. Do not launch a packaging or validator sequence.
+- **Handoff:** additionally inspect relevant structure, key states/transitions, viewport behavior, obvious console/runtime errors and requested interaction hooks. State exactly what was and was not checked.
+- **Selected-source preparation:** require explicit human selection basis, preserve identity/snapshot, and prepare downstream metadata. It still does not verify production behavior.
+
+Provider self-checks, outer artifact sanity review and downstream project verification are separate evidence layers. Never claim native rendering, accessibility, responsive coverage, product correctness or acceptance unless the appropriate downstream project checks actually prove them.
+
+## Figma and other specialist paths
+
+Figma is optional. Select it only when editable collaboration or library handoff materially benefits the request and a real connector/plugin/export path plus authentication is operational. A listed plugin, skill description or catalogue entry is not proof that editable Figma export works.
+
+If Figma is requested but unavailable:
+
+- report the missing connector/auth/export capability precisely;
+- offer a non-Figma artifact only when it still answers the user's design decision;
+- never relabel HTML, an image or a manifest record as an editable Figma design.
+
+Apply the same capability/readiness rule to image, video, 3D/WebGL and other specialist providers.
+
+## Failure and recovery
+
+- Preserve provider diagnostics; do not replace failures with generated placeholders.
+- Avoid unbounded polling or repeated blind reruns.
+- Re-discover capability after provider upgrades or registry mismatches.
+- If structured paths fail but a UI artifact exists, UI inspection may recover it while retaining the degraded-provider qualifier.
+- If the provider is unavailable and no justified fallback exists, return `unavailable` with the minimum setup needed rather than generating with an unrelated image tool and calling it equivalent.

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

@@ -0,0 +1,124 @@
+# Dynamic Resource Selection
+
+Use this reference to derive a bounded design-resource commission from the actual request. It is a decision model, not a fixed production sequence.
+
+## 1. Establish the scope ceiling
+
+Extract the smallest explicit output boundary before interpreting the background:
+
+- subject: one control/component, one page, named pages, a flow or a reusable system;
+- platform and viewport when known;
+- modes, states and transitions explicitly requested;
+- fidelity or editability requested, if any;
+- exclusions such as “other pages not included,” “preview only,” “no Figma” or “do not update files.”
+
+Rich background improves a bounded artifact. It never authorizes more artifacts. If the user supplies a complete app plan but asks to preview one button, generate at most the one-control resource.
+
+## 2. Choose the intent
+
+| Intent | User decision being supported | Default stopping point |
+| --- | --- | --- |
+| `exploration` | “What might this look or feel like?” | Visible scoped candidate plus minimal sanity review |
+| `handoff` | “Can another designer/developer reliably consume this?” | Project-native artifact plus provenance, coverage, limitations and relevant checks |
+| `selected-source-preparation` | “Preserve this explicitly selected direction for later use.” | Immutable identity or approved snapshot, explicit selection basis and downstream notes |
+
+Intent is task-local and need not be persisted. Selected-source preparation does not itself adopt Design Authority.
+
+## 3. Inventory relevant input roles
+
+Preserve each supplied item's actual role:
+
+- `exact-target`: already authoritative only for its declared conditions;
+- `constraint`: a rule that controls only its stated scope;
+- `inspiration`: directionally useful but not fidelity authority;
+- `current-implementation-evidence`: evidence of current behavior, not desired behavior by default;
+- `background`: product/technical context that informs but does not expand generation scope.
+
+An optional Source Plan is one possible input. Raw notes or an initial proposal are equally valid. Never require one merely to make the other usable.
+
+## 4. Identify independent gaps
+
+Ask what remains uncertain inside the scope:
+
+- **structure:** information hierarchy, layout regions or page relationships;
+- **flow:** navigation, branching, recovery or multi-step sequence;
+- **behavior:** control states, transitions, gestures, feedback, loading/error/empty/disabled cases;
+- **visual direction:** composition, typography, color, density, imagery or brand character;
+- **platform/responsiveness:** safe areas, breakpoints, input methods or viewport behavior;
+- **system reuse:** tokens, component variants or cross-surface rules needed by more than the requested artifact;
+- **team editability:** a real need for collaborative editable frames/libraries or an organizational Figma handoff.
+
+Do not manufacture a gap already resolved by selected Source.
+
+## 5. Consider resources conditionally
+
+| Resource | Select when it closes this gap | Usually omit when |
+| --- | --- | --- |
+| Control/component state study | One control's variants, anatomy, feedback or edge states are the decision | The page target already specifies those states precisely |
+| Low-fidelity wireframe | Hierarchy, topology or flow must be judged without visual-style distraction | Structure is settled and only visual direction is unknown |
+| High-fidelity visual candidate | Visual hierarchy, tone or composition needs selection | Existing selected targets already govern the requested conditions |
+| Interactive prototype | Transitions, navigation, state retention or task feel must be experienced | A static decision is sufficient or the provider cannot produce genuine interaction |
+| Flow/journey board | Multiple surfaces, branches or recovery paths must be compared together | The request is one isolated surface/control |
+| Design-system slice | Several requested artifacts need shared tokens/components or reuse rules | One exploratory candidate does not justify a system |
+| Component inventory/specification | Development handoff needs explicit reusable variants and states | Exploration is visual only and no reuse decision is requested |
+| Figma handoff | Editable collaborative frames/libraries are explicitly valuable and operational | A screenshot/HTML/project-native source is sufficient or connector/auth/export is unavailable |
+| Image/illustration/icon/media study | Bespoke content materially defines the selected direction | Generic placeholders answer the present decision |
+
+A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions.
+
+## 6. Assign a disposition to every considered resource
+
+- `selected`: required to close a current gap;
+- `optional`: useful, but not necessary for the current decision;
+- `not-needed`: redundant or outside the scope ceiling;
+- `unavailable`: justified but not currently supported/configured;
+- `decision-required`: a genuine unresolved preference changes the commission materially.
+
+Give one concrete reason. Do not turn `optional` into automatic extra work.
+
+## 7. Build the commission envelope
+
+The task-local envelope should contain only product-specific information:
+
+```yaml
+intent: exploration | handoff | selected-source-preparation
+scope:
+  subjects: [named control/surface/flow keys]
+  ceiling: one-control | one-page | named-pages | named-flow | system-slice
+  platform: known-or-unknown
+  viewports: []
+coverage:
+  required_content: []
+  required_states: []
+  required_transitions: []
+inputs:
+  exact_targets: []
+  constraints: []
+  inspiration: []
+  background: []
+selected_capability:
+  kind: runtime-discovered-kind
+  id: runtime-discovered-id
+exclusions: []
+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.
+
+## 8. Iterate and stop
+
+- Keep each revision inside the original scope ceiling unless the user explicitly expands it.
+- 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 and Figma copies merely because a process diagram lists them.
+- Stop as soon as the requested decision is supported.
+
+When a human explicitly selects or rejects a direction, return an accepted-design-decision delta when requested rather than editing the initial proposal. Include accepted, rejected and unresolved choices; product, information, control/state and visual implications; affected stable keys; and selected artifact locators/hashes. Do not require a delta after every iteration. Interim observations remain task-local and may be returned once as a consolidated delta after the design direction is final. A separate plan owner decides whether, when and what to revise.
+
+## Worked scope examples
+
+- **Large draft, one filter control:** select a control-state study if anatomy and states are uncertain; omit page/flow resources.
+- **One page, style preview:** select one high-fidelity candidate; do not add a design-system pack or validator run.
+- **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.
+- **Raw draft before Source Plan:** iterate only requested candidates, optionally return one consolidated accepted-decision delta when requested after selection, and leave both draft revision and later Source Plan authoring separate.