ULTRON.

FIXThe identity is a free cookie, and the chat minted one for anyone who asked. A cookieless loop took a fresh quarter-million tokens per call and a fresh three-second window with it, so the only thing standing between one script and the whole day's allowance was the global cap — and the day's allowance, spent, greets every real user with back tomorrow.

• The address is metered: four free packs invented a day, and two million tokens spent a day. Both counters are on disk, so a watchdog restart is not a fresh day.
• A pack is counted on the first use of an identity, not on the page load — a cookie lifted off a page and never spent owes nothing.
• A signed-in account is held to the token half only. It already has an identity; inventing one is not its business.
• Refusals carry Retry-After and say which line they hit, and the page now gives the wait a unit — a day-scale fence in raw seconds read as nonsense.
• New suite, 29 checks across three starts: eight fail on the old build, which serves four identities from one address without complaint. The meter was proved to survive a restart and to clear.
• Cost, stated: four identities per address per day, so a flat that never signs in meets the wall on the fifth. Signing in lifts it.

FIXThe brake on the login was keyed on the address, and the address is a header the caller writes. A hundred wrong passwords took one curl loop and one variable; twenty guesses per address was twenty guesses repeated for as long as you could type a new number.

• The name is fenced now, which is a key nobody can choose — thirty guesses at one name inside a quarter of an hour and that name is out for five, checked before the hash. The address fence stays as the outer ring, sized for a fumbled run rather than a dictionary.
• Both maps are on disk. The watchdog restarts the server, and a restart used to hand every fenced address its budget back.
• New suite, 25 checks over HTTP, each guess from a different address: nine of them fail on the old build and the rotating address walks straight through six attempts. The lock was proved to survive a restart and to expire afterwards.
• Cost, stated: thirty wrong passwords lock that name out for five minutes even for the person who owns it. That is what a per-account brake is.

FIXThe customer login had no brake at all. The operator gate has had one since the first night; the login a stranger actually reaches answered a hundred wrong passwords in fifteen seconds and refused none of them, each attempt spending 120,000 hash rounds. Worse, an unknown name skipped the hash entirely, so the response time named every account that exists.

• Attempts are counted per address and the address is out after twenty failures in ten minutes, for five. A right password clears it. Signing up shares the budget, because both spend the same hash.
• Unknown names are hashed against a random dummy salt, so a login costs the same whether the name exists or not.
• Hashing is held to one slot per core with a bounded queue, so a burst waits its turn instead of owning the machine; past the queue the answer is a plain 429 with Retry-After.
• The page had its own fault: it parsed every reply as JSON, so a 429 came back as an error page and the button went silent. It now says too many attempts — try again in N seconds.
• New suite, 20 checks over HTTP, and nine of them fail on the old build. The lockout was also proved to expire, on a restart with a three-second lock.

FIXSigning up asked the account map whether a name was free, spent a hundred thousand hash rounds, and only then wrote the row. Nothing held the gap. Eight people arriving together on one name all read "free" and all registered it: the last write wins the key, so seven of them are told they have an account whose password is not theirs — and the one whose password it is gets a salt they never chose. Both sides are told it worked.

• The name check and the row behind it are one step under the lock now, and the check is re-run inside it, so the map decides rather than a read that went stale while the hash ran.
• The 120,000 PBKDF2 rounds stay outside the lock — a signup waits behind a hash, not behind a lock, and a hash never waits behind a signup.
• Claiming an account carries what the visitor already had: the balance move and the machine binding were both read-modify-writes outside a lock, and are now one step each — the balance through the balance lock, the binding under the lock the rest of the map uses.
• New suite, 25 checks: five rounds of eight simultaneous signups on one name, then a round where the winner's password must still open the account and the seven strangers' must not, then eight names at once that must all survive. The old build registers seven or eight of the eight, and the man who was told the name was his cannot log in to it — the last write's salt is the one on file.

FIXBoth address fences asked the question under a lock and wrote the answer down after letting it go. Eight people — or one person with eight curls — arriving together from one address all read an empty fence and all took what the fence exists to refuse: a free half-million pack, and a thousand-million referral fee. The eight marks then fought over a single temp file, so the address was not even burnt afterwards.

• The free pack's check and its mark are now one step inside the balance lock, and the mark lands only after the grant is in the balance — a burnt fence is never burnt for nothing.
• The referral fence is the same, inside the graph's lock, and a refusal leaves the address exactly as it found it.
• An operator press no longer burns an address it was only testing: the escape from the fence no longer writes to it.
• New suite, 35 checks over HTTP: six rounds of eight simultaneous callers per address, each round on its own address. The old build paid two to four per round and paid out 8× the referral fee; here every round is exactly one grant, seven refusals, and one fee per round.
• The old build also throws PermissionError out of the referral store under the same run.

FIXThe receipts were the last read-modify-write without a lock, and the page polls them while everything else writes to them. A trim of the list wrote its own copy back over a receipt written a second earlier — a row that vanished, and the output that later came back for it had nowhere to land. Two rows minted at once buried one another, and two saves fought over one temp file: the old build sprays PermissionError out of the receipt store under a hammer.

