create-agdf 0.14.5 → 0.20.0

package/generated/.opencode/contracts/task-target-resolution.md

@@ -2,19 +2,71 @@
 
 ## Purpose And Ordering
 
-Resolve the user's primary work target before repository activation, Scope Classification, mode
-selection or gate evaluation. Repository governance is downstream of the task target; the current
-working directory, an inspected repository or a source mentioned as evidence must never become the
-work target by accident.
+After positive Request Activation, resolve the user's primary work target before repository
+activation, Scope Classification, mode selection or gate evaluation for routes that require a
+target. Repository governance is downstream of the task target; the current working directory, an
+inspected repository or a source mentioned as evidence must never become the work target by
+accident. Silent Request Activation abstention and targetless catalog routes do not invoke this
+contract.
 
-The canonical order is:
+The canonical order after Request Activation selected a target-bound route is:
 
 1. resolve or revalidate the task target;
 2. derive the governance target from that resolved target;
 3. activate repository-local AGDF control only for that governance target;
 4. then apply read-only orientation, Scope Classification, mode selection and gate evaluation.
 
-If task-target resolution is unresolved, steps 2–4 and every mutation are forbidden.
+If task-target resolution is unresolved, steps 2–4 and every mutation are forbidden. The unresolved
+result is terminal for the current response and overrides continuation, missing-control, fresh-UR
+and approval branches. Prior chat artefacts, runs and approvals remain candidate context only; they
+must not produce a conditional gate result until one target is resolved.
+
+## Direct Skill Invocation Preflight
+
+After the already-loaded Request Activation guard has positively selected a direct, target-bound
+skill route, every canonical AGDF skill invocation starts with this preflight before skill-specific
+input discovery, repository inspection, run selection, gate evaluation, quality evaluation or
+mutation. This applies equally when a user invokes a skill explicitly and when the agent router
+selected it. Automatic selection alone is not positive activation; on silent abstention this
+preflight is not run.
+
+1. Determine the current conversation language for presentation. A German user turn or an ongoing
+   German conversation uses `de`; an unsupported language falls back to the complete English locale
+   pack through the Interaction Contract.
+2. Resolve or revalidate the primary target under Target Authority Precedence. When an exact-version
+   surface-local validator is available, use one of the existing `target-check --json` forms below.
+3. Validate the normalized Resolution Result. Do not infer missing fields from cwd, chat storage,
+   an inspected repository, a prior run or evidence sources.
+4. If `resolution_state` is `unresolved`, consume `task_target_orientation.markdown` verbatim from
+   the Interaction Contract, request only the normalized `next_action` in the same presentation
+   language and stop the current skill invocation. This is a terminal pre-decision outcome: do not
+   inspect repository control state, select a run, evaluate a gate or quality decision, produce the
+   skill's normal output, or mutate files.
+5. If `resolution_state` is `resolved`, use only its `governance_target` for downstream repository,
+   run, gate and evidence access. Revalidate after an explicit target change and before every
+   mutation or gate decision.
+
+The resolved `presentation_language` remains binding for the complete user-facing interaction:
+target orientation, clarification and subsequent skill-owned chat output must not mix locale packs.
+Durable artefacts, machine fields, task identifiers and exact approval values retain their canonical
+language as defined by the Interaction Contract.
+
+Context-only form when no reliable target is selected:
+
+```bash
+node <surface-local-agdf> target-check --json --language <current-chat-language> --working-directory <absolute-path>
+```
+
+Selected-target form:
+
+```bash
+node <surface-local-agdf> target-check --json --language <current-chat-language> --target-source <explicit_target|continued_target|current_repository> --primary-target <absolute-path> --working-directory <absolute-path>
+```
+
+The two forms are validation paths, not permission to invent a target or contact a registry. If no
+exact-version surface-local validator exists, continue agent-natively only as far as the observable
+evidence permits and report machine validation as unavailable. Do not install or resolve a remote
+runtime during ordinary skill invocation.
 
 ## Resolution Result
 
