create-agdf 0.8.0 → 0.8.2

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

@@ -84,7 +84,7 @@ It must not introduce a second gate model or override `agdf-gate-check`, `delive
 
 - `mode`: `quick_task | verified_change | structured_delivery | unknown`
 - `run_id`: the exactly selected canonical run
-- `presentation_language`: `de | en`, with unsupported or absent chat language resolved to `en`
+- `presentation_language`: the resolved complete locale-pack tag; absent, unsupported or incomplete packs resolve to the registry's deterministic `en` fallback
 - `status`: `open | blocked | pass | warn | revise | block | in_progress`
 - `current_gate`: current user gate or internal step
 - `mode_slice_decision`: `undecided | quick_task | verified_change | structured_slice | structured_delivery | block`
@@ -157,8 +157,9 @@ question or exact-text fallback.
 
 The card answers exactly three user questions, in this order:
 
-1. **Where am I?** A human-readable gate title, selected `run_id` as secondary
-   context and a clear ready-for-decision state.
+1. **Where am I?** A localized human-readable gate title, deterministic human
+   run title, selected `run_id` as secondary context, compact `UR · PRD · SD · TP`
+   artefact links and a clear ready-for-decision state.
 2. **What does this decision do?** The exact `Approval: <GateName>` value, its
    concrete next outcome and the most important boundary that remains.
 3. **What happens next?** The immediate agent-controlled action and the next
@@ -168,7 +169,8 @@ The card answers exactly three user questions, in this order:
 Use this compact composition:
 
 ```text
-<human-readable gate title> · <run_id>
+<localized gate title> · <human run title> · <run_id>
+<UR link or localized missing text> · <PRD link or localized missing text> · <SD link or localized missing text> · <TP link or localized missing text>
 <localized ready-for-decision line>
 
 <localized approve heading>
@@ -178,11 +180,14 @@ Use this compact composition:
 <localized immediate agent action>. <localized next user decision or no-action statement>.
 ```
 
-Resolve all explanatory text through the Interaction Locale Contract. German
-uses the approved German product labels for readiness, approval and the next
-transition; English is the deterministic default for absent or unsupported
-locales. Gate names, `run_id` and exact approval values are never translated.
-The meaning, ordering and authority boundary must be identical across locales.
+Resolve all AGDF-owned explanatory text through the canonical Interaction
+Locale Registry. `en` and `de` are initial reviewed packs, not a closed locale
+list. English is the deterministic fallback for absent, unsupported or
+incomplete packs. Gate identifiers, `run_id`, canonical paths and exact
+approval values are never translated. The visible gate title is localized;
+for example, the German title may be `Lösungsdesign` while the authorization
+value remains `Approval: SD`. Meaning, ordering and authority boundaries are
+identical across locale packs.
 
 The approval-time card must not be a Markdown table or dashboard. It must not
 present raw control-state keys, machine status values, diagnostic codes,
@@ -333,11 +338,13 @@ Every AGDF interaction belongs to exactly one semantic kind:
 - `clarification`: asks for missing intent or a choice that does not itself authorize a gated transition.
 - `tool_permission`: requests host-owned authority for a command, file change, network access, external path, app action or comparable technical side effect.
 - `gate_approval`: requests deliberate user input for the one current AGDF user gate after its durable artefact and selected run are ready.
+- `blocked`: explains a blocker and the one permissible recovery action without offering approval controls.
+- `status`: reports current state without asking for a decision.
 
 The semantic interaction envelope is:
 
 ```text
-interaction_kind: clarification | tool_permission | gate_approval
+interaction_kind: clarification | tool_permission | gate_approval | blocked | status
 surface: codex | claude | opencode | fallback
 run_id: required for gate_approval
 current_gate: required for gate_approval
@@ -364,7 +371,7 @@ Before presenting `gate_approval`, the agent must:
 
 1. resolve exactly one selected run;
 2. run the canonical gate evaluation and confirm that the current gate's durable artefact is present and ready;
-3. emit the separate localized Gate Transition Card immediately before the gate question, then ask exactly one gate question that identifies `run_id` and `current_gate` and offers the exact approving value `Approval: <GateName>` plus bounded revise and cancel/decline outcomes;
+3. emit the separate localized Gate Transition Card immediately before the gate question, then ask exactly one gate question that identifies `run_id` and `current_gate` and offers the exact approving value `Approval: <GateName>` followed by stable `revise` and `decline` outcomes; host-owned dismissal maps to `cancel` where only three choices are available;
 4. wait for deliberate user input without a timeout, default, preselection, hook-supplied answer or agent-to-agent substitute;
 5. re-run canonical gate evaluation against the same `run_id` and expected gate immediately before persistence;
 6. reject missing evidence, ambiguous or wrong run, wrong gate, stale state and any response that is no longer valid;
