project-tiny-context-harness 0.7.6 → 0.7.8

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

@@ -0,0 +1,57 @@
+---
+name: design-system-authoring
+description: Use only when the user explicitly asks to initialize, generate, choose, adopt, replace or repair a project design system or design style with Open Design; asks for “初始化设计系统”, “生成设计系统”, “确定设计风格”, “采纳 Open Design 设计系统”, or explicitly invokes design-system-authoring in a Minimal Context Harness project. This cold-start capability never runs merely because DESIGN.md is missing, a project is new, another Skill needs visual style, or ordinary UI work begins.
+---
+
+# Design System Authoring
+
+Generate or select an Open Design design system, obtain an explicit selection, and adopt that selection into the project's existing durable Design Authority. The user invokes this Skill at project cold start or later repair time; installation only makes it available.
+
+## Hard boundaries
+
+- Run only from an explicit user request. Never auto-run from `init`, `sync`, the default Workflow, `design-resource-authoring`, a missing/starter `DESIGN.md`, or a new-project inference.
+- A combined explicit user request to initialize the system and then generate resources authorizes that sequence; a resource gate alone does not.
+- Open Design owns generation, revision, previews and its catalogue. Use its live structured capabilities; do not copy its prompts, emulate its generator, vendor a catalogue or invent provider IDs.
+- Keep candidate generation, human/delegated selection and authority adoption distinct. A successful job or attractive preview is not selected and is not project authority.
+- Project `DESIGN.md` and its one declared authored exact-value token source or generation direction are canonical. An Open Design design-system record and project binding are provider synchronization, not a second authority.
+- Put durable surface, information-architecture and interaction facts in their owning `project_context/**`; put visual-system semantics, rationale, token direction and reference interpretation in `DESIGN.md`. Do not duplicate facts across owners.
+- Do not create a design registry, receipt, workflow state, Contract, acceptance gate or provider runtime inside Tiny Context.
+- Do not persistently install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Task-local use of an already available Open Design MCP/daemon is allowed.
+- Do not implement production UI or claim downstream fidelity, accessibility, product correctness or acceptance.
+
+## Read the references
+
+1. Always read [open-design-design-system-provider.md](references/open-design-design-system-provider.md) before discovery, generation, revision, selection or provider synchronization.
+2. Always read [authority-adoption.md](references/authority-adoption.md) before changing `DESIGN.md`, its token source, relevant Context or provider bindings.
+
+## Core workflow
+
+1. **Confirm explicit intent and scope.** Identify whether the user wants a new system, selection from existing systems, repair, or replacement; capture the product/brand purpose, supported surface/platform, accessibility needs, required modes and supplied references. Ask only when an unresolved aesthetic or brand choice materially changes the candidates and the user has not delegated selection.
+2. **Inspect current authority.** Read core Context, relevant surface/interaction Context, `DESIGN.md`, its declared token source/generation direction and any recorded Open Design provenance. Classify the project as `unconfigured`, `configured`, or `configured-but-inconsistent`; this is a task-local finding, not new state.
+3. **Discover live Open Design capabilities.** Prefer structured MCP. List/read `od://design-systems/<id>/DESIGN.md`, inspect tool schemas, and feature-detect design-system creation/revision/acceptance plus project binding. Record the live provider/MCP version and any fallback used.
+4. **Reuse or generate candidates.** Reuse an existing provider system only when its identity and meaning fit. If a live MCP creation capability exists, use it. Otherwise use the official daemon generation-job API described in the provider reference. Keep every output a candidate until selection.
+5. **Review and iterate.** Inspect `DESIGN.md`, generated token files, preview/showcase and relevant workspace files. Use provider revision jobs for scoped feedback, poll boundedly, preserve diagnostics and keep pending revisions non-authoritative.
+6. **Obtain selection.** Require an explicit user/team selection, or an explicit instruction delegating selection with known criteria. Record the selection basis, provider design-system ID, selected revision when applicable and immutable content digest/snapshot. Reject or leave other candidates unselected.
+7. **Adopt once.** Reconcile the selected system through the authority-adoption procedure. Update root `DESIGN.md`, establish exactly one authored token source/generation direction, update only owning Context facts, and record provider provenance without making it authoritative.
+8. **Synchronize Open Design.** Accept the selected pending revision when applicable. Confirm MCP can read the adopted provider system. For later style-bearing resource work, create or verify an Open Design project with `create_project.designSystem` equal to the adopted provider ID.
+9. **Validate and report.** Run project-owned Context/design lint and source/package checks appropriate to the repository. Separately report provider execution, artifact readiness, selection, authority adoption, provider synchronization, verification and unresolved issues.
+
+## Readiness classification
+
+Treat Design Authority as unconfigured when `DESIGN.md` is absent, explicitly says `Design authority status: unconfigured`, remains an unedited starter, contains only style adjectives/inspiration, or lacks one authored exact-value token source/generation direction. A configured visual system still does not make every surface implementation-ready; selected exact/constraint targets and declared coverage remain separate.
+
+If authority is already configured and the user did not ask to replace or repair it, prefer reuse and explain the current system. Never generate a competing system as filler.
+
+## Completion response
+
+Report:
+
+- requested operation and design-system scope;
+- Open Design transport/version and capabilities actually used;
+- candidate IDs and review performed;
+- explicit or delegated selection basis;
+- adopted `DESIGN.md`, token source and Context owners changed;
+- provider ID, revision/digest and project-binding verification;
+- validations run, limitations and decisions still required.
+
+Always distinguish `provider succeeded`, `artifact ready`, `selected`, `authority adopted` and `binding verified`; none implies the next.

