create-agdf 0.7.2 → 0.8.0

package/bin/create-agdf.js

@@ -286,6 +286,17 @@ function resolveLanguagePreference(explicitLanguage) {
   };
 }
 
+function resolveConfiguredChatLanguage(targetDir) {
+  const configPath = join(targetDir, ".agdf", "control", "config.json");
+  if (!existsSync(configPath)) return "en";
+  try {
+    const config = JSON.parse(readFileSync(configPath, "utf8"));
+    return normalizeLanguage(config.chat_language) || "en";
+  } catch {
+    return "en";
+  }
+}
+
 function languageConfigContent(languagePreference) {
   return `${JSON.stringify({
     artifact_language: languagePreference.artifact_language,
@@ -2149,26 +2160,44 @@ function postApprovalTransition(missingApproval) {
     ["Approval: UR", {
       next_gate_after_approval: "Brownfield Review",
       allowed_after_approval: "Run Brownfield Review and record Mode/Slice Decision before PRD or implementation.",
+      internal_next_step: "Brownfield Review and Mode/Slice Decision",
+      next_user_gate: "PRD",
+      user_action_required: "yes",
     }],
     ["Approval: PRD", {
       next_gate_after_approval: "SD",
       allowed_after_approval: "Draft Solution Design; implementation remains forbidden.",
+      internal_next_step: "draft Solution Design",
+      next_user_gate: "SD",
+      user_action_required: "yes",
     }],
     ["Approval: SD", {
       next_gate_after_approval: "TP",
       allowed_after_approval: "Draft Task/Test Plan; implementation remains forbidden.",
+      internal_next_step: "draft Task/Test Plan",
+      next_user_gate: "TP",
+      user_action_required: "yes",
     }],
     ["Approval: TP", {
-      next_gate_after_approval: "Brownfield Analysis",
-      allowed_after_approval: "Run implementation-prep Brownfield Analysis before CD+Tests.",
+      next_gate_after_approval: "none",
+      allowed_after_approval: "Run implementation-prep Brownfield Analysis before CD+Tests; no further user approval is required at this internal step.",
+      internal_next_step: "pre-implementation Brownfield Analysis",
+      next_user_gate: "none",
+      user_action_required: "no",
     }],
     ["Approval: QA", {
       next_gate_after_approval: "UAT",
       allowed_after_approval: "Request UAT when QA has passed; release remains gated.",
+      internal_next_step: "prepare UAT evidence",
+      next_user_gate: "UAT",
+      user_action_required: "yes",
     }],
     ["Approval: UAT", {
       next_gate_after_approval: "OR",
       allowed_after_approval: "Produce OR or delivery closeout; VCS and release actions still require explicit instruction.",
+      internal_next_step: "OR or delivery closeout",
+      next_user_gate: "none",
+      user_action_required: "no",
     }],
   ]);
 
@@ -2187,11 +2216,15 @@ function buildStatusCard({
   missingApproval = "none",
   nextAllowedAction,
   runState,
+  chatLanguage = "en",
   findings = [],
 }) {
   const qualityOutlook = deriveQualityOutlook(runState, findings);
   const postApproval = postApprovalTransition(missingApproval);
+  const isUserGateApproval = missingApproval !== "none";
   return {
+    run_id: extractField(runState.content ?? "", "run_id") || "unknown",
+    presentation_language: chatLanguage,
     mode: extractField(runState.content ?? "", "mode") || "unknown",
     status,
     current_gate: currentGate,
@@ -2202,6 +2235,10 @@ function buildStatusCard({
     missing_approval: missingApproval || "none",
     next_gate_after_approval: postApproval.next_gate_after_approval,
     allowed_after_approval: postApproval.allowed_after_approval,
+    user_visible_outcome_after_approval: postApproval.allowed_after_approval,
+    internal_next_step: postApproval.internal_next_step || (isUserGateApproval ? "none" : nextAllowedAction),
+    next_user_gate: postApproval.next_user_gate || "none",
+    user_action_required: postApproval.user_action_required || (isUserGateApproval ? "yes" : "no"),
     evidence: runState.evidence_refs,
     next_skill: nextSkillByGate[currentGate] ?? "gate-check",
     next_step: nextAllowedAction,
@@ -2554,6 +2591,7 @@ function evaluateGateCheck(targetDir, selection = {}) {
       missingApproval,
       nextAllowedAction,
       runState,
+      chatLanguage: resolveConfiguredChatLanguage(targetDir),
       findings: deliveryMap.findings,
     }),
     delivery_map: {
@@ -2571,17 +2609,58 @@ function evaluateGateCheck(targetDir, selection = {}) {
 
 function printGateCheckStatusCard(report) {
   const card = report.status_card;
-  console.log(`AGDF status-card: ${card.status}`);
-  console.log(`Current gate: ${card.current_gate}`);
-  console.log(`Blocked by: ${card.blocking_condition}`);
-  console.log(`Missing approval: ${card.missing_approval}`);
-  if (card.next_gate_after_approval !== "none") console.log(`Next gate after approval: ${card.next_gate_after_approval}`);
-  if (card.allowed_after_approval !== "none") console.log(`Allowed after approval: ${card.allowed_after_approval}`);
-  console.log(`Next skill: ${card.next_skill}`);
-  console.log(`Next step: ${card.next_step}`);
-  console.log(`Quality outlook: ${card.quality_outlook}`);
-  if (card.allowed_now.length > 0) console.log(`Allowed now: ${card.allowed_now.join("; ")}`);
-  if (card.forbidden_now.length > 0) console.log(`Forbidden now: ${card.forbidden_now.join("; ")}`);
+  const de = card.presentation_language === "de";
+  const labels = de ? {
+    title: "AGDF-Statuskarte",
+    run: "Ausgewählter Run",
+    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",
+  } : {
+    title: "AGDF status-card",
+    run: "Selected run",
+    gate: "Current gate",
+    blocked: "Blocked by",
+    missing: "Missing approval",
+    outcome: "User-visible 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",
+  };
+  console.log(`${labels.title}: ${card.status}`);
+  console.log(`${labels.run}: ${card.run_id}`);
+  console.log(`${labels.gate}: ${card.current_gate}`);
+  console.log(`${labels.blocked}: ${card.blocking_condition}`);
+  console.log(`${labels.missing}: ${card.missing_approval}`);
+  console.log(`${labels.outcome}: ${card.user_visible_outcome_after_approval}`);
+  console.log(`${labels.internal}: ${card.internal_next_step}`);
+  console.log(`${labels.userGate}: ${card.next_user_gate}`);
+  console.log(`${labels.userAction}: ${card.user_action_required}`);
+  if (card.next_gate_after_approval !== "none") console.log(`${labels.nextGate}: ${card.next_gate_after_approval}`);
+  if (card.allowed_after_approval !== "none") console.log(`${labels.allowedAfter}: ${card.allowed_after_approval}`);
+  console.log(`${labels.skill}: ${card.next_skill}`);
+  console.log(`${labels.step}: ${card.next_step}`);
+  console.log(`${labels.quality}: ${card.quality_outlook}`);
+  if (card.allowed_now.length > 0) console.log(`${labels.allowed}: ${card.allowed_now.join("; ")}`);
+  if (card.forbidden_now.length > 0) console.log(`${labels.forbidden}: ${card.forbidden_now.join("; ")}`);
 }
 
 function printGateCheckReport(report, json, statusCard = false) {
@@ -2698,6 +2777,7 @@ function evaluateDeliveryMap(targetDir, selection = {}) {
       missingApproval: gateDecision.missing_approval,
       nextAllowedAction,
       runState,
+      chatLanguage: resolveConfiguredChatLanguage(targetDir),
       findings: map.findings,
     }),
     backlog_pointers: readBacklogPointers(targetDir),

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

@@ -62,20 +62,37 @@ 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. 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.
+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.
+
+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.
+
+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
+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.
 
 Surface behavior:
 
-- Codex: use the native short-question/request-user-input control when callable, ask one gate question and omit auto-resolution.
-- Claude Code: use `AskUserQuestion` only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; otherwise use exact text. Claude permissions and `ExitPlanMode` remain separate.
+- 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.
+- Claude Code: invoke `AskUserQuestion` on the first eligible attempt only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; if it is not rendered or applied, use exact text immediately. Claude permissions and `ExitPlanMode` remain separate.
 - 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.
+
 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.
 
 ## Rules
@@ -165,6 +182,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/generated/.github/skills/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 `agdf-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`: `de | en`, with unsupported or absent chat language resolved to `en`
 - `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 `agdf-gate-check`, `delive
 - `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,56 @@ 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 human-readable gate title, selected `run_id` as secondary
+   context 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
+<human-readable gate title> · <run_id>
+<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 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.
+
+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.
@@ -295,24 +351,38 @@ 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>` plus bounded revise and cancel/decline outcomes;
 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;
 7. persist an accepted approval only through the existing control-state workflow.
 
+The first eligible native-attempt has a single bounded outcome: the declared
+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.
 
 Surface adapter rules:
 
 | Surface | Native question adapter | Gate-safe use | Technical permission boundary |
 |---|---|---|---|
-| Codex | native `request_user_input` or equivalent short-question control when callable | one gate question; omit auto-resolution; otherwise use exact text | Codex command, edit, network, external-directory and app-action approvals remain host-owned `tool_permission`. |
-| Claude Code | `AskUserQuestion` | use only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; otherwise use exact text | Claude permissions and `ExitPlanMode` are not AGDF approval. |
+| Codex | native `request_user_input` or equivalent short-question control when callable | on the first eligible attempt, present one gate question with auto-resolution omitted; if unavailable or not applied, use exact text without retry | Codex command, edit, network, external-directory and app-action approvals remain host-owned `tool_permission`. |
+| Claude Code | `AskUserQuestion` | on the first eligible attempt, use only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; if unavailable or not applied, use exact text without retry | Claude permissions and `ExitPlanMode` are not AGDF approval. |
 | OpenCode | built-in `question` | use with exact approval/revise/cancel options when `permission.question` permits it; explicit user deny selects exact-text fallback | `once`, `always`, `reject`, permission suggestions and auto mode are technical outcomes only. |
 | Fallback or non-interactive | concise exact text | wait for a new explicit user response; never synthesize or auto-resolve one | Host-specific technical permission remains separate. |
 
@@ -320,6 +390,20 @@ 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 and exact-text fallback explanations use the configured project chat language from `.agdf/control/config.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;
+- 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.
+
+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.
+
 ## 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-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 `agdf-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`: `de | en`, with unsupported or absent chat language resolved to `en`
 - `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 `agdf-gate-check`, `delive
 - `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,56 @@ 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 human-readable gate title, selected `run_id` as secondary
+   context 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
+<human-readable gate title> · <run_id>
+<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 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.
+
+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.
@@ -295,24 +351,38 @@ 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>` plus bounded revise and cancel/decline outcomes;
 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;
 7. persist an accepted approval only through the existing control-state workflow.
 
+The first eligible native-attempt has a single bounded outcome: the declared
+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.
 
 Surface adapter rules:
 
 | Surface | Native question adapter | Gate-safe use | Technical permission boundary |
 |---|---|---|---|
-| Codex | native `request_user_input` or equivalent short-question control when callable | one gate question; omit auto-resolution; otherwise use exact text | Codex command, edit, network, external-directory and app-action approvals remain host-owned `tool_permission`. |
-| Claude Code | `AskUserQuestion` | use only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; otherwise use exact text | Claude permissions and `ExitPlanMode` are not AGDF approval. |
+| Codex | native `request_user_input` or equivalent short-question control when callable | on the first eligible attempt, present one gate question with auto-resolution omitted; if unavailable or not applied, use exact text without retry | Codex command, edit, network, external-directory and app-action approvals remain host-owned `tool_permission`. |
+| Claude Code | `AskUserQuestion` | on the first eligible attempt, use only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; if unavailable or not applied, use exact text without retry | Claude permissions and `ExitPlanMode` are not AGDF approval. |
 | OpenCode | built-in `question` | use with exact approval/revise/cancel options when `permission.question` permits it; explicit user deny selects exact-text fallback | `once`, `always`, `reject`, permission suggestions and auto mode are technical outcomes only. |
 | Fallback or non-interactive | concise exact text | wait for a new explicit user response; never synthesize or auto-resolve one | Host-specific technical permission remains separate. |
 
@@ -320,6 +390,20 @@ 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 and exact-text fallback explanations use the configured project chat language from `.agdf/control/config.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;
+- 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.
+
+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.
+
 ## 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

@@ -62,20 +62,37 @@ 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. 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.
+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.
+
+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.
+
+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
+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.
 
 Surface behavior:
 
-- Codex: use the native short-question/request-user-input control when callable, ask one gate question and omit auto-resolution.
-- Claude Code: use `AskUserQuestion` only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; otherwise use exact text. Claude permissions and `ExitPlanMode` remain separate.
+- 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.
+- Claude Code: invoke `AskUserQuestion` on the first eligible attempt only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; if it is not rendered or applied, use exact text immediately. Claude permissions and `ExitPlanMode` remain separate.
 - 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.
+
 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.
 
 ## Rules
@@ -165,6 +182,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/generated/plugins/agdf/.codex-plugin/plugin.json

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

package/generated/plugins/agdf/meta/agdf-plugin.definition.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
   "id": "agdf",
-  "version": "0.7.2",
+  "version": "0.8.0",
   "displayName": "AI Governance & Delivery Framework",
   "developerName": "Arndt Gold",
   "description": "Codex-first operating system for governed AI-assisted delivery.",

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`: `de | en`, with unsupported or absent chat language resolved to `en`
 - `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,56 @@ 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 human-readable gate title, selected `run_id` as secondary
+   context 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
+<human-readable gate title> · <run_id>
+<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 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.
+
+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.
@@ -295,24 +351,38 @@ 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>` plus bounded revise and cancel/decline outcomes;
 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;
 7. persist an accepted approval only through the existing control-state workflow.
 
+The first eligible native-attempt has a single bounded outcome: the declared
+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.
 
 Surface adapter rules:
 
 | Surface | Native question adapter | Gate-safe use | Technical permission boundary |
 |---|---|---|---|
-| Codex | native `request_user_input` or equivalent short-question control when callable | one gate question; omit auto-resolution; otherwise use exact text | Codex command, edit, network, external-directory and app-action approvals remain host-owned `tool_permission`. |
-| Claude Code | `AskUserQuestion` | use only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; otherwise use exact text | Claude permissions and `ExitPlanMode` are not AGDF approval. |
+| Codex | native `request_user_input` or equivalent short-question control when callable | on the first eligible attempt, present one gate question with auto-resolution omitted; if unavailable or not applied, use exact text without retry | Codex command, edit, network, external-directory and app-action approvals remain host-owned `tool_permission`. |
+| Claude Code | `AskUserQuestion` | on the first eligible attempt, use only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; if unavailable or not applied, use exact text without retry | Claude permissions and `ExitPlanMode` are not AGDF approval. |
 | OpenCode | built-in `question` | use with exact approval/revise/cancel options when `permission.question` permits it; explicit user deny selects exact-text fallback | `once`, `always`, `reject`, permission suggestions and auto mode are technical outcomes only. |
 | Fallback or non-interactive | concise exact text | wait for a new explicit user response; never synthesize or auto-resolve one | Host-specific technical permission remains separate. |
 
@@ -320,6 +390,20 @@ 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 and exact-text fallback explanations use the configured project chat language from `.agdf/control/config.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;
+- 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.
+
+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.
+
 ## 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

@@ -62,20 +62,37 @@ 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. 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.
+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.
+
+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.
+
+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
+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.
 
 Surface behavior:
 
-- Codex: use the native short-question/request-user-input control when callable, ask one gate question and omit auto-resolution.
-- Claude Code: use `AskUserQuestion` only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; otherwise use exact text. Claude permissions and `ExitPlanMode` remain separate.
+- 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.
+- Claude Code: invoke `AskUserQuestion` on the first eligible attempt only when no timeout can auto-continue and no hook supplies `answers` or `updatedInput`; if it is not rendered or applied, use exact text immediately. Claude permissions and `ExitPlanMode` remain separate.
 - 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.
+
 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.
 
 ## Rules
@@ -165,6 +182,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,28 @@
+export function validateGateApprovalResponse({
+  response,
+  responseOrigin,
+  expectedApproval,
+  expectedRunId,
+  currentRunId,
+  expectedGate,
+  currentGate,
+  expectedRevisionId,
+  currentRevisionId,
+  durableArtefactReady,
+}) {
+  const checks = [
+    [responseOrigin === "deliberate_user_input", "non_deliberate_response"],
+    [typeof response === "string" && response.length > 0, "empty_response"],
+    [expectedApproval === `Approval: ${expectedGate}`, "approval_formula_mismatch"],
+    [response === expectedApproval, "wrong_or_non_approval_response"],
+    [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);
+  return failed
+    ? { accepted: false, reason: failed[1] }
+    : { accepted: true, reason: "accepted" };
+}

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";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-agdf",
-  "version": "0.7.2",
+  "version": "0.8.0",
   "description": "Bootstrap AGDF repository-local plugin files, Copilot/OpenCode instructions, skills, control files and machine-readable checks.",
   "type": "module",
   "files": [