create-agdf 0.9.7 → 0.9.9

package/README.md

@@ -6,6 +6,11 @@ AGDF is useful when AI-assisted work can affect an existing system and a team ne
 
 ## Quick start
 
+AGDF's normal operating model has three roles: chat/skills provide the user interaction,
+`.agdf/control/` owns durable state and the CLI validates or renders that state. The CLI is not a
+second gate system. Use `npx ...@latest` below for installation and explicit refresh; after
+`npm install -g @agdf/cli`, prefer `agdf ...` for repeated local checks.
+
 If you use Codex, this is the recommended first installation:
 
 ```bash
@@ -46,6 +51,7 @@ npx --yes @agdf/cli@latest init
 npx --yes @agdf/cli@latest config --language en
 npx --yes @agdf/cli@latest doctor
 npx --yes @agdf/cli@latest gate-check --status-card
+npx --yes @agdf/cli@latest gate-check --approval-envelope
 npx --yes @agdf/cli@latest gate-check --json
 ```
 
@@ -209,7 +215,11 @@ npx --yes create-agdf@latest gate-check --json
 
 The gate check reports `open | blocked`, the current gate, blocking reason, missing exact approval, allowed outputs, forbidden outputs, next allowed action, evidence references and the embedded doctor report.
 
-Use `gate-check --status-card` for compact interactive output, especially in OpenCode where shell output is highly visible. Keep `gate-check --json` for automation, CI, regression evidence and audit trails.
+Use an installed `agdf gate-check --approval-envelope` to print deterministic ready-gate cards and the
+exact-text request without a fresh registry lookup. Use `gate-check --status-card` for compact
+operational detail and keep `gate-check --json` for native-adapter input, automation, CI, regression
+evidence and audit trails. The CLI output validates and renders the selected run; it does not replace
+the agent-native workflow or approve a gate.
 
 Use `delivery-path-search` only for high-impact planning decisions with several materially different next steps:
 

package/generated/.github/copilot-instructions.md

@@ -13,4 +13,4 @@ AGDF is active in this repository.
 - Do not infer gate approval from generic consent such as "ok", "go ahead", "do it", "continue", "leg los" or "approved".
 - Do not treat chat history as the source of truth for gate state, approvals, evidence or delivery status.
 - Do not paste full control files, templates or artefact bodies into chat unless the user explicitly asks for the full content; summarize and link paths instead.
-- For interactive checks, prefer `npx --yes @agdf/cli@latest gate-check --status-card`. Use `gate-check --json` for automation or audit evidence and summarize the status card instead of mirroring full JSON into chat.
+- For deterministic ready-gate rendering, prefer an installed `agdf gate-check --approval-envelope`; use `agdf gate-check --json` for native-adapter input, automation or audit evidence. Reserve `npx ...@latest` for bootstrap, installation, refresh or a missing local executable.

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

@@ -44,7 +44,7 @@ If required control files are missing, do not automatically create a full `.agdf
 The default first action is to draft the minimal UR in the response and request `Approval: UR`.
 Use `init` only when the user explicitly asks for durable AGDF control state, the repository already uses `.agdf/control/` as its live working state, or a deterministic CLI/CI setup path is being executed.
 
-Use the executable control path when a machine-readable check is requested, when the gate state is ambiguous, when CI or PR evidence is needed, or when a repository-local automation needs JSON output:
+Use the executable control path when a machine-readable check is requested, when the gate state is ambiguous, when CI or PR evidence is needed, when deterministic ready-gate rendering is required, or when a repository-local automation needs JSON output. Prefer an already installed `agdf` executable; use registry-resolved `npx ...@latest` only for bootstrap, installation, explicit refresh or when no local executable exists:
 
 ```bash
 npx --yes @agdf/cli@latest init
