create-agdf 0.14.5 → 0.20.0

package/generated/.opencode/contracts/prd-definition.md

@@ -0,0 +1,130 @@
+# AGDF Runtime Contract — PRD Definition
+
+Use only a bound `skill_continuation` with `phase: prd_definition`. This contract owns semantic
+product drafting and clarification; it creates no gate, writer, persistence or approval authority.
+
+## Binding and sources
+
+Dispatch prd-definition before direct work. An unbound invocation uses the existing
+resolve_delivery_run candidate inventory, matching the original request to approved UR scope,
+then gate-check resume intake with run_id and expected_revision_id. Never select AGDF_RUN_ID,
+invent a replacement run/UR or use discovery, skill selection or cwd as editing intent.
+
+Use the returned governance_target, run_id, revision_id, contained artifact_path, absolute
+plugin-owned template_path and exact sources. The installed, version-matched plugin is the sole
+authoring-template authority. Repository `.agdf/control/templates/` copies are derived scaffold
+references and never override template_path. If template_path is unavailable or unsafe, stop
+without writing or falling back and route the explicit plugin repair/reinstall recovery.
+Read the approved UR, completed Brownfield Review/Mode-Slice result and required ready UX Intent
+Definition, original request and confirmed answers. Invalid/stale/foreign/approved bindings,
+missing prerequisites, source proof or integrity blockers require fresh canonical control.
+The approved UR is the primary derivation source; analyses are subordinate inputs.
+
+## Draft the product
+
+Use the existing PRD format, not a new template store: draft/open metadata with named Owner and
+`Traceability contract: criteria-chain-v1`; Product Scope; UX Intent And Success; Working Modes And
+Effective State; Activation, Blockers, Recovery And Transitions; Acceptance Criteria; Non-Goals;
+Users And Roles; Constraints; Evidence Requirements; Risks And Open Questions; Approval Decisions;
+Next Step. Populate relevant fields concretely or justify not_applicable. Product authority and
+visible presentation owner are distinct; technical storage/architecture/task choices belong later.
+
+Derive supported scope, roles, constraints and observable acceptance from the approved need and
+confirmed context. Preserve non-goals and unique stable criterion_id values; never invent users,
+product promises, approval, new scope or later design. Each applicable UX criterion names working
+mode, source state, action, expected effective state, visible feedback, blocker/failure behavior,
+recovery/next action, observable success and required evidence. Structural completeness is not
+semantic proof: retain the concrete inputs/draft and reasoned derivation for later review.
+
+## Clarify product decisions
+
+Keep one Approval Decisions table: Decision | Timing | Status | Resolution | Owner. A product,
+acceptance, accountable-owner or release-acceptance question belongs to before_prd. If material
+information is missing, preserve a useful draft with that row open and ask one bundled question.
+Do not manufacture an answer or report readiness. Retain answered context; sufficient inputs need
+no redundant question, and Run IDs are not product questions. Genuine later_sd/later_tp questions
+remain owner-bound deferrals, never hidden product decisions. Conflicting approved UR intent routes
+to its existing revision owner before a changed product draft can be presented.
+
+When a visible flow or decision remains hard to assess in prose, use a focused UI preview or scenario
+walkthrough following `ux-intent-definition`'s UI preview guidance. Reuse existing UX findings rather
+than creating a parallel specification or requiring another preview. Carry the scenario, observed
+feedback and qualification limits into the existing UX Intent And Success and Evidence Requirements
+sections; translate adopted behavior into stable acceptance criterion IDs. Record material product
+choices in the same Approval Decisions table, preserving unresolved `before_prd` rows. A positive
+reaction to a mockup resolves only the product questions actually answered; it is not `Approval: PRD`.
+For an optional aid, an unavailable visualization capability alone is not a readiness blocker when
+semantics can be clarified otherwise. Preserve an explicitly required preview from approved UR scope:
+read the UX report's exact run-local preview version, relative path, digests and observation limits.
+Confirm that the referenced durable copy exists and matches before relying on its findings; a
+chat-only preview, stale version or missing requested interaction leaves the obligation open.
+Use the existing UX analytical recovery route for missing required preview evidence; do not invent
+a product answer, repeat UR intake or bypass the required UX result. If PRD clarification creates or
+changes a preview, apply the UX skill's same retention and versioning rules. Keep material choices
+open until actually answered. Scope changes return to the earliest affected owner. Preview fidelity
+does not prescribe SD choices or prove working implementation.
+
+Gate-check alone evaluates readiness. Permission to finish clarification under
+AGDF_PRD_DECISIONS_OPEN does not remove the blocker or permit approval. Missing required UX input
+and unrelated integrity/source blockers are not PRD clarification permission. Use the interaction
+contract Bounded internal recovery route for eligible UX preparation; do not author PRD first.
+
+## Prepare the preview review handoff
+
+For a required UI preview, put a concise review task and versioned preview access in UX Intent And
+Success, relate the scenarios to stable criterion IDs, and retain the observations and limitations
+in Evidence Requirements. Keep material answers in Approval Decisions. Explain that PRD approval
+adopts the specified behavior and criteria; implementation, visual-design acceptance and delivery
+evidence require their own applicable sources. Do not label a proposed flow as already delivered.
+Follow interaction.md PRD Preview Review At Approval for the single canonical presentation owner,
+viewing/approval distinction, host availability and required revalidation. Prepare source material;
+never hand-build an extra approval card or claim missing runtime integration is implemented.
+
+The PRD owns exactly one `## Preview Review` section containing only one fenced `json` object.
+Use `schema_version: "1"`, a short lowercase `version` ending in `-vN`, the canonical approved
+`source_ur_digest`, and `entry: ".agdf/control/artefacts/<run_id>/previews/<version>/index.html"`.
+Provide `files` sorted by path, each with `path`, raw-byte SHA-256 `digest`, exact `bytes` and
+`media_type`; also provide `review_task`, nonempty `scenarios`, valid PRD `criterion_ids`, and
+`open_questions` (an array, possibly empty). No other keys or separate manifest are accepted.
+The whole descriptor is at most 16 KiB; at most 32 files, 128 KiB each and 1 MiB combined.
+Supported media are text/html, text/css, text/javascript and PNG/JPEG/WebP/GIF/SVG images.
+Keep classic scripts, styles, CSS imports and images local and declared; no network, modules,
+forms, embedded frames or host calls. Unsupported resource syntax fails explicitly. Bundle or
+simplify the example within the existing unapproved source owner; never substitute a blank view.
+The prepared PRD presentation snapshots exact source files and the isolated rendered view. It
+offers versioned access beside the document; opening it is not approval or proof of human review.
+A changed or unavailable required file requires repair/revision and a fresh presentation before
+an approval reply. Existing unmarked URs need no descriptor; an authored descriptor always binds.
+
+## Explicit revision and recording
+
+Before recording, use the continuation's resolved language and summary fields with
+gate-artifact-preparation's Language and approval summary preparation. A translated summary
+must be part of the draft before presentation, not deferred until a renderer failure.
+Use the shared canonical summary validator and separate recognized goal, scope and decisions
+labels. A required malformed summary is an unready authoring input, not a missing user choice.
+On an eligible own unapproved formatting diagnosis, correct once, validate and replace through
+the same typed writer, then reevaluate without a restart question. An unchanged failure stops;
+this does not permit editing a ready or approved draft without its existing authority.
+
+For a registered ready unapproved draft, require an actual human drafting/revision request;
+loading or selecting this skill is insufficient. The shared explicit route is gate-check with
+intake true, intake_mode resume, run_id, expected_revision_id and prd_action revise
+(CLI --prd-action revise). Ordinary ready-draft continuation presents the existing result.
+Never edit an approved PRD or transfer its approval. An approved-intent change uses the existing
+earliest affected UR/PRD revision route, not this unapproved authoring assignment.
+
+Use the shared Reviewed Recording Input in gate-artifact-preparation and existing
+run-step --step artefact --gate PRD --evidence <recording-input.json> with the supplied current
+run/revision. Record PRD derived_from the exact approved UR; analyses do not replace that source.
+Initial registration uses update_draft false; explicit registered replacement uses true with
+fresh reviewed mapping and recording paths. Retain previous proof/history and other protected
+bytes. Never hand-author receipts, substitute run-update for required source binding or reseal
+unknown edits. Follow existing transaction recovery and supported visible retry with fresh state.
+
+Use the returned revision and redispatch gate-check. When supplied, prepare exact run-present,
+show its returned text verbatim and wait for a NEW deliberate Approval: PRD. A different artifact
+language needs the existing localized summary: goal, scope, every criterion ID once and decision
+context, within unchanged limits. Editorial correction uses permitted canonical replacement and
+a fresh presentation; an old reply cannot approve changed content. Only valid PRD approval permits
+the existing SD stage. This skill creates no SD, TP, implementation, QA or release result.

