Skip to content

feat(builder): forced self-refutation checklist before declaring done #252

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
eduralph merged 2 commits into from
Jul 5, 2026
Merged

feat(builder): forced self-refutation checklist before declaring done #252

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
dbccef2
feat(builder): forced self-refutation checklist before declaring done…
eduralph Jul 5, 2026
da429fd
fix(builder): phrase the self-refutation checks as yes-polarity (#247…
eduralph Jul 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions template/agents/builder.md.jinja
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,6 +75,28 @@ and leave the verify honestly unable to prove it (rather than a fabricated pass)
surfaces a NEEDS-HUMAN item in SUMMARY §6, so the human validates the fix at sign-off —
exactly where an irreducibly-manual check belongs. Ask; don't work around.

## Before you declare done — refute your own test (forced, recorded)

A green test only counts if it would have gone **red** without your fix and it drives the
**real** thing. This is where hollow evidence keeps slipping through — a Jepsen leg that
injects no nemesis, a fixture hand-built to exclude the failing node, a test driving a
stand-in instead of the production backend — each caught only downstream by the adversary,
at the cost of an iteration. So before you declare done, **answer these three questions and
record the answers in `build-notes.md`** (not just "yes" — the concrete evidence for each).
Each is phrased so a sound fix answers **yes**; any **no** means the test isn't binding yet:

- **(a) Genuine red?** Does the test **fail** with your fix **reverted**? Actually revert it
and re-run: it MUST go red. If it stays green, the test does not bind the objective.
- **(b) Production path?** Does the test drive the **production** code the fix changes — not
a copy / mock / re-implementation of it? A green run against a stand-in is worse than no test.
- **(c) Fixture includes the fault?** Does the fixture **include the failing element** — the
killed node, the real backend, an actually-injected nemesis — rather than curate it out?
A `healthy_fleet` built to exclude the node you killed proves nothing.

If any answer is "no", the item is **not done**: fix the test (or, per the headless caveat
above, flag it NEEDS-HUMAN) before you hand off. Record the three answers even when they all
pass — the human reads them at sign-off.

## Commit-ready for the target repo

The patch must be **committable to the target repo**, not just gate-green. When the
Expand Down
Loading