| name | fable-review |
| description | How Fable 5 reviewed a diff — its own, a worker's, or a PR: reading order, what to personally verify vs delegate, refutation stance, severity honesty. Load before accepting any diff you didn't just watch yourself write, and before shipping any diff you did. |
Fable review
A review answers two questions, in this order: does it do what was
asked, and what else does it change. Order matters — a flawless
diff for the wrong task is worth nothing, so check spec-fit before
hunting bugs.
Read the full diff. Always. Never review from a summary, a worker's
report, or the parts that "look interesting." The bug is reliably in the
hunk you were tempted to skim. If the diff is too large to read in full,
that's a finding in itself: reject it into reviewable pieces.
Personally read novelty; delegate breadth. New user-facing behavior,
new logic, new judgment calls — read those lines yourself, every time;
that's where taste lives and taste doesn't delegate. Regression sweeps,
call-site enumeration, "does anything else use this" — fan those out to
agents. Delegating novelty review is how bad judgment ships under your
name.
Review to refute, not to nod. Your job is to construct the concrete
input, state, or sequence that makes this code wrong — not to confirm it
looks reasonable. Plausible-looking code is the null hypothesis, not a
finding. For each nontrivial hunk ask: empty input, second invocation,
concurrent call, unicode, the error path, the boundary value. If you
can't attack it concretely, say "read, no attack found" — which is
weaker than "verified" and should be reported as such.
A finding must survive your own verification attempt. Before
reporting a bug, try to trigger it — run the code, trace the value by
hand, check the caller actually passes what you fear. Report what
survives, ranked by severity, worst first. Label anything you couldn't
confirm as plausible-unconfirmed. A review that cries wolf on ten
maybe-bugs buries the one real one and teaches everyone to skim your
reviews.
Worker Concerns are agenda, not commentary. When a worker's report
lists concerns, every item gets resolved: verified false, fixed, or
explicitly accepted with a reason. A concern acknowledged-and-ignored is
the most predictable source of production surprises, because the system
literally told you where it was weak.
Nits: batch or drop. Style preferences that a formatter or a
convention doesn't already enforce are your preferences; either batch
them in one line at the end or drop them. Never let twenty nits share a
review with one real defect — the defect drowns.
The clean diff gets one adversarial pass. When everything looks right
and tests pass, that's the moment scrutiny naturally hits zero — so
spend one deliberate pass on "how could this be wrong anyway": wrong
file shipped, test asserting the bug, mock hiding the failure, migration
that works on empty tables only.
Verdicts are decisions, not moods. End every review with exactly one
of: SHIP, FIX-THEN-SHIP (with the fix list), or REJECT (with the reason
and a tighter spec). "Looks pretty good overall, a few thoughts…" is not
a verdict; it forces someone else to make the call you were supposed to
make.
