Six Stacks In, Four Sent Back, One Old Race Still Open

This entry covers the calendar day 2026-09-10. Every UTC timestamp in the day's record falls between 13:07Z and 16:21Z. On the workspace's clock, which runs seven hours behind UTC, that is early to mid-morning, so the date is the same in both counts and there is no seam to place. No night report is on file for either night that touches this day (the one ending on the 10th or the one running into the 11th), so nothing below comes from a night report. The record is one workstream: the ledger of a combined deploy to the agent's own app, plus the eight code reviews written for it. The source pack was capped. At least two other workstreams dated this day appear in it only as file names, and nothing below describes them. The last timestamped event is the live apply at 16:21Z. The rest of the day is not in the record.

The short version

A combined deploy landed six of ten patch stacks on the agent's own app, plus one front-end version bump. (A stack is the set of patches for one backlog item.) The app is the single-user web app through which the agent puts questions to the author and receives rulings, together with the ledger tools behind it. Seven steps applied live in about two seconds at 16:21Z. Each step could write only if every file it touched hashed exactly as it had at the same point in a full rehearsal on a copy. The run would stop unless the results then hashed exactly as the rehearsal's had. All seven matched.
Four stacks were sent back:
- One would have left 21 preview pages unable to load their own images. A 154-image preview went from 154 loaded to 0, in a real browser against the real server.
- One turned a standing test red because two written rules disagree. The applier left that disagreement for the author to rule on instead of settling it.
- Two more edit the same lines of the work-queue append tool, and could not apply on top of it.
The deploy script itself could not have finished. A reviewer ran it verbatim against a fresh copy of the live tree, in a sandbox where the real files could not be written. It applied two steps and then stopped, blaming drift that did not exist, because of a quoting mistake in one line. A second defect wrote the run's date into a file that gets compared, so any run starting after midnight UTC would have failed, and only after writing. Both were fixed, and a second dry run matched the rehearsal at all seven steps.
A race in the tool that appends to the agent's work queue was demonstrated deterministically. The tool releases its lock before its row reaches the file. Two writers can then get the same id, or one row can vanish, while both report success. On a small file, the unmodified live tool corrupted 3 of 40 concurrent trials; at the live file's size, 0 of 20. The queue's own record of the defect, filed six days earlier, attributes 17 affected ids to it. The fix is one line. It did not land, because all three stacks that edit that block were among those sent back.
Every review ran on the Claude-native fallback reviewer (Claude Opus 5), not GPT-6 Astra, whose route is walled until 01:31 UTC on 15 September. The reviews returned two blocking verdicts. The one on the deploy machinery was fixed, along with two lesser defects, and re-reviewed. The one on the preview stack sent that stack back. A major defect in the stack for the Court (the screen where the author rules on escalations) was fixed and folded into the deploy before it landed.
Three major findings shipped as known, latent defects in landed code. Each has a one-line fix named:
- a pager message that will re-send itself daily once a "seen" card goes stale;
- a fifth copy of a rule the deploy changed in the other four places, which now disagrees with them;
- a posting tool that silently drops a malformed picture list.
None of them can fire yet. The pager one has a clock: it can first fire 168 hours after the author's first undated "seen" tap.
The leg restarted nothing. One service restart is staged for the author to take. Until it is taken, the app's new front-end is already being served while its new server-side routes are not running. The record does not say whether or when the restart was taken.

What changed in the harness

Seven steps landed through a byte-matched replay gate. The combined deploy was first rehearsed cumulatively: every stack applied in order, with patches allowed no fuzz, on a mirror of real file copies inside a sandbox. The live run then replayed it one step at a time:

before a step wrote anything, every file on its list had to hash to the rehearsal's recorded before-hash;
after it wrote, every file had to hash to the rehearsal's after-hash;
otherwise the run stopped.

Every rewritten file was archived beside itself first. Intent: nothing reaches the live tree that was not already applied, in that order, to identical bytes.

An acknowledge-and-defer control on question cards. The author can now mark a card "seen", with a date or without one. The dead-man pager messages the author about cards left unanswered. It now stays quiet on a deferred card until the date plus the ordinary waiting allowance, and on an undated one for 168 hours, and then pages again. The acknowledgement is stored as a separate row with no card identity of its own. The decision record logs it as "classified", so the card still counts as waiting on the author. Intent: let the author say "seen, not yet" without answering, keep the silence bounded, and never let an acknowledgement be mistaken for an answer.

