create-agdf 0.11.4 → 0.12.0

package/README.md

@@ -149,7 +149,7 @@ Then verify the visible installation state:
 npx --yes @agdf/cli@latest opencode-status --json
 ```
 
-The status command reports global configuration, package loadability, global native-skill completeness, installed host/plugin-SDK version divergence, declaration-level support for both experimental hooks, durable repository activation, legacy local-surface compatibility and session signals. SDK declarations are not proof that a live host invoked a hook, and host/SDK divergence is warning-only rather than auto-aligned. The command does not infer an active OpenCode session from config alone.
+The status command reports global configuration, package loadability, global native-skill completeness, installed host/plugin-SDK version divergence, declaration-level support for both experimental hooks, durable repository activation, legacy local-surface compatibility and session signals. SDK declarations are not proof that a live host invoked a hook. Status is read-only and keeps divergence warning-only; the explicit `opencode` install command attempts to align the SDK only to the exact detected host version and returns a partial result when alignment is unavailable, fails or cannot be verified. The command does not infer an active OpenCode session from config alone.
 In JSON schema version 1, `repository_surface.gate_check_agent` remains a deprecated compatibility alias for the native `gate_check_skill` path so existing status consumers keep working during the agent-to-skill migration.
 
 Use the `opencode-repo` target when a repository should opt into the globally installed AGDF OpenCode runtime:

package/generated/.agdf/control/templates/artefacts/BROWNFIELD_REVIEW.md

@@ -55,6 +55,31 @@ Brownfield cites repository evidence.
 - evidence:
 - transparency_note:
 
+## Structured Depth Evidence
+
+- depth_policy_version: `1`
+- depth_facts_status: `complete | missing | conflicting | not_applicable`
+- primary_reason_code:
+- decisive_full_depth_triggers:
+- rejected_alternative:
+- missing_or_conflicting_facts:
+- depth_evidence_refs:
+
+Use `not_applicable` only when an unchanged Quick/Compact or Verified Change path is selected before
+Structured Depth. A positive structured decision requires complete facts. Missing or conflicting
+decisive facts without an already-evidenced full-depth trigger persist `decision: block` and name
+the evidence owner and precise Brownfield/Mode-Slice re-evaluation action.
+
+| check_id | result | evidence |
+|---|---|---|
+| coherent_outcome | `pass | fail | unknown | not_applicable` |  |
+| authority_boundary | `pass | fail | unknown | not_applicable` |  |
+| owner_consumer_coordination | `pass | fail | unknown | not_applicable` |  |
+| full_depth_impacts_absent | `pass | fail | unknown | not_applicable` |  |
+| migration_propagation_bounded | `pass | fail | unknown | not_applicable` |  |
+| failure_recovery_local | `pass | fail | unknown | not_applicable` |  |
+| independently_acceptable | `pass | fail | unknown | not_applicable` |  |
+
 ## PRD / SD Open Questions
 
 | Question | Required gate | Impact |

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

@@ -22,6 +22,7 @@ The skill answers:
 Use these focused runtime-contract modules:
 
 - `../contracts/gate-transition.md`
+- `../contracts/modes.md`
 - `../contracts/context-graph.md`
 - `../contracts/quality.md`
 
@@ -54,6 +55,19 @@ not applicable; Brownfield records cite repository evidence. Do not create a sec
 11. Large UI surfaces and state hooks must be checked for mixed render, view-model, derived state, orchestration, persistence, and recovery ownership.
 12. Context Graph impact must be curated; it is not a review log or version index.
 13. Specification archive migrations must follow the archive index if present.
+14. In `post_ur_review`, evaluate unchanged compact paths first. For a structured candidate, apply
+    only the `Structured Depth Decision` in `modes.md`; do not recreate its trigger/check matrix in
+    this skill.
+15. A positive structured decision requires `depth_policy_version: 1`,
+    `depth_facts_status: complete`, complete evidence for all seven bounded-slice checks, a primary
+    reason code, rejected alternative and evidence references. A decisive full-depth trigger may
+    support `structured_delivery`; `structured_slice` requires every bounded-slice check to pass.
+16. Missing or conflicting decisive facts without an already-evidenced full-depth trigger persist
+    the existing `block` decision with `depth_facts_missing | depth_facts_conflicting`, named facts,
+    their evidence owner where known, a Brownfield Review link and a precise next action for evidence
+    completion and Brownfield/Mode-Slice re-evaluation.
+17. Owner, file, consumer, task or derived-path counts must never select a structured depth by
+    themselves.
 
 ## When To Use
 - after `agdf-gate-check` permits `Brownfield Review` or the selected canonical run record names Brownfield Review as the next allowed action
@@ -107,6 +121,11 @@ 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`,
+    `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
+    Mode/Slice Decision atomically.
 
 ## Output
 Use a concise structure:
@@ -133,6 +152,13 @@ For `post_ur_review`, include the four UI/UX routing fields immediately after `s
 definition is required, its `ready | blocked | not_applicable` result must be visible before PRD
 readiness. A required `blocked` result is at least `revise` for this routing step.
 
