Target release: v1.5.0

User Story

As someone planning a greenfield rewrite of an inherited codebase, I want low-fidelity wireframes of each existing UI screen so the team can agree on "what we must preserve" without trying to lift the pixel-level UI — and I want them clearly marked as AI-inferred sketches, not lifts, so nobody mistakes them for ground truth.

Context

/extract-features already discovers UI screens (axis 5 of its six-axis scan). It knows what screens exist and which routes / components / data fields each one touches. The Feature Inventory at projects/<name>/feature-inventory.md lists them, but only as names — no visual rendering.

For the rewrite use case, low-fi mockups help. For a live project where the real screens exist, they're unnecessary. So this is opt-in via flag, not default.

Inference honesty (load-bearing)

This is the design tension. The output is a model's guess at the wireframe based on:

• Route component imports (form components → form sections; table components → table sections; modal components → modal layouts)
• Form field types from the route's bound data model (string → text input; enum → dropdown; bool → checkbox)
• Existing component library conventions (Material UI, Tailwind, Chakra patterns the model recognises)

It's not lifted from real markup. Even with good signals, the output can hallucinate sections or miss conditional UI logic.

Two design decisions follow from this:

1. ASCII format only. PNG/SVG renders look more authoritative than they should. ASCII boxes keep the fidelity honest — readers see a sketch and treat it as a sketch.
2. Disclaimer header per mockup. Every wireframe is prefixed with > AI-inferred sketch — verify before relying on. so even a reader who skims an inventory can't mistake it for ground truth.

Acceptance Criteria

• New flag: /extract-features --with-mockups
• For each UI screen discovered in axis 5, emit an ASCII wireframe sketch under a new ## Screens section in the inventory file
• Each wireframe:
  • Boxed ASCII layout (top nav, sidebar if detected, main column, footer if detected)
  • Form fields with [ ] for inputs, [v] for dropdowns, [X] for checkboxes, buttons in [ButtonLabel]
  • Tables as ASCII grids when detected
  • Maximum width 80 chars (readable in terminal + markdown rendering)
• Each wireframe prefixed with > AI-inferred sketch — verify before relying on. Source: <route or component path>
• Source citation per screen: the path of the route or component the wireframe was inferred from
• Operator can edit them inline (it's just markdown — no special build step)
• Tests cover: form-heavy screen, table-heavy screen, modal screen, dashboard screen (mixed)
• Backward-compat: running /extract-features without --with-mockups produces today's output unchanged
• AgDR documenting the inference-honesty design choice (ASCII-only, mandatory disclaimer, not default)

Out of scope (v1)

• PNG / SVG output. ASCII is the v1 contract for the honesty reason above. If high-fidelity is needed later, file a separate ticket with a different inference / lifting strategy.
• Interactive wireframes. Static ASCII embedded in the inventory file. If interactive previews are wanted, /journey already produces that for user flows.
• Wireframe verification against running app. No comparison against the rendered DOM. The wireframe is purely static-analysis-derived.
• Multi-language UI inference. v1 assumes the screen's source language is in the codebase's primary language. Adopters with i18n can post-edit.

Risks

• Disclaimer noise: every screen carrying a disclaimer header may look heavy. Mitigation: short single-line disclaimer, not a paragraph.
• Inference quality varies by component library: a Tailwind+headless setup will read cleaner than a custom-CSS one-off. Tests should show ~3-4 realistic patterns the inference handles well; for everything else, the disclaimer covers it.
• File size growth: an app with 200 screens = a large inventory file. Consider a per-screen page link if --with-mockups is set: emit inventory + projects/<name>/screens/<slug>.md per screen. Decide in AgDR.

Glossary