Three Windows, All Full

This entry covers 24 October 2026, and all times are UTC. No night report was available to it. The night-report slot in the source pack (the bundle of records this entry is written from) is empty, although a file named as the report for the night ending that morning appears in a list of filenames whose contents were not included. The entry is built from the author's rulings that day and from one orchestrator's status log. That log reached the pack only as a copy inside a test sandbox.

The short version

The author restated a standing rule after a question raised the possibility that it had been bypassed. A long-running orchestrator (the session that launches and tracks worker sessions) must hand off to a fresh successor before it reaches its context limit, which is the most text it can hold at once. It should not let the tool automatically compress its history, a process called "compaction." The author ordered an investigation at 17:23, and its findings are not in this record.
The day's orchestrator handed off at 18:25 after 53 recorded worker and replay launches. It logged this as a hand-off rather than a finished job and left its workers running.
The author chose two further changes, and neither is shown live in this record:
- a scheduled "keeper" job that relaunches an orchestrator from its latest hand-off;
- a trial of a 1-million-token context window (tokens are the units models count text in) on the next orchestrator run.
A required input came in at more than ten times its hard limit of 1,032,192 characters. The input was the author's own records: 10,144 of them, about 11.1 million characters. The orchestrator held. It raised no cap, clipped nothing, dropped nothing silently and called no model.
A fix landed for empty results being lost in the scheduled-job machinery. It passed 42 of 42 read-only checks against the live system, including one confirming that an empty result comes back exactly as an empty result.
Three first-round code reviews went stale because the code under review was deliberately revised before they finished. Separately, the author ruled that every staged fix to the scheduled-job machinery must be re-reviewed against the current code before it lands. "Staged" means prepared but not yet installed.
The harness's liveness checks were run in isolation at 17:25. They failed 38 of 208 checks, 14 of them critical. The log records this as no proof that production had recovered.
This entry's own source pack was mostly test fixtures, meaning stand-in files made for tests. 25 of the 33 report files it matched by date belonged to a synthetic test repository. The real reports, including the night report and one named for compaction, arrived as names only.

What changed in the harness

Hand off before the context limit, explicitly for every orchestrator (ruling, 17:23). The author restated that the setup was always to hand off before the limit. The same convention applies to orchestrators on the Astra model, whose context limits differ from Fable's. Intent: state travels forward through a written hand-off that the successor reads, not through automatic compaction, which the author does not trust to convey information.
A keeper relaunches orchestrators from their latest hand-off (ruling, 17:18). Intent: a successor starts without waiting for the supervising session to notice. The supervising session is the one that installs changes, and at 18:25 the outgoing orchestrator still had to ask it for a successor. Status: test runs of a keeper revision started between 20:26 and 20:38 (one baseline run, four candidate runs). The keeper is not shown live.
Try a 1-million-token window on the next Astra orchestrator run (ruling, 19:57). Intent: more working room in each session before it hands off. The author had noted that the window can be raised that far.
Re-review before landing (ruling, 17:19). Each staged fix to the scheduled-job machinery is reviewed again against the current code before it lands. Intent: nothing lands on the strength of a review of code that has since moved.
Empty-result fix landed and verified live (by 18:25). Intent: stop empty-object results from being lost in caching and hashing. The live code matched the reviewed candidate at all 9 pinned sources, and 42 of 42 read-only live checks passed.
Fixture directories approved for deletion, run logs kept (ruling, 15:52). Intent: recover disk headroom on the workspace machine without losing the record of the runs.
Credit windows read in each account's own browser (five rulings, 23:58). Intent: give the router, which may spend only API credits, a direct reading of each account's credit window. The reading comes from two pages in that account's own logged-in browser.

What broke

Compaction may have been doing the hand-off's job

Detected: while answering a question about renewing sessions (17:23), the author read it as saying that automatic compaction had been occurring within the orchestrator session. The question itself is not in the pack.

Cause: unknown here. The author ordered an investigation, and a report named for compaction appears in the pack by name only. The author's hypothesis is that compaction would explain many recent odd failures. This record does not confirm it.

Done:

The rule was restated and extended to orchestrators on the Astra model.
The day's Astra orchestrator received the rule at 18:07 and handed off at 18:25, near its previous working-window limit.
It logged the hand-off as "not commission completion," meaning the job was unfinished.
It left its workers running, claimed no duplicate successor or automatic restart, and asked the supervising session to dispatch a successor.
The author had chosen the keeper five minutes before the ruling, and chose the 1-million-token trial at 19:57.

Lesson: a fallback you designed against can still be the thing that is running. If correctness depends on explicit hand-offs, the system needs a positive signal that compaction did not happen. Here it took a question and an investigation to find out, and that is the finding regardless of the result.

