Codebase map

Create offline HTML/SVG in the existing editorial report. Preserve the full report: flow views, change summary, boundaries, tasks, acceptance and evidence. For application UI, add the optional screen-flow view described in UI-FLOW.md: connected screens with actions, decisions and the existing elements each proposed screen copies; captures where safe, else labelled sketches. Every visible change needs it; no invented markup/styles. Never call workflow recursively.

Explain behaviour for a reader new to the project first, technical evidence underneath. Keep risks and unresolved decisions visible.

1. Establish the view and current evidence

Apply workflow rules readiness: gaps permit read-only inspection or authorised setup drafts, not an approval-ready implementation report. Read project rules, worktree and local changes. Inspect the behavior’s owner, entrypoints, callers, alternate paths and tests/docs. Reuse task findings after checking freshness. Keep static inspection, runtime observation, inference and unknowns distinct. Missing access blocks current-code claims; label explicitly requested hypothetical designs.

Choose explain when the user wants a no-assumed-context walkthrough of how a feature works today; current for a concise current-state map, proposed for a supplied/requested future design, compare for an implementation review. Explain mode shows the real flow, then exact evidence; do not create a plan or improvements unless asked. Compare opens the proposed flow; current behaviour and an aligned comparison remain available. For new features show the verified integration point, not a fictional baseline.

Identify and reuse the current/named task and its requirements, answers, PLAN, TODO, FINDINGS and decisions. If a likely existing record is ambiguous, ask before creating another artifact location; a new command is not a new task. Read the selected plan/review identity exactly. Distinguish the recorded baseline, approved scope, implementation and acceptance; do not infer authority from a pending badge in a historical snapshot. No new refactor candidates or product features merely to enrich the map. Inspection needs no task scaffold.

2. Apply the local flowchart design

Read FLOWCHART-DESIGN.md: no external diagram-design installation, lookup or invocation is required. Use local assets/renderer, not Matt's architecture command. Missing files/runtime require repair, not waived approval.

Use the inspected evidence, approved answers, type, audience, revision and allowed artifact paths. Choose the geometry, not new product behavior. Main flow: start/actions/real decisions/results, short domain labels and labelled branches. Structural containment, runtime steps and delivery dependencies belong in separate focused views when needed. Preserve independent controls as independent; do not invent an exclusive decision or sequence. Unknowns and conditional/error paths needed for approval stay visible.