@@ -375,7 +382,16 @@ host control is presented, or the agent immediately uses the exact-text
 fallback. A host that does not apply the control does not trigger a second
 native prompt. AGDF must not simulate or force host-owned presentation.
 
-A free-form native response is valid only when the existing exact-approval validator accepts it for the current gate after revalidation. Revise, decline and cancel outcomes never advance a gate.
+An eligible interaction must make its presentation outcome visible and
+distinguishable: `presented`, `unavailable_before_invocation`,
+`attempted_not_applied`, or `unsafe_to_wait`. This is transient presentation
+evidence only, never a persisted approval, selected-run authority or substitute
+for post-response revalidation. A textual fallback names the outcome, gives the
+exact approval value and confirms that authority is unchanged. A fresh explicit
+user request may reopen the unchanged decision after revalidation; it is not an
+automatic retry.
+
+A free-form native response is valid only when the existing exact-approval validator accepts it for the current gate after revalidation. A localized label, description, option position, recommendation style or host action never authorizes a gate. Revise, decline and cancel outcomes never advance a gate.
 
 Surface adapter rules:
 
@@ -392,18 +408,63 @@ Exact textual approvals remain canonical and fully supported on every surface. I
 
 ### Interaction Locale Contract
 
-User-facing native questions, option descriptions and exact-text fallback explanations use the configured project chat language from `.agdf/control/config.json`:
+User-facing native questions, option descriptions, primary chat cards, exact-text
+fallback and human CLI output use the configured project chat language from
+`.agdf/control/config.json` and the canonical registry
+`agdf-interaction-locales.json`:
 
-- `chat_language: de` selects the German presentation copy;
-- `chat_language: en` selects English presentation copy;
-- an absent, unsupported or not-yet-translated chat language falls back deterministically to English;
-- one question must not mix presentation languages;
+- resolve an exact complete pack, then its language subtag, then deterministic English fallback;
+- `en` and `de` are the initial complete packs; additional reviewed complete packs are supported without changing runtime logic;
+- an incomplete pack is unsupported and must fail to English as a unit;
+- one interaction must not mix presentation languages, including labels and descriptions;
 - durable artefacts, runtime rules, task identifiers and machine-facing approval values remain English;
 - the exact approval value remains `Approval: <GateName>` in every locale;
-- localized `revise`, `decline` and `cancel` labels are presentation text only and never carry gate authority.
+- localized `revise`, `decline` and `cancel` labels are presentation text only and never carry gate authority;
+- host-owned chrome follows the host's own UI language and must not be presented as AGDF-translated chat copy.
 
 The locale changes presentation only. It must not change gate meaning, option ordering, readiness, validation, revalidation or persistence. Host-provided free-text labels and skip actions are not AGDF-owned approval options and must never advance a gate.
 
+### Human Decision Presentation Contract
+
+The primary user surface is a pure projection of the selected canonical run.
+It must never become a second evaluator, state store, renderer authority or
+approval path. Native controls, exact-text fallback and human CLI output use
+the same semantic payload and outcome ordering; machine JSON retains its
+stable field names and diagnostic values.
+
+For every primary chat card:
+
+1. Resolve a human run title deterministically from the current artefact
+   heading, approved UR heading, first non-empty Objective line, then normalized
+   `run_id`.
+2. Show `UR · PRD · SD · TP` in that stable order. Existing selected-run
+   artefacts are links with readable labels; missing artefacts use localized
+   non-link text. Never guess a path or emit a broken link.
+3. Use a localized visible gate title while preserving the exact gate identifier
+   and `Approval: <GateName>` authorization value.
+4. Keep primary copy decision-oriented. Raw keys such as `next_user_gate`,
+   `mode_slice_decision` and `required_next_gate`, diagnostic codes and machine
+   status values belong to JSON or audit detail, not the primary interaction.
+
+For a ready approval, explicit options are ordered `approve`, `revise`,
+`decline`; an explicit `cancel` follows only on surfaces that support it, while
+host dismissal maps to `cancel` on three-choice surfaces. Do not preselect,
+auto-submit, recommend as authorization, skip or reorder an option. Labels and
+descriptions use the same resolved locale and must have distinct, non-empty
+accessible names. Translation length budgets must preserve meaning without
+truncation being the only distinction.
+
+Normalize outcomes as distinct values:
+
+```text
+approve | revise | decline | cancel | no_response | timeout | empty | invalid | stale
+```
+
+Missing input, timeout, cancellation and empty input are not decline. Only
+`approve` backed by the exact revalidated `Approval: <GateName>` value may
+advance a gate. Clarification, blocked, internal-step and status-only
+interactions must not display gate-approval controls.
+
 ## Brownfield Review After G-00
 
 After an approved and durable UR, perform a lightweight `Brownfield Review` before PRD when Brownfield, UI, UX, admin, runtime, policy, persistence, architecture, ownership or source-of-truth impact is possible.

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

