create-agdf 0.14.4 → 0.20.0

package/generated/plugins/agdf/meta/contracts/control-scaffold.md

@@ -56,9 +56,19 @@ Repository-level discovery is derived; do not maintain a writable active-run das
 closed. Legacy `AGDF_RUN.md` is migration input or an explicitly rendered non-authoritative projection,
 never a second writable owner. Read-only commands must not migrate state.
 
+`run-create` writes a sealed run. The seal covers the run state and every file listed under
+Artefacts; an unrecorded edit blocks `doctor` and `gate-check` with `AGDF_RUN_SEAL_MISMATCH`. After
+changing either, call `run-update --run <run_id> --revision <revision_id>` before `gate-check`; it
+advances the revision and refuses Approvals changes. Only `run-approve` records an approval. Both run
+on the surface-local validator. The seal detects unrecorded edits; it is not a signature.
+Keep one `Artefacts` row per type: update the existing placeholder row instead of appending another.
+`run-update` and all run writers reject duplicate rows without advancing the revision. Remove the
+extra row and retry `run-update` to record the correction. Duplicate rows in older sealed runs also
+block `doctor` and gate presentation.
+
 When a repository needs durable AGDF state, use the plugin-local `control/` scaffold as the starting point.
 
-- `config.json` stores project language preferences. Use `artifact_language` for generated AGDF artefacts and `chat_language` for user-facing responses unless the user explicitly asks otherwise. Runtime rules remain English.
+- `config.json` stores project language preferences. Use `artifact_language` for generated AGDF artefacts. `chat_language` is the direct-command presentation default; dispatcher calls supply `presentation_language` under their current-request language contract. This presentation override never changes `artifact_language`. Runtime rules remain English. Authoring continuations supply the resolved languages and any required localized approval-summary heading before drafting.
 - `.agdf/control/runs/<run_id>/RUN_STATE.md` is the canonical current-run dashboard; legacy `AGDF_RUN.md` is migration input or an explicit non-authoritative projection.
 - `MASTER_BACKLOG.md` is the living pointer for active delivery work.
 - `BROWNFIELD_REVIEW.md` records the post-UR existing-system view and Mode/Slice Decision before PRD depth or Quick Task execution is chosen.
@@ -92,15 +102,18 @@ AGDF is agent-native first and CLI-verifiable by design.
 
 The primary operating path is the active skill plus the live `.agdf/control/` artefacts.
 Agents should read the repository state, apply this Runtime Contract, create or update only the currently allowed artefact, and make the next permissible step explicit.
-When control state is missing for a fresh request, keep the first step lightweight: draft the minimal UR in the response and request `Approval: UR`.
+When control state is missing, follow the existing setup/link boundary before run creation.
+After a concrete run is bound, dispatch delegates requirement drafting to `ur-definition`.
+Only fresh canonical readiness and a run-present binding may request `Approval: UR`.
+This branch is unreachable for `target_unresolved`.
 Initialize a control scaffold only when durable AGDF control state is explicitly requested, already used by the repository, or required by a deterministic CLI/CI setup path.
 
 Helper commands are deterministic proof and automation interfaces, not the normal-work ritual:
 
 - `init` creates the machine-readable control scaffold.
-- `doctor --json` checks whether `.agdf/control/` is consistent and actionable; it is not the reviewer.
+- `doctor --json` checks whether `.agdf/control/` is consistent and actionable; it is not the reviewer. On a host that lists the AGDF MCP server, the read-only tool `agdf_inspect` (`operation: doctor | gate-check | delivery-map | contract`) returns the same `--json` object and canonical Markdown without a shell; the shell binding stays the fallback. It never writes control state or prepares an approval binding.
 - `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.
+- `gate-check --approval-envelope` prints a read-only summary and link to the current artefact. The agent uses `run-present` before asking for an exact gate approval.
 - `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.

package/generated/plugins/agdf/meta/contracts/gate-artifact-preparation.md