• The list trim, the dismissal, the take-back and the row write are each one step under the lock the box already uses.
• The trim no longer replaces the list: it removes only what it took, by identity, from the list that is there at the moment it writes — so a row added inside the step survives it.
• A new race suite, 15 checks: the window is held open deterministically by hooking the trim, and a hammer runs writers against the polling reader. Three of the checks fail on the old build — both window checks and the collision count — and all 15 pass here.
• Live over HTTP: 24 keeps across 175 concurrent polls, no receipt missing, six rounds clean; a live drop took its row and a second press named the first.

FIXA keep and a drop could overwrite each other. The keep read the box, then wrote it back; a drop landing in between removed an entry and recalled its receipt, and the keep's write put the entry straight back — a command sitting in the box under a row that said it would never run. A drop pressed on a row the five-entry cap had just taken answered nothing at all, so a press that missed looked exactly like one that landed.

• The box's read-modify-write, its drop and the projection the page reads are each one step under the lock now. Nothing can interleave between the read and the write.
• A drop that takes nothing says why, in the same words the take-back refusals use: the box filled up and pushed it out, it aged out of the box, another press dropped it, the box is empty.
• The page sends the receipt with the box id, so a click that arrives late is still that row's press and never a wildcard drop-all. The note lands on the receipt the row left behind and fades.
• 12 new checks on the box suite, and a new race suite: 20 rounds with the window held open deterministically, plus a hammer of keeps and drops. All 20 rounds fail against the old build.
• Live over HTTP: a ghost press answered the box filled up and pushed it out just now, a live one dropped without a word. In the browser the bar stayed at 5 of 5, the flag moved on, and the receipt carried the refusal.

FIXFive is a wall and the box never said so. The sixth kept command pushed the oldest out and nothing on screen had warned which one was at risk, so the operator could not drop the one he meant to lose first.

• The bar now counts itself — 3 of 5 — and names the entry it would actually take: next keep pushes this out, in amber, on the row itself.
• Every held command shows its age. The clock is the other wall, and a hold with five hours on it is nearly gone by itself.
• The count falls and the warning moves when one is dropped, and clears once the box is no longer full. A box that is not full flags nothing — there is nothing to lose yet.
• 408 checks to 425, sixteen of them failing against the old build. Live: the flagged row was the one the sixth keep took, with the cap's words in its receipt, and the warning moved to the next.

FIXThe five-entry cap pushed a two-minute-old hold out of the box and called it "aged out" — the six hours it never got were still ahead of it. And every route out of the box wrote the same word, so a hand-drop on a row that had aged once before still read "it aged out" a second time.

• Three ways out of the box, three reasons. The press is dropped from the box. The clock is aged out of the box, stamped with the second its six hours actually ran out. The cap is the box filled up and pushed it out, stamped when it was pushed — which is now, not six hours' time.
• A row that nothing witnessed — a record left by an older build, or a hand on the file — no longer invents a press: it says it left the box and nothing more.
• The reason is set and the others cleared on every recall, and all of them come off when a row is re-armed for release. A stale flag used to survive a second leaving and misname it.
• The receipts bar and the row body both read the reason from one pair of helpers rather than a nested conditional per surface.
• 391 checks to 408, seven of them failing against the old build — including the exact lie, a drop reading "it aged out of the box". Live over HTTP: six holds pushed the first out with the cap refusal, a hand-drop refused with its own words, and an entry aged eight hours on disk was recalled at 2h ago with the clock's refusal while the fresh hold beside it stood untouched.

FIXA recalled row said when it was kept and never when it stopped being held, so a command that aged out hours ago read "kept 7h ago" as though the wait were still running.

• Every route that takes a row back now writes the moment it left — the press, the six-hour clock, the five-entry cap, and the read-side net for entries nothing else saw go.
• An aged row is stamped with the second its clock ran out, not with the moment a page happened to look, so the refusal says "it aged out of the box 2h ago" instead of "just now".
• The line reads kept 7h ago, aged out 1h ago: the keep and the loss, both in the past where they belong. A row still in the box is unchanged.
• Found on the way: a receipt whose box entry the read path trimmed was called "dropped from the box" even though the clock had done it. The read now tells the two apart by whether the entry is still in the box's file.
• Also: /api/pay now states the 200,000-token stay bonus, and the price suite proves the grant rather than trusting the copy. The watch board's save no longer aborts when it lands mid-rebuild and finds a key missing.
• 376 checks to 391, six of them failing against the old build; the aged line was rendered from the shipped code and read back. Watch suite 25 to 28, four failing against the old writer.

FIXA kept command had three ways out of the box and only one of them told the receipt. Press the drop link and the row learned the wait was over. Let it age past six hours, or keep a sixth command so the cap pushed it out, and the row went on describing a future that had already gone.

