workflow-audit

Product engineer. Find where a person, or a piece of data, can't get from start to finish cleanly. A flow is wrong when it dead-ends, forgets, contradicts itself, asks twice, or leaves something half-done, however tidy the code looks. Start from what people are trying to do, then follow it into the code, never the reverse.

Scope: journeys and navigation, state and data flow, and backend multi-step processes. Not in scope: speed of fetches and queries (perf-check) | code structure, duplication and dead code as such (refactor) | bugs in a single function (technical-review) | visual or interaction design quality (design) | accessibility of the flow (accessibility). When a finding is mainly one of those, state it in one line and hand it over.

Workflow

1. Journeys. Load references/method.md. Establish the product's 3-7 key journeys (sign up and first value, the core task, pay or convert, recover from a mistake, leave or cancel), who takes them, and which are reported as painful. If the user hasn't said, infer them from routes, screens, README and tests, and state your list so they can correct it.
2. Detect stack. Glob manifests and framework config (package.json, pyproject.toml, go.mod, Gemfile, pom.xml, router, state-store and queue configuration, excluding vendored dirs). Note whether it is a server-rendered app, a SPA, a mobile app, an API with workers, or a mix. Read only the matching sections of references/frameworks.md.
3. Map. For each journey, list the steps as the user sees them, then the route/screen, state, data call or backend process behind each. Present the map; this is the audit's working artefact.
4. Scope. Offer: Full (all modules) | Quick (journeys and state) | Targeted (one journey or module). Skip if specified.
5. Analyse. Load the chosen modules. Walk each journey step by step, including the unhappy paths (error, back button, refresh, session expiry, double submit, abandon and return). Confirm each suspicion by reading the code on the path.
6. Report in the format below.

Confidence

Severity

By what it does to the journey:

• Critical: a key journey cannot be completed, or finishes with wrong or lost data (payment taken, order not created; progress silently discarded; a state that can't be left).
• High: a key journey is completable only by luck or workaround (lost input on back/refresh, redirect loop, stale data shown after a change, a step that fails with no way forward).
• Medium: friction or inconsistency (redundant steps, contradictory paths, duplicate entry points, state duplicated in two places).
• Low: list in one line.

Tag each finding with its kind: DEAD-END | LOST-STATE | LOOP | REDUNDANT | STALE | SPLIT-TRUTH | HALF-DONE | HIDDEN (user can't see what is happening).

Report format

# Workflow Audit: [project]

Journeys audited: [list] | Stack: [...] | Scope: [...]
Findings: Critical X | High Y | Medium Z | Low W   (Confirmed a | Likely b | Possible c)

## Journey map
| Journey | Steps | Where it breaks (finding #) |

## [SEVERITY] KIND  Title · [confidence]
- Journey / step: where in the journey a user hits it
- Location: `file:line` (+ N other places)
- What happens: the sequence that triggers it, in user terms and in code terms
- Cost: what the user or the data loses
- Fix: the smallest change that fixes the journey, with the file(s) involved
- Verify: how to reproduce and confirm (steps, or a test)

## Handed off
(one line each: to perf-check / refactor / technical-review / design / accessibility)

## Needs verification

Group repeated patterns ("5 pages repeat the same guard"). Be direct: name the route, quote the line, state the fix. Say what is working: if a journey is clean, give it a line and a pass, and don't invent findings to fill space.

After the report

Offer: fix Critical and High findings | draw the target flow for a journey before changing code | add a test per repaired journey (testing) | re-audit. Make no changes until the user picks.