project-tiny-context-harness 0.8.0 → 0.8.1

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

@@ -1,110 +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.
+# 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

@@ -1,100 +1,100 @@
----
-name: long-task-workflow
-description: Author, preflight, execute, resume, verify, or close one complete Single-Goal Delivery Contract in the current native Goal and workspace. Use only when explicitly invoked or a valid common-dir active authority binding exists.
----
-
-# Single-Goal Long-Task Workflow
-
-## Boundaries
-
-Use one current native Goal, one repository, one selected workspace, one complete Contract and one Final Gate. Never create a scheduler, model worker, agent runtime, App Server, branch, worktree, merge, push, PR, deployment, Campaign/SFC/Packet/Wave chain, matrix, verdict or second Contract plan. Never activate from task size alone.
-
-The host and user own model selection and native-Goal lifecycle. The workflow has exactly one user-choice checkpoint after the first Authority Lock and before implementation; Harness neither switches the model nor persists model-routing/checkpoint state. No checkpoint file, acknowledgement state, model route, model-tier scheduler, automatic model switch, `authority_revision_in_progress` state or native-Goal completion state is created. Outside that boundary, do not pause a healthy Goal solely to change or downgrade the model. Do not create a separate approval checkpoint for a defensible recommended plan choice. A targeted pre-Authority clarification is still required when a missing user preference could materially change research or selection; genuine Source conflicts or choices the user explicitly reserves may likewise require a decision before Authority Lock. Capability-related drift is handled by targeted repair plus the Final Gate. Never proactively spawn, assign or coordinate parallel subagents. Platform-native internal delegation, if it occurs, is opaque and non-authoritative and must converge into the unified current workspace snapshot before verification can count.
-
-`long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. `delivery-set` is retired and non-executing.
-
-## Controlling Objective
-
-Prevent false completion inside declared authority. Implementation may drift, fail or require rework, but every declared non-Result requirement and AC must remain traceable and every unsatisfied, unverifiable, insufficiently evidenced or stale item must block completion. In particular, a proxy target, presence text, degradation path, fixed input, self-reported boundary effect or internal entrypoint must never substitute for the declared target behavior. Findings should localize repair through Source Item, Stage, Outcome, Claim, Assertion, Check, Evidence Capability, execution target, Binding and owner boundary.
-
+---
+name: long-task-workflow
+description: Author, preflight, execute, resume, verify, or close one complete Single-Goal Delivery Contract in the current native Goal and workspace. Use only when explicitly invoked or a valid common-dir active authority binding exists.
+---
+
+# Single-Goal Long-Task Workflow
+
+## Boundaries
+
+Use one current native Goal, one repository, one selected workspace, one complete Contract and one Final Gate. Never create a scheduler, model worker, agent runtime, App Server, branch, worktree, merge, push, PR, deployment, Campaign/SFC/Packet/Wave chain, matrix, verdict or second Contract plan. Never activate from task size alone.
+
+The host and user own model selection and native-Goal lifecycle. The workflow has exactly one user-choice checkpoint after the first Authority Lock and before implementation; Harness neither switches the model nor persists model-routing/checkpoint state. No checkpoint file, acknowledgement state, model route, model-tier scheduler, automatic model switch, `authority_revision_in_progress` state or native-Goal completion state is created. Outside that boundary, do not pause a healthy Goal solely to change or downgrade the model. Do not create a separate approval checkpoint for a defensible recommended plan choice. A targeted pre-Authority clarification is still required when a missing user preference could materially change research or selection; genuine Source conflicts or choices the user explicitly reserves may likewise require a decision before Authority Lock. Capability-related drift is handled by targeted repair plus the Final Gate. Never proactively spawn, assign or coordinate parallel subagents. Platform-native internal delegation, if it occurs, is opaque and non-authoritative and must converge into the unified current workspace snapshot before verification can count.
+
+`long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. `delivery-set` is retired and non-executing.
+
+## Controlling Objective
+
+Prevent false completion inside declared authority. Implementation may drift, fail or require rework, but every declared non-Result requirement and AC must remain traceable and every unsatisfied, unverifiable, insufficiently evidenced or stale item must block completion. In particular, a proxy target, presence text, degradation path, fixed input, self-reported boundary effect or internal entrypoint must never substitute for the declared target behavior. Findings should localize repair through Source Item, Stage, Outcome, Claim, Assertion, Check, Evidence Capability, execution target, Binding and owner boundary.
+
 For selected design resources, one design-specific objective is that Agent implementation, acceptance and testing fully conform to every material UI/UX fact explicitly expressed within declared scope and conditions. Open Design can produce source-rich, implementation-readable resources, but capability alone is not a guarantee: resource authoring must require a canonical entry, complete dependency acquisition and stable machine-resolvable facts. The validated `design-resource-handoff-v1` remains the residual scope/applicability/semantic adapter rather than a copy of CSS values. Preserve each fact through immutable inputs, typed locators, complete subject × target × condition × dimension cells, Context-reachable targets, Source/Control/Claim authority, one independent Assertion per verification method and current-snapshot project Checks to Final Gate. Never invent an unexpressed fact: refine the resource, retain `decision_required`/`unavailable`, or block fidelity work. Neither provider success, file hashes nor handoff integrity proves production conformance.