• The box is where a command waits when nothing can run it, and its receipt is the record of that wait. The clock and the five-entry cap both removed entries silently, so the receipt still pointed at a box entry that no longer existed: no take-back offered, no refusal reason, nothing to say the command would never run.
• Both routes now recall the row the moment the entry leaves, and write it down rather than holding it in memory — the record is correct before anything reads it.
• The two are told apart from a drop: the row reads "taken back, then aged out of the box — it will not run", and a take-back refuses with "it aged out of the box" instead of blaming a press nobody made.
• Dropping the whole box now sweeps the already-aged entries too, so a drop-all leaves nothing behind still claiming a hold.
• 362 checks to 376, six of them failing against the old code. Live over HTTP: an entry aged seven hours on disk and the server restarted — the read emptied it from the box, recalled the row as aged, and refused the take-back with the right words while the fresh hold beside it stood. Then six holds on one identity: box held five, the oldest recalled with the reason and the rest untouched. The aged line rendered in the browser.

FIXTwo identical tells written before receipts existed both invented a row, and the two real rows still in the box were then marked "dropped from the box" while both commands sat there, still going nowhere.

• Linking waited for exactly one free matching row. With two tells of the same words there were two free rows, so neither was used: each tell minted an empty receipt, and the read then saw the real pair named by nobody and recalled them. Dropping a chip recalled nothing; the receipts said the commands were gone when they were not.
• A tell now takes the earliest taken-back row that no other live tell names, and the tells are linked in the order they were written, so the k-th tell of a text keeps the k-th copy. Two twins stay two commands instead of collapsing into phantoms.
• The kept-command rows the chat path mints were excluded from that search even though they are the rows their own tells name — a tell that lost its pointer could not take its own row back. They are candidates now.
• A link made while reading the receipts lived only in memory. Nothing else wrote the box file, so a restart before any other write replayed the tells pointerless under rows that still existed. The read now persists it.
• 351 checks to 362. Proved three ways: the one-candidate rule back fails 6, the kept-row exclusion fails 2, the save dropped fails 1. Live over HTTP on a real stripped pair: both linked to their own rows, none minted, none recalled; one dropped — only that row recalled, take-back refused with the reason — the survivor released alone and re-armed. In the browser: two chips, the drop printed the recall on one row, the other still offered, no script errors.

FIXA command kept before receipts existed had no receipt to name: dropping it recalled nothing, so its row went on claiming the box still held a copy that was already gone.

• Tells written by the older build carry no receipt pointer, and everything since keys on one. Dropping one was a no-op — the row sat there announcing a future action that had already been cancelled — and the read-side fallback matched on the words, which any identical twin could keep alive.
• A tell that names no receipt now gets one: a taken-back row of the same command that no other tell has claimed, otherwise a fresh row of its own, exactly as a new ask is given. Nothing is stolen — a row only moves when no other live tell names it.
• Linking happens on read, under the lock, because the page asks for the box and the receipts at the same moment. Without the second check inside the lock both requests minted a row and the loser's was left orphaned and recalled while the tell's pointer had moved on — reproduced 4 out of 4 against the unlocked version.
• A take-back that arrives beside a pointerless tell of the same words joins that tell instead of being eaten as a repeat.
• 323 checks to 351, the new ones proved by breaking the linking, the claim test and the adopt branch. Live: a real pointerless entry from last night linked on read, dropped to "kept, then dropped from the box — it will not run", and refused a take-back with that reason; a second linked, released to a machine, re-armed one row and offered the take-back. In the browser the chip rendered alone, the drop printed the recall, one row, no script errors.

FIXA command kept from an answer while no machine was linked existed only as a chip in the box: no receipt, nothing in the transcript, and the output it eventually produced was thrown away.

• The box could be the only home of a command. Ask for something with nothing bound and the answer was kept there, out of sight of the transcript — and the receipt bar, which records every taken-back command, had no row for it.
• So dropping that chip lost the command with no trace at all. When a machine eventually linked and ran it, the output echoed a token that matched no receipt and the answer went nowhere: it ran, and the page never showed it.
• Asking twice for the same command was the same fault from the other side. The box deduped a chat reply by text, so the second answer was eaten as a repeat of the first and only one command was ever kept.
• A kept command now gets its own receipt, and the box entry names it. Dropping the chip recalls the row — "kept, then dropped from the box — it will not run" — and a take-back is refused with that reason. Releasing it re-arms the same row, names the machine it went to, and the output fills it.
• A repeat is now the same turn, not the same words: two identical asks are two commands with two chips and two receipts, while a retried message stays one. Hand-added tells, which have no turn to name, still collapse by text.
• 286 checks to 323, eighteen of them failing against the old code. Live: two identical chat answers, both kept, neither recalled, one dropped and only that row recalled, the survivor released alone and re-queued, box empty. In the browser the receipt stayed quiet while the chip stood, then printed the recall on the drop, and a released row showed the machine and the take-back offer.

FIXTwo identical commands taken back were collapsed into one tell, and the older receipt was recalled as dropped while its copy still sat in the box.