@@ -22,17 +74,19 @@ Use one normalized result:
 
 - `resolution_state`: `resolved | unresolved`
 - `reason_code`: `explicit_target | continued_target | multiple_plausible_targets |
-  target_content_mismatch | target_unavailable | no_reliable_target`
+  target_content_mismatch | target_unavailable | no_reliable_target | target_source_invalid`
 - `primary_target`: exactly one requested work object when resolved, otherwise empty
 - `evidence_sources`: zero or more mentioned or inspected sources that do not gain mutation authority
 - `working_directory`: execution context only, never target authority by itself
 - `governance_target`: the repository whose control state applies to the primary target, otherwise empty
 - `target_changed`: whether an explicit new target replaced the previously confirmed target
 - `next_action`: required clarification, supply or retry action when unresolved
+- `input_error`: present only for invalid target-selection input; contains the canonical `field` and
+  `allowed_values` without echoing the rejected value
 
 A resolved result requires a non-empty `primary_target` and a reason code of `explicit_target` or
 `continued_target`. An unresolved result requires an empty `primary_target`, an empty
-`governance_target`, one of the four unresolved reason codes and a non-empty `next_action`.
+`governance_target`, one of the five unresolved reason codes and a non-empty `next_action`.
 Contradictory or incomplete results fail closed.
 
 ## Target Authority Precedence
@@ -94,7 +148,7 @@ Never silently expand scope to make the request fit a different project.
 ## Presentation Boundary
 
 `contracts/interaction.md` owns the visible, non-authorizing Task Target Orientation.
-`create-agdf/lib/interaction-presentation.js` owns its rendering. The renderer projects a normalized
+`packages/core/lib/interaction-presentation.js` owns its rendering. The renderer projects a normalized
 result; it must not resolve targets, derive governance or become a state store.
 
 Show orientation when target/context separation is material, when the target changes, or when the

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

@@ -0,0 +1,81 @@
+# AGDF Runtime Contract — TP Definition
+
+Use only a bound skill_continuation with phase tp_definition. This is the semantic Task/Test
+Plan author, never a gate, writer, approval or implementation authority.
+
+## Binding and content
+
+Use the returned target/run/revision, destination, exact approved PRD/SD and analytical sources,
+resolved languages and installed plugin-owned template_path. Missing/unsafe templates stop before
+writing; repository scaffold copies are no fallback. Unbound invocation uses the existing scope
+inventory, then revision-bound gate-check intake. Ambient runs, cwd, selection and discovery grant
+no assignment or editing intent. Keep approved sources and foreign runs protected.
+
+Preserve criteria-chain-v1, stable task/scenario IDs and the existing TP template. Map every PRD
+criterion and associated SD decision to tasks, dependencies, boundary/error scenarios, observable
+expected results and exact evidence sources. Reference acceptance IDs; never copy or rename their
+authority. Test Plan gives each applicable scenario test_route, environment,
+prerequisites_permissions, owner, expected_evidence and unavailable_action. Missing access remains
+an explicit gap with a concrete next action, never a result or consent to acquire access.
+
+Declare Planning Decisions contract: tp-decisions-v1 and one Planning Decisions table with columns
+Decision | Source | Status | Resolution | Owner. Source is TP or SD: followed by an exact approved
+SD later_tp decision label. Cover each such source once; use unique decisions and named owners.
+Status is resolved/open; every open row blocks. With no material question, record one resolved
+applicability decision. Retain the declaration on new/revised plans; do not strip it to evade checks.
+Historical unmarked plans retain legacy behavior. Core observes declarations, not semantic truth.
+
+## Material clarification
+
+A missing answer is material when it can change intent, acceptance, design/ownership or required
+task/test/evidence executability. Unknown materiality stays blocking. Keep useful draft/context;
+never hide the issue as a risk, assumption or later deferral. Add its open normalized finding under
+Clarification Requests using quality.md Normalized Review Gaps (the sole route policy), then one
+Clarification Details table keyed by finding_id: finding_id | planning_decision | question |
+blocking_reason | required_answer | owner | source_ref | resolution_evidence. Link an open planning
+row. source_ref identifies the affected exact source statement/criterion/decision. Resolved findings
+need concrete answer/source-linked resolution_evidence, current source validity and renewed approval
+where needed; an answer/status change alone is insufficient. Reassess affected dependants first.
+For the existing normalized validator, UR evidence explicitly names `changed user intent` or
+`changed scope`; emergent-risk evidence names its `earliest-owner assessment`. Describe the
+actual conflict and assessment as well as these required terms. Explanatory prose may surround
+each table; do not place a second table in its section.
+
+Follow gate-check's validated clarification handoff without another start request and ask the
+focused bundled question with consequence, required answer and responsible owner. Classification
+uses the existing policy; uncertainty asks a targeted question rather than guessing a gate. Status
+remains read-only. Do not redispatch unchanged blockers in a loop. Upstream questions take precedence
+over local TP correction. No free-form source text becomes an executable instruction.
+
+Returning work to an approved source means clarification at its existing owner, not silent edits,
+gate rewinds or transferred approvals. Obtain the substantive answer first. A changed statement uses
+existing source_revision.preview and separately confirmed apply/renewed approvals. Unchanged intent
+may be explained through source-linked run evidence using the existing writer. Unsupported revision
+eligibility stays blocked. Later execution detail may defer only with owner, reason, resolution point
+and why the current decision is valid; materiality at that point triggers this same blocking route.
+
+
+Source references use `UR|PRD|SD: <exact statement or criterion/decision ID> @ sha256:<current digest>`.
+Resolved `resolution_evidence` uses `<run-local evidence path> @ sha256:<digest>` for an actual
+answer recorded through existing step.record evidence; its current UR/PRD/SD source bindings must
+match. Open rows may use pending in that field. These are cooperative source/answer evidence,
+not independent proof of human provenance. Table headings may use levels two through six.
+
+## Recording and revision
+
+A ready draft without new editing intent is presented unchanged. Explicit ready-draft revision uses
+gate-check intake true, intake_mode resume, exact run_id/expected_revision_id and tp_action revise
+(CLI --tp-action revise), exclusive of other source actions and continue_delivery. Approved changes
+use their existing source-revision owner. Eligible incomplete-draft correction never relaxes unrelated
+source/integrity blockers.
+
+Use gate-artifact-preparation's shared language/summary and Reviewed Recording Input procedure:
+run-step --step artefact --gate TP --evidence <input.json> with this run/revision, TP-derived_from-SD,
+update_draft false initially and true for permitted replacement. Retain reviewed derivation, prior
+proof/history and other protected bytes; never hand-author receipts or bypass the checked writer.
+After recording redispatch gate-check for this same run with `continue_delivery: true`
+(CLI `--continue-delivery`). This resumes the authoring workflow: a validated material question
+returns `tp_clarification` to ask now, while an explicit status read remains read-only. If ready,
+prepare its exact run-present, show returned text and wait
+for a NEW deliberate Approval: TP. Changed content needs a fresh presentation/reply. Neither this
+skill nor a successful draft check grants implementation, QA or release permission.

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

@@ -0,0 +1,94 @@
+# AGDF Runtime Contract — UR Definition
+
+This contract guides `ur-definition` only after a non-authorizing, bound
+`skill_continuation` with `phase: ur_definition`. It creates no gate or persistence authority.
+
+## Binding and ownership
+
+Use only the returned governance_target, run_id, revision_id, artifact_path and template_path.
+template_path is the absolute, version-matched template owned by the installed plugin runtime.
+Repository copies under `.agdf/control/templates/` are derived scaffold references and never
+override this authoring source. Read the template without rewriting it; persist only artifact_path.
+A direct invocation first dispatches ur-definition; without a bound run follow the existing
+resolve_delivery_run assignment, then gate-check intake/resume with its expected_revision_id.
+Never use AGDF_RUN_ID, cwd, discovery or a previous approval as authority. Missing, stale,
+foreign, invalid or approved bindings require fresh control routing; do not write.
+Gate-check delegates UR content here and remains the read-only readiness/approval owner.
+PRD semantic preparation belongs to prd-definition. Semantic SD/TP preparation belongs to sd-definition/tp-definition; shared registration
+remains in gate-artifact-preparation.
+
+## Define the need
+
+Read the original request and answered context. Populate Problem, Goal, Affected Users,
+Scope, Non-Goals, Acceptance Signals, Existing Source Of Truth, Risks And Unknowns and Next Step.
+Keep user intent distinct from assumptions. Cite known repository owners where available;
+record unknown ownership without inventing facts. Do not invent users, scope, requirements,
+acceptance promises, approvals or downstream product/design decisions.
+
+### Preserve requested clarification deliverables
+
+For a user-facing change, capture what the user needs to see or try to judge the proposed behavior.
+When a preview, mockup or prototype is explicitly requested, preserve it as an actual deliverable
+in Scope: its purpose, user task, relevant states/scenarios, required interaction or format and
+when it is needed (for example before PRD approval). Record observable review success in Acceptance
+Signals and unresolved product questions in Risks And Unknowns. Use answered context; ask only if
+an ambiguity materially changes the requested deliverable. Do not turn an illustrative example into
+a requirement. Without an explicit preview commitment, do not impose one on unrelated or already
+clear requests.
+
+Distinguish a required preview from an optional clarification aid. An explicitly requested
+interactive preview cannot silently become a screenshot, static wireframe or written walkthrough.
+Preserve the requirement and name a concrete recovery or obtain an explicit scope change if it
+cannot be delivered. Record the responsible later UX/PRD step in Next Step; UR authoring still
+writes only its assigned UR, not a preview or product implementation. A requested before-PRD preview
+is created through UX intent clarification under the existing post-UR routing owner. Its durable
+output belongs to `.agdf/control/artefacts/<run_id>/previews/` for the bound run; the UX skill owns
+creation, versioning, evidence and references. An inline chat rendering alone does not fulfill that
+run deliverable. In a new UR, set exactly one initial metadata line before the first section:
+`Preview requirement: before_prd_interactive` for a required interactive before-PRD preview,
+otherwise `Preview requirement: none`. Preserve the task/scenarios in Scope and Acceptance
+Signals; the field cannot replace them. Missing markers in existing URs retain legacy semantics;
+do not retrofit an approved source or infer a requirement from prose/examples. Unknown or duplicate
+values require correction through the existing UR owner. This adds no gate or separate approval.
+
+When a missing fact materially changes the problem, intended users, scope or success signal,
+ask one bundled semantic clarification covering the actual gap. Do not ask for technical run
+identifiers or repeat answered questions. Preserve a useful draft with
+`Requirements clarification: open`; it is not ready for approval. If the concrete request is
+complete, draft immediately. Minor unknowns may be marked assumptions/deferred questions when
+they do not change the need; explain them, do not create redundant clarification loops.
+Set `Requirements clarification: complete` only when all required sections are concrete and
+no material requirement decision remains open. This is cooperative semantic judgement, not approval.
+Keep Status draft and Gate approval open.
+
+## Language and approval summary
+
+Use the continuation's `artifact_language` resolved from `.agdf/control/config.json` for
+the UR and its resolved `presentation_language` for user-facing text. Do not infer the
+artefact language from the request, template headings or runtime rules. The configured
+chat language is the direct-command default; explicit dispatcher presentation input
+follows its current-request language contract and does not change the artefact language.
+
+Before recording a complete draft, when `approval_summary_required` is true, include exactly
+one `## <approval_summary_heading>` section using the supplied heading verbatim. Write a
+complete summary in the resolved presentation language covering problem, goal, affected users,
+scope, non-goals, acceptance signals, source ownership, risks/unknowns and next step.
+Do not truncate decision-relevant content or use ellipses. The existing approval renderer's
+limits and validation apply. This summary is editorial; the UR remains authoritative.
+For new-format URs, a missing or invalid required summary returns to this same authoring
+route before presentation. Correct it through the existing revision writer; no user approval
+is required merely to complete an unapproved incomplete draft.
+
+## Revision and recording
+
+A new draft is recorded through existing run-step --step ur --title <short title>, using
+--dir <governance_target> --run <run_id> --revision <revision_id>.
+For an already registered unapproved draft, require explicit user revision intent. Resume
+through gate-check with intake true, intake_mode resume, run_id, expected_revision_id and
+ur_action revise (CLI --ur-action revise). Ordinary intake of a ready draft still presents it.
+After editing a registered draft use existing run-update, not run-step: the previous seal
+must be replaced by the canonical revision writer. Never edit an approved UR or its approval.
+Use the returned new revision, redispatch gate-check for this target/run, prepare the fresh
+run-present when supplied, show its returned text verbatim and wait for a NEW deliberate
+`Approval: UR`. Previous presentations/replies cannot approve a changed draft.
+After valid UR approval, existing Brownfield Review and Mode/Slice routing continue unchanged.

