TL;DR: You should prove a risky idea can fail, then prove its refusal, in a disposable prototype before you let it touch production. Read the Ranex slice log for the records behind that rule.
You have seen a risky fix get a green check, a review approval, and a merge — then fail in the place where failure costs real users and real time. The issue is not that someone forgot to care. The issue is that production became the first honest test.
In this note
- Why prototype before production
- What the gate requires
- The reviewer-approved flake
- A practical prototype checklist
- Where Ranex stands
Why prototype before production
A scratch prototype gives you a place to discover that your design is wrong without adding runtime surface or promising a fix you have not earned. It is a gate before production, not a shortcut to it.
ADR-013 makes that boundary explicit for Ranex hardening ideas. The decision followed reviews that found authenticity gaps: a same-UID command could reach a signing key through /proc/<pid>/environ; the suite froze test IDs rather than bodies; an approver was an unauthenticated CLI string; and evidence replaced an earlier record rather than appending it.
Those findings did not authorize a pile of direct patches. They described risks and possible designs. A design that sounds sensible is still a design that has not faced the failure it claims to stop.
The rule is deliberately plain. Keep the experiment in a scratch git worktree or scratch directory, never in src/ranex. Start with a failing test that demonstrates the unsafe control. Make the smallest scratch change. Then show the intended behavior and a deliberate negative control. The scratch code ships nothing and never becomes an import path.
What the gate requires
The gate requires executable evidence, not an author summary. Each idea needs its observed red baseline, its green result, and a negative control that demonstrates refusal.
ADR-013 makes UID separation, test-body hashing, authenticated approvers, evidence chaining, per-run network denial, external journal anchoring, and negative controls testable. It also makes stale counts a visible documentation failure. Every idea has a two-week wall-clock time box. At expiry, the owner records one choice: polish and extend, drop the idea, or open a production slice. Silence is not an outcome.
That last part protects you from a prototype becoming permanent architecture by neglect. A prototype is research with a decision date, not a side project that gets waved through because it has survived long enough.
The production slice can open independently only when its own exit criteria are green. A passing prototype does not prove production integration is safe. That limit matters: copying a result into a new boundary introduces new code, new inputs, and new ways to be wrong.
The reviewer-approved flake
SLICE-011 shows why the artifact must outrank the report. It was a disposable durability prototype, not ADR-013’s authenticity hardening work, and it shipped nothing. Its five claims covered a provider watchdog, reconciler ordering, durable retry, durable blockers, and session-ID fencing.
Every claim started with an unsafe baseline and received a negative control. The slice closed on 2026-08-07 with nine done criteria met and a digest-bound record. That is useful evidence. It was not the end of the checking.
Its fifth claim had been reported stable and approved when supervisor reruns against the worktree found two failures in 16 full-suite runs. The failure was in the negative control. The fixture set PRAGMA busy_timeout after journal_mode; two concurrently opening workers could hit database is locked outside the catch. Captured worker stderr was discarded, so the useful signal disappeared with it.
The fixture was fixed, the full suite then completed 20 consecutive clean runs, and reviewers issued fresh verdicts on the corrected bytes. The lesson is harsher than “run tests again.” An unstable negative control cannot distinguish a race from a changed mechanism. If your control flakes, your conclusion flakes with it.
The project had already learned a related lesson in a hand-run mutation check: 59 refusals no test executed. A passing report is not a substitute for a test that turns red when the protection is removed.
A practical prototype checklist
You can use this discipline without Ranex. The move is to make the risky assumption visible before you rely on it.
- Choose a disposable boundary. Use a worktree or directory that production cannot import.
- Make the unsafe baseline fail first. Reproduce the actual key read, altered test body, stale record, crash, or race.
- Keep one negative control. Turn off the mechanism and show that the defect returns.
- Re-run the artifact on disk. Do not promote a session summary into evidence.
- Keep failure output. A fixture that discards stderr can hide the only clue you need.
- Write the expiry decision down. Extend, drop, or create the production slice on purpose.
- Rebuild for production. Copy the proven design into separately reviewed production work; do not ship scratch code.
Where Ranex stands
Ranex is pre-release. Its README describes a working verdict path, while the authenticity gaps behind ADR-013 remain unstarted in production. The README’s milestone rule is direct: every hardening idea must be proven red-first in a scratch prototype before production code.
That is plain status, not a promise disguised as a feature announcement. The current kernel has controls, but this ADR does not close RISK-06, RISK-07, or the other listed gaps. A prototype record changes what a later slice is allowed to consider; it does not make the risk vanish by prose before release.
Questions people actually ask
What does prototype before production mean?
ADR-013 requires each hardening idea to begin red-first in a scratch worktree or directory, then show green behavior and a negative control before a production slice can open.
What did SLICE-011 show about a reviewer-approved test suite?
SLICE-011 showed that its claim-5 suite had two failures in 16 full-suite runs after it was reported stable and approved; the corrected fixture then completed 20 consecutive clean runs.
Does a green prototype prove production integration is safe?
ADR-013 says no: a green prototype supplies evidence for a later production decision, while production integration still needs its own slice review and tests.
Your next risky idea does not need a grand plan. Give it a place where it can fail, make that failure visible, and refuse to call the result done until the artifact survives inspection. Try it. Break it. Tell me what broke.
Disclosure: this post was drafted with AI assistance. Every factual claim traces to the repository’s README or slice records — the same fact gate the product enforces on code. It ships only after Anthony’s own review.
Top comments (0)