• The box refused a new tell when the same text was already the last thing in it. So take the same command back twice and only the first stayed: the second take-back re-pointed that one tell at its own receipt, and the first row lost its entry.
• The row that lost it read "taken back, then dropped from the box — it will not run" while the command was still in the box and would still run. One of the two commands was quietly eaten: only one copy came back out on the next link.
• A tell is now a repeat only of the same receipt. Two take-backs of identical text are two tells, each naming its own row; a repeat by text alone still collapses on the chat path, which has no receipt to name.
• Dropping one of the two recalls only its own row and leaves the other's tell alone. Releasing both puts one copy back for each, and each output fills its own row with no void and no double-run mark.
• 270 checks to 286, proved six ways — every one of the six new checks fails against the old code. Live over HTTP: two rows queued, both taken back, two tells with different receipts, neither recalled, one dropped — only that one recalled — the other released and re-queued, a whole-box drop recalling both. In the browser: two identical chips with a drop link each, the click recalled one row and left the other's chip standing, no script errors.

FIXDropping a pulled-back command off the box left its receipt saying "taken back to the box" forever — over a command that would never run.

• The box is where a taken-back command waits, and the receipt beside it in the transcript pointed there. Drop the command from the box and the receipt had no idea: it kept the pointer, kept the wording, offered no take-back (a held row never does), and sat there for a day describing a wait that had already ended.
• The box ages commands off after six hours and receipts only after twenty-four, so time did the same thing quietly: at six hours the hold vanished and the receipt went on claiming it.
• A dropped or aged hold now recalls its receipt. The row reads "taken back, then dropped from the box — it will not run", the offer stays off, a take-back is refused with that reason, and the mark is written down rather than sitting in memory.
• The box's own drop repaints the rows with it, so the truth is on screen the moment the command goes.
• 246 checks to 270, proved four ways: the recall dropped fails 1, the read-time check cut fails 1, the finished-row guard cut fails 1, the refusal reason blanked fails 1. Live over HTTP: released, taken back, dropped — one row, same id, recalled, take-back refused with the reason, box and queue both empty. In the browser: the row read "taken back to the box", the drop put it to "dropped from the box" with the offer gone, no script errors.

FIXReleasing a pulled-back command a second time grew a second receipt, and the first one went on saying "taken back to the box" while its command was out and running.

• A release that is taken back sits in the box with its receipt. Sending it out again — the same command, the same intent — wrote a fresh row and left the old one behind, still marked as back. Two rows for one command, both pointing at the same copy, and whichever was older never caught up with the truth.
• Going out again now re-arms the receipt that goes with the hold: the new release token is written on it, it stops reading as back, and there is one row where there was always one command. If that receipt was dismissed while it sat in the box, a row is minted instead, because a release with no receipt is invisible in the past.
• The void stopped calling a row a double run when the row is the one that just filled: it ran the copy it was holding, once. A row that filled also stopped reaching for a queued copy of the same text — its own copy came off the queue when it was pulled back, so anything waiting under that text belongs to someone else.
• A held row keeps its pointer now instead of having it pruned on the first read; only a finished row prunes. A row that answered twice keeps the newest answer and says so, rather than stacking rows.
• 230 checks to 246, proved three ways: minting the second row again fails 6, voiding the filling row again fails 6, pruning a held pointer again fails 1. Live over HTTP and in the browser: released, taken back, released again — one row, same id, the offer back — then the machine took it, the output filled that one row, nothing marked, nothing left in the box.

FIXA take-back on a row with no pointer could take the one copy another row had already named — and the page offered it every time.

• A row released before tokens existed has no token of its own, so its take-back found a copy by text: the oldest one. If another row had already named that release, the text take stole it. The named row then read as gone off the queue, refused every take-back for as long as it lived, and when the stolen copy answered, the token on the output filled the wrong receipt.
• A pointerless take-back now passes over any copy another row points at and takes the oldest free one. With nothing free it refuses, rather than steal.
• The offer follows the same rule: a row with no free copy stops showing a take-back that could only mislead. When a refusal does come, it says the copy is claimed instead of pretending the queue moved.
• 218 checks to 230, proved three ways: the plain text take restored fails 8, the offer flag left on text fails 1, the refusal reason cut fails 1. Live over HTTP on a stripped row with a named twin waiting: it took its own copy, the twin kept its place, and the page showed the twin's offer and not the stripped row's.

FIXA row released before tokens existed still voided by text, so it could eat an identical twin — and the pointer on a finished row was left as a dead key.

• A take-back of a pointerless row now reads back the token of the copy it actually pulled and keeps it. From that moment the row is exact: the void and any second take-back touch that release and nothing else.
• A pointer that ages off the queue is pruned to a marker. It used to fall back to text and drop a waiting twin; gone from the queue means taken, which means running.
• A pointerless row that never gets taken back keeps the text rule. That path is now only for releases made before tokens, and it disappears as they age out.
• 193 checks to 218, proved three ways: the text void restored fails 2, the adoption dropped fails 5, the pruned-pointer refusal cut fails 2.

FIXA void took every taken-back copy of the command, so one answer ate a second release you had asked for.

• The void fired by command text, a habit from before releases carried tokens. Two identical commands, both taken back, are two things you asked for — one output answers one of them. The other's held copy was deleted, its row marked void, and it never ran.
• An output that names its release now voids only that release. The twin keeps its copy, keeps its turn, and takes its own output when it comes.
• An output with no token — an agent too old to echo one, or a row released before tokens existed — still voids by text. Nothing can tell those copies apart, and running twice is still the worse mistake.
• 189 checks to 193, proved three ways: the text void restored fails 5, the pointerless branch cut fails 2, the call not passing its token fails 5.