@@ -0,0 +1,184 @@
+{
+  "schemaVersion": 1,
+  "fallbackLocale": "en",
+  "optionOrder": ["approve", "revise", "decline", "cancel"],
+  "lengthBudgets": {
+    "label": 40,
+    "description": 160,
+    "title": 100
+  },
+  "locales": {
+    "en": {
+      "statusCard": {
+        "title": "AGDF status-card",
+        "run": "Selected run",
+        "humanTitle": "Run title",
+        "gate": "Current gate",
+        "blocked": "Blocked by",
+        "missing": "Missing approval",
+        "outcome": "Outcome after approval",
+        "internal": "Internal next step",
+        "userGate": "Next user gate",
+        "userAction": "User action required",
+        "nextGate": "Next gate after approval",
+        "allowedAfter": "Allowed after approval",
+        "skill": "Next skill",
+        "step": "Next step",
+        "quality": "Quality outlook",
+        "allowed": "Allowed now",
+        "forbidden": "Forbidden now",
+        "artefacts": "Artefacts"
+      },
+      "gateTitles": {
+        "UR": "User requirements",
+        "PRD": "Product requirements",
+        "SD": "Solution design",
+        "TP": "Task and test plan",
+        "QA": "Quality assurance",
+        "UAT": "User acceptance",
+        "Brownfield Review": "Brownfield review",
+        "Mode/Slice Decision": "Delivery scope decision",
+        "Brownfield Analysis": "Implementation preparation",
+        "CD+Tests": "Implementation and tests",
+        "CR": "Code review",
+        "OR": "Delivery report"
+      },
+      "interaction": {
+        "ready": "Ready for your decision",
+        "approveHeading": "Approve now",
+        "nextHeading": "Next",
+        "approveDescription": "Approve this gate with the exact authorization value.",
+        "reviseLabel": "Revise",
+        "reviseDescription": "Keep the gate open and request changes.",
+        "declineLabel": "Decline",
+        "declineDescription": "Reject this gate deliberately; authority remains unchanged.",
+        "cancelLabel": "Cancel",
+        "cancelDescription": "Close this decision without approving or declining it."
+      },
+      "artefacts": {
+        "notYetCreated": "not yet created"
+      },
+      "primary": {
+        "status": {
+          "open": "open",
+          "blocked": "blocked",
+          "pass": "passed",
+          "warn": "attention needed",
+          "revise": "revision needed",
+          "in_progress": "in progress"
+        },
+        "none": "none",
+        "blocked": "current gate prerequisites",
+        "quality": "Keep the presentation contract, evidence and gate authority aligned.",
+        "actions": {
+          "UR": "Clarify and approve the user requirements.",
+          "Brownfield Review": "Review existing owners and choose the smallest safe delivery path.",
+          "Mode/Slice Decision": "Decide the proportionate delivery scope from repository evidence.",
+          "PRD": "Define and approve the product behavior.",
+          "SD": "Define and approve the solution design.",
+          "TP": "Define and approve the task and test plan.",
+          "Brownfield Analysis": "Verify owners, reuse and regression coverage before implementation.",
+          "CD+Tests": "Implement the approved plan and collect test evidence.",
+          "CR": "Review the implementation and resolve blocking findings.",
+          "QA": "Evaluate quality evidence and make the QA decision.",
+          "UAT": "Make the deliberate user-acceptance decision.",
+          "OR": "Prepare the auditable delivery report."
+        },
+        "afterApproval": {
+          "UR": "Review existing owners and choose the proportionate delivery path; implementation remains blocked.",
+          "PRD": "Draft the solution design; implementation remains blocked.",
+          "SD": "Draft the task and test plan; implementation remains blocked.",
+          "TP": "Run pre-implementation Brownfield Analysis; implementation starts only if it passes.",
+          "QA": "Prepare the user-acceptance decision; release remains blocked.",
+          "UAT": "Prepare the delivery report; version-control and release actions still require explicit instruction."
+        }
+      }
+    },
+    "de": {
+      "statusCard": {
+        "title": "AGDF-Statuskarte",
+        "run": "Ausgewählter Run",
+        "humanTitle": "Run-Titel",
+        "gate": "Aktuelles Gate",
+        "blocked": "Blockiert durch",
+        "missing": "Fehlende Freigabe",
+        "outcome": "Ergebnis nach Freigabe",
+        "internal": "Interner nächster Schritt",
+        "userGate": "Nächstes User-Gate",
+        "userAction": "Nutzeraktion erforderlich",
+        "nextGate": "Nächstes Gate nach Freigabe",
+        "allowedAfter": "Nach Freigabe erlaubt",
+        "skill": "Nächster Skill",
+        "step": "Nächster Schritt",
+        "quality": "Qualitätsausblick",
+        "allowed": "Jetzt erlaubt",
+        "forbidden": "Aktuell verboten",
+        "artefacts": "Artefakte"
+      },
+      "gateTitles": {
+        "UR": "Nutzeranforderungen",
+        "PRD": "Produktanforderungen",
+        "SD": "Lösungsdesign",
+        "TP": "Aufgaben- und Testplan",
+        "QA": "Qualitätssicherung",
+        "UAT": "Nutzerabnahme",
+        "Brownfield Review": "Brownfield-Prüfung",
+        "Mode/Slice Decision": "Entscheidung zum Lieferumfang",
+        "Brownfield Analysis": "Implementierungsvorbereitung",
+        "CD+Tests": "Implementierung und Tests",
+        "CR": "Code-Review",
+        "OR": "Lieferbericht"
+      },
+      "interaction": {
+        "ready": "Bereit für deine Entscheidung",
+        "approveHeading": "Jetzt freigeben",
+        "nextHeading": "Danach",
+        "approveDescription": "Dieses Gate mit dem exakten Freigabewert autorisieren.",
+        "reviseLabel": "Überarbeiten",
+        "reviseDescription": "Das Gate offen lassen und Änderungen anfordern.",
+        "declineLabel": "Ablehnen",
+        "declineDescription": "Dieses Gate bewusst ablehnen; die Berechtigung bleibt unverändert.",
+        "cancelLabel": "Abbrechen",
+        "cancelDescription": "Diese Entscheidung ohne Freigabe oder Ablehnung schließen."
+      },
+      "artefacts": {
+        "notYetCreated": "noch nicht erstellt"
+      },
+      "primary": {
+        "status": {
+          "open": "offen",
+          "blocked": "blockiert",
+          "pass": "bestanden",
+          "warn": "Prüfung erforderlich",
+          "revise": "Überarbeitung erforderlich",
+          "in_progress": "in Arbeit"
+        },
+        "none": "keine",
+        "blocked": "Voraussetzungen des aktuellen Gates",
+        "quality": "Präsentationsvertrag, Nachweise und Gate-Berechtigung konsistent halten.",
+        "actions": {
+          "UR": "Nutzeranforderungen klären und freigeben.",
+          "Brownfield Review": "Bestehende Owner prüfen und den kleinsten sicheren Lieferweg wählen.",
+          "Mode/Slice Decision": "Den angemessenen Lieferumfang anhand der Repository-Nachweise festlegen.",
+          "PRD": "Produktverhalten definieren und freigeben.",
+          "SD": "Lösungsdesign definieren und freigeben.",
+          "TP": "Aufgaben- und Testplan definieren und freigeben.",
+          "Brownfield Analysis": "Owner, Wiederverwendung und Regressionstests vor der Implementierung prüfen.",
+          "CD+Tests": "Den freigegebenen Plan implementieren und Testnachweise sammeln.",
+          "CR": "Implementierung prüfen und blockierende Befunde beheben.",
+          "QA": "Qualitätsnachweise bewerten und die QA-Entscheidung treffen.",
+          "UAT": "Die bewusste Nutzerabnahme entscheiden.",
+          "OR": "Den auditierbaren Lieferbericht erstellen."
+        },
+        "afterApproval": {
+          "UR": "Bestehende Owner prüfen und den angemessenen Lieferweg wählen; die Implementierung bleibt gesperrt.",
+          "PRD": "Das Lösungsdesign entwerfen; die Implementierung bleibt gesperrt.",
+          "SD": "Den Aufgaben- und Testplan entwerfen; die Implementierung bleibt gesperrt.",
+          "TP": "Die Brownfield-Analyse vor der Implementierung durchführen; die Implementierung startet nur nach bestandenem Ergebnis.",
+          "QA": "Die Nutzerabnahme vorbereiten; die Veröffentlichung bleibt gesperrt.",
+          "UAT": "Den Lieferbericht vorbereiten; Versionskontroll- und Veröffentlichungsaktionen benötigen weiterhin eine ausdrückliche Anweisung."
+        }
+      }
+    }
+  }
+}

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