+For a structured `post_ur_review` candidate, also include the complete `Structured Depth Evidence`
+section from `BROWNFIELD_REVIEW.md`. The decision projection must show the primary reason, decisive
+dimensions, bounded-slice result, rejected alternative, evidence and required next gate. For
+missing/conflicting facts, show product-language `depth_unresolved` while persisting `block`; name
+the gap and exact recovery action. Structural instruction checks can detect missing contract
+elements but do not prove semantic model compliance or live-host behavior.
+
 ## Pass / Revise / Block Guidance
 - `pass`: existing owners are understood, reuse path is clear, and no blocking drift or parallel structure risk remains.
 - `revise`: relevant evidence, tests, ownership, or reuse path is incomplete.

package/generated/.github/skills/agdf-gate-check/SKILL.md

@@ -20,6 +20,7 @@ This skill must not create later artefacts such as PRD, SD, TP, CD, CR, QA, or U
 ## Runtime Contract
 Use these focused runtime-contract modules:
 
+- `../contracts/task-target-resolution.md`
 - `../contracts/gate-transition.md`
 - `../contracts/interaction.md`
 - `../contracts/control-scaffold.md`
@@ -75,6 +76,12 @@ The CLI reports are validators and JSON evidence, not the primary user experienc
 
 Plugin `AGDF_*` environment variables set by the OpenCode `shell.env` hook are convenience only and must not be used as the only proof of activation; host shell-env propagation to spawned tool shells is not guaranteed and is OpenCode-owned, not AGDF-owned. A relative glob or `grep` for `.agdf/control/config.json` must not be used as proof of presence or absence of `.agdf/control/config.json`; an absolute `read` or the canonical CLI probe is required.
 
