create-agdf 0.8.2 → 0.8.3

package/bin/create-agdf.js

@@ -26,8 +26,10 @@ import {
   verifyLegacyProjection,
 } from "../lib/control-state/index.js";
 import {
+  attachApprovalOrientationSnapshot,
   buildArtefactRefs,
   buildRunCandidates,
+  buildQualityReadiness,
   canonicalizeLanguageTag,
   formatArtefactRefs,
   gateTitle,
@@ -60,7 +62,7 @@ const agdfFragmentPath = "AGENTS.agdf.md";
 const openCodeConfigFragmentPath = "opencode.agdf.json";
 const userGateOrder = ["UR", "PRD", "SD", "TP", "QA", "UAT"];
 const durableGateArtefacts = new Set(["UR", "PRD", "SD", "TP", "QA"]);
-const internalStepArtefacts = new Set(["Brownfield Review", "Verified Change", "Brownfield Analysis", "CD+Tests", "CR"]);
+const internalStepArtefacts = new Set(["Brownfield Review", "Verified Change", "Brownfield Analysis", "CD+Tests", "TP Review", "Clean Implementation Review", "Clean Review", "CR", "Code Review"]);
 const deliveryRelationships = [
   { from: "UR", relationship: "approved_by", to: "Approval: UR", requiredBy: "UR" },
   { from: "PRD", relationship: "derived_from", to: "UR", requiredBy: "PRD" },
@@ -2281,6 +2283,36 @@ function buildStatusCard({
   };
 }
 
+function statusFromReviewArtefact(artefact) {
+  if (!artefact) return "unknown";
+  const text = `${artefact.status ?? ""} ${artefact.notes ?? ""}`.toLowerCase();
+  for (const status of ["block", "revise", "warn", "pass"]) {
+    if (new RegExp(`\\b${status}(?:ed)?\\b`).test(text)) return status;
+  }
+  return "unknown";
+}
+
+function qualityReadinessForRunState(runState, nextAction) {
+  const artefacts = runState.artefacts;
+  const plan = artefacts.get("TP Review");
+  const clean = artefacts.get("Clean Implementation Review") ?? artefacts.get("Clean Review");
+  const code = artefacts.get("CR") ?? artefacts.get("Code Review");
+  const qa = artefacts.get("QA");
+  if (![plan, clean, code, qa].some(Boolean)) return null;
+  const reviewRows = [plan, clean, code, qa].filter(Boolean);
+  const decisive = reviewRows.find((artefact) => /\b(?:block|revise)\b/i.test(`${artefact.status ?? ""} ${artefact.notes ?? ""}`));
+  const readiness = buildQualityReadiness({
+    planCoverage: statusFromReviewArtefact(plan),
+    solutionIntegrity: statusFromReviewArtefact(clean),
+    codeQuality: statusFromReviewArtefact(code),
+    qaDecision: statusFromReviewArtefact(qa),
+    decisiveReason: decisive?.notes ?? "",
+    nextAction,
+  });
+  if (!readiness) return null;
+  return Object.freeze({ ...readiness, decisive_reference: decisive?.path ?? "" });
+}
+
 function resolvedArtefactFile(targetDir, rawPath) {
   const normalizedPath = String(rawPath ?? "").replace(/^`|`$/g, "").trim();
   if (!normalizedPath || isAbsolute(normalizedPath) || normalizedPath.includes("<") || normalizedPath.includes(">")) return "";
@@ -2672,8 +2704,20 @@ function evaluateGateCheck(targetDir, selection = {}) {
     chatLanguage: presentationLocale,
     findings: deliveryMap.findings,
   });
+  const humanPresentation = buildHumanPresentation(targetDir, runState, currentGate, presentationLocale);
   Object.defineProperty(statusCard, "humanPresentation", {
-    value: buildHumanPresentation(targetDir, runState, currentGate, presentationLocale),
+    value: humanPresentation,
+    enumerable: false,
+  });
+  attachApprovalOrientationSnapshot(statusCard, {
+    ready: status === "open" && missingApproval === `Approval: ${currentGate}`,
+    humanPresentation,
+    revisionId: extractField(runState.content ?? "", "revision_id"),
+    registry: interactionLocales,
+    requestedLocale: presentationLocale,
+  });
+  Object.defineProperty(statusCard, "runState", {
+    value: runState,
     enumerable: false,
   });
 
@@ -2730,6 +2774,21 @@ function printGateCheckStatusCard(report) {
   console.log(`${labels.allowed}: ${primary.actions[card.current_gate] ?? primary.none}`);
   console.log(`${labels.step}: ${primary.actions[card.current_gate] ?? primary.none}`);
   console.log(`${labels.quality}: ${primary.quality}`);
+  const readiness = qualityReadinessForRunState(card.runState, report.next_allowed_action);
+  if (readiness) {
+    const quality = localePack(interactionLocales, card.presentation_language).qualityReadiness;
+    console.log("");
+    console.log(`${quality.title}: ${primary.status[readiness.status] ?? readiness.status}`);
+    for (const row of readiness.rows) {
+      console.log(`${quality.rows[row.id]}: ${primary.status[row.status] ?? quality.unknown}`);
+    }
+    const reason = readiness.decisive_reason
+      || (readiness.status === "pass" ? primary.none : quality.fallbackReasons[readiness.decisive_dimension] || primary.none);
+    console.log(`${quality.reason}: ${reason}`);
+    if (readiness.status !== "pass" && readiness.decisive_reference) console.log(`${quality.reference}: ${readiness.decisive_reference}`);
+    console.log(`${quality.nextAction}: ${readiness.next_action || primary.none}`);
+    console.log(`${quality.decisionOwner}: ${quality.decisionOwnerValue}`);
+  }
 }
 
 function printGateCheckReport(report, json, statusCard = false) {

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

@@ -62,16 +62,18 @@ For a ready `gate_approval`:
 
 1. Resolve exactly one selected run and evaluate the current gate.
 2. Confirm the required durable artefact is present and ready before presenting a question.
-3. Render a separate localized Gate Transition Card immediately before any native question or exact-text fallback. It includes the deterministic human run title and `UR · PRD · SD · TP` links from the selected run. Never put the card only into the question, button description or hidden tool context.
-4. Treat the operational Run Status Card as evaluation and audit input, not as the approval-time product surface. Do not paste its table, raw keys, machine statuses, evidence or diagnostic detail into the transition card.
-5. Compose the transition card as one human-readable gate title with `run_id`, one ready-for-decision line, one short approval-effect block and one short next-transition block. It must answer only: where am I, what does this decision do, and what happens next.
-6. Distinguish internal process steps from user decisions in natural language. For example, after `Approval: TP`, say that pre-implementation Brownfield Analysis runs next and that no further user action is required now; do not expose `next_user_gate: none` or `user_action_required: no`, and do not ask for a second approval for Brownfield Analysis.
-7. Ask exactly one question that names the selected `run_id` and `current_gate`.
-8. Offer options in stable order: exact `Approval: <GateName>`, localized revise and localized decline. Add explicit cancel only where supported after decline; otherwise host dismissal maps to cancel. Never preselect, skip, auto-submit or reorder an option.
-9. Use the surface adapter declared in the canonical plugin definition only when it can wait for deliberate input without auto-resolution; otherwise request the same exact approval in concise text.
-10. Re-run gate evaluation for the same run and expected gate after the response and immediately before persistence.
-11. Reject a missing artefact, ambiguous or wrong run, wrong gate, stale expected gate, timeout/default, hook-supplied answer, agent message, technical permission outcome or plan approval.
-12. Persist accepted input only through the existing control-state workflow.
+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. 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.
+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; otherwise request the same exact approval in concise text.
+11. Render both cards once in that single complete assistant message. 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.
 
 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.
 
@@ -191,10 +193,12 @@ 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.
+This complete operational status table remains the status-reporting and detail
+surface. When the same response immediately requests a ready gate approval,
+render its six-field compact approval-time projection first, then the Gate
+Transition Card in the same immediately preceding assistant message, then
+invoke exactly one native question or exact-text fallback. Both cards derive
+from the same snapshot and are shown exactly once.
 
 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-interaction-locales.json

@@ -29,6 +29,27 @@
         "forbidden": "Forbidden now",
         "artefacts": "Artefacts"
       },
+      "qualityReadiness": {
+        "title": "Quality Readiness",
+        "rows": {
+          "plan_coverage": "Plan coverage",
+          "solution_integrity": "Solution integrity",
+          "code_quality": "Code quality",
+          "qa_decision": "QA decision"
+        },
+        "reason": "Reason",
+        "reference": "Evidence report",
+        "nextAction": "Next action",
+        "decisionOwner": "Decision owner",
+        "decisionOwnerValue": "QA Gate",
+        "unknown": "evidence missing",
+        "fallbackReasons": {
+          "plan_coverage": "Plan coverage requires revision before QA can pass.",
+          "solution_integrity": "Solution integrity requires revision before QA can pass.",
+          "code_quality": "Code quality findings require revision before QA can pass.",
+          "qa_decision": "QA evidence requires revision before the gate can pass."
+        }
+      },
       "gateTitles": {
         "UR": "User requirements",
         "PRD": "Product requirements",
@@ -115,6 +136,27 @@
         "forbidden": "Aktuell verboten",
         "artefacts": "Artefakte"
       },
+      "qualityReadiness": {
+        "title": "Quality Readiness",
+        "rows": {
+          "plan_coverage": "Planabdeckung",
+          "solution_integrity": "Lösungsintegrität",
+          "code_quality": "Code-Qualität",
+          "qa_decision": "QA-Entscheidung"
+        },
+        "reason": "Grund",
+        "reference": "Nachweisbericht",
+        "nextAction": "Nächste Aktion",
+        "decisionOwner": "Entscheidungsinstanz",
+        "decisionOwnerValue": "QA-Gate",
+        "unknown": "Nachweis fehlt",
+        "fallbackReasons": {
+          "plan_coverage": "Die Planabdeckung muss vor einem QA-Pass überarbeitet werden.",
+          "solution_integrity": "Die Lösungsintegrität muss vor einem QA-Pass überarbeitet werden.",
+          "code_quality": "Code-Qualitätsbefunde müssen vor einem QA-Pass überarbeitet werden.",
+          "qa_decision": "Die QA-Nachweise müssen vor einem QA-Pass überarbeitet werden."
+        }
+      },
       "gateTitles": {
         "UR": "Nutzeranforderungen",
         "PRD": "Produktanforderungen",

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

@@ -28,6 +28,13 @@ QA-specific `decision` is exactly `pass | revise | block`.
 `pass` is allowed only when TP coverage, Brownfield fit, solution integrity, and relevant documentation/Context Graph impact are sufficiently evidenced.
 `sot_drift` must not pass silently as a warning.
 
+When post-CD+Tests review evidence exists, present the Runtime Contract's derived Quality
+Readiness projection before the detailed QA report: Plan coverage, Solution integrity, Code
+quality and QA decision in that order. Name `agdf-qa-gate` as the sole decision owner, show one
+decisive reason and one permissible next action, and keep detailed reports as evidence links or
+on-demand detail. The projection is non-authorizing and must not replace the Run Status Card,
+Gate Transition Card or the durable QA report.
+
 ## Rules
 1. No QA pass without strong evidence.
 2. TP is the reference, not merely working code.

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

@@ -145,15 +145,55 @@ 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.
 
+## Quality Readiness Projection
+
+After CD+Tests, when any of the four review/QA artefacts exists, surfaces may show one compact
+derived `Quality Readiness` projection. It answers the user-facing question "what is the current
+quality outcome and what should happen next?" without replacing evidence or creating another
+decision authority.
+
+- It contains exactly four rows, in this order: `Plan coverage` from `agdf-task-plan-review`,
+  `Solution integrity` from `agdf-clean-implementation-review`, `Code quality` from `agdf-code-review`,
+  and `QA decision` from `agdf-qa-gate`.
+- `agdf-qa-gate` is always labeled as the sole decision owner. The other three rows are evidence
+  dimensions, not competing pass/revise/block decisions.
+- Overall status reuses canonical severity ordering. Missing or conflicting required evidence
+  must not render `pass`; surface `revise` or `block` with the decisive reason and one permitted
+  next action instead.
+- The projection is derived, non-persistent and non-authorizing. It cannot accept an approval,
+  advance a gate, suppress a report or replace the Run Status Card, Gate Transition Card, JSON
+  projection or durable review artefacts.
+- Show compact rows on `pass`. On `revise` or `block`, expand only the decisive row with its
+  canonical report reference; do not paste complete reports into chat.
+
 ## 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.
+Every ready `gate_approval` uses one fixed visible sequence: first the compact
+approval-time Run Status Card, then the Gate Transition Card, then exactly one
+native question or exact-text fallback. Both cards derive from one immutable,
+non-authorizing presentation snapshot produced after canonical selected-run,
+gate and durable-artefact readiness evaluation. The snapshot never selects a
+run, decides a gate, persists state or grants approval.
+
+The two distinct card blocks form one Approval Orientation Envelope in one
+immediately preceding assistant message. The agent must complete that message
+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 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
+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 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
+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:
 
@@ -189,11 +229,13 @@ for example, the German title may be `Lösungsdesign` while the authorization
 value remains `Approval: SD`. Meaning, ordering and authority boundaries are
 identical across locale packs.
 
-The approval-time card must not be a Markdown table or dashboard. It must not
+The Gate Transition 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.
+Run and gate identity may appear in both cards to anchor the shared snapshot;
+status rows, action inventories and transition prose must not be duplicated.
 
 For `Approval: TP`, the effect is permission to run pre-implementation
 Brownfield Analysis, implementation remains gated until that analysis passes,
@@ -359,19 +401,20 @@ response_origin: deliberate_user_input for gate_approval
 This envelope is not a new persisted record. The selected canonical `RUN_STATE.md` and existing artefact chain remain the durable authority.
 
 Before presenting `gate_approval` for any user gate (`UR`, `PRD`, `SD`, `TP`,
-`QA`, or `UAT`), the agent must emit the localized Gate Transition Card as a
-separate, immediately preceding interaction block. The card is not optional,
-not hidden in the question text and not replaced by a host button label.
-Native buttons or exact-text fallback may appear only after this card. The
-underlying Run Status Card fields remain available to evaluation and audit,
-but their dashboard projection must not be pasted into this approval-time
-message.
+`QA`, or `UAT`), the agent must emit the compact localized Run Status Card and
+the localized Gate Transition Card as two distinct blocks in that order within
+one immediately preceding assistant message. Neither card is optional, hidden
+in the question text or replaced by a host button label. Do not invoke the
+native question tool until the complete two-card envelope is visible. Native
+buttons or exact-text fallback may appear only after both cards. Render the two
+cards once per eligible attempt; an unavailable or not-applied native control
+proceeds to exact text without repeating them.
 
 Before presenting `gate_approval`, the agent must:
 
 1. resolve exactly one selected run;
 2. run the canonical gate evaluation and confirm that the current gate's durable artefact is present and ready;
-3. emit the separate localized Gate Transition Card immediately before the gate question, then ask exactly one gate question that identifies `run_id` and `current_gate` and offers the exact approving value `Approval: <GateName>` followed by stable `revise` and `decline` outcomes; host-owned dismissal maps to `cancel` where only three choices are available;
+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;
 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;

package/generated/.opencode/AGDF.md

@@ -51,13 +51,13 @@ Structured Delivery Mode must respect gates, reviews and closeout discipline.
 |---|---|---|
 | `agdf-delivery-path-search` | high-impact planning decisions with several plausible next delivery steps before implementation | read-only advisory search; never grants gate permission or replaces gate-check |
 | `agdf-brownfield-analysis` | after gate-check permits Brownfield Review or implementation preparation, before non-trivial changes in existing systems | clarifies reuse, owners, risks and Mode/Slice Decision; never bypasses gate-check; Brownfield Review is not implementation permission |
-| `agdf-clean-implementation-review` | inspect workarounds, fallbacks, parallel structures or symptom fixes | not a TP or QA substitute |
-| `agdf-code-review` | mandatory CR step after code changes, focused on defects, regression and security findings | does not replace TP review, clean review or QA |
+| `agdf-clean-implementation-review` | evidence dimension: inspect whether the solution is structurally clean | supports Quality Readiness; not a TP or QA substitute |
+| `agdf-code-review` | evidence dimension: review the actual diff for defects, regression and security findings | supports Quality Readiness; does not replace QA |
 | `agdf-delivery-closeout` | commit/PR-near handoff after QA/OR/UAT | never performs VCS actions automatically |
 | `agdf-gate-check` | new build/change intent, unclear approval, Structured Delivery, later-gate artefact requested | does not create later artefacts or skip Mode/Slice Decision after Brownfield Review |
-| `agdf-qa-gate` | final QA decision | only instance for `pass | revise | block` |
+| `agdf-qa-gate` | sole final Quality Readiness decision | only instance for `pass | revise | block` |
 | `agdf-release-or` | auditable closeout for every relevant run | not a QA substitute |
-| `agdf-task-plan-review` | after implementation and before QA, verify TP coverage | no final QA decision |
+| `agdf-task-plan-review` | evidence dimension: verify whether the approved Task Plan was fulfilled | supports Quality Readiness; no final QA decision |
 
 Select exactly one primary skill first.
 Add more only when they cover a distinct concrete risk dimension.

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

@@ -29,6 +29,27 @@
         "forbidden": "Forbidden now",
         "artefacts": "Artefacts"
       },
+      "qualityReadiness": {
+        "title": "Quality Readiness",
+        "rows": {
+          "plan_coverage": "Plan coverage",
+          "solution_integrity": "Solution integrity",
+          "code_quality": "Code quality",
+          "qa_decision": "QA decision"
+        },
+        "reason": "Reason",
+        "reference": "Evidence report",
+        "nextAction": "Next action",
+        "decisionOwner": "Decision owner",
+        "decisionOwnerValue": "QA Gate",
+        "unknown": "evidence missing",
+        "fallbackReasons": {
+          "plan_coverage": "Plan coverage requires revision before QA can pass.",
+          "solution_integrity": "Solution integrity requires revision before QA can pass.",
+          "code_quality": "Code quality findings require revision before QA can pass.",
+          "qa_decision": "QA evidence requires revision before the gate can pass."
+        }
+      },
       "gateTitles": {
         "UR": "User requirements",
         "PRD": "Product requirements",
@@ -115,6 +136,27 @@
         "forbidden": "Aktuell verboten",
         "artefacts": "Artefakte"
       },
+      "qualityReadiness": {
+        "title": "Quality Readiness",
+        "rows": {
+          "plan_coverage": "Planabdeckung",
+          "solution_integrity": "Lösungsintegrität",
+          "code_quality": "Code-Qualität",
+          "qa_decision": "QA-Entscheidung"
+        },
+        "reason": "Grund",
+        "reference": "Nachweisbericht",
+        "nextAction": "Nächste Aktion",
+        "decisionOwner": "Entscheidungsinstanz",
+        "decisionOwnerValue": "QA-Gate",
+        "unknown": "Nachweis fehlt",
+        "fallbackReasons": {
+          "plan_coverage": "Die Planabdeckung muss vor einem QA-Pass überarbeitet werden.",
+          "solution_integrity": "Die Lösungsintegrität muss vor einem QA-Pass überarbeitet werden.",
+          "code_quality": "Code-Qualitätsbefunde müssen vor einem QA-Pass überarbeitet werden.",
+          "qa_decision": "Die QA-Nachweise müssen vor einem QA-Pass überarbeitet werden."
+        }
+      },
       "gateTitles": {
         "UR": "Nutzeranforderungen",
         "PRD": "Produktanforderungen",

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

@@ -145,15 +145,55 @@ 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.
 
+## Quality Readiness Projection
+
+After CD+Tests, when any of the four review/QA artefacts exists, surfaces may show one compact
+derived `Quality Readiness` projection. It answers the user-facing question "what is the current
+quality outcome and what should happen next?" without replacing evidence or creating another
+decision authority.
+
+- It contains exactly four rows, in this order: `Plan coverage` from `agdf-task-plan-review`,
+  `Solution integrity` from `agdf-clean-implementation-review`, `Code quality` from `agdf-code-review`,
+  and `QA decision` from `agdf-qa-gate`.
+- `agdf-qa-gate` is always labeled as the sole decision owner. The other three rows are evidence
+  dimensions, not competing pass/revise/block decisions.
+- Overall status reuses canonical severity ordering. Missing or conflicting required evidence
+  must not render `pass`; surface `revise` or `block` with the decisive reason and one permitted
+  next action instead.
+- The projection is derived, non-persistent and non-authorizing. It cannot accept an approval,
+  advance a gate, suppress a report or replace the Run Status Card, Gate Transition Card, JSON
+  projection or durable review artefacts.
+- Show compact rows on `pass`. On `revise` or `block`, expand only the decisive row with its
+  canonical report reference; do not paste complete reports into chat.
+
 ## 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.
+Every ready `gate_approval` uses one fixed visible sequence: first the compact
+approval-time Run Status Card, then the Gate Transition Card, then exactly one
+native question or exact-text fallback. Both cards derive from one immutable,
+non-authorizing presentation snapshot produced after canonical selected-run,
+gate and durable-artefact readiness evaluation. The snapshot never selects a
+run, decides a gate, persists state or grants approval.
+
+The two distinct card blocks form one Approval Orientation Envelope in one
+immediately preceding assistant message. The agent must complete that message
+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 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
+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 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
+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:
 
@@ -189,11 +229,13 @@ for example, the German title may be `Lösungsdesign` while the authorization
 value remains `Approval: SD`. Meaning, ordering and authority boundaries are
 identical across locale packs.
 
-The approval-time card must not be a Markdown table or dashboard. It must not
+The Gate Transition 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.
+Run and gate identity may appear in both cards to anchor the shared snapshot;
+status rows, action inventories and transition prose must not be duplicated.
 
 For `Approval: TP`, the effect is permission to run pre-implementation
 Brownfield Analysis, implementation remains gated until that analysis passes,
@@ -359,19 +401,20 @@ response_origin: deliberate_user_input for gate_approval
 This envelope is not a new persisted record. The selected canonical `RUN_STATE.md` and existing artefact chain remain the durable authority.
 
 Before presenting `gate_approval` for any user gate (`UR`, `PRD`, `SD`, `TP`,
-`QA`, or `UAT`), the agent must emit the localized Gate Transition Card as a
-separate, immediately preceding interaction block. The card is not optional,
-not hidden in the question text and not replaced by a host button label.
-Native buttons or exact-text fallback may appear only after this card. The
-underlying Run Status Card fields remain available to evaluation and audit,
-but their dashboard projection must not be pasted into this approval-time
-message.
+`QA`, or `UAT`), the agent must emit the compact localized Run Status Card and
+the localized Gate Transition Card as two distinct blocks in that order within
+one immediately preceding assistant message. Neither card is optional, hidden
+in the question text or replaced by a host button label. Do not invoke the
+native question tool until the complete two-card envelope is visible. Native
+buttons or exact-text fallback may appear only after both cards. Render the two
+cards once per eligible attempt; an unavailable or not-applied native control
+proceeds to exact text without repeating them.
 
 Before presenting `gate_approval`, the agent must:
 
 1. resolve exactly one selected run;
 2. run the canonical gate evaluation and confirm that the current gate's durable artefact is present and ready;
-3. emit the separate localized Gate Transition Card immediately before the gate question, then ask exactly one gate question that identifies `run_id` and `current_gate` and offers the exact approving value `Approval: <GateName>` followed by stable `revise` and `decline` outcomes; host-owned dismissal maps to `cancel` where only three choices are available;
+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;
 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;

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

@@ -62,16 +62,18 @@ For a ready `gate_approval`:
 
 1. Resolve exactly one selected run and evaluate the current gate.
 2. Confirm the required durable artefact is present and ready before presenting a question.
-3. Render a separate localized Gate Transition Card immediately before any native question or exact-text fallback. It includes the deterministic human run title and `UR · PRD · SD · TP` links from the selected run. Never put the card only into the question, button description or hidden tool context.
-4. Treat the operational Run Status Card as evaluation and audit input, not as the approval-time product surface. Do not paste its table, raw keys, machine statuses, evidence or diagnostic detail into the transition card.
-5. Compose the transition card as one human-readable gate title with `run_id`, one ready-for-decision line, one short approval-effect block and one short next-transition block. It must answer only: where am I, what does this decision do, and what happens next.
-6. Distinguish internal process steps from user decisions in natural language. For example, after `Approval: TP`, say that pre-implementation Brownfield Analysis runs next and that no further user action is required now; do not expose `next_user_gate: none` or `user_action_required: no`, and do not ask for a second approval for Brownfield Analysis.
-7. Ask exactly one question that names the selected `run_id` and `current_gate`.
-8. Offer options in stable order: exact `Approval: <GateName>`, localized revise and localized decline. Add explicit cancel only where supported after decline; otherwise host dismissal maps to cancel. Never preselect, skip, auto-submit or reorder an option.
-9. Use the surface adapter declared in the canonical plugin definition only when it can wait for deliberate input without auto-resolution; otherwise request the same exact approval in concise text.
-10. Re-run gate evaluation for the same run and expected gate after the response and immediately before persistence.
-11. Reject a missing artefact, ambiguous or wrong run, wrong gate, stale expected gate, timeout/default, hook-supplied answer, agent message, technical permission outcome or plan approval.
-12. Persist accepted input only through the existing control-state workflow.
+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. 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.
+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; otherwise request the same exact approval in concise text.
+11. Render both cards once in that single complete assistant message. 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.
 
 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.
 
@@ -191,10 +193,12 @@ 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.
+This complete operational status table remains the status-reporting and detail
+surface. When the same response immediately requests a ready gate approval,
+render its six-field compact approval-time projection first, then the Gate
+Transition Card in the same immediately preceding assistant message, then
+invoke exactly one native question or exact-text fallback. Both cards derive
+from the same snapshot and are shown exactly once.
 
 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/.opencode/skills/agdf-qa-gate/SKILL.md

@@ -28,6 +28,13 @@ QA-specific `decision` is exactly `pass | revise | block`.
 `pass` is allowed only when TP coverage, Brownfield fit, solution integrity, and relevant documentation/Context Graph impact are sufficiently evidenced.
 `sot_drift` must not pass silently as a warning.
 
+When post-CD+Tests review evidence exists, present the Runtime Contract's derived Quality
+Readiness projection before the detailed QA report: Plan coverage, Solution integrity, Code
+quality and QA decision in that order. Name `agdf-qa-gate` as the sole decision owner, show one
+decisive reason and one permissible next action, and keep detailed reports as evidence links or
+on-demand detail. The projection is non-authorizing and must not replace the Run Status Card,
+Gate Transition Card or the durable QA report.
+
 ## Rules
 1. No QA pass without strong evidence.
 2. TP is the reference, not merely working code.

package/generated/AGENTS.md

@@ -51,13 +51,13 @@ Structured Delivery Mode must respect gates, reviews and closeout discipline.
 |---|---|---|
 | `agdf-delivery-path-search` | high-impact planning decisions with several plausible next delivery steps before implementation | read-only advisory search; never grants gate permission or replaces gate-check |
 | `agdf-brownfield-analysis` | after gate-check permits Brownfield Review or implementation preparation, before non-trivial changes in existing systems | clarifies reuse, owners, risks and Mode/Slice Decision; never bypasses gate-check; Brownfield Review is not implementation permission |
-| `agdf-clean-implementation-review` | inspect workarounds, fallbacks, parallel structures or symptom fixes | not a TP or QA substitute |
-| `agdf-code-review` | mandatory CR step after code changes, focused on defects, regression and security findings | does not replace TP review, clean review or QA |
+| `agdf-clean-implementation-review` | evidence dimension: inspect whether the solution is structurally clean | supports Quality Readiness; not a TP or QA substitute |
+| `agdf-code-review` | evidence dimension: review the actual diff for defects, regression and security findings | supports Quality Readiness; does not replace QA |
 | `agdf-delivery-closeout` | commit/PR-near handoff after QA/OR/UAT | never performs VCS actions automatically |
 | `agdf-gate-check` | new build/change intent, unclear approval, Structured Delivery, later-gate artefact requested | does not create later artefacts or skip Mode/Slice Decision after Brownfield Review |
-| `agdf-qa-gate` | final QA decision | only instance for `pass | revise | block` |
+| `agdf-qa-gate` | sole final Quality Readiness decision | only instance for `pass | revise | block` |
 | `agdf-release-or` | auditable closeout for every relevant run | not a QA substitute |
-| `agdf-task-plan-review` | after implementation and before QA, verify TP coverage | no final QA decision |
+| `agdf-task-plan-review` | evidence dimension: verify whether the approved Task Plan was fulfilled | supports Quality Readiness; no final QA decision |
 
 Select exactly one primary skill first.
 Add more only when they cover a distinct concrete risk dimension.

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

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

package/generated/plugins/agdf/meta/agdf-agent-router.md

@@ -52,13 +52,13 @@ Structured Delivery Mode must respect gates, reviews and closeout discipline.
 |---|---|---|
 | `delivery-path-search` | high-impact planning decisions with several plausible next delivery steps before implementation | read-only advisory search; never grants gate permission or replaces gate-check |
 | `brownfield-analysis` | after gate-check permits Brownfield Review or implementation preparation, before non-trivial changes in existing systems | clarifies reuse, owners, risks and Mode/Slice Decision; never bypasses gate-check; Brownfield Review is not implementation permission |
-| `clean-implementation-review` | inspect workarounds, fallbacks, parallel structures or symptom fixes | not a TP or QA substitute |
-| `code-review` | mandatory CR step after code changes, focused on defects, regression and security findings | does not replace TP review, clean review or QA |
+| `clean-implementation-review` | evidence dimension: inspect whether the solution is structurally clean | supports Quality Readiness; not a TP or QA substitute |
+| `code-review` | evidence dimension: review the actual diff for defects, regression and security findings | supports Quality Readiness; does not replace QA |
 | `delivery-closeout` | commit/PR-near handoff after QA/OR/UAT | never performs VCS actions automatically |
 | `gate-check` | new build/change intent, unclear approval, Structured Delivery, later-gate artefact requested | does not create later artefacts or skip Mode/Slice Decision after Brownfield Review |
-| `qa-gate` | final QA decision | only instance for `pass | revise | block` |
+| `qa-gate` | sole final Quality Readiness decision | only instance for `pass | revise | block` |
 | `release-or` | auditable closeout for every relevant run | not a QA substitute |
-| `task-plan-review` | after implementation and before QA, verify TP coverage | no final QA decision |
+| `task-plan-review` | evidence dimension: verify whether the approved Task Plan was fulfilled | supports Quality Readiness; no final QA decision |
 
 Select exactly one primary skill first.
 Add more only when they cover a distinct concrete risk dimension.

package/generated/plugins/agdf/meta/agdf-interaction-locales.json

@@ -29,6 +29,27 @@
         "forbidden": "Forbidden now",
         "artefacts": "Artefacts"
       },
