create-agdf 0.10.2 → 0.11.0

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

@@ -83,6 +83,64 @@ Structured Delivery skills use this shape when relevant:
 - `required_next_step`: exactly the next clean step
 - `impact_codes`: affected Quality Contract codes, if the target repo has a registry
 
+
+## Normalized Review Gaps
+
+This section is the sole normative owner for review-gap classification and routing. An applicable
+finding from Task Plan Review, Clean Implementation Review or Code Review carries exactly one
+normalized gap type and one routing target:
+
+| gap_type | meaning | routing_target |
+|---|---|---|
+| `requirements_gap` | approved product behavior or an acceptance criterion is missing or contradictory | `PRD`; use `UR` only when user intent or scope changed |
+| `design_gap` | technical ownership, architecture, fallback policy, exit criterion or a prohibited parallel structure was not decided | `SD` |
+| `plan_gap` | an approved requirement or design obligation lacks an executable task, test or evidence mapping | `TP` |
+| `implementation_gap` | code or a surface does not fulfil an approved requirement, design or task | `CD+Tests` |
+| `evidence_gap` | required test, runtime or visible evidence is absent or insufficient | `evidence_obligation` |
+| `emergent_risk` | implementation exposes a concrete risk not reasonably decidable from approved artefacts | earliest affected `UR | PRD | SD | TP | CD+Tests | evidence_obligation` target after explicit assessment |
+
+Normalized finding rows use these fields in order:
+
+`finding_id | gap_type | routing_target | gap_status | evidence | required_next_step`
+
+- `finding_id` is stable within the durable review report.
+- `gap_type` is exactly one type from the table above.
+- `routing_target` is exactly `UR | PRD | SD | TP | CD+Tests | evidence_obligation` and must agree
+  with the fixed route above. `requirements_gap` may use `UR` only with evidence of changed user
+  intent or scope. `emergent_risk` requires an explicit earliest-owner assessment.
+- `gap_status` is exactly `open | resolved`.
+- `evidence` names concrete source, diff, test, observation or missing proof.
+- `required_next_step` is exactly one executable action consistent with the routing target.
+
+Missing, unknown or contradictory fields fail closed as an open gap. Consumers must not silently
+reclassify a finding. Classification is non-authorizing: it cannot edit or approve UR, PRD, SD or TP,
+advance a gate or replace a review decision. `agdf-qa-gate` consumes the normalized findings and cannot
+return `pass` while any applicable finding is open or invalid.
+
+`none` is permitted only as a presentation sentinel on a fulfilled UX Intent Fidelity row.
+It is not a seventh normalized finding type and must not appear in a normalized finding row.
+
+A consumer may repeat the field order and allowed scalar values needed to emit valid output. It must
+reference this section for meanings and routes instead of maintaining a second complete mapping.
+
+## UX Intent Fidelity
+
+When an approved PRD contains applicable UX criteria, `agdf-task-plan-review` produces an additional
+evidence matrix with these columns in order:
+
+`prd_criterion | working_mode_state | task_id | visible_evidence | fidelity_status | gap_type`
+
+`fidelity_status` is exactly `fulfilled | partial | missing | not_verifiable`. A fulfilled row uses
+the `none` sentinel. Any non-fulfilled row uses the applicable normalized type from `Normalized
+Review Gaps`; it may also emit the normalized finding shape when routing detail is required.
+
+This matrix verifies PRD-to-TP coverage and TP-to-code/surface fulfilment. It does not create product
+requirements and does not decide QA. A missing implementation-relevant PRD requirement is a
+`requirements_gap` and routes to PRD revision. `agdf-qa-gate` consumes this evidence and cannot return
+`pass` while an applicable row is `partial`, `missing` or `not_verifiable`, or while a visible-behavior
+claim has code evidence without visible evidence. The four-row Quality Readiness projection and
+`agdf-qa-gate` sole decision ownership remain unchanged.
+
 A skill may briefly remind this shape, but must not duplicate a complete code or rule matrix.
 
 
@@ -97,4 +155,3 @@ It must distinguish:
 - interpretations
 - missing evidence
 - the next permissible step
-

package/generated/.opencode/AGDF.md