FIXA take-back could pull the copy next to its own, and a void could do the same — the token was only consulted first, then the text took over.

• Both paths tried the row's token and, when it found nothing, fell through to dropping the oldest copy of the same text. The token finding nothing almost always means the machine has taken that copy and is already running it — so the fallback pulled an identical release that was still waiting. That one then never ran, and when its own output eventually arrived it was reported as a second run.
• A row with a token now touches that copy and nothing else. If it is gone from the queue the take-back refuses, and the void records a double run it could not reach. Neither disturbs a twin.
• A row with no token — released before tokens existed — keeps the text fallback, because there is nothing better to go on.
• Eleven more checks, one hundred and seventy-nine total, proved four ways: restore the text fallback in the take-back and four fail, in the void and three do, drop the double-run mark and three do, cut the pointerless branch and six do.
• Proved over HTTP against the live machine: three identical releases, one taken by the machine, the next taken back and the last left waiting. The void pulled its own copy, the waiting twin was untouched, its row was not called a second run, and nothing ran twice. In the browser the offer rendered, the click put the command back in the box, no script errors.
• The four escape-sequence warnings on startup are gone; server.err is empty again.

FIXAn output carrying a token nobody knew still had its text guessed at — and a take-back pulled any copy of that text.

• The token only helped when it matched a row. When it did not — a command pushed from the console or issued by a job, or a release whose row had been dismissed — the server quietly fell through to matching by age and text, and that output could land in somebody else's receipt. A token now names a row or nothing.
• Take-back dropped the oldest copy of the command off the queue, not the copy its own row was released as. Two identical releases and it could pull the wrong one, leaving the one it meant to run. It pulls by token and refuses when that copy is gone.
• The offer of a take-back followed the same fault: a row whose own copy had been taken still showed queued on it, not run yet because a twin was waiting, and pressing it refused. The offer asks after the row's own copy now.
• An agent too old to echo a token still fills by order, but no longer blindly: a release the machine has not taken is passed over, because that copy cannot have answered.
• Seventeen more checks, one hundred and sixty-eight total, proved four ways: let an unknown token fall through and three fail, blind the queue test and five do, take back by text and one does, ask after the text instead of the copy and one does.
• Proved over HTTP against the live machine: an unknown token left the row waiting and its own token filled it, the offer vanished once its copy had gone, and a take-back with a twin copy waiting pulled its own and left the twin alone. On DESKTOP-6N3NABB the output came back carrying the release token and landed on its own row.

FEATUREAn output can now name the release that produced it.

• Every queued command carries a release token, handed to the machine with the command and echoed back with its output. The receipt is found by that token, not by guessing at age.
• Identical commands stop being indistinguishable: two rows, two tokens, and the outputs can come back in either order without one stealing the other's text. The third identical output finally has somewhere to land instead of being dropped.
• The same token answering twice is a double run on one release — the row is marked and keeps its first answer.
• A void now pulls its copy by token too. Dropping by command text could take a different identical copy off the queue and leave the one it meant; it cannot now.
• A voided copy that was successfully pulled never ran, so it no longer counts as evidence of a race. Only a copy that is running or has answered does.
• Twenty-one more checks, one hundred and forty-eight total, proved four ways: disable the token fill and five fail, disable the token pull and two do, loosen the race test and one does, return the queued text instead of the entry and it collapses.
• Proved over HTTP against the live machine: two identical copies released, popped, answered out of order — each landed on its own row, neither called a double run, then the first release answered again and the row read as a second run with the first answer kept. On the real machine the token came back in the output.
• Honest: an agent too old to echo the token still falls back to filling by order, which is the previous behaviour, so nothing breaks while a machine updates.

FIXA void could not recall a copy that was already running — and the row called it void anyway.

• The take-back voids the held copy by leaving it out of the box and pulling it back off the queue. If the copy had already been released a second time and the machine had popped it, the pull failed and the command ran — while the row still insisted the copy was void and swallowed the second output into a sentence that said it never happened.
• A pull that finds nothing waiting now marks the row d2: not waiting means already running. The row reads it ran once — this copy is running too until its output arrives, then it ran twice — the void could not reach it with the second output kept.
• The mark is carried to whichever row the later output fills, so the sentence survives the release path rather than only the direct one.
• Twelve more checks, one hundred and twenty-seven total, proved four ways: drop the running mark and one fails, skip the sibling search and one does, mark every filled row and one does, drop the running wording from the page and one does.
• Proved over HTTP and in the browser: two copies out, one popped, the second taken back and released again and popped, then both outputs — both rows ended up marked, the first run unmarked, the box empty and the queue clear.
• Honest: this reports the double run, it does not prevent it. An output still cannot say which release produced it; a third identical output has nowhere to land.

FIXA take-back that raced the machine could still run the command twice.