+## OpenCode Subagent Enforcement Boundary
+
+OpenCode plugin hooks (`tool.execute.before`) do not intercept tool calls from subagents spawned via the `task` tool (anomalyco/opencode issue #5894, PR #36238 open). AGDF enforcement through plugin hooks applies to primary-agent tool calls only; in the subagent path, AGDF governance is auditing-only, not enforcement.
+
+This is a host limitation, not an AGDF-owned defect. Do not claim that AGDF gates are technically enforced in the OpenCode subagent path. Do not route work to a subagent to bypass a primary-agent gate. When subagent work touches gate-relevant files, verify the result through the canonical validator (`doctor --json`, `gate-check --json`) after the subagent returns, not during.
+
 ## Native Interaction Path
 
 `../contracts/interaction.md` is the complete normative owner for interaction kinds, locale,
@@ -84,12 +91,15 @@ do not restate or infer a surface matrix in this skill.
 
 This skill owns only these operational responsibilities:
 
-1. Select exactly one run and evaluate its current gate.
-2. Confirm that the required durable artefact is present and ready.
-3. Consume the canonical `approval_presentation` verbatim for the selected run, gate and revision.
-4. Present that projection and obtain deliberate input through the contract-selected native or exact-text path.
-5. Revalidate the same run, gate and revision immediately after the response and before persistence.
-6. Persist only a currently valid exact approval through the existing control-state workflow.
+1. Resolve or revalidate the primary task target before selecting repository control state.
+2. Derive repository activation only from the resolved governance target; an evidence source or
+   working directory is not sufficient.
+3. Select exactly one run and evaluate its current gate.
+4. Confirm that the required durable artefact is present and ready.
+5. Consume the canonical `approval_presentation` verbatim for the selected run, gate and revision.
+6. Present that projection and obtain deliberate input through the contract-selected native or exact-text path.
+7. Revalidate the same target, run, gate and revision immediately after the response and before persistence.
+8. Persist only a currently valid exact approval through the existing control-state workflow.
 
 For status, blocked, read-only or rationale interactions, consume the canonical
 `status_presentation.markdown` verbatim and apply the locale contract without asking for approval.
@@ -156,18 +166,30 @@ Use what is available:
 If a status is not explicit, do not assume it is satisfied.
 
 ## Workflow
-1. Check exact approvals.
-2. Check artefact status.
-3. Determine the earliest blocking user gate or internal mandatory step.
-4. Derive allowed and forbidden outputs.
-5. Name the exact missing approval, if any.
-6. If consent was only implicit, say it is not yet approval and provide the exact formula.
-7. Ensure the next step follows the gate transition table. In particular, never jump from `Approval: UR` to implementation.
-8. Treat a generic "start", "continue" or "leg los" request as a request to perform only the current next allowed action.
-9. After Brownfield Review, choose the smallest safe process path before creating later artefacts.
-10. If the selected path is not visibly recorded with scope reason and evidence, keep the run at `Mode/Slice Decision`.
-11. When `.agdf/control/` is missing or incomplete, make the next allowed artefact action explicit. For a fresh request, that means draft the minimal UR in the response, then request `Approval: UR`. Do not write a full control scaffold unless durable control state was explicitly requested or is already the repository's live AGDF working state.
-12. If branch, workspace and durable artefacts disagree, do not choose a scope silently; report the ambiguity and ask for the smallest clarifying gate action.
+1. Resolve or revalidate the primary target through `task-target-resolution.md`.
+2. If resolution is unresolved, consume the canonical target orientation, request only its
+   clarification/recovery action and stop before repository activation, gate evaluation or mutation.
+3. Derive the governance target from the primary target; never from `cwd` or an evidence source alone.
+4. Check exact approvals.
+5. Check artefact status.
+6. Determine the earliest blocking user gate or internal mandatory step.
+7. Derive allowed and forbidden outputs.
+8. Name the exact missing approval, if any.
+9. If consent was only implicit, say it is not yet approval and provide the exact formula.
+10. Ensure the next step follows the gate transition table. In particular, never jump from `Approval: UR` to implementation.
+11. Treat a generic "start", "continue" or "leg los" request as a request to perform only the current next allowed action.
+12. After Brownfield Review, choose the smallest safe process path before creating later artefacts.
+13. If the selected path is not visibly recorded with scope reason and evidence, keep the run at `Mode/Slice Decision`.
+14. When `.agdf/control/` is missing or incomplete, make the next allowed artefact action explicit. For a fresh request, that means draft the minimal UR in the response, then request `Approval: UR`. Do not write a full control scaffold unless durable control state was explicitly requested or is already the repository's live AGDF working state.
+15. If branch, workspace and durable artefacts disagree, do not choose a scope silently; report the ambiguity and ask for the smallest clarifying gate action.
+
+### Task Target Orientation
+
+When target/context separation is material, the target changed, or resolution is unresolved, consume
+`task_target_orientation.markdown` verbatim from `renderTaskTargetOrientation` in
+`../contracts/interaction.md`. Do not reconstruct its fields or maintain a skill-local target
+template. If the renderer returns `null`, fail closed to target clarification and do not proceed to
+repository activation, Scope Classification or gate evaluation.
 
 ### Scope Classification Output
 When this skill classifies a fresh scope as ungated (Quick Task or Trivial Change Boundary), consume

package/generated/.github/skills/agdf-interaction-locales.json

@@ -58,6 +58,31 @@
         "escalation": "Escalation triggers",
         "challenge": "Challenge path"
       },