@@ -53,6 +53,11 @@ npx --yes @agdf/cli@latest gate-check --json
 npx --yes @agdf/cli@latest delivery-map --json
 ```
 
+For repeated local checks, use `agdf doctor --json`, `agdf gate-check --json` or
+`agdf gate-check --approval-envelope`. The last command prints the validated
+two-card exact-text interaction; JSON exposes the same `approval_presentation`
+for a native-capable adapter.
+
 `init` creates the control scaffold. `doctor` checks whether `.agdf/control/` is actionable. `agdf-gate-check` consumes that result and the selected canonical run record to report the operative process decision: `open | blocked`, current gate, blocking reason, missing approval, allowed outputs, forbidden outputs, next allowed action and evidence references.
 `delivery-map` reports the durable delivery picture: active artefacts, approvals, Artefact Chain relationships, evidence refs, missing evidence, risks, Context Graph gate effect and machine-readable findings.
 
@@ -73,15 +78,15 @@ 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. Build one immutable, non-authorizing presentation snapshot from the selected evaluated run and current revision identity.
-4. Compose one Approval Orientation Envelope as one immediately preceding assistant message containing two distinct blocks. Render the compact localized approval-time Run Status Card first. Its first visible line is the localized action-oriented gate title as a level-two Markdown heading or equivalent accessible host heading; generic AGDF/card labels and raw gate IDs cannot be the primary heading. It contains exactly selected run, readiness status, current gate, missing exact approval, one next action and quality outlook; omit raw keys, machine statuses, evidence, diagnostics and allowed/forbidden inventories.
-5. In the same assistant message, render a separate localized Gate Transition Card second, 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 either card only into the question, button description or hidden tool context. Do not invoke the native question tool until the complete two-card envelope is visible.
-6. 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. Run and gate identity may anchor both cards; do not duplicate status rows, action inventories or the native question.
+3. Consume the validated canonical `approval_presentation` for the same selected run, gate and revision. Do not compose or rewrite headings, fields, card order, locale copy or Markdown in the model.
+4. Emit its complete `run_status_card` block first and `gate_transition_card` block second in one immediately preceding assistant message. The first heading is neutral; the five status fields are selected run, readiness, current gate, human-readable required decision and a neutral approve/revise/decline instruction. The exact approval value appears only in the transition card across these two blocks.
+5. Never put either card only into the question, button description or hidden tool context. Do not invoke a native question until both rendered blocks are visible.
+6. If the projection is absent or invalid, render no partial card and invoke no native control. Re-evaluate the gate. Use only the exact-text request when the same gate is still ready and its canonical value is independently valid; otherwise report the non-ready reason and request no decision.
 7. 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.
 8. Ask exactly one question that names the selected `run_id` and `current_gate`.
 9. 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.
 10. Use the surface adapter declared in the canonical plugin definition only when it can wait for deliberate input without auto-resolution and can transport `exact_option_value` or `separate_label_and_value`; never invoke a `decorated_label_only` adapter. Otherwise request the same exact approval in concise text.
-11. Render both cards once in that single complete assistant message. Never merge, reverse, omit or duplicate them; the action heading does not replace either card. If the native attempt is unavailable or not applied, continue to exact text without repeating either card.
+11. Render both supplied cards once in that single complete assistant message. Never merge, reverse, omit, duplicate or reconstruct them; the decision heading does not replace either card. If the native attempt is unavailable or not applied, continue to exact text without repeating either card.
 12. Re-run gate evaluation for the same run and expected gate after the response and immediately before persistence.
 13. 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.
 14. Persist accepted input only through the existing control-state workflow.
@@ -95,7 +100,7 @@ A hook, permission result or session context message cannot replace an eligible
 
 Before composing the question, resolve the configured chat locale from `.agdf/control/config.json` through `../agdf-interaction-locales.json`: exact complete pack, language subtag, then English fallback. German and English are initial packs, not a closed language list. Keep `Approval: <GateName>` exactly unchanged in every language, and do not mix presentation languages within one interaction. Labels and descriptions use the same resolved locale; host-owned UI chrome remains host-owned and may use a different language.
 
-For the transition card, 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 canonical renderer resolves the complete 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`. Verify that the supplied blocks use one locale and a neutral decision heading while leaving the exact gate identifier and approval value unchanged. Do not model-edit the supplied Markdown.
 
 The primary option is derived exactly as `Approval: <GateName>` from the evaluated current gate; 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.
 