• If the machine popped the command in the instant before the fetch, the take-back still held a copy — and that copy ran later, after the first one had already answered. Two runs, one row.
• A hold now carries the receipt it was pulled from. When an output arrives for a command that was taken back, the copy is voided: pulled out of the box, and off the queue too if it had already been released again. The row says it ran first — the held copy is void.
• Voiding is keyed on the command, not the row. With the same command released twice there is no way to know which release produced an output, and the newer row takes the text — so every taken-back copy of that command is voided. One output, one run.
• One hundred and thirteen checks, proved by breaking it three ways: skip the void and eight fail, do not pull it off the queue and two do, hold without the receipt id and six do.
• Proved over HTTP and in the browser: the machine popped first, the take-back held the second copy, the output arrived — the row read it ran first, the box emptied, and the copy came off a queue it had already been released to.

FIXA take-back link died silently on any page but the one that owned the row.

• Receipts are kept against the cookie that released them. Two windows share that cookie, so the link worked there — a second browser, a different profile or the ops console got a redraw that looked identical and nothing else.
• A take-back now searches your own receipts first, then everyone else's. A foreign hit is pulled the same way and kept into the box of the page that pressed it, because that is the page that will release it again. The owner's row reads taken back by another page.
• A refusal was silent too. It now says which refusal it is — it ran, already back, gone from the queue, no such row — for six seconds, then fades.
• Ninety-seven checks, proved by breaking it three ways: stop the foreign search and five fail, drop the page marker and one does, blank the reason and three do.
• Proved over HTTP with two identities and a third stranger: a second profile took the row, the command landed in its box, the owner's row named it, the second press said already back, the stranger said no such row, and a re-release put the command back on the machine's queue.

FIXA command released to a machine that never took it was gone for the day.

• The receipt proved where a kept command went. If it went to a box that was asleep, the row just said "waiting for output" while the command sat in a queue for twenty-four hours — no way to tell stalled from slow, and no way to bring it home.
• A waiting row now says queued on it, not run yet and offers to take it back. That word comes from the queue itself, so it is never a guess: once the machine has popped the command the offer is gone.
• Taking one back puts it in the kept box again and stops waiting on it. It refuses if the output is already in, so nothing runs twice. A receipt row also now outlives the command it records instead of expiring eighteen hours early.
• Eighty-two checks, proved by breaking it three ways: skip the queue test on a take-back and two fail, never mark a row as queued and one does, drop the preference for the row that is still waiting and two do.
• Proved over HTTP and in a browser: released to an absent machine, offered back, pulled back into the box, released again to a live one, and the output landed on the new row with the taken-back row left empty.

FIXA kept command vanished the moment it was taken, and its output landed where nobody was looking.

• The hold made a future command visible before it ran. The instant a machine linked the box emptied — so the action was in the past with no trace of where it went, and the output arrived on a machine you were not watching.
• A release now writes a receipt: the command, the machine that took it, the time, and the output as it comes back. It reads back on load and on every tick, under the "kept" block, and each row can be dismissed.
• Kept and taken are one surface with one ordering: what has not run yet sits above what has.
• Fifty-two checks, proved by breaking it three ways: drop the receipt on release and twelve fail, fill the newest instead of the oldest and two do, remove the boot read and the id from the page and two do.
• Proved over HTTP and in a browser with a live machine: two kept, both taken, the host named on each, both outputs landing on their own row within one tick, one dismissed, both cleared, and the receipt surviving a restart.

FIXA kept command was invisible after a reload, and could only be dropped all at once.

• The hold built an hour ago outlives a reload on the server — and vanished from the page on one. Reload, and a command could still fire later on whatever linked, with nothing on screen to say it would.
• The page now reads the hold back on load and on every tick, as a quiet block under the log: each command shown, each with its own drop.
• Entries carry an id, so one can be revoked without losing the rest. Entries written before ids existed are given one as they are read, and it is written through.
• Fifty-two checks, proved by breaking it three ways: ignore the id on drop and four fail, drop the id-minting and two do, take the boot read out of the page and two do.
• Proved over HTTP with a real identity: two held, one dropped by id, the other left standing, then the rest cleared — and the empty box stayed empty on reload.

NEWA command with no machine to take it is now kept, and runs the moment one links.

• Last night made the command visible when nothing was bound to run it. It was still dead text — reload the page and it was gone. Unbound means no machine, not no intent.
• Such a command is held against your identity and released to the first machine that links, in order, through the same queue that already survives an agent being switched off. It says so under the answer, with one press to drop it.
• Held commands expire after six hours and cap at five, so yesterday's fix does not come back to haunt a machine today.
• It also catches the untagged case: ask for a command and one is often returned bare, with no marker at all. A single short line whose first word is a real shell verb counts; the word "Done" does not.
• Thirty-eight checks, proved by breaking it three ways, and proved end to end: asked with nothing attached, the answer was held, a machine linked, the command ran on it and the hold emptied.

FIXThe last file on a plain write was the one holding your conversation.