package/generated/.opencode/skills/agdf-brownfield-analysis/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: agdf-brownfield-analysis
-description: "Use this skill after gate-check or live AGDF control state confirms that Brownfield Review or implementation preparation is allowed. Use it after Approval: UR as the lightweight Brownfield Review after G-00 before PRD when existing systems may be affected, and again before non-trivial implementation after TP. Do not use it as the first AGDF skill for a fresh \"I want to build/change X\" prompt when approval, scope, or next allowed action is unclear."
+description: "Use this skill for this scope: permitted Brownfield Review or preparation before non-trivial existing-system changes. Boundary: clarifies reuse, owners, risks and Mode/Slice; never bypasses control or grants implementation. The requested effect, not discovery, decides AGDF activation."
 ---
 
 # brownfield-analysis
@@ -19,15 +19,48 @@ The skill answers:
 - whether Context Graph impact exists without automatically creating a node
 
 ## Runtime Contract
-Use these focused runtime-contract modules:
+Use `continuation.runtime_contracts` after `skill_continuation`. If absent: listed MCP `agdf_inspect` (`operation: contract`, `module: <name>`); else supplied schema-2 executable/argv_prefix[0] `contract --module <name>`; else bundled files below. MCP reads need no hook or shell. Missing module: stop; never infer/search for runtime.
 
 - `../../contracts/gate-transition.md`
 - `../../contracts/modes.md`
 - `../../contracts/context-graph.md`
 - `../../contracts/quality.md`
 