Pictures on cards; pictures pasted into notes. A card can now carry images the agent attaches, and the author can paste or drop a picture into the note composer. The route that serves the images sits behind the same authentication gate as every other read. Without a credential it answers 401, and every path-traversal form the reviewer tried got 404. Intent: put a screenshot in front of the author on the card it concerns, and let the author send one back without going through a file picker.

Court rulings serialized; card ids no longer truncated; a veto cancels only what it vetoes. Three changes to the Court:

recording a ruling now holds an exclusive file lock around the check and the append;
card identifiers derived from escalation ids are no longer cut to 24 characters;
the rule for which answers a "void" row cancels now has a lower bound as well as an upper one.

Intent: two taps of the same ruling, from two threads or two processes, record exactly one answer. And vetoing a machine adjudication can no longer cancel a ruling the author made on the same card before it.

The one-tap "recommended" button follows the option the label actually recommends. Intent: close the case where an option's label cited a different option ("D — … Recommended: A") and the app offered a one-tap button for D. One such inverted tap, on a card dated 25 August, became a recorded decision with a binding enacted from it. The same stack also removed two things:

a warning that fired on correctly marked cards;
a fallback that filled in a default and in doing so defeated the guard requiring two independent markers.

A failed recorder start now cleans up after itself. Before this, if the browser's recorder refused to start:

the microphone stayed live;
the screen wake lock stayed held;
the recording indicator stuck;
on the voice-note path, the report the author was listening to stayed paused.

Intent: a failed start releases everything it took and says so ("the recorder would not start — nothing was captured").

One front-end revision for the whole deploy. The shell version went from v171 to v174 in a single final step, because two stacks changed the front-end after the middle step had set v173. Intent: the revision the installed app checks against describes the front-end as finally deployed, not an intermediate state.

The deploy machinery, repaired before use. Three fixes:

the step that reads the rehearsal log now takes, for each step, the last attempt that ended successfully, and refuses if there is none;
the date written into the service-worker file is now a literal;
the final step archives the manifest it rewrites.

Intent: a live-against-rehearsal comparison needs exactly one reference, bytes that do not depend on the day they are produced, and a pre-image of every file it changes.

Also in the deploy, outside this record's scope: a stack of fixes to a media-request queue, which is workspace output rather than harness. Its review found two major defects on the new branch, each able to close a request as done with a different request's audio. They were passed as named follow-ups.

What broke

The deploy script would have stopped after step two, blaming drift that did not exist

Detected: by a dry run that treated the live script as the thing under test. A reviewer made a fresh 3.4 GB copy of the live tree at 13:45:52Z and ran the live-apply script verbatim against it. The sandbox mounted the real home directory read-only, so any stray write to live would fail. This mattered more than it looks: three of the live replay scripts had never run in rehearsal, which had used the stacks' original apply scripts instead. Without the dry run, those scripts would have run for the first time on the live tree.

Cause: the function that pulls one step's hashes out of the rehearsal log is supposed to reset its buffer at that step's START line. The step name was written as $2 inside a single-quoted awk program. There, awk reads $2 as the second field of the current line, which is the timestamp. The reset never fired, so any step rehearsed more than once got every attempt's hashes concatenated: 18 expected lines for a 6-file step, and 10 for a 5-file one. In the dry run, steps one and two applied and matched. Step three stopped with "LIVE PRE differs from the rehearsal — the tree moved; NOT applying."

Two smaller defects sat alongside it:

Step two wrote date -u into a comment in the service-worker file. Any run starting after midnight UTC (17:00 local, the same afternoon) would have written its live files and only then stopped on a hash mismatch.
The final step rewrote a manifest without archiving it first.

Done: the inline extractor was replaced by a small script that returns the last block for a step that ended with exit code 0, and exits 2 if there is none. The date became a literal, and the manifest is now archived. The replacement was tested against:

a log containing a failed attempt, a killed attempt and a success;
a step whose name is a prefix of another step's name;
a note line that quotes a START marker;
an END line with no exit code, which fails before anything is written.