@@ -116,6 +121,7 @@ Surface behavior:
 - Codex: invoke the native short-question/request-user-input control only when preflight proves `exact_option_value` or `separate_label_and_value`, and omit auto-resolution. The canonical `decorated_label_only` capability must use exact text without invoking the adapter. `Approval: <GateName> (Recommended)` is never a valid option or approval.
 - 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.
+- GitHub Copilot: the current repository-instruction surface has no conforming native approval adapter. Transmit the canonical rendered cards followed by the exact-text request; never claim or simulate a native control. Copilot tool confirmations, plan interactions and repository permissions remain separate.
 - 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. A label, description, option position or recommendation never authorizes a gate. Host-provided free-text or `Überspringen`/`Skip` actions never advance an AGDF gate.

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

@@ -14,6 +14,7 @@
         "run": "Selected run",
         "humanTitle": "Run title",
         "gate": "Current gate",
+        "requiredDecision": "Required decision",
         "blocked": "Blocked by",
         "missing": "Missing approval",
         "outcome": "Outcome after approval",
@@ -81,17 +82,31 @@
         "Block": "Block"
       },
       "gateActionTitles": {
-        "UR": "Approve user requirements",
-        "PRD": "Approve product requirements",
-        "SD": "Approve solution design",
-        "TP": "Approve task and test plan",
-        "QA": "Approve quality decision",
-        "UAT": "Accept delivery result"
+        "UR": "Review and decide on user requirements",
+        "PRD": "Review and decide on product requirements",
+        "SD": "Review and decide on solution design",
+        "TP": "Review and decide on task and test plan",
+        "QA": "Review and decide on quality assurance",
+        "UAT": "Review and decide on user acceptance"
+      },
+      "gateRequiredDecisions": {
+        "UR": "User Requirements approval",
+        "PRD": "Product Requirements approval",
+        "SD": "Solution Design approval",
+        "TP": "Task and Test Plan approval",
+        "QA": "Quality Assurance approval",
+        "UAT": "User Acceptance decision"
       },
       "interaction": {
         "ready": "Ready for your decision",
         "approveHeading": "Approve now",
         "nextHeading": "Next",
+        "decisionInstruction": "Choose approve, request revision or decline.",
+        "decisionPrompt": "Choose approve, request revision or decline for {gate} in run {run_id}.",
+        "exactTextRequest": "To approve, reply exactly with `{approval}`; otherwise request revision or decline.",
+        "decisionFollows": "will be the next user decision",
+        "presentationFailure": "Approval cards could not be rendered safely.",
+        "nonReadyDecision": "No decision requested: {reason}.",
         "approveDescription": "Approve this gate with the exact authorization value.",
         "reviseLabel": "Revise",
         "reviseDescription": "Keep the gate open and request changes.",
@@ -201,6 +216,7 @@
         "run": "Ausgewählter Run",
         "humanTitle": "Run-Titel",
         "gate": "Aktuelles Gate",
+        "requiredDecision": "Erforderliche Entscheidung",
         "blocked": "Blockiert durch",
         "missing": "Fehlende Freigabe",
         "outcome": "Ergebnis nach Freigabe",
@@ -268,17 +284,31 @@
         "Block": "Block"
       },
       "gateActionTitles": {
-        "UR": "Nutzeranforderung freigeben",
-        "PRD": "Produktanforderungen freigeben",
-        "SD": "Lösungsdesign freigeben",
-        "TP": "Umsetzungsplan freigeben",
-        "QA": "Qualitätsentscheidung freigeben",
-        "UAT": "Ergebnis abnehmen"
+        "UR": "Nutzeranforderungen prüfen und entscheiden",
+        "PRD": "Produktanforderungen prüfen und entscheiden",
+        "SD": "Lösungsdesign prüfen und entscheiden",
+        "TP": "Aufgaben- und Testplan prüfen und entscheiden",
+        "QA": "Qualitätssicherung prüfen und entscheiden",
+        "UAT": "Nutzerabnahme prüfen und entscheiden"
+      },
+      "gateRequiredDecisions": {
+        "UR": "Freigabe der Nutzeranforderungen",
+        "PRD": "Freigabe der Produktanforderungen",
+        "SD": "Freigabe des Lösungsdesigns",
+        "TP": "Freigabe des Aufgaben- und Testplans",
+        "QA": "Freigabe der Qualitätssicherung",
+        "UAT": "Entscheidung über die Nutzerabnahme"
       },
       "interaction": {
         "ready": "Bereit für deine Entscheidung",
         "approveHeading": "Jetzt freigeben",
         "nextHeading": "Danach",
+        "decisionInstruction": "Freigeben, Überarbeitung anfordern oder ablehnen.",
+        "decisionPrompt": "Für {gate} im Run {run_id}: freigeben, Überarbeitung anfordern oder ablehnen.",
+        "exactTextRequest": "Zur Freigabe exakt mit `{approval}` antworten; andernfalls Überarbeitung anfordern oder ablehnen.",
+        "decisionFollows": "ist die nächste Nutzerentscheidung",
+        "presentationFailure": "Die Freigabekarten konnten nicht sicher dargestellt werden.",
+        "nonReadyDecision": "Keine Entscheidung angefordert: {reason}.",
         "approveDescription": "Dieses Gate mit dem exakten Freigabewert autorisieren.",
         "reviseLabel": "Überarbeiten",
         "reviseDescription": "Das Gate offen lassen und Änderungen anfordern.",

package/generated/.github/skills/contracts/control-scaffold.md

@@ -83,6 +83,7 @@ Helper commands are deterministic proof and automation interfaces, not the norma
 - `init` creates the machine-readable control scaffold.
 - `doctor --json` checks whether `.agdf/control/` is consistent and actionable; it is not the reviewer.
 - `gate-check --json` reports reproducible gate state; it does not replace the gate-check skill judgement.
+- `gate-check --approval-envelope` prints the canonical ready-gate cards and exact-text request from the same evaluation; it does not grant approval or replace the chat workflow.
 - `delivery-map --json` reports the delivery picture for CI, PRs, regression checks and audit trails.
 
 Machine-readable outputs should stay agent-friendly: stable decisions, blocking gate or current gate, missing approval, allowed outputs, forbidden outputs, next step, evidence and findings.
@@ -106,4 +107,3 @@ It must expose:
 
 Missing relationship evidence in the Artefact Chain is at least `revise` once the related gate artefact is approved or passed.
 Declared missing evidence, declared risk or Context Graph gate effect may escalate the delivery map to `warn`, `revise` or `block`.
-

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

@@ -116,22 +116,40 @@ before invoking any native question tool or emitting an exact-text approval
 request. Splitting the cards across separate assistant turns or invoking the
 tool after only one card is a failed interaction, not a valid presentation.
 
-The first visible line of that envelope is the localized action-oriented title
+The first visible line of that envelope is the localized neutral decision title
 of the current user gate, rendered as a level-two Markdown heading or equivalent
 accessible host heading inside the compact approval-time Run Status Card.
 `AGDF Status`, `Run Status Card`, `Gate Transition Card`, raw gate identifiers
 and machine values are semantic or diagnostic labels only and must not become
-the primary heading. The action title appears exactly once and does not replace,
+the primary heading. Approval-directed titles such as `Approve solution design`
+are also invalid. The decision title appears exactly once and does not replace,
 merge or reorder either required card block.
 
-The compact approval-time Run Status Card contains exactly six operational
-fields: selected run, readiness status, current gate, missing exact approval,
-one next action and quality outlook. It uses localized human-readable labels
+The compact approval-time Run Status Card contains exactly five operational
+fields: selected run, readiness status, current gate, a localized human-readable
+required decision and one neutral instruction to choose approve, request revision
+or decline. It does not contain the exact approval value or quality outlook. It uses localized human-readable labels
 and must not contain evidence, diagnostic codes, raw control-state keys,
 allowed/forbidden inventories or machine values. The complete Run Status Card remains the operational,
 CLI and audit projection and remains available for complete detail outside the
 approval-time compact view.
 
+The first scan across both cards reveals the requested decision, readiness,
+required approval, approval effect, remaining boundary and next transition.
+Identity and artefact references provide supporting context without competing
+with that sequence. Across the two cards, the exact `Approval: <GateName>` value
+appears exactly once, in the Gate Transition Card. The later native prompt or
+exact-text request may repeat it only as the required input.
+
+The canonical `interaction-presentation.js` owner builds and validates one
+immutable snapshot, then renders both complete Markdown blocks and the approval
+interaction. The public additive `approval_presentation` schema contains
+`schema_version`, selected run/revision/gate/locale identity, fixed sequence,
+both rendered blocks, canonical prompt/options/exact-text fallback and
+`authorizes: false`. It is a valid object only for a ready user gate and `null`
+otherwise. Agents and surface adapters transmit these blocks without rebuilding
+headings, fields, ordering, locale copy or Markdown.
+
 The Gate Transition Card is the second orientation message. It is derived from
 the same snapshot and canonical post-approval transition, but it is not another
 state model, persisted record, renderer or approval authority. It turns only
@@ -152,7 +170,7 @@ The card answers exactly three user questions, in this order:
 Use this compact composition:
 
 ```text
-<localized gate title> · <human run title> · <run_id>
+<localized gate title> · <human run title> · `<run_id>`
 <UR link or localized missing text> · <PRD link or localized missing text> · <SD link or localized missing text> · <TP link or localized missing text>
 <localized ready-for-decision line>
 
@@ -185,6 +203,12 @@ 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.
 
+If snapshot validation or rendering fails, emit no partial card and forbid native
+invocation. Perform a fresh gate evaluation. Show only the localized exact-text
+request when the same gate remains ready and the canonical approval value is
+independently valid. Otherwise report the current non-ready reason and request no
+decision. Never patch, guess or model-reconstruct missing presentation content.
+
 
 ## Native Interaction Contract
 
@@ -230,7 +254,7 @@ Before presenting `gate_approval`, the agent must:
 
 1. resolve exactly one selected run;
 2. run the canonical gate evaluation and confirm that the current gate's durable artefact is present and ready;
-3. build one immutable non-authorizing presentation snapshot, emit its compact Run Status Card and Gate Transition Card in that order 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;
+3. consume one validated canonical `approval_presentation`, emit its compact Run Status Card and Gate Transition Card verbatim in that order 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;
@@ -261,6 +285,13 @@ exact approval value and confirms that authority is unchanged. A fresh explicit
 user request may reopen the unchanged decision after revalidation; it is not an
 automatic retry.
 
+For deterministic local projection, use an already installed `agdf gate-check
+--json` and consume `approval_presentation`, or use `agdf gate-check
+--approval-envelope` on an exact-text surface. These are renderer/validator
+helpers, not a second UX or gate authority. Do not require a registry-resolved
+`npx ...@latest` call for each normal interaction. `npx` remains the explicit
+bootstrap, installation, refresh or missing-local-executable path.
+
 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:
@@ -270,6 +301,7 @@ Surface adapter rules:
 | Codex | native `request_user_input` or equivalent short-question control when callable | invoke on the first eligible attempt when preflight proves `exact_option_value`; 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. |
+| GitHub Copilot | none in the current AGDF repository-instruction surface | transmit the canonical rendered cards followed by the exact-text request; never claim or simulate a native approval control | Copilot tool confirmations, plan interactions and repository permissions are not AGDF approval. |
 | 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. |
 
 Native structured questions are for real decision points. Prefer repository inspection over clarification and do not show them for status reporting, discoverable facts, routine read-only work or repeated non-ready gate prompts.
@@ -352,8 +384,10 @@ For every primary chat card:
 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.
+3. Use a localized neutral decision title while preserving the exact gate identifier
+   and `Approval: <GateName>` authorization value. The technical value appears
+   once across the two cards, in the transition card; the later input control may
+   repeat it as the required 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.

package/generated/.opencode/README.md

@@ -10,7 +10,7 @@ These files were generated from the AGDF source repository for OpenCode.
 - `.opencode/skills/` contains native OpenCode skills generated from the canonical AGDF skills.
 - For new build/change intent or unclear approval, load `agdf-gate-check` through OpenCode's native `skill` tool.
 - Use `npx --yes @agdf/cli@latest opencode-status --json` to distinguish global hook/native-skill configuration, package loadability, session activity and this repository surface.
-- Use `npx --yes @agdf/cli@latest gate-check --status-card` for compact interactive gate state; reserve full `--json` output for automation or audit evidence.
+- For deterministic ready-gate rendering, prefer an installed `agdf gate-check --approval-envelope`; reserve `agdf gate-check --json` for native-adapter input, automation or audit evidence and use `npx ...@latest` only for bootstrap, refresh or a missing local executable.
 - `.opencode/agdf-runtime-contract.md` is the shared gate and output contract.
 
 ## Skills

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

@@ -14,6 +14,7 @@
         "run": "Selected run",
         "humanTitle": "Run title",
         "gate": "Current gate",
+        "requiredDecision": "Required decision",
         "blocked": "Blocked by",
         "missing": "Missing approval",
         "outcome": "Outcome after approval",
@@ -81,17 +82,31 @@
         "Block": "Block"
       },
       "gateActionTitles": {
-        "UR": "Approve user requirements",
-        "PRD": "Approve product requirements",
-        "SD": "Approve solution design",
-        "TP": "Approve task and test plan",
-        "QA": "Approve quality decision",
-        "UAT": "Accept delivery result"
+        "UR": "Review and decide on user requirements",
+        "PRD": "Review and decide on product requirements",
+        "SD": "Review and decide on solution design",
+        "TP": "Review and decide on task and test plan",
+        "QA": "Review and decide on quality assurance",
+        "UAT": "Review and decide on user acceptance"
+      },
+      "gateRequiredDecisions": {
+        "UR": "User Requirements approval",
+        "PRD": "Product Requirements approval",
+        "SD": "Solution Design approval",
+        "TP": "Task and Test Plan approval",
+        "QA": "Quality Assurance approval",
+        "UAT": "User Acceptance decision"
       },
       "interaction": {
         "ready": "Ready for your decision",
         "approveHeading": "Approve now",
         "nextHeading": "Next",
+        "decisionInstruction": "Choose approve, request revision or decline.",
+        "decisionPrompt": "Choose approve, request revision or decline for {gate} in run {run_id}.",
+        "exactTextRequest": "To approve, reply exactly with `{approval}`; otherwise request revision or decline.",
+        "decisionFollows": "will be the next user decision",
+        "presentationFailure": "Approval cards could not be rendered safely.",
+        "nonReadyDecision": "No decision requested: {reason}.",
         "approveDescription": "Approve this gate with the exact authorization value.",
         "reviseLabel": "Revise",
         "reviseDescription": "Keep the gate open and request changes.",
@@ -201,6 +216,7 @@
         "run": "Ausgewählter Run",
         "humanTitle": "Run-Titel",
         "gate": "Aktuelles Gate",
+        "requiredDecision": "Erforderliche Entscheidung",
         "blocked": "Blockiert durch",
         "missing": "Fehlende Freigabe",
         "outcome": "Ergebnis nach Freigabe",
@@ -268,17 +284,31 @@
         "Block": "Block"
       },
       "gateActionTitles": {
-        "UR": "Nutzeranforderung freigeben",
-        "PRD": "Produktanforderungen freigeben",
-        "SD": "Lösungsdesign freigeben",
-        "TP": "Umsetzungsplan freigeben",
-        "QA": "Qualitätsentscheidung freigeben",
-        "UAT": "Ergebnis abnehmen"
+        "UR": "Nutzeranforderungen prüfen und entscheiden",
+        "PRD": "Produktanforderungen prüfen und entscheiden",
+        "SD": "Lösungsdesign prüfen und entscheiden",
+        "TP": "Aufgaben- und Testplan prüfen und entscheiden",
+        "QA": "Qualitätssicherung prüfen und entscheiden",
+        "UAT": "Nutzerabnahme prüfen und entscheiden"
+      },
+      "gateRequiredDecisions": {
+        "UR": "Freigabe der Nutzeranforderungen",
+        "PRD": "Freigabe der Produktanforderungen",
+        "SD": "Freigabe des Lösungsdesigns",
+        "TP": "Freigabe des Aufgaben- und Testplans",
+        "QA": "Freigabe der Qualitätssicherung",
+        "UAT": "Entscheidung über die Nutzerabnahme"
       },
       "interaction": {
         "ready": "Bereit für deine Entscheidung",
         "approveHeading": "Jetzt freigeben",
         "nextHeading": "Danach",
+        "decisionInstruction": "Freigeben, Überarbeitung anfordern oder ablehnen.",
+        "decisionPrompt": "Für {gate} im Run {run_id}: freigeben, Überarbeitung anfordern oder ablehnen.",
+        "exactTextRequest": "Zur Freigabe exakt mit `{approval}` antworten; andernfalls Überarbeitung anfordern oder ablehnen.",
+        "decisionFollows": "ist die nächste Nutzerentscheidung",
+        "presentationFailure": "Die Freigabekarten konnten nicht sicher dargestellt werden.",
+        "nonReadyDecision": "Keine Entscheidung angefordert: {reason}.",
         "approveDescription": "Dieses Gate mit dem exakten Freigabewert autorisieren.",
         "reviseLabel": "Überarbeiten",
         "reviseDescription": "Das Gate offen lassen und Änderungen anfordern.",

package/generated/.opencode/contracts/control-scaffold.md

@@ -83,6 +83,7 @@ Helper commands are deterministic proof and automation interfaces, not the norma
 - `init` creates the machine-readable control scaffold.
 - `doctor --json` checks whether `.agdf/control/` is consistent and actionable; it is not the reviewer.
 - `gate-check --json` reports reproducible gate state; it does not replace the gate-check skill judgement.
+- `gate-check --approval-envelope` prints the canonical ready-gate cards and exact-text request from the same evaluation; it does not grant approval or replace the chat workflow.
 - `delivery-map --json` reports the delivery picture for CI, PRs, regression checks and audit trails.
 
 Machine-readable outputs should stay agent-friendly: stable decisions, blocking gate or current gate, missing approval, allowed outputs, forbidden outputs, next step, evidence and findings.
@@ -106,4 +107,3 @@ It must expose:
 
 Missing relationship evidence in the Artefact Chain is at least `revise` once the related gate artefact is approved or passed.
 Declared missing evidence, declared risk or Context Graph gate effect may escalate the delivery map to `warn`, `revise` or `block`.
-

package/generated/.opencode/contracts/interaction.md

@@ -116,22 +116,40 @@ before invoking any native question tool or emitting an exact-text approval
 request. Splitting the cards across separate assistant turns or invoking the
 tool after only one card is a failed interaction, not a valid presentation.
 
-The first visible line of that envelope is the localized action-oriented title
+The first visible line of that envelope is the localized neutral decision title
 of the current user gate, rendered as a level-two Markdown heading or equivalent
 accessible host heading inside the compact approval-time Run Status Card.
 `AGDF Status`, `Run Status Card`, `Gate Transition Card`, raw gate identifiers
 and machine values are semantic or diagnostic labels only and must not become
-the primary heading. The action title appears exactly once and does not replace,
+the primary heading. Approval-directed titles such as `Approve solution design`
+are also invalid. The decision title appears exactly once and does not replace,
 merge or reorder either required card block.
 
-The compact approval-time Run Status Card contains exactly six operational
-fields: selected run, readiness status, current gate, missing exact approval,
-one next action and quality outlook. It uses localized human-readable labels
+The compact approval-time Run Status Card contains exactly five operational
+fields: selected run, readiness status, current gate, a localized human-readable
+required decision and one neutral instruction to choose approve, request revision
+or decline. It does not contain the exact approval value or quality outlook. It uses localized human-readable labels
 and must not contain evidence, diagnostic codes, raw control-state keys,
 allowed/forbidden inventories or machine values. The complete Run Status Card remains the operational,
 CLI and audit projection and remains available for complete detail outside the
 approval-time compact view.
 
+The first scan across both cards reveals the requested decision, readiness,
+required approval, approval effect, remaining boundary and next transition.
+Identity and artefact references provide supporting context without competing
+with that sequence. Across the two cards, the exact `Approval: <GateName>` value
+appears exactly once, in the Gate Transition Card. The later native prompt or
+exact-text request may repeat it only as the required input.
+
+The canonical `interaction-presentation.js` owner builds and validates one
+immutable snapshot, then renders both complete Markdown blocks and the approval
+interaction. The public additive `approval_presentation` schema contains
+`schema_version`, selected run/revision/gate/locale identity, fixed sequence,
+both rendered blocks, canonical prompt/options/exact-text fallback and
+`authorizes: false`. It is a valid object only for a ready user gate and `null`
+otherwise. Agents and surface adapters transmit these blocks without rebuilding
+headings, fields, ordering, locale copy or Markdown.
+
 The Gate Transition Card is the second orientation message. It is derived from
 the same snapshot and canonical post-approval transition, but it is not another
 state model, persisted record, renderer or approval authority. It turns only
@@ -152,7 +170,7 @@ The card answers exactly three user questions, in this order:
 Use this compact composition:
 
 ```text
-<localized gate title> · <human run title> · <run_id>
+<localized gate title> · <human run title> · `<run_id>`
 <UR link or localized missing text> · <PRD link or localized missing text> · <SD link or localized missing text> · <TP link or localized missing text>
 <localized ready-for-decision line>
 
@@ -185,6 +203,12 @@ 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.
 
+If snapshot validation or rendering fails, emit no partial card and forbid native
+invocation. Perform a fresh gate evaluation. Show only the localized exact-text
+request when the same gate remains ready and the canonical approval value is
+independently valid. Otherwise report the current non-ready reason and request no
+decision. Never patch, guess or model-reconstruct missing presentation content.
+
 
 ## Native Interaction Contract
 
@@ -230,7 +254,7 @@ Before presenting `gate_approval`, the agent must:
 
 1. resolve exactly one selected run;
 2. run the canonical gate evaluation and confirm that the current gate's durable artefact is present and ready;
-3. build one immutable non-authorizing presentation snapshot, emit its compact Run Status Card and Gate Transition Card in that order 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;
+3. consume one validated canonical `approval_presentation`, emit its compact Run Status Card and Gate Transition Card verbatim in that order 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;
@@ -261,6 +285,13 @@ exact approval value and confirms that authority is unchanged. A fresh explicit
 user request may reopen the unchanged decision after revalidation; it is not an
 automatic retry.
 
+For deterministic local projection, use an already installed `agdf gate-check
+--json` and consume `approval_presentation`, or use `agdf gate-check
+--approval-envelope` on an exact-text surface. These are renderer/validator
+helpers, not a second UX or gate authority. Do not require a registry-resolved
+`npx ...@latest` call for each normal interaction. `npx` remains the explicit
+bootstrap, installation, refresh or missing-local-executable path.
+
 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:
@@ -270,6 +301,7 @@ Surface adapter rules:
 | Codex | native `request_user_input` or equivalent short-question control when callable | invoke on the first eligible attempt when preflight proves `exact_option_value`; 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. |
+| GitHub Copilot | none in the current AGDF repository-instruction surface | transmit the canonical rendered cards followed by the exact-text request; never claim or simulate a native approval control | Copilot tool confirmations, plan interactions and repository permissions are not AGDF approval. |
 | 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. |
 
 Native structured questions are for real decision points. Prefer repository inspection over clarification and do not show them for status reporting, discoverable facts, routine read-only work or repeated non-ready gate prompts.
@@ -352,8 +384,10 @@ For every primary chat card:
 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.
+3. Use a localized neutral decision title while preserving the exact gate identifier
+   and `Approval: <GateName>` authorization value. The technical value appears
+   once across the two cards, in the transition card; the later input control may
+   repeat it as the required 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.