@@ -13,6 +13,7 @@ Therefore generated OpenCode skill names use the AGDF prefix:
 
 - `agdf-delivery-path-search`
 - `agdf-brownfield-analysis`
+- `agdf-ux-intent-definition`
 - `agdf-clean-implementation-review`
 - `agdf-code-review`
 - `agdf-delivery-closeout`
@@ -39,6 +40,10 @@ Do not infer active scope from branch names, uncommitted workspace deltas, chat
 If multiple active scopes are plausible, list the evidenced lines and route to `agdf-gate-check` or workstate clarification instead of choosing silently.
 After `Approval: UR`, run lightweight Brownfield Review before PRD when Brownfield, ownership, runtime, policy, persistence, architecture, UI or UX impact is possible.
 Brownfield Review must produce a Mode/Slice Decision: `quick_task`, `verified_change`, `structured_slice`, `structured_delivery` or `block`.
+That same review records the shared UI/UX impact classification. Run `agdf-ux-intent-definition` before
+PRD readiness for medium/high impact and for low impact with ambiguous mandatory PRD semantics. It is
+an internal analytical step, not a gate or product authority; a required blocked result keeps PRD
+readiness closed.
 Make that decision visible before coding or drafting later artefacts: state the selected path, scope reason, evidence and next required gate in the live control state or linked artefact.
 Do not assume the full PRD/SD/TP chain before that decision; use only as much gate depth as the reviewed change size justifies. A user-visible change is not automatically Verified Change eligible; any missing or ambiguous record condition escalates to the declared structured target before implementation.
 
@@ -51,6 +56,7 @@ 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-ux-intent-definition` | after approved UR and post-UR routing for medium/high UI/UX impact or ambiguous low-impact product semantics before PRD readiness | non-authorizing analytical PRD input; never creates product intent, gate permission, technical design or a parallel product source of truth |
 | `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 |

package/generated/.opencode/README.md

@@ -22,3 +22,4 @@ These files were generated from the AGDF source repository for OpenCode.
 - `agdf-qa-gate`
 - `agdf-release-or`
 - `agdf-task-plan-review`
+- `agdf-ux-intent-definition`

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