package/generated/.opencode/contracts/quality.md

@@ -2,15 +2,20 @@
 
 ## Quality Readiness Projection
 
+When `qa-gate` authors or refines `QA_REPORT.md`, it uses only the bound absolute plugin-owned
+`template_path`. Repository scaffold copies are derived review references, not an authoring source.
+An unavailable or unsafe template blocks QA report authoring without mutation or success-shaped
+fallback; it does not turn missing evidence into a QA decision.
+
 After CD+Tests, when any of the four review/QA artefacts exists, surfaces may show one compact
 derived `Quality Readiness` projection. It answers the user-facing question "what is the current
 quality outcome and what should happen next?" without replacing evidence or creating another
 decision authority.
 
-- It contains exactly four rows, in this order: `Plan coverage` from `agdf-task-plan-review`,
-  `Solution integrity` from `agdf-clean-implementation-review`, `Code quality` from `agdf-code-review`,
-  and `QA decision` from `agdf-qa-gate`.
-- `agdf-qa-gate` is always labeled as the sole decision owner. The other three rows are evidence
+- It contains exactly four rows, in this order: `Plan coverage` from `task-plan-review`,
+  `Solution integrity` from `clean-implementation-review`, `Code quality` from `code-review`,
+  and `QA decision` from `qa-gate`.
+- `qa-gate` is always labeled as the sole decision owner. The other three rows are evidence
   dimensions, not competing pass/revise/block decisions.
 - Overall status reuses canonical severity ordering. Missing or conflicting required evidence
   must not render `pass`; surface `revise` or `block` with the decisive reason and one permitted