package/assets/skills/design-system-authoring/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Design System Authoring"
+  short_description: "Generate and adopt a project design system"
+  default_prompt: "Use $design-system-authoring to generate, select, and adopt an Open Design design system for this project."
+policy:
+  allow_implicit_invocation: false

package/assets/skills/design-system-authoring/references/authority-adoption.md

@@ -0,0 +1,47 @@
+# Design-System Authority Adoption
+
+Adopt one explicitly selected Open Design result through existing Minimal Context owners. This is a reconciliation step, not a new authority lifecycle.
+
+## Preconditions
+
+- Selection is explicit, or the user explicitly delegated selection and the stated criteria support one defensible choice.
+- The exact provider design-system ID and selected revision/body are readable.
+- `DESIGN.md`, generated token artifacts and relevant preview/workspace files have been inspected.
+- The selected content has a stable digest or user-approved snapshot.
+- Conflicts with product/surface Context are resolved or remain an explicit decision; provider output never silently overrides product meaning.
+
+## Single-owner writeback
+
+Use these owners:
+
+- `project_context/**`: durable surface responsibility, information hierarchy, navigation, stable interaction/state, product accessibility requirements and repeatable verification entrypoints;
+- root `DESIGN.md`: visual principles, typography, color, spacing, radius, elevation, motion rationale, component visual semantics, token-source declaration and interpretation of design references;
+- one project-native authored token source or one explicit generation direction: exact values consumed by implementation;
+- selected authored targets: concrete composition/condition coverage, kept as ordinary versioned project Source.
+
+Do not copy the same fact into several owners. Open Design metadata is provenance only.
+
+## Adoption procedure
+
+1. Read the project's `DESIGN.md` format and lint expectations. Preserve valid project-specific content unless the user explicitly authorized replacement.
+2. Reconcile selected provider semantics against controlling Context. Provider-invented business, permission, data or algorithmic rules are excluded unless independently authorized by product Source.
+3. Write the selected visual system into `DESIGN.md` and declare exactly one authored exact-value token source or generation direction. Avoid style-only adjectives without implementation meaning.
+4. Record provider provenance in a normal `DESIGN.md` section unless the format explicitly permits metadata fields. Include provider name/version, design-system ID, selected revision when applicable, selection basis, source/snapshot locator and SHA-256 digest. State that project files are canonical.
+5. Update only relevant Context when durable surface/interaction/verification facts changed. Use stable surface/control/target keys to connect owners without duplicating the visual prose.
+6. Put concrete selected targets/tokens in project-native versioned paths selected by the user or existing project convention. Never silently choose a repository directory merely because Open Design has a mutable workspace.
+7. Accept the selected provider revision if one exists, then re-read the MCP design-system resource and compare its identity/body or digest with the adopted selection.
+8. Verify downstream project binding by creating or reading a provider project with the selected ID. Provider mismatch is a synchronization problem, not evidence that project Design Authority is absent.
+
+## Validation
+
+Run the repository-owned Design Authority lint, Context validation and token generation/check paths. At minimum confirm:
+
+- `DESIGN.md` is no longer an unconfigured starter;
+- exactly one authored token source/generation direction is declared and resolvable;
+- provenance points to the selected provider ID/revision/digest;
+- no competing design-system authority or duplicate token owner was introduced;
+- MCP can read the provider design system;
+- a downstream Open Design project reports the matching `designSystemId`;
+- candidate resources remain candidates unless independently selected.
+
+Report changed owners and validation results. Do not claim production visual acceptance from these checks.

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

