create-agdf 0.10.2 → 0.11.0

package/README.md

@@ -114,7 +114,7 @@ it does not localize the CLI lifecycle card.
 - `codex-repo` writes a repository-local Codex marketplace under `.agents/plugins/` and a local AGDF plugin copy under `plugins/agdf/`
 - `claude` installs the AGDF plugin globally for Claude Code
 - `copilot` writes `AGENTS.md`, Copilot custom instructions under `.github/`, visible repository skills under `.github/skills/`, and AGDF control templates under `.agdf/control/`
-- `opencode` installs the AGDF npm plugin and nine native skills as a user-wide OpenCode surface
+- `opencode` installs the AGDF npm plugin and ten native skills as a user-wide OpenCode surface
 - `opencode-status` reports OpenCode global config, package loadability, global native-skill completeness, durable repository activation, legacy compatibility and observable session signals
 - `status` reports installation, repository activation and delivery separately without mutating state
 - `disable` writes a supported repository-local opt-out while retaining global capability and durable control state
@@ -161,7 +161,7 @@ npm create agdf@latest -- opencode-repo
 OpenCode loads the AGDF npm plugin and global native skills from global OpenCode config. Global adapters use the collision-safe `agdf-global-` prefix, including `agdf-global-gate-check`. `opencode-repo` adds the durable `.agdf/control/config.json` marker and control templates; it does not write `opencode.json`, `.opencode/AGDF.md`, copied contracts or copied skills.
 The global skills load on demand through OpenCode's native `skill` tool. Use `agdf-global-gate-check` first for new build/change intent or unclear approval. Existing local `.opencode/` assets remain supported as a compatibility path and are not deleted.
 The built-in `question` tool can present a gate choice, but `.agdf/control/` and exact post-response validation remain authoritative; technical permission and auto-mode outcomes never approve an AGDF gate. Explicit `permission.question: deny` remains unchanged and uses exact-text fallback.
-The global layer makes the nine native AGDF skills discoverable, but does not activate repository governance by itself. Global skills fail closed until the current repository has valid `.agdf/control/config.json`. Use `opencode-repo` to create the durable activation marker.
+The global layer makes the ten native AGDF skills discoverable, but does not activate repository governance by itself. Global skills fail closed until the current repository has valid `.agdf/control/config.json`. Use `opencode-repo` to create the durable activation marker.
 
 ## Control scaffold
 

package/generated/.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/.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/.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/.github/skills/README.md

@@ -13,6 +13,7 @@ These repository skills were generated from the AGDF source repository and are i
 - `agdf-qa-gate`
 - `agdf-release-or`
 - `agdf-task-plan-review`
+- `agdf-ux-intent-definition`
 
 ## Runtime contract
 

package/generated/.github/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/.github/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/.github/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/.github/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/.github/skills/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/.github/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/.github/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/.github/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/.github/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/.github/skills/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/.github/skills/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