@@ -11,6 +11,9 @@
     "en": {
       "statusCard": {
         "title": "AGDF status-card",
+        "status": "Status",
+        "field": "Status field",
+        "value": "Value",
         "run": "Selected run",
         "humanTitle": "Run title",
         "gate": "Current gate",
@@ -107,6 +110,7 @@
         "exactTextRequest": "To approve, reply exactly with `{approval}`; otherwise request revision or decline.",
         "decisionFollows": "will be the next user decision",
         "presentationFailure": "Approval cards could not be rendered safely.",
+        "statusPresentationFailure": "Status card could not render safely.",
         "nonReadyDecision": "No decision requested: {reason}.",
         "approveDescription": "Approve this gate with the exact authorization value.",
         "reviseLabel": "Revise",
@@ -214,6 +218,9 @@
     "de": {
       "statusCard": {
         "title": "AGDF-Statuskarte",
+        "status": "Status",
+        "field": "Statusfeld",
+        "value": "Wert",
         "run": "Ausgewählter Run",
         "humanTitle": "Run-Titel",
         "gate": "Aktuelles Gate",
@@ -310,6 +317,7 @@
         "exactTextRequest": "Zur Freigabe exakt mit `{approval}` antworten; andernfalls Überarbeitung anfordern oder ablehnen.",
         "decisionFollows": "ist die nächste Nutzerentscheidung",
         "presentationFailure": "Die Freigabekarten konnten nicht sicher dargestellt werden.",
+        "statusPresentationFailure": "Statuskarte nicht sicher darstellbar.",
         "nonReadyDecision": "Keine Entscheidung angefordert: {reason}.",
         "approveDescription": "Dieses Gate mit dem exakten Freigabewert autorisieren.",
         "reviseLabel": "Überarbeiten",

package/generated/.opencode/contracts/gate-transition.md

@@ -99,6 +99,31 @@ Mode/Slice Decision rules:
 
 A Mode/Slice Decision without scope reason and evidence is not recorded. Treat it as missing and keep the next step at `Mode/Slice Decision`.
 
+### UI/UX Impact And UX Intent Definition
+
+The existing `agdf-brownfield-analysis` `post_ur_review` mode is the single proportional routing owner for
+both Greenfield and Brownfield delivery. It records:
+
+- `delivery_context: greenfield | brownfield`
+- `ui_ux_impact: none | low | medium | high`
+- `ui_ux_impact_reason`
+- `ux_intent_definition_required: yes | no`
+
+Classify impact as:
+
+- `none`: no user-facing capability, decision, state, feedback or recovery behavior changes;
+- `low`: a bounded user-facing change preserves unambiguous intent, working modes, effective-state,
+  activation and recovery semantics;
+- `medium`: a bounded capability materially changes its primary action, working mode, effective
+  state, visible state type, blocker, activation or recovery behavior; or
+- `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.
+
+`medium | high` requires `agdf-ux-intent-definition` before PRD readiness. `low` requires it when any
+mandatory PRD UX semantics remain ambiguous. `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.
+
 
 ## Gate Transition Model
 

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

@@ -40,6 +40,29 @@ It must not introduce a second gate model or override `agdf-gate-check`, `delive
 
 `next_gate_after_approval` and `allowed_after_approval` must be `none` when no approval is missing, when the current step is internal, or when the run is in OR/completed handoff. They must not imply implementation, QA, release, commit, push or PR authority unless the existing gate model already allows that authority.
 
+### Deterministic Operational Presentation
+
+`status_card` is the canonical machine/audit projection. The same evaluation also exposes an additive
+`status_presentation` object with selected run/revision/gate/locale identity, `semantic_block:
+run_status_card`, one compact Markdown block with localized labels and canonical evaluated values,
+and `authorizes: false`. The full raw and evidence-bearing projection remains available unchanged in
+`status_card` JSON for audit and automation; it is not duplicated into the primary chat card.
+Fresh legacy-compatible control state without a durable revision uses the explicit non-authorizing
+identity `unversioned`; ready approval presentation remains impossible without a real revision.
+
+`interaction-presentation.js` is the only owner that may select, label, order, localize and render the
+operational status fields. The gate-check CLI, skills and surface adapters consume
+`status_presentation.markdown` verbatim. They may add concise surrounding explanation, but they must
+not reconstruct a table, omit or rename fields, substitute generic gate actions for evaluated
+`allowed_now`/`forbidden_now`, or maintain another status-card template. If the projection is missing
+or its selected run, revision, gate or locale identity is stale, presentation fails closed rather
+than falling back to model-generated status Markdown.
+
+This determinism protects semantic parity, permission boundaries and evidence visibility across
+hosts. It does not standardize host chrome or unrelated conversational prose. `approval_presentation`
+remains the separate decision-time projection and is present only for a ready user gate; both public
+presentations derive from the same `status_card` snapshot and neither grants approval.
+
 
 ### Breadcrumb
 

package/generated/.opencode/contracts/quality.md

@@ -83,6 +83,64 @@ Structured Delivery skills use this shape when relevant:
 - `required_next_step`: exactly the next clean step
 - `impact_codes`: affected Quality Contract codes, if the target repo has a registry
 
+
+## Normalized Review Gaps
+
+This section is the sole normative owner for review-gap classification and routing. An applicable
+finding from Task Plan Review, Clean Implementation Review or Code Review carries exactly one
+normalized gap type and one routing target:
+
+| gap_type | meaning | routing_target |
+|---|---|---|
+| `requirements_gap` | approved product behavior or an acceptance criterion is missing or contradictory | `PRD`; use `UR` only when user intent or scope changed |
+| `design_gap` | technical ownership, architecture, fallback policy, exit criterion or a prohibited parallel structure was not decided | `SD` |
+| `plan_gap` | an approved requirement or design obligation lacks an executable task, test or evidence mapping | `TP` |
+| `implementation_gap` | code or a surface does not fulfil an approved requirement, design or task | `CD+Tests` |
+| `evidence_gap` | required test, runtime or visible evidence is absent or insufficient | `evidence_obligation` |
+| `emergent_risk` | implementation exposes a concrete risk not reasonably decidable from approved artefacts | earliest affected `UR | PRD | SD | TP | CD+Tests | evidence_obligation` target after explicit assessment |
+
+Normalized finding rows use these fields in order:
+
+`finding_id | gap_type | routing_target | gap_status | evidence | required_next_step`
+
+- `finding_id` is stable within the durable review report.
+- `gap_type` is exactly one type from the table above.
+- `routing_target` is exactly `UR | PRD | SD | TP | CD+Tests | evidence_obligation` and must agree
+  with the fixed route above. `requirements_gap` may use `UR` only with evidence of changed user
+  intent or scope. `emergent_risk` requires an explicit earliest-owner assessment.
+- `gap_status` is exactly `open | resolved`.
+- `evidence` names concrete source, diff, test, observation or missing proof.
+- `required_next_step` is exactly one executable action consistent with the routing target.
+
+Missing, unknown or contradictory fields fail closed as an open gap. Consumers must not silently
+reclassify a finding. Classification is non-authorizing: it cannot edit or approve UR, PRD, SD or TP,
+advance a gate or replace a review decision. `agdf-qa-gate` consumes the normalized findings and cannot
+return `pass` while any applicable finding is open or invalid.
+
+`none` is permitted only as a presentation sentinel on a fulfilled UX Intent Fidelity row.
+It is not a seventh normalized finding type and must not appear in a normalized finding row.
+
+A consumer may repeat the field order and allowed scalar values needed to emit valid output. It must
+reference this section for meanings and routes instead of maintaining a second complete mapping.
+
+## UX Intent Fidelity
+
+When an approved PRD contains applicable UX criteria, `agdf-task-plan-review` produces an additional
+evidence matrix with these columns in order:
+
+`prd_criterion | working_mode_state | task_id | visible_evidence | fidelity_status | gap_type`
+
+`fidelity_status` is exactly `fulfilled | partial | missing | not_verifiable`. A fulfilled row uses
+the `none` sentinel. Any non-fulfilled row uses the applicable normalized type from `Normalized
+Review Gaps`; it may also emit the normalized finding shape when routing detail is required.
+
+This matrix verifies PRD-to-TP coverage and TP-to-code/surface fulfilment. It does not create product
+requirements and does not decide QA. A missing implementation-relevant PRD requirement is a
+`requirements_gap` and routes to PRD revision. `agdf-qa-gate` consumes this evidence and cannot return
+`pass` while an applicable row is `partial`, `missing` or `not_verifiable`, or while a visible-behavior
+claim has code evidence without visible evidence. The four-row Quality Readiness projection and
+`agdf-qa-gate` sole decision ownership remain unchanged.
+
 A skill may briefly remind this shape, but must not duplicate a complete code or rule matrix.
 
 
@@ -97,4 +155,3 @@ It must distinguish:
 - interpretations
 - missing evidence
 - the next permissible step
-

package/generated/.opencode/skills/agdf-brownfield-analysis/SKILL.md

@@ -35,6 +35,11 @@ When `.agdf/control/` is present, persist or link `post_ur_review` output under
 
 Do not mix both modes silently. Name the active mode in the output.
 
+In `post_ur_review`, also record `delivery_context`, `ui_ux_impact`, `ui_ux_impact_reason` and
+`ux_intent_definition_required` using the single classification and routing contract in
+`../../contracts/gate-transition.md`. Greenfield records make existing-system evidence explicitly
+not applicable; Brownfield records cite repository evidence. Do not create a second Greenfield router.
+
 ## Rules
 1. Brownfield first: understand the existing codebase before PRD/SD decisions when existing-system impact is possible, and again before implementation.
 2. Brownfield Review after `Approval: UR` is a sizing and routing step. It must visibly decide `quick_task`, `verified_change`, `structured_slice`, `structured_delivery`, or `block` before PRD depth or implementation is chosen. Persist the completed review and its decision, scope reason, evidence and required next gate in the same internal operation; mark the review `done` only after both the artefact and canonical run projection are complete. An interrupted, incomplete or legacy record stays at fail-closed `Mode/Slice Decision` recovery without another user approval.
@@ -124,6 +129,10 @@ Use a concise structure:
 - required_next_step:
 ```
 
+For `post_ur_review`, include the four UI/UX routing fields immediately after `scope`. If UX intent
+definition is required, its `ready | blocked | not_applicable` result must be visible before PRD
+readiness. A required `blocked` result is at least `revise` for this routing step.
+
 ## Pass / Revise / Block Guidance
 - `pass`: existing owners are understood, reuse path is clear, and no blocking drift or parallel structure risk remains.
 - `revise`: relevant evidence, tests, ownership, or reuse path is incomplete.

package/generated/.opencode/skills/agdf-clean-implementation-review/SKILL.md

@@ -24,6 +24,8 @@ Use these focused runtime-contract modules:
 - `../../contracts/context-graph.md`
 
 Clean-review-specific output must make the primary solution, fallbacks, workarounds, parallel structures, exit criteria, and next cleanup/review step visible.
+Applicable findings must use `../../contracts/quality.md` §Normalized Review Gaps. This skill
+must distinguish a missing upstream decision from implementation that violates an approved decision.
 
 ## Rules
 1. Clean primary solution before fallback.
@@ -35,6 +37,10 @@ Clean-review-specific output must make the primary solution, fallbacks, workarou
 7. Maintainability matters; "works somehow" is not enough.
 8. Async execute paths must not decide product rules again.
 9. Shared finalization or merge rules belong in one owner.
+10. Missing canonical ownership, fallback policy, exit criteria or parallel-structure decisions are
+    upstream gaps; do not invent those decisions during review.
+11. Actual code that violates an approved design or plan is an implementation gap.
+12. Missing, unknown or contradictory classifications fail closed and stay open.
 
 ## When To Use
 - after `CD+Tests`
@@ -89,6 +95,16 @@ Use this compact structure:
 - required_next_step:
 ```
 
+When findings exist, append:
+
+```text
+## Normalized Findings
+| finding_id | gap_type | routing_target | gap_status | evidence | required_next_step |
+|---|---|---|---|---|---|
+```
+
+Use the shared Quality Contract for meanings and routes; do not copy its complete mapping here.
+
 ## Pass / Revise / Block Guidance
 - `pass`: primary solution is clean, tested, and integrated with existing owners.
 - `revise`: solution works but contains avoidable fallback, unclear ownership, or missing evidence.
@@ -106,3 +122,5 @@ This skill must not:
 - hide unjustified workarounds
 - treat green tests as proof of solution integrity
 - decide final QA
+- create a missing design, plan or product decision during review
+- silently repair or reclassify an invalid normalized finding

package/generated/.opencode/skills/agdf-code-review/SKILL.md

@@ -23,6 +23,8 @@ Use these focused runtime-contract modules:
 - `../../contracts/context-graph.md`
 
 Code-review-specific output must make actual findings, missing review scope, evidence strength, and the next required step visible.
+Applicable findings must use `../../contracts/quality.md` §Normalized Review Gaps. Concrete diff
+defects remain Code Review findings; missing upstream constraints route to their authoritative owner.
 
 ## Rules
 1. Review the actual diff and impacted code, not intent alone.
@@ -33,6 +35,9 @@ Code-review-specific output must make actual findings, missing review scope, evi
 6. Brownfield owners and existing conventions are binding unless deviation is justified.
 7. Distinguish blocking defects from fixable review findings.
 8. CR does not grant QA pass.
+9. Do not turn Code Review into a static requirements checklist or invent missing upstream constraints.
+10. A genuinely new implementation risk uses `emergent_risk` with an explicit earliest-owner assessment.
+11. Missing, unknown or contradictory classifications fail closed and stay open.
 
 ## When To Use
 - after `CD+Tests`
@@ -81,6 +86,16 @@ Use this compact structure:
 - required_next_step:
 ```
 
+When findings exist, append:
+
+```text
+## Normalized Findings
+| finding_id | gap_type | routing_target | gap_status | evidence | required_next_step |
+|---|---|---|---|---|---|
+```
+
+Use the shared Quality Contract for meanings and routes; do not copy its complete mapping here.
+
 ## Decision Guidance
 - `pass`: no meaningful review finding remains evident in reviewed scope.
 - `revise`: fixable correctness, regression, or maintainability issues remain.
@@ -100,3 +115,5 @@ This skill must not:
 - hide missing review scope
 - generate style-only findings
 - duplicate TP Review or QA as if they were the same step
+- invent a requirement, design decision or plan obligation to justify a finding
+- silently repair or reclassify an invalid normalized finding

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

@@ -85,10 +85,11 @@ This skill owns only these operational responsibilities:
 5. Revalidate the same run, gate and revision immediately after the response and before persistence.
 6. Persist only a currently valid exact approval through the existing control-state workflow.
 
-For status, blocked, read-only or rationale interactions, consume the same canonical projection and
-locale contract without asking for approval. Internal process steps remain distinct from user
-decisions. If the projection, adapter evidence or revalidation is missing, follow the contract's
-fail-closed outcome and leave authority unchanged.
+For status, blocked, read-only or rationale interactions, consume the canonical
+`status_presentation.markdown` verbatim and apply the locale contract without asking for approval.
+Do not reconstruct its fields, ordering, labels or Markdown from `status_card` JSON. Internal process
+steps remain distinct from user decisions. If the projection, adapter evidence or revalidation is
+missing, follow the contract's fail-closed outcome and leave authority unchanged.
 
 ## Rules
 1. Fail closed when a required approval or artefact status is missing.
@@ -163,23 +164,15 @@ If a status is not explicit, do not assume it is satisfied.
 12. If branch, workspace and durable artefacts disagree, do not choose a scope silently; report the ambiguity and ask for the smallest clarifying gate action.
 
 ## Output
-Keep the result short and operational. Render the Runtime Contract's compact human-facing Run Status Card rather than a surface-specific summary:
-
-| Run status | Value |
-|---|---|
-| Status | `open | blocked` |
-| Current gate | `<GateName or internal step>` |
-| Allowed now | `<currently allowed outputs>` |
-| Blocked by | `<blocking condition or none>` |
-| Missing approval | `Approval: <GateName> | none` |
-| Next step | `<single permissible next step>` |
-| Quality outlook | `<next meaningful quality focus or none>` |
-
-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.
+Keep the result short and operational. For a status-only response, consume the Runtime Contract's
+code-owned `status_presentation.markdown` verbatim. It is the compact localized operational Run
+Status Card and already includes current and post-approval authority, next-step and quality fields.
+Keep full raw evidence in `status_card` JSON or concise surrounding detail when relevant; do not turn
+the primary chat card into an audit dump. Do not maintain or render a skill-local table template.
 
 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
+render its five-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.

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

@@ -31,6 +31,8 @@ Use these focused runtime-contract modules:
 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.
+Consume applicable findings through `../../contracts/quality.md` §Normalized Review Gaps.
+QA must not maintain a second mapping or reclassify review findings.
 
 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
@@ -48,6 +50,11 @@ Gate Transition Card or the durable QA report.
 6. Solution integrity is mandatory.
 7. Always output exactly one decision: `pass`, `revise`, or `block`.
 8. Open risks, missing tests, partial TP coverage, or side effects must be visible.
+9. Applicable UX Intent Fidelity rows must all be `fulfilled` with suitable visible evidence before `pass`.
+10. A `requirements_gap` routes to PRD revision; QA must not invent or accept the missing criterion.
+11. Any applicable normalized finding that is `open`, missing, unknown, contradictory or supported by
+    insufficient evidence prevents `pass`.
+12. A `resolved` finding counts only when its durable review evidence proves the routed correction or decision.
 
 ## When To Use
 - after `CD+Tests`
@@ -82,14 +89,16 @@ If evidence is missing, lower the decision accordingly.
 2. Verify TP coverage.
 3. Verify P0/P1 completion.
 4. Verify Brownfield fit.
-5. Verify solution integrity.
-6. Verify tests and evidence strength.
-7. Verify documentation and Context Graph impact if relevant.
-8. Decide:
+5. Verify UX Intent Fidelity when applicable, including visible evidence for visible-behavior claims.
+6. Consume normalized findings without reclassification; fail closed on every open or invalid row.
+7. Verify solution integrity.
+8. Verify tests and evidence strength.
+9. Verify documentation and Context Graph impact if relevant.
+10. Decide:
    - `pass`
    - `revise`
    - `block`
-9. State the single required next step.
+11. State the single required next step.
 
 ## Output
 Use this shape:
@@ -125,3 +134,4 @@ This skill must not:
 - replace UAT
 - treat missing reviews as completed
 - downgrade SoT drift to harmless warning
+- silently repair, normalize or reroute a review finding

package/generated/.opencode/skills/agdf-release-or/SKILL.md

@@ -52,7 +52,7 @@ Use the Runtime Contract definition of `Relevant Run` to decide whether OR is ma
 13. Keep machine status normalization in the CLI; do not write internal snake_case status values into the human-facing backlog.
 14. Reconcile Context Graph impact before clean closeout: report `context_graph_reconciliation: resolved | not_applicable | open_gap`.
 15. If Context Graph work remains unresolved, report it as an explicit open gap and do not describe the run as cleanly handoff-ready.
-15. After writing or updating `MASTER_BACKLOG.md`, run `doctor --json` (or the locally available equivalent) and resolve any `AGDF_BACKLOG_STATUS_UNKNOWN` or `AGDF_BACKLOG_ARTEFACT_LABEL_UNKNOWN` finding before closeout. See the AGDF control scaffold's `MASTER_BACKLOG.md` template Rules section for the canonical status/artefact label vocabulary.
+16. After writing or updating `MASTER_BACKLOG.md`, run `doctor --json` (or the locally available equivalent) and resolve any `AGDF_BACKLOG_STATUS_UNKNOWN` or `AGDF_BACKLOG_ARTEFACT_LABEL_UNKNOWN` finding before closeout. See the AGDF control scaffold's `MASTER_BACKLOG.md` template Rules section for the canonical status/artefact label vocabulary.
 
 ## When To Use
 - at the end of every relevant run

package/generated/.opencode/skills/agdf-task-plan-review/SKILL.md

@@ -27,6 +27,8 @@ Use these focused runtime-contract modules:
 
 TP-specific output must evaluate every relevant `task_id` with completion status, AC coverage, evidence, missing evidence, and QA-relevant gaps.
 If `context_graph_required_action` is not `none`, the affected task is complete only if follow-up, evidence, or an intentionally open gap is visible.
+Applicable review gaps must use `../../contracts/quality.md` §Normalized Review Gaps. This skill
+must not maintain its own type-to-route mapping.
 
 ## Rules
 1. The Task Plan is the reference, not plausible code.
@@ -39,6 +41,12 @@ If `context_graph_required_action` is not `none`, the affected task is complete
 8. P0/P1 gaps must be handed to QA.
 9. Out-of-scope changes must be reported.
 10. When evidence is unclear, fail closed to at least `partially_done`.
+11. When approved PRD UX criteria apply, verify both PRD-to-TP coverage and TP-to-code/surface fulfilment.
+12. Never invent a missing UX requirement. Report `requirements_gap` and route it to PRD revision.
+13. Visible behavior requires visible evidence; code evidence alone is `not_verifiable`.
+14. A fulfilled UX Intent Fidelity row uses `none`; every non-fulfilled applicable row uses one
+    normalized gap type and a contract-valid route.
+15. Missing, unknown or contradictory classifications fail closed and stay open.
 
 ## Clarifications
 ### TP Slice Before Target State
@@ -90,6 +98,27 @@ Use this compact structure:
 - required_next_step:
 ```
 
+When applicable, append:
+
+```text
+## UX Intent Fidelity
+| prd_criterion | working_mode_state | task_id | visible_evidence | fidelity_status | gap_type |
+|---|---|---|---|---|---|
+```
+
+Use `fulfilled | partial | missing | not_verifiable` for `fidelity_status` and
+the shared Quality Contract for `gap_type`. `none` is allowed only on a fulfilled row.
+
+When an applicable gap needs routing detail, append:
+
+```text
+## Normalized Findings
+| finding_id | gap_type | routing_target | gap_status | evidence | required_next_step |
+|---|---|---|---|---|---|
+```
+
+Use only contract-defined values. Do not reconstruct the type-to-route mapping locally.
+
 Completion status:
 
 - `fully_done`
@@ -122,3 +151,7 @@ This skill must not:
 - hide partial work
 - upgrade missing evidence into confidence
 - reinterpret the TP scope
+- create or silently repair product requirements
+- treat code existence as visible UX evidence
+- emit `none` as a normalized finding type
+- silently repair or reclassify an invalid finding

package/generated/.opencode/skills/agdf-ux-intent-definition/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: agdf-ux-intent-definition
+description: Use this skill after approved UR and post-UR routing when UI/UX impact is medium or high, or low with ambiguous product semantics, to define user intent, success, working modes, effective state, visible state ownership, activation, blockers, recovery and transitions as structured PRD input; fail closed when evidence or product decisions are unresolved. This internal analysis never grants gate permission or replaces the approved PRD.
+---
+
+# ux-intent-definition
+
+## Purpose
+
+Create structured, testable UX intent input before PRD approval so implementation reviews verify an
+approved product promise instead of inventing requirements after code exists.
+
+## Runtime Contract
+
+Use:
+
+- `../../contracts/gate-transition.md` for impact routing, authority and revision behavior;
+- `../../contracts/quality.md` for evidence and fail-closed output discipline.
+
+## Authority
+
+This is an internal analytical skill, not a user gate. It cannot approve artefacts, grant
+implementation permission, change approved UR/PRD intent, prescribe technical design or become a
+parallel product source of truth. Proposed criteria become authoritative only when incorporated into
+and approved as PRD content. Technical storage, derivation and component ownership remain SD concerns.
+
+## Inputs
+
+- approved UR and its intent, success signal, primary action and persona/context;
+- post-UR `delivery_context`, `ui_ux_impact`, reason and required flag;
+- existing behavior/ownership evidence for Brownfield work;
+- known working modes, state semantics, activation, blockers, recovery and transitions.
+
+## Workflow
+
+1. Confirm the approved UR and routing evidence. If required evidence is absent or conflicts, block.
+2. Identify the primary user intent, observable success and primary decision/action.
+3. For every relevant working mode, define effective state and visible state types.
+4. Separate `effective_state_authority_by_mode` from
+   `primary_state_presentation_owner_by_mode`; do not turn either into technical ownership.
+5. Define activation/deactivation, blockers with visible next actions, actionable recovery (including
+   visible retry for recoverable transient failure) and relevant state transitions.
+6. Propose observable PRD acceptance criteria and identify open product questions.
+7. Return exactly one decision: `ready | blocked | not_applicable`.
+
+## Decision Rules
+
+- `ready`: every required output is reliable enough for PRD drafting.
+- `blocked`: user intent, modes, effective state, authority, activation, blockers, recovery, transitions
+  or Brownfield evidence is missing, contradictory or materially ambiguous.
+- `not_applicable`: routing proves that no relevant user-facing intent, state or recovery behavior changes.
+
+A conflict with approved UR routes to UR revision. A material product change discovered after PRD
+approval routes to PRD revision, or UR revision when intent/scope changes. Never resolve the conflict
+silently. A required blocked result prevents PRD readiness.
+
+## Output
+
+Populate each field or use an explicit, justified `not_applicable`:
+
+```text
+- decision: ready | blocked | not_applicable
+- blocking_reason:
+- primary_user_intent:
+- success_signal:
+- primary_decision_or_action:
+- working_modes:
+- effective_state_by_mode:
+- visible_state_types:
+- effective_state_authority_by_mode:
+- primary_state_presentation_owner_by_mode:
+- activation_paths:
+- blockers:
+- recovery_paths:
+- relevant_state_transitions:
+- proposed_prd_acceptance_criteria:
+- open_product_questions:
+- affected_outputs:
+- evidence:
+- missing_evidence:
+- required_next_step:
+```
+
+For `blocked`, `blocking_reason`, `open_product_questions`, `affected_outputs`, `evidence`,
+`missing_evidence` and `required_next_step` are mandatory. When durable control state exists, write
+the result to `.agdf/control/artefacts/<key>/UX_INTENT_DEFINITION.md` without a Gate or approval field.
+
+## Forbidden
+
+- invent product intent or silently choose between conflicting modes/state authorities;
+- bypass UR/PRD revision or claim PRD readiness from a blocked result;
+- add a gate, approval value or implementation permission;
+- prescribe components, persistence, endpoints, styles or other technical design;
+- treat supporting analysis as authoritative beside the approved PRD.