Auto-lander dashboard — part 2 (refusal catalogue and post-land)
The second half of the Auto-lander dashboard page: every reason the lander can refuse a branch is one row in a catalogue with a block, advisory or off mode, the merged-tree verify now runs one cheap check, and the project's main folder follows a branch once it lands.
What it is
This is part 2 of the Auto-lander dashboard page. Part 1 covers the live status, where each of your branches is, the land history and the two pause toggles; this page is the rest of the behaviour — the catalogue of every refusal and the modes you can set on it, how the pre-swap verify changed, and what a land does to the folder you keep open beside it.
Where to find it
The dashboard itself is on part 1: the Auto-lander tab in the Dev Pipeline panel. Everything here is what the lander does behind that tab, plus the model of your main project folder after a land.
How it behaves
Every refusal is one row in a catalogue, and you can turn any of them down (2026-09-24). The
auto-lander can refuse a branch for twenty-two reasons — fifteen checked before the merge (a
dependency or lockfile change, a file git itself runs, a mass deletion, an oversized memory doc, a
doubled frontmatter key, the three translation rules, the gate receipt, an override approval, the
guard-lane baseline, the accepted-debt test floor, recently landed work the branch dropped, the AI
PR checklist and the dev-pipeline record) and seven checked right before the swap (syntax breakage,
unresolved conflict markers, the hook-step re-check, the merged-tree verify, the land-content
verify, lost ledger rows, and a branch that came back from a cloud box without the source
commitment its capture should have recorded — the last one joined on 2026-10-07, and it is the one
refusal that a person can also clear by waiting, since the returned-work road finishes that
enrolment by itself). A committed secret is no longer one of them: since 2026-09-23 a daily
scan of everything that reached master reports it instead. Each one has a mode: block (the
reason stops the land — the default for all but three), advisory (the check still runs and its
reason is logged, but the land proceeds) or off (the check does not run).
GET /auto-lander/standards lists every standard with its default, its effective mode and where
that mode comes from; PATCH /auto-lander/standards/<id> with { "mode": "advisory" } (or
block, off, or default to drop your override) flips one, and the whole map is the
landStandardModes setting. Only the machine's own CLI token or the desktop may flip one — an
agent's session token is refused, so no agent can switch off the rule that judges its own branch.
The test floor does not blame a branch for master's newer failures (2026-09-27). Master's list of
known failing tests is refreshed every six hours, while master changes every few minutes, so a test
master broke since the last refresh is not on the list yet. When git shows the list is older than
where a branch started, a failing test in a file the branch never touched counts as master's, and
both the ready tag and the land log name each one. A failure in a file the branch changed — its own
new test included — still blocks.
An emergency environment switch can still force a standard off, never on. A standard an operator
switched off is logged on every attempt it skips, and a standard left at advisory logs its reason
instead of refusing. To go back to the shipped behaviour, set the standard to default or clear
the setting: the defaults reproduce the lander exactly as before — the dev-pipeline record and the
memory-doc cap advisory, the AI PR checklist off, everything else blocking.
The merged-tree verify now runs one cheap check instead of two, and the expensive one is yours to
turn back on (2026-10-07). Of the six checks made right before the swap, one — registry
completeness, which asks whether every script under a scripts/ folder has an entry in its
registry — has to read the whole tree to answer. Because the generated index families match
essentially all of the memory docs, that read fired on very nearly every branch an agent lands. It
is a policy check: a miss reds a generated index and is fixed by declaring the script, so it removes
nothing from your branch.
It now ships off, armed by the mergedTreeVerifyScriptRegistry setting — PATCH /settings/mergedTreeVerifyScriptRegistry with { "value": true } turns it back on. There is no
switch for it in the panel: it is a diagnostic lever rather than a preference, and the panel's
Auto-lander section carries only the controls a person changes day to day, exactly as
landerMasterBuildFreezeEnforced and the other pre-swap knobs have no control either. Its
neighbour dropped paths, which also reads the tree, is deliberately
not behind that setting and stays on: a merge that vanishes files is lost work, and a land that
loses master's code is not a working merge. The standard's own mode (landStandardModes) still
outranks both — setting merged-tree-verify to off stops the whole check regardless, and the
emergency switch still only ever forces a standard off, never on.
After a branch lands, the project's main folder follows it (2026-09-29). Landing moves the main
branch, then brings the project's main folder up to the new version — even when somebody has
committed directly in that folder since the last merge, which used to leave it skipped by every
later land. If the folder holds changes the lander will not overwrite (staged work, or leftovers of
an earlier update that did not finish), it is left on its older files and an inbox card names it:
"folder was left on older files after a change landed". Until the folder is brought up to date,
anything that runs from it — a scheduled script, for example — keeps using the older files, and a
commit made in it as it stands would undo the change. The one exception is the folder Omniscio
itself runs from: while the app is running, some of its files are brought up to date only at the
next launch. The mechanism is the checkout's recorded sync point and its re-proof, rule S114 in
auto-lander-invariants-engine-part1-contract.md.
Bringing that folder up to date after a land is routine, so it is silent (2026-10-05): the
checkout keeper writes an inbox card only when it had to leave files alone, a step failed, or the
outcome is one it does not recognise. Each update is still logged and its old files saved under
Saved Work — rule routine-levelling-is-silent in
lander-lifecycle-e11-checkout-history-contract.md.
Related
- Auto-lander dashboard — the live status, the branch queue and the land history.
Last verified 2026-10-08