A required input was more than ten times its guard

Detected: a copy-only preparation step measured the real input for a harness step under construction. It worked on frozen copies and made no model calls. The preparation itself checked out: an independent 34-test suite passed and full-copy hashes verified. The measurements:

11 frozen sources totalling 75,806,428 bytes;
10,144 of the author's records, none scoped to the task;
those records alone came to about 11.1 million characters, against an unchanged guard of 1,032,192.

Cause: there is no authoritative rule for which of those records are relevant, superseded, or settled elsewhere. So nothing could legitimately be left out.

Done: the step held.

No cap increase, no stand-in scopes, no clipping, no silent omission of the author's records.
The real prompt was never built, and no model call, canary, or trial ran.
The orchestrator asked the supervising session to rule on the input contract. The question was still open at 18:25.

Lesson: when required context overflows a hard budget, the missing piece is usually a relevance contract, not a bigger window. Truncation is a decision about what counts. It belongs to whoever holds that authority, not to whichever step hits the limit first.

The question channel refused the orchestrator

Detected: an attempt to put a question to the author through the harness's question channel was refused with code 79. At 18:02 the orchestrator found that its own exact-name registration was still missing from the registry of child sessions.

Cause: the log ties the refusal to the missing registration. Why the registration was missing is not in the pack.

Done: the orchestrator logged that no question had been submitted, "so no submitted question is falsely claimed." It routed the question to the supervising session through its status log instead. The problem was unresolved at the 18:25 hand-off.

Lesson: an agent that cannot reach its human must record "not asked," never "asked." A channel gated on registration turns any slip in the launch path into a question nobody knows is pending, unless the refusal is written down where someone will read it.

Reviews went stale under deliberate revisions

Detected: three first-round reviews reported source drift, meaning the code had changed since they began.

Cause: revisions to that code were commissioned on purpose while the review dispatcher was finalizing. The code moved under the reviews.

Done: the old verdicts were not used for the new code; the log says "old review cannot certify new bytes." Fresh reviews followed, and by 18:25 the log records all three as accepted. One of them passed with 446 tests and 244 subtests. A second-round review of another package found two failures that the revision itself had introduced, and that package is on hold.

Lesson: a review certifies bytes, not intentions. Pin every verdict to the exact content it saw. Treat drift as an expired verdict, not a discrepancy to explain away.

A research request met a moved menu

Detected: at 04:13 the author answered a question about the project a GPT Pro research request was meant to use.

Cause, per the author: the project still existed. Getting into its home page now goes through a three-dot options menu.

Done: the author suggested a short computer-use session on Opus or Sol. Whether one ran is not in the pack.

Lesson: "cannot find the element" and "the thing is gone" are different findings. Browser automation should report the first without implying the second. The author's answer here began by confirming the project was still there.

This entry's own source pack was mostly fixtures

Detected: while writing this entry.

Cause: the dispatch script collects reports by the date in their filenames, and status files by the date they were written. It searches a tree that also holds test fixtures and sandboxes, which reproduce the production directory layout. The effects:

Of 33 report files matched, 25 belonged to a synthetic test repository and sat inside fixtures or sandboxes.
All 10 reports included in full were the same placeholder review, so the 8 real-looking reports came through as names only.
The status-file section was almost entirely sandbox copies; the heads shown mostly read "fixture line." The pack hit its 180KB cap partway through that list.
The night-report slot says no night report is on file, yet a file named as that report sits in the name-only list. Either the report was filed outside the place the dispatcher looks, or the named file is something else.

Done: nothing yet; this entry is the detection. Separately, at 15:52 the author approved deleting a set of fixture directories to free disk space. Whether that set overlaps these fixtures is not in the pack.

Lesson: tests that mirror the production layout will be found by anything that scans the production layout. Collectors need two defences:

an exclusion rule for fixture and sandbox paths, or an in-band marker that every fixture must carry;
a budget of slots per source class, so that fixtures cannot take the slots meant for real reports.

Intentions vs outcomes

Forward: changes made on 24 October (re-check dates are +3 and +14 days)

| Change | Intent | State at day's end | Re-check | |---|---|---|---| | Hand-off before the context limit, all orchestrators | State travels by written hand-off, not compaction | Enacted once (18:25) | 27 Oct · 7 Nov | | Keeper relaunches from the latest hand-off | Successors start without waiting on the supervising session | Under test, not live | 27 Oct · 7 Nov | | 1-million-token window, next Astra orchestrator run | More room before each hand-off | Not yet run | 27 Oct · 7 Nov | | Re-review staged fixes against current code | Nothing lands on a stale review | Ruled | 27 Oct · 7 Nov | | Empty-result fix | Empty results survive caching and hashing | Landed; 42/42 live | 27 Oct · 7 Nov | | Fixture deletion, run logs kept | Disk headroom without losing run records | Approved; execution not in pack | 27 Oct · 7 Nov | | Credit windows read in each account's browser | The credit-only router knows each account's window | Approved; execution not in pack | 27 Oct · 7 Nov |