@@ -38,7 +43,8 @@ For larger or more formal work, create or update the durable artefacts fully, th
 ### Chat and Tool-Call Discipline
 
 Chat output shows decisions and outcomes. Files show evidence and detail. The agent
-minimises both the number of tool calls and the amount of accompanying chat text. This
+uses the sole Routine Continuation And Visible Events policy in interaction.md; every required
+checkpoint and review still executes. It minimises tool calls and accompanying chat text. This
 is surface-agnostic: it changes agent behaviour and framework text, not host rendering.
 Whether a host renders a tool-call block visibly is a host concern; the framework ensures
 the agent makes fewer calls and produces less text around them.
@@ -55,7 +61,7 @@ Tool-call batching:
 
 - `RUN_STATE.md` is written once per user gate approval, not once per field change. The
   agent keeps intermediate state in memory between gate approvals and writes the complete
-  updated state in one operation.
+  updated state in one operation, then records it with `run-update` before the next `gate-check`.
 - The agent does not `read` existing artefacts for format reference. Skill instructions
   carry the format/structure inline. If a specific existing artefact must be inspected
   for content (not format), the read has no accompanying commentary.
@@ -74,6 +80,40 @@ Always visible:
 
 ## Quality Contract Output
 
+Current structured QA preparation requires concrete authored fields in the first scalar block
+of existing QA sections: `delivered_result` under TP Coverage, `qualification_limits` under
+Missing Evidence and `delivery_risks` under Risks (canonical numbered headings supported).
+Only limits/risks permit explicit `none`. Initial Run drafts stay authorable; current decisions
+require concrete orienting Objective. The shared bounded context observer excludes examples,
+quotes/code/HTML and whole template values; diagnosis and preparation never repair sources.
+UAT derives Goal from approved UR, actual result/limits from current QA, original QA/accepted
+deviation disposition and the existing approval effect. It stores no second result authority.
+When source and display languages differ, existing source-authored Approval Summary uses
+Goal/Ziel and Delivered result/Ergebnis, Qualification limits/Grenzen, Risks/Risiken. Complete
+current fields before new QA approval; missing approved legacy content stays protected and
+needs its existing renewal assessment, never silent backfill. Historical accepted documents
+and completed Runs retain original proof. No content check grants approval or proves truth.
+
+Core reads reported technical results through one shared observer. `Decision`/`decision` and
+technical `Status` declarations may repeat the same supported result; `passed` normalizes to
+`pass`. Lifecycle metadata such as `Status: draft` or `Status: done` is not a QA result.
+Only initial result metadata (optionally after the report H1) and the first scalar field block
+under a column-zero H2 `Decision` or `QA Decision` heading are authored result contexts. Numeric
+section prefixes and closing heading hashes are supported; canonical `## 1. QA Decision` remains
+valid. Prose, unrelated/nested headings and non-metadata fields close the field block; a blank
+line never reopens it. Metadata names are the existing Decision, Status, Gate, Gate approval,
+Based on, Date, Owner, Type, Mode, Reviewer, reviewed_at, run_id, source_revision and Traceability
+contract. Fenced/indented code, lists, blockquotes (including lazy continuations), HTML containers,
+comments and raw blocks never supply results or conflicts. Only a clearly terminated container
+allows a following genuine decision section; uncertain/unclosed markup keeps its remainder excluded.
+This is a conservative bounded report grammar, not general Markdown parsing or prose-intent inference.
+Bound Quick review and non-UX internal registration reuse the observer. Only the internal analysis
+domain opts into `not_applicable`; its existing eligibility/reason checks remain authoritative.
+Conflicting supported values, an unknown or empty explicit Decision, or a missing supported
+result remain unconfirmed. This observes authored evidence only: it grants no QA decision,
+approval, source replacement or closeout permission. Exact approved bytes and current bindings
+remain separately enforced.
+
 Structured Delivery skills use this shape when relevant:
 
 - `decision`: `pass | revise | block | not_applicable`
@@ -107,25 +147,56 @@ Normalized finding rows use these fields in order:
 - `gap_type` is exactly one type from the table above.
 - `routing_target` is exactly `UR | PRD | SD | TP | CD+Tests | evidence_obligation` and must agree
   with the fixed route above. `requirements_gap` may use `UR` only with evidence of changed user
-  intent or scope. `emergent_risk` requires an explicit earliest-owner assessment.
+  intent or scope. An open `emergent_risk` requires an explicit earliest-owner assessment
+  before routing corrective work; a resolved row retains its original route and resolution evidence.
 - `gap_status` is exactly `open | resolved`.
 - `evidence` names concrete source, diff, test, observation or missing proof.
