Skip to main content

One post tagged with "review"

View All Tags

· 4 min read
VibeGov Team

Most teams only optimize build speed and miss the quality signal: continuous discovery.

GOV-08 introduces Exploratory Review as the Exploration side of the VibeGov operating model: a structured discovery engine that finds usability and spec gaps before they become release debt.

This mode is designed to inspect shipped outputs, identify uncovered behavior, and convert findings into actionable backlog work.

The core idea​

  • Delivery flow answers: "How do we ship this correctly?"
  • Exploratory flow answers: "What are we still missing?"

Both are needed for sustainable quality.

Exploration is not QA theater​

A weak exploratory pass sounds like this:

  • "I clicked around a bit"
  • "nothing obvious broke"
  • "there are probably some issues"

That is not governance. That is drift with a progress accent.

A strong exploratory pass should:

  1. define the review unit purpose,
  2. record preconditions,
  3. inventory elements and revealed surfaces,
  4. execute a scenario matrix,
  5. classify outcomes explicitly,
  6. convert every uncovered or failing behavior into tracked work.

If no durable artifacts come out of the pass, the pass was incomplete.

Review like an operator, not a tourist​

Tourist review checks whether a page loads.

Operator review checks whether a user can actually complete work across:

  • primary actions,
  • secondary actions,
  • edge and error paths,
  • keyboard flows,
  • state transitions,
  • newly revealed surfaces like dialogs, drawers, menus, and validation messages.

This is where many teams discover that a route that looked fine on first render actually fails in the real workflow.

The scenario matrix matters​

Per route or feature, classify scenarios as:

  • Validated
  • Invalidated
  • Blocked
  • Uncovered / spec gap

This is much better than a generic "reviewed" label because it preserves the actual state of knowledge.

And whenever a route claims to save, mutate, delete, sync, import, connect, or reconfigure something, the review must verify the resulting persistence or contract outcome — not just visible UI confirmation.

What exploratory review does in practice​

Exploratory review runs continuously alongside normal delivery to keep backlog hydration active.

For each route or feature area:

  1. Inventory elements and states actually visible in the product.
  2. Validate behavior from an end-user perspective.
  3. Compare observed behavior with current specs and test coverage.
  4. Open focused issues for each uncovered contract or failure.
  5. Attach spec links or mark SPEC_GAP.
  6. Feed those issues back into the normal delivery flow.

Exploratory execution is analysis-first: it reuses governance rules, but does not write production code or run automation tests as part of the exploratory pass itself.

Why this reduces technical debt​

Technical debt grows when known gaps are informal, untracked, or postponed without structure.

Exploratory Review Mode prevents that by forcing every discovered gap to become a concrete backlog artifact with ownership and traceability.

That is why backlog hydration matters: it turns product reality into engineering reality before drift hardens.

What good output looks like​

Per page/feature review, publish:

  • review purpose
  • preconditions affecting confidence
  • elements and revealed surfaces found
  • scenario classifications
  • expected vs actual notes
  • issue links created
  • spec links or SPEC_GAP
  • next recommended backlog action
  • completeness label: Complete / Complete-with-blockers / Partial / Invalid-review

If gaps are found but no artifacts are created, the review is not complete.

Blockers should redirect work, not freeze it​

A blocked route does not mean the entire exploratory loop stops.

When exploratory work hits a blocker:

  • confirm it,
  • capture evidence,
  • open a blocker issue,
  • record confidence limits,
  • move to the next ready review unit.

This preserves flow without hiding the problem.

Adoption tip​

Start with a scoped surface, but keep the flow always active:

  • begin with your top 3 core routes
  • run exploratory continuously on a schedule that fits team capacity
  • track issue conversion rate, closure time, and repeat-gap trends

Then expand route coverage while preserving disciplined backlog hydration.