Skip to main content

Exploratory Route Report Template

Use this at the end of each single-route or single-URL exploratory review.

This template turns GOV-08 into an execution artifact teams can reuse consistently.

Pre-flight checklist

Before starting a route review, write down:

  • Route / review unit: what exact page, route, or surface is in scope
  • User / operator goal: what the person is actually trying to achieve
  • Preconditions: auth state, role, seed data, provider state, environment constraints
  • Likely scenario classes: happy path, invalid/error, empty/loading, keyboard, persistence, role/session variance
  • Confidence risks: anything likely to limit completeness before you start

This keeps the review explicit before interaction begins and reduces fake-complete reporting.

Full template

Route: </url>

Page purpose:
- <what this page is for>

Preconditions:
- Auth/session: <signed in/out, role, provider state>
- Data/state: <seeded/empty/partial>
- Environment notes: <runtime/env constraints affecting confidence>

Elements found:
- <visible sections/controls>
- <revealed dialogs/drawers/menus>
- <notable states surfaced>

Uncovered elements:
- <element/control/state not adequately covered by current spec/tests>
- none

Use-cases exercised:
- Happy path: <done/not applicable>
- Secondary flows: <done/not applicable>
- Invalid/error paths: <done/not applicable>
- Keyboard path: <done/not applicable>
- Refresh/back-forward: <done/not applicable>
- Persistence/post-action verification: <done/not applicable>

Scenario classification:
- Validated:
- <item>
- Invalidated:
- <item + issue ID>
- Blocked:
- <item + blocker reason + issue ID>
- Uncovered-spec-gap:
- <item + why + issue ID or SPEC_GAP artifact>

Evidence notes:
- <what actually happened>
- <what persisted / did not persist>
- <important UI/API observations>
- <confidence limits if any>

Issues created/linked:
- <#id title>
- <#id title>
- none

Spec / traceability follow-up:
- Requirement IDs: <ids or none>
- Spec gap: <SPEC_GAP or none>
- Planned test path: <path or none>

Residual scope:
- <none | what remains and why>

Completeness label:
- Complete | Complete with blockers | Partial | Invalid review

Next URL / next action:
- </next-url>

Compressed chat version

Use this when the route is straightforward and you do not need the fuller breakdown.

Route: </url>
Purpose: <page purpose>
Preconditions: <auth/data/env>

Elements found:
- ...
- ...

Uncovered elements:
- ...
- none

Use-cases exercised:
- ...
- ...

Scenario classification:
- Validated: ...
- Invalidated: ... (#...)
- Blocked: ... (#...)
- Uncovered-spec-gap: ... (#... or SPEC_GAP)

Issues:
- #...
- none

Spec/traceability:
- Req IDs: ...
- SPEC_GAP: ...
- Test follow-up: ...

Residual scope:
- none | ...

Completeness:
- Complete | Complete with blockers | Partial | Invalid review

Next URL / next action:
- </next-url>

Filled examples

Example A — Complete

Route: /settings/profile
Purpose: update display profile safely
Preconditions: signed in as standard user; existing profile data loaded

Elements found:
- profile form
- avatar picker trigger
- save button
- cancel button
- validation messages

Uncovered elements:
- none

Use-cases exercised:
- happy path submit
- cancel path
- invalid submit
- keyboard traversal
- refresh persistence check

Scenario classification:
- Validated: rename flow persists after refresh
- Invalidated: none
- Blocked: none
- Uncovered-spec-gap: none

Issues:
- none

Spec/traceability:
- Req IDs: USER-PROFILE-01
- SPEC_GAP: none
- Test follow-up: ui/profile/profile-edit.cy.ts

Residual scope:
- none

Completeness:
- Complete

Next URL / next action:
- /settings/security

Example B — Complete with blockers

Route: /billing
Purpose: review and update billing details
Preconditions: signed in as workspace admin; no live billing sandbox access

Elements found:
- plan summary
- payment method panel
- invoices table
- manage billing action
- retry payment dialog

Uncovered elements:
- invoice empty-state contract

Use-cases exercised:
- plan summary review
- retry payment dialog open/close
- keyboard traversal
- refresh persistence for non-mutating states

Scenario classification:
- Validated: plan summary renders correctly
- Invalidated: payment retry dialog loses focus trap (#412)
- Blocked: manage billing redirect requires unavailable provider sandbox (#413)
- Uncovered-spec-gap: invoice empty-state behavior not traceable (#414)

Issues:
- #412 billing retry dialog focus trap
- #413 billing provider sandbox blocker
- #414 invoice empty-state contract gap

Spec/traceability:
- Req IDs: BILLING-02
- SPEC_GAP: billing empty-state copy and action rules
- Test follow-up: ui/billing/billing-dialog.cy.ts

Residual scope:
- full mutation verification for live payment method changes pending provider access

Completeness:
- Complete with blockers

Next URL / next action:
- /settings/team

Example C — Partial

Route: /integrations/slack
Purpose: connect and validate Slack integration flow
Preconditions: signed in as admin; workspace seeded; provider auth intermittently failing

Elements found:
- connect button
- status badge
- reconnect action
- disconnect action
- error banner

Uncovered elements:
- reconnect conflict state
- disconnected empty state actions

Use-cases exercised:
- initial connect attempt
- invalid reconnect state
- keyboard traversal

Scenario classification:
- Validated: error banner surfaced on failed callback
- Invalidated: disconnect action leaves stale connected badge (#515)
- Blocked: provider callback instability prevents full happy-path completion (#516)
- Uncovered-spec-gap: reconnect conflict messaging undefined (#517)

Issues:
- #515 stale integration status after disconnect
- #516 provider callback blocker
- #517 reconnect conflict contract gap

Spec/traceability:
- Req IDs: INTEGRATIONS-SLACK-03
- SPEC_GAP: reconnect conflict handling
- Test follow-up: ui/integrations/slack/reconnect.cy.ts

Residual scope:
- successful connect persistence and downstream state verification still unexecuted because provider callback is unstable

Completeness:
- Partial

Next URL / next action:
- move to next ready integrations route while blocker is active

Usage rule

  • Use the compressed chat version when there are no issues or only light findings.
  • Use the full template when there are multiple findings, blockers, spec gaps, or confidence limitations.
  • Every route report must still classify outcomes under: Validated / Invalidated / Blocked / Uncovered-spec-gap.
  • Every non-validated item should include an inline issue ID or explicit linked artifact.
  • Do not mark a route complete if findings are untracked.