-
-Only fresh evidence from the complete current final snapshot may create machine acceptance. Otherwise report the task as unfinished or qualified. `machine_accepted_external_pending` means machine-verifiable authority passed while named external confirmation remains; it is not full delivery completion. Machine acceptance covers declared machine Authority and has no direct native-Goal effect. Never substitute prose, progress, historical tests, Receipts, one exit code or Agent judgment for the Final Gate.
-
-Prefer the lowest practical Authoring, Runtime, State, Recovery and verification cost that preserves the same false-completion interception. Add no mechanism whose distinct protection does not materially exceed its total cost.
-
-## Progressive Reference Loading
-
-Read only the reference needed for the current activity; these files are guidance, not new artifacts or authority:
-
-- When inputs are raw, mixed, attachment-heavy, incomplete or need synthesis/refinement while the Contract Draft is being mapped, read [`references/source-authoring.md`](references/source-authoring.md) alongside the Contract-authoring reference. Do not wait for a separate Source-authoring phase before opening the Draft.
-- 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).
-
-Do not copy reference detail into another plan or state file. The same `delivery-contract.yaml`, active authority and current workspace remain the only lifecycle surfaces.
-
-## Contract Draft And Outcome Decomposition
-
-Every input enters the same non-authoritative `delivery-contract.yaml` Draft immediately. Before the first successful formal Compile, continuously revise that Source-bound Draft while real Source inventory, provenance, refinement, markers, repository binding and mapping converge. It need not be completed in one response; keep reading Source, repository and relevant Context and feed Preflight findings back into that same Draft. Draft authoring, Preflight, Compile, rolling execution, targeted verification and Final Gate are one `long-task-workflow` lifecycle. Do not create a Source-authoring phase, standalone Contract Draft Skill, Draft Receipt, Authoring State, draft schema/CLI/runtime state or second plan.
-
-A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema field or runtime entity. Decompose only vertical, independently observable, decidable and target-verifiable results whose dependencies and owner boundary can be stated; one Outcome belongs to one declared Stage and does not span materially different success paths. Declare the ordered Stage DAG and one gate Outcome per Stage in the same Contract. Use those boundaries to keep a stage-constrained dependency-ready working set, target verification, localize failures, resume findings/next actions and stale local results precisely.
-
-`depends_on` means acceptance readiness. The gate Outcome transitively depends on the rest of its Stage, later Stage Outcomes depend on prerequisite gate Outcomes, and every multi-Outcome gate proves cross-surface consistency. The current Goal derives a temporary Rolling Frontier from Stage and Outcome status, but must not persist a Stage Receipt, scheduler, Worker queue, mandatory implementation DAG, model route or process tree. Never split for response/YAML/file length, implementation layer, module/file count, Agent capacity, Worker assignment or desired parallelism.
-
-> Outcome decomposes execution and diagnosis, not completion authority.
-
-## Entry And Authoring Loop
-
-1. Read the user request or external initial proposal, selected design resources and minimum controlling Context. Collect the architecture owners, extension points and boundaries needed for the shared deliberation before deciding `Context Delta`.
+
+Only fresh evidence from the complete current final snapshot may create machine acceptance. Otherwise report the task as unfinished or qualified. `machine_accepted_external_pending` means machine-verifiable authority passed while named external confirmation remains; it is not full delivery completion. Machine acceptance covers declared machine Authority and has no direct native-Goal effect. Never substitute prose, progress, historical tests, Receipts, one exit code or Agent judgment for the Final Gate.
+
+Prefer the lowest practical Authoring, Runtime, State, Recovery and verification cost that preserves the same false-completion interception. Add no mechanism whose distinct protection does not materially exceed its total cost.
+
+## Progressive Reference Loading
+
+Read only the reference needed for the current activity; these files are guidance, not new artifacts or authority:
+
+- When inputs are raw, mixed, attachment-heavy, incomplete or need synthesis/refinement while the Contract Draft is being mapped, read [`references/source-authoring.md`](references/source-authoring.md) alongside the Contract-authoring reference. Do not wait for a separate Source-authoring phase before opening the Draft.
+- 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).
+
+Do not copy reference detail into another plan or state file. The same `delivery-contract.yaml`, active authority and current workspace remain the only lifecycle surfaces.
+
+## Contract Draft And Outcome Decomposition
+
+Every input enters the same non-authoritative `delivery-contract.yaml` Draft immediately. Before the first successful formal Compile, continuously revise that Source-bound Draft while real Source inventory, provenance, refinement, markers, repository binding and mapping converge. It need not be completed in one response; keep reading Source, repository and relevant Context and feed Preflight findings back into that same Draft. Draft authoring, Preflight, Compile, rolling execution, targeted verification and Final Gate are one `long-task-workflow` lifecycle. Do not create a Source-authoring phase, standalone Contract Draft Skill, Draft Receipt, Authoring State, draft schema/CLI/runtime state or second plan.
+
+A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema field or runtime entity. Decompose only vertical, independently observable, decidable and target-verifiable results whose dependencies and owner boundary can be stated; one Outcome belongs to one declared Stage and does not span materially different success paths. Declare the ordered Stage DAG and one gate Outcome per Stage in the same Contract. Use those boundaries to keep a stage-constrained dependency-ready working set, target verification, localize failures, resume findings/next actions and stale local results precisely.
+
+`depends_on` means acceptance readiness. The gate Outcome transitively depends on the rest of its Stage, later Stage Outcomes depend on prerequisite gate Outcomes, and every multi-Outcome gate proves cross-surface consistency. The current Goal derives a temporary Rolling Frontier from Stage and Outcome status, but must not persist a Stage Receipt, scheduler, Worker queue, mandatory implementation DAG, model route or process tree. Never split for response/YAML/file length, implementation layer, module/file count, Agent capacity, Worker assignment or desired parallelism.
+
+> Outcome decomposes execution and diagnosis, not completion authority.
+
+## Entry And Authoring Loop
+
+1. Read the user request or external initial proposal, selected design resources and minimum controlling Context. Collect the architecture owners, extension points and boundaries needed for the shared deliberation before deciding `Context Delta`.
    - For material production UI, read the Contract-authoring visual guidance before Compile. When selected resources arrive as an implementation handoff, require one marked `design-resource-handoff-v1` in `task.source_paths` and run `ty-context design-resource preflight <handoff.md>`; incomplete applicable cells, unsupported evidence, unresolvable locators, partial implementation-source acquisition, unresolved meaning or stale resource identity is blocking. Traverse affected surface/control/target keys from owning Context through `DESIGN.md`, then open every affected selected `exact-target` or `constraint` as Context-reachable ordinary Source. Confirm selection basis, readable immutable identity/digest, declared surface/viewport/mode/state coverage and editable upstream owner/locator/update route. A registry or handoff index mention is not consumption. Missing, stale, unreadable, truncated or conflicting resources remain `decision_required`; if only the editable upstream is unavailable, the immutable target may guide implementation but requested resource edits remain a manual/external boundary. 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. When Controls exist, bind them through Product `surface_bindings` to the required production target, existing route/component Bindings and a root-entry journey; each selected target's identity/conditions/files, covered Source Claims/root Assertion, per-method independent Assertions and blocker lineage must match the handoff before typed evidence can prove it.