+`instruction_only`: first load `../../contracts/task-target-resolution.md` and `../../contracts/interaction.md`.
+
+<!-- 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 -->
+
+## Executable Dispatch
+
+Use listed MCP `agdf_dispatch` (load deferred; host prefix allowed): `skill_id` `brownfield-analysis`, `presentation_language`, `working_directory`, and only bound `target_source`/`primary_target` and `run_id`. Never search unlisted tools.
+If absent/failing: supplied schema-2 executable, child-only environment, immutable argv_prefix, declared arguments; `--skill brownfield-analysis`, language and working directory.
+For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
+`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
+Quote shell values as data.
+For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
+On skill_continuation use only its target/control. Without that tool and a valid binding: `dispatcher_unavailable`; no runtime search, environment repair
+or help retries. Dispatch never authorizes.
+
 Brownfield-specific output must make evidence, missing existing-system view, parallel-structure risk, reuse strategy, and the minimal next step visible.
-When `.agdf/control/` is present, persist or link `post_ur_review` output under `.agdf/control/artefacts/<key>/BROWNFIELD_REVIEW.md`.
+When `.agdf/control/` is present, persist or link `post_ur_review` output under `.agdf/control/artefacts/<key>/BROWNFIELD_REVIEW.md`,
+then record the Mode/Slice Decision with the validator's `run-step --step route --route <mode> --reason --evidence`.
 
 ## Modes
 
@@ -41,9 +74,36 @@ In `post_ur_review`, also record `delivery_context`, `ui_ux_impact`, `ui_ux_impa
 `../../contracts/gate-transition.md`. Greenfield records make existing-system evidence explicitly
 not applicable; Brownfield records cite repository evidence. Do not create a second Greenfield router.
 