@@ -84,7 +84,7 @@ It must not introduce a second gate model or override `agdf-gate-check`, `delive
 
 - `mode`: `quick_task | verified_change | structured_delivery | unknown`
 - `run_id`: the exactly selected canonical run
-- `presentation_language`: `de | en`, with unsupported or absent chat language resolved to `en`
+- `presentation_language`: the resolved complete locale-pack tag; absent, unsupported or incomplete packs resolve to the registry's deterministic `en` fallback
 - `status`: `open | blocked | pass | warn | revise | block | in_progress`
 - `current_gate`: current user gate or internal step
 - `mode_slice_decision`: `undecided | quick_task | verified_change | structured_slice | structured_delivery | block`
@@ -157,8 +157,9 @@ question or exact-text fallback.
 
 The card answers exactly three user questions, in this order:
 
-1. **Where am I?** A human-readable gate title, selected `run_id` as secondary
-   context and a clear ready-for-decision state.
+1. **Where am I?** A localized human-readable gate title, deterministic human
+   run title, selected `run_id` as secondary context, compact `UR · PRD · SD · TP`
+   artefact links and a clear ready-for-decision state.
 2. **What does this decision do?** The exact `Approval: <GateName>` value, its
    concrete next outcome and the most important boundary that remains.
 3. **What happens next?** The immediate agent-controlled action and the next
@@ -168,7 +169,8 @@ The card answers exactly three user questions, in this order:
 Use this compact composition:
 
 ```text
