Skip to content

/wbReview — Exhaustive Simulation () ​

/wbReview is the inspector. Its job is the plan-vs-reality diff: read what was supposed to happen (the plan), read what actually happened (the diff or the current state), and surface where they disagree. Unlike /wbAudit, which judges code against universal standards, /wbReview judges code against intent. Same code can pass an audit and fail a review — or vice versa — because the questions are different.

Read this if you want to know what --plan does that /wbAudit --wbPlan doesn't, why --act and --wbPlan are independent flags here too, and where review ends and refactor begins.


1. Role & target ​

AspectBehavior
RoleThe Inspector — surgical plan-vs-reality check.
TargetAn uncommitted diff, a recent commit, a directory, or a plan row.
Cell scopeNone directly. Review produces a report; chaining (--act / --wbPlan) routes the report into actionable artifacts.
Side effects allowedReading code, reading the active plan, comparing diff to plan row descriptions, reading recent reports under reports/<date>/.
Side effects forbiddenEditing source code, applying suggestions, mutating plan cells directly.

The plan-vs-reality framing is the design center. Three concrete asymmetries follow from it:

  • Scope creep is reviewable. If a plan row asks for "fix regex escape" and the diff also includes a CSS class change, /wbReview flags it. /wbAudit would not — extra CSS isn't audit-worthy on its own.
  • Missing work is reviewable. If the plan row says "add denylist + tests" and the diff includes the denylist but no tests, /wbReview flags it. /wbAudit looks at what's there, not what's missing.
  • Style consistency with the rest of the codebase is reviewable. If the diff introduces a pattern alien to the existing code, /wbReview surfaces the divergence even when the new pattern is "fine on its own."

These three together give review its distinct lane.


2. Argument resolution matrix ​

FormExampleWhat /wbReview does
No argumentCommand: /wbReviewReviews uncommitted changes (git status + diff). Maps each touched file back to the most-recent plan row that owns it.
Plan row IDCommand: /wbReview --plan (alone)Equivalent: review uncommitted changes through the plan lens.
Specific commitCommand: /wbReview <sha>Reviews a single commit. Maps to plan rows referenced in the commit body.
DirectoryCommand: /wbReview core2/packages/wb-core/Reviews all files in the directory against the plan rows that touch them.
Free-text scopeCommand: /wbReview "the auth changes"Refused. Same reasoning as /wbAudit — adversarial review is too sensitive to fuzzy targeting.

Key behavior: when reviewing a diff, the agent resolves "which plan row owns this change" by reading recent reports/<date>/plans/plan_*.md files and matching files-touched against the row's description. If no plan row claims a touched file, that file is reviewed under "scope-creep" by default.


3. Flag matrix ​

FlagShortcutModeWhat it does
--plan-pFilterStrict plan-conformance mode. Failures on any deviation (scope creep, missing required artifact, style divergence).
--act-aChainRoutes review output through /wbActOn — produces a sibling action file ranking review findings by impact/effort.
--wbPlan-PChainRoutes review output through /wbActOn's plan-generation engine — appends new rows to the active plan, one per critical finding.

--act and --wbPlan are independent and composable, same shape as /wbAudit.

How --plan changes the verdict ​

Without --plan, /wbReview is advisory: it flags issues but doesn't refuse. With --plan, it gates: any finding becomes a hard "review failed" verdict.

ModeScope creep findingMissing artifactStyle divergence
Default (advisory)Flagged with severityFlagged with severityFlagged with severity
--plan (strict)Hard failHard failHard fail

The advisory/strict split exists because reviews happen at different points in the workflow. Mid-task, advisory is more useful (you want to know without being blocked). Pre-merge or pre-release, strict is what you want.


4. Pipelines (the agent-native scenarios) ​

📋/wbReview Exhaustive Simulation
The mid-session "am I drifting?" check/wbReview
> /wbReview
[SYSTEM] Target: uncommitted changes (git diff against HEAD).
[CONTEXT] Active plan: plan_<package>_<date>.md (rows 1-3).
[MAP] Touched files → owning rows:
core2/packages/wb-core/src/tierEnforcement.js → row 1 (JWT)
core2/packages/wb-core/src/renderString.js → row 2 (escape)
core2/packages/wb-core/src/components/UnrelatedButton.vue → ⚠️ no row claims this
## Findings (advisory)
### 1 — Scope creep on UnrelatedButton.vue
**Severity:** P2 (advisory)
**File:** core2/packages/wb-core/src/components/UnrelatedButton.vue
**Why:** No plan row touches components in this session. The diff
adds a 30-line button component that isn't named in any row's
description.
**Why this is advisory, not strict:** the file might be necessary
infrastructure for row 2 (renderString uses code slots which use
buttons). But the plan row doesn't say so explicitly. Worth a
30-second judgment call.
**Recommendation:** Either (a) add a plan row for the button, or
(b) split it into a separate commit, or (c) defer the button work
to a later session.
### 2 — Missing test for row 1
**Severity:** P1
**File:** core2/packages/wb-core/src/tierEnforcement.js (changes present)
core2/packages/wb-core/tests/tierEnforcement.spec.js (no changes)
**Why:** Row 1's Verify column reads "unit test asserts alg:'none'
rejected." The implementation is here; the test is not.
**Recommendation:** Add the test before /wbValid. Without it, the
validator has nothing to run.
[OK] 2 findings, advisory. No mutation. Run with --plan to gate.
⚠️ Note: A `/wbWork` session has been running for an hour. The user wants a quick advisory pass: did anything I just did stray from what the plan asked for?

💠 Pipeline The mid-session "am I drifting?" check ​

A /wbWork session has been running for an hour. The user wants a quick advisory pass: did anything I just did stray from what the plan asked for?

💠 Pipeline The strict pre-validation gate ​

Same situation, but the user is about to run /wbValid and wants to be sure nothing slips:

💠 Pipeline The chained "review → plan rows for the gaps" ​

A long session has accumulated review findings that warrant follow-up work. Instead of fixing in place, route the findings into new plan rows:


5. Edge cases & refusals ​

TriggerWhat /wbReview does
No diff, no commit, no targetHalt. ❌ Nothing to review — no uncommitted changes, no commit specified.
Free-text targetRefused with disambiguation list.
Target file genuinely matches no plan rowReviewed under "scope-creep." Not a refusal — the user might be fixing typos that don't need a row.
Diff includes only generated files (dist-*, lock files)One-line notice. Generated diffs aren't review-worthy on their own.
/wbReview --plan with no active planHalt. Strict mode requires a plan to compare against.
--plan --wbPlan with no findingsProduces an empty review report; no plan rows added. The chained mutation is conditional on findings.
Target commit references a plan row that no longer exists in the active planNotice that the row is missing; reviews against commit body's description verbatim instead.

The pattern: /wbReview is a plan-aware critic. It reads intent (the plan) and reality (the diff), names where they disagree, and either advises or gates depending on --plan. The chaining flags turn findings into either ranked actions (--act) or new plan rows (--wbPlan), so review failures become tracked work rather than friction. The unifying principle: a review without intent is just an opinion; the plan is what makes it adjudicable.