Skip to main content

GOV 08 EXPLORATORY REVIEW

This page embeds the canonical rule text and adds commentary after each section to explain why the section exists.

GOV-08 — Exploratory Review​

Commentary: Exploratory review is where VibeGov turns observed product reality into durable engineering work instead of informal feedback.

Purpose​

Exploratory review is a structured discovery loop that runs alongside normal delivery.

Its job is to continuously:

  • validate product behavior from an end-user or operator perspective,
  • reveal uncovered surfaces, states, and scenario gaps,
  • hydrate backlog with tracked follow-up work before those gaps turn into release debt.

Exploratory review is not a substitute for implementation or release verification. Its primary output is evidence-backed backlog hydration.

Commentary: The goal is not to "have a look." The goal is to reduce unknowns and convert them into governed backlog artifacts.

Execution constraints​

During exploratory execution:

  1. No production code changes

    • Exploratory is a discovery and validation activity, not implementation.
    • Keeping code unchanged preserves clean evidence of current user experience.
    • Fixes discovered here must be routed into normal delivery via issue -> spec -> implementation.

  2. Automation is optional supporting evidence, not the completion signal

    • Exploratory completion does not require automation suites when no implementation occurs.
    • Route or feature coverage must be established through scenario-based review of live behavior.
    • If work shifts into implementation or automated verification, switch modes and follow that mode's evidence rules.

Exploratory output feeds normal delivery flow for implementation, automated validation, and release decisions.

Commentary: Exploratory mode stays high-signal by focusing on live behavior, evidence notes, and artifacts rather than pretending to be implementation or CI.

Operating model​

  • Exploratory is continuous (always active as a quality/discovery engine).
  • It can run by explicit user trigger and/or schedule.
  • It is parallel to normal delivery behavior, not a replacement lifecycle.
  • A review unit can be a route, page, feature slice, API surface, or operational workflow, but the scope must be explicit.

Commentary: Treat exploratory review as an operating discipline, not a sporadic ritual.

Review anti-patterns to prevent​

  • Do not treat "page rendered" as "page validated."
  • Do not treat a toast, redirect, or visual confirmation as proof that persistence or mutation succeeded.
  • Do not collapse unrelated uncovered contracts into one vague finding.
  • Do not report findings without backlog/spec/traceability artifacts.
  • Do not allow a local blocker to freeze a whole review queue.

Commentary: Naming the common failure modes makes them easier to prevent during real execution.

Review posture​

Review the product like the person who depends on it, not like a passive observer.

For each review unit:

  • state the user or operator goal
  • identify preconditions, permissions, seed/state needs, and dependencies
  • traverse the unit through realistic primary and secondary flows
  • treat newly revealed surfaces and state transitions as in-scope, not optional extras

Revealed surfaces/states include, at minimum, dialogs, drawers, menus, validation surfaces, loading/empty/error/success states, disabled/enabled transitions, post-action controls, redirects, and follow-on states reached after interaction.

Commentary: Good review posture means operating the system through realistic work, not skimming the happy path.

Scenario-matrix review (mandatory)​

A review unit is incomplete until its scenario matrix is defined and every scenario is classified.

At minimum, include scenarios for:

  • happy path / primary flow
  • cancellation or abort path
  • invalid input path
  • empty state
  • loading state
  • edge and error behavior
  • keyboard/accessibility or non-pointer interaction
  • refresh/back-forward persistence path where applicable
  • state transitions and post-action states
  • permission, session, data-shape, or dependency-driven variations when relevant

For each scenario:

  1. exercise it from start to finish or until blocked
  2. compare expected vs actual behavior against specs, traceability, and existing test intent
  3. record evidence notes
  4. assign one classification:
    • Validated
    • Invalidated
    • Blocked
    • Uncovered-spec-gap

Commentary: A required scenario grid prevents reviews from stopping at "I clicked around and it seemed okay."

Persistence and mutation verification rule​

Any action that claims to save, mutate, delete, sync, submit, import, connect, or reconfigure must be verified by resulting state/persistence/contract outcome — not just UI confirmation.

Acceptable verification includes refresh checks, downstream-state checks, source-of-truth checks, or other evidence that the claimed mutation actually took effect.

Commentary: This is one of the most important anti-false-green rules in the whole governance stack.

Classification rules​

Use these classifications precisely:

  • Validated: behavior is exercised, specified sufficiently, and observed to match intent.
  • Invalidated: behavior is exercised and observed to fail, regress, or contradict intent.
  • Blocked: behavior cannot be meaningfully exercised because of a real prerequisite or external dependency blocker.
  • Uncovered-spec-gap: behavior or surface is reachable, but the intended contract is missing, ambiguous, or not traceable enough to judge.