-<human-readable gate title> · <run_id>
+<localized gate title> · <human run title> · <run_id>
+<UR link or localized missing text> · <PRD link or localized missing text> · <SD link or localized missing text> · <TP link or localized missing text>
 <localized ready-for-decision line>
 
 <localized approve heading>
@@ -178,11 +180,14 @@ Use this compact composition:
 <localized immediate agent action>. <localized next user decision or no-action statement>.
 ```
 
-Resolve all explanatory text through the Interaction Locale Contract. German
-uses the approved German product labels for readiness, approval and the next
-transition; English is the deterministic default for absent or unsupported
-locales. Gate names, `run_id` and exact approval values are never translated.
-The meaning, ordering and authority boundary must be identical across locales.
+Resolve all AGDF-owned explanatory text through the canonical Interaction
+Locale Registry. `en` and `de` are initial reviewed packs, not a closed locale
+list. English is the deterministic fallback for absent, unsupported or
+incomplete packs. Gate identifiers, `run_id`, canonical paths and exact
+approval values are never translated. The visible gate title is localized;
+for example, the German title may be `Lösungsdesign` while the authorization
+value remains `Approval: SD`. Meaning, ordering and authority boundaries are
+identical across locale packs.
 
 The approval-time card must not be a Markdown table or dashboard. It must not
 present raw control-state keys, machine status values, diagnostic codes,
@@ -333,11 +338,13 @@ Every AGDF interaction belongs to exactly one semantic kind:
 - `clarification`: asks for missing intent or a choice that does not itself authorize a gated transition.
 - `tool_permission`: requests host-owned authority for a command, file change, network access, external path, app action or comparable technical side effect.
 - `gate_approval`: requests deliberate user input for the one current AGDF user gate after its durable artefact and selected run are ready.
+- `blocked`: explains a blocker and the one permissible recovery action without offering approval controls.
+- `status`: reports current state without asking for a decision.
 
 The semantic interaction envelope is:
 
 ```text
-interaction_kind: clarification | tool_permission | gate_approval
+interaction_kind: clarification | tool_permission | gate_approval | blocked | status
 surface: codex | claude | opencode | fallback
 run_id: required for gate_approval
 current_gate: required for gate_approval
@@ -364,7 +371,7 @@ Before presenting `gate_approval`, the agent must:
 
 1. resolve exactly one selected run;
 2. run the canonical gate evaluation and confirm that the current gate's durable artefact is present and ready;