-   - 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. Start one complete Delivery Contract Draft for the whole selected delivery immediately. If inputs are not self-contained, apply the Source-authoring reference inside this same Draft loop: inventory every proposal/resource/attachment, refine the writable real Source, preserve traceable provenance and resolve or retain genuine decisions while mapping target profile, Stages, Outcomes and repository evidence. Conversation-only material becomes exactly one project-native Markdown Source. Source completeness is a Preflight/Compile convergence requirement, not an earlier internal stage.
-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 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 its corresponding Draft meaning can pass Preflight/Compile.
+   - 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. Start one complete Delivery Contract Draft for the whole selected delivery immediately. If inputs are not self-contained, apply the Source-authoring reference inside this same Draft loop: inventory every proposal/resource/attachment, refine the writable real Source, preserve traceable provenance and resolve or retain genuine decisions while mapping target profile, Stages, Outcomes and repository evidence. Conversation-only material becomes exactly one project-native Markdown Source. Source completeness is a Preflight/Compile convergence requirement, not an earlier internal stage.
+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 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 its corresponding Draft meaning can pass Preflight/Compile.
 5. 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 applicability, source profile/entry/dependency set, provider/project/run provenance, typed locators, immutable digest/snapshot and editable upstream owner/locator/update route. Candidates authorize no fidelity Claim. Changing an adopted resource produces a new immutable version and updates the owning reference rather than overwriting the locked baseline.