A scenario that is only partially exercised must still end in one of the classifications above, with the evidence note explaining the limit.

Commentary: Richer classifications create more honest backlog truth than a generic "reviewed" status.

Surface and state coverage (mandatory)​

A page, route, or feature review is incomplete until all meaningful elements, controls, sections, and revealed surfaces/states are classified through the scenario matrix.

  • Do not stop after the first visible happy path.
  • Do not ignore surfaces revealed by clicks, submissions, errors, redirects, or state changes.
  • Do not batch unrelated uncovered contracts into one vague finding.
  • Do not report completion while any explored surface remains unclassified or untracked.

Commentary: This is what keeps exploratory review from degrading into shallow browsing.

Required follow-up artifacts​

Every non-validated classification requires tracked follow-up artifacts before the review unit can be marked complete.

Required follow-up by classification:

  • Invalidated: create or link a focused backlog item, capture expected vs actual behavior, and record required spec/traceability/test follow-up.
  • Blocked: create or link an explicit blocker artifact, capture what was attempted, why confidence is limited, and what work can continue elsewhere.
  • Uncovered-spec-gap: create or link the gap artifact, record the missing or ambiguous contract, and identify the implementation/test follow-up path.

If multiple scenarios expose different contracts, create or link separate artifacts for each distinct contract.

Commentary: Exploration only hydrates the backlog when each distinct finding survives as a durable artifact.

Blocker severity model​

Classify blockers before deciding how to respond:

  • Local-blocker: only this route/use-case is blocked
  • Flow-blocker: blocks a cluster of related routes/use-cases
  • System-blocker: runtime, environment, auth, provider, or dependency issue affecting broad execution
  • Governance-blocker: missing or contradictory requirement/instruction that needs clarification

The response should scale with the blocker, but the default remains: make it visible, bound its impact, and keep unaffected work moving.

Commentary: Not every blocker deserves the same response. Severity helps preserve flow without hiding risk.

Route-order heuristic​

When reviewing many routes and no stronger product-specific dependency exists, use this default order:

  1. Entry routes
    • landing, auth, onboarding, first-run, and public entry surfaces
  2. Core workflow routes
    • the main product paths users depend on most
  3. Settings/admin/configuration routes
    • billing, permissions, integrations, policy, account, and operational setup
  4. Edge/special/fallback routes
    • empty states, error states, redirects, exception paths, and rarely used operational surfaces

If a product-specific dependency order is stronger, use that instead — but make the ordering logic explicit.

Commentary: A default route order gives exploratory sweeps a predictable shape without pretending every product has the same dependency graph.

Required exploratory output (per review unit)​

  • review unit and user/operator goal
  • preconditions and confidence limits
  • scenario matrix with classifications
  • elements, states, and revealed surfaces exercised
  • expected vs actual evidence notes
  • issues/tasks/spec-gap artifacts created or linked
  • next recommended backlog action or next route

Commentary: Standard output structure makes exploratory reporting comparable, reviewable, and reusable.

Commentary: For route-by-route execution, teams should use the dedicated Exploratory Route Report Template to keep checkpoints uniform and artifact-complete.

Artifact completeness rule​

Findings without tracked artifacts are incomplete.

A note, screenshot, or verbal summary is not a completed exploratory result unless the corresponding follow-up work is linked in the backlog and its spec/traceability impact is recorded.

Commentary: This blocks ceremonial reporting and forces durable follow-through.

Review completeness rubric​

Every review unit should end with one explicit completeness label:

  • Complete — all scenarios accounted for and artifacts created
  • Complete-with-blockers — all reachable scenarios accounted for; blockers logged
  • Partial — intentionally stopped; residual scope listed
  • Invalid-review — insufficient coverage/evidence; must be redone

Commentary: A completeness label makes partial work visible instead of letting it masquerade as finished.

Done criteria​

Exploratory work is complete for a review unit only when:

  • the scenario matrix is accounted for end-to-end,
  • all invalidated, blocked, or uncovered items have tracked artifacts,
  • spec/traceability/test follow-up is identified for those artifacts,
  • the next recommended backlog action is stated,
  • the final completeness label is recorded honestly.

Commentary: Completion means ambiguity was reduced, artifacts were created, and the remaining state of knowledge is explicit.

Self-check before claiming completion​

  • Did I classify scenarios, or just sample them?
  • Did I verify persistence/data outcome, or only surface reaction?
  • Did every finding become a tracked artifact?
  • Did I record confidence limits honestly?
  • Did I move on from blockers correctly?

Commentary: A short self-check catches workflow drift before a weak update becomes accepted status.