-- `required_next_step` is exactly one executable action consistent with the routing target.
+- `required_next_step` for an open finding is exactly one executable action consistent with
+  the routing target. A resolved finding may state `none`, explain that no further corrective
+  action remains, or name its subsequent review/lifecycle step. Its evidence must remain concrete;
+  resolution never makes a missing field, invalid type/route or placeholder evidence valid.
 
 Missing, unknown or contradictory fields fail closed as an open gap. Consumers must not silently
 reclassify a finding. Classification is non-authorizing: it cannot edit or approve UR, PRD, SD or TP,
-advance a gate or replace a review decision. `agdf-qa-gate` consumes the normalized findings and cannot
+advance a gate or replace a review decision. `qa-gate` consumes the normalized findings and cannot
 return `pass` while any applicable finding is open or invalid.
 
-`none` is permitted only as a presentation sentinel on a fulfilled UX Intent Fidelity row.
-It is not a seventh normalized finding type and must not appear in a normalized finding row.
+`none` is not a seventh normalized finding type. It is permitted as a presentation sentinel on a
+fulfilled UX Intent Fidelity row and as `required_next_step` on a resolved finding, never as
+`gap_type`, `routing_target` or resolution evidence. Open findings still require executable action.
+
+Current QA/UAT decision preparation and prepared closeout use the same normalized-finding
+observer. A technical pass cannot present a human approval while a registered review contains
+an open or invalid finding. Historical approved reports are observed without rewriting their
+bytes, decisions or receipts; a resolved finding does not require a new repair or a new approval.
 
 A consumer may repeat the field order and allowed scalar values needed to emit valid output. It must
 reference this section for meanings and routes instead of maintaining a second complete mapping.
 
+## Human QA Acceptance With Deviations
+
+The technical QA decision remains exactly `pass | revise | block`. An explicit human acceptance
+of deviations is a separate disposition; it never changes `revise` to `pass`, resolves a finding,
+marks a missing test passed, or grants native production qualification.
+
+The existing unapproved QA report may contain one `QA Deviation Acceptance` JSON section,
+specified in `docs/qa-deviation-acceptance.md`. Core evaluates it through the normalized finding
+owner above. Only complete, current low/medium evidence-only findings may be proposed; every
+open finding must be covered exactly. Upstream or implementation gaps, malformed/conflicting
+findings, `block`, non-passing protected Code/Clean reviews, stale associations and hard Run
+blockers prevent this route. Existing required obligations are not silently waived.
+
+Before requesting a decision, show the bounded usage scope and each finding's risk, consequence,
+follow-up and owner. The sole contextual action is `Approve with deviations` (German:
+`Mit Abweichungen freigeben`); Chat uses the existing exact `Approval: QA` against that newly
+presented version. A previously rejected response is never transferred. The existing approval
+transaction, receipt and exact-material owner record one effect for both routes. UAT follows
+only after that deliberate acceptance; the original report and open findings remain intact.
+UAT and OR must carry the accepted deviations forward explicitly.
+
 ## UX Intent Fidelity
 
-When an approved PRD contains applicable UX criteria, `agdf-task-plan-review` produces an additional
+When an approved PRD contains applicable UX criteria, `task-plan-review` produces an additional
 evidence matrix with these columns in order:
 
 `prd_criterion | working_mode_state | task_id | visible_evidence | fidelity_status | gap_type`