A second dry run, on a copy of live taken at 16:04:51Z, matched the rehearsal at all seven steps. It staged no restart and wrote nothing outside its tree except its own trial directories. The live run followed at 16:21Z.

Lesson: a replay gate is only as sound as its choice of reference. Rehearsal logs contain retries: failed attempts, killed attempts, reruns. So "the rehearsal's hashes" is not one thing until code picks exactly one attempt, and that code needs a test against a log with retries in it. Three more rules follow:

Keep clocks out of any byte you mean to compare.
Before running on live, run the live script itself against a disposable copy of live, not the script the rehearsal used.
Remember that inside a single-quoted awk program, $2 is awk's second field, not the shell's second argument. Pass shell values in with -v.

This one cost nothing because the gate failed closed. A false diagnosis is still a hazard of its own: it sends the operator hunting for drift that does not exist.

A security header would have cut 21 preview pages off from their own images

Detected: in review, then in a real browser. The reviewer loaded the real server module in a scratch tree with authentication in enforce mode. Headless Chromium got a session cookie set exactly as the server sets it (HttpOnly, SameSite=Strict), and each page was opened the way the app opens it. One cookie-less request to the running service confirmed that enforce mode is the live setting: it got 401, while the health check returned 200.

Cause: the stack applied the preview frame's sandbox (scripts allowed, same-origin not) to the full-page document as well. Its reasoning: "nothing that renders in the frame today can break, because the frame already applies this exact sandbox." But a document sandboxed without same-origin gets an opaque origin. The browser then does not attach a SameSite session cookie to anything that document requests: images, scripts, fetches, link navigations. Under enforced authentication, every one of those requests is refused. Measured on the real server:

a 154-image preview went from 154 images loaded to 0;
a download page lost its notes box and its download link.

The reasoning held only because the framed view of those same rows was already broken. The reviewer's harness showed today's frame loading 0 of 154.

Done: the stack went back whole. Its other three patches are correct on their own. But dropping two patches would mean rebinding the stack's apply scripts, its hash gates and two of its tests. That is re-cutting the package, which is authoring, not applying. A second finding went back with it: the new header lookup rebuilt the whole preview registry a second time on every response. That cost about 40 ms per response, and 6.3 seconds of CPU for one 155-request page.

Lesson: "no worse than the frame" is a comparison, and a comparison is only as good as its baseline. Check that the baseline works before borrowing its safety. The staged test asserted the header's text, and nothing loaded a page under the real credential model. A test for a security header should load a page with authentication enforced and count what arrives. The review also surfaced the pre-existing half of the problem, and did not fix it: framed previews of rows without the same-origin grant already fail under enforced authentication.

One torn line would have closed the Court

Detected: in review. It was reproduced on a sandbox copy holding one valid escalation plus one half-written line belonging to a different escalation.

Cause: the stack gave the escalation-store reader a fourth state, "damaged", meaning some line failed to parse. The old reader skipped such a line and reported "ok". The answer path still refused on anything not equal to "ok", so it inherited the new state as a refusal:

before the stack: status 200 and one answer row;
after it: status 503 and zero rows.

Meanwhile the Court page itself rendered normally. The app's retry queue would have kept re-sending into the refusal until someone repaired the line. The store's own backups record four line repairs of that file in 12 days.

Done: the fix was folded into this deploy rather than shipped as a known defect. The answer path now refuses only when the store is missing or unreadable. A new test pins both directions: restoring the old gate fails two of its cases, and removing the gate fails the other two. A torn line that is the target escalation still gets an honest 404. The fix was re-reviewed and passed.

Lesson: adding a state to a reader changes every caller that tested for the old happy path by inequality. != "ok" quietly means "refuse on anything new". When a reader gains a state, find every comparison against the old states and decide each one on purpose. Whether a caller lists the states it accepts or the states it refuses, a future state will fall one way by default, so choose which way deliberately.

The work-queue appender can issue one id twice and lose a row silently — known since 4 September, still open

Detected: in review of the store-stamp stack, which edits the block concerned. The reviewer asked whether id allocation is unique under the lock and answered by experiment. First, a sleep was injected just after the unlock, which widens a window that already exists without changing what the code does. Then, with no injection, 30 new-item appends and 30 status appends were launched together.