@@ -0,0 +1,132 @@
+# AGDF Runtime Contract — Gate Artifact Preparation
+
+This contract guides the `gate-check` skill when canonical gate evaluation returns
+`control.next_operation.type: prepare_gate_artifact`. It is procedural guidance only; canonical
+Run State, gate evaluation and exact approval remain authoritative.
+
+## Common Route
+
+- Use only the supplied `gate`, `artifact_path`, `template_path`, `source_artifacts`, `target`,
+  `run_id` and `revision_id`. `template_path` is the absolute canonical authoring template from the
+  installed, version-matched plugin for PRD, SD, TP or QA Report preparation. Repository scaffold
+  copies are derived references only. Do not rediscover or substitute a run, target, source
+  artifact or template. A missing or unsafe template blocks authoring without fallback or mutation.
+- Prepare only the named current-gate artifact from the supplied approved sources.
+  Record with `run-step --step artefact --gate <PRD|SD|TP|QA>
+  --evidence .agdf/control/artefacts/<run_id>/<input.json> --run <run_id> --revision <revision_id>`.
+  Do not publish a pointer and its required source relationship in separate accepted revisions.
+- After persistence, redispatch `gate-check` for the same target/run and use its fresh revision,
+  gate route and approval presentation. Do not reuse this operation or ask for approval until the
+  fresh dispatcher result supplies a valid presentation.
+- If a source is missing, a prerequisite is unresolved, the state changed, or persistence fails, stop
+  dependent authoring. Use interaction.md Bounded internal recovery only for its dispatched eligible
+  analytical owner; other conditions stay blocked. Never infer approval or create later-gate work.
+
+## Reviewed Recording Input (version 1)
+
+### Language and approval summary preparation
+
+Use the supplied `artifact_language` from `.agdf/control/config.json` for the artefact and
+the resolved `presentation_language` for user-facing text. The configured chat language is
+the direct-command default; dispatcher presentation input follows its current-request contract.
+Neither the request language nor English runtime/template text changes the artefact language.
+When `approval_summary_required` is true, before recording include exactly one
+`## <approval_summary_heading>` section with the supplied heading verbatim and a complete
+summary in the resolved presentation language. Apply the existing interaction contract's
+summary completeness and size limits; use no ellipses or hidden decision-relevant omissions.
+For PRD include user goal, scope, every canonical criterion ID exactly once, and decision context
+when approval decisions exist. Corrections use the existing permitted recording/revision path
+and require a fresh presentation. The summary grants no approval and is not another authority.
+
+Before recording, prefer the existing read-only MCP tool `agdf_inspect` with
+`operation: artifact-readiness`, `presentation_language`, `working_directory`, the resolved
+`primary_target`/`target_source`, and the supplied `run_id`, `gate` and `expected_revision_id`.
+Supported draft gates are `UR | PRD | SD | TP`. The Core derives the contained run-local
+`<gate>.md` path; there is no caller-supplied arbitrary path or implicit Run selection.
+This operation calls the existing summary, product-decision and traceability validators.
+The response has `report.ready`, `checks`, concrete `diagnostics`, `artifact_path`,
+`artifact_digest`, current/expected revision and `next_action`; `authorizes` is always false.
+`ready` covers authoring checks only: it neither records the draft nor establishes semantic
+derivation, source-binding proof, final QA, presentation or approval readiness. Missing source,
+stale revision, approved source or canonical integrity/gate blockers keep it unready. Resolve
+the named issue through its existing owner. No recording or approval follows from this result
+alone. Registration and run-present repeat their own current canonical checks.
+
+Without that MCP capability, use the exact Core function
+`inspectArtifactReadiness(root, { runId, gate, expectedRevisionId, presentationLanguage })`
+in `packages/core/lib/control-inspect/artifact-readiness.js` (packaged as
+`runtime/create-agdf/runtime/core/lib/control-inspect/artifact-readiness.js` in the plugin). Same report; no writes.
+Do not search for internal validator signatures or invent a replacement validator.
+The existing Core `evaluateApprovalSummaryReadiness` remains the summary owner.
+For a German PRD summary use separate `- Ziel:`, `- Umfang:` and, when decisions exist,
+`- Entscheidungen:` lines; English summaries use `- Goal:`, `- Scope:` and `- Decisions:`.
+Each criterion has its own `- AC-...:` line. A combined label such as `Ziel und Umfang:` or
+`Entscheidungskontext:` is not one of these fields. Readiness and presentation share this validator;
+do not accept prose as a substitute or invent another parser. An eligible own unapproved format
+correction stays with the existing authoring continuation, once per diagnosed condition, followed
+by canonical replacement and fresh evaluation. A ready draft still needs actual editing intent;
+status is read-only, protected sources and unrelated blockers remain stopped.
+
+Prepare files under `.agdf/control/artefacts/<run_id>/` before recording. The single shared Core
+relationship registry selects PRD-derived_from-UR, SD-derived_from-PRD, TP-derived_from-SD or
+QA_REPORT-tests-TP. UR-approved_by remains exclusively approval-owned. QA recording copies an
+existing report's explicit Decision/Status value (`pass | revise | block`); it does not decide QA.
+
+The JSON object has exactly these fields:
+
+- `schema_version`: string `1`.
+- `target_id`: existing local command-target identity, SHA-256 of `agdf-command-target/1`, NUL,
+  and the canonical real absolute governance target. This is a binding, not authority.
+- `run_id`, `expected_revision_id`: the supplied selected run and current revision.
+- `destination`: exactly `type`, `path`, `digest`, `status`; logical registry type, canonical
+  run-local `<type>.md`, full canonical SHA-256 and `draft` for PRD/SD/TP, report decision for QA.
+- `source`: exactly `type`, `path`, `digest`; the registry's approved source and canonical digest.
+- `relationship`: exactly `from`, `relationship`, `to`; the explicit registry triple.
+- `review`: exactly `reviewer`, `path`, `digest`; named reviewer, separate contained mapping file
+  and its canonical SHA-256. Do not overwrite an earlier sealed proof file.
+- `update_draft`: boolean; true only for an explicit current-gate draft update.
+
+The mapping file is JSON with exactly `schema_version`, `target_id`, `run_id`, `relationship`,
+`destination`, `source`, `reviewer`, `reviewed`. Identity and source/destination objects match
+the recording input exactly; reviewer matches review.reviewer, and reviewed is boolean true.
+Digests use the existing canonical text/line-ending semantics. This is cooperative review
+attestation, never independent proof of a human review or semantic derivation. QA/review assesses
+the meaning. A prose header or gate order is not machine proof.
+
+The existing operation checks current permission, contained non-symlink files, exact approved
+sources and revision under locks. It appends its sealed Artefact Bindings receipt/history and
+publishes pointer, relationship and audit together. The receipt is writer-owned; do not hand-author
+it. An allowed draft replacement supersedes the prior active binding, retaining history. A changed
+draft is accepted only when its prior binding reconstructs the recorded seal and every other
+bound/approved byte remains unchanged. Otherwise stop with explicit maintenance/revision recovery.
+
+Before presentation/approval, a recorded eligible current artefact must have its evidenced source
+relationship. Missing artefacts remain draftable; a relationship-only blocker must not redraft the
+artefact repeatedly. Only authorized bound continuation can attempt one exact previously sealed
+proof correction before output. The shared Core continuation service coordinates this operation
+and fresh routing; the dispatcher service itself only reads and routes. Explicit status, doctor,
+evaluation and run-present never correct.
+Unknown/malformed/foreign/stale/ambiguous proof, missing full approval integrity or unrelated
+blockers remain blocked; legacy absence grants no correction permission. A successful correction
+creates a new audited revision and fresh evaluation without another approval. Terminal output
+already emitted is never intercepted. Older runtimes have no automatic correction capability.
+
+## Gate-Specific Work
+
+### PRD
+
+Semantic PRD drafting and clarification belongs exclusively to prd-definition under its focused
+contract. This module supplies the shared Reviewed Recording Input procedure only; gate-check
+controls prerequisites, readiness and presentation.
+
+### SD
+
+Semantic SD drafting and clarification belongs exclusively to sd-definition under its focused
+contract. This module supplies the shared Reviewed Recording Input procedure only; gate-check
+controls prerequisites, declared decision readiness, traceability and presentation.
+
+### TP
+
+Semantic TP drafting, clarification and explicit unapproved revision belong exclusively to
+tp-definition under its focused contract. This module supplies shared recording only; gate-check
+retains prerequisite/readiness and presentation authority.