• Job transcripts were mirrored with no flush, no fsync and no generation behind them, and every error was swallowed. A cut mid-write left half a file, the reader gave up and the page was told the job was gone — the thread orphaned, and a full disk looked exactly the same.
• They now go through the same durable write as the balances: flushed, fsynced, and the previous generation kept. A damaged job falls back to it and says so out loud, and a save that fails prints instead of vanishing.
• The job directory had never been cleaned at all — 111 files and 800KB from one night, for records nobody reads after half an hour. Anything past a day goes on the next job.
• Thirty checks, and they bite: put the plain writer back and seven fail, drop the fallback and four do, keep the file-size copy that looks right and the second cut takes the transcript for good.
• Proved over HTTP: a truncated job now serves the generation before it with a 200 and the steps intact, where it used to answer gone.

FIXA power cut could have wiped the entire household board — every host, every device, the whole ledger.

• The observatory store was written with a bare dump and a swap: never flushed, no generation kept. A cut left it truncated, the loader caught the error and moved on with an empty board — and the loop saves every eight seconds, so the emptiness went over the file within one tick.
• It now flushes and fsyncs, keeps the generation it replaces, and refuses to keep a copy of a file that does not parse. A truncated store recovers the generation before it instead of opening blank. A failed save also says so now, instead of being swallowed.
• Twenty-five checks, proved by breaking it: drop the fallback and a cut loads empty, copy on size instead of on parse and the second cut takes the board for good.

FIXA power cut could hand a buyer their balance back as the free pack.

• The balance file was swapped atomically but never flushed, and the file being replaced was gone the instant the new one landed. A cut could leave it truncated, which read as empty — and an empty map is every identity re-created at 250,000 on the next message. A paid wallet, quietly restored to nothing.
• Every write now flushes and fsyncs before the swap, and keeps the generation it replaces as .prev. A broken file reads back as the last good one instead of nothing. Worst case is the single write that was in flight.
• Balances, orders and statements all take the same path. An unwritable statement still grants the tokens.
• Eighteen checks. Proved by breaking it: remove the fallback and two fail, stop copying the previous generation and twelve do.

FIXThe receipt was readable by anyone holding an invite link.

• An id was treated as a secret. It is not — every invite link carries one, so a stranger could read a buyer's whole statement from it.
• A statement now wants either the signed cookie or a read-only receipt tag, &k=, signed in its own domain so a receipt link can never be used as a login.
• A receipt link is offered on the top-up page to hand to a partner or an accountant. It reads, it cannot spend.
• The file was growing a set for every stranger who ever loaded the front page. It now holds the five hundred most recently written identities, evicting the coldest — history only, never a token.
• Proved by breaking it both ways: with the check removed six checks fail, with eviction stubbed three do. Forty-nine checks green.

Every token that moves leaves a line behind it.

• A balance was a number with no history. The free pack, a spend, a credited pack, a reversal, a friend joining, a friend paying — each writes time, signed amount, reason and the balance it left, inside the same lock as the balance itself.
• Your statement is on the top-up page, newest first, sixty lines. Nobody else's is.
• Writing the record can never fail the money: an unwritable file still grants the tokens.

FIXAn invite link was worth a million tokens a minute to anyone who could type a loop.

• A referral paid per identity, and an identity is only a cookie. Twenty curl -X POST calls to /api/bind with a reference and no cookie saved took 1,000,000 off one link in under a second — measured, not guessed.
• A referral now pays once per arriving address, once a day. The same fence the free pack already used, for the same reason.
• The friend is still bound to whoever invited them when it does not pay; the count shows what paid and what is waiting on a new address, rather than one number that flatters.
• The bonus was 50,000 in the copy while the code paid 1,000,000, and there is a second 5,000,000 due when a referred friend actually buys a pack. Both figures are now filled from the server like the price, so the copy cannot drift again.
• Fifty-five checks, and both directions proved by breaking it: stub the fence off and six fail, stick it on and nine do.

FIXThe price was three different numbers. Now it is one.

• The brief said $3 for 500,000. The code granted 1,000,000. The top-up page said both — 1,000,000 in the price block, "ANOTHER 500,000" on the button you get after buying. The brief wins: $3 for 500,000.
• The figures are no longer typed into the pages. The server holds one number and the price block, the button, the free-pack line and the message after a purchase are filled from it, so copy cannot drift from the grant again.
• A bad number in the environment falls back to the real one instead of selling a zero-token pack.
• The landing page claimed 250,000 tokens was "roughly five hundred messages". It is about a hundred.
• Twenty-seven checks guard it: the environment figure, the API, the wallet delta against a real settled order, and a scan of the three customer pages that fails on any token number the server will not honour. Proved by restoring the old code — it fails four.
• Two older suites had the pack size typed into them; both now read it from the server rather than asserting yesterday's price.

NEWThe morning list now hands you the page.

• Every item on it carries a "fix" link straight to the surface that settles it — the dark machines to the sites list, unconfirmed packs to the queue, incidents to the board.
• A list that only describes a fault makes you go looking. This one does not.

FIXAn expired reference is examined again, honestly.

• The probe that proves an old reference is refused carried a frozen fixture, and the fixture went stale — the order in it had already been claimed, so the probe had nothing left to bite. It now mints its own order, backdates it past the two-hour life, and checks the refusal — with a live order claimed in the same run as the control.
• Start-up now takes a lock file before it asks the port. Two launches a millisecond apart both used to hear silence and both bind — one listening, one blind. A lock left by a crash is stolen only after its owner is confirmed dead.
• That needed a fix underneath it: a hand edit to orders.json was invisible until the next restart. The file is the record, memory is only its cache — it now reloads when the file has moved, and replaces rather than merges, so a row deleted outside stays gone.