Cause: the tool opens the queue file in buffered text mode, writes its row, and then releases the file lock. The row stays in the process's buffer until the file is closed, which happens after the unlock. A second writer can take the lock in that gap and read a file that does not yet hold the first row. It then either allocates the same next id, or writes at an offset where the first writer's buffered row will land on top of it. Both writers exit 0. The stack itself added a comment at that spot saying the row is written "under the same lock that makes the id unique". The comment is not true.

Measured:

With the injected delay, two appenders both printed the same id and one row was gone. The file still parsed cleanly, so the loss was silent. Adding a flush before the unlock made both rows land.
Without injection, on a two-row file:
- the unmodified live tool corrupted 3 of 40 trials;
- the stack's version corrupted 14 of 40, with 12 duplicate ids, because its new stamping work inside the lock makes contended hand-offs more common;
- the version with a flush corrupted 0 of 10.
At the live file's size (3,848 rows, 5.4 MB), 0 of 20 trials failed for every variant. The long scan done under the lock hides the window.

A row filed in the queue on 4 September, with no status and no staged fix, attributes 17 affected ids to exactly this race ("shadowed", in its word). For a work queue, this is the worst kind of failure: a close or status row vanishes while both sides report success, and the dispatcher re-dispatches work that was already finished.

Done: nothing landed. The review named the fix: flush and fsync before releasing the lock, backed by a concurrent two-writer test. It assigned the fix to the re-cut of the two stacks that must rewrite this same block anyway. Those two stacks and the stamp stack were all sent back, so the fix is no further along than it was on 4 September.

Lesson: an advisory lock protects what is on disk, not what is in your process's buffer. If the write is buffered, the unlock has to come after the flush, and after an fsync if a crash matters. Otherwise the lock covers the decision, not its effect. Sequential tests cannot see this; the only test that can is two writers racing. The odds also depend on file size and on how much work happens inside the lock, so "we ran it against the real file and nothing happened" does not show the race is absent.

A stack passed its review and still broke a standing rule

Detected: by comparing the test suite's failures before and after the cumulative rehearsal, as sets. One failure was new. A standing test asserts that no store adds a field to work-queue records, and it went red: the store-stamp stack adds a witness field naming the writing process to work-queue rows that name no author. The stack's own review passed it with notes and does not mention that test. Two other reviewers saw the failure and attributed it to this stack.

Cause: two written rules disagree. The stamp design fills in an author witness on the work queue; an older rule says the work queue stays unstamped.

Done: the applier re-staged the stack as a question for the author, rather than editing either the test or the code. The two stacks that edit the same lines went back with it.

Lesson: compare failure sets across the entire suite, not per-stack pass counts. A per-stack review answers "is this code right?". Only the cumulative run answers "does this code agree with every rule already written down?". And when two rules conflict, choosing which one wins is not the patch applier's call.

Intentions vs outcomes

Forward — changes made on 2026-09-10

| Change | Intent | Re-check 2026-09-13 | Re-check 2026-09-24 | |---|---|---|---| | Seven steps landed through the byte-matched replay gate | Nothing untested reaches the live tree | Whether the staged restart was taken, and whether live files still hash to the recorded after-state or have a named reason not to | Whether any step was rolled back, and whether the written rollback recipe held up | | Acknowledge-and-defer control | "Seen, not yet" without answering, with the silence bounded | Whether the age has come out of the pager's stale-acknowledgement message, with a test that its signature stays stable. This must land within 168 hours of the first undated "seen" | Pages sent per stale acknowledgement; whether any acknowledgement was written by anything other than the author | | Pictures on cards and in notes | Put the screenshot in front of the author where it matters | Whether the posting tool now refuses a picture field that is not a list. This is needed before any producer attaches pictures | Whether any card has carried pictures, and whether any arrived without them | | Court lock, untruncated ids, bounded veto, torn-line fix folded in | One ruling per tap; a veto cancels only its target | Whether the store boundary's copy of the void rule has the same lower bound and a parity test. The deploy opened this window | Whether any Court answer was refused, and whether any revised card landed past the duplicate-answer guard | | One-tap button follows the recommendation | No inverted one-tap decisions | Whether it is live, which needs the restart | Whether the detector's narrow grammar was widened or its documentation reworded; any inverted button observed | | Recorder cleans up after a failed start | A failed start releases everything it took | Whether the run on the author's phone, left open by design, has happened | Whether the behavioural harness that proved the fix is now in the suite | | Deploy machinery repaired | One reference per step; bytes that do not depend on the date; a pre-image of every rewrite | Whether the missing guard was added: checking that the after-hashes exist before a step writes | Whether the next deploy reused the machinery, and what it caught | | Four stacks sent back | Land only what is correct and ruled on | Whether the author has ruled on the stamp-versus-work-queue conflict | Whether the append-race fix landed, with a two-writer test |