-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. Before formal Compile and the first implementation edit, complete the shared `Architecture Deliberation` once and surface concise repository-bound conclusions rather than private reasoning. Cover the current owner/extension point/source of truth, dependencies and lifecycle, selected and rejected alternatives, a plausible future-change challenge, touched debt and its disposition, forbidden shortcuts and project-owned Checks. Even a preservation result names concrete owners and why no new or worsened debt is introduced. Put durable conclusions in owning Context and material falsifiable delivery conclusions in real marked Source plus existing Contract fields, then decide `Context Delta: none|required`. A material scope, owner, Context or design change before implementation stales and refreshes the deliberation.
-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. For selected design targets, keep resource-integrity Checks distinct from root-bound implementation conformance, freeze the validated handoff and target resources, preserve exact condition equality, map every covered handoff Source Item into the conformance Assertion and declare current actual/comparison artifacts. Run read-only `ty-context long-task preflight <workdir>`, repair every handoff, Contract and `decision_required` error in the same Draft, then formally Compile only when ready.
-11. When the first Compile returns `execution_model_checkpoint.required: true`, obey its terminal-turn boundary. Unless an earlier user message explicitly states this task's current-model or switch-and-resume strategy, do no product implementation, file edit, build or test after that result; end the current turn and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. Generic “continue”, “resume”, “finish” or “continue the Goal” language does not satisfy the checkpoint. Later revisions return `required: false` and do not repeat it.
-
-Architecture quality uses the existing authority model, not a new gate or field. The visible deliberation proves that architecture work occurred, not that subjective quality is machine-proven. Encode every material falsifiable invariant 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.
-
-## Rolling Execution
-
-After Authority Lock and the one-time execution-model checkpoint are satisfied, implement only Outcomes in the derived current Stage frontier, plus prerequisite regression repairs and current Finding repairs, in the current workspace. A later Stage cannot substitute for an unpassed earlier gate. Small implementation plans and repair hypotheses are internal execution state and cannot silently change Product, Technical or Acceptance authority.
-
-Re-evaluate `Context Delta` whenever implementation or repair discovers a durable fact. Controlling Context changes always use Authority Revision; they require a user decision only when mapped Claims, targets, proof obligations or another decision boundary changes. Graph-derived, non-explicit `implementation-index` and `archive` are Supporting Context in referenced mode and may auto-revise when only navigation/background changed. Full snapshot mode treats every selected Context file as controlling.
-
-If rolling implementation materially changes scope, ownership, dependency direction, the selected design or a debt disposition, refresh the Architecture Deliberation and express any authority change through marked Source/Context plus protected revision before continuing. This is refinement of the same checkpoint, not a second workflow stage.
-
-Use `verify --explain [--outcome/--check]` when execution cost is unclear; it previews declared main and Counterfactual runner invocations without executing or writing Progress. Use targeted `verify --outcome/--check` only to drive repair. Progress is repair evidence only and never acceptance authority. Keep precise findings attached to the owning Source item, Claim, Assertion, Check, Binding and owner path. Do not add another model-switch pause or coordinate parallel subagents.
-
-When the Contract declares a target-runtime Check because a proxy can pass while the target fails independently, run it at the earliest owning Outcome's first runnable boundary. Every required target is proved separately from its root; Browser evidence requires Playwright and Native/Desktop evidence requires the project binary. For material UI, the first runnable vertical slice is inspected through the production shell/navigation entry, not only a deep link or detached route. `progress_stale` is a freshness fact, not an immediate execution instruction: after accumulated relevant changes, refresh the Check before dependent work relies on it or before Final Gate. Coalesce related edits and use the cheapest reliable target Check; do not mandate a full environment rebuild per Outcome or per edit. This is rolling feedback through existing targeted verify, not acceptance, a trigger queue or per-target progress state.
-
-When implementation discovers a blocker or missing Contract paths, first classify the revision. Difficulty or delay alone never reclassifies machine-verifiable scope as external and never removes Source; a real scope, Product, Acceptance or machine/external boundary change must first be explicit marked Source. Keep exact revision identity, old-Authority continuity, compare-and-swap adoption, evidence invalidation and the complete Final Gate for every path:
-
-1. machine-proven monotonic strengthening auto-adopts;
-2. locked-semantics-preserving Source/Context snapshot refresh, bounded runner/input/environment repair, repo-bound scope expansion, risk strengthening and machine-proven equivalent Counterfactual coverage auto-adopt as mechanically bounded repair;
-3. a scope-only candidate may additionally use `ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]` to exercise only existing active Check identities with unchanged runner/verifier authority;
-4. Product/Source Claim/target/external-confirmation change, lost scenario/Claim/Evidence Capability/failure interception, forbidden or owner-Context removal, runner type/effect change, verifier-kernel change and every unknown reason remain preview-only and require the exact user-decision identity; risk downgrade is rejected.
-
-Candidate diagnostics are transient: they authorize no acceptance and write no pending/user-decision state, Active Authority, cache, Progress or Receipt. Keep related edits in the same `delivery-contract.yaml`; do not compile each intermediate candidate merely to obtain an identity. When the stable candidate is ready, run ordinary `compile --revise` once. If it needs a decision, first present the self-contained `pending_authority_revision.decision_brief`, which explains Authority Revision, separates `user_decision_reasons` from mechanically bounded changes, names material changes and affected Outcomes, and states reject/previous-Authority, adoption, no-completion and Final-Gate effects. If an explicit current-task instruction already covers every listed decision reason exactly, mechanically relay that existing decision through the exact approval command without asking again; generic continue/resume/finish, blanket authorization, recommendation, partial coverage or Agent inference never qualifies. Otherwise ask once for that stable exact identity. The executing Agent never originates its own weakening decision. Adoption is not delivery completion: discard invalidated evidence, run `status` or `resume`, and return to rolling implementation or repair under the revised Authority before Final Gate.
-
-## Live Final Authority
-
-Complete Context, implementation and project tests, create a clean candidate commit, then run `ty-context long-task final-gate <workdir>`.
-
-Final Gate recompiles Source authority, validates active task/revision/compiled/worktree identity, creates one Git-tree snapshot, reruns every required Global and Outcome Check and rechecks active identity before acceptance. It derives Stage results and target qualification from that run; it does not trust targeted Progress as a Stage pass. A target-runtime Check must exercise its exact target in that current Gate execution; rerunning a reader for a historical or tracked status report is not live target proof. Design-resource integrity, an isolated route or `visual_render` cannot replace required root-bound `design_conformance`, and unresolved design blockers remain blocking. Final Gate, Stop and close never trust historical Progress, Receipt or compiled cache.
-
-Final Gate is the Long-Task path's sole `Architecture Conformance` carrier. It reruns the declared architecture obligations/constraints/forbidden shortcuts, owner/path/Binding boundaries and project-owned Checks on that same snapshot and blocks scope escape, bypass, duplicate authority, a second source of truth, wrong dependency direction, undeclared boundary change or new/worsened debt represented by those invariants. Do not also run the default Workflow's standalone Contract Conformance closure. Any later candidate or authority change invalidates the Gate and uses the existing freshness path again.
-
-Machine acceptance covers only declared machine authority. Preserve every pending external confirmation through `final-gate`, `status`, `resume`, `stop-check`, the package-owned Stop Hook and `close`; accepted output identifies `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`, while `closed_scope: machine_authority` means only Authority cleanup. Do not invent external-confirmation or native-Goal tracking state.
-
-Before invoking platform-native Goal completion, perform one veto-only conformance review: compare the current Goal and user instructions with accepted marked Source, and check for pending revisions, unresolved blockers or omitted requirements. Any mismatch keeps the Goal active and returns to Source/Contract repair. A clean review does not add acceptance proof and never lets Agent judgment replace Final Gate.
-
-## Handoff
-
-Report implementation, effective risk, Architecture Deliberation/Conformance status, Claim Coverage, Stage frontier/results, declared target profile, exact `target_state`, Live Gate result, acceptance scope, every pending external confirmation, Context status and blockers. Use verifier terms exactly: `progress_passing` means targeted repair evidence, `progress_stale` is a freshness fact rather than a current pass or immediate rerun command, `final_workflow_status: null` means unfinished, `authority_revision_adopted` means return to rolling execution, and `machine_accepted_external_pending` must retain its named confirmations. Contract target states are only `implementation_complete`, `target_profile_usable` and `production_release_ready`; terminal failure uses `not_accepted` or `blocked_external`. Never shorten targeted progress to “Outcome complete” or invent per-platform progress/status. State the threat-model limits: the visible checkpoint cannot prove private reasoning or universal future-proofing, undeclared requirements cannot be discovered, installed verifier/Git metadata are trusted, native-Goal/model selection belongs to the host/user, and internal platform delegation is not observed.
+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. Before formal Compile and the first implementation edit, complete the shared `Architecture Deliberation` once and surface concise repository-bound conclusions rather than private reasoning. Cover the current owner/extension point/source of truth, dependencies and lifecycle, selected and rejected alternatives, a plausible future-change challenge, touched debt and its disposition, forbidden shortcuts and project-owned Checks. Even a preservation result names concrete owners and why no new or worsened debt is introduced. Put durable conclusions in owning Context and material falsifiable delivery conclusions in real marked Source plus existing Contract fields, then decide `Context Delta: none|required`. A material scope, owner, Context or design change before implementation stales and refreshes the deliberation.
+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. For selected design targets, keep resource-integrity Checks distinct from root-bound implementation conformance, freeze the validated handoff and target resources, preserve exact condition equality, map every covered handoff Source Item into the conformance Assertion and declare current actual/comparison artifacts. Run read-only `ty-context long-task preflight <workdir>`, repair every handoff, Contract and `decision_required` error in the same Draft, then formally Compile only when ready.
+11. When the first Compile returns `execution_model_checkpoint.required: true`, obey its terminal-turn boundary. Unless an earlier user message explicitly states this task's current-model or switch-and-resume strategy, do no product implementation, file edit, build or test after that result; end the current turn and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. Generic “continue”, “resume”, “finish” or “continue the Goal” language does not satisfy the checkpoint. Later revisions return `required: false` and do not repeat it.
+
+Architecture quality uses the existing authority model, not a new gate or field. The visible deliberation proves that architecture work occurred, not that subjective quality is machine-proven. Encode every material falsifiable invariant 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.
+
+## Rolling Execution
+
+After Authority Lock and the one-time execution-model checkpoint are satisfied, implement only Outcomes in the derived current Stage frontier, plus prerequisite regression repairs and current Finding repairs, in the current workspace. A later Stage cannot substitute for an unpassed earlier gate. Small implementation plans and repair hypotheses are internal execution state and cannot silently change Product, Technical or Acceptance authority.
+
+Re-evaluate `Context Delta` whenever implementation or repair discovers a durable fact. Controlling Context changes always use Authority Revision; they require a user decision only when mapped Claims, targets, proof obligations or another decision boundary changes. Graph-derived, non-explicit `implementation-index` and `archive` are Supporting Context in referenced mode and may auto-revise when only navigation/background changed. Full snapshot mode treats every selected Context file as controlling.
+
+If rolling implementation materially changes scope, ownership, dependency direction, the selected design or a debt disposition, refresh the Architecture Deliberation and express any authority change through marked Source/Context plus protected revision before continuing. This is refinement of the same checkpoint, not a second workflow stage.
+
+Use `verify --explain [--outcome/--check]` when execution cost is unclear; it previews declared main and Counterfactual runner invocations without executing or writing Progress. Use targeted `verify --outcome/--check` only to drive repair. Progress is repair evidence only and never acceptance authority. Keep precise findings attached to the owning Source item, Claim, Assertion, Check, Binding and owner path. Do not add another model-switch pause or coordinate parallel subagents.
+
+When the Contract declares a target-runtime Check because a proxy can pass while the target fails independently, run it at the earliest owning Outcome's first runnable boundary. Every required target is proved separately from its root; Browser evidence requires Playwright and Native/Desktop evidence requires the project binary. For material UI, the first runnable vertical slice is inspected through the production shell/navigation entry, not only a deep link or detached route. `progress_stale` is a freshness fact, not an immediate execution instruction: after accumulated relevant changes, refresh the Check before dependent work relies on it or before Final Gate. Coalesce related edits and use the cheapest reliable target Check; do not mandate a full environment rebuild per Outcome or per edit. This is rolling feedback through existing targeted verify, not acceptance, a trigger queue or per-target progress state.
+
+When implementation discovers a blocker or missing Contract paths, first classify the revision. Difficulty or delay alone never reclassifies machine-verifiable scope as external and never removes Source; a real scope, Product, Acceptance or machine/external boundary change must first be explicit marked Source. Keep exact revision identity, old-Authority continuity, compare-and-swap adoption, evidence invalidation and the complete Final Gate for every path:
+
+1. machine-proven monotonic strengthening auto-adopts;
+2. locked-semantics-preserving Source/Context snapshot refresh, bounded runner/input/environment repair, repo-bound scope expansion, risk strengthening and machine-proven equivalent Counterfactual coverage auto-adopt as mechanically bounded repair;
+3. a scope-only candidate may additionally use `ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]` to exercise only existing active Check identities with unchanged runner/verifier authority;
+4. Product/Source Claim/target/external-confirmation change, lost scenario/Claim/Evidence Capability/failure interception, forbidden or owner-Context removal, runner type/effect change, verifier-kernel change and every unknown reason remain preview-only and require the exact user-decision identity; risk downgrade is rejected.
+
+Candidate diagnostics are transient: they authorize no acceptance and write no pending/user-decision state, Active Authority, cache, Progress or Receipt. Keep related edits in the same `delivery-contract.yaml`; do not compile each intermediate candidate merely to obtain an identity. When the stable candidate is ready, run ordinary `compile --revise` once. If it needs a decision, first present the self-contained `pending_authority_revision.decision_brief`, which explains Authority Revision, separates `user_decision_reasons` from mechanically bounded changes, names material changes and affected Outcomes, and states reject/previous-Authority, adoption, no-completion and Final-Gate effects. If an explicit current-task instruction already covers every listed decision reason exactly, mechanically relay that existing decision through the exact approval command without asking again; generic continue/resume/finish, blanket authorization, recommendation, partial coverage or Agent inference never qualifies. Otherwise ask once for that stable exact identity. The executing Agent never originates its own weakening decision. Adoption is not delivery completion: discard invalidated evidence, run `status` or `resume`, and return to rolling implementation or repair under the revised Authority before Final Gate.
+
+## Live Final Authority
+
+Complete Context, implementation and project tests, create a clean candidate commit, then run `ty-context long-task final-gate <workdir>`.
+
+Final Gate recompiles Source authority, validates active task/revision/compiled/worktree identity, creates one Git-tree snapshot, reruns every required Global and Outcome Check and rechecks active identity before acceptance. It derives Stage results and target qualification from that run; it does not trust targeted Progress as a Stage pass. A target-runtime Check must exercise its exact target in that current Gate execution; rerunning a reader for a historical or tracked status report is not live target proof. Design-resource integrity, an isolated route or `visual_render` cannot replace required root-bound `design_conformance`, and unresolved design blockers remain blocking. Final Gate, Stop and close never trust historical Progress, Receipt or compiled cache.
+
+Final Gate is the Long-Task path's sole `Architecture Conformance` carrier. It reruns the declared architecture obligations/constraints/forbidden shortcuts, owner/path/Binding boundaries and project-owned Checks on that same snapshot and blocks scope escape, bypass, duplicate authority, a second source of truth, wrong dependency direction, undeclared boundary change or new/worsened debt represented by those invariants. Do not also run the default Workflow's standalone Contract Conformance closure. Any later candidate or authority change invalidates the Gate and uses the existing freshness path again.
+
+Machine acceptance covers only declared machine authority. Preserve every pending external confirmation through `final-gate`, `status`, `resume`, `stop-check`, the package-owned Stop Hook and `close`; accepted output identifies `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`, while `closed_scope: machine_authority` means only Authority cleanup. Do not invent external-confirmation or native-Goal tracking state.
+
+Before invoking platform-native Goal completion, perform one veto-only conformance review: compare the current Goal and user instructions with accepted marked Source, and check for pending revisions, unresolved blockers or omitted requirements. Any mismatch keeps the Goal active and returns to Source/Contract repair. A clean review does not add acceptance proof and never lets Agent judgment replace Final Gate.
+
+## Handoff
+
+Report implementation, effective risk, Architecture Deliberation/Conformance status, Claim Coverage, Stage frontier/results, declared target profile, exact `target_state`, Live Gate result, acceptance scope, every pending external confirmation, Context status and blockers. Use verifier terms exactly: `progress_passing` means targeted repair evidence, `progress_stale` is a freshness fact rather than a current pass or immediate rerun command, `final_workflow_status: null` means unfinished, `authority_revision_adopted` means return to rolling execution, and `machine_accepted_external_pending` must retain its named confirmations. Contract target states are only `implementation_complete`, `target_profile_usable` and `production_release_ready`; terminal failure uses `not_accepted` or `blocked_external`. Never shorten targeted progress to “Outcome complete” or invent per-platform progress/status. State the threat-model limits: the visible checkpoint cannot prove private reasoning or universal future-proofing, undeclared requirements cannot be discovered, installed verifier/Git metadata are trusted, native-Goal/model selection belongs to the host/user, and internal platform delegation is not observed.

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

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Long-Task Workflow"
-  short_description: "Run one Delivery Contract in the current native Goal"
-  default_prompt: "Use /long-task-workflow to prepare, execute, resume, verify, or close one Canonical Delivery Contract in the current workspace."
+interface:
+  display_name: "Long-Task Workflow"
+  short_description: "Run one Delivery Contract in the current native Goal"
+  default_prompt: "Use /long-task-workflow to prepare, execute, resume, verify, or close one Canonical Delivery Contract in the current workspace."