+      "qualityReadiness": {
+        "title": "Quality Readiness",
+        "rows": {
+          "plan_coverage": "Plan coverage",
+          "solution_integrity": "Solution integrity",
+          "code_quality": "Code quality",
+          "qa_decision": "QA decision"
+        },
+        "reason": "Reason",
+        "reference": "Evidence report",
+        "nextAction": "Next action",
+        "decisionOwner": "Decision owner",
+        "decisionOwnerValue": "QA Gate",
+        "unknown": "evidence missing",
+        "fallbackReasons": {
+          "plan_coverage": "Plan coverage requires revision before QA can pass.",
+          "solution_integrity": "Solution integrity requires revision before QA can pass.",
+          "code_quality": "Code quality findings require revision before QA can pass.",
+          "qa_decision": "QA evidence requires revision before the gate can pass."
+        }
+      },
       "gateTitles": {
         "UR": "User requirements",
         "PRD": "Product requirements",
@@ -115,6 +136,27 @@
         "forbidden": "Aktuell verboten",
         "artefacts": "Artefakte"
       },
+      "qualityReadiness": {
+        "title": "Quality Readiness",
+        "rows": {
+          "plan_coverage": "Planabdeckung",
+          "solution_integrity": "Lösungsintegrität",
+          "code_quality": "Code-Qualität",
+          "qa_decision": "QA-Entscheidung"
+        },
+        "reason": "Grund",
+        "reference": "Nachweisbericht",
+        "nextAction": "Nächste Aktion",
+        "decisionOwner": "Entscheidungsinstanz",
+        "decisionOwnerValue": "QA-Gate",
+        "unknown": "Nachweis fehlt",
+        "fallbackReasons": {
+          "plan_coverage": "Die Planabdeckung muss vor einem QA-Pass überarbeitet werden.",
+          "solution_integrity": "Die Lösungsintegrität muss vor einem QA-Pass überarbeitet werden.",
+          "code_quality": "Code-Qualitätsbefunde müssen vor einem QA-Pass überarbeitet werden.",
+          "qa_decision": "Die QA-Nachweise müssen vor einem QA-Pass überarbeitet werden."
+        }
+      },
       "gateTitles": {
         "UR": "Nutzeranforderungen",
         "PRD": "Produktanforderungen",

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

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
   "id": "agdf",
-  "version": "0.8.2",
+  "version": "0.8.3",
   "displayName": "AI Governance & Delivery Framework",
   "developerName": "Arndt Gold",
   "description": "Codex-first operating system for governed AI-assisted delivery.",
@@ -153,14 +153,14 @@
     {
       "slug": "clean-implementation-review",
       "discovery": "automatic",
-      "useFor": "inspect workarounds, fallbacks, parallel structures or symptom fixes",
-      "boundary": "not a TP or QA substitute"
+      "useFor": "evidence dimension: inspect whether the solution is structurally clean",
+      "boundary": "supports Quality Readiness; not a TP or QA substitute"
     },
     {
       "slug": "code-review",
       "discovery": "automatic",
-      "useFor": "mandatory CR step after code changes, focused on defects, regression and security findings",
-      "boundary": "does not replace TP review, clean review or QA"
+      "useFor": "evidence dimension: review the actual diff for defects, regression and security findings",
+      "boundary": "supports Quality Readiness; does not replace QA"
     },
     {
       "slug": "delivery-closeout",
@@ -177,7 +177,7 @@
     {
       "slug": "qa-gate",
       "discovery": "automatic",
-      "useFor": "final QA decision",
+      "useFor": "sole final Quality Readiness decision",
       "boundary": "only instance for `pass | revise | block`"
     },
     {
@@ -189,8 +189,8 @@
     {
       "slug": "task-plan-review",
       "discovery": "automatic",
-      "useFor": "after implementation and before QA, verify TP coverage",
-      "boundary": "no final QA decision"
+      "useFor": "evidence dimension: verify whether the approved Task Plan was fulfilled",
+      "boundary": "supports Quality Readiness; no final QA decision"
     }
   ],
   "marketplaces": {

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

@@ -145,15 +145,55 @@ 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.
 
+## Quality Readiness Projection
+
+After CD+Tests, when any of the four review/QA artefacts exists, surfaces may show one compact
+derived `Quality Readiness` projection. It answers the user-facing question "what is the current
+quality outcome and what should happen next?" without replacing evidence or creating another
+decision authority.
+
+- It contains exactly four rows, in this order: `Plan coverage` from `task-plan-review`,
+  `Solution integrity` from `clean-implementation-review`, `Code quality` from `code-review`,
+  and `QA decision` from `qa-gate`.
+- `qa-gate` is always labeled as the sole decision owner. The other three rows are evidence
+  dimensions, not competing pass/revise/block decisions.
+- Overall status reuses canonical severity ordering. Missing or conflicting required evidence
+  must not render `pass`; surface `revise` or `block` with the decisive reason and one permitted
+  next action instead.
+- The projection is derived, non-persistent and non-authorizing. It cannot accept an approval,
+  advance a gate, suppress a report or replace the Run Status Card, Gate Transition Card, JSON
+  projection or durable review artefacts.
+- Show compact rows on `pass`. On `revise` or `block`, expand only the decisive row with its
+  canonical report reference; do not paste complete reports into chat.
+
 ## 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.
+Every ready `gate_approval` uses one fixed visible sequence: first the compact
+approval-time Run Status Card, then the Gate Transition Card, then exactly one
+native question or exact-text fallback. Both cards derive from one immutable,
+non-authorizing presentation snapshot produced after canonical selected-run,
+gate and durable-artefact readiness evaluation. The snapshot never selects a
+run, decides a gate, persists state or grants approval.
+
+The two distinct card blocks form one Approval Orientation Envelope in one
+immediately preceding assistant message. The agent must complete that message
+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 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
+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 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
+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:
 
@@ -189,11 +229,13 @@ for example, the German title may be `Lösungsdesign` while the authorization
 value remains `Approval: SD`. Meaning, ordering and authority boundaries are
 identical across locale packs.
 
-The approval-time card must not be a Markdown table or dashboard. It must not
+The Gate Transition 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.
+Run and gate identity may appear in both cards to anchor the shared snapshot;
+status rows, action inventories and transition prose must not be duplicated.
 
 For `Approval: TP`, the effect is permission to run pre-implementation
 Brownfield Analysis, implementation remains gated until that analysis passes,
@@ -359,19 +401,20 @@ response_origin: deliberate_user_input for gate_approval
 This envelope is not a new persisted record. The selected canonical `RUN_STATE.md` and existing artefact chain remain the durable authority.
 
 Before presenting `gate_approval` for any user gate (`UR`, `PRD`, `SD`, `TP`,
-`QA`, or `UAT`), the agent must emit the localized Gate Transition Card as a
-separate, immediately preceding interaction block. The card is not optional,
-not hidden in the question text and not replaced by a host button label.
-Native buttons or exact-text fallback may appear only after this card. The
-underlying Run Status Card fields remain available to evaluation and audit,
-but their dashboard projection must not be pasted into this approval-time
-message.
+`QA`, or `UAT`), the agent must emit the compact localized Run Status Card and
+the localized Gate Transition Card as two distinct blocks in that order within
+one immediately preceding assistant message. Neither card is optional, hidden
+in the question text or replaced by a host button label. Do not invoke the
+native question tool until the complete two-card envelope is visible. Native
+buttons or exact-text fallback may appear only after both cards. Render the two
+cards once per eligible attempt; an unavailable or not-applied native control
+proceeds to exact text without repeating them.
 
 Before presenting `gate_approval`, the agent must:
 
 1. resolve exactly one selected run;
 2. run the canonical gate evaluation and confirm that the current gate's durable artefact is present and ready;
-3. emit the separate localized Gate Transition Card immediately before the gate question, then ask exactly one gate question that identifies `run_id` and `current_gate` and offers the exact approving value `Approval: <GateName>` followed by stable `revise` and `decline` outcomes; host-owned dismissal maps to `cancel` where only three choices are available;
+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;
 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;

package/generated/plugins/agdf/skills/delivery-path-search/help.md

@@ -1,5 +1,23 @@
-# Delivery Path Search
+## NAME
 
-Use this workflow before implementation when competing high-impact delivery paths need an evidence-backed comparison.
+`delivery-path-search` - delivery path search
 
-It is read-only and advisory. The canonical AGDF gate-check still decides what may happen next.
+## SYNOPSIS
+
+`/delivery-path-search` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Compares materially different high-impact delivery paths using scope, risk, evidence, tests, cost, and gate readiness. The result is advisory and read-only; canonical AGDF `gate-check` remains the authority for what may happen next.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /delivery-path-search
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, enforcement levels, bounded search rules, and output requirements.

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

@@ -62,16 +62,18 @@ For a ready `gate_approval`:
 
 1. Resolve exactly one selected run and evaluate the current gate.
 2. Confirm the required durable artefact is present and ready before presenting a question.
-3. Render a separate localized Gate Transition Card immediately before any native question or exact-text fallback. It includes the deterministic human run title and `UR · PRD · SD · TP` links from the selected run. Never put the card only into the question, button description or hidden tool context.
-4. Treat the operational Run Status Card as evaluation and audit input, not as the approval-time product surface. Do not paste its table, raw keys, machine statuses, evidence or diagnostic detail into the transition card.
-5. Compose the transition card as one human-readable gate title with `run_id`, one ready-for-decision line, one short approval-effect block and one short next-transition block. It must answer only: where am I, what does this decision do, and what happens next.
-6. Distinguish internal process steps from user decisions in natural language. For example, after `Approval: TP`, say that pre-implementation Brownfield Analysis runs next and that no further user action is required now; do not expose `next_user_gate: none` or `user_action_required: no`, and do not ask for a second approval for Brownfield Analysis.
-7. Ask exactly one question that names the selected `run_id` and `current_gate`.
-8. Offer options in stable order: exact `Approval: <GateName>`, localized revise and localized decline. Add explicit cancel only where supported after decline; otherwise host dismissal maps to cancel. Never preselect, skip, auto-submit or reorder an option.
-9. Use the surface adapter declared in the canonical plugin definition only when it can wait for deliberate input without auto-resolution; otherwise request the same exact approval in concise text.
-10. Re-run gate evaluation for the same run and expected gate after the response and immediately before persistence.
-11. Reject a missing artefact, ambiguous or wrong run, wrong gate, stale expected gate, timeout/default, hook-supplied answer, agent message, technical permission outcome or plan approval.
-12. Persist accepted input only through the existing control-state workflow.
+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. 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.
+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; otherwise request the same exact approval in concise text.
+11. Render both cards once in that single complete assistant message. 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.
 
 Before composing the question, resolve the configured chat locale from `.agdf/control/config.json` through `plugin/meta/agdf-interaction-locales.json`: exact complete pack, language subtag, then English fallback. German and English are initial packs, not a closed language list. Keep `Approval: <GateName>` exactly unchanged in every language, and do not mix presentation languages within one interaction. Labels and descriptions use the same resolved locale; host-owned UI chrome remains host-owned and may use a different language.
 
@@ -191,10 +193,12 @@ 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.
+This complete operational status table remains the status-reporting and detail
+surface. When the same response immediately requests a ready gate approval,
+render its six-field compact approval-time projection first, then the Gate
+Transition Card in the same immediately preceding assistant message, then
+invoke exactly one native question or exact-text fallback. Both cards derive
+from the same snapshot and are shown exactly once.
 
 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/skills/qa-gate/SKILL.md

@@ -28,6 +28,13 @@ QA-specific `decision` is exactly `pass | revise | block`.
 `pass` is allowed only when TP coverage, Brownfield fit, solution integrity, and relevant documentation/Context Graph impact are sufficiently evidenced.
 `sot_drift` must not pass silently as a warning.
 
+When post-CD+Tests review evidence exists, present the Runtime Contract's derived Quality
+Readiness projection before the detailed QA report: Plan coverage, Solution integrity, Code
+quality and QA decision in that order. Name `qa-gate` as the sole decision owner, show one
+decisive reason and one permissible next action, and keep detailed reports as evidence links or
+on-demand detail. The projection is non-authorizing and must not replace the Run Status Card,
+Gate Transition Card or the durable QA report.
+
 ## Rules
 1. No QA pass without strong evidence.
 2. TP is the reference, not merely working code.

package/lib/interaction-presentation.js

@@ -2,6 +2,14 @@ const REQUIRED_GATES = ["UR", "PRD", "SD", "TP", "QA", "UAT"];
 const ARTEFACT_ORDER = ["UR", "PRD", "SD", "TP"];
 const OUTCOMES = new Set(["approve", "revise", "decline", "cancel", "no_response", "timeout", "empty", "invalid", "stale"]);
 const ATTEMPT_OUTCOMES = new Set(["presented", "unavailable_before_invocation", "attempted_not_applied", "unsafe_to_wait"]);
+const APPROVAL_SEQUENCE = Object.freeze(["run_status_card", "gate_transition_card", "approval_interaction"]);
+const QUALITY_STATUS_RANK = { pass: 0, warn: 1, revise: 2, block: 3 };
+const QUALITY_DIMENSIONS = Object.freeze([
+  Object.freeze({ id: "plan_coverage", owner: "task-plan-review" }),
+  Object.freeze({ id: "solution_integrity", owner: "clean-implementation-review" }),
+  Object.freeze({ id: "code_quality", owner: "code-review" }),
+  Object.freeze({ id: "qa_decision", owner: "qa-gate" }),
+]);
 
 function plainObject(value) {
   return value && typeof value === "object" && !Array.isArray(value);
@@ -55,7 +63,7 @@ export function validateLocaleRegistry(registry) {
     for (const [key, value] of visibleStrings(pack)) {
       if (!value.trim()) errors.push(`empty_copy:${locale}:${key}`);
       const budget = key.startsWith("gateTitles.") ? budgets.title
-        : key.includes("Description") || key.startsWith("primary.actions.") || key.startsWith("primary.afterApproval.") || key === "primary.quality"
+        : key.includes("Description") || key.includes("fallbackReasons") || key.startsWith("primary.actions.") || key.startsWith("primary.afterApproval.") || key === "primary.quality"
           ? budgets.description
           : budgets.label;
       if (Number.isInteger(budget) && value.length > budget) errors.push(`length_budget:${locale}:${key}`);
@@ -203,8 +211,111 @@ export function normalizeInteractionOutcome(value, { expectedApproval, stale = f
   return "invalid";
 }
 
+export function buildApprovalOrientationSnapshot({
+  ready = false,
+  statusCard,
+  humanPresentation,
+  revisionId = "",
+  registry,
+  requestedLocale,
+} = {}) {
+  if (!ready || !plainObject(statusCard) || !plainObject(humanPresentation)) return null;
+  const gate = String(statusCard.current_gate ?? "").trim();
+  const runId = String(statusCard.run_id ?? "").trim();
+  const expectedApproval = `Approval: ${gate}`;
+  if (!REQUIRED_GATES.includes(gate) || !runId || statusCard.status !== "open" || statusCard.missing_approval !== expectedApproval) return null;
+
+  const locale = resolvePresentationLocale(registry, requestedLocale);
+  const pack = localePack(registry, locale);
+  const runTitle = String(humanPresentation.runTitle ?? "").trim() || normalizedRunTitle(runId);
+  const currentGateTitle = String(humanPresentation.gateTitle ?? "").trim() || gateTitle(registry, locale, gate);
+  const artefactRefs = Object.freeze([...(humanPresentation.artefactRefs ?? [])].map((ref) => Object.freeze({ ...ref })));
+  const statusFields = Object.freeze([
+    Object.freeze({ id: "selected_run", label: pack.statusCard.run, value: `${runTitle} · ${runId}` }),
+    Object.freeze({ id: "readiness_status", label: pack.statusCard.title, value: pack.interaction.ready }),
+    Object.freeze({ id: "current_gate", label: pack.statusCard.gate, value: `${gate} — ${currentGateTitle}` }),
+    Object.freeze({ id: "missing_approval", label: pack.statusCard.missing, value: expectedApproval }),
+    Object.freeze({ id: "next_action", label: pack.statusCard.step, value: pack.primary.actions[gate] ?? String(statusCard.next_step ?? "") }),
+    Object.freeze({ id: "quality_outlook", label: pack.statusCard.quality, value: pack.primary.quality }),
+  ]);
+  const options = Object.freeze(gateOptions(registry, locale, gate).map((option) => Object.freeze({ ...option })));
+
+  return Object.freeze({
+    schema_version: "1",
+    run_id: runId,
+    revision_id: String(revisionId ?? "").trim(),
+    current_gate: gate,
+    presentation_language: locale,
+    sequence: APPROVAL_SEQUENCE,
+    compact_status_card: Object.freeze({ title: pack.statusCard.title, fields: statusFields }),
+    gate_transition_card: Object.freeze({
+      title: `${currentGateTitle} · ${runTitle} · ${runId}`,
+      artefact_refs: artefactRefs,
+      ready: pack.interaction.ready,
+      approve_heading: pack.interaction.approveHeading,
+      exact_approval: expectedApproval,
+      approval_effect: pack.primary.afterApproval[gate] ?? pack.primary.actions[gate] ?? "",
+      next_heading: pack.interaction.nextHeading,
+      next_gate: String(statusCard.next_gate_after_approval ?? "none"),
+    }),
+    approval_interaction: Object.freeze({ expected_approval: expectedApproval, options, authorizes: false }),
+    authorizes: false,
+  });
+}
+
+export function attachApprovalOrientationSnapshot(statusCard, options = {}) {
+  if (!plainObject(statusCard)) throw new Error("approval orientation status card missing");
+  const snapshot = buildApprovalOrientationSnapshot({ ...options, statusCard });
+  Object.defineProperty(statusCard, "approvalOrientation", {
+    value: snapshot,
+    enumerable: false,
+  });
+  return snapshot;
+}
+
+function qualityStatus(value) {
+  const normalized = String(value ?? "").trim().toLowerCase();
+  return Object.hasOwn(QUALITY_STATUS_RANK, normalized) ? normalized : "unknown";
+}
+
+export function buildQualityReadiness({
+  planCoverage,
+  solutionIntegrity,
+  codeQuality,
+  qaDecision,
+  decisiveReason = "",
+  nextAction = "",
+} = {}) {
+  const values = [planCoverage, solutionIntegrity, codeQuality, qaDecision];
+  const rows = QUALITY_DIMENSIONS.map((dimension, index) => Object.freeze({
+    ...dimension,
+    status: qualityStatus(values[index]),
+  }));
+  const known = rows.filter((row) => row.status !== "unknown");
+  if (known.length === 0) return null;
+  const status = rows.some((row) => row.status === "unknown")
+    ? "revise"
+    : known.reduce((current, row) =>
+      QUALITY_STATUS_RANK[row.status] > QUALITY_STATUS_RANK[current] ? row.status : current,
+    "pass");
+  const decisiveRow = rows.find((row) => row.status === status && status !== "pass")
+    ?? rows.find((row) => row.id === "qa_decision")
+    ?? rows[0];
+  return Object.freeze({
+    status,
+    rows: Object.freeze(rows),
+    decisive_reason: String(decisiveReason ?? "").trim(),
+    decisive_dimension: decisiveRow.id,
+    next_action: String(nextAction ?? "").trim(),
+    decision_owner: "qa-gate",
+    authorizes: false,
+  });
+}
+
 export const interactionPresentationConstants = Object.freeze({
   artefactOrder: Object.freeze([...ARTEFACT_ORDER]),
   outcomes: Object.freeze([...OUTCOMES]),
   attemptOutcomes: Object.freeze([...ATTEMPT_OUTCOMES]),
+  approvalSequence: APPROVAL_SEQUENCE,
+  qualityDimensions: QUALITY_DIMENSIONS,
 });

package/package.json

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