+In the same `post_ur_review`, record architecture relevance before the existing Mode/Slice
+Decision. Check only boundaries the proposed change could affect: module or owner, externally
+consumed interface, data or source-of-truth ownership, compatibility or migration, runtime or
+host contract, and security or policy authority. An unresolved effect on one of these boundaries
+is relevant until its evidence owner resolves it. Cite the affected repository paths, contracts
+or observed behavior; do not infer relevance from file or owner counts.
+
+For a local change with no material boundary effect or unresolved architecture question, record
+`architecture-not-applicable` and the affected code/owner evidence supporting that reason. Do
+not require a full architecture checklist or diagram for this route. For a relevant change,
+record the boundary, impact, evidence, missing facts and existing owner of the next action in
+the same Brownfield Review. Classify each architecture finding in its existing Reuse And
+Parallel-Structure Risk row as `problem`, `trade-off` or `unresolved`. A proposed trade-off that
+knowingly retains or adds debt is not accepted merely because it is documented: the same finding
+must have a rationale, accountable owner, mitigation and finite review date or exit condition.
+Until all four are present, leave it unresolved and route the missing decision to its owner.
+The Brownfield Review itself must then be at least `revise`; use `block` when the missing
+decision prevents a safe Mode/Slice route. Do not report `pass` while claiming that the debt
+acceptance is still open.
+Use a focused diagram only when it answers a named ownership or dependency question that the
+textual evidence cannot settle; link it from the same review.
+
+Architecture evidence informs the sole Structured Depth Decision in `modes.md`; it does not
+select a mode independently. If a decisive route fact is missing or conflicting, use the
+existing `block` and `depth_facts_missing | depth_facts_conflicting` recovery. Route later gaps
+through the normalized owners in `quality.md`; this review grants no downstream approval.
+
 ## Rules
 1. Brownfield first: understand the existing codebase before PRD/SD decisions when existing-system impact is possible, and again before implementation.