@@ -0,0 +1,110 @@
+# Open Design Design-System Provider
+
+Use Open Design's live structured surface. Do not assume the installed version matches this compatibility note; discover first and branch on actual tool/resource schemas.
+
+## Capability order
+
+1. Open Design MCP resources/tools.
+2. The same installed Open Design daemon's structured HTTP API when MCP lacks the required design-system lifecycle operation.
+3. Open Design UI/CLI only for bootstrap, preview inspection or a capability unavailable through structured paths.
+
+Never call a copied prompt or local imitation a provider result. Persistent MCP registration, plugin/auth changes and new disclosure paths require separate authorization.
+
+## Current verified MCP contract
+
+Open Design 0.15.1 exposed MCP server 0.2.0 using protocol `2025-06-18`. A live read-only smoke observed 152 concrete design-system resources through `resources/list`; `resources/read` returned their Markdown bodies. The URI families are:
+
+- `od://design-systems/<id>/DESIGN.md` for current design-system bodies;
+- `od://skills/<id>/SKILL.md` for functional skills;
+- `od://focus/active` for current focus.
+
+This version returns `-32601` for `resources/templates/list`. Treat template enumeration as optional protocol capability: use concrete `resources/list` results when present and never reject a readable design-system catalogue merely because the template-list method is absent.
+
+Its 18 observed tools included `list_projects`, `get_project`, `create_project`, `start_run`, `get_run`, file/artifact operations and capability discovery. `create_project` accepts optional `designSystem`; verify the result through `get_project.designSystemId`. This version exposes design systems as resources but no create/update design-system MCP tool.
+
+Feature-detect future structured methods before using the fallback. A tool name alone is insufficient: inspect its input schema and result.
+
+## Generation fallback for Open Design 0.15.1
+
+When MCP cannot create a design system, discover the running daemon and use its official API. Prefer install metadata supplied by Open Design rather than hardcoded paths. Confirm `/api/health` and the version first.
+
+Start generation:
+
+```http
+POST /api/design-systems/generation-jobs
+Content-Type: application/json
+```
+
+The body is the provider's current design-system input. Supported 0.15.1 fields observed in the installed provider include:
+
+```json
+{
+  "title": "Product design system",
+  "category": "Custom",
+  "surface": "web",
+  "summary": "Product and brand intent",
+  "sourceNotes": "Bounded design brief",
+  "provenance": {
+    "companyBlurb": "Product context",
+    "sourceUrls": [],
+    "githubUrls": [],
+    "localCodeFiles": [],
+    "figFiles": [],
+    "assetFiles": [],
+    "notes": "Selection constraints"
+  }
+}
+```
+
+Send only relevant, user-authorized sources. Do not transmit secrets or unrelated repository content. `surface` is provider-defined; validate the live accepted value. A supplied `body` creates a direct draft and must not be misrepresented as model generation.
+
+Poll `GET /api/design-systems/generation-jobs/<jobId>` at a bounded cadence until a terminal state. Preserve the job ID, step diagnostics and returned `designSystemId`. The observed pipeline explores resources, creates a draft, generates `DESIGN.md`/README/SKILL/tokens/previews/context files, registers files and prepares review.
+
+## Review and revision
+
+Read the system and inspect its assets through:
+
+- `GET /api/design-systems/<id>`;
+- `GET /api/design-systems/<id>/files` and `/file?path=<path>`;
+- `GET /api/design-systems/<id>/preview` or `/showcase`;
+- `POST /api/design-systems/<id>/workspace` when an editable review project is required.
+
+Create scoped feedback with:
+
+```http
+POST /api/design-systems/<id>/revision-jobs
+Content-Type: application/json
+
+{"feedback":"...","sectionTitle":"optional section"}
+```
+
+Poll the returned job through the generation-job endpoint. A succeeded revision job creates a pending revision; it does not alter project authority and must not be called accepted. Inspect revisions with `GET /api/design-systems/<id>/revisions`. After explicit selection, set exactly that revision to accepted:
+
+```http
+PATCH /api/design-systems/<id>/revisions/<revisionId>
+Content-Type: application/json
+
+{"status":"accepted"}
+```
+
+Reject explicitly discarded revisions when useful. Accepting a provider revision updates the provider copy only; the authority-adoption step still owns the project writeback.
+
+The provider also exposes `POST /api/design-systems/<id>/token-contract/rebuild-jobs`. Use it only when the live token-quality decision says a rebuild is available or the user explicitly requests a forced rebuild. A generated token contract still needs selection and project adoption.
+
+## Provider binding for downstream resources
+
+For a new Open Design resource project, call MCP `create_project` with the adopted provider ID in `designSystem`. Immediately call `get_project` and require `designSystemId` to match.
+
+For an existing project, inspect `get_project` first. When it is missing or mismatched, prefer a new bounded project with the correct binding if MCP offers no safe update. Use a live structured provider update only after feature-detecting it and preserving project identity. Never proceed with a style-bearing run while silently bound to another system.
+
+## Failure semantics
+
+Keep these states separate:
+
+- daemon/MCP execution: queued, running, succeeded, failed, cancelled or unknown;
+- candidate artifacts: missing, partial, retrievable, rendered or corrupt;
+- selection: unreviewed, selected, rejected or decision-required;
+- project adoption: unchanged, partially adopted, adopted or inconsistent;
+- provider binding: unverified, matched or mismatched.
+
+Preserve exact errors and stop bounded polling. Do not mark a candidate selected because generation succeeded, and do not mark project authority adopted because a provider revision was accepted.

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

