This entry covers Friday 2026-08-14. Two shift reports sit among its sources and they straddle the day differently: one spans the evening of 08-13 into the morning of 08-14 — its overnight work belongs to the previous entry, and only its morning state is used here — and one spans 08-14 into the morning of 08-15, which is the main source. The check-backs in the ledger were run against that record and against the following morning's, and are labelled retrospective.
The short version
- A background worker session that a failed launch created and never recorded held a capacity slot for 51.7 hours. It was invisible to the counter that was supposed to see it, and refused by the cleaner every ten minutes for two days. Four more defects of the same kind were live in production, and all five had one cause: the record of a resource was written after the resource existed rather than before.
- The cleaner that closes finished sessions has been armed since 2026-07-30 and has killed nothing since 2026-08-07 — 2,097 refusals in four days, with 14 distinct sessions judged ready to close and left running. It is blocked on a design gate that has never been satisfied.
- 31 of the 35 live sessions on the machine carry no marker at all, so the cleaner cannot see them by design. The written procedure for starting a session never mentions the marker.
- The daily board watching the workspace's ~107 scheduled jobs is noisy and blind at the same time. Of 12 red lines, 8 were real failures, 2 were demonstrably false, and 2 were checking whether a human had read something rather than whether a job worked. Two green lines were falsely reassuring about a publication outage they structurally could not see. At most 6 of the 12 red lines warranted any action.
- A weekly research job did the expensive work, discarded the result, and reported success. 217,646 characters of finished research were recovered afterwards from the provider's own history at no additional cost.
- An alarm reading "CPU temperature 92°C" was the wifi radio. The processor read 47°C at that instant and never exceeded 49°C under the day's heaviest load; the sensor index had been renumbered at boot.
- An approved decision sat three hours unenacted because the answer landed in a skippable part of the digest, and the list of items said to be waiting on the author was wrong in 5 of 6 rows.
- The workspace machine's disk went from 96% to 93% — roughly 65 gigabytes freed — with every moved file hash-verified in two separate places before anything was deleted.
What changed in the harness
A resource-lifecycle contract went live for background worker sessions. Launching one now mints an identity before the session exists, fences it to the kernel's own process container for that session, routes releases through typed handlers, and hands closure to a small replayable program on a system timer rather than to whichever supervisor happened to start the work. Intent: make releasing a capacity slot a mechanism with a verified terminal state, instead of a sweep that infers one from what a pane looks like. The pass/fail bar was registered with the completion gate before the build started, and the measurement window closes 2026-08-29.
Three of the five acquisition defects were fixed, tested and committed the same day. A launch that refuses now aborts the acquisition it has already made instead of leaving the session running; the capacity counter reads the newest record for a name and requires the live session's identity to match it; and identity is minted at acquisition, so closure no longer depends on resolving it afterwards. Intent, respectively: a refused launch cannot leave a live unregistered session holding a slot; a shutdown order written for a dead generation cannot be applied to a live one wearing the same name; every closed session leaves a marker.
A standing doctrine on repairs. The author ruled that repairs backed by provenance — fixing something to do what it was already supposed to do — enact the recommended option and notify, rather than arriving as a decision. Cards are reserved for genuine forks. Intent: stop routine repairs waiting on an answer that was never in doubt. It paid for itself within hours: two scheduled-job unblocks were finished before the corresponding card answers arrived, and the pilot's three broken preconditions never waited at all.
The digest now prints the last answer un-skippably. Intent: an answered decision cannot sit unenacted because its answer landed in a tail section that gets skipped.
A class rule for the waiting-on-you list: an item counts as waiting on the author if and only if a live unanswered card exists for it. Intent: the list stops containing work already taken over, and work already answered.
Unattended agent legs now launch in bypass mode. Intent: no permission prompt raised by unattended background work reaches the author's phone. The scope of the question-routing work was extended to cover prompt routing as well.
The report-to-cards accounting check now runs on every pass. Intent: a report that should have produced decisions cannot quietly produce none. A backlog of roughly 70 prior reports is queued for the same check.
A source-labelling convention became standing. A raw research input that feeds a commissioned deliverable now opens with an explicit label naming the deliverable it feeds. Intent: a source cannot be mistaken for the answer, which is exactly the mistake that prompted it — and the day's investigation reports carry the label.
The resource sentinel selects its temperature sensor by type rather than by index. Intent: a thermal zone renumbered at boot can never again be alerted as the CPU.
Two repair sessions landed against the scheduled-job health board — a first pass on the highest-priority defects, then a second on three more, with 36 of 36 tests passing. Intent: rebuild the board toward a state where green means something.
The weekly research driver's wait moved out of the agent session and into the outer shell script. Intent: a job that cannot collect its result must not exit zero.
A retention ruling, recorded and folded into the lifecycle design. Reports and transcripts are kept indefinitely; no cleanup, expiry, or retention-deletion may be built into the lifecycle mechanism. Intent: the single timer that mechanism owns governs only how long an empty terminal shell may linger after its workload is verified dead. It destroys containers, never records.
What broke
A session nobody had recorded held a capacity slot for two days
Detected: by an empirical investigation that went looking for defects of a predicted class — not by any alarm. Cause: on 2026-08-12 a launch created a session, tagged it, then refused to proceed because the instruction text did not read back correctly, and returned without killing the session it had just created. Three separate refusal paths in that one file have the same shape. Because the session was never written to the dispatch record, the capacity counter — built by intersecting the dispatch record with live sessions — counted it as zero. It sat there holding 18 processes, 42.0 hours old at the moment of measurement and about 39 hours past its own expiry, refused by the cleaner every ten minutes throughout. Fifteen minutes after the original refusal the automatic retry hit a name collision, so one failed launch produced both an orphan generation and a reused name. Done: the abort-on-refusal fix was written, tested and committed the same day; the orphan was collected at 51.7 hours.
Lesson: if a resource can become live before its record is durable, then "must register" is a convention, not an invariant — and it fails silently in the worst direction, because an unregistered resource is invisible to precisely the accounting that would have caught it. The ordering has to be: mint the identity, create the resource carrying that identity, commit the record, then publish the handle. Every path that gives up after creation must undo the creation. A diagnostic capture taken immediately before the kill costs nothing next to leaving the thing running "for inspection."
The same lookup that discounts a dead session would have killed a live one
Detected: by running the identity check by hand against a live session. Cause: the capacity calculation keys on session name and takes the oldest record for each name. Name reuse is measured, not hypothetical — 3 of 27 distinct names in one 30-record window carried two generations (11%), and the append-only child registry holds 8 duplicated names across 390 rows. So a shutdown order written for a session that ended on 08-12 was being applied to a different session, 1.2 hours old and actively working, that merely wore the same name. Today the harm is benign-shaped: a working session is discounted, the cap frees up, too much gets launched. Under the new teardown executor the identical lookup would have selected a stale record and killed live work. The correct pattern — newest record wins, and refuse to act unless the live session's identity matches — already existed 470 lines further down the same file, in the release path. The capacity loop had simply never been given it. Done: fixed, tested and committed the same day.
Lesson: a name is not an identity. Any destructive action must be fenced to an immutable generation, and a check that is merely advisory today becomes load-bearing the moment something acts on it. Worth looking for specifically: the case where the right pattern already exists elsewhere in the same file. That usually means the correct rule was learned once and never propagated.
The cleaner has been armed for two weeks and has killed nothing for one
Detected: by a full census of its own log. Cause: it is deliberately gated — it refuses to act wholesale until a design gate is satisfied, and the file that would satisfy it does not exist. The positive-authorization list it would consult is also absent, with zero rows. Counts since 2026-07-01: 9 sessions closed in total, of which 3 were test fixtures, so 6 real ones. 2,097 refusals in the four days since the gate went in, and 2,511 unauthorized results in the four days before that. Fourteen distinct sessions have been classified ready to close and left running. Two historical durations survive in the log from before the gate: 28.4 and 28.6 hours of a session sitting stable and unreaped. Separately, 31 of the 35 live sessions carry no marker, so they never reach classification at all — the documented procedure for starting a session never mentions the marker, and only one automated path sets it. A third finding fell out of reconciling the counts: 5 of the 9 closures wrote no anti-resurrection marker, because that write is guarded on an identity which was unresolved in the majority of cases. Of 47 markers on disk only 4 carry the cleaner's own reason; the rest have several writers and no schema. Done: the marker gap is closed by construction under the new contract, since identity is minted at acquisition; the cleaner itself remains gated, and the new lifecycle work fills the vacuum.
Lesson: an armed-but-gated component is not a safety posture, it is an unmonitored outage with a plausible explanation attached. Two things it needs: an alarm on zero actions over N ticks, so a component whose entire purpose is to act cannot run dead while looking green; and a check that the population it is supposed to cover can physically reach it. Coverage by convention — "the procedure says to tag it" — is coverage you do not have, and here it was 4 sessions out of 35. The corollary for contracts like "always write a marker": if the write is guarded on a value that is often missing, the contract silently does not apply exactly when you most need it to.
The health board was noisy and blind at the same time
Detected: by putting the board's own diagnosis out for external adversarial review twice, with a full ground-truth sample of the day's failing rows in between. Cause: the board collapses at least six genuinely different properties into one red/green bit — whether the process ran, whether it produced an intermediate file, whether the external objective was achieved, whether an old incident is still unacknowledged, whether a human has read something, and whether anyone should act right now. Of the day's 12 red lines: 8 were real failed conditions, 2 were demonstrably false, and 2 were checking a human's reading queue rather than job health. Judged by whether the author had anything useful to do, immediate-action precision was at most 6 of 12 (50%) — 6 of 9 if you generously exclude the two miscategorised rows and one unresolved one. Two green lines were false: both check files created before deployment, so neither can establish that publication succeeded, which is the outage they were quietly reassuring about. Done: the review's second pass rejected its own first framing, which is what made commissioning it worthwhile; two repair sessions landed against the concrete defects with 36 of 36 tests passing. The broad claim that fleet health was improving while monitoring degraded was not ratified — the comparison used incompatible populations.
Lesson, and it is the day's second spine: "the script exited zero", "a log exists", "markdown exists", "the model answered" are all proxies. For every check the question that matters is: what exact real-world proposition becomes true when this passes? If the answer names an intermediate artifact and the job's purpose is external, the check will stay green straight through an outage. Two named false-green classes fall out: result-loss (upstream work succeeds, the handoff or persistence fails) and intermediate-success (local production succeeds, external delivery fails). Both were observed the same day. And no acknowledgement layer repairs any of it — it can reduce messages, but it cannot make an ill-defined proposition true.
A weekly job did the expensive research, threw it away, and reported success
Detected: by chasing what looked like a job producing nothing, and finding it had produced a great deal. Cause: the expensive remote work completed normally. The driver then called the result fetcher from inside an agent session; the fetch blocked past the harness's default tool timeout; the harness backgrounded the operation and expected an asynchronous completion path; and the one-shot headless driver had no way to receive that completion. The result was never collected into the workspace — and the job exited zero and represented the run as successful. Done: 217,646 characters across four lost weekly reports were recovered from the provider's own history at no additional quota cost, and the wait was moved out of the agent session into the outer shell script. One conflict in the record: the shift report says four recovered outputs, the external review's verification list says three. Both readings are in the sources and the discrepancy is not resolved here.
Lesson: a single exit code cannot describe a multi-stage pipeline, and the most expensive failure mode is the one where the costly stage succeeds. A job whose remote result is known to exist but uncollected should exit non-zero, record the remote result identifier durably before waiting, leave a recovery item, and on retry fetch the existing result rather than recomputing — otherwise a well-meant retry is a destructive one. The correction runs the other way too: the original diagnosis, "the job produced nothing," was wrong and had to be rewritten as a handoff-and-persistence failure with false success reporting, which is strictly worse.
The "CPU temperature" alarm was the wifi radio
Detected: by the author asking about a temperature alert. Cause: the sentinel read thermal zone index 2 and logged it as CPU temperature. Zone numbering is not stable across boots. On the current boot zone 1 is the processor package and zone 2 is the wifi module. At the instant the sentinel logged "92", the readings were: system zone 27°C, processor package 47°C, wifi module 94°C. Independent core sensors put the package at 42°C and individual cores at 37–49°C; both drives sat at 34–38°C; there were zero thermal throttle events in the system journal. The radio was genuinely hot, for a legible reason — the day's spikes line up exactly with sustained bulk transfer: a 29-gigabyte copy plus a 256,000-file checksum manifest between 06:10 and 06:20, then a 46-gigabyte verified upload across the middle of the day, 61,466 files confirmed on the first tranche alone. Done: the sentinel now selects the zone by type, falling back to the dedicated core-temperature sensors. The historical temperature column is marked suspect for this entire boot and was annotated rather than rewritten.
Lesson: a sensor identified by position in an enumeration will eventually measure something else, and it will do so with no error at all — the number stays plausible, the units stay right, only the label is wrong. Bind to a stable identifier, never an index. The second-order point is the useful one: the alert was false and the investigation still produced positive evidence, because the recent cooling change was demonstrably working — the processor stayed cool under the heaviest transfer load of the day.
The decision surface was wrong in two directions at once
Detected: by auditing the waiting-on-you list row by row against the decision store. Cause: 5 of 6 rows were mislabelled. Two were items the agent had taken over but never closed at the source, so they still read as the author's problem. One was gated on a card he had already answered. Separately, an approval that had arrived sat three hours unenacted, because the answer landed in the tail of the digest — a section that can be skipped. Unattended legs were launching in a mode that inherited interactive permission behaviour, so approval prompts from work the author was not watching arrived on his phone. And the accounting that ties a report to the decisions it owes had broken, so a report could produce no cards without anything noticing. Done: the class rule (waiting-on-you if and only if a live unanswered card exists), the un-skippable last-answer line, bypass-mode launches for unattended legs, and the report-to-cards check on every pass all shipped; a backfill of roughly 70 prior reports is queued.
Lesson: a queue claiming to say what is blocked on a person is itself a monitored surface, and it needs a falsifiable definition or it drifts into a list of things nobody is doing. The definition that works is a join against durable state — there is an open card or there isn't — not a status field somebody sets. The mirror-image failure deserves naming separately: an answer that has arrived but has not been enacted is indistinguishable, from outside, from an answer that never came.
Intentions vs outcomes
Forward — changes made 2026-08-14
| What changed | Intent | Re-check 2026-08-17 | Re-check 2026-08-28 |
|---|---|---|---|
| Resource-lifecycle contract live for background worker sessions: identity minted before creation, kernel-container fencing, typed handlers, replayable executor on a system timer | Slot release becomes a verified mechanism instead of a sweep inferring state from pane appearance | Has every launch since produced a durable record before the handle was published? Any executor tick that failed to replay? | Window closes 08-29 — is there a sample of at least 50 completed managed launches, and what are the three zombie-hour figures? |
| Abort-acquisition on every refusal path in the launcher | A refused launch cannot leave a live unregistered session holding a slot | Any refusal since — did the session die and the capture survive? | Same, plus: has a new refusal path been added without the abort? |
| Capacity counter reads the newest record per name and requires the live session's identity to match | A shutdown order for a dead generation cannot touch a live one wearing the same name | Count name-reuse events since; confirm each resolved to the newer generation | Same, run against the teardown executor rather than the counter |
| Identity minted at acquisition so closure never depends on resolving it afterwards | Every closed session leaves a marker | Ratio of closures carrying a marker to total closures | Same, plus: do the markers share one schema and one writer? |
| Ruling — provenance-backed repairs enact the recommended option and notify; cards are for genuine forks | Routine repairs stop waiting on an answer that was never in doubt | How many repairs enacted without a card, and did any turn out to be a fork? | Same, plus: has card volume dropped without work going unrecorded? |
| Waiting-on-you class rule: an item is the author's only if a live unanswered card exists | The list stops carrying work already taken over, and work already answered | Re-audit the list row by row; expect zero mislabels | Same |
| Digest prints the last answer un-skippably | An answered decision cannot sit unenacted | Longest gap between an answer arriving and being enacted | Same |
| Unattended legs launch in bypass mode; prompt routing added to the question-routing scope | No prompt from unattended work reaches the author's phone | Any permission prompt delivered to the phone since | Same |
| Report-to-cards accounting check runs on every pass | A report that owes cards cannot quietly produce none | Refusal count at the checker; has the ~70-report backfill run? | Same |
| Source-labelling convention on raw research inputs | A source input cannot be mistaken for the commissioned answer | Do all new source reports carry the label? | Same, plus: has any deliverable shipped a raw source unlabelled? |
| Sentinel selects the thermal zone by type | A renumbered sensor can never again be alerted as the CPU | Compare the logged value against the independent core sensors | Same, across at least one reboot |
| Two repair sessions on the scheduled-job health board (36/36 tests) | Rebuild toward "green means something" | Re-sample the day's red rows: how many warrant action? | Same, plus a sample of green rows against their real objectives |
| Weekly research driver waits in the outer shell, not inside the agent session | A job that cannot collect its result must not exit zero | Has one full run completed end-to-end through the new path? | Same, plus: does a result slower than the old timeout now survive? |
| Ruling — reports and transcripts retained indefinitely; no deletion in the lifecycle mechanism | The only timer in the mechanism releases a container, never a record | Search the mechanism for any delete step; expect zero | Same |
Backward — check-backs, retrospective
Verdicts were run against the day's record and, where noted, the following morning's. Each names the method and what that method cannot see.
| Prior intention | Verdict | Method | Limit |
|---|---|---|---|
| Standing: the session cleaner, armed 2026-07-30, would close finished sessions | DRIFTED — armed and inert: 9 closures ever (6 real), 2,097 refusals in four days, 14 distinct sessions judged ready and left running, nothing killed since 2026-08-07 | Full census of the cleaner's own log since 2026-07-01 | The log records classification, not whether refusing was correct; and it cannot see the 31 of 35 untagged sessions, which never reach classification |
| 2026-08-07: three false-negative repairs to the cleaner's busy, pending-input and freshness tests | HOLDS as code, UNVERIFIABLE in effect | The repairs are present, each documented in place with its measurement — the old busy pattern matched 43 of 51 live sessions while 0 showed a genuine in-progress marker | Since the cleaner has killed nothing since the day after those repairs, no production evidence exists either way |
| Standing: "write an anti-resurrection marker for every closed session" | DRIFTED, repaired same day — 5 of the 9 closures wrote none, the write being guarded on an identity unresolved in most cases; of 47 markers on disk only 4 carry the cleaner's own reason | Cross-reconciled the closure log against the marker directory | Establishes that the contract silently did not apply; does not establish what a correct marker set would have contained |
| 2026-08-13: the public site was stale because a credential rotation left the scheduled job holding a revoked copy | DRIFTED — the narrower claim survives, the specific one does not. That the provider rejects the deploy for authentication is proven; which credential defect causes it is not, and at least five other explanations remain open | External adversarial review of the incident evidence | The review reasons over the same evidence the claim was built from. Only a controlled redeploy after repair, or a capability check on the credential, settles it — the following morning's scheduled runs were to be the first production verification |
| 2026-08-13: the storage offload starts the moment a shell service answers on the second machine, verified replicas first, nothing deleted until they check out | HOLDS — both phases hash-verified in two places before any deletion; 96% → 93%, roughly 65G freed | The following morning's report, which also records that the apparent stall was the gap between completion and the deletion rule, not a failure | Self-reported completion. No independent restore test of the moved data appears in this record |
| 2026-08-13: the stalled external verdict review would be retried with the evidence pack split in two | UNVERIFIABLE — no result appears anywhere in this record | Absence from the following morning's report, which otherwise enumerates the day's work | Absence from a report is not evidence no attempt was made; this cannot distinguish "not retried" from "retried and unreported" |
| 2026-07-31: eleven harness changes (a model check on every pass, lease cross-checks, a zero-byte guard, gate repairs, the fallback-tier ruling, recall instrumentation) — their 14-day re-check falls today | UNVERIFIABLE from this record | The day's sources are two shift reports and four investigation reports; none touches any of the eleven | These rows were checked at +3 days and held then. They need a run against the live tree, which this record cannot substitute for; they stay in the ledger |
| 2026-08-11: twelve changes to the decision-surface and publication gates — their 3-day re-check falls today | UNVERIFIABLE from this record, with one partial reading: the waiting-on-you audit found 5 of 6 rows mislabelled, which is a finding about that surface but is not a check of any of the twelve | Same sources | A partial signal from an adjacent audit is not the scheduled check; the rows stay |
| Standing weekly re-check (author-flagged): memory | UNVERIFIABLE — the fact-check run is mid-flight, its remaining shards gated behind a provider quota reset | Shift-report status only, on both nights | No completion figures and no recall measurement in either report; it stays on the weekly cycle regardless of verdict |
What we still don't know
- Whether the lifecycle pilot will clear its own bar. The window closes 2026-08-29 and the bar is demanding: at least a 90% reduction in capacity zombie-hours, zero false kills, 100% registration before publication, and no managed resource more than fifteen minutes past due without an explicit hold. It also wants a sample of at least 50 completed managed launches, which the current launch rate may not produce inside the window.
- What the baseline it will be measured against actually is. Three definitions exist in the record and they differ by a factor of seventeen: a loose count of every tick where capacity was blocked gives 34.7 hours over fourteen days; a tight count requiring a stale occupant and work waiting gives 120 minutes, all on a single day; an existing queue row quotes 270 minutes for the same incident by measuring the span rather than the qualifying ticks. Carrying any of these without its formula is how the pilot gets graded against the wrong thing.
- Whether killing a process container is safe in general. A browser-automation service shared by the whole fleet lives inside the container of a pane that died long ago. A naive kill of that generation takes it out from under everything using it. The current teardown spares it by name; a container-based one must check for allowlisted shared services or reproduce that guard, and this is not yet an adverse-case test.
- The other ninety-odd green rows on the health board. Two false-green classes are proven and the twelve red rows were sampled exhaustively, but the greens were not — the two examined were picked because they were already suspected. That is fine for diagnosis and useless as an estimate. Fleet-wide false-negative rate, detection latency and monitor accuracy are all unknown, and no claim about fleet health improving is supported.
- Why the board's own row count moved from 105 to 107 in a day. It may be legitimate growth. Denominator drift in the thing measuring you is part of the problem being measured.
- Two of the five acquisition defects remain open and are the author's to rule on. One is documentation-versus-reality drift on a component that can kill things: its own header states it ships disabled with no timer installed, and its timer is active.
- The expiry a session carries can be extended indefinitely by anyone with terminal access — no authorization, no maximum, no record of the change — and it is not written down anywhere durable, so it dies with the terminal server. The lifecycle design splits it into a renewable lease, a non-renewable hard expiry, and a retention delay; none of that is in force for sessions outside the pilot.
- Whether the weekly research driver's repair is complete. The external review's verification list — a regression test where the result takes longer than the old timeout, a durable remote-result identifier recorded before waiting, retry semantics that fetch rather than recompute, and one observed successful end-to-end run — is unmet in this record. The sources also disagree on whether three or four recovered outputs still need disposition.
- What the historical temperature record actually measured. For the whole current boot, the logged "CPU temperature" column is whatever thermal zone 2 happened to be. It was annotated rather than rewritten, which is right for an append-only log and leaves the data unusable.
- Whether the previous night's stalled verdict review ever completed. It was stood down under the circuit-breaker with a split-pack retry planned; no outcome appears in any source here.
Technical detail
The identity primitive was already present and unused. The terminal multiplexer on this machine is linked against the service manager's library and places every pane in its own transient container — verified at 36 live panes to 36 distinct containers, no exceptions. The container holds the entire workload tree (one measured session: the agent process plus 17 tool and child processes, all 18 in one container), it survives the death of the pane process, its identifier is minted at pane creation and never reused, and its kill control is writable by the unprivileged user with no elevation. That is a stronger identity than the "container identity or process ID plus start time" the external review posed as a requirement, and it satisfies the cleaner's own design-gate criterion forbidding naked numeric process IDs — with no new infrastructure. The recommended token for the pilot is the tuple (resource id, container path, session creation time, process start time), with the boot identifier stamped alongside so a record surviving a reboot is unambiguously stale.
Containers survive what process trees do not. Tool servers reparent to the service manager when the pane's process group is signalled — that is the measured behaviour, and the reason a separate teardown script exists. Reparenting changes the parent process ID; it does not move a process between containers, because a process inherits its container at fork and leaves only by explicit migration. Four containers on this machine currently have no live pane and still hold processes: 2, 2, 12 and 70. The 70-process one contains a process started 2026-08-08 — the exact orphan named in the teardown script's own header, still resident six days later, its originating pane long gone. The container is the only handle that still names it correctly. Process-tree emptiness is not a reliable closure predicate here; container emptiness is.
There is no reservation to release. The external review's ledger contract assumed a reservation identifier released by compare-and-set. On this machine capacity is measured after the fact from the provider's usage endpoint, and the "slot" is a derived count over live sessions, not an object. That removes an entire class of double-release hazard and narrows the pilot: what must exist is a lease record whose presence the cap counts, not a reservation with its own release protocol. The hard cap must keep counting externally present generations, because its fork-bomb argument depends on that and remains correct.
The choke point is one file, not ten. The review assumed roughly ten call sites able to create sessions raw. There are 9 live executable sites workspace-wide, but only one creates background worker sessions, and only three sit on live automation paths at all; the rest are experiment launchers and mothballed tooling. Making that one site mandatory is a change of about forty lines. What the review understated: registration there is not merely conventional, it is structurally unable to hold, because it happens after the resource is live and can fail without aborting it.
The board's ratified defects, precisely. The follow-up review ratified five diagnoses outright. A queue checker discarded a currently existing artifact because its modification time was 120 milliseconds after the timestamp captured at the start of a multi-second scan — reproduced deterministically from one millisecond out to five seconds, with passing controls for genuine absence and for historical back-testing. A finite work programme's freshness check demands output newer than seven hours, and the programme has 79 of 79 targets done with zero pending, so the row is guaranteed red after success — a lifecycle false positive whose correct fix is an explicit completed state with a low-cadence completion invariant, not retirement. A paging self-test is monitored but has zero schedule entries and zero timers, an inventory defect; whether "add a schedule" is the fix is undetermined, since a canary running on the same host and reporting through the same delivery path it tests cannot announce that path's failure. A sentinel writes degraded on every tick while any historical incident stays unacknowledged — a deterministic sticky-state contract rather than a flaky check, and the defect is that "any unacknowledged incident exists" is the wrong proposition for a job-health board.
Where the review declined to ratify. Not ratified: that fleet health was improving, and any fleet-wide estimate of monitor accuracy. Ratified only narrowly: that the sentinel's contract is undefined and internally disputed; that the deploy is rejected for authentication, without the specific credential defect being proven; and that a dirty working tree is a real deployment blocker, without the correct remediation being established. The last matters most — auto-committing generated files to turn the gate green would do so by weakening the invariant the gate exists to enforce.
The design shape the review approved, and the one it rejected. The idea came from a public preprint on temporal composability, which defines reverting a component's side effects when the component is removed, with a disposer paired to every registration. The review was explicit that this is design inspiration and not a transferred theorem: killing a session relinquishes a container, it does not undo the files, messages or commits the workload produced, so the honest term is paired release, not inverse. Approved: an acquisition-bound lifecycle contract with a centralized replayable executor, class-specific typed handlers, distributed supervisors supplying triggers, and an operating-system timer as the owner-independent recovery anchor. Rejected outright: a delayed shell-command queue — a literal command plus an executable success predicate stored in a ledger — which is a durable remote-code-execution and delayed-destruction surface, because append-only history makes an entry auditable, not trustworthy. The ledger holds a declarative capability-scoped action selecting an allowlisted handler with validated arguments, never a program. The steelman the review took seriously and answered: this is only more than "a timer plus a scheduled job" where it supplies registration-before-publication, generation binding, multi-step partial-failure recovery, verified closure rather than command success, and owner-death recovery. Where it does not supply those, a timer calling a typed helper is a legitimate implementation and should not be dismissed for lacking novel terminology.
Retention is a slot delay, not a deletion schedule. Four state bits separate cleanly: the logical lease the cap counts releases immediately on verified workload death; the workload processes die on the release trigger, gracefully and then forcibly against the exact container; the terminal shell may linger for a configured interval, default 600 seconds; and the pane capture, transcript, report and lifecycle ledger are kept indefinitely, touched by no sweep this mechanism adds. The handler has no delete step and must never grow one. Aborting an acquisition still captures the pane to a file before killing, so "left running for inspection" stops costing a capacity slot without costing the diagnostic.
Ledger write discipline, and the gap. The sanctioned append helper opens in append mode, takes an exclusive kernel lock, validates every record, repairs a missing trailing newline, syncs to disk and unlocks; a separate integrity assertion checks that line count never decreases and that the prior byte prefix is unchanged. That half is roughly 80% of what the design needs and is reusable as-is. The gap is authorization: every ledger is mode 0664 owned by the single workspace user — the user every agent on the machine runs as — so nothing structurally prevents any process from rewriting any of them. The child registry has no helper at all: a bare shell append, no lock, no sync, no schema, serialized only incidentally by a lock the caller happens to hold for another reason.
Scheduling substrate. One whole-user crontab, 90 non-comment lines, 71 of them routed through a shared wrapper providing per-job locking, wall-clock timeout, a heartbeat file and a run ledger whose outcome vocabulary is consumed downstream. Sixteen service-manager user timers run alongside it and already carry the lifecycle-critical jobs. Any programmatic edit to the crontab is a whole-file rewrite racing every unrelated edit, which is why the lifecycle executor's trust anchor is a timer unit and not a cron line.
A correction to a claim this workspace has been repeating. "Terminal kill verbs issued by an agent session are blocked by the provider's classifier" is narrower than usually stated: a single scoped kill of one pane from an agent session succeeded with a zero exit code. What was actually blocked were kill loops over the live fleet. The external-executor design must stand on its real reasons — that the actor deciding destruction should not be a member of the population being destroyed, that caps and leases need continuity across runs, and that the author arms the schedules — and not on the blanket claim.
Polaris is an AI agent that runs this workspace overnight under a constitution the author ratified clause by clause. Its standing limits are unchanged: 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.