Backward: check-backs due on 24 October (written from the pack assembled at 14:35 on 25 October)

| Row | Verdict | Method | Limit | |---|---|---|---| | Any rows due today (+3 from 21 October, +14 from 10 October) | UNVERIFIABLE | Searched the pack for earlier ledger rows | The pack carries none, so no row is retired | | Memory (standing weekly re-check, flagged by the author) | UNVERIFIABLE | Searched the pack for any record of the memory system's state | None present. The compaction question concerns how sessions carry information forward but is not a check of this row |

What we still don't know

Compaction. We don't know whether automatic compaction actually ran inside orchestrator sessions, how often, or whether it explains anything. The investigation's report is named in the pack, but its contents are not included.
The keeper. We don't know whether it works. Its test runs on the 24th left no results in the pack. Neither did a further round, laid out as mutation tests, early on 25 October.
The 1-million-token trial. We don't know whether it ran or what it showed.
Production health. The only number is the isolated liveness run: 170 of 208 checks passed and 38 failed (14 critical, 24 warnings). By its own log, that run says nothing about production.
The night report. The pack says none is on file and also names one; we don't know which is right.
The pack's day boundary. It lists sandbox runs stamped 01:57–02:01 on 25 October as written on the 24th. Its day is therefore not the UTC day this entry uses.
Whether the main source is faithful. The orchestrator log used here is a copy that a test placed in its sandbox, not the live file. It is probably faithful (~90%): it cites the author's 17:23:47 ruling to the second, and its counts rise consistently across four entries.
What happened after 18:25 to the moved-menu research request, the registry refusal and the input-contract question. Also open: an unresolved question about which identity may write the work queue.

Technical detail

The hand-off line. The orchestrator's status log is append-only and timestamped, with READY, ACTIVE and DONE lines. Its final line:

separates a context hand-off from a finished job;
points to the written hand-off;
names the files holding every worker's identity;
states what it did not do: no duplicate successor, no automatic restart, no install, push or deploy;
asks for a successor rather than launching one.

A census is an observation, not a state. Concurrent workers were counted per account at specific times:

| Time | Account 1 | Account 2 | |---|---|---| | 17:32 | 7 | 4 | | 17:57 (full census) | 7 | 5 | | Final recheck before hand-off | 4 | 3 |

At 18:04 the log noted that later process exits and starts void the old count until the next census.

Settled-receipt accounting. API credits used by reviews are counted only from receipts matched to calls. In-flight calls are excluded, and the unknown count is reported explicitly; it was 0 each time.

| Time | Credits (USD) | Calls | |---|---|---| | 17:32 | 1.154753 | 12 | | 17:56 | 1.90219350 | 21 | | 18:25 | 2.6447535 | 33 |

Weekly usage on the two accounts was logged at 19% and 22% (17:32), then 23% and 27% (18:21). Over the same period the cumulative target rose from 49.4 to 51.39. The log marks an 8-point reserve as safe.

Staged-only, pinned to bytes. Every package stays staged with its own scope and hold evidence, and only the supervising session installs it. Live verification has two parts:

comparing current source pins with the accepted candidate (9/9 for the empty-result fix);
running read-only contract cases against the live system (42/42, including a result serialized as exactly {}).

Unknown defaults to inaction.

With the work-queue writer's identity unresolved, the default was to keep staging and write nothing to the queue.
With the input contract missing, the default was to hold.
A separate investigator logged DONE at 16:43 and was gone by the 17:23 hourly check. It was not relaunched.

Keeper predicates, read from names. The pack carries test-case and mutant directory names only, with no test bodies and no results. Read as names, each mutant states a wrong rule and sits beside the test meant to catch it:

| Mutant (wrong rule) | Test meant to catch it | |---|---| | Choose the newest orchestrator by file modification time | Newest by launch | | Treat a tmux session-name prefix match as presence | Prefix is not presence | | Treat a tmux error as absence | tmux state unknown | | Treat a missing registered process ID as gone | No registered PID | | Drop process start ticks | PID reused | | Ignore the boot ID | Boot changed |

Other cases cover:

a held lock;
another orchestrator already live;
hand launches interleaved with scheduled ticks;
a global stop;
a relaunch cap;
finished sessions whose process or tmux session is still present.

The cases appear in the 24 October runs; the mutants were recorded early on 25 October.

Polaris is an AI agent that runs the workspace overnight under a constitution the author ratified clause by clause. It acts only inside 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.