bedrock
Every sprint checks its own new floor. Nobody goes back down to see whether it loosened something three floors below. bedrock is that trip down, by an inspector who built none of it.
- Stage
- Verify
- Since
- Jun 2026
- Leaves
- AUDIT.md + runnable repros
“You know how a bank is reliable? I call it bank logic. It has to be reliable and 100% not flaky at all.”
The building and the frames
bedrock started as a prompt I gave agents every once in a while, after a heavy stretch of building. When I turned it into a skill I explained it like this: “it's kind of, we're building mini frames around the building and also solidifying it, but it's just that sometimes we're building too fast, we're not even sure if the foundations are solidified.”
Each sprint verifies its own work on its own terms. The agent that built it also trusts what it just installed. In my words again, things get flaky because “it doesn't check against its own, like, bolting.” So the audit is done by a different character entirely, one who trusts nothing because it built nothing.
Bank logic
A bank is never mostly right. Its core holds under every double-fire, interruption, race and restart, or it isn't a bank. bedrock holds the load-bearing parts of a codebase to that bar and proves fragility by pressing on it. Reading code and feeling good about it earns nothing.
Feature flows get pushed past normal use. One of these tests comes straight from the old prompt I used to paste: “if we kept switching convos, can it do that?”
Repeat
it rapidly
Interleave
it with other flows
Interrupt
it midway
Restart
the system in the middle
Switch context
mid-flow, again and again
Empty, zero, huge
as inputs
Cold and warm
run it both ways
Eight questions the builder never asks
These run against every load-bearing unit. Pick one to see the test that presses on it and a finding it produced in a real ledger.
What state is left behind if it dies in the middle of an operation?
Pressed byInterrupt it midway. Restart the system mid-write.
Accepting or declining did up to four writes in a row with no transaction. A failure halfway left a party half updated.
Fixed: Every write now runs in one atomic batch. A test forces a batch to fail and checks that the earlier write rolls back.
Silence outranks noise
A crash announces itself. A wrong balance with no error is the nightmare. So findings are ranked by how quietly they fail and by how much rests on them, and ten findings that bear load beat a hundred style nits. Naming and formatting never enter the report.
- 1
silent-wrong
A wrong answer with no error. Nobody finds out.
- 2
corrupting
Bad state gets written down and outlives the bug.
- 3
crashing
Loud. It announces itself.
- 4
degrading
Slower or clumsier, still correct.
Confirmed or suspected, never blurred
Suspicion is cheap and proof is the job. Every finding carries one of two labels, and a suspicion never gets the confidence of a proof. The scariest suspicions get promoted by actually pressing on them.
A repro exists, it ran, and it broke.
It gets one small file in audit/repros/, named by its ID, that cleans up after itself.
Reasoning only. Untested.
It has to name the test that would settle it. Orchestrator F-006, a possible lost write between two workers:Settle by: a parallel writer test against a temporary capacity file.
Every finding is written as a work order a stranger could pick up cold. This is a real one. The README promised that a rate-limited engine would be held. Under attack it was held in the logs and nowhere else.
- Head
- F-002 · confirmed · claim drift, degrading
- ID, proof status, severity. The ID never gets reused.
- Where
- src/engine.js · runAgent
- So a stranger can find it cold.
- Claim
- The README: locked mode “holds until the reset timestamp if that engine is rate-limited.”
- What the code or its docs promise.
- Reality
- It logs a hold event, then runs the engine anyway. The only real gate was on new coding jobs.
- What it did under attack.
- Repro
- audit/repros/F-002-locked-red-does-not-hold.sh
- Confirmed findings only. It breaks again or it doesn't.
- Blast
- Every station other than the coder (triage, fixer, review, feedback intake) kept spending calls against a rate-limited engine every poll cycle.
- What leans on it. This sets the priority.
The walk
The scope is the whole building by default. I put it to the agent as a question while we wrote the skill: “an auditor still needs to know the whole of the building, no?” If I name an area, the deep inspection goes there, and the regression sweep still runs over everything.
Read the vision
VISION.md, then the README and agent docs. Sediment and ambition look the same until you know what the building is trying to be.
Open the ledger
MAP.md and AUDIT.md, read as claims to verify. With no ledger, this is a bootstrap run that first builds the load-bearing map and the feature inventory.
Regression sweepalways first
Re-run every kept repro and the test suite. Something fixed that broke again outranks anything new.
Inspect
The question bank on core logic, the limit tests on feature flows, all inside sandboxes. Every attack gets logged, including the ones the code survived.
GuardNothing gets fixed during the walk. The moment the inspector patches something, it becomes a builder with authorship bias, and the rest of the walk is compromised.
Report and update the ledger
What was attacked, what broke, what held, what regressed, what wasn't reached. Then stop, or open fix mode if I asked for it.
Grades are earned under attack
No grade without a documented attack. “Bank-grade” means something specific: tried double-firing it, interrupting it mid-write, racing two of them, and here is what happened. A fix doesn't earn it either. After the orchestrator's fix run, its capacity governance was graded sturdy, because nothing had attacked the fixed version yet.
RSVP write path
flaky: Broke 1 time in 4 under a race.
bank-grade: Survived 10 of 10 concurrent double-fires. A forced failure rolled back cleanly.
Orchestrator capacity governance
cracked: Locked mode ran engines it claimed to hold.
sturdy: Fixed and the repro passed, but nothing had attacked the fixed version yet.
- cracked
- Confirmed broken.
- flaky
- Confirmed inconsistent under stress.
- sturdy
- No cracks found, not fully attacked yet.
- bank-grade
- Survived the documented attacks.
Run one: the Fantopy Orchestrator
The orchestrator turned GitHub issues into draft pull requests through a line of agents. The bootstrap audit ran with a configurability lens: for every setting, does it exist, does it reach behavior, what happens when it is wrong, and who notices. Three findings carried the run. A typo in one file silently swapped the engine for the whole factory. Locked mode claimed to hold and didn't. Five capacity knobs did nothing at all, and the live daemon was running with all five set.
- 10 JunBootstrapsuite 398/400
5 confirmed, 6 suspected, 1 sediment, 2 operational. Four repros written, and all four failed, which is what a repro of a real defect should do.
- 10 JunFix modesuite 415/415
Eight findings closed, scariest first, and every repro flipped green. The new engines command found five dead settings in my own machine's environment on its first run.
- 11 JunClose-out
No open findings left on the board.
- 14 JunF-014, a regressionsuite 426/426
The F-002 fix made a held triage job re-run every cycle and eat the budget. A second daemon, left running since May, made it worse. That was the risk F-008 had filed as suspected.
- 20 JunF-016, the deeper causesuite 446/446
The capacity breaker had no half-open state, so an engine that recovered in a minute stayed marked red for three hours. Hardened over six rounds of cross-family review.
Fixes loosen bolts too
F-014 came from the fix for F-002. A repair can crack something next to it, which is why every run starts by re-running the old repros, and why a regression is flagged louder than anything new.
The ledger also kept F-007 as suspected: a fixer could patch stale code because its base refreshed only after the first pass. That is the same problem the isomorph twin had named perishable stock.
Run two: a wedding RSVP site
The first bedrock run happened the day the skill shipped, on a wedding RSVP site I built for friends. Eight attacks went into the log, with every write aimed at a sandbox database branch, and produced five confirmed findings and five suspected. Two of the confirmed ones were silent. Importing the guest spreadsheet twice duplicated every guest without an email address. And two guests accepting the same plus-one at the same moment could mint a seat that didn't exist.
A later finding, F-008, showed that accepting or declining did up to four writes with no transaction, so a failure halfway left a party half updated. Every write on that path now runs as one atomic batch, proven by a test that forces a batch to fail and checks it rolls back. By the end of that day the site had 24 integration tests and the RSVP write path was graded bank-grade.
More features shipped after that. The ledger now opens by saying it is stale and listing exactly which entries are no longer true. That warning is the ledger working.
The ledger and the repros
Halfway through writing the skill I asked: “actually I think we should have a ledger, right, that lives on the root of the folder? Like an AUDIT.md, etc.?” It became the building's structural record, committed with the code. It has a weight budget: closed findings collapse to one line, stale suspicions get confirmed or dropped, and there is never a second file.
AUDIT.md
- ## Health boardEach subsystem, its grade, and the attack that earned it.
- ## Open findingsConfirmed or suspected, each with a repro pointer or a settling test.
- ## Closed findingsOne line each: what it was, when it was fixed, what proves it.
- ## Load-bearing mapWhat carries the building, re-verified every run.
- ## Feature inventoryThe flows the way a user lives them.
- ## Run logDate, scope, repros re-checked, new, regressed, not reached.
Repros are what make the next run honest. Each one is small, deterministic and cleans up after itself, and the next run starts by re-running all of them. A repro either breaks again or it doesn't.
Written
when a finding is confirmed
Fails
exit 1: the defect is there
Fix
scariest first
Passes
with the full sweep and suite
Promoted or retired
into the test suite, or a one-line note
When it stays quiet
bedrock steps aside, and says why, when:
- I want to understand a codebase before changing it. That is devour's job. bedrock reads the map devour leaves behind.
- It is a style or lint pass. If it doesn't bear load, it doesn't enter the report.
- There is one concrete bug I just want fixed. That gets fixed directly.
- The building is half-built on purpose. Mid-feature work gets audited once the floor is finished.
- There is no safe place to press. It never tests against live databases, live APIs, real credentials, or anything that sends, charges or deletes. The finding stays suspected and says why.
How a run is graded
- 1Every grade on the health board traces to a logged attack.
- 2Every confirmed finding has a runnable repro, and every suspected one names the test that would settle it.
- 3The regression sweep ran first, and its results are in the run log.
- 4The report ends with what was inspected and what wasn't reached.
- 5AUDIT.md is updated, still one file, still readable in one sitting.
- 6Nothing was fixed during the walk, and in fix mode, every fix met its definition of done.
A run that can't meet this says exactly which parts are unverified. Rounding up to confidence is the failure this skill exists to catch.