create-agdf 0.10.3 → 0.11.0

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-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-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.

package/generated/AGENTS.md

@@ -13,6 +13,7 @@ Therefore generated Copilot 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/plugins/agdf/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agdf",
-  "version": "0.10.3",
+  "version": "0.11.0",
   "description": "AI Governance & Delivery Framework (AGDF) brings an operating system for governed AI-assisted delivery to Claude Code, combining workflow skills, control templates and machine-readable repository checks for gate decisions, Brownfield analysis, task-plan review, QA decisions, durable run state and auditable closeout.",
   "keywords": [
     "agentic",

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

@@ -1,6 +1,6 @@
 {
   "name": "agdf",
-  "version": "0.10.3",
+  "version": "0.11.0",
   "description": "Operating system for governed AI-assisted delivery.",
   "author": {
     "name": "Arndt Gold",

package/generated/plugins/agdf/control/templates/artefacts/BROWNFIELD_REVIEW.md

@@ -17,6 +17,18 @@ Status: `draft | done | not_applicable | superseded`
 
 What approved UR scope is being sized and routed?
 
+## UI / UX Impact Routing
+
+- delivery_context: `greenfield | brownfield`
+- ui_ux_impact: `none | low | medium | high`
+- ui_ux_impact_reason:
+- ux_intent_definition_required: `yes | no`
+- ux_intent_definition_result: `ready | blocked | not_applicable`
+
+Use the single classification contract in `meta/contracts/gate-transition.md`. A required `blocked`
+result prevents PRD readiness. Greenfield explicitly marks existing-system evidence not applicable;
+Brownfield cites repository evidence.
+
 ## Existing-System View
 
 | Area | Existing owner or artefact | Evidence | Impact |

package/generated/plugins/agdf/control/templates/artefacts/PRD.md

@@ -11,31 +11,63 @@ Owner:
 
 What exactly must be delivered?
 
-## 2. Acceptance Criteria
+## 2. UX Intent And Success
 
-Which observable outcomes must be true?
+- ui_ux_impact: none | low | medium | high
+- ux_intent_definition: <ready analysis reference | directly defined low-impact semantics | justified not_applicable>
+- primary_user_intent:
+- success_signal:
+- primary_decision_or_action:
 
-## 3. Non-Goals
+Every field must be populated or explicitly justified as `not_applicable`. Medium/high impact requires
+a `ready` UX Intent Definition result before this PRD is ready.
+
+## 3. Working Modes And Effective State
+
+For every user-relevant working mode, define:
+
+| working_mode | effective_state | visible_state_types | effective_state_authority | primary_state_presentation_owner |
+|---|---|---|---|---|
+|  |  |  |  |  |
+
+Product/system authority decides what is effectively true. Presentation ownership identifies the
+primary surface that communicates state and next action. Technical storage, derivation and component
+ownership remain Solution Design concerns.
+
+## 4. Activation, Blockers, Recovery And Transitions
+
+- activation_and_deactivation:
+- blockers_and_visible_next_actions:
+- recovery_paths: <include visible retry for recoverable transient failure>
+- relevant_state_transitions: <trigger, source, target, visible feedback, next action, failure/rollback>
+
+## 5. Acceptance Criteria
+
+Every applicable UX criterion must include a stable `criterion_id`, `working_mode`, `source_state`,
+trigger/action, expected effective state, visible feedback, blocker/failure behavior, recovery/next
+action, observable success and required evidence. Specify observable behavior, not implementation.
+
+## 6. Non-Goals
 
 What remains out of scope?
 
-## 4. Users And Roles
+## 7. Users And Roles
 
 Who is affected and who decides?
 
-## 5. Constraints
+## 8. Constraints
 
 Which business, operational, legal, security or compatibility constraints apply?
 
-## 6. Evidence Requirements
+## 9. Evidence Requirements
 
 Which evidence must later support QA?
 
-## 7. Risks And Open Questions
+## 10. Risks And Open Questions
 
 Which questions must SD, TP or Brownfield Analysis clarify later?
 
-## 8. Next Step
+## 11. Next Step
 
 Review this PRD and approve only with:
 

package/generated/plugins/agdf/control/templates/artefacts/UX_INTENT_DEFINITION.md

@@ -0,0 +1,51 @@
+# UX Intent Definition: <Title>
+
+Status: draft | ready | blocked | not_applicable
+Decision: ready | blocked | not_applicable
+Based on: approved UR and post-UR routing evidence
+Date:
+Owner:
+
+This is non-authorizing analytical input. It is not a user-gate artefact, carries no approval and
+grants no implementation permission. After PRD approval, the PRD is the sole product authority.
+
+## 1. Routing Evidence
+
+- delivery_context: greenfield | brownfield
+- ui_ux_impact: none | low | medium | high
+- ui_ux_impact_reason:
+- ux_intent_definition_required: yes | no
+
+## 2. Intent And Success
+
+- primary_user_intent:
+- success_signal:
+- primary_decision_or_action:
+
+## 3. Working Modes And State
+
+- working_modes:
+- effective_state_by_mode:
+- visible_state_types:
+- effective_state_authority_by_mode:
+- primary_state_presentation_owner_by_mode:
+
+## 4. Activation, Blockers, Recovery And Transitions
+
+- activation_paths:
+- blockers:
+- recovery_paths:
+- relevant_state_transitions:
+
+## 5. Proposed PRD Acceptance Criteria
+
+- proposed_prd_acceptance_criteria:
+
+## 6. Decision Evidence
+
+- blocking_reason:
+- open_product_questions:
+- affected_outputs:
+- evidence:
+- missing_evidence:
+- required_next_step:

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

@@ -14,6 +14,7 @@ Therefore plugin skill names are intentionally unprefixed:
 - `gate-check`
 - `delivery-path-search`
 - `brownfield-analysis`
+- `ux-intent-definition`
 - `task-plan-review`
 - `clean-implementation-review`
 - `code-review`
@@ -40,6 +41,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 `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 `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.
 
@@ -52,6 +57,7 @@ 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 |
+| `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 |
 | `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 |

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

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
   "id": "agdf",
-  "version": "0.10.3",
+  "version": "0.11.0",
   "displayName": "AI Governance & Delivery Framework",
   "developerName": "Arndt Gold",
   "description": "Operating system for governed AI-assisted delivery.",
@@ -168,6 +168,12 @@
       "useFor": "after gate-check permits Brownfield Review or implementation preparation, before non-trivial changes in existing systems",
       "boundary": "clarifies reuse, owners, risks and Mode/Slice Decision; never bypasses gate-check; Brownfield Review is not implementation permission"
     },
+    {
+      "slug": "ux-intent-definition",
+      "discovery": "automatic",
+      "useFor": "after approved UR and post-UR routing for medium/high UI/UX impact or ambiguous low-impact product semantics before PRD readiness",
+      "boundary": "non-authorizing analytical PRD input; never creates product intent, gate permission, technical design or a parallel product source of truth"
+    },
     {
       "slug": "clean-implementation-review",
       "discovery": "automatic",

package/generated/plugins/agdf/meta/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 `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 `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