package/generated/plugins/agdf/meta/contracts/gate-transition.md

@@ -56,12 +56,30 @@ They must not override AGDF gates, approvals or the Runtime Contract.
 - For UR, PRD, SD, TP and QA, approval and durable artefact presence are separate requirements. A gate is not satisfied by approval text alone when its artefact is missing from `.agdf/control/` or not linked to the authoritative repository SoT.
 - Approval of one user gate permits work on the next allowed gate artefact or required internal step only. It does not permit implementation unless the approved gate is `TP` and required internal implementation prerequisites are satisfied.
 - Gates must never be skipped or inferred from urgency, tone, chat history, task wording or an instruction to "start". The next allowed action is always the next unsatisfied gate or internal mandatory step.
-- Missing control files or missing current-state fields do not forbid the agent from preparing the current allowed artefact. They forbid later-gate work and implementation. For a fresh request, the default allowed work is to draft a minimal UR in the response and request `Approval: UR`. Initialize or write `.agdf/control/` 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.
+- After positive Request Activation and task-target resolution, missing control files or missing
+  current-state fields do not forbid drafting the current minimal UR when the turn supplies a concrete
+  outcome. They do forbid later-gate work, implementation and every gate-approval request. Obtain
+  explicit setup or link authority, initialize or link canonical control and persist a revision-stable
+  UR first; only then may revalidation determine whether `Approval: UR` is ready. This branch is
+  unreachable for `target_unresolved` and never creates a free-standing legacy live run.
+- Brownfield Review and its route may be recorded while the UR card is ready, so that card can name the next gate; this grants nothing beyond the pending `Approval: UR`.
 - `Approval: UR` permits Brownfield Review after G-00 first. The review records its Mode/Slice Decision in the same internal operation when evidence is sufficient; the user is told that no action is required now. A separate `Mode/Slice Decision` step is fail-closed recovery for incomplete or legacy review state, not a normal user decision. UR approval never permits implementation by itself and does not preselect PRD.
 - PRD, SD and TP depth is chosen after Brownfield Review through the Mode/Slice Decision, not before existing-system impact is understood.
 - The Mode/Slice Decision must be visible before any PRD shortcut, Quick Task execution or implementation: record the decision, required next gate, scope reason and evidence in the selected canonical `RUN_STATE.md` or an equivalent linked control artefact.
 - `Approval: PRD` permits Solution Design drafting, not implementation.