@@ -25,6 +25,7 @@ Prefer the lowest practical Authoring, Runtime, State, Recovery and verification
 
 Read only the reference needed for the current phase; these files are guidance, not new artifacts or authority:
 
+- When inputs are raw, mixed, attachment-heavy, incomplete or need synthesis/refinement before Contract mapping, read [`references/source-authoring.md`](references/source-authoring.md) and author the needed self-contained meaning directly inside this workflow.
 - Before creating or structurally revising Source markers, Outcomes, requirements, controls, obligations, architecture boundaries, paths, Bindings, Assertions or risk, read [`references/contract-authoring.md`](references/contract-authoring.md).
 - Before creating or repairing Checks, runners, Observations, proof surfaces, Playwright/structured evidence, Counterfactuals, Population or environment probes, read [`references/evidence-design.md`](references/evidence-design.md).
 - Before Preflight, Compile, protected revision, resume, targeted verify, Final Gate, Stop, close or abandon, read [`references/authority-lifecycle.md`](references/authority-lifecycle.md).
@@ -43,18 +44,19 @@ A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema
 
 ## Entry And Authoring Loop
 
-1. Read the user request or external proposal plus minimum controlling Context and decide `Context Delta: none|required`.
+1. Read the user request or external initial proposal, selected design resources and minimum controlling Context, then decide `Context Delta: none|required`.
    - For material production UI, read the Contract-authoring visual guidance before Compile. Inspect any external design resources as ordinary Source, including selection basis, stable identity and declared surface/viewport/mode/state coverage. An unconfigured starter, candidate, style-only rule or inspiration-only reference is incomplete design authority unless Source explicitly scopes the result as prototype/non-fidelity or supplies a selected target before implementation.
    - If the user is asking to generate or iterate standalone design resources before Contract authoring rather than execute this delivery, use `design-resource-authoring` instead. Its result may later return as ordinary Source; it creates no Contract Draft or Authority.
 2. If a valid active binding exists, run `ty-context long-task resume <workdir>` and read the lifecycle reference.