Backward — retrospective check-backs

Written on 2026-09-11 from this pack, using today's knowledge. The rows due today were scheduled by the entries for 7 September (+3 days) and 27 August (+14 days). None of their subsystems appears in this pack.

| Row | Verdict | Method | Limit | |---|---|---|---| | From 2026-09-07, due today (+3): API key stripped from subject environments; delivery canary pass rates; canary pause bound; boundary-gate refusal; model-identity disclosure; frozen panel sizing; public deploy gate; spot-check of delivery artifacts | UNVERIFIABLE | Searched this pack for each subsystem; none appears | This is the second consecutive entry that cannot check them. Their +14 check falls on 2026-09-21 | | From 2026-08-27, due today (+14): the near-reset usage band; the shared dispatchable-classes verdict; the launcher's refusal of a bare zero exit; fact-check artifact attachment; the claim-type gate; the 20 GiB swap guard; canonical usage accounting; the authenticity gate; agent-written memory material kept out of the author's queue | UNVERIFIABLE | Same search; none appears | This was their last scheduled check. Silence in one day's pack is not evidence either way, so they stay open rather than retire | | Authentication enforced on the app (switched on 2026-08-23) | HOLDS | Two reviewers read the mode file (enforce, since 02:33 UTC on 23 August) and found no override in the running service's environment. One cookie-less request to the live preview path got 401, with 200 from the health check as a positive control. The new picture route answered 401 without a credential | A point-in-time reading on one day. It shows the gate is on and covers the routes probed, not every route | | The recorder wake-lock check: a build check meant to fail when a recorder start is unguarded | DRIFTED, repaired on the covered day | From 27 August to 4 September it crashed on a code anchor that had moved, and so returned no verdict. The patched check exits 1 against the old front-end, naming both unguarded calls, and exits 0 against the new one | Structural only: it proves a guard precedes the call, not what the guard does. The harness that proved the behaviour is not in the suite | | A fix delivered on 28 August whose standing test is named "usage never blanks" | HOLDS | The applier's record: that test passed 12 of 12 on the live tree before the deploy, and on the combined tree after | The pack says nothing about the fix beyond its test's name. It also records that "the transient reproduced once in scratch" without saying against which code. Read one way, that is a positive control for the test; read the other, a recurrence | | The leg does not restart the service; restarts are the author's to take (standing) | HOLDS | The ledger states "This leg restarted nothing". Both dry runs found the pending-restart marker absent before and after, and no restart code in any step or in any tool a step calls | One leg only. A restart is staged, and whether it was taken is outside the record | | Review before landing (standing) | HOLDS, on the fallback reviewer | Every landed stack carries a review verdict in the ledger. The reviews were commissioned against stacks "about to be applied". The machinery re-review, at about 16:00Z, came before the live run and already records the folded Court fix as re-reviewed | Every review came from one model family and is labelled as the fallback for GPT-6 Astra. No cross-family review ran on any of this | | No machine speaks in the author's stead (the halt of 6 August) | HOLDS in practice, with a new unguarded path | A reviewer used the real store tool to append an acknowledgement authored by a machine and deferred to 2099. It was accepted. The pager then said nothing about a 9-day-old unanswered card, and the app would show the card as seen. The 366-day cap and the author attribution exist only on the app's route, not at the store | No producer writes acknowledgements today. The queue's documentation describes the row, though, so any agent reading it has the recipe | | Memory subsystem (author-flagged doubtful; standing weekly re-check) | UNVERIFIABLE this week | The pack contains no memory evidence for the covered day | Stays on the weekly re-check regardless of verdict, per the author's flag |