+- Before presenting a PRD approval, the PRD `Approval Decisions` table must resolve every `before_prd` product, acceptance, owner and release-scope decision and name its PRD owner. Collect related missing answers in one request. `later_sd` and `later_tp` rows may remain open only with a named owner; they cannot silently carry a product decision past PRD approval. The runtime suppresses `run-present` and `run-approve` when PRD readiness is open.
+- The `criteria-chain-v1` contract keeps PRD acceptance as the sole product source: every PRD criterion has one stable `criterion_id`; SD maps every criterion exactly once to its design, source-of-truth owner, decision and compatibility/risk treatment; TP maps every criterion and SD decision to task IDs, scenario IDs, expected results and evidence. Existing gate readiness checks suppress the SD or TP presentation when a marked artefact has incomplete or inconsistent mappings. Do not create a parallel acceptance register or copy acceptance prose downstream.
+- A clarification after approval that does not change approved scope, behavior or acceptance may be attributed as run evidence without changing the approved PRD. The no-mode `run-revise --run <run_id> --revision <revision_id>` remains the early PRD-to-SD revision path before downstream artefacts are linked. It requires a revised PRD, new `run-present` and a new deliberate `Approval: PRD`.
+- Versioned approved-source revision uses the existing `source_revision.preview` then separately confirmed `source_revision.apply` owner. Proposal schema 2 and receipt schema 3 bind `policy_version: 2`, original initiating phase, concrete source statements, exact quality/source-set/result assessment and full impact/quality digests. In an active structured Run before deliberate UAT approval, UR may reopen from PRD/SD/TP/CD+Tests/QA/pending UAT; PRD from SD/TP/CD+Tests/QA/pending UAT; SD from TP/CD+Tests/QA/pending UAT; TP from CD+Tests/QA/pending UAT. The actually approved earliest changed statement determines the source, never the phase or a keyword. Unknown or conflicting upstream intent requires clarification; pure implementation defects with unchanged sources stay under the valid TP and checks. Unapproved drafts use existing authoring/update, not approved-source revision.
+- New preview binds exact target/Run/revision/UUID, reviewed proposal, source bytes, registered quality facts and impact. Unchanged verified upstream approvals remain exact; selected and transitive downstream source approvals/bindings require renewal. Affected or unknown analytical/quality fulfillment is reassessed; UR requires fresh post-UR Review/Mode and required UX. Lower-source analytical retention requires exact current writer-owned applicability and specific rationale. Archive affected reports, approvals and presentations before atomic application under existing locks/journal; affected QA report and approval lose current authority together, and pending old UAT material is superseded. Fresh applicable checks/reviews and QA precede renewed UAT. Deliberate UAT approval, done OR, completed/closed/foreign/stale/damaged or incompatible pending state prohibits this path.
+- Legacy proposal schema 1 and source receipt schemas 1/2 keep their original predicates: active structured CD+Tests before QA/UAT, or UR at SD with approved UR/PRD and linked draft SD before downstream work. Historical verification selects the original receipt policy and archived initiating state; never widen old proof retrospectively or rewrite its bytes. Unsupported new versions reject concretely. The existing early PRD reopening boundary remains unchanged.
+- Under legacy policy 1, the same explicit preview/apply owner also supports UR revision in an active structured Run at SD with exact approved UR/PRD and a linked, reviewed draft SD, before SD approval, linked TP, implementation, reviews or closeout. Its reviewed proposal binds the current UR/PRD/SD sources, marks applicable analyses for reassessment and returns the same Run to UR. Other cases remain unsupported by legacy policy 1; expanded cases require the version 2 proposal and proof. The no-mode PRD boundary is unchanged. The canonical fixed-group MCP revision facade uses the same reviewed preview/apply owner and deliberate confirmation; it grants no gate approval.
+- Source revision apply archives the exact previous sources, mappings, presentations (including pending SD cards) and Run before its atomic commit. Append-only `Source Revisions` in the sealed Run determine invalidated bindings; archive files are historical evidence only. Old files, approvals, replies and presentations never authorize renewal. Draft and record the affected sources through their current owners, present them afresh and obtain new deliberate approvals.
+- UR revision requires fresh post-UR Review/Mode and required UX. Later source revision retains only reviewed exact applicable analytical inputs; reassessment routes existing owners before dependent source authoring. Every approved-source revision clears preparation, CD+Tests and review fulfillment; retained code/tests require fresh assessment under the renewed TP. Read-only inspection never recovers. Use explicit `--inspect`/`--recover` for the exact pending operation; a replay reports its historical effect separately from current state and grants no approval.
 - `Approval: SD` permits Task/Test Plan drafting, not implementation.