-3. Otherwise author one complete Delivery Contract for the whole selected delivery. Declare the target profile, its non-empty required product target refs, each target's runtime family/root entrypoint, ordered Stages and vertical Outcomes. Do not create a second Contract plan, matrix or top-level Contract split.
-4. Preserve at least one real `source_path`. Wrap every material Source item in its original Markdown with non-rendering `ty-source-item:start/end` markers without rewriting the text; marked Source Item keys and `source_claim` keys are exactly equal.
-5. An ordinary prose plan, optional Source Plan or externally authored design resource remains valid Source after marker-only enumeration and does not need to match a recommended authoring structure. Preserve stable semantic keys and Markdown anchors where practical. External design authoring neither updates Context nor creates Contract authority by itself; candidate resources authorize no fidelity Claim.
-6. Continue reading repository, Source and Context and revise the same Draft. A request to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent the user's tradeoff priorities. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. Infer them only from the user's words, Source, Context or controlling constraints. If quality versus cost, speed, reliability, privacy, lock-in, operational burden or another material priority is unknown or ambiguous, stop before that research or selection and ask one concise targeted clarification. Do not impose a questionnaire, re-ask known preferences or interrupt minor reversible choices whose recommendation would not change.
-7. Once the material preference envelope is clear, decide what research is needed. Use current authoritative or primary evidence for external capability, pricing, quota, license, compatibility, region, security posture or support claims. When one recommendation is then defensible, record it in real Source with the authoring instruction, preference/evidence basis and exact added meaning instead of pausing for approval. Append the delegated item without rewriting the user's original text when ordinary prose is the Source. Return only when authoritative requirements conflict, the user explicitly reserves the choice, a material preference remains unknown, critical semantics have no defensible recommendation or no falsifiable acceptance standard can be formed.
-8. Contract expansion remains limited to meaning-preserving structural decomposition, evidence-backed repository binding and choices first recorded as delegated real Source. Never place a new product rule, default, threshold, recovery behavior, permission or platform/data scope only in Contract YAML. Default plan delegation authorizes meaning, not action: payment, contracting, production deployment or publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named external confirmations. Any conflicting, user-reserved, missing-preference or unsupported semantic remains `decision_required`.
-9. Give every Check an atomic Given/When scenario and journey role; give every Assertion the minimum all-of Evidence Capabilities that can actually prove its Claim. Separate required success and degradation Checks. Type every external confirmation with impacted Claim refs and target-blocking effect. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
-10. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
+3. If the inputs are not yet self-contained, use the Source-authoring reference now. Inventory every proposal, selected design resource and attachment; preserve direct meaning; add only traceable derived/delegated meaning; enumerate material surfaces/controls/states and acceptance; and resolve or retain genuine decisions. Revise a supplied writable initial proposal when it is the delivery Source. If the request exists only in conversation, materialize exactly one project-native Markdown Source for this delivery. This is an internal authoring step in the same Goal, not a standalone Source Plan service, second plan, schema, gate or lifecycle.
+4. Otherwise author one complete Delivery Contract for the whole selected delivery. Declare the target profile, its non-empty required product target refs, each target's runtime family/root entrypoint, ordered Stages and vertical Outcomes. Do not create a second Contract plan, matrix or top-level Contract split.
+5. Preserve at least one real `source_path`. Wrap every material Source item in its original Markdown with non-rendering `ty-source-item:start/end` markers without rewriting direct text; marked Source Item keys and `source_claim` keys are exactly equal. Newly delegated meaning must first be written into that real Source with provenance before marking.
+6. An ordinary prose proposal, legacy Source Plan or externally authored design resource remains valid Source and does not need to match a recommended structure. Preserve stable semantic keys and Markdown anchors where practical. Selected resources retain their stable resource/surface/control/state/target keys, declared coverage, provider/project/run/entry provenance and immutable digest/snapshot; candidates authorize no fidelity Claim.
+7. Continue reading repository, Source and Context and revise the same Draft. A request to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent the user's tradeoff priorities. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. Infer them only from the user's words, Source, Context or controlling constraints. If quality versus cost, speed, reliability, privacy, lock-in, operational burden or another material priority is unknown or ambiguous, stop before that research or selection and ask one concise targeted clarification. Do not impose a questionnaire, re-ask known preferences or interrupt minor reversible choices whose recommendation would not change.
+8. Once the material preference envelope is clear, decide what research is needed. Use current authoritative or primary evidence for external capability, pricing, quota, license, compatibility, region, security posture or support claims. When one recommendation is then defensible, record it in real Source with the authoring instruction, preference/evidence basis and exact added meaning instead of pausing for approval. Append the delegated item without rewriting the user's original text when ordinary prose is the Source. Return only when authoritative requirements conflict, the user explicitly reserves the choice, a material preference remains unknown, critical semantics have no defensible recommendation or no falsifiable acceptance standard can be formed.
+9. Contract expansion remains limited to meaning-preserving structural decomposition, evidence-backed repository binding and choices first recorded as delegated real Source. Never place a new product rule, default, threshold, recovery behavior, permission or platform/data scope only in Contract YAML. Default plan delegation authorizes meaning, not action: payment, contracting, production deployment or publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named external confirmations. Any conflicting, user-reserved, missing-preference or unsupported semantic remains `decision_required`.
+10. Give every Check an atomic Given/When scenario and journey role; give every Assertion the minimum all-of Evidence Capabilities that can actually prove its Claim. Separate required success and degradation Checks. Type every external confirmation with impacted Claim refs and target-blocking effect. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
+11. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
 
 Architecture quality uses the existing authority model, not a new gate: when Source or controlling Context declares an architecture invariant, encode it as a Source-backed technical obligation/global constraint/forbidden shortcut plus owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture claim can fail independently. An unverifiable design preference remains task-local, durable Context or `decision_required`; it must not be promoted into false proof.
 

