Four Days
This quest shipped arguing that Beacon's missing port was the design. Four days later, Beacon had a port. A small engine now runs beside the workshop, answers on a reserved number like every sibling around it, and comes back on its own after a reboot. The four lessons before this one were not wrong when they were written, and the interesting question is not whether the refusal was a mistake. It is what happened to it — because it did not disappear. It moved.
What the Engine Does, and What It Is Forbidden To Do
The engine's job list is short, and every item on it is bookkeeping:
- Queue — a person composes a job: which pipeline, which pointer, one line of why.
- Claim — a working session takes the job, and the claim is visible to every other session on every machine.
- Record — every stage a session finishes is appended to that job's log, stamped with who did it.
- Review — reviewer rounds and their findings are logged against the job, and that log is what lets the workshop's verify step refuse a run whose review had not closed before the synthesis stage was first recorded done.
- Serve — the material a pointer names, and the web interface where all of the above is visible.
The forbidden list is the old refusal list, narrowed to what still matters. No render: the engine has no route that makes media, and every frame is still made by a command-line run that a session starts. No scheduler: nothing in it fires on a clock. No brain: taking a job hands a work order to a working session, and the engine judges nothing. The architecture document compresses all three into one line worth stealing — the engine is the clipboard, never the camera.
Why the Table Said Yes
The stated reason was organizational. Riding the shared message thread as a queue had become clumsy, and the family already had the right shape: the quest workshop and the memory steward each ran a delegation engine of their own. Adopting it was not building a second mechanism beside a working one; it was joining the one the family already used — and the same day, the engine's mechanical core was extracted into a shared kit, because three workshops now ran it.
What the engine carries once it exists is the decision table's answer from the lesson before. Jobs started being taken on a second machine, a travelling laptop as well as the desk, so a claim has to live somewhere both can see: state coordinated across concurrent callers. A laptop taking a job has to read the same material as the desk rather than a stale local mirror: several clients need the same answer. Two rows came back yes. The table did what it was built to do. It never forbade a service; it said when one had been earned.
The warning in that lesson predicted the rest. Promoting a workshop, it said, is contained work, and by then you know what the interface should be. It was contained because the interface was not invented. The engine was ported whole from a sibling, down to its command verbs.
How to Move a Refusal Without Losing It
The dangerous version of this story is erosion: someone adds a small server because the need is real, and the reason that held the line is never read again. What happened here is the opposite, and it is repeatable. The reason was re-read. The part of the refusal the new facts no longer supported was withdrawn by name. The part they still supported was restated more precisely than before — not "no server" but "a server that never renders, schedules, or judges." And the new line came with its own alarm: if a future need sounds like "the engine should render this," that is the eroded version, and the work goes back to a session.
The rest of the workshop moved in step. The engine gave Beacon uptime of its own, and uptime cannot ride another project's dependency upgrades, so the borrowed environment ended the same week. That is what a refusal written with its reason buys you. When the world changes, you can tell exactly which parts of the refusal changed with it, and which did not.