Covers the calendar day of 2026-07-21. Two night reports overlap it and neither matches it: the report dated the 21st covers the night that ended that morning (a session that began about 18:20 the previous evening and ran to dawn), and the report dated the 22nd covers 12:39 on the 21st through 05:00 the next morning. That leaves roughly six and a half hours in the middle of the day — from the morning reconciliation to the early-afternoon handover — with no night report over it, only status files and the ruling ledger. One further seam worth naming: rulings are timestamped in UTC and sessions log in local time, seven hours apart, so a few records dated the 21st happened on the evening of the 20th. Those are left out.
The short version
- The launcher reported that remote control had failed to connect, and it had not. The session had engaged in three seconds and zero connection errors existed. The failure was in how the launcher checked, not in what it launched. Fixed at three layers the same day, adversarially reviewed, six of the reviewer's higher-priority findings remediated before the day ended.
- A tool the workspace maintains was reporting a result as impossible when the real problem was one of its own divisors. The author said so directly, told the agent to go find the breakdown, and two independent research arms converged on it: a variable that had been frozen into a lookup table as if it were a hardware constant. A second, independent error sat underneath it.
- The night guard closed nothing all night, correctly — and then deferred everything else because a refused attempt had already spent the night's budget of one. The guard's own safety check charged the refusal as if it had acted.
- A review rule written to prevent evidence-shopping turned out to be the shopping channel. The rule said the highest-quality evidence wins; deciding which evidence is admissible therefore decided the answer. The reviewer caught the author's own table quietly downgrading an inconvenient item.
- The orchestrator lease changed hands at 12:55, mid-afternoon, when the seat it was running on exhausted its top-tier quota. Generation 3 came up on a second account, and the successor session launched later that night used the launcher fixed hours earlier — which verified correctly on the first attempt, in the exact scenario that had produced the false failure the day before.
- Five separate adversarial review gates closed that day, running three, four, two, three and five rounds. One of them caught a live scheduling bug in a script it had not been asked to look at — a command substitution that would have executed at the wrong moment and killed the following Monday's run.
- Fifteen adjudications were recorded in the day's ledger. Zero external acts, zero money spent, no pushes, no deploys.
What changed in the harness
Launch verification was rebuilt around evidence instead of inference. Intent: make "is the remote-control transport actually connected" a checked fact, so the launcher stops manufacturing failures. Six changes went in together — awareness of which config directory a seat runs under, a file-birth-time probe that now prints a visible warning when the underlying system call is unavailable rather than silently degrading, session-identity resolution from the debug directory bound to the pane it belongs to, an engagement test that accepts either a transcript event or the transport's own connected record, a shell-safety fix, and recovery advice that tells the next caller not to relaunch (because relaunching costs an account seat).
The pass check began asserting that a second model is always working. Intent: "at least one review-model session is always burning" stops being something the orchestrator remembers and becomes something the pass proves. Evidence of work is a recently written transcript or a live process; the freshness bar is 45 minutes; and when the check fails, the alert carries the dispatch queue so the response is immediate rather than a lookup.
The author's to-dos got their own surface, separate from questions. Intent: an open question is something he answers in a sentence; a to-do is something he has to sit down at a machine and do. Mixing them made both lists lie about their own urgency. The pass check gained a cursor over check-off events written from the app, so a completed item is recorded, projected into the list, and reported.
A check-before-delivering rule was written into the session procedure. Intent: stop the same report being delivered twice. Before any report goes out, the delivery ledger and the destination are both checked; every delivery is recorded the moment it lands.
The commissioned-research procedure was codified as a standing skill. Intent: turn a pattern that had been improvised twice into something repeatable — a deep dive and a four-persona council run over one shared evidence pack, synthesised into a report, delivered with narration, with open design questions surfaced as questions rather than buried in prose. It was validated twice within its first twelve hours.
The lease now requires its seat. Intent: a succession is not complete while the lease has no seat. The manual transfer the night before had omitted the pane identifier, which would have left the pane-level guard dormant on the night guard's first armed night. Fixed by forced re-initialisation through the single writer that owns the lease, and the lesson written into the continuity design.
The local model-reference table was corrected, with its staleness root-caused. Intent: stop a stale local table silently overriding knowledge that was already correct. The correction was paired with the reason the table had gone stale — the updater responsible for it had been blocked since the 18th.
The deep-dive fallback became a council rather than a single call. Intent, from the author's amendment: what stands in for a deep research dive should have comparable depth. Applied in both the daily and weekly sweep scripts.
A review-dispatch timeout was raised from 25 to 75 minutes. Intent: a timeout is a claim about how long the work takes, and 25 minutes was shorter than a full-codebase review. Both dispatches succeeded on the next attempt.
What broke
The remote-control failure that never happened
Detected: the launcher reported repeated authentication failures on connect, and the standing advice for that condition — relaunch — had already been followed once, at the cost of a seat.
Cause: the verification, not the connection. The session had engaged in three seconds and no authentication failures existed at all. The launcher had been inferring engagement from signals that did not carry it, and inferring failure from their absence.
Done: fixed at three layers on the day — the launcher itself, the standing memory that had encoded the wrong recovery advice, and follow-up items filed against the watchdog. The fix was then handed to an adversarial reviewer, which returned six higher-priority findings; all six were remediated the same day. That night the successor session was launched with the fixed launcher and verified correctly on its first attempt, in the same scenario that had produced the false failure.
Lesson: a monitor that reports a failure which never happened is as expensive as one that misses a real failure — and it is harder to notice, because the response looks like diligence. The recovery advice makes it worse: a false positive with an expensive remedy attached converts a non-event into real damage. Any check that can return FAILURE needs the same scrutiny as one that returns OK, including the question of what it does when its own evidence is simply absent.
The infeasibility that was a divisor
Detected: the author, reading the tool's output, refused the result. His instruction was direct — the number the calculator calls impossible is a number that demonstrably runs in production, so the error is yours; go find it.
Cause: two errors, either fatal alone. The first was a deployment variable frozen into a lookup table as though it were a property of the hardware — the three values in that table turned out to be three different things (a scheduling allocation unit, a single instance size, and a misread), none of them the quantity the model needed. The second was a uniform division of the whole workload across that number, when production practice replicates some components and shards only others. A stale precision assumption compounded both.
Done: two research arms — a long-form dive and a live-source sweep — with the prime suspect pre-registered in writing before either returned. They converged on the suspect and the dive added the second error the suspect had missed. The redesign deletes the constant, models placement per component over declared interconnect domains, and — the part that matters here — replaces the FEASIBLE/INFEASIBLE boolean with a five-status vector, so that missing evidence renders as UNVERIFIED instead of as "impossible."
Lesson: a boolean verdict launders a modelling error into a fact about the world. When a system can only say yes or no, every gap in its own inputs comes out as a confident no. The generalisable fix is not a better constant, it is a return type with room for "I do not know" — and it applies to anything an agent reports, not just calculators. Second lesson, on method: writing down what you expect to find before the research returns is what makes convergence meaningful rather than self-confirming.
A refusal that cost the night its only attempt
Detected: the night guard's first graduated night ended with zero closes and zero errors — and with everything after its single attempt deferred.
Cause: the guard is capped at one destructive attempt per night. Its one attempt was correctly refused by a safety check before any keystroke was sent. But the attempt was charged at the top of the row, so a refusal that did nothing consumed the budget for actions that would have been permitted.
Done: filed to the backlog on the night. It was not fixed on the day.
Lesson: charge the budget for effects, not for attempts. A cap exists to bound damage; a refusal does no damage, so charging it converts a safety mechanism into a denial-of-service against the system's own useful work. The general form: any counter that gates behaviour must be incremented at the last moment that still precedes the irreversible act, never at the top of the block.
The rule against evidence-shopping was itself the shopping channel
Detected: by a reviewer, in round one, twice over.
Cause: the proposed rule was "the highest evidence class wins," which sounds like an anti-shopping rule. It is not: if the answer is determined by the best available evidence, then whoever decides what is admissible decides the answer. The reviewer executed the proposed scenario rather than reading it — and found it rendered only 48% of what the design claimed. It then caught the author's own evidence table silently downgrading an item that, at its correct classification, the author's own rule would have selected.
Done: the rule was fixed at the root — the admissible set is frozen in advance, applicability is judged before quality, and where no admitted evidence actually applies, the default becomes an explicit, banked, labelled choice rather than a derivation. A proposal of the author's own, which happened to improve the outcome, fell to the corrected rule and was withdrawn.
Lesson: a rule that selects on quality is a rule that selects on admission. The self-check that catches it: does my rule produce the outcome I wanted before I wrote it? Here it did, and the reviewer found the mechanism. Two related notes for anyone running review gates — a reviewer that executes the proposal finds things a reviewer that reads it cannot, and a gate that only ever catches other people's work is not being pointed at the right target.
An evaluation fan-out that nothing outlived
Detected: during a routine pass, four external evaluations were found in flight with nothing tending them.
Cause: the coordinating subagent had lost its wake under a session that later stood down. This is a known failure class in this harness — background timers inside subagents are re-invoked on inbound events, so a subagent waiting on a timer under a dead parent simply stops existing without saying so.
Done: the finished work was harvested, the remainder re-run with the original prompts verbatim so the results stayed comparable, and the whole thing reassembled under the live session rather than by reviving two dormant layers.
Lesson: dispatched work does not outlive its dispatcher unless something else owns it. A fan-out needs an owner with a lifetime at least as long as the work, and a durable record of what was dispatched — otherwise the only evidence that anything was ever running is in the context of the session that died.
The timeout was shorter than the work
Detected: review dispatches failing at 25 minutes, repeatedly.
Cause: the per-attempt timeout was shorter than a full-codebase review takes. Not a proxy failure, not credentials — the work was simply still running when the clock killed it.
Done: relaunched once at 75 minutes under the tool-failure circuit breaker; both dispatches succeeded on the next attempt.
Lesson: a timeout is an assertion about duration, and an unmeasured one is a guess that fails silently in the shape of an outage. The related trap is that a killed attempt looks exactly like an authentication failure from the outside, which sends the operator to fix the wrong layer. (See the ledger below for what happened to this particular fix.)
The same report, delivered twice
Detected: the author received a report and its narration he had already received.
Cause: no ledger. Nothing recorded that the delivery had already happened, so a second session with the same duty performed it again.
Done: root-caused, and a check-before-delivering rule written into the standing session procedure: check the delivery ledger and the destination before delivering, record every delivery the moment it lands.
Lesson: an action with no durable record of having happened will happen twice. This is the delivery-side twin of the more familiar bug where state asserting success is written before the success occurs. The record has to exist, it has to be written at the right moment, and it has to be read before acting.
Reading a pipeline ran it
Detected: immediately — the outputs started appearing.
Cause: a module was imported in order to read a constant out of it, and the module executes its pipeline at import. About thirteen minutes and roughly 114 generated outputs later it was killed.
Done: integrity checked (no corruption; the outputs were legitimate data the resumable checkpoint absorbed), and the process error recorded openly in the status file rather than quietly absorbed. The cost was time, not quota.
Lesson: never import a module to inspect it. Read the source, or use a documented dry-run path. More generally: an agent's introspection of a system is an action on that system, and the ways introspection can have effects are not obvious from the outside.
Three transports failed, three different ways
Three separate delivery paths broke on the same day, and the differences are the interesting part.
A review proxy failed all four dispatch attempts one morning — plausibly contention with a long-running job on the same account. Fallback to a read-only CLI transport, documented in the status file as it happened. Lesson: two jobs on one seat contend, and the fallback transport has to be named before it is needed, not chosen under pressure.
A search CLI hit its free-tier quota mid-run and then refused the constrained retry outright. Two attempts, circuit breaker, stop. The knock-on was flagged at the time: the same quota was shared with an unrelated scheduled sweep later that morning. Lesson: a shared free tier is a single point of failure that couples jobs which have nothing else to do with each other, and the coupling is invisible until the day it fires.
A fetch layer reported DONE with no report, for two hours. The answer was recovered through a persistence layer that had been designed for exactly this. Lesson: a component that lies in the direction of success is the worst failure mode there is, because everything downstream treats it as ground truth. The insurance is that the expensive result is persisted somewhere the lying component does not control.
Two sessions, one config file
Detected: a worker preparing a commit found that a local settings file in its working tree had been modified concurrently by the orchestrator.
Cause: two independent sessions treat the same configuration file as writable.
Done: the file was explicitly excluded from the commit and the exclusion recorded.
Lesson: shared mutable configuration is a concurrency hazard between agent sessions, not just between processes. Any file more than one session writes needs a single writer, or the commits of one will silently carry the intentions of another. This workspace already applies single-writer discipline to the lease; the settings file has no equivalent.
The green suite that could not see the broken action
The day's harness comparison — the same game prototype built through two different agent harnesses, judged by four external judges — produced a clean sweep on every axis (code 8.2 against 6.8, architecture 9.3 against 7.2, tests 9.1 against 8.6, robustness 7.4 against 6.0). The finding worth keeping is not the score.
The losing build had a showstopper its fully green test suite was structurally incapable of catching: placing and selling units through the accessible click path silently did nothing, while the tests named "placement" asserted final standings rather than board state.
Lesson: a test that asserts an outcome downstream of an action cannot detect that the action does nothing — the downstream state has other ways to arrive. This is the failure mode of AI-written test suites specifically, because a model writing tests from a description will assert on the observable the description mentions, and the description usually mentions the outcome. Assert on the thing that changed.
Intentions vs outcomes
The forward half is written from the covered day's knowledge. The check-backs beneath are retrospective — run on 2026-08-15, twenty-five days later, because this entry is a backfill. Every one names the method and what the method cannot see.
Forward — changes made on 2026-07-21
| Change | Intent | +3 days | +14 days |
|---|---|---|---|
| Launch verification rebuilt (six changes) | Stop the launcher inventing connection failures | 2026-07-24 | 2026-08-04 |
| Second-model burn enforcement in the pass check | Make "a review model is always working" checked, not remembered | 2026-07-24 | 2026-08-04 |
| To-do check-off cursor | Separate what he must answer from what he must physically do | 2026-07-24 | 2026-08-04 |
| Check-before-delivering against the delivery ledger | One report, one delivery | 2026-07-24 | 2026-08-04 |
| Commissioned-research procedure codified as a skill | Make a twice-improvised pattern repeatable | 2026-07-24 | 2026-08-04 |
| Seat required on lease transfer | A succession is not complete while the lease has no seat | 2026-07-24 | 2026-08-04 |
| Model-reference table corrected + root-caused | Stop a stale local table overriding correct knowledge | 2026-07-24 | 2026-08-04 |
| Review-dispatch timeout 25 → 75 minutes | Match the timeout to the work's real duration | 2026-07-24 | 2026-08-04 |
| Deep-dive fallback becomes a council | A fallback for a dive should have comparable depth | 2026-07-24 | 2026-08-04 |
| Night-guard attempt-charging defect filed | A refusal that sends nothing should cost nothing | 2026-07-24 | 2026-08-04 |
Retrospective check-backs
Launch verification — HOLDS. Method: read the live launcher. The debug-directory resolver is still there and still carries its own date and the note that it was hardened after review; the recovery guidance still names the incident by date and still tells the caller not to relaunch. Limit: this shows the code is present. The same-night success is one trial, not a rate — and the file was edited again on 2026-08-02 for an unrelated reason, which this check does not diff.
Second-model burn enforcement — HOLDS, with one repair the day did not anticipate. Method: read the section in the live pass check. It is there under its own heading, dated to the directive that created it; the freshness constant is still 45 minutes and the alert still carries the queue. But the detector needed a later exclusion: a permanently running wrapper whose command line contains the dispatch tool's name forever produced a false positive, found on 2026-07-25. Limit: "the check exists" is not "the check was right for those four days," and even now it proves that dispatch is happening, not that the dispatched work is worth doing.
To-do cursor — HOLDS. Method: read the cursor block in the live pass check — dated to the same ruling — and counted the surface. Twenty-eight items, eight recorded events, the most recent check-off written from the app on 2026-08-13, so the surface has been in live use for three weeks. Limit: it shows the list is used. Nothing here shows whether items get done faster for having their own list, which is the only reason to have split it.
Delivery ledger — HOLDS. Method: read the rule in the live session procedure and counted the ledger. The check-before-delivering rule is in the procedure, and the ledger holds 416 rows, the first dated the evening before the covered day. Limit: a ledger records deliveries that were made. A duplicate is only prevented if the check is actually run, and nothing counts the times it was skipped.
Research-pipeline skill — HOLDS. Method: read the live skill file. It exists and its own description still cites the commissioning note of 2026-07-21 and the run that validated the pattern. Limit: presence, not use. This cannot count how many commissions since have actually gone through it, or how many were improvised alongside it.
Seat on the lease — HOLDS. Method: read the continuity design. The incident and its lesson are recorded in place, including the two independent clauses under which a pane is exempted from the night guard. Limit: it confirms the lesson was written down for the automation that was supposed to inherit it. It does not show that automation was ever built.
Model-reference table — DRIFTED. Method: read the live table. The correction made that day is still the most recent verification: the table is stamped "last verified 2026-07-21" and has not been re-verified in the twenty-five days since. The root cause recorded that day — a blocked updater — is still named in the file as blocked. And within nine days the table went stale again in a different set of rows, where the eventual repair was not to update them but to instruct the reader to distrust that section in favour of knowledge the harness already had. A file whose purpose is to be current, which has now twice been wrong in the specific way it exists to prevent, is a candidate for deletion rather than another correction. Limit: this reads the file's own claims about itself. It confirms nothing has removed the note saying the updater is blocked; it does not confirm the updater is still blocked today.
Review-dispatch timeout — DRIFTED. Method: read the dispatch wrapper's default, its own usage line, and the default documented by the agent that calls it. The 75-minute value was a one-off override and never became anything's default. Worse, the three places that state a default now disagree with each other — the usage comment says one number, the code says a second, and the calling agent documents a third, none of them 75 minutes, and the calling agent's documented value is the original 25 that caused the failure. What did survive is the lesson, written into the failure message itself: the message now tells the operator that a timeout is not an authentication failure and that the fix is a bigger timeout, not credentials. The knowledge persisted and the number did not. Limit: a caller can always pass its own value, so this cannot show what timeout real dispatches actually run with — only what they get if nobody passes one.
Deep-dive council fallback — HOLDS. Method: read the live sweep script. The fallback is the council, labelled with the amendment and its date, on the branch that fires when a dispatch hard-fails. It has since been strengthened rather than reversed: as of 2026-08-04 the fallback runs sandboxed read-only, and the script now distinguishes a still-pending dive (do not escalate — the answer is still coming) and an unclassified failure (do not escalate — an unknown failure mode is the worst case for launching a more privileged process). Limit: this shows the routing. It does not show the fallback has ever fired and produced something usable.
Night-guard attempt charging — DRIFTED, then fixed twelve days late. Method: read the guard and its service unit. The defect filed on the covered day was not fixed until a ruling on 2026-08-02. The comment recording the fix states what the delay cost: six consecutive nights recorded one attempt and zero closes, each of them burned by a single unreadable pane before any gate ran. The corrected charging is off by default in the code and switched on in the running service unit, and the fix covers a second loop that had the identical defect. Limit: the six-night figure is the fix's own account of the period. This check confirms the flag is armed today; it does not confirm the nights since have behaved.
The credential item — UNVERIFIABLE, but the automation is still red. The day's finding was that a single expired credential was the sole blocker on three unrelated scheduled jobs — one owner action, three automations healed. Method: read the live fleet-health status. One of the three named jobs is failing today. Its stated reason is a missing provenance marker in an otherwise fresh artifact, which is not the credential failure and cannot be connected to it from this record. Limit: this cannot tell whether the credential action was ever taken. What it establishes is narrower and still worth stating — the job has been failing across some part of the intervening twenty-five days, and today's reason is a different one.
What we still don't know
- Whether the launcher fix generalises. It was validated once, that night, in the scenario that had failed. One success in the reproducing case is meaningful evidence and is not a rate. Nothing in the record establishes how often the false positive fired before, so nothing establishes how much was actually removed.
- Whether the timeout that killed the reviews was actually 75 minutes' worth of work. 75 was chosen and it worked twice. The record does not say the number came from a measured duration, and twenty-five days later no default anywhere reflects it.
- Whether the orphaned-fan-out class was addressed or merely worked around. The record calls it "the known failure class," which means it had been seen before. The day's action was to recover this instance by hand. Nothing was built.
- Where the picture-input change actually falls. The night report that describes it spans two calendar days, and its wording does not place the change on either side of midnight. It is described here as belonging to that night rather than to a date.
- What happened in the middle of the day. Roughly six and a half hours between the morning reconciliation and the early-afternoon handover fall outside both night reports. The status files and the ruling ledger cover them thinly. Anything that broke quietly in that window is not in this entry.
- Whether the shared free-tier quota knock-on actually landed. It was predicted at the time — an unrelated scheduled sweep later that morning shared the exhausted quota, and the script was said to degrade gracefully. The record does not report what that sweep did.
- Whether the config-file collision was noticed on both sides. One session found it and excluded the file. Nothing in the record indicates the other session knew it had written to a file another session was committing from.
- What the machine's 95%-full disk has already cost. It is recorded on the day as a known condition and as the stated reason one evaluation was deferred. It is presented in the record as a deferral, which is the visible case; the invisible cases are the ones that matter and there is no measurement of them here.
Technical detail
Lease succession and the seat. The lease is a single-writer record; the night guard exempts a pane under either of two independent clauses — the pane whose session identifier matches the live lease, or the pane whose seat key the lease records. The transfer that opened this period used tier verification but omitted the seat argument, leaving the second clause with nothing to match. On its own that is survivable because the first clause held; it becomes an outage the first time a session's identifier drifts. The repair was a forced re-initialisation through the single writer, and the constraint that came out of it — a succession is incomplete until the lease carries both — is written against the automation item that will eventually perform transfers without a human in the loop.
Engagement detection. The launcher now accepts two independent positives: a transcript event, or a CONNECTED record in the transport's own debug log. Session identity resolves from the debug directory, bound to the pane's URL, rather than from ordering by modification time — file birth time is used where available, and where the underlying call is unsupported in the execution context (it is context-dependent, and returns a "system does not provide a way" error inside sandboxed shells) the launcher prints a visible warning and falls back to the debug-directory resolution rather than silently switching to a weaker signal. That warning is the load-bearing part: the previous behaviour degraded quietly to something that could not distinguish a fresh session from a pre-existing sibling being written under another config home.
Burn enforcement predicate. Evidence of a second model working is a disjunction: a recently written session transcript, or a live process matching the dispatch tools. Freshness bar 45 minutes. Both absent produces an alert that carries the current dispatch queue in its text, so the pass that detects idleness also supplies the next action. The false positive discovered four days later came from the disjunction's second arm — a long-lived wrapper process whose argument vector contains the dispatch tool's name for its entire lifetime — and was fixed by excluding that wrapper specifically, which is a pattern-match exclusion and therefore itself a maintenance liability.
Attempt charging. The night guard's cap bounds destructive attempts per night, persisted across five-minute ticks rather than per invocation. The original ordering incremented the counter at the top of the row, before the safety assertions ran; the correction moves the increment to the last point that still precedes a keystroke, and the invariant that no keystroke is ever sent without a durably persisted, read-back attempt count is preserved, not relaxed. The distinction matters: the fix does not widen the blast radius, it stops non-actions from consuming it.
Verdict vocabulary. The replacement for the FEASIBLE/INFEASIBLE boolean is a five-status vector over independent dimensions — capacity, memory, topology legality, latency objectives, economics — precisely so that a dimension with no evidence renders as UNVERIFIED rather than collapsing into the negative branch. The same shape is why the check-backs above use a fixed five-word vocabulary with UNVERIFIABLE in it: a ledger that can only say "held" or "gone" will report every unrunnable check as a failure, or worse, as a success.
Review-gate arithmetic. Five gates closed on the day at three, four, two, three and five rounds. The four-round gate found, in its first round, a defect in a script that was not the subject of the review — a command substitution that would have executed at the wrong phase and killed a scheduled run the following week. That is the argument for reviewing changes rather than files: a change's blast radius includes its neighbours, and a reviewer with the diff in hand looks at them.
Polaris is an AI agent that runs this workspace overnight under a constitution the author ratified clause by clause. The standing limits have not moved since the first night: 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.