package/assets/skills/long-task-workflow/references/contract-authoring.md

@@ -9,7 +9,8 @@ Read this only while authoring or structurally revising the one `delivery-contra
 - Typed dispositions keep Result, Requirement, Control, Technical Obligation, Non-completing Claim, Acceptance, Global Constraint/Non-goal, Forbidden Shortcut, Risk, External Confirmation and Decision distinct.
 - Every non-decision Source item owns exactly one same-kind, text-identical canonical target; no target may collapse multiple Source items. `out_of_scope` is not a resolution.
 - A Source AC maps criterion-identically to one named Assertion and proves at least one independently Source-backed non-Result Claim.
-- Missing recommended Source Plan headings or keys never blocks authoring. Missing mandatory Material Source Item markers does.
+- Missing recommended legacy Source Plan headings or keys never blocks authoring. When raw/mixed inputs are not self-contained, use `source-authoring.md` inside this workflow before Contract mapping. Missing mandatory Material Source Item markers does block activation.
+- A revised initial proposal and selected design resources are parallel Source inputs. Preserve their stable resource/surface/control/state/target keys, declared conditions, provider/project/run/entry provenance and immutable digest/snapshot; do not flatten visual meaning into an untraceable prose summary.
 - `delegated` in a Source Plan is provenance, not a Contract disposition or new Claim kind. An instruction to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent material tradeoff preferences. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. If such a preference is unknown or ambiguous, ask a concise targeted question before research or selection and keep the item `decision_required` until answered; do not impose a fixed questionnaire or re-ask preferences already supplied by the user, Source, Context or controlling constraints.
 - Once the material preference envelope is clear, use current authoritative or primary evidence for external capability, price, quota, license, compatibility, region, security posture or support claims. When one defensible recommendation exists, record the authoring instruction, preference/evidence or conservative-default basis and exact added meaning in real Source, then preserve that keyed item as ordinary Source of its semantic kind. If ordinary prose is the Source, append the delegated item without rewriting the user's original text; never place the choice only in Contract YAML.
 - A delegated plan choice is not action authorization. Payment, contracting, production deployment/publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named External Confirmations. Conflicting authority, an explicitly user-reserved choice, a missing material preference or the absence of a defensible recommendation remains `decision_required`; high impact or multiple options with known criteria alone does not.
@@ -91,7 +92,7 @@ When the selected delivery includes a new/redesigned screen, primary layout/navi
 - keep subjective visual direction, taste or approval outside false machine proof. Resolve an undecided direction as `decision_required`; represent required human design or new-baseline approval as an explicit external confirmation.
 - for combined design-and-implementation delivery, ordinary design Outcomes/Stages may author candidates before selection, but candidate/planned artifacts cannot authorize fidelity Claims. Append the selected result to real marked Source and the owning registry/target input; after Authority Lock adopt it through the existing protected revision before downstream fidelity implementation. This creates no target-selection state, second Contract or second Gate.
 
-External authored design resources remain ordinary upstream Source rather than a Contract Draft, verification result or alternate authority. This guidance adds no UI-specific Contract block, Claim kind, risk level, lifecycle state, required design package, design directory or Gate. The additive generic Control fields only preserve Source meaning through existing Source, Requirement/Control/Assertion, Stage, Binding, proof-surface, verification-input, revision and external-confirmation mechanisms.
+External authored design resources remain ordinary upstream Source rather than a Contract Draft, verification result or alternate authority. The revised initial proposal plus selected immutable resources is the recommended upstream input; no standalone Source Plan handoff is required. A legacy Source Plan remains valid ordinary Source if supplied. This guidance adds no UI-specific Contract block, Claim kind, risk level, lifecycle state, required design package, design directory or Gate. The additive generic Control fields only preserve Source meaning through existing Source, Requirement/Control/Assertion, Stage, Binding, proof-surface, verification-input, revision and external-confirmation mechanisms.
 
 ## Compact Authoring
 

package/assets/skills/long-task-workflow/references/source-authoring.md

@@ -0,0 +1,98 @@
+# Integrated Source Authoring Reference
+
+Read this when raw, mixed, attachment-heavy or incomplete inputs need to become self-contained delivery Source before Contract mapping. This work occurs inside the same `long-task-workflow` Goal and feeds the same Contract Draft; it is not a standalone Source Plan stage or second lifecycle.
+
+## Objective and boundary
+
+Preserve every material user, product, technical, visual and acceptance constraint from the initial/revised proposal and supplied resources. Add only traceable necessary derivations, defensible delegated choices and evidence-backed repository facts. Make the real Source understandable without the original conversation.
+
+Do not create a Source Plan schema, CLI, Preflight, Compile, Receipt, cache, authority or state. Do not bind a choice only in Contract YAML. Do not let current implementation silently redefine intent. A pre-existing Source Plan is simply one possible input.
+
+## Input inventory
+
+1. Assign every proposal, selected design resource, screenshot, document, diagram, table and other attachment a stable input ID.
+2. Inspect all material pages/frames/screens/tables/visible states; never silently sample a multi-part artifact.
+3. Classify each input as user instruction, product requirement, technical constraint, existing proposal, selected target, repository/Context evidence, constraint, inspiration or background.
+4. For visual resources, preserve selection basis, classification (`exact-target`, `constraint` or `inspiration`), stable resource/surface/control/state/target keys, declared platform/viewport/mode/state/content coverage, provider/project/run/entry provenance and immutable digest/snapshot. Unselected candidates authorize no fidelity.
+5. Record incorporated meaning and every unreadable, conflicting or intentionally unused part. Higher authority and user-stated precedence win; unresolved conflicts remain decisions.
+
+## Preference and research gate
+
+Before comparative research or a material product, technical, architecture or provider selection, identify decision-changing criteria such as fidelity versus cost, delivery speed, reliability/support, privacy/compliance, lock-in/control, operational burden, platform scope and extensibility.
+
+Infer preferences only from user words, Source, Context or controlling constraints. If an unknown preference would materially change research or recommendation, ask one concise targeted clarification before proceeding. Do not impose a questionnaire, re-ask known preferences or pause for minor reversible choices with the same defensible recommendation.
+
+Use current primary/authoritative evidence for changing external facts. Record source, scope and retrieval date. Preference clarification authorizes plan meaning, not payment, contracting, deployment/publication, destructive production mutation, permission grants, sensitive-data transmission or required legal/security/human approval; those remain typed external confirmations.
+
+## Authoring modes
+
+Infer rather than ask the user to choose:
+
+- **refinement:** preserve and complete a substantially developed proposal;
+- **synthesis:** build coherent Source from a goal plus mixed inputs;
+- **hybrid:** use one proposal as backbone and fill gaps from other inputs.
+
+A short request is sufficient when roles, goal and reference authority are recoverable. Reuse an authorized writable proposal as the real Source. If the delivery exists only in conversation, materialize exactly one project-native Markdown Source according to repository convention. Do not create a parallel planning artifact.
+
+## Semantic authoring
+
+For every material item, preserve one origin:
+
+- `direct`: stated by user or controlling input, with all qualifiers;
+- `derived`: unavoidable for completeness/falsifiability, identifies `Derived From`, states why necessary and changes no user capability, business rule or scope;
+- `delegated`: a defensible choice requested by instructions to synthesize/refine/use judgment, records `Delegated By`, preference/evidence basis and exact added meaning;
+- `evidence-backed`: repository/Context fact with exact source and no promotion of incidental code shape to product intent;
+- `decision_required`: conflicting authority, explicitly user-reserved choice, missing material preference or no defensible recommendation.
+
+High impact or several options is not itself a reason to pause when criteria support one recommendation. Keep real high-risk actions as external confirmations. Never introduce a requirement for the first time only inside acceptance criteria.
+
+## Structure and stable keys
+
+Use stable semantic lowercase-kebab keys and Markdown anchors where practical. Preserve keys when wording changes but meaning does not; never renumber for ordering or reuse a retired key for new meaning.
+
+Define vertical Outcomes only when observable results are independently decidable and later verifiable. Do not split by response length, frontend/backend layer, module count, agent capacity or desired parallelism; do not merge distinct results merely for brevity.
+
+Use only applicable semantic types:
+
+- result/Outcome;
+- Requirement (`REQ`);
+- user-visible Control (`CTRL`);
+- technical obligation (`OBL`);
+- explicitly non-completing meaning (`NCOMP`);
+- acceptance scenario (`AC`);
+- global non-goal/constraint and forbidden shortcut;
+- risk with exact Fact, Affected Outcome, Basis and Consequence;
+- external confirmation (`EXT`);
+- genuine decision (`DEC`);
+- advisory implementation hint (`HINT`), which is not a material requirement.
+
+## UI and control completeness
+
+For each in-scope surface, record purpose, entry/exit/navigation, regions/overlays and included Control keys. For every material interactive control, independently preserve applicable:
+
+`surface`, `region`, `control type`, `label/content`, `location`, `user task`, `visibility`, `availability`, `trigger`, `input`, `validation`, `default`, `interaction`, `navigation/result`, `loading`, `empty`, `success`, `failure`, `recovery`, `permission`, `feedback` and `accessibility`.
+
+Do not invent controls for a non-interface delivery. A coarse frame or configured design system does not supply unshown states. Selected design resources and product/technical Source remain parallel: visuals cannot invent business/data/permission/algorithmic rules.
+
+## Acceptance and risk
+
+Each AC has exactly one Given/When/Then scenario, names the REQ/CTRL/OBL/NCOMP meaning it accepts and introduces no undeclared product semantics. Keep representative/sample/framework checks distinct from full-population claims and partial delivery distinct from completion.
+
+Use the Runtime's exact risk Fact names when marking risk. Data migration is `data_migration`; a weakly observable critical path is separate `critical_user_path` and `weak_observability` facts; preserve `multi_repository_change` in Source so Contract compilation can reject unsupported delivery honestly.
+
+## Completeness audit
+
+Before Contract mapping confirm:
+
+1. Every material original statement and qualifier is preserved.
+2. Every supplied input is incorporated or has an explicit unreadable/unused/conflict disposition.
+3. Distinct requirements and independently decidable Outcomes were not collapsed.
+4. Every material UI surface/control/state is explicit or marked not applicable/unresolved.
+5. Every REQ and material CTRL state has acceptance, external confirmation, decision or explicit exception.
+6. Derived/delegated/evidence-backed items have traceable basis and no hidden product expansion.
+7. Non-goals, forbidden shortcuts, risks and recovery are concrete.
+8. No unsupported number, threshold, metric or external claim appears.
+9. Selected design resources retain stable identity and exact declared coverage; candidates remain non-authoritative.
+10. The Source is self-contained enough for Contract authoring and names every still-required external artifact.
+
+Then add non-rendering `ty-source-item:start/end` markers to the real Markdown Source without rewriting direct text, and proceed to `contract-authoring.md`. The markers and Contract mapping are part of this same Long-Task authoring loop.