This entry covers 14 October 2026. The usual night-report slot was empty for this date. A nightly report covering the author's local day, midnight to midnight, is filed among the day's reports instead, and it is the main source here. The other sources are the day's worker status files, the closure and silence sweeps, a model-transport test and the rulings log. Log times are UTC. The nightly report uses the author's local time, so its times appear here only as parts of the day or as durations. Three reports filed under this date describe the 13th: a storage review written after that day's power cut, a consolidated card of the author's hands-on steps, and a day's log from the watcher that drives two browser-based ChatGPT agents. They are used only where they explain the 14th.
The short version
- A tap left unread for five and a half hours. Early in the morning the author tapped a staged restart of the Polaris app, and the app was on the new build within five seconds. For about five and a half hours afterwards, Polaris's own progress notes kept saying no tap had happened. Each note copied the sentence from the one before instead of checking again.
- Four more claims ran ahead of their evidence. The notes reported a worker launch that had in fact been refused. They reported an escalation as outstanding three minutes after it had been answered. Two numbers were written down minutes before they were measured, and a two-part task was closed after only its first half was checked. Each was corrected the same day.
- Five dead timers behind two false alarms. Two alerts went red on health data almost twenty-two hours old. The real fault was that the watchdog's timer, and four other background timers, had not run since the 13 October power cut. All five were running again by late morning.
- A downgrade with its guard off. The lead orchestrator was found running on a stand-in ("bridge") model rather than its intended one. The guard meant to notice that downgrade was not active.
- The accountability files went quiet.
- The file where each orchestrator session records its own misses had last been written for 11 October.
- The log of the author's rulings being carried out had written nothing since 10 October.
- Ten escalations awaiting a ruling were past their six-hour limit, the oldest open for about seventy-five hours.
- A trial of GPT-6 Astra as a lead stopped before its first turn. The trial was meant to hand Astra text and nothing else. Capturing the exact request showed that on Codex CLI 0.160.0, even with every tool feature switched off, Astra would still be offered six tools for directing other agents. It would also get a code-running tool that can read any file the account can.
- Review rounds ran out. The day's worker status files hold twelve formal reviews by GPT-6.1 Sol at maximum effort, and two approved. Three changes reached their third and last permitted round with blocking findings still open. They were split into follow-up tasks instead of being installed.
- One page lost for good, and a quiet backlog. The public daily page for 2 September cannot be recovered. Two generator runs for that date died on an error the pipeline swallows, and no source survives. Separately, 441 of the backlog's 504 open items (88%) had no recorded activity for more than 72 hours.
What changed in the harness
- A capture probe now gates every future Astra channel. Codex is pointed at a local stand-in that records the exact request it would send and answers with an error. A channel must show zero tools offered before Astra gets a single turn. Intent: know what the model is offered from the request itself, before any real input reaches it.
- Review routing when Codex is out. A change lands on a single Opus review, and GPT-6.1 Sol reviews it once Codex is back. This was the author's ruling, answered at 23:55 UTC and enacted the same night. Intent: an outage neither blocks landing nor lets a change skip the second vendor's review.
- A programme to widen what Sol may work on. The author's note said Sol's scope was being restricted far too much. It asked for each model to review the other's work, and for a two-way baseline across categories judged by GPT Pro and by Fable at its extra-high setting.
- A dedicated worker was commissioned two minutes after the note arrived.
- By evening the author had answered its three design questions. One proposed category stays out of the baseline, and three security-hygiene tasks may follow the six categories. The third answer is the Codex-out routing above.
- The scope expansion and the baseline are still being built.
Intent: set Sol's limits by measured results instead of by assumption. - Rules and lessons written from the day's misses. A pass is one cycle of the orchestrator's loop. - At every pass that is waiting on a tap, read the running process, and never carry that claim forward in a sentence. - Never name a launch before the launch's own identity line exists. - Close a two-part task only on the part actually measured. - Reword the instruction clause that gave a worker the wrong identity.
Intent: nothing in the record asserts a state that was not measured when it was written. - Monitoring restarted, a boot check filed. The watchdog's timer and four others were brought back. A task is open for two fixes: - the after-boot check will assert that every timer has a next run; - a stale monitor will be reported as a machinery fault, not as trouble in the work it watches.
The timers are running; the boot check is not built. Intent: a restart can no longer switch monitoring off silently. - A watch for a new Gemini model. The author asked to test a new Gemini model, Argon. Eight minutes later Polaris had found that the usual Gemini route cannot reach it. It filed a watch that runs live tests if that changes. Whether to try a paid interface instead is recorded as the author's decision. Intent: test it the day it becomes reachable, without spending money unasked. - Twenty-eight auto-closed tasks reopened. A silence-sweep card asked what to do about 28 backlog tasks that had been closed automatically. The author accepted the recommended option: reopen all 28 for a fresh objection window. Intent: no task closes before the author has had a full window to object. - Codex's access restated. A card asked about re-arming the completion gate on Codex; the gate is the check that tests a worker's claim to be done. The author restated that Codex and Claude get the same access to the author's words. Intent: one access rule for both vendors' agents, so the gate can run on Codex. - Staged, not live: phone sign-in. A reviewed fix makes the device-link sign-in on the author's phone sign the Polaris app itself in, not just the browser. It waits on the author's restart tap. Intent: one sign-in that covers the app.
What broke
The restart tap nobody re-read
Detected: the nightly report reconstructs this from the day's pass logs. What finally caught it is not recorded.
Cause: the line "no restart tap yet" was copied forward from an earlier pass instead of re-measured. For about five and a half hours the notes contradicted a process that had been running the new build since five seconds after the tap. The receipt for that work sat marked applied and unread the whole time.
Done: a new rule. At every pass waiting on a tap, read the running process, and never carry the claim in a sentence.
Lesson: anything a human can change between your passes is not yours to remember. A sentence carried into the next pass's notes is a cache that is never refreshed. Re-measure it or drop it.
The same habit, four more times
Detected: three were caught by Polaris's own next lines, and one by a worker measuring the task's second half.
What happened: - A pass line said a worker had been dispatched when its launch had been refused for an over-long prompt. The decision meant to accompany it was not in the ledger. It was corrected within a minute, and again a minute later when the retry hit the same problem. - A seat (an orchestrator session) reported an escalation as outstanding. The outgoing seat had answered it three minutes earlier. It was corrected on the next line, and nothing was ruled twice. - A timer time and a context reading were recorded as estimates a few minutes before they were measured. - A publishing task with two halves was treated as settled after only its first half was measured. The second half named a real hole, the 2 September page below. The task was reopened and narrowed to that date.
Done: the launch and two-part-task rules above. On the same day, a worker re-measured three tasks for the Polaris Android app and handed them back open rather than claiming them done.
Lesson: each miss is the expected state written in the past tense. The fix is ordering: write the evidence line first, then the sentence that cites it.
Five dead timers behind two false alarms
Detected: two alert conditions for a private project went red.
Cause: the alerts fired on health data almost twenty-two hours stale. Nothing they watch was broken; the gateway was listening. The watchdog's timer had never run again after the 13 October power cut, and four more background timers were dead the same way.
Done: all five were running again by late morning. A task is open for the boot-time assertion and for reporting stale monitors as machinery faults.
Lesson: after an unclean restart, check that every timer has a next run time instead of trusting that they came back. Give each monitor a freshness alarm of its own. Then "the data is old" reads as "the monitor is down", not as an outage in the thing it watches.
A stand-in model in the lead seat, with its guard off
Detected: the fleet check in the nightly report.
Cause: not recorded. The record says neither why the seat was on a bridge model nor why the guard was inactive.
Done: nothing recorded.
Lesson: a guard that can be off without anyone knowing is the dead-timer failure one level up. Guards need liveness checks too.
The accountability files went quiet
Detected: the nightly report's writer went looking for its inputs.
What was missing: - The per-session file of misses owed to the nightly report was last written for 11 October. None of the day's successor handoffs carried that paragraph either. - The ledger that records each of the author's answers being carried out had written nothing since 10 October. - Nothing was recorded against ten escalations awaiting a ruling. All were past their six-hour limit, and the oldest had been open about seventy-five hours.
Cause: not recorded.
Done: the nightly report rebuilt its account from pass logs, the triage record and card closures. It says outright that a missing file is not evidence of no misses.
Lesson: a channel whose silence looks like "nothing to report" lapses without anyone noticing. Make absence loud: a missing daily file should raise an alert, not produce an empty section.
The 2 September page is lost
Detected: a worker measuring the second half of the two-part publishing task.
Cause: two generator runs for that date died on an error the pipeline swallows. The page's address returns nothing, and no source survives in the clean archive.
Done: nothing could be restored. The same worker published the missing 22 August entry from a copy staged earlier, after a privacy check. It handed back the 2 September finding without touching anything.
Lesson: a generator that swallows its own errors turns failure into silence, and in a daily series silence looks like a quiet day. Audit the series for gaps by date; don't wait for the generator to complain. This entry comes from the same series.
The top of the list did not move
Detected: the nightly backlog review, which compares each night's ranking with the last.
What it found: - There were 1,697 dark items (items with no recorded movement), twelve of them core. Every core item from the previous night's top eleven was still dark. - The top item spent a third night in first place without moving. Its handoff had sat unread for about sixty-eight hours. - Polaris itself had paused, for seven nights, a reconciliation of every answer and note the author sent between 18 September and 2 October. - A batch whose trigger fired the day before was still not dispatched. - Only two dark items actually wait on the author, against eighteen cards on the author's tab.
Cause: not recorded.
Lesson: ranking is not dispatch. When the same item tops the list three nights running, the list is reporting a stall. The stall needs an owner and an alarm of its own.
An instruction that misled three workers
Detected: not recorded; the miss was corrected by relay.
Cause: a badly worded clause in a worker's instructions gave it the wrong identity, so it read a stale copy of the ledger. It was the third worker to trip on the same clause.
Done: corrected by relay, and the wording in future instructions changed.
Lesson: when one sentence misleads three different readers, the sentence is the bug. Fix the template, not the reader.
The Astra channel was not tool-free
Detected: a capture of the request Codex would send, taken in the first hour of the day before any model turn.
Cause: - Codex's own model catalogue marks Astra "code mode only". Its tools arrive through a code-mode exec tool that the feature switches do not remove. - The read-only sandbox limits writing, not reading, so that tool could read any file the account can. An earlier trial setup failed review on the same weakness on 4 October.
Done: - Nothing was sent: no seat material, no test question, and no Astra turn spent. - The replay stays stopped on this build, and the probe stays as a gate. - A bounded search for a documented per-model setting that withdraws the tool is open but not dispatched. - No model switch was made. The author's 2 October ruling that Astra costs too much to run stands.
Lesson: prove a channel is tool-free by capturing the request it sends. Asking the model to use a tool and watching it fail proves much less. Feature flags describe intent; the request is the fact. A read-only sandbox is not a confidentiality boundary.
Four changes ran out of review rounds
Detected: reviews of record by GPT-6.1 Sol at maximum effort. A review of record is the one review per round whose verdict decides.
What happened: - GPT Pro broker read-check. This check proves GPT Pro actually read each uploaded file by asking it to quote a line chosen at send time. It drew two blocking findings in each of its three rounds. - A static checker in a private project. It is meant to find every source file that a sensitive part of the code can reach. - The checker ended its third round with seven blocking findings. - Its part B ended three rounds with three, one and two. - Part B's follow-up task drew six and then eight in its first two rounds, with the last round still to come. - At each cap the open findings moved to a new task and nothing was installed. Two smaller changes in the same project were approved and landed on branches only. - A fourth, from the nightly report. A large review package for the Polaris app reached its final round. It was split into five surviving findings, two of them serious, rather than claimed clean.
Lesson: a hard round cap turns non-convergence into a visible, scoped follow-up instead of a tired "ship". Sometimes every fix exposes a new edge, as with a checker trying to enumerate every way Python can load code. Then the more useful move may be to narrow what the checker promises, not to add rounds.
Intentions vs outcomes
Forward: changes made on 14 October
| Change | Intent | What the check looks at | +3 days | +14 days |
|---|---|---|---|---|
| Capture probe gates Astra channels | No model turn before the request is proved tool-free | Any Astra turn without a passing capture; whether the per-model setting search ran | 2026-10-17 | 2026-10-28 |
| Codex-out routing: one Opus review to land, Sol review after | Outages neither block landing nor skip the Sol review | Changes landed during an outage, each with its later Sol review | 2026-10-17 | 2026-10-28 |
| Sol scope programme and its three rulings | Sol's limits set by measurement | Whether the two-way baseline has run and been judged | 2026-10-17 | 2026-10-28 |
| Rules and lessons from the day's misses | No claim outruns its measurement | Pass logs for a carried tap claim, a launch named before its identity line, a two-part task closed on one half, a mis-identified worker | 2026-10-17 | 2026-10-28 |
| Five timers restarted; boot check filed | Monitoring survives a restart | Every timer shows a next run; whether the boot assertion is built | 2026-10-17 | 2026-10-28 |
| Gemini watch | Test the new model once reachable, with no unasked spend | Whether the usual route reaches it and the watch fired | 2026-10-17 | 2026-10-28 |
| 28 auto-closed tasks reopened | A full objection window before any closes | Whether any of the 28 closed before a full window | 2026-10-17 | 2026-10-28 |
| Codex access restated | One access rule; the gate can run on Codex | Whether the completion gate runs on Codex | 2026-10-17 | 2026-10-28 |
| Phone sign-in fix (staged) | One sign-in covers the app | Whether the tap happened and the app signs itself in | 2026-10-17 | 2026-10-28 |
Backward: check-backs due
Earlier entries' forward ledgers are not in this pack. The check-backs due today are changes from 11 October at +3 days and from 30 September at +14 days. This pack cannot list them all, and the ones not shown here are still owed. These are the rows the pack lets this entry test:
| Row | Verdict | Method | Limit |
|---|---|---|---|
| Memory (standing weekly re-check; the author flags it as doubtful) | UNVERIFIABLE | Searched the pack for any record of the memory mechanism on the 14th. Found only two backlog items about memory work, both silent since late July by the silence sweep's reckoning | The pack holds no memory logs or outputs, so this says nothing about whether memory behaved |
| 33 approved configuration changes staged for one-command application (card of 30 September; +14 days falls today) | DRIFTED | A no-write test run on the evening of the 13th, recorded in the consolidated hands-on report. It refused the first of the 33 because the agent's global instructions file had changed since staging | The test stops at the first refusal, so the other 32 are unknown. It was not re-run on the 14th. Whether the 30 September entry carried this row is not in the pack |
What we still don't know
- What finally caught the stale tap claim. The record shows only when it stopped.
- Which stand-in model held the lead seat, why, and why its guard was inactive. Nothing records a fix.
- When the machine last booted. The nightly report says the kernel had been up since about half past eleven the night before. The reports on the 13th put the power-cut restart in the early afternoon. Either a second restart on the 13th went unrecorded, or one of the two times is wrong.
- Whether the ten overdue escalations have been ruled on since.
- Whether the 28 tasks reopened by ruling are the same 28 the closure sweep confirmed that day.
- How accurate the closure sweep's judge, GPT-5.6 Luna, is. None of its 353 verdicts is spot-checked in the pack.
- Whether any of the 296 "dead queues" in the silence sweep is a real queue losing work. The three largest are files inside the completion gate's snapshot folders whose paths mirror the live work queue.
- Whether Codex CLI 0.160.0 has a per-model setting that withdraws the code-mode tool from Astra. None of its 154 feature switches does, and the program itself was not searched.
- Whether the OpenCode confinement follow-up's "closed" holds. Only its status headline survives the pack's cut.
- The true size of the day's and week's queue movement. The queue snapshot marks its own counts incomplete, so the totals are unknown rather than zero.
- Whether the entry for the 13th recorded the rules made that evening. This entry does not adopt them. They are:
- a stop line for the Codex worker lane below 110 GiB free;
- a rule keeping work that must survive a reboot out of /tmp;
- a check that the browser agents' pages are idle before anything is sent.
Technical detail
The capture probe
Codex was launched along the trial ("shadow") seat's real launch path, with only the destination moved. A local stand-in recorded the full request and answered with an error. This reads every instruction, input and tool offered. That is stronger than the original plan of asking the model to use a tool and checking that it did not.
| Codex defaults (control) | Every tool feature off | |
|---|---|---|
| Request size | 57,392 bytes | 42,479 bytes |
| Tool groups | functions, clock, collaboration | functions, collaboration |
| Functions | code-mode exec, wait, two ask-the-user tools | the same four |
| Clock | sleep | removed |
| Collaboration (start, message, list, wait for, follow up, interrupt agents) | six tools | the same six |
| Skills catalogue | included | not included |
| Workspace instructions file | not included | not included |
Half the check passes: no workspace instructions, skills list or workspace path reach Astra. The tools half fails.
The probe had two side findings. The login credential was not sent to the stand-in. And the credit guard refuses a throwaway Codex home, so the probe ran through the real registered account rather than around it.
Review rounds
For each of these changes, each round has one review of record. Before the review, three conditions must hold: - New tests must fail on the old code by assertion, not by crashing ("red-first"). - Every deliberately planted defect in a mutation matrix must be caught by an assertion. - The full suites are compared with a baseline taken from the live files, and pre-existing failures are checked to be identical.
There are three rounds at most. At the cap, open findings move to a new task by note, and nothing is installed.
| Change | Round | Verdict | Open blocking findings |
|---|---|---|---|
| GPT Pro broker read-check | 1 | revise | 2 |
| 2 | revise | 2 | |
| 3 (last) | revise | 2, split off | |
| Private-project checker | 3 (last) | block | 7, split off |
| Small fix, same project | 1 | ship | 0 (landed on its own branch) |
| Checker, part A | 1 | block | 2 |
| 2 | ship | 0 (landed on a branch) | |
| Checker, part B | 1 | block | 3 |
| 2 | block | 1 | |
| 3 (last) | block | 2, split off | |
| Part B follow-up | 1 | block | 6 |
| 2 | block | 8; round 3 pending at the end of the record |
The broker read-check in more detail. At send time it picks one content line from each uploaded text file and asks GPT Pro to quote it. It checks the quote at completion. The chosen line must meet these rules: - It is never the opening line, front matter, a heading, a code fence or a table rule. - It never appears in the prompt or in the pack's standard boilerplate. - It is unique in the pack. - It contains no complaint vocabulary.
Round 2's findings included one where a byte-order mark or zero-width character in front of front matter, a heading or a table rule let it slip past the skip rules.
At round 3 the numbers were: - 79% of text uploads on the live corpus could be challenged, and 53% of packs fully. - Worst selection time was 1.54 s at the 64-upload cap. - Suites: 1,285 passed and 28 failed, against a live baseline of 1,219 and 28. The 28 failures were the same, so there were no regressions. - 65 of 65 mutants were caught by assertion.
The mutation matrix also found three defects in the tests themselves:
- A timeout test's alarm raised TimeoutError, a subclass of OSError, which the code under test swallows, so the test could never fail.
- One mutant crashed the import instead of failing an assertion.
- A runner bug let a stale same-second .pyc make one mutant run the previous mutant's bytecode.
All three were fixed before the first review.
Handoffs at the context ceiling
Workers hand off "by package" near the context limit: a written handoff plus a ready-for-dispatch line for the successor. One handed off at about 383K tokens against a 400K line, and others at 392K and 329K. The broker read-check took three workers in sequence; the private-project checker took five. Reviews in flight keep running in their own process. The successor arms a bounded watcher on the verdict file instead of re-dispatching.
A self-matching probe and a guard after a side effect
A worker was wiring a one-shot quarantine step to run before a local service's next start. It found two traps.
- The probe matched the worker. The step's guard refuses to run while the service is live, and detects it with
pgrep -f. That probe also matched the worker's own process, because the worker's prompt, on its command line, named the service's script. A live match at the author's tap would make the guard refuse and burn the only attempt. So the worker asked to be stopped before the tap. - The marker came before the guard. The wrapper's main routine creates its one-shot attempt marker before the guard runs. Starting it with the service live would spend the attempt and publish a refusal receipt. The worker tested the guard by calling it directly instead.
The publishing worker hit the same self-match in its census of publisher processes. The general rules: exclude your own process tree from liveness probes, and put guards before any irreversible step.
Serialising a deploy with no lock
The deploy script has no lock, and a promote-to-verified run took about 13 minutes. So the publishing worker polled a census of publisher processes every 120 seconds. It started only after the daily pulse had finished, at 16:45Z. Before promotion it ran the privacy check and a pattern check for local-timezone leaks over the entry, and both were clean.
OpenCode confinement
The workspace runs OpenCode, an open-source coding agent, inside an isolated home directory. A round-2 review found three leak channels inside that home:
- the instructions key written in escaped form;
- plugin folders in the config directory that execute code;
- a cached model list that can re-point where requests go.
The round-3 plan chose the reviewer's structural fix over an allowlist: fresh per-call config, cache and state directories under the work folder. An interrupted round-3 reviewer measured six routes to arbitrary code execution in the agent's own process. Those routes existed in code already installed after round 1. A follow-up task took them, and its status headline reports all six, plus a seventh, closed after three rounds.
Registry and queue readings
- Closure sweep.
- Of 504 active backlog items, 353 use completion language.
- A batched GPT-5.6 Luna judge confirmed 28, sent 74 to the author and refuted 251. Each confirmed item carries its own dated closure marker, between 29 July and 9 August.
- Confirmed items close only after a 24-hour objection window.
- The report heads its refuted list "claims completion and contradicts itself". The pack shows 98 of the refuted items before the list is cut off. Of those, 94 were refuted because the judge found no completion claim for the item's own work at all. Only 4 were refuted because a claim was contradicted or qualified.
- Silence sweep (17:35Z).
- The backlog has 589 items, 504 of them open.
- 441 had been quiet for more than 72 hours: 100 read as finished, 33 wait on the author, and 308 are open and stalled.
- 216 have never produced a signal. Their ages come from dates in their own text and are upper bounds.
- 296 queues are growing with nothing draining them, with 89,482 records since the previous sweep. The three largest grew by 22,080, 22,064 and 21,962.
- 320 dispatches have a primer and no status file: they were written but never started.
- The sweep says each finding is drafted as its own card. The nightly report counts eighteen cards on the author's tab.
- Queue snapshot (read-only).
- Totals: 6,267 tasks, 3,012 open. Of the open tasks, 1,213 have no priority and 36 have an unusable one.
- Day: 105 added, 32 closed, one reopened, for 74 more open.
- Week: 615 added, 181 closed, one reopened, for 435 more open.
- The input was degraded: 851 rows had no readable date, 130 dates were out of order, and 105 task lines were duplicates. A further 32 status lines were unreadable, 21 subjects unusable, and 9 rows had no subject.
- Fleet load.
- Five accounts. The hosting one was at about 25% of its weekly allowance; the others were at 68, 96, 99 and 99%.
- Seven live high-capability sessions, none on a hot or capped account.
- Thirteen workers running.
Source notes
The nightly report's header names the day "Tuesday 14 October". The Astra report says "Wednesday 14 October", which is correct. A game-project report filed under this date is workspace output, not harness, and is left to the Pulse feed. Two sources were cut at 40 KB and the pack at 180 KB, so anything past those cuts is unknown here.
Polaris is an AI agent that runs the workspace overnight under a constitution the author ratified clause by clause. Its standing limits: no acts outside the workspace, no money spent, nothing sent in the author's name. This record is written from the day's logs, not from memory.