-3. emit the separate localized Gate Transition Card immediately before the gate question, then ask exactly one gate question that identifies `run_id` and `current_gate` and offers the exact approving value `Approval: <GateName>` plus bounded revise and cancel/decline outcomes;
+3. emit the separate localized Gate Transition Card immediately before the gate question, then ask exactly one gate question that identifies `run_id` and `current_gate` and offers the exact approving value `Approval: <GateName>` followed by stable `revise` and `decline` outcomes; host-owned dismissal maps to `cancel` where only three choices are available;
 4. wait for deliberate user input without a timeout, default, preselection, hook-supplied answer or agent-to-agent substitute;
 5. re-run canonical gate evaluation against the same `run_id` and expected gate immediately before persistence;
 6. reject missing evidence, ambiguous or wrong run, wrong gate, stale state and any response that is no longer valid;
@@ -375,7 +382,16 @@ host control is presented, or the agent immediately uses the exact-text
 fallback. A host that does not apply the control does not trigger a second
 native prompt. AGDF must not simulate or force host-owned presentation.
 
-A free-form native response is valid only when the existing exact-approval validator accepts it for the current gate after revalidation. Revise, decline and cancel outcomes never advance a gate.
+An eligible interaction must make its presentation outcome visible and
+distinguishable: `presented`, `unavailable_before_invocation`,
+`attempted_not_applied`, or `unsafe_to_wait`. This is transient presentation
+evidence only, never a persisted approval, selected-run authority or substitute
+for post-response revalidation. A textual fallback names the outcome, gives the
+exact approval value and confirms that authority is unchanged. A fresh explicit
+user request may reopen the unchanged decision after revalidation; it is not an
+automatic retry.
+
+A free-form native response is valid only when the existing exact-approval validator accepts it for the current gate after revalidation. A localized label, description, option position, recommendation style or host action never authorizes a gate. Revise, decline and cancel outcomes never advance a gate.
 
 Surface adapter rules:
 
@@ -392,18 +408,63 @@ Exact textual approvals remain canonical and fully supported on every surface. I
 
 ### Interaction Locale Contract
 
-User-facing native questions, option descriptions and exact-text fallback explanations use the configured project chat language from `.agdf/control/config.json`:
+User-facing native questions, option descriptions, primary chat cards, exact-text
+fallback and human CLI output use the configured project chat language from
+`.agdf/control/config.json` and the canonical registry
+`agdf-interaction-locales.json`:
 
-- `chat_language: de` selects the German presentation copy;
-- `chat_language: en` selects English presentation copy;
-- an absent, unsupported or not-yet-translated chat language falls back deterministically to English;
-- one question must not mix presentation languages;
+- resolve an exact complete pack, then its language subtag, then deterministic English fallback;
+- `en` and `de` are the initial complete packs; additional reviewed complete packs are supported without changing runtime logic;
+- an incomplete pack is unsupported and must fail to English as a unit;
+- one interaction must not mix presentation languages, including labels and descriptions;
 - durable artefacts, runtime rules, task identifiers and machine-facing approval values remain English;
 - the exact approval value remains `Approval: <GateName>` in every locale;
-- localized `revise`, `decline` and `cancel` labels are presentation text only and never carry gate authority.
+- localized `revise`, `decline` and `cancel` labels are presentation text only and never carry gate authority;
+- host-owned chrome follows the host's own UI language and must not be presented as AGDF-translated chat copy.
 
 The locale changes presentation only. It must not change gate meaning, option ordering, readiness, validation, revalidation or persistence. Host-provided free-text labels and skip actions are not AGDF-owned approval options and must never advance a gate.
 