@@ -136,10 +207,10 @@ Review Gaps`; it may also emit the normalized finding shape when routing detail
 
 This matrix verifies PRD-to-TP coverage and TP-to-code/surface fulfilment. It does not create product
 requirements and does not decide QA. A missing implementation-relevant PRD requirement is a
-`requirements_gap` and routes to PRD revision. `agdf-qa-gate` consumes this evidence and cannot return
+`requirements_gap` and routes to PRD revision. `qa-gate` consumes this evidence and cannot return
 `pass` while an applicable row is `partial`, `missing` or `not_verifiable`, or while a visible-behavior
 claim has code evidence without visible evidence. The four-row Quality Readiness projection and
-`agdf-qa-gate` sole decision ownership remain unchanged.
+`qa-gate` sole decision ownership remain unchanged.
 
 A skill may briefly remind this shape, but must not duplicate a complete code or rule matrix.
 

package/generated/.opencode/contracts/request-activation.md

@@ -0,0 +1,252 @@
+# AGDF Runtime Contract — Request Activation
+
+## Purpose And Authority
+
+Request Activation decides whether the current user request may enter an AGDF operation. It runs
+before task-target resolution, repository activation, control inspection, run or gate selection,
+dispatcher v1, AGDF presentation, and mutation.
+
+This contract is the sole semantic owner for request applicability, requested-effect precedence,
+invocation provenance, selection origin, the bounded operation catalog, and silent abstention. It
+does not resolve a target, inspect a repository, validate control, select a run, evaluate a gate,
+render AGDF output, or authorize work.
+
+The decision is request-scoped and transient:
+
+- no raw prompt or derived request classification is written to disk, logs, control state, or a new
+  telemetry field;
+- no network request, remote classifier, repository read, tool call, or dispatcher call is needed
+  to make the semantic decision;
+- passive SessionStart context, installed-plugin presence, cwd, repository presence, durable control,
+  a prior unrelated run, router selection, and automatic skill discovery are not activation evidence;
+- exact approval, target, run, gate, lifecycle, status, and presentation authority remains with the
+  existing downstream owners after positive applicability.
+
+## Transient Decision
+
+```text
+policy_version: 1
+requested_effect:
+  read_only_assistance
+  | governed_delivery
+  | binding_delivery_artefact
+  | named_agdf_operation
+  | control_lifecycle
+  | continuation_action
+  | ambiguous
+request_class:
+  ordinary_read_only
+  | delivery_intent
+  | explicit_agdf_operation
+  | explicit_control_lifecycle
+  | active_run_continuation
+  | ambiguous_effect
+decision:
+  abstain
+  | clarify
+  | activate_named_operation
+  | activate_delivery_intake
+  | activate_continuation
+invocation_provenance:
+  current_user_text
+  | trusted_ephemeral_user_action
+  | unavailable
+selection_origin:
+  explicit_user_action
+  | automatic_discovery
+  | router_selection
+  | unavailable
+operation_id: optional identifier from the bounded operation catalog
+authorizes: false
+persist: false
+```
+
+| Request class | Requested effect | Decision |
+|---|---|---|
+| `ordinary_read_only` | Assessment, explanation, comparison, recommendation, review, diagnosis, hypothetical or advisory implementation discussion, or AGDF discussed only as a subject. | `abstain` |
+| `delivery_intent` | An actual governed change, fix, refactor, implementation, or other delivery effect is requested. | `activate_delivery_intake` |
+| `delivery_intent` | A binding gate-relevant delivery artefact is requested. An example, template, recommendation, or advisory draft is not binding. | `activate_delivery_intake` |
+| `explicit_agdf_operation` | The current request expressly invokes AGDF, a supported skill, or a named AGDF help, suitability, status, run, gate, audit, approval, quality, or closeout operation. Merely naming AGDF as the subject of a question is not invocation. | `activate_named_operation` |
+| `explicit_control_lifecycle` | The current request expressly asks to initialize or validate durable `.agdf/control`, inspect its lifecycle or validity, or perform supported target-bound repository activation or disablement. | `activate_named_operation` |
+| `active_run_continuation` | The request asks to perform the immediately pending action for an active run, supplies its exact pending approval, or unambiguously answers that pending action. Merely asking about the run or gate is named read-only inspection, not continuation. | `activate_continuation` |
+| `ambiguous_effect` | The requested effect cannot be determined reliably and no explicit mutation or binding delivery output is established. | `abstain` when useful read-only assistance is possible; otherwise `clarify` |
+
+Determine the requested effect, not the presence of delivery-related words. Quoted, negated,
+hypothetical, example, error-message, and code-block text does not become a current delivery request.
+When a mixed request actually asks for both assessment and a delivery effect, delivery intent wins.
+When no actual delivery effect is requested, ambiguity stays read-only and never activates AGDF by
+default.
+
+Apply precedence in this order:
+
+1. An explicit request for a supported AGDF or control-lifecycle operation activates exactly that
+   named operation. AGDF discussed only as a subject does not.
+2. An actual requested mutation or binding delivery outcome activates delivery even when assessment,
+   explanation, or recommendation is also requested.
+3. An explicit constraint such as `do not implement` or `only assess` keeps the constrained work
+   read-only unless another actual delivery effect remains.
+4. Delivery language inside quotations, examples, code, errors, negations, or hypothetical advice is
+   context only.
+5. Active-run continuation requires current-turn action intent or an immediately bound action
+   response. A read-only question about a run or gate is a named inspection operation, not
+   continuation, and an unrelated later request inherits no activation.
+6. Without reliable positive evidence, choose ordinary read-only handling or ambiguous effect. Never
+   default to activation.
+
+## Invocation Provenance And Selection Origin
+
+`requested_effect`, `invocation_provenance`, and `selection_origin` are independent values.
+
+- Current-turn text that explicitly requests AGDF or a supported operation is sufficient provenance.
+- A host signal is accepted only when it is trusted, ephemeral, bound to the current deliberate user
+  action, and grants no approval or target authority.
+- Automatic discovery, router selection, skill loading, and passive hook output are selection origin,
+  never invocation provenance.
+- When invocation provenance is unavailable, the requested effect remains decisive. Selection origin
+  alone never activates AGDF.
+
+## Operation Catalog
+
+The following JSON block is the complete logical operation catalog. It maps an already determined
+positive request class to one existing route owner; it is not a natural-language classifier. Entries
+whose `owner_kind` is `command` must resolve through the existing `commandRegistry`. The
+`delivery.start` skill owner and every derived direct-skill ID must resolve through
+`pluginDefinition.skillSet`. Function owners remain downstream implementation owners and do not
+grant applicability or authority.
+
+<!-- AGDF-REQUEST-ACTIVATION-OPERATIONS:START -->
+```json
+{
+  "schema_version": 1,
+  "operations": [
+    { "operation_id": "assist.agdf_help", "route_family": "control_independent_help", "target_boundary": "explicit_optional", "control_boundary": "no_probe", "owner_kind": "contract", "owner": "request_activation_contract" },
+    { "operation_id": "assist.agdf_suitability", "route_family": "control_independent_help", "target_boundary": "explicit_optional", "control_boundary": "no_probe", "owner_kind": "contract", "owner": "request_activation_contract" },
+    { "operation_id": "delivery.start", "route_family": "governed_delivery_intake", "target_boundary": "required_after_activation", "control_boundary": "presence_then_dispatcher_revalidation", "owner_kind": "skill", "owner": "gate-check" },
+    { "operation_id": "lifecycle.control.init", "route_family": "repository_control_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "absence_allowed", "owner_kind": "command", "owner": "init" },
+    { "operation_id": "lifecycle.repository.activate.codex", "route_family": "repository_surface_lifecycle", "target_boundary": "explicit_required", "control_boundary": "no_delivery_invention", "owner_kind": "command", "owner": "codex-repo" },
+    { "operation_id": "lifecycle.repository.activate.opencode", "route_family": "repository_surface_lifecycle", "target_boundary": "explicit_required", "control_boundary": "no_delivery_invention", "owner_kind": "command", "owner": "opencode-repo" },
+    { "operation_id": "lifecycle.repository.disable", "route_family": "repository_surface_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "existing_owner", "owner_kind": "command", "owner": "disable" },
+    { "operation_id": "lifecycle.plugin.install.codex", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "codex" },
+    { "operation_id": "lifecycle.plugin.install.claude", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "claude" },
+    { "operation_id": "lifecycle.plugin.install.copilot", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "copilot" },
+    { "operation_id": "lifecycle.plugin.install.opencode", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "opencode" },
+    { "operation_id": "lifecycle.plugin.uninstall", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "uninstall" },
+    { "operation_id": "status.installation.codex", "route_family": "global_installation_status", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "function", "owner": "inspectGlobalInstallationStatus" },
+    { "operation_id": "status.installation.claude", "route_family": "global_installation_status", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "function", "owner": "inspectGlobalInstallationStatus" },
+    { "operation_id": "status.installation.copilot", "route_family": "global_installation_status", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "function", "owner": "inspectGlobalInstallationStatus" },
+    { "operation_id": "status.installation.opencode", "route_family": "global_installation_status", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "function", "owner": "inspectGlobalInstallationStatus" },
+    { "operation_id": "status.overview", "route_family": "status_overview", "target_boundary": "explicit_or_reliably_resolved_optional", "control_boundary": "repository_component_only_after_target", "owner_kind": "function", "owner": "evaluateStatusOverview" },
+    { "operation_id": "status.repository_delivery", "route_family": "repository_status", "target_boundary": "explicit_required", "control_boundary": "absence_is_result", "owner_kind": "function", "owner": "evaluateGeneralStatus" },
+    { "operation_id": "status.opencode_repository", "route_family": "repository_status", "target_boundary": "explicit_required", "control_boundary": "absence_is_result", "owner_kind": "function", "owner": "evaluateOpenCodeStatus.repository" },
+    { "operation_id": "runtime.checks", "route_family": "global_runtime_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "runtime-checks" },
+    { "operation_id": "control.doctor", "route_family": "deterministic_control_inspection", "target_boundary": "required_after_activation", "control_boundary": "missing_is_result", "owner_kind": "command", "owner": "doctor" },
+    { "operation_id": "control.delivery_map", "route_family": "deterministic_control_inspection", "target_boundary": "required_after_activation", "control_boundary": "missing_is_result", "owner_kind": "command", "owner": "delivery-map" },
+    { "operation_id": "run.create", "route_family": "run_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "command_preconditions", "owner_kind": "command", "owner": "run-create" },
+    { "operation_id": "run.migrate", "route_family": "run_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "command_preconditions", "owner_kind": "command", "owner": "run-migrate" },
+    { "operation_id": "run.render_legacy", "route_family": "run_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "command_preconditions", "owner_kind": "command", "owner": "run-render-legacy" },
+    { "operation_id": "continuation.current", "route_family": "active_run_continuation", "target_boundary": "required_after_activation", "control_boundary": "target_run_gate_revalidation", "owner_kind": "function", "owner": "existingTargetRunGateRevalidators" }
+  ],
+  "derived_operations": [
+    { "operation_id_pattern": "skill.<slug>", "route_family": "direct_skill", "derive_from": "pluginDefinition.skillSet", "target_boundary": "dispatcher_v1", "control_boundary": "dispatcher_v1", "owner_kind": "dispatcher", "owner": "skill-dispatch-v1" }
+  ]
+}
+```
+<!-- AGDF-REQUEST-ACTIVATION-OPERATIONS:END -->
+
+Route boundaries:
+
+- `assist.*`, global plugin lifecycle, global runtime checks, and global installation status never
+  invent a repository target or probe repository control.
+- `status.overview` always returns its targetless global component. It adds repository or delivery
+  status only after explicit or reliably resolved target evidence; cwd is never implicit authority.
+- Repository lifecycle, repository status, Doctor, Delivery Map, and run lifecycle resolve a target
+  only after positive applicability and then call only their declared owner.
+- `skill.<slug>` invokes dispatcher v1 as the first operational call. There is no preceding target,
+  repository, control, run, gate, or renderer call.
+- `delivery.start` may resolve target and inspect structural control presence for draft/setup only.
+  Candidate control is not actionable evidence; dispatcher v1 revalidates target and control before
+  any gate result.
+- Active-run continuation establishes applicability from action intent, then revalidates target, run,
+  gate, revision, and exact approval through existing owners.
+
+Missing control is route-specific. Help and suitability answer normally; status reports unavailable
+control or run state; gate-dependent operations block on missing evidence; explicit lifecycle setup
+uses its existing recovery; continuation requests restoration or selection of the referenced run;
+delivery intake drafts and persists a real UR before any approval presentation. No missing-control
+route synthesizes an immediate `Approval: UR` merely because a control file is absent.
+
+## Active Run Inventory
+
+"Zeige die aktiven AGDF-Runs in diesem Projekt" / "Show the active AGDF runs in this project"
+selects `control.doctor`, even with gate-check loaded. For "this project", bind its verified chat
+repository root as `primary_target`, `target_source: current_repository`; cwd alone is not authority.
+Ambiguous or unavailable projects use existing target clarification.
+Call `agdf_inspect` with `operation: doctor`, `all_active: true`, `presentation_language` and actual
+`working_directory`; fallback: surface-local `doctor --dir <verified-root> --all-active --json`.
+Omit run selection, intake and continuation. Show every returned run plus integrity findings.
+Distinguish empty, absent control, incomplete inventory and failure; partial counts are not totals.
+Listing never repairs, initializes or requests approval.
+
+## Request Applicability Guard
+
+The block below is the only compact guard source. It is projected byte-for-byte into the canonical
+router and every canonical skill before any operational boundary. Generated surfaces may transform
+only host-specific skill names and resource paths outside this block.
+
+The `guard_fingerprint` is SHA-256 over the complete marker-bounded block after replacing its own
+hex value with `<computed>` and normalizing line endings to LF. The projection tool owns that derived
+field and every copied marker region; missing, partial, duplicate, reordered, or manually edited
+regions fail check mode.
+
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:START -->
+## Request Activation
+
+- `owner`: `request_activation_contract`
+- `path`: `meta/contracts/request-activation.md`
+- `policy_version`: `1`
+- `guard_fingerprint`: `sha256:af2f01f9e18a3ba1c520faf0691aa1cd4a4299bdfa027cf83651c5d14319bfdc`
+
+Decide effect from loaded instructions before AGDF action.
+
+Abstain silently (no AGDF call) for assessment/explanation/comparison/recommendation/review/diagnosis/advice; hypothetical/example/error/code/quoted/negated delivery language; AGDF as subject; or a read-only constraint absent other delivery. Ambiguity is read-only: answer or ask one neutral question.
+
+Activate for any requested file/code change however small, a binding gate artefact, explicit AGDF/control-lifecycle operation or unambiguous active-run action; delivery wins mixed intent.
+
+Invocation proof: explicit user text/trusted ephemeral action, not discovery/selection, skill load, hooks, cwd, repo/control or prior runs.
+
+Then pick one catalog route; non-authorizing, downstream checks remain.
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:END -->
+
+## Discovery Description Suffix
+
+The single sentence below is appended to every skill frontmatter description after the
+definition-owned `useFor` and `boundary` values.
+
+<!-- AGDF-REQUEST-ACTIVATION-DISCOVERY-SUFFIX:START -->
+The requested effect, not discovery, decides AGDF activation.
+<!-- AGDF-REQUEST-ACTIVATION-DISCOVERY-SUFFIX:END -->
+
+## Failure Semantics
+
+- `abstain` and `clarify` cause zero request-driven calls to dispatcher v1, target resolution,
+  repository activation, control presence, run selection, control evaluation, AGDF rendering,
+  lifecycle, status, or mutation owners.
+- A partial, missing, duplicate, stale, or fingerprint-mismatched guard fails generation and Runtime
+  Integrity. It never falls back to the previous broad trigger.
+- A missing or unknown operation ID stops at routing. It is not reinterpreted as `delivery.start` or
+  generic `gate-check`.
+- No hook, generated profile, test fixture, installed runtime, keyword list, or host-specific prompt
+  becomes another request-applicability owner.
+
+
+### Delivery intent transport
+
+A delivery request without a confirmed run binding first dispatches gate-check with intake true
+and no run_id. Its resolve_delivery_run continuation supplies canonical UR scope evidence for the
+coding agent's assignment. One unequivocal same-scope continuation uses resume, its run_id and
+expected_revision_id; a clear independent scope uses new and an unused run_id even when unrelated
+runs exist. Single-run count, recency, shared files and ambient AGDF_RUN_ID prove no scope match.
+Overlapping plausible scopes require one question about the work, not a technical Run-ID choice.
+Incomplete inventory is a technical failure, never evidence for a new scope. Read-only requests omit intake and
+continue_delivery. On a bound run, continue_delivery requests the next canonical internal
+continuation listed in the interaction contract without another user prompt; it approves no gate.

package/generated/.opencode/contracts/sd-definition.md

@@ -0,0 +1,69 @@
+# AGDF Runtime Contract — SD Definition
+
+Use only a bound skill_continuation with phase sd_definition. This contract owns semantic
+design drafting and clarification; it adds no gate, writer, persistence or approval authority.
+
+## Binding and sources
+
+Dispatch before direct work. Unbound invocation uses the existing resolve_delivery_run inventory,
+matching original need to approved scope, then revision-bound gate-check resume intake. Never
+select AGDF_RUN_ID, invent a run, infer editing intent from discovery/selection or use cwd as
+authority. Use only returned governance_target, run_id, revision_id, artifact_path, absolute
+plugin-owned template_path and sources. The installed, version-matched plugin is the sole
+authoring-template authority; repository scaffold copies never override it. Missing or unsafe
+template_path blocks authoring without mutation or fallback and requires explicit plugin repair.
+Read the exact approved PRD, resolved product decisions, completed Brownfield routing and required
+ready analytical inputs. PRD is product authority; analyses are subordinate. Missing/stale/foreign/
+approved bindings or unrelated prerequisite/integrity/source blockers require fresh control.
+
+## Draft and clarify
+
+Use the existing SD format and one canonical unapproved design: draft/open metadata, named Owner,
+Solution Overview, Ownership And Source Of Truth, Architecture Decisions, Integration Points,
+Constraints And Compatibility, Test And Evidence Strategy, Acceptance Traceability, Risks And
+Open Questions, Design Decisions, Next Step. Retain criteria-chain-v1. Explain architecture,
+boundaries, flows, reuse, alternatives, rationale and trade-offs at proportionate depth. Map every
+PRD criterion exactly once to realization, authoritative owner, stable SDD IDs or reasoned none
+and compatibility/risk. Never duplicate acceptance, invent scope/users or claim implementation.
+Retain actual sources/draft and a reasoned derivation review; structure alone is not semantic proof.
+
+Always declare Design Decisions contract: sd-decisions-v1 and exactly one Design Decisions table:
+Decision | Timing | Status | Resolution | Owner. Unique decisions use before_sd or later_tp,
+status resolved/open/deferred, named owner and concrete resolution or deferral reason. Material
+architecture/design choices belong before_sd and must be resolved before presentation. later_tp
+may defer execution/test/evidence detail only; never hide binding architecture or product intent.
+With no material unknown, record a concrete resolved applicability decision, not an empty table.
+Legacy unmarked designs retain existing checks; this never permits removing a new draft's
+declaration/table to conceal questions. Declared readiness does not prove all questions were found.
+
+Missing material facts: preserve a useful draft and before_sd open row, retain answered context
+and ask one focused bundled question. Sufficient inputs need no redundant question. Record confirmed
+answers and updated design through the checked writer, then re-evaluate. Specific decision or
+traceability correction permission never removes its blocker or unrelated source/integrity checks.
+A product-scope/acceptance conflict stays unresolved and returns to the earliest affected existing
+UR/PRD revision owner. Do not edit approved sources, invent a transition after downstream linking
+or manufacture answers; use supported revision/recovery and fresh source approval where required.
+
+## Explicit revision and recording
+
+Before recording, use the continuation's resolved language and summary fields with
+gate-artifact-preparation's Language and approval summary preparation. A translated summary
+must be part of the draft before presentation, not deferred until a renderer failure.
+
+A ready registered draft requires actual human editing intent; skill loading/selection is not
+permission. Ordinary continuation presents its current result. Explicit canonical revision uses
+gate-check intake true, intake_mode resume, run_id, expected_revision_id and sd_action revise
+(CLI --sd-action revise), exclusive of UR/PRD actions and continue_delivery. Never edit an
+approved design or transfer approvals. Source-intent changes use their existing revision owner.
+
+Use gate-artifact-preparation's shared Reviewed Recording Input with the supplied run/revision:
+run-step --step artefact --gate SD --evidence <recording-input.json>. Record SD-derived_from-PRD
+from its exact approved source. Initial registration uses update_draft false; permitted explicit
+replacement uses true with fresh mapping/input paths, preserving previous proof/history and
+other protected bytes. No hand-authored receipt, run-update bypass or unknown-edit reseal.
+Use supported transaction/recovery with fresh state on failure.
+
+Redispatch gate-check after recording. Prepare its exact run-present when supplied, show returned
+text verbatim and wait for a NEW deliberate Approval: SD. Changed drafts require fresh presentation;
+old replies cannot approve new content. Use the existing localized summary when languages differ.
+Only valid approval permits existing TP drafting; this skill creates no TP, code, QA or release.