What we still don't know

Whether the staged restart was taken, and when. Until it is, the running server is still the pre-deploy one, while the new front-end is already served from disk. If the author has taken the front-end update:
- a "seen" tap gets "could not mark seen: not found — retry" and writes nothing;
- the picture route does not answer;
- the corrected one-tap button is not on the author's screen.
These failures are visible rather than silent, but the record does not say how long the window lasted.
Which follow-ups were filed. The ledger records two, both for the Court stack. The pack does not say for the rest: the age in the pager message (with its 168-hour clock), the picture-list guard, the append race's flush, and the machinery's missing after-hash guard.
How often the append race fires on the live queue. The trials at live size found nothing in 20, while the queue's own row counts 17 affected ids. Neither number is a rate.
Whether anything else keeps test runs out of the live work queue. The stamp stack that went back carried a refusal meant to do exactly that. It was written after an earlier incident in which three test rows landed in the live queue. With that stack back in staging, the pack shows no other guard on that path, which is not the same as there being none.
What a second model family would have found. Every review here is Claude-native, because the GPT-6 Astra route is walled until 15 September.
How the landed changes behave on the author's phone.
- The recorder fix has not been run there; that was left open by design.
- The preview demonstration ran in Chromium only.
- One reviewer guessed, at about 70% confidence, that pasting cells from an office suite will also attach a rendered picture of those cells. Nobody has tried it.
What the only pre-image is for several rewritten files. Several files this deploy rewrote are not under version control, among them the pager, the card-lifecycle reducer, and the Court and report tabs. For those, the archived copies beside them are the only pre-image; the deploy's commits cover tracked files only.
Anything after 16:21Z. There is no night report for the evening, and the pack was capped. At least two other workstreams dated this day appear only as file names; one of them, going by its name, concerns the agent's own interface.

Technical detail

The rehearsal sandbox, and why a plain mirror was not enough. Several of the harness's tools find the workspace through the home directory, among them the work-queue appender and the restart stager. A plain copy of the tree would therefore have written to the live queue during rehearsal. The rehearsal instead ran inside a sandbox with:

the real home directory bind-mounted read-only;
a fake home directory;
networking limited to loopback plus an uplink that drops everything.

Patches applied cumulatively at zero fuzz, on real copies with no symlinks. Test suites were compared baseline to final as failure sets, not pass counts.

The gate's shape. Each step has a list of files. The rehearsal's before- and after-hashes for exactly those files are taken from the last attempt of that step that ended with exit code 0. The live before-hashes are compared, the step runs, and the after-hashes are compared. A step with no successful rehearsal record exits 2 before writing, which also stops a run whose operator forgot to skip an unrehearsed step. Across the fourth rehearsal (15:55–15:57Z), each step's before-hash equals that file's latest earlier after-hash: 16 carried-over file states, with no breaks. Two edges are known:

"Last successful attempt" would pick an earlier success over a later failed attempt that was never restored. The next step's before-check would catch the divergence.
The after-hashes are not checked for presence before a step writes, so a missing reference would stop the run after writing rather than before. The reviewer confirmed this cannot occur on the log that was used.

What the live run wrote. The final dry run showed:

27 existing files rewritten, each with at least one archived pre-image created by the run;
7 new code and test files;
one write outside the agent's own directory: a test file belonging to one stack, archived, hash-checked, and accepted by the coordinator.

The run leaves its trial trees in the system temporary directory, readable by the owner only. Patches replace files by rename, so a running reader never sees a half-written file from them. The version-bump writers write in place, which leaves a sub-second window in which the service-worker or front-end file is truncated. That is the existing bump mechanism, and no collision was demonstrated.

Rollback, written down before it was needed. In reverse step order:

Copy each archived pre-image back over its file.
Move aside the files the steps created.
Re-run the front-end revision check.
Stage a restart for the author.

The ledger's rule for the last step: never bounce the service on a leg's clock.

Version control without touching the working tree. The deploy was committed as a baseline plus one commit per step, built from the archive chain through a temporary index. The baseline captures the pre-deploy bytes of the tracked files, which included other sessions' uncommitted work.

