Skip to main content

Checkpoint Reporting

VibeGov reporting should reduce ambiguity, not create it.

A good checkpoint tells the next reader:

  • what mode you were in,
  • what was actually done,
  • what evidence exists,
  • what remains blocked or unresolved,
  • what should happen next.

If you are not sure which checkpoint shape matches the work, use Mode Selection and Evidence Closing first.

Exploratory checkpoint template​

Use this when the pass is analysis-first.

  • Review unit: route/page/feature under review
  • Purpose: what the user is trying to achieve
  • Preconditions: auth/data/runtime limits affecting confidence
  • Elements / revealed surfaces: what was actually exercised
  • Uncovered elements: controls/states/contracts still not adequately covered
  • Scenario status: Validated / Invalidated / Blocked / Uncovered-spec-gap
  • Expected vs actual: concise notes for failed or interesting paths
  • Artifacts created: issue links, spec links, SPEC_GAP, traceability notes
  • Residual scope: what remains, if anything
  • Next action: next route, next issue, or blocker recovery step

For route-by-route execution, use the dedicated Exploratory Route Report Template.

Operator copy/paste block​

Use this compact form in chat, threads, standups, or agent checkpoints when you need consistency without the full expanded template.

Route: </url>
Purpose: <goal>
Preconditions: <auth/data/env>
Elements: <key surfaces exercised>
Uncovered: <none | list>
Validated: <summary>
Invalidated: <summary + issue IDs>
Blocked: <summary + issue IDs>
Spec gap: <none | gap + artifact>
Residual: <none | what remains>
Completeness: <Complete | Complete with blockers | Partial | Invalid review>
Next: <next route or action>

Development checkpoint template​

Use this when behavior changed or when Development is running release-readiness/shipping checks.

  • Active issue: ID + title
  • Requirement IDs: bound requirements
  • Scope: what changed
  • Validation: commands/checks/tests run + pass/fail
  • Release readiness: build/startup/deploy/smoke/version checks when applicable
  • Artifacts: commit hash, PR/release artifact if applicable
  • Residual risk: anything known but unresolved
  • Next action: validate further, merge, release, or continue backlog

Blocker checkpoint template​

Use this when work cannot meaningfully advance.

  • Blocked unit: issue/route/feature
  • Blocker: exact constraint or failure
  • Attempted actions: what was tried
  • Confidence limits: what remains unknown
  • Artifact created: blocker issue link
  • Redirected work: what you moved to next
  • Recovery condition: what must become true to resume

Release verification checkpoint template​

Use this as a Development sub-template when checking integrated readiness.

  • Build/version: what was reviewed
  • Covered scope: what was in/out
  • Integrated results: pass/fail summary
  • Known blockers/risks: anything preventing confidence
  • Decision: go / no-go / conditional follow-up
  • Next action: release, rollback, patch, or continue validation

Good vs bad examples​

Bad:

  • "Reviewed the page, mostly good, some issues found."
  • "Save flow works."
  • "Blocked by auth."

Good:

  • "/settings/profile: tested rename, cancel, invalid submit, valid submit, refresh persistence, and keyboard traversal. Invalidated: avatar dialog focus trap (#214), profile save persistence gap (#215). Blocked: billing subpanel due to missing role grant (#216). Residual scope: role-variance review pending."

Reporting anti-patterns​

Avoid these:

  • "done" with no evidence
  • "reviewed" with no scenario classification
  • "blocked" with no blocker artifact
  • "tested" with no named checks or outcomes
  • one giant summary issue for many unrelated uncovered behaviors
  • UI-success claims with no persistence/data-outcome verification

Workflow self-check​

Before claiming completion, ask:

  • Did I classify scenarios, or just sample them?
  • Did I verify persistence/data outcome, or only surface response?
  • Did every finding become an artifact?
  • Did I record confidence limits honestly?
  • Did I move on from blockers correctly?
  • Did I distinguish exploratory from Development evidence?

Why this matters​

Weak reporting creates false confidence.

Strong reporting creates:

  • easier handoff,
  • better backlog quality,
  • faster review,
  • cleaner governance history.

When checkpoint/reporting feedback is materially edited by a human or reviewer, that can also become input to the Feedback Assimilation Pattern so the system learns from the change instead of only applying it once.