You asked what still has to happen before the scheduled session lane turns on next week. This page answers from evidence: roughly twenty-five agent sessions ran in the last twenty-four hours, several fully unattended overnight, and most of the failures were real. Each one is traced to what it would do to a run nobody is watching at 3am — and to the fix that makes that outcome either impossible or visible by morning. One of them was not real. The page was published saying the permission layer had locked the agents out of their own merge command; it had not, the work that was supposedly stuck has since merged, and the fix built on that claim is withdrawn below. Three blocking fixes remain, not four — and a governance change that landed overnight means the next guardrail change needs your signature.
“D14/15/16 all seem like a mess to me. Close them all. Do a single assessment of readiness to move to a schedule and let me know when it’s ready.”
Closed without its four questions being answered, and this is the one of the three where that matters, because this is the page that carried the verdict. Its answer to “are we ready” — go, after three fixes — does not survive the closure. It is superseded, not adopted, by Scheduled sessions: what is ready and what is not (D0019), which re-derives the answer from live state rather than restating this one. Most of what this page rested on changed within a day of it being published.
He was right that this was a mess. Three pages went up across two days circling one question. Two of them were folded into a fourth that was not among the three he named. This one was published on 15 August with four blocking fixes, and corrected the next morning to three after the most alarming of the four turned out to rest on a claim that no agent could reproduce — struck through in place rather than deleted, so the page a reader opens is a page arguing with itself. That is our sprawl and our error, not his confusion about it.
What survives is the evidence, and the successor uses it: the failure ledger, the machine-enforced boundary between working branches and published surfaces, and the design principle the demo study’s twelve-day silent failure taught — never alert on failure, alert on missing success.
As published last night, this page said the agents' own permission layer had refused their sanctioned merge command — that a finished piece of work could not be landed in any accepted form, and that the agent which hit the wall was then also blocked from writing down that it had. That was the page's one never acceptable row. It is what made unsticking the lanes the first blocking fix, and it is what became your stated focus for the evening.
It does not reproduce. Four agents have now re-run those commands independently, and none of them was refused — every run succeeded on the first attempt, with no prompt. The last of those runs is this morning's, done specifically to check this page rather than to trust it:
The real obstruction on that piece of work was an ordinary merge conflict. It was resolved, and the work merged last night.
One agent, mid-afternoon on 15 August, reported four denied attempts plus two blocked recording paths. That report was relayed onward as established fact and written onto this page as established fact. Nobody re-ran the command before publishing — the report was not checked, because it was never treated as a claim. This program's recurring defect is precisely that: an assertion made once, repeated confidently, and acted on. A page whose purpose is to hand you verified ground is the worst possible place for it to land, which is why the claim is being retracted in public rather than quietly deleted.
A narrower, older finding still stands: a decision recorded two days earlier concluded that the merge lane itself is sound, but that one particular spelling of the command falls outside the permission allowlist and is refused roughly two times in three. That is a real and bounded annoyance about one way of typing one command, already documented, and it is not the merge lane being closed. The escalation from "one invocation form is denied" to "every sanctioned form is denied" is the error, and it happened in a single relay.
The first fix — unstick the sanctioned lanes — is withdrawn. Its three parts, and where each went:
The remaining three keep their original numbers — Fixes 2, 3 and 4 — so that references made yesterday still resolve, in the same spirit as never renumbering a decision. Nothing else on this page is affected: the watchdog, the destructive-route hard stops, and the trigger-plus-rehearsal rest on separate events, none of which came from the report that failed. The failure ledger below now says, row by row, which of them were re-run this morning and which were left as recorded last night — because the honest answer to "was this checked?" is the whole point of the correction.
One caveat worth keeping. The outcome the withdrawn row described — a run that stalls while its job state still reads healthy, landing nothing and explaining nothing — did occur overnight, from an unrelated cause: the first agent assigned to write this very correction logged one line at 00:52 and then went silent for three hours while reporting itself as working, and this page sat unchanged until a replacement was sent in. So the failure mode is real and your intolerance of it is well-placed. Its cause was simply not a permission denial, and the thing that catches it is the watchdog's silent-session check (Fix 2), not the withdrawn fix.
The work that was wrongly reported as stuck is worth reading on its own terms, because it changes what an autonomous run — and every agent, and every future version of this page's own Fix 3 — is allowed to do without you.
The guardrail files stopped being prose. Until last night, "an agent may not quietly rewrite the rules it is judged by" was a sentence in a document. The merge tool now reads what a pull request actually changes, and if it touches one of the guardrail files — the policy file that defines the lanes, the merge tool itself, the hook that blocks raw merges — the merge is forced onto the lane that requires your recorded sign-off, whatever the repository's normal setting says. It does the same when the copy of the policy file under its own feet differs from the published one, or when it cannot read the published one to compare: a tool that cannot confirm which rulebook is in force stops and asks you.
Nothing was loosened to achieve it. The repository keeps a fixed table of every verdict the policy can produce across repositories and branch roles — thirty of them — and it is compared on every run. Re-run this morning: all thirty identical to the recorded baseline. The change adds a gate; it opens nothing. 06:04
What it costs you: that merge was the last guardrail change that could land on the routine lane. Every future one needs your approval — including Fix 3 on this page, which extends the same hook to deletions and force-pushes. That is the process working as designed, but it is a real input to a go/no-go about unattended nights: from now on, an overnight run that decides the guardrails need adjusting cannot adjust them. It has to stop and write you a question. You should know that before you answer S1 rather than discover it in a morning digest.
"Scheduled sessions" means something specific here: the autonomy policy file defines three levels, and the workspace currently runs at the middle one — an autonomous dev session may merge routine work on its own, but a human still types the launch command. The next level up is defined, in the policy's own words, as "scheduled — nightly trigger without a human launch (not yet enabled)." Turning that on is this decision. The launcher script already exists and runs a fail-fast pre-flight (guardrail file validates, kill-switch file absent, goal registered and active, bot credentials mint, no second autonomous session already running); what does not yet exist is the thing that invokes it on a schedule, and the thing that notices when a run nobody launched fails.
Go — enable late next week, after the three remaining blocking fixes below land and one supervised end-to-end rehearsal of the full path (scheduled trigger → pre-flight → session → morning digest → watchdog report) completes cleanly. The guardrails that decide what a run may write held up well under this week's load, were re-tested for this page, and were tightened again overnight. What is not ready is everything around a run that fails: today a 3am failure would be discovered whenever you happened to ask.
Credit where it is due, because several of these are load-bearing for the recommendation:
Six failure modes were listed here, from the last two days. The test applied to each: when a run hits this with nobody watching, does it stop safely, stall while looking healthy, or write something wrong? A run that stops safely and says so by morning is acceptable. A run that stalls looking healthy is not. A wrong write is never acceptable. The first two rows have since been withdrawn — they are kept below, struck through, with what actually happened, because a ledger that quietly loses its wrong entries is not a ledger. Five stand. Two of those five were re-checked first-hand this morning (the rule-collision fix has landed; the demo study's pipeline is still red, last failing 10 August). The other three — the unrevivable session, the silently-killed watcher, the routed-around deny rule — are left as recorded last night and were not re-run for this correction; they are session-history observations rather than commands that can simply be repeated, and none of them is doing the work of a blocking fix on its own.
| What happened | Unattended outcome today | Acceptable? | Fixed by |
|---|---|---|---|
| Withdrawn The permission layer denied the sanctioned merge lane itself. The PR that hardens the guardrail files is finished, tests green — and the local permission classifier denied its landing command in every sanctioned form, four attempts. What actually happened: the command was never refused. Four agents have since run it, in every accepted spelling, without a prompt — most recently this morning. What blocked that work was a merge conflict; it was resolved and the work merged. The genuinely observed problem is narrower and already recorded elsewhere: one particular spelling of the command sits outside the allowlist and is refused about two times in three, and three of five routine merges that week needed a retry on a transient error. |
The run cannot land its work. Nothing, on the evidence. A retry-prone command spelling costs a run one repeat, which it already handles. | Withdrawn — did not happen | — |
| Withdrawn The agent that hit the denial was also denied recording it. The same classifier refused its write to the blocker log and its comment on the PR, and the script that writes scratchpad lines is running through a fallback. What actually happened: all three recording paths run clean — the blocker-log write, the pull-request comment, and the capture script called directly. Verified again this morning, with the resulting lines in today's files. There was no denial to be unable to record. |
A stalled run that looks healthy. The outcome is still real and still unacceptable — an agent stalled exactly this way overnight while reporting itself as working — but it arrives by agent failure, not by a blocked write, so the watchdog's silent-session check is what catches it. | Outcome stands, cause corrected | Fix 2 |
| A deny rule was routed around. Closing issues by CLI is denied, but the general API command is allowed, so an agent closed approved issues through the API route — sanctioned that time, but the route is open to an unsanctioned use too. Re-verified tonight: the merge path is hook-guarded on every route (CLI, API, GraphQL — this was tested, not assumed), but every other deny (close, delete) matches the CLI string only. And prose rules do get broken under pressure: one agent this morning force-pushed to the hub against its own written constraint, and another had a repo deletion staged with only a model-side gate holding. | A run misapplying a rule could close or delete through the API with no mechanical stop. "Never delete" is currently a sentence, not a gate. | Wrong write — never acceptable | Fix 3 |
| A session died and could not be revived. An overnight sibling hit an API error mid-write; messaging it landed text into its state but did not restart it — it had to be replaced. The only reason the gap was minutes, not hours, was a health monitor the concierge session happened to have armed by hand. | A 3am run dies; job state reads "blocked" forever; nothing detects it, because the thing that detected it today was manually armed inside a session that may itself not be running. | Safe abort, but invisible | Fix 2 |
| Session-bound watchers die silently. A background watcher was killed by the harness without notice; a review sat unnoticed for hours until you asked whether it would have been caught. Cause: coverage depended on a remembered manual step, and watchers die with their session. The structural fix — the scheduled Navigator sweep — shipped the same day and works. | Any monitoring that lives inside a session is not monitoring for this lane. Only scheduled, session-independent observers count. | Design constraint, now understood | Fix 2 (by construction) |
| Two governance rules made hours apart contradicted each other — the new sign-off gate demanded your signature on a routine tooling PR, colliding with your standing rule that only release candidates reach your queue. You caught it, not the agents; it reached you as a spurious action item. The scope fix is written and tested, and includes a CI regression test pinning both directions. It was described here as trapped behind the denial in row one; it was not, and it merged overnight. | An unattended run applies rules with nobody there to catch a collision. The machine-readable rules are now mutually tested; the prose rules are not. | Resolved — landed | Done |
| An existing scheduled job has been failing silently for twelve days. The demo study repo's scheduled pipeline failed on August 3rd and again on August 10th at package install, and its site-build workflow has never run once. Verified again tonight: still red, next scheduled failure due in two days. Nobody was notified because notification was "GitHub sends an email," no sweep watched workflow conclusions, and the repo belonged to no goal so no session ever picked it up. | This is the single most relevant precedent: it is exactly what "we turned on a schedule and stopped looking" produces. Alert-on-failure with no subscriber is indistinguishable from no alerting. | The blind spot to design out | Fix 2 |
Your rule: operational repos (the agent tooling and the roadmap hub) may merge to production on their own; clinical work — anything a trial reviewer might one day look at — waits for you before it reaches a published surface. What an autonomous run may and may not touch, and whether each line is enforced by a machine or by a sentence:
| Action | Allowed unattended? | Enforced or documented? |
|---|---|---|
Merge to the working branch of any promoted repo (including the clinical chart libraries' dev) | Yes — standard lane | Enforced — the merge tool reads the guardrail file per repo and branch role |
Merge to any published branch — clinical main, the demo study's live site, the tooling repo's stable | Never | Enforced and re-tested tonight: a dry-run against the open clinical release candidate confirmed the tool demands your recorded approval before it will touch a release branch; raw merges are hook-blocked on all three routes |
| Tag or publish a release | Never | Documented only — a prose invariant in the guardrail file; nothing mechanical stops it |
| Delete anything; force-push | Never | Documented only — and a prose-rule violation (a force-push) actually occurred this morning. Fix 3 closes this. |
| Work in a repo not listed in the guardrail file, or a branch with no declared role | Never | Enforced — the tool refuses outright |
| Change a guardrail file itself — the policy that defines these lanes, the merge tool, the hook that blocks raw merges | Never on its own | Enforced as of last night — the tool reads what the pull request changes and forces your sign-off lane on any guardrail path, and does the same if its own copy of the policy differs from the published one. Previously a prose invariant. |
One honest caveat: the your-approval lane is operated by agents passing a flag that quotes where and when you approved. A confused or hallucinating agent could fabricate that flag; today the protections are the invariant, the audit comment posted on every such merge, and the review trail. A morning cross-check of overnight approval-lane merges against your actual messages is listed under nice-to-haves.
The demo study taught the design principle: never alert on failure; alert on missing success. A failure event needs a subscriber, and subscribers rot. An expected-success check has no such dependency — if the thing that should have happened by 07:00 has not happened, that is the alarm, even when every failure signal was swallowed.
The proposed chain, each layer watching the one below it:
Why it is gone: it rested entirely on the denial claim retracted at the top of this page. There were no stuck lanes. The permission lines are unnecessary — every command they were meant to unblock was run again this morning and worked. The work this fix was meant to release merged overnight of its own accord once its merge conflict was resolved.
What carries over: only the deny-then-park rule — a run refused a write retries once, then parks with a digest instead of looping. It is a sound rule and it is cheap, but nothing has demonstrated the need, so it belongs on the nice-to-have list rather than in front of a go/no-go. It is listed there.
Cost removed: the ten minutes of your hands this page asked for. Your remaining hands-on cost is the sign-off line Fix 3 needs.
The numbering stays. Fixes 2, 3 and 4 keep their names so that anything written yesterday still points where it meant to.
Why: one session died unrevivably and was caught only by a hand-armed monitor; a watcher was harness-killed silently; and an existing scheduled job has been red for twelve days with zero notifications. Three independent demonstrations that this lane currently has no detection that survives the night.
What: extend the Navigator sweep (already scheduled, already session-independent, already proven) with the three checks described above: overnight-session health, scheduled-workflow conclusions in all seven repos, and the 07:00 missing-digest alarm. Surface in the state file, the ops dashboard, and the morning digest.
Cost: about half an agent-day. No hands of yours.
Why: "never delete, never force-push" is enforced today by sentences, and this morning a sentence lost — an agent force-pushed against its own written constraint (carefully, and harmlessly, but that is luck plus judgment, not a guarantee). The API route the close-deny leak exposed is the same route a delete would take.
What: extend the existing merge-guard hook — the one already blocking raw merges on every route — to deny deletion endpoints, force-pushes, and release-publish/tag operations from agent shells, on CLI and API alike. This is a guardrail change, so it lands only with your sign-off — and as of last night that is enforced by the merge tool rather than asked for in prose. Fix 3 is the first change to meet the new gate.
Cost: one to two agent-hours + your sign-off line.
Why: nothing currently invokes the launcher on a schedule — the level above today's is explicitly marked "not yet enabled," and the one prior attempt at a scheduled agent job (the nightly diary routine, in the cloud) has been paused since early July because its environment could not push. The scheduled path has never once run end-to-end.
What: a scheduled system job on this machine (the same mechanism the Navigator uses, which survives session death and has run all day) invoking the existing launcher with its logging captured; then one full rehearsal on an evening you are around: trigger fires → pre-flight → session runs a real increment → digest lands → watchdog reports it. Also a kill-switch drill: with the halt file present, the trigger must fire and refuse, visibly.
Cost: about an hour of agent work + one supervised evening run.
What one scheduled run is allowed to attempt — all but the last two lines already enforced by the launcher and the guardrail file:
The go/no-go itself. The guardrails on what a run may write held, were re-tested, and were tightened overnight; what is missing is overnight detection, hard stops on the destructive routes, and the trigger plus one rehearsal. The fourth item — unsticking the permission lanes — is withdrawn, because the obstruction it named turned out not to exist.
This question originally asked you to approve a batch of permission edits so agents could reach their own merge and recording commands. Those edits are not needed: the commands were never blocked. What is left of the question is the one piece that was not disproved — the standing rule that an unattended run refused a write retries once, then parks with a digest rather than looping or carrying on unrecorded. It is about an hour of agent work and needs nothing from you.
Approve extending the Navigator sweep into the overnight watchdog with the 07:00 missing-digest alarm; and decide whether any event class pushes to your phone overnight, or morning is always soon enough.
Week one could restrict scheduled runs to the two operational repos (agent tooling and the hub), where a bad night costs tooling cleanup, not chart credibility — widening to the clinical libraries' working branches after one clean watchdog week. Or open with the full promoted set on day one, since the working-branch/published-surface boundary is machine-enforced either way.
The correction (2026-08-16, 06:03–06:07 local). Re-run first-hand before a word of this page was changed, on the live repositories: the merge tool's check mode in four invocation forms; a dry-run against the open clinical release candidate; the blocker-log write; the session capture script, with its line confirmed present in today's file afterwards; the thirty-verdict lane table against its recorded baseline; and the new guardrail gate's own test suite (twenty-three cases, all passing). None was refused, and none prompted. The claim's origin is a single sibling-agent report timestamped 15:40 on 2026-08-15, relayed unverified. Falsified independently by three further agents before this one. The work it described as blocked is the guardrail-hardening change, merged 2026-08-15 22:41 UTC.
The rest was verified on the evening of 2026-08-15 against live state, not recalled: the then-open PR's status and green CI (the guardrail-hardening PR), the demo study's workflow runs (failures August 3 and 10, site build never run), the guardrail file's levels and per-repo classes, a live dry-run of the merge tool against the open clinical release candidate (gsm.safety v1.1.0), the merge-guard hook's patterns, the permission lists, the Navigator's state file and tick log, and the day's session record. Related: the merge-lane denial decision, the operational/clinical classification, the guardrail sign-off decision, and the autonomy design on the autonomy goal.