+- New SD drafts from sd-definition declare sd-decisions-v1 with same-artifact Design Decisions.
+  Material before_sd decisions must be resolved with named owners before presentation/approval.
+  Legacy designs without declaration/table retain existing checks; no automatic migration.
 - `Approval: TP` permits implementation-preparation Brownfield Analysis and then CD+Tests when Brownfield evidence supports it.
 - `CD+Tests` is implementation and test status only, not a delivery signal.
 - `code-review` standardizes the mandatory `CR` step, but does not replace QA.
@@ -69,6 +87,20 @@ They must not override AGDF gates, approvals or the Runtime Contract.
 - `release-or` reports the run, but does not replace QA or produce the operative commit/PR handoff.
 - `delivery-closeout` owns the operative Git handoff text when QA/OR/UAT state allows it.
 
+## Canonical Authoring Templates
+
+Bound authoring continuations use only their supplied absolute `template_path` from the installed,
+version-matched plugin. This applies exactly to UR, PRD, SD, TP, UX Intent Definition, Brownfield
+Review, Verified Change, QA Report and OR. `RUN_STATE.md`, `AGDF_RUN.md`, `MASTER_BACKLOG.md`,
+`CONTEXT_GRAPH.md`, `SOT_REGISTRY.md` and `AGENT_QUALITY_CONTRACTS.json` remain owned by their
+existing scaffold/control writers. Repository `.agdf/control/templates/` files are derived,
+reviewable references and never a runtime fallback.
+
+UX Intent Definition and Brownfield Review consume the supplied template only at their existing
+analytical owner. Verified Change consumes it only through the existing gate-check/evaluator compact
+record owner. Missing, unsupported or unsafe plugin templates stop authoring before any repository
+mutation and require explicit plugin repair or reinstall; status and inspection remain available.
+
 
 ## Brownfield Review After G-00
 
@@ -79,6 +111,8 @@ It is the sizing and routing step that decides how much later gate discipline is
 When evidence is sufficient, persist the review and Mode/Slice selection together; do not expose a
 second routine user decision. Keep the standalone Mode/Slice step only for fail-closed recovery when
 the review record is incomplete or legacy.
+The same review records conditional Architecture Impact under `brownfield-analysis`; its evidence
+feeds the existing Mode/Slice Decision, whose structured-depth policy remains in `modes.md`.
 
 Its output is limited to:
 
