There is a moment when an internal tool stops being an experiment, and it is not the moment it gets a README or a test suite. It is the moment you stop trusting yourself to change it casually. The engine gateway, the router that decides where this factory’s tasks run and whether their content may leave the machine, crossed that line quietly over four review runs with ledger ids EG-022 through EG-025: every material changeset to the gateway now gets an architecture review, through the gateway itself, before it gets committed.
Dogfooding a review tool on its own changes sounds like a party trick. EG-025 is why it is not.
The refactor that looked like housekeeping
The change under review was the kind you approve while reading email: the cloud-egress confirmation gate, previously a function that exited the whole script when a run lacked consent, refactored to return a status code so its two call sites could own their own exit paths. Tidier control flow, more precise ledger wording, two new tests. All 106 existing tests passed.
The review found eight findings, mostly nits, and one that was not: under the new calling convention, the callers guard the function call to capture its status, and that guard suppresses the shell’s abort-on-error behaviour inside the function body. So when the function’s first step, reading the engine’s runtime class, failed, the failure no longer stopped anything. The runtime variable came back empty, the checks keyed on it fell through, and an autonomous run would have sailed past the egress boundary on the “proceed” path. The gate, whose single job is to fail closed, had learned to fail open, in a refactor whose whole purpose was to make its behaviour cleaner.
The fix was one line plus a stderr message: a failed runtime read now returns refusal immediately. It was applied the same session, pinned by test, and the suite went to 108. The ledger for EG-025 records the review, the verdict, and the human’s tollgate approval.
The part that makes it a platform story
The model that ran the EG-025 review is the same model that wrote the refactor being reviewed. If you expect a reviewer to defend its own earlier choices, that arrangement sounds worthless. In practice the separation that matters is not who, it is what: the writing session was optimising for “make the change work”; the review session was handed a different contract, a different prompt, and a findings-list-plus-verdict output format, with the diff as evidence. The reviewer had no stake in the code being good. It found the regression precisely because reviewing and writing are different jobs, even when the same engine does both.
That is also what marks the gateway’s crossing from prompt to platform. A one-off script gets edited and shrugged at. A platform component has control surfaces whose regressions hurt silently, so it earns a standing ritual: the trigger is any material change to those surfaces, the route is a review task through the tool’s own front door (which dogfoods the product every time the product changes), and the discipline is that findings get closed in the same session or explicitly parked in the backlog with their deferral written down. EG-022 through EG-024 established the habit on ordinary changesets. EG-025 paid for all of them.
The part worth stealing
Pick the internal tool you change most casually and ask what its control surfaces are: the two or three code paths where a silent regression would mean permission granted, data sent, or money spent. Those paths deserve a review trigger that does not depend on you feeling careful that day. The reviewer can be a model, a colleague, or a checklist run by your future self; what does the work is the standing appointment and the demand for located findings, not the reviewer’s identity.
What Next
The Blog Factory Eats Its Own Dog Food
Earlier in From Prompt to Platform: the first time a Hekton system was pointed at itself, and why self-hosting is this factory's favourite proving ground.