-2. Brownfield Review after `Approval: UR` is a sizing and routing step. It must visibly decide `quick_task`, `verified_change`, `structured_slice`, `structured_delivery`, or `block` before PRD depth or implementation is chosen. Persist the completed review and its decision, scope reason, evidence and required next gate in the same internal operation; mark the review `done` only after both the artefact and canonical run projection are complete. An interrupted, incomplete or legacy record stays at fail-closed `Mode/Slice Decision` recovery without another user approval.
+2. Brownfield Review after `Approval: UR`, or before it while the UR card is ready so that card can name the route, is a sizing and routing step. It must visibly decide `quick_task`, `verified_change`, `structured_slice`, `structured_delivery`, or `block` before PRD depth or implementation is chosen. Persist the completed review and its decision, scope reason, evidence and required next gate in the same internal operation; mark the review `done` only after both the artefact and canonical run projection are complete. An interrupted, incomplete or legacy record stays at fail-closed `Mode/Slice Decision` recovery without another user approval.
 3. Reuse-before-create: prefer existing modules, services, components, tables, endpoints, tests, and configuration.
 4. Minimal clean slice: choose the smallest durable intervention, not merely the smallest technical diff.
 5. No silent parallel structures.
@@ -68,10 +128,11 @@ not applicable; Brownfield records cite repository evidence. Do not create a sec
     completion and Brownfield/Mode-Slice re-evaluation.
 17. Owner, file, consumer, task or derived-path counts must never select a structured depth by
     themselves.
+18. In `post_ur_review`, apply the architecture-relevance rules above before the Mode/Slice Decision.
 
 ## When To Use
-- after `agdf-gate-check` permits `Brownfield Review` or the selected canonical run record names Brownfield Review as the next allowed action
-- after `agdf-gate-check` permits implementation preparation or the selected canonical run record already names Brownfield Analysis as the next allowed action
+- after `gate-check` permits `Brownfield Review` or the selected canonical run record names Brownfield Review as the next allowed action
+- after `gate-check` permits implementation preparation or the selected canonical run record already names Brownfield Analysis as the next allowed action
 - after `Approval: UR` when existing owners, SoT, contracts, policies, persistence, runtime paths, tests, UI, UX or architecture may affect PRD/SD scope
 - before `CD+Tests`
 - before changes to an existing repository
@@ -93,7 +154,7 @@ Use what is available:
 - repository conventions
 
 If inputs are missing, work only from observable evidence and mark gaps explicitly.
-If gate status, approval, scope or next allowed action is unclear, stop and route to `agdf-gate-check` instead of recommending PRD/SD detail or starting implementation.
+If gate status, approval, scope or next allowed action is unclear, stop and route to `gate-check` instead of recommending PRD/SD detail or starting implementation.
 When used as Brownfield Review after `Approval: UR`, do not recommend PRD, SD, TP, or implementation until the Mode/Slice Decision is explicit, evidenced and recorded.
 
 ## Workflow
@@ -121,7 +182,8 @@ When used as Brownfield Review after `Approval: UR`, do not recommend PRD, SD, T
 9. Check UI monolith risk for large surfaces or central hooks.
 10. Check Context Graph impact according to `../../contracts/context-graph.md`.
 11. Recommend the minimal clean implementation path.
-12. In `post_ur_review`, record `depth_policy_version`, `depth_facts_status`,
+12. In `post_ur_review`, record the conditional Architecture Impact described above in the same Brownfield Review.
+13. In `post_ur_review`, record `depth_policy_version`, `depth_facts_status`,
     `primary_reason_code`, `decisive_full_depth_triggers`, `rejected_alternative`,
     `missing_or_conflicting_facts`, `depth_evidence_refs` and evidence for all seven bounded-slice
     check IDs in the Brownfield Review. Then persist the completed review and the existing