@@ -123,8 +157,16 @@ Classify impact as:
 - `high`: the change spans capabilities or modes, creates competing or safety-relevant authority,
   adds high-consequence decisions or materially changes cross-surface activation and recovery.
 
+Assess the proposed user-facing behavior, not whether implementation code has already changed.
 `medium | high` requires `ux-intent-definition` before PRD readiness. `low` requires it when any
-mandatory PRD UX semantics remain ambiguous. `none` records the analytical decision
+mandatory PRD UX semantics remain ambiguous or approved UR scope explicitly requires a UI preview
+for UX/PRD clarification. Preserve that requested deliverable in routing evidence and set
+`ux_intent_definition_required: yes`; do not replace it with a text-only analysis or inflate impact
+merely to route it. Distinguish a required clarification preview from the actual product deliverable
+and from optional illustrative aids. A missing preview does not require UR creation to be repeated.
+Preserve an explicitly requested before-PRD review in the Mode/Slice Decision; compact routes must
+not bypass that agreed review sequence. Use the existing proportional modes, not a new preview mode.
+`none` records the analytical decision
 `not_applicable`. The skill is an internal, non-authorizing step: it adds no gate, approval value or
 implementation permission. A required `blocked` result keeps PRD readiness closed.
 
@@ -135,6 +177,7 @@ This table is the canonical transition model. Skills may reference it, but must
 
 | State | Current gate or step | Allowed | Forbidden | Missing approval |
 |---|---|---|---|---|
+| Positive delivery intake has one resolved target, but canonical control is absent or incomplete | `Control setup` | draft the minimal UR, obtain explicit setup or link authority, initialize or link canonical control and persist the revision-stable UR | gate approval requests, live legacy run creation, PRD, SD, TP, Brownfield Analysis, implementation, QA, release | none |
 | No approved UR | `UR` | clarify user need, formulate and persist UR, request `Approval: UR` | PRD, SD, TP, Brownfield Analysis, implementation, QA, release | `Approval: UR` |
 | `UR` approved and UR artefact persisted or linked, Brownfield Review missing | `Brownfield Review` | classify workstream, existing owners, SoT, reuse risks, change size and PRD/SD open questions; mark review done or not_applicable | PRD, SD, TP, implementation, QA, release | none |
 | Brownfield Review done or not_applicable, Mode/Slice Decision missing or incomplete | `Mode/Slice Decision` | decide `quick_task`, `verified_change`, `structured_slice`, `structured_delivery` or `block`; record scope reason, evidence and required next gate depth | PRD, SD, TP, implementation, QA, release | none |
@@ -150,8 +193,9 @@ This table is the canonical transition model. Skills may reference it, but must
 | Brownfield Analysis passed for approved TP | `CD+Tests` | implement approved TP tasks and run tests | QA pass, UAT, release | none |
 | `CD+Tests` done for approved TP, CR missing | `CR` | run mandatory Code Review and resolve blocking findings | QA pass, UAT, release | none |
 | `CR` done, QA not approved | `QA` | run QA gate, persist/refine QA report, request `Approval: QA` | UAT, release | `Approval: QA` |
-| `QA` approved but QA report missing or not pass | `QA` | persist/link QA report with `pass` decision or revise/block evidence | UAT, release | none |
-| QA approved and QA report is `pass` or `passed`, UAT not approved | `UAT` | request `Approval: UAT`, prepare non-operative delivery summary | release and automatic VCS actions | `Approval: UAT` |
+| `QA` approved but QA report missing or not pass, without a current exact deviation-acceptance receipt | `QA` | persist/link QA report with `pass` decision or revise/block evidence | UAT, release | none |
+| QA report is `revise` with an eligible explicit evidence-only deviation proposal and no QA acceptance | `QA` | present the exact scope, risks, consequences and follow-up; request contextual acceptance under quality.md | UAT, release and treating missing tests as passed | `Approval: QA` |
+| QA approved with report `pass`/`passed` or a current exact human deviation-acceptance receipt, UAT not approved | `UAT` | request `Approval: UAT`, carry accepted deviations and original QA result into the non-operative summary | release and automatic VCS actions | `Approval: UAT` |
 | UAT approved | `OR` | produce OR or delivery closeout; prepare VCS handoff only when requested | automatic commit, push, PR or release | none |