+### Human Decision Presentation Contract
+
+The primary user surface is a pure projection of the selected canonical run.
+It must never become a second evaluator, state store, renderer authority or
+approval path. Native controls, exact-text fallback and human CLI output use
+the same semantic payload and outcome ordering; machine JSON retains its
+stable field names and diagnostic values.
+
+For every primary chat card:
+
+1. Resolve a human run title deterministically from the current artefact
+   heading, approved UR heading, first non-empty Objective line, then normalized
+   `run_id`.
+2. Show `UR · PRD · SD · TP` in that stable order. Existing selected-run
+   artefacts are links with readable labels; missing artefacts use localized
+   non-link text. Never guess a path or emit a broken link.
+3. Use a localized visible gate title while preserving the exact gate identifier
+   and `Approval: <GateName>` authorization value.
+4. Keep primary copy decision-oriented. Raw keys such as `next_user_gate`,
+   `mode_slice_decision` and `required_next_gate`, diagnostic codes and machine
+   status values belong to JSON or audit detail, not the primary interaction.
+
+For a ready approval, explicit options are ordered `approve`, `revise`,
+`decline`; an explicit `cancel` follows only on surfaces that support it, while
+host dismissal maps to `cancel` on three-choice surfaces. Do not preselect,
+auto-submit, recommend as authorization, skip or reorder an option. Labels and
+descriptions use the same resolved locale and must have distinct, non-empty
+accessible names. Translation length budgets must preserve meaning without
+truncation being the only distinction.
+
+Normalize outcomes as distinct values:
+
+```text
+approve | revise | decline | cancel | no_response | timeout | empty | invalid | stale
+```
+
+Missing input, timeout, cancellation and empty input are not decline. Only
+`approve` backed by the exact revalidated `Approval: <GateName>` value may
+advance a gate. Clarification, blocked, internal-step and status-only
+interactions must not display gate-approval controls.
+
 ## Brownfield Review After G-00
 
 After an approved and durable UR, perform a lightweight `Brownfield Review` before PRD when Brownfield, UI, UX, admin, runtime, policy, persistence, architecture, ownership or source-of-truth impact is possible.

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

@@ -54,7 +54,7 @@ The CLI reports are validators and JSON evidence, not the primary user experienc
 
 ## Native Interaction Path
 
-Use the Runtime Contract's Native Interaction Contract to classify every candidate interaction as `clarification`, `tool_permission` or `gate_approval` before selecting a host control.
+Use the Runtime Contract's Native Interaction Contract to classify every candidate interaction as `clarification`, `tool_permission`, `gate_approval`, `blocked` or `status` before selecting a host control.
 
 Prefer inspection over asking. Do not invoke a structured question for status reporting, facts available in the repository, routine read-only work or a gate that is not ready. Do not repeatedly prompt for the same non-ready gate.
 
@@ -62,20 +62,20 @@ For a ready `gate_approval`:
 
 1. Resolve exactly one selected run and evaluate the current gate.
 2. Confirm the required durable artefact is present and ready before presenting a question.
-3. Render a separate localized Gate Transition Card immediately before any native question or exact-text fallback. Never put the card only into the question, button description or hidden tool context.
+3. Render a separate localized Gate Transition Card immediately before any native question or exact-text fallback. It includes the deterministic human run title and `UR · PRD · SD · TP` links from the selected run. Never put the card only into the question, button description or hidden tool context.
 4. Treat the operational Run Status Card as evaluation and audit input, not as the approval-time product surface. Do not paste its table, raw keys, machine statuses, evidence or diagnostic detail into the transition card.
 5. Compose the transition card as one human-readable gate title with `run_id`, one ready-for-decision line, one short approval-effect block and one short next-transition block. It must answer only: where am I, what does this decision do, and what happens next.
 6. Distinguish internal process steps from user decisions in natural language. For example, after `Approval: TP`, say that pre-implementation Brownfield Analysis runs next and that no further user action is required now; do not expose `next_user_gate: none` or `user_action_required: no`, and do not ask for a second approval for Brownfield Analysis.
 7. Ask exactly one question that names the selected `run_id` and `current_gate`.
-8. Offer the exact approving option `Approval: <GateName>` plus bounded revise and cancel/decline outcomes.
+8. Offer options in stable order: exact `Approval: <GateName>`, localized revise and localized decline. Add explicit cancel only where supported after decline; otherwise host dismissal maps to cancel. Never preselect, skip, auto-submit or reorder an option.
 9. Use the surface adapter declared in the canonical plugin definition only when it can wait for deliberate input without auto-resolution; otherwise request the same exact approval in concise text.
 10. Re-run gate evaluation for the same run and expected gate after the response and immediately before persistence.
 11. Reject a missing artefact, ambiguous or wrong run, wrong gate, stale expected gate, timeout/default, hook-supplied answer, agent message, technical permission outcome or plan approval.
 12. Persist accepted input only through the existing control-state workflow.
 
-Before composing the question, resolve the configured chat locale from `.agdf/control/config.json`. Use German presentation text for `chat_language: de`; use English for `chat_language: en` or as the deterministic fallback for an absent or unsupported locale. Keep `Approval: <GateName>` exactly unchanged in every language, and do not mix presentation languages within one question.
+Before composing the question, resolve the configured chat locale from `.agdf/control/config.json` through `../../agdf-interaction-locales.json`: exact complete pack, language subtag, then English fallback. German and English are initial packs, not a closed language list. Keep `Approval: <GateName>` exactly unchanged in every language, and do not mix presentation languages within one interaction. Labels and descriptions use the same resolved locale; host-owned UI chrome remains host-owned and may use a different language.
 
-For the transition card, German uses `Bereit für deine Entscheidung`, `Jetzt freigeben` and `Danach`; English uses `Ready for your decision`, `Approve now` and `Next`. Keep each card in one locale. Use a human-readable gate title rather than an internal status label. Do not render a Markdown table, dashboard rows, raw control-state keys, diagnostic codes, evidence lists, a duplicated gate question or a false user gate in the approval-time card.
+For the transition card, use the complete resolved locale pack. The initial German pack includes `Bereit für deine Entscheidung`, `Jetzt freigeben` and `Danach`; the initial English pack includes `Ready for your decision`, `Approve now` and `Next`. Keep each card in one locale. Use a localized human-readable gate title rather than an internal status label, while leaving the exact gate identifier and approval value unchanged. Do not render a Markdown table, dashboard rows, raw control-state keys, diagnostic codes, evidence lists, a duplicated gate question or a false user gate in the approval-time card.
 
 The primary option remains exactly `Approval: SD`; only explanatory copy and non-authoritative outcome labels are localized. Concrete localized copy belongs to the user-facing interaction layer or the approved delivery artefact, not to English runtime rules.
 
@@ -84,6 +84,13 @@ apply or safely return the native question on that attempt, switch immediately
 to the exact textual approval. Do not ask the user to request the buttons again
 and do not create a retry loop or simulated control.
 
+State the outcome visibly: `presented`, `unavailable_before_invocation`,
+`attempted_not_applied` or `unsafe_to_wait`. For every fallback, say in the
+configured locale why a native control was not usable, show the exact approval
+value and confirm that authority is unchanged. This transient outcome is not
+approval evidence. A new explicit user request may reopen the unchanged decision
+only after fresh run/gate/artefact revalidation; never retry automatically.
+
 Surface behavior:
 
 - Codex: invoke the native short-question/request-user-input control on the first eligible attempt when callable, ask one gate question and omit auto-resolution; if it is not rendered or applied, use exact text immediately.
@@ -91,9 +98,11 @@ Surface behavior:
 - OpenCode: use built-in `question` when permitted. Preserve explicit `permission.question` denial and use exact text in that case. `once`, `always`, `reject` and auto mode never become gate input.
 - Other, unavailable or non-interactive surfaces: use exact textual approval and wait for a new explicit user response.
 
-Localized labels such as `Überarbeiten`/`Revise`, `Ablehnen`/`Decline` and `Abbrechen`/`Cancel` are presentation mappings to stable non-approval outcomes only. Host-provided free-text or `Überspringen`/`Skip` actions never advance an AGDF gate.
+Localized labels such as `Überarbeiten`/`Revise`, `Ablehnen`/`Decline` and `Abbrechen`/`Cancel` are presentation mappings to stable non-approval outcomes only. A label, description, option position or recommendation never authorizes a gate. Host-provided free-text or `Überspringen`/`Skip` actions never advance an AGDF gate.
+
+A free-form response must still exactly match the current gate's approval formula after revalidation. Keep `decline`, `cancel`, `no_response`, `timeout`, `empty`, `invalid` and `stale` distinct; none advances the gate. Native presentation, host permission and plan approval are inputs or separate authority domains, never durable AGDF authority.
 
-A free-form response must still exactly match the current gate's approval formula after revalidation. Revise, decline and cancel never advance the gate. Native presentation, host permission and plan approval are inputs or separate authority domains, never durable AGDF authority.
+Every primary chat card shows the selected run's `UR`, `PRD`, `SD` and `TP` in that order. Render an existing canonical path as a readable link and a missing artefact as localized non-link text; never guess paths. Resolve the human run title from current artefact heading, approved UR heading, Objective, then normalized `run_id`. Status, blocked, clarification and internal-step interactions use the same locale and artefact projection but do not show approval buttons. Keep raw process keys and machine status values in JSON or audit detail.
 
 ## Rules
 1. Fail closed when a required approval or artefact status is missing.

package/generated/plugins/agdf/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agdf",
-  "version": "0.8.0",
+  "version": "0.8.2",
   "description": "Codex-first operating system for governed AI-assisted delivery.",
   "author": {
     "name": "Arndt Gold",