NEWA morning brief at /morning.

• One page, generated: what was built overnight, what is still weak, and — the part that matters — the short list of things only you can do. Taken from the log and from the box, so it cannot claim something that stopped being true.
• Nothing in it is hand-written. The built list and the weakness list are lifted straight out of the night log's own headings and honesty lines, which is why they agree with it.
• Each entry opens to the run's detail. A healthy box says go back to bed.

NEWLead Cleaver can be tried before it is downloaded.

• The bulk list cleaner now has a page you can paste into: the same rules as the binary, run in the page, nothing uploaded. It prints exactly what the program prints — proved identical, byte for byte, on the same fixture.
• A foreign number is now refused instead of being sliced to ten digits. A +44 landline used to come back wearing area code 442, which owns nothing.
• Download count on the page, one per address per hour.

NEWThe pack no longer waits for someone to wake up.

• Pressing "I have sent it" credits the pack at once instead of holding it until the money is checked by hand. The credit is marked unconfirmed on the page and in the operator's queue.
• Confirmed against the transfer within a day, or taken back. If part of the pack is already spent, the reversal takes what is left and leaves the balance at zero rather than negative, and says how much went.
• Takings only count on a confirmation. An unconfirmed pack is not money yet.
• An order left unconfirmed for a day confirms itself, so a shop nobody is watching still closes its books.
• Reading the balance without a cookie now issues an identity. Before, a script read one wallet and was charged in another.
• Thirty-eight checks guard the provisional path; eighteen more race it.

NEWTwo doors on this server were unlocked, and both cost money.

• A page on another site could post to any of the console and the browser handed over the operator's credentials for it. State changes now have to declare where they came from; a foreign origin gets a refusal.
• The free 500,000 was once per identity, and an identity is only a cookie — delete it and take another. It is now one per address per day as well. Deleting cookies no longer resets it; the shop owner is exempt so it can be tested.
• Password comparison no longer stops at the first wrong character.
• Forty-one checks guard these. The free button says which rule applies before it is pressed.

NEWThe front door stops sounding like a script.

• Methods the site does not use are refused properly instead of answering "not implemented", and browsers can preflight the API again.
• Missing pages are a real page in one consistent shape, not two bytes of text.
• A body over 12MB is refused with the right error instead of being read into memory, and odd `//` or `/../` paths resolve the way they should.
• Fifty-nine checks now guard all of it.

NEWThe pay link names who it pays.

• Top-up now says the payee and the currency under the price, resolved from the link itself and rechecked hourly. A dead tag is called out rather than sending money into nothing.
• The payment link carries the exact amount, so nobody types it and nobody under-sends.

FOUNDThe price and the account disagree. The pack is priced in dollars; the pay link settles in AUD, so a $3 pack became A$3 — about $2.81 net. The link now asks the conversion (A$4) and both the shop and the operator board say so in plain numbers instead of pretending.

NEWA front door.

• The bare domain used to open on an arcade. It opens on the product now: what this is, what it does, what it costs, and where the edges are — before it asks you for anything.
• The arcade is still here, one click down at /games.

FIXAn invite link could come out empty. The invite endpoint handed back a blank code to any caller that arrived without a cookie, so the copied link pointed at nothing. It mints an identity now, and the same is true of the bind call a friend's page makes on arrival — which is also what credits you.

NEWTokens are sold now, not given.

• The $3 button opens an order with a short reference. Put the reference in the note, press "I have sent it", and the pack is credited once the transfer is marked paid.
• The reference is honoured for two hours. Nothing is credited before the money is seen, and a second press on a settled order credits nothing.
• The order survives a reload, so a closed tab is not a lost receipt.

FIXThe shop was behind the operator's password. On the public host, only the chat and the games were open — top-up, changelog and LeadCleaver demanded a login a customer never had. All three are open now; the console is not.

NEWThis page, and a top-up page that explains itself.

• First run now says what the thing does before it asks you to type.
• Top-up states the price, the quantity of tokens, what they buy, and the free routes, before a button.
• The exhausted-tokens banner links to the page instead of crediting silently.

FIXA print could kill a request.

Uploads returned an empty reply now and then because a failed write to the log pipe raised out of the handler before the record was saved. Both streams are wrapped; a log write can no longer take a request down with it.

FIXRestarts had been quietly failing. The old process kept serving, so patches sat on disk unloaded. Restarts are checked against the listening socket now.

NEWThe board. A watchtower over the network: names asked, by which device, proven or merely cached, folded back onto the site they belong to. A house roster sorted by anonymity. A page that grades how much of its own evidence is real.

NEWInvites. Every identity carries a code. A friend arriving on it credits the referrer and shows the count.

FIXFleet liveness read as dead. Screenshots are off by default now, so nothing was arriving to prove a machine alive. The poll is the heartbeat.

NEWFirst light. A chat that reaches a Windows machine and runs what you ask. The shell is the product; the console is how you watch it happen.