package/generated/.opencode/skills/agdf-clean-implementation-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: agdf-clean-implementation-review
-description: Use this skill to determine whether an implementation is a clean primary solution or whether fallbacks, workarounds, guards, defaults, shims, or parallel structures have made it unnecessarily complex. Use it after code changes, before QA, or whenever symptom treatment is suspected.
+description: "Use this skill for this scope: evidence dimension: inspect whether the solution is structurally clean. Boundary: supports Quality Readiness; not a TP or QA substitute. The requested effect, not discovery, decides AGDF activation."
 ---
 
 # clean-implementation-review
@@ -18,11 +18,43 @@ This skill answers:
 - is it maintainable or workaround-heavy
 
 ## Runtime Contract
-Use these focused runtime-contract modules:
+Use `continuation.runtime_contracts` after `skill_continuation`. If absent: listed MCP `agdf_inspect` (`operation: contract`, `module: <name>`); else supplied schema-2 executable/argv_prefix[0] `contract --module <name>`; else bundled files below. MCP reads need no hook or shell. Missing module: stop; never infer/search for runtime.
 
 - `../../contracts/quality.md`
 - `../../contracts/context-graph.md`
 
+`instruction_only`: first load `../../contracts/task-target-resolution.md` and `../../contracts/interaction.md`.
+
+<!-- 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 -->
+
+## Executable Dispatch
+
+Use listed MCP `agdf_dispatch` (load deferred; host prefix allowed): `skill_id` `clean-implementation-review`, `presentation_language`, `working_directory`, and only bound `target_source`/`primary_target` and `run_id`. Never search unlisted tools.
+If absent/failing: supplied schema-2 executable, child-only environment, immutable argv_prefix, declared arguments; `--skill clean-implementation-review`, language and working directory.
+For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
+`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
+Quote shell values as data.
+For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
+On skill_continuation use only its target/control. Without that tool and a valid binding: `dispatcher_unavailable`; no runtime search, environment repair
+or help retries. Dispatch never authorizes.
+
 Clean-review-specific output must make the primary solution, fallbacks, workarounds, parallel structures, exit criteria, and next cleanup/review step visible.
 Applicable findings must use `../../contracts/quality.md` §Normalized Review Gaps. This skill
 must distinguish a missing upstream decision from implementation that violates an approved decision.
@@ -58,7 +90,7 @@ Use what is available:
 - Code Deliverables
 - changed files
 - tests and test results
-- `agdf-code-review` or Code Review Report
+- `code-review` or Code Review Report
 - QA Report
 - Brownfield Analysis findings
 - PRD or SD architecture notes

package/generated/.opencode/skills/agdf-code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: agdf-code-review
-description: Use this skill after code changes and before QA to produce the mandatory Code Review Report for correctness, regression, security, and maintainability findings in the actual diff. It standardizes the CR step without replacing TP review, clean review, or QA.
+description: "Use this skill for this scope: evidence dimension: review the actual diff for defects, regression and security findings. Boundary: supports Quality Readiness; does not replace QA. The requested effect, not discovery, decides AGDF activation."
 ---
 
 # code-review
@@ -17,11 +17,43 @@ It answers:
 - whether Brownfield, TP, or clean-review follow-up remains open
 
 ## Runtime Contract
-Use these focused runtime-contract modules:
+Use `continuation.runtime_contracts` after `skill_continuation`. If absent: listed MCP `agdf_inspect` (`operation: contract`, `module: <name>`); else supplied schema-2 executable/argv_prefix[0] `contract --module <name>`; else bundled files below. MCP reads need no hook or shell. Missing module: stop; never infer/search for runtime.
 
 - `../../contracts/quality.md`
 - `../../contracts/context-graph.md`
 
+`instruction_only`: first load `../../contracts/task-target-resolution.md` and `../../contracts/interaction.md`.
+
+<!-- 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 -->
+
+## Executable Dispatch
+
+Use listed MCP `agdf_dispatch` (load deferred; host prefix allowed): `skill_id` `code-review`, `presentation_language`, `working_directory`, and only bound `target_source`/`primary_target` and `run_id`. Never search unlisted tools.
+If absent/failing: supplied schema-2 executable, child-only environment, immutable argv_prefix, declared arguments; `--skill code-review`, language and working directory.
+For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
+`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
+Quote shell values as data.
+For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
+On skill_continuation use only its target/control. Without that tool and a valid binding: `dispatcher_unavailable`; no runtime search, environment repair
+or help retries. Dispatch never authorizes.
+
 Code-review-specific output must make actual findings, missing review scope, evidence strength, and the next required step visible.
 Applicable findings must use `../../contracts/quality.md` §Normalized Review Gaps. Concrete diff
 defects remain Code Review findings; missing upstream constraints route to their authoritative owner.