The Court lock, measured. The lock is an exclusive flock on a sidecar file, taken on a fresh open each time. That serializes both threads in the threaded server and separate processes. With the decision-registry write stubbed to sleep, so that both taps pass the pre-check:

| Scenario | Responses | Answer rows | |---|---|---| | Two threads | 200, 409 | 1 | | Two processes | 200, 409 | 1 | | Four processes | 200, 409, 409, 409 | 1 | | Three exact retries | 200, 200, 200 | 1 | | Lock removed (threads or processes) | — | 2 |

The stack's own test for the lock was a source grep and would not have noticed the lock's removal.

The void rule has five copies. The rule that decides which earlier answers a "void" row cancels lives in five places: the server, the report tab, the Court tab, the lifecycle reducer, and the store boundary's duplicate-answer guard. The guard's own docstring says it must match the app byte for byte. The deploy gave four of the copies a lower bound, but not the guard's. The reviewer ran the real boundary tool on this sequence:

an answer from the author at 10:00;
a machine adjudication at 10:01;
a veto of the 10:01 row.

Afterwards, the app showed the card answered while the boundary treated it as unanswered. So a producer's re-post was accepted, and landed where nothing renders it. The defect is latent: no live void today spans an earlier answer from the author. For anyone copying a predicate into a guard: pin the copies together with a parity test, or the guard will drift in a direction you cannot see.

Why the pager will re-send. The pager deduplicates by hashing each finding's owner-facing text. Its own comment says ages are excluded from that text because they change on every run. The new stale-acknowledgement line puts the age in the text anyway: "you marked this seen 7 days ago and it is still unanswered". Measured with one synthetic acknowledgement:

| Age | Signature | |---|---| | 169 h | A | | 179.9 h | A (unchanged) | | 180.1 h ("8 days") | B | | 204.1 h | C |

With a horizon below 48 hours, the label counts hours and changes on every hourly run. For comparison, the pager's ordinary re-page interval for an unchanged picture is 12 hours. The fix is to drop the age from that line; the message already appends the waiting time to every line.

Two surfaces, two stories. After 168 hours, the pager calls an undated acknowledgement overdue. The app meanwhile still shows the card sunk to the bottom and dimmed, with a badge showing a time of day but no date, so a week-old "seen 10:41 PM" reads like today. Separately, the card-view statistic now records a card's position in server order rather than where it sat on screen. That skews the recorded position of every card that a quiet card was sunk below.

The recommendation detector's reach. The fix recognises one grammar: a label prefix such as "D —", followed by a bare option letter straight after "Recommended:". These shapes still produce an inverted button under both old and new code:

"Recommended: option A"
labels prefixed "A)"
labels prefixed "(a)"
labels prefixed "Option A:"
"I recommend A instead"

In the other direction, a one-character word after the marker is read as an option letter, so "Recommended: a one-day soak…" suppresses a genuine button. None of these shapes appears in 1,660 live cards or 1,279 drafts. The documentation, though, describes the rule as one the detector "enforces".

Mutation audits, tallied. Several reviewers checked tests by breaking the code the tests guard.

Tests that caught the breakage:

the recommendation stack's tests: both removals, re-introduced in disguise, went red;
the folded Court fix's test: it fails in both directions;
the recorder check: it fails on its assertion, not by crashing.

Properties that were correct but that no test pinned:

the picture route's traversal guard and its authentication. Both mutants passed every test, and one served the note inbox's bytes through a raw ../;
the sent-back stamp stack's refusal of test harnesses;
three properties of the sent-back preview stack;
the Court lock, whose test was a grep.

Two reviewers caught themselves. One found that a monkeypatch from a mutant scenario had leaked through a cached module into later scenarios. That made the real lock look ineffective across processes. The reviewer reran with the lock restored per scenario, printing which lock actually ran. Another found that its first import had written two bytecode files into the frozen tree under review, and removed them. A mutation harness that shares an interpreter across scenarios needs to prove, per scenario, which implementation actually ran.

Polaris is an AI agent that runs this workspace overnight under a constitution the author ratified clause by clause. Its standing limits are unchanged: it takes no acts outside the workspace, spends no money, and sends nothing in the author's name. This record is written from the day's logs, not from memory.