+      "taskTargetResolution": {
+        "title": "AGDF task target",
+        "field": "Field",
+        "value": "Value",
+        "state": "Resolution",
+        "resolved": "Resolved",
+        "unresolved": "Clarification required",
+        "primaryTarget": "Primary target",
+        "governanceTarget": "Governance target",
+        "evidenceSources": "Evidence sources",
+        "workingDirectory": "Working directory",
+        "targetChanged": "Target changed",
+        "yes": "yes",
+        "none": "none",
+        "reason": "Reason",
+        "nextAction": "Next action",
+        "reasonCodes": {
+          "explicit_target": "Explicit current-turn target",
+          "continued_target": "Confirmed target continued",
+          "multiple_plausible_targets": "Multiple plausible work targets",
+          "target_content_mismatch": "Requested change mismatches target",
+          "target_unavailable": "Named target is unavailable",
+          "no_reliable_target": "No reliable work target"
+        }
+      },
       "internalStateLabels": {
         "verifiedChange": "Compact change under review",
         "verifiedChangeEscalated": "Escalated to structured delivery",
@@ -284,6 +309,31 @@
         "escalation": "Eskalationsauslöser",
         "challenge": "Widerspruchspfad"
       },
+      "taskTargetResolution": {
+        "title": "AGDF-Arbeitsziel",
+        "field": "Feld",
+        "value": "Wert",
+        "state": "Auflösung",
+        "resolved": "Aufgelöst",
+        "unresolved": "Klärung erforderlich",
+        "primaryTarget": "Primäres Ziel",
+        "governanceTarget": "Governance-Ziel",
+        "evidenceSources": "Evidenzquellen",
+        "workingDirectory": "Arbeitsordner",
+        "targetChanged": "Ziel gewechselt",
+        "yes": "ja",
+        "none": "keines",
+        "reason": "Grund",
+        "nextAction": "Nächste Aktion",
+        "reasonCodes": {
+          "explicit_target": "Explizites Ziel im aktuellen Turn",
+          "continued_target": "Bestätigtes Ziel wird fortgesetzt",
+          "multiple_plausible_targets": "Mehrere plausible Arbeitsziele",
+          "target_content_mismatch": "Änderung passt nicht zum Zielinhalt",
+          "target_unavailable": "Benanntes Ziel ist nicht verfügbar",
+          "no_reliable_target": "Kein belastbares Arbeitsziel"
+        }
+      },
       "internalStateLabels": {
         "verifiedChange": "Kompakte Änderung wird geprüft",
         "verifiedChangeEscalated": "Eskaliert zu structured delivery",

package/generated/.github/skills/agdf-runtime-contract.md

@@ -4,6 +4,7 @@ This manifest indexes the thematic runtime-contract modules used by AGDF skills
 
 | Module | Path | Coverage |
 |---|---|---|
+| Task target resolution | `contracts/task-target-resolution.md` | Primary target authority, evidence/mutation separation, governance derivation, continuation and fail-closed target states |
 | Gate transitions | `contracts/gate-transition.md` | Source precedence, scope ambiguity, gate rules, Brownfield routing and transition model |
 | Interaction | `contracts/interaction.md` | Run Status Card, approval orientation, native interaction and locale contracts |
 | Modes | `contracts/modes.md` | Mode selection, Quick Task, Verified Change, trivial and bug boundaries |

package/generated/.github/skills/contracts/gate-transition.md

@@ -93,9 +93,13 @@ Mode/Slice Decision rules:
 
 - `quick_task`: use only when Brownfield Review shows a narrow local change, no new product semantics beyond the approved UR, no architecture/policy/persistence/contract expansion, and evidence is sufficient to proceed with a small implementation plus relevant checks.
 - `verified_change`: use only when the compact record can prove one canonical owner, bounded clean-at-baseline paths, no prohibited impact, deterministic propagation/validation and a structured escalation target. It skips later approvals only after every condition is evidenced and machine-validated.
-- `structured_slice`: use when some formal artefacts are needed, but they can stay intentionally small and scoped to the approved slice.
-- `structured_delivery`: use when the change has broad product, architecture, runtime, policy, persistence, release or cross-owner impact.
-- `block`: use when ownership, SoT, impact, evidence or product direction is not clear enough to choose a safe path.
+- `structured_slice` and `structured_delivery`: apply the sole normative `Structured Depth Decision`
+  in `modes.md`; this contract owns only the operational transition and does not duplicate its
+  trigger or bounded-slice matrix.
+- `block`: use when ownership, SoT, impact, evidence or product direction is not clear enough to
+  choose a safe path. A `depth_unresolved` product result is persisted through this existing value
+  with `depth_facts_missing | depth_facts_conflicting`, a Brownfield Review evidence link and a
+  precise evidence-owner/re-evaluation next action; it never creates a new mode or advances a gate.
 
 A Mode/Slice Decision without scope reason and evidence is not recorded. Treat it as missing and keep the next step at `Mode/Slice Decision`.
 

package/generated/.github/skills/contracts/interaction.md

@@ -338,6 +338,28 @@ repeat the sentence later in the same request. Existing-run status inspection re
 uses the existing status projection; this branch must not create a second status-card or narration
 owner.
 
+### Task Target Orientation
+
+Task-target semantics and ordering live in `task-target-resolution.md`. When target/context
+separation is material, a confirmed target changes, or resolution is unresolved, the agent consumes
+the canonical `task_target_orientation.markdown` verbatim from `renderTaskTargetOrientation` in
+`create-agdf/lib/interaction-presentation.js`.
+
+The projection may show the primary target, governance target, evidence sources and working
+directory for a resolved result. For an unresolved result it shows the localized reason and required
+next action. It carries `authorizes: false`, never renders approval controls and never selects or
+derives a target.
+
+For a fresh request, render the target orientation before read-only orientation, Scope
+Classification or any gate presentation when it is required. An unresolved result suppresses every
+downstream orientation and gate surface. A resolved result with material target separation may be
+followed by the one applicable downstream surface. Avoid a redundant target block for an obvious
+unchanged target.
+
+If the input is incomplete or contradictory, the renderer returns `null`. The agent then fails closed
+to target clarification and must not model-reconstruct Markdown. `agdf-gate-check` must not maintain a
+skill-local target-orientation template.
+
 ### Scope Classification Card
 
 When `agdf-gate-check` classifies a fresh scope as ungated (Quick Task or Trivial Change Boundary),

package/generated/.github/skills/contracts/modes.md

@@ -36,6 +36,87 @@ reason, evidence and required next depth in the same internal operation. `Mode/S
 only a fail-closed recovery step for incomplete or legacy records and is not a normal second user
 decision.
 
+### Structured Depth Decision
+
+This section is the sole normative owner for choosing between `structured_slice` and
+`structured_delivery`. Apply it only after an approved durable UR, a Brownfield Review of the
+existing-system context, and unchanged evaluation of Quick Task/Compact Delivery and Verified
+Change. A compact path must be ineligible or explicitly escalated, and the decisive depth facts must
+be durably evidenced before a positive structured decision is recorded.
+
+Choose `structured_delivery` when any one evidenced full-depth trigger applies:
+
+1. **Authority, policy or security** — a trust or authority boundary, permission, security,
+   compliance or normative policy changes, or independent decision owners require coordinated
+   approval.
+2. **Architecture or runtime** — execution, orchestration, durable execution, concurrency, failure
+   or recovery boundaries change beyond a local slice.
+3. **Persistence, data or migration** — persistent schema or meaning changes, data migration,
+   irreversible state transition, coordinated cutover, an extended compatibility window or
+   non-local rollback is required.
+4. **External or public contract** — an external API, public CLI behavior, protocol, file format or
+   compatibility-sensitive integration contract changes, including independent consumer
+   coordination or versioning.
+5. **Release, deployment or cross-host** — the work needs its own rollout, deployment, rollback,
+   feature-flag or release plan, or coordinated activation across hosts, products or operational
+   boundaries.
+6. **Unbounded consumer or owner coordination** — the outcome cannot be delivered as an
+   independently acceptable and reversible slice, or consumers or owners require a shared cutover
+   or compatibility window.
+
+A single trigger is decisive because of its effect, never because of a numeric count.
+
+Choose `structured_slice` only when `depth_facts_status` is `complete`, no full-depth trigger is
+evidenced, and all seven bounded-slice checks are positively evidenced as `pass`:
+
+| Check ID | Required evidence |
+|---|---|
+| `coherent_outcome` | One coherent user or product outcome has a clear acceptance boundary. |
+| `authority_boundary` | Authority and source of truth are known and no new trust, policy, permission or security boundary is introduced. |
+| `owner_consumer_coordination` | Owners and consumers are identified and coordination stays inside the slice without a shared external cutover. |
+| `full_depth_impacts_absent` | Architecture, runtime, persistence, data, external API, public CLI, release and cross-host effects are evidenced as not full-depth relevant. |
+| `migration_propagation_bounded` | Migration and propagation are bounded, compatible, testable and locally reversible. |
+| `failure_recovery_local` | Failure, recovery and rollback remain controllable inside the slice. |
+| `independently_acceptable` | The slice has independent acceptance signals and hides no unknown later work as a prerequisite. |
+
+Multiple files, owners, consumers or derived paths do not fail these checks by themselves. File,
+owner, consumer, task or derived-path counts are not a decision proxy and must never be used as a
+threshold for either structured mode.
+
+If a decisive fact is missing or conflicting and no evidenced full-depth trigger already supports
+`structured_delivery`, the product-language result is `depth_unresolved`. This is not a persisted
+mode. Persist the existing Mode/Slice value `block`, use `depth_facts_missing` or
+`depth_facts_conflicting`, name the affected facts and evidence owner where known, link the
+Brownfield Review, forbid later artefacts and implementation, and provide a precise next action for
+evidence completion and Brownfield/Mode-Slice re-evaluation. Unknown facts must not default to
+`structured_delivery`.
+
+Positive decisions persist the existing `structured_slice | structured_delivery` value, required
+next gate, a `scope_reason` containing the primary reason code and decisive rationale plus the
+rejected alternative, and evidence linking the complete Structured Depth Evidence. Re-evaluate
+before continuing whenever scope growth reveals a new full-depth trigger.
+
+Normalized reason codes are audit and rationale categories, not new modes or gates:
+
+- `bounded_structured_slice`
+- `authority_policy_security_depth`
+- `architecture_runtime_depth`
+- `persistence_migration_depth`
+- `external_contract_depth`
+- `release_cross_host_depth`
+- `unbounded_consumer_coordination`
+- `depth_facts_missing`
+- `depth_facts_conflicting`
+
+Structured Slice and Structured Delivery use the same existing gate and approval sequence. Their
+difference is artefact depth: Slice artefacts cover only the coherent bounded outcome and its owners,
+contracts, propagation, recovery, tasks and tests; Full Delivery covers every affected authority,
+architecture, runtime, consumer, migration, operational and release boundary.
+
+Historical or deterministic benchmark observations are non-authorizing evidence. They do not define
+this policy, retroactively regrade historical runs or prove live-host behavior. A future benchmark
+may apply this policy only with complete, versioned neutral depth facts.
+
 ### Verified Change
 
 `verified_change` is a compact, fail-closed path for a bounded user-visible change with one canonical owner and deterministic proof. It is neither a prose exception nor a new user approval gate.

package/generated/.github/skills/contracts/task-target-resolution.md

@@ -0,0 +1,102 @@
+# AGDF Runtime Contract — Task Target Resolution
+
+## 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.
+
+The canonical order 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.
+
+## Resolution Result
+
+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`
+- `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
+
+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`.
+Contradictory or incomplete results fail closed.
+
+## Target Authority Precedence
+
+Resolve in this order:
+
+1. an explicit file, artefact or repository named as the work target in the current user turn;
+2. a previously confirmed target only when the current turn unambiguously continues the same action,
+   object and scope;
+3. the current repository or working directory only when the request explicitly or deictically asks
+   for work on "this project", "this repository" or an equivalent current-scope reference;
+4. otherwise `no_reliable_target`.
+
+An explicit current-turn target always replaces an inherited target. Make the change visible when
+the previous target could otherwise remain plausible.
+
+Do not fall back to the working directory, a neighboring file or an evidence source when the
+explicit target is unavailable or its content does not support the requested change.
+
+## Evidence And Mutation Boundary
+
+Reading, inspecting, mentioning or relying on a repository or artefact makes it an evidence source,
+not a mutation target. Evidence access never grants mutation authority and never activates that
+repository's AGDF control state.
+
+Derive `governance_target` only from:
+
+- the repository containing the resolved `primary_target`; or
+- an explicit user statement that a named repository governs the target.
+
+An external standalone artefact may have no repository governance target. In that case the router
+continues with the applicable non-repository path; it must not borrow governance from the current
+working directory.
+
+## Continuation And Target Change
+
+A confirmed target may continue across related turns only when the current request remains
+unambiguous. Revalidate it before every mutation or gate decision. New explicit target evidence wins.
+New ambiguity ends the inherited binding and produces `multiple_plausible_targets`.
+
+When a durable AGDF run exists, its Source And Scope State may record the confirmed target as
+evidence. It does not override a newer explicit user target. Outside a run, continuation remains
+transient conversation state; do not create a global target store or a second run-state owner.
+
+## Fail-Closed States
+
+- `multiple_plausible_targets`: more than one work target remains plausible; list the candidates and
+  request the smallest clarification.
+- `target_content_mismatch`: the requested content change is not supported by the explicit target's
+  observable content; name the mismatch and ask whether the target or requested change should change.
+- `target_unavailable`: the named file, attachment or artefact cannot be inspected; request supply or
+  access and offer a visible retry.
+- `no_reliable_target`: neither an explicit target nor an unambiguous continuation exists; request a
+  target.
+
+These states forbid repository activation, Scope Classification, gate evaluation and mutation.
+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
+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
+result is unresolved. Avoid redundant presentation for an obvious unchanged target. Presentation
+never grants mutation or gate authority.

package/generated/.opencode/AGDF.md

@@ -73,6 +73,7 @@ Never jump directly from `Approval: UR`, implicit consent, or a generic "start"
 ## Runtime Contract
 For repeated output, gate, Quality Contract and Context Graph rules, use:
 
+- `contracts/task-target-resolution.md` for primary target authority before repository activation
 - `contracts/gate-transition.md` for gate terms, Brownfield routing and transition rules
 - `contracts/interaction.md` for status cards, approval orientation and native interaction
 - `contracts/modes.md` for delivery-mode boundaries
@@ -126,3 +127,4 @@ For relevant runs that change durable state, code, artefacts or gate status:
 - An explicit user `permission.question: deny` remains authoritative and selects the exact-text AGDF fallback; never convert an OpenCode permission outcome or auto mode into gate approval.
 - Shared output and gate rules live in `.opencode/agdf-runtime-contract.md`.
 - Do not paste full control files, templates or artefact bodies into chat unless the user explicitly asks for the full content; summarize and link paths instead.
+- OpenCode plugin hooks (`tool.execute.before`) do not intercept tool calls from subagents spawned via the `task` tool (issue #5894, PR #36238 open). AGDF enforcement through plugin hooks applies to primary-agent tool calls only; in the subagent path, AGDF governance is auditing-only. Do not route work to a subagent to bypass a primary-agent gate; verify subagent results through the canonical validator after the subagent returns.

package/generated/.opencode/agdf-interaction-locales.json

@@ -58,6 +58,31 @@
         "escalation": "Escalation triggers",
         "challenge": "Challenge path"
       },
+      "taskTargetResolution": {
+        "title": "AGDF task target",
+        "field": "Field",
+        "value": "Value",
+        "state": "Resolution",
+        "resolved": "Resolved",
+        "unresolved": "Clarification required",
+        "primaryTarget": "Primary target",
+        "governanceTarget": "Governance target",
+        "evidenceSources": "Evidence sources",
+        "workingDirectory": "Working directory",
+        "targetChanged": "Target changed",
+        "yes": "yes",
+        "none": "none",
+        "reason": "Reason",
+        "nextAction": "Next action",
+        "reasonCodes": {
+          "explicit_target": "Explicit current-turn target",
+          "continued_target": "Confirmed target continued",
+          "multiple_plausible_targets": "Multiple plausible work targets",
+          "target_content_mismatch": "Requested change mismatches target",
+          "target_unavailable": "Named target is unavailable",
+          "no_reliable_target": "No reliable work target"
+        }
+      },
       "internalStateLabels": {
         "verifiedChange": "Compact change under review",
         "verifiedChangeEscalated": "Escalated to structured delivery",
@@ -284,6 +309,31 @@
         "escalation": "Eskalationsauslöser",
         "challenge": "Widerspruchspfad"
       },
+      "taskTargetResolution": {
+        "title": "AGDF-Arbeitsziel",
+        "field": "Feld",
+        "value": "Wert",
+        "state": "Auflösung",
+        "resolved": "Aufgelöst",
+        "unresolved": "Klärung erforderlich",
+        "primaryTarget": "Primäres Ziel",
+        "governanceTarget": "Governance-Ziel",
+        "evidenceSources": "Evidenzquellen",
+        "workingDirectory": "Arbeitsordner",
+        "targetChanged": "Ziel gewechselt",
+        "yes": "ja",
+        "none": "keines",
+        "reason": "Grund",
+        "nextAction": "Nächste Aktion",
+        "reasonCodes": {
+          "explicit_target": "Explizites Ziel im aktuellen Turn",
+          "continued_target": "Bestätigtes Ziel wird fortgesetzt",
+          "multiple_plausible_targets": "Mehrere plausible Arbeitsziele",
+          "target_content_mismatch": "Änderung passt nicht zum Zielinhalt",
+          "target_unavailable": "Benanntes Ziel ist nicht verfügbar",
+          "no_reliable_target": "Kein belastbares Arbeitsziel"
+        }
+      },
       "internalStateLabels": {
         "verifiedChange": "Kompakte Änderung wird geprüft",
         "verifiedChangeEscalated": "Eskaliert zu structured delivery",

package/generated/.opencode/agdf-runtime-contract.md

@@ -4,6 +4,7 @@ This manifest indexes the thematic runtime-contract modules used by AGDF skills
 
 | Module | Path | Coverage |
 |---|---|---|
+| Task target resolution | `contracts/task-target-resolution.md` | Primary target authority, evidence/mutation separation, governance derivation, continuation and fail-closed target states |
 | Gate transitions | `contracts/gate-transition.md` | Source precedence, scope ambiguity, gate rules, Brownfield routing and transition model |
 | Interaction | `contracts/interaction.md` | Run Status Card, approval orientation, native interaction and locale contracts |
 | Modes | `contracts/modes.md` | Mode selection, Quick Task, Verified Change, trivial and bug boundaries |

package/generated/.opencode/contracts/gate-transition.md

@@ -93,9 +93,13 @@ Mode/Slice Decision rules:
 
 - `quick_task`: use only when Brownfield Review shows a narrow local change, no new product semantics beyond the approved UR, no architecture/policy/persistence/contract expansion, and evidence is sufficient to proceed with a small implementation plus relevant checks.
 - `verified_change`: use only when the compact record can prove one canonical owner, bounded clean-at-baseline paths, no prohibited impact, deterministic propagation/validation and a structured escalation target. It skips later approvals only after every condition is evidenced and machine-validated.
-- `structured_slice`: use when some formal artefacts are needed, but they can stay intentionally small and scoped to the approved slice.
-- `structured_delivery`: use when the change has broad product, architecture, runtime, policy, persistence, release or cross-owner impact.
-- `block`: use when ownership, SoT, impact, evidence or product direction is not clear enough to choose a safe path.
+- `structured_slice` and `structured_delivery`: apply the sole normative `Structured Depth Decision`
+  in `modes.md`; this contract owns only the operational transition and does not duplicate its
+  trigger or bounded-slice matrix.
+- `block`: use when ownership, SoT, impact, evidence or product direction is not clear enough to
+  choose a safe path. A `depth_unresolved` product result is persisted through this existing value
+  with `depth_facts_missing | depth_facts_conflicting`, a Brownfield Review evidence link and a
+  precise evidence-owner/re-evaluation next action; it never creates a new mode or advances a gate.
 
 A Mode/Slice Decision without scope reason and evidence is not recorded. Treat it as missing and keep the next step at `Mode/Slice Decision`.