@@ -78,6 +110,8 @@ Use this compact structure:
 
 ```text
 ## Code Review
+Record the decision with the validator's `run-step --step review --decision <pass|revise|block> --evidence`.
+
 - decision: pass | revise | block | not_applicable
 - findings:
   - [severity] file/path - issue - evidence

package/generated/.opencode/skills/agdf-delivery-closeout/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: agdf-delivery-closeout
-description: Use this skill for the final delivery handoff after QA, OR, or UAT when a run should move toward commit, push, or PR. It standardizes commit-ready summaries, UAT-gated commit offers, and the next delivery step without replacing QA or OR decisions.
+description: "Use this skill for this scope: commit/PR-near handoff after QA/OR/UAT. Boundary: never performs VCS actions automatically. The requested effect, not discovery, decides AGDF activation."
 ---
 
 # delivery-closeout
@@ -17,15 +17,47 @@ It answers:
 - whether evidence-based technical follow-up remains useful
 - whether Context Graph follow-up from OR/QA remains open
 
-This skill does not replace `agdf-qa-gate`, `agdf-release-or`, user approvals, or gate decisions.
+This skill does not replace `qa-gate`, `release-or`, user approvals, or gate decisions.
 
 ## Runtime Contract
-Use these focused runtime-contract modules:
+Use `continuation.runtime_contracts` after `skill_continuation`. If absent: listed MCP `agdf_inspect` (`operation: contract`, `module: <name>`); else supplied schema-2 executable/argv_prefix[0] `contract --module <name>`; else bundled files below. MCP reads need no hook or shell. Missing module: stop; never infer/search for runtime.
 
 - `../../contracts/closeout.md`
 - `../../contracts/context-graph.md`
 - `../../contracts/gate-transition.md`
 
+`instruction_only`: first load `../../contracts/task-target-resolution.md` and `../../contracts/interaction.md`.
+
+<!-- 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 -->
+
+## Executable Dispatch
+
+Use listed MCP `agdf_dispatch` (load deferred; host prefix allowed): `skill_id` `delivery-closeout`, `presentation_language`, `working_directory`, and only bound `target_source`/`primary_target` and `run_id`. Never search unlisted tools.
+If absent/failing: supplied schema-2 executable, child-only environment, immutable argv_prefix, declared arguments; `--skill delivery-closeout`, language and working directory.
+For `--language`: Required presentation language for the latest natural-language user request as one well-formed BCP 47 tag. If the request explicitly asks for a response language, use that tag; otherwise use the dominant request language. Use en when mixed or ambiguous. A valid unsupported tag renders through the complete English pack. Missing or invalid input fails before governance evaluation.
+`target_source`: `explicit_target` if request names `primary_target`; `continued_target` if it unambiguously continues confirmed target; `current_repository` if request names this/current repo with one matching repo active. Otherwise omit the pair; cwd has no target authority.
+Quote shell values as data.
+For a result with `terminal: true`, the entire assistant response must consist only of host_action.text, copied verbatim. Add no question, explanation, heading, citation, link or other surrounding text; do not translate or reformat it; invoke no later tool and stop.
+On skill_continuation use only its target/control. Without that tool and a valid binding: `dispatcher_unavailable`; no runtime search, environment repair
+or help retries. Dispatch never authorizes.
+
 ## Rules
 1. Delivery follows gate clarity.
 2. Never perform commit, push, or PR automatically.
@@ -44,7 +76,7 @@ Use these focused runtime-contract modules:
 - after `Approval: UAT`
 - when the user asks for commit, push, or PR handoff
 
-Do not use as a substitute for `agdf-qa-gate`, `agdf-release-or`, or `agdf-gate-check`.
+Do not use as a substitute for `qa-gate`, `release-or`, or `gate-check`.
 
 ## Inputs
 Use what is available: