create-agdf 0.7.3 → 0.8.1

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

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

package/generated/plugins/agdf/meta/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/plugins/agdf/meta/agdf-plugin.definition.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
   "id": "agdf",
-  "version": "0.7.3",
+  "version": "0.8.1",
   "displayName": "AI Governance & Delivery Framework",
   "developerName": "Arndt Gold",
   "description": "Codex-first operating system for governed AI-assisted delivery.",
@@ -67,29 +67,72 @@
   },
   "interactions": {
     "fallback": "exact_text",
+    "localeRegistry": "meta/agdf-interaction-locales.json",
+    "fallbackLocale": "en",
+    "optionOrder": [
+      "approve",
+      "revise",
+      "decline",
+      "cancel"
+    ],
+    "outcomes": [
+      "approve",
+      "revise",
+      "decline",
+      "cancel",
+      "no_response",
+      "timeout",
+      "empty",
+      "invalid",
+      "stale"
+    ],
     "surfaces": {
       "codex": {
         "questionAdapter": "request_user_input",
         "availability": "when_callable",
         "gateSafety": "omit_auto_resolution",
+        "explicitOutcomes": [
+          "approve",
+          "revise",
+          "decline"
+        ],
+        "dismissOutcome": "cancel",
         "technicalPermissionOwner": "codex_host"
       },
       "claude": {
         "questionAdapter": "AskUserQuestion",
         "availability": "when_no_auto_continue_timeout",
         "gateSafety": "no_timeout_or_hook_supplied_answer",
+        "explicitOutcomes": [
+          "approve",
+          "revise",
+          "decline"
+        ],
+        "dismissOutcome": "cancel",
         "technicalPermissionOwner": "claude_host"
       },
       "opencode": {
         "questionAdapter": "question",
         "availability": "when_permission_question_allows",
         "gateSafety": "preserve_explicit_deny",
+        "explicitOutcomes": [
+          "approve",
+          "revise",
+          "decline"
+        ],
+        "dismissOutcome": "cancel",
         "technicalPermissionOwner": "opencode_host"
       },
       "fallback": {
         "questionAdapter": "exact_text",
         "availability": "always",
         "gateSafety": "wait_for_deliberate_user_input",
+        "explicitOutcomes": [
+          "approve",
+          "revise",
+          "decline",
+          "cancel"
+        ],
         "technicalPermissionOwner": "host_specific"
       }
     }

package/generated/plugins/agdf/meta/agdf-runtime-contract.md

@@ -83,6 +83,8 @@ When a run needs an operational status view, use the Run Status Card as a compac
 It must not introduce a second gate model or override `gate-check`, `delivery-map`, QA, OR, or user approvals.
 
 - `mode`: `quick_task | verified_change | structured_delivery | unknown`
+- `run_id`: the exactly selected canonical run
+- `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`
@@ -92,6 +94,10 @@ It must not introduce a second gate model or override `gate-check`, `delivery-ma
 - `missing_approval`: exact missing approval formula or `none`
 - `next_gate_after_approval`: the next user gate or internal step unlocked by the missing approval, or `none`
 - `allowed_after_approval`: concise description of what becomes allowed after the missing approval, or `none`
+- `user_visible_outcome_after_approval`: concise user-facing result of approving the current gate
+- `internal_next_step`: the next agent-controlled process step, or `none`
+- `next_user_gate`: the next actual user approval gate, or `none`
+- `user_action_required`: `yes` only when the user must provide another deliberate approval or decision; otherwise `no`
 - `evidence`: concrete evidence references currently visible
 - `next_skill`: next AGDF skill or `none`
 - `next_step`: the single next permissible process action
@@ -139,6 +145,61 @@ and `Allowed after approval` when a missing approval exists, `Next step` and
 `Quality outlook`. Keep mode, forbidden actions, evidence and next-skill detail
 in the surrounding control artefact when they are relevant.
 
+## Gate Transition Card
+
+The Gate Transition Card is the primary user-facing orientation message for a
+ready `gate_approval`. It is derived from the Run Status Card and canonical
+post-approval transition, but it is not another state model, persisted record,
+renderer or approval authority. The Run Status Card remains the operational,
+CLI and audit projection; the Gate Transition Card turns only the decision-
+relevant subset into concise product copy immediately before the host-native
+question or exact-text fallback.
+
+The card answers exactly three user questions, in this order:
+
+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
+   actual user decision when one exists; otherwise a plain statement that no
+   further user action is required now.
+
+Use this compact composition:
+
+```text
+<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>
+`Approval: <GateName>` <localized concrete effect>. <localized remaining boundary>.
+
+<localized next heading>
+<localized immediate agent action>. <localized next user decision or no-action statement>.
+```
+
+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,
+evidence lists, allowed/forbidden inventories or implementation detail that is
+not needed for the decision. It must not repeat the native question. The card
+normally fits in one title, one readiness line and two short content blocks.
+
+For `Approval: TP`, the effect is permission to run pre-implementation
+Brownfield Analysis, implementation remains gated until that analysis passes,
+and the next block states plainly that no further user decision is required
+now. Brownfield Analysis must not be presented as a user gate.
+
 ## Source Precedence
 
 Every governed repository should make the normative instruction source visible.
@@ -277,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
@@ -295,11 +358,20 @@ response_origin: deliberate_user_input for gate_approval
 
 This envelope is not a new persisted record. The selected canonical `RUN_STATE.md` and existing artefact chain remain the durable authority.
 
+Before presenting `gate_approval` for any user gate (`UR`, `PRD`, `SD`, `TP`,
+`QA`, or `UAT`), the agent must emit the localized Gate Transition Card as a
+separate, immediately preceding interaction block. The card is not optional,
+not hidden in the question text and not replaced by a host button label.
+Native buttons or exact-text fallback may appear only after this card. The
+underlying Run Status Card fields remain available to evaluation and audit,
+but their dashboard projection must not be pasted into this approval-time
+message.
+
 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. 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;
@@ -310,7 +382,7 @@ 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.
+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:
 
@@ -325,6 +397,65 @@ Native structured questions are for real decision points. Prefer repository insp
 
 Exact textual approvals remain canonical and fully supported on every surface. If native capability availability or safety is unknown, use the textual fallback. Host permission, plan approval, native question presentation, timeout/default behavior, hook output and agent messages never carry AGDF gate authority by themselves.
 
+### Interaction Locale Contract
+
+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
+`plugin/meta/agdf-interaction-locales.json`:
+
+- 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;
+- 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/plugins/agdf/skills/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,12 +62,22 @@ 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. Ask exactly one question that names the selected `run_id` and `current_gate`.
-4. Offer the exact approving option `Approval: <GateName>` plus bounded revise and cancel/decline outcomes.
-5. 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.
-6. Re-run gate evaluation for the same run and expected gate after the response and immediately before persistence.
-7. 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.
-8. Persist accepted input only through the existing control-state workflow.
+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 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` through `plugin/meta/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, 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.
 
 Make exactly one native-attempt for the ready gate. If the host does not render,
 apply or safely return the native question on that attempt, switch immediately
@@ -81,7 +91,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.
 
-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.
+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.
+
+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.
@@ -170,6 +184,11 @@ Keep the result short and operational. Render the Runtime Contract's compact hum
 
 When an approval is missing, also include `Next gate after approval` and `Allowed after approval` exactly as constrained by the Runtime Contract. Keep forbidden outputs, evidence and next-skill detail in the concise surrounding text when relevant; they are not extra status-card rows.
 
+This operational status table is for status reporting. When the same response
+immediately requests a ready gate approval, replace the table in the visible
+approval experience with the Gate Transition Card defined above, then invoke
+the native question or exact-text fallback. Do not show both cards.
+
 If this skill creates or updates control artefacts, do not paste full file bodies into the chat.
 List paths, summarize the decision, name the blocker or approval needed, and keep the durable content in the files.
 

package/lib/control-state/gate-approval-validator.js

@@ -0,0 +1,49 @@
+import { normalizeInteractionOutcome } from "../interaction-presentation.js";
+
+export function validateGateApprovalResponse({
+  response,
+  responseOutcome,
+  responseOrigin,
+  expectedApproval,
+  expectedRunId,
+  currentRunId,
+  expectedGate,
+  currentGate,
+  expectedRevisionId,
+  currentRevisionId,
+  durableArtefactReady,
+  timedOut = false,
+  noResponse = false,
+}) {
+  const checks = [
+    [responseOrigin === "deliberate_user_input", "non_deliberate_response"],
+    [expectedApproval === `Approval: ${expectedGate}`, "approval_formula_mismatch"],
+    [Boolean(expectedRunId) && expectedRunId === currentRunId, "changed_or_wrong_run"],
+    [Boolean(expectedGate) && expectedGate === currentGate, "changed_or_wrong_gate"],
+    [Boolean(expectedRevisionId) && expectedRevisionId === currentRevisionId, "stale_revision"],
+    [durableArtefactReady === true, "durable_artefact_not_ready"],
+  ];
+
+  const failed = checks.find(([accepted]) => !accepted);
+  if (failed) return { accepted: false, reason: failed[1] };
+
+  const outcomeCandidate = responseOutcome && responseOutcome !== "approve" ? responseOutcome : response;
+  const outcome = normalizeInteractionOutcome(outcomeCandidate, {
+    expectedApproval,
+    timedOut,
+    noResponse,
+  });
+  const rejectionReasons = {
+    revise: "revision_requested",
+    decline: "declined",
+    cancel: "cancelled",
+    no_response: "no_response",
+    timeout: "timed_out",
+    empty: "empty_response",
+    invalid: "wrong_or_non_approval_response",
+    stale: "stale_response",
+  };
+  return outcome === "approve"
+    ? { accepted: true, reason: "accepted" }
+    : { accepted: false, reason: rejectionReasons[outcome] ?? "wrong_or_non_approval_response" };
+}

package/lib/control-state/index.js

@@ -4,3 +4,4 @@ export * from "./run-state-resolver.js";
 export * from "./run-state-writer.js";
 export * from "./legacy-migration.js";
 export * from "./aggregate.js";
+export * from "./gate-approval-validator.js";