Auto-lander dashboard

What it is

What it is. The Auto-lander dashboard is one place to watch — and lightly control — the auto-lander, the background service that automatically merges branches you've marked ready-to-merge into their main branch, locally, while Omniscio is open (it only ever moves forward and never pushes to a remote). It lives as the Auto-lander tab in the Dev Pipeline panel and brings together three things that used to be scattered: the daemon's live status, where each of your branches is and what it is waiting on, and the history of what it has landed, handed back on a conflict, or set aside.

What it shows.

• Live status — a banner at the top with a coloured dot and a plain-language line for exactly what the auto-lander is doing right now: Idle — watching for ready branches, Landing branches…, Resolving a conflict…, Backing off after a failed land, Conflict needs you, Paused, or off. It updates by itself the moment the daemon's state changes — no refresh.

• Where your branches are — the answer to "where is my branch, and what is it waiting on", grouped by repository. Each watched repo is a card showing whether it's Watching or Paused, and under it one row per branch giving four things in plain English:

  • Where it is — Next to be merged · In line to merge · 2 of 5 · Merging now · Held up · Handed back to you · Set aside — it needs a person.
  • What it is waiting on — one sentence, in the auto-lander's own words (e.g. "new commits landed after it was tagged"). Never a code you have to look up. "Tagged" means marked ready-to-merge — a note the app writes on the branch itself, bound to the exact commit that was verified, so a branch that gains commits afterwards is no longer "ready" for that commit (git-guardrails.md gives the marker's rules). You are not expected to redo that by hand: when a branch you marked ready gains commits or is rebased onto newer work, the auto-lander re-checks and re-tags it for you, and only tells you if that automatic pass genuinely cannot land it (dev-pipeline-panel.md).
  • How long it has been there, and whether that's normal — "12m · about the usual wait", "1h 15m · longer than usual", "3h 20m · much longer than usual". The comparison is against the real measured wait, not a guess: half of all branches merge inside about 15 minutes and three quarters inside 45.
  • Whether anything is needed from you — every row says either Needs you or Nothing needed from you, and the line above the list totals it up ("nothing needs you — these are being handled automatically", or "2 of 7 need you"). Branches that need you are always at the top.

  A row only appears while its branch still exists. A hand-back is a statement about a branch, so once that branch is gone — deleted after an abandoned re-attempt, or merged by something that never recorded the merge — there is nothing left for you to act on and the row retires itself. This is why the count can be lower than a list you saw earlier: it tracks live work, not history. If a branch of yours is genuinely still there and still handed back, it keeps reporting.

  Above the list it says how old the reading is ("as of 3 minutes ago") — so you never mistake a stale answer for a live one. A repo with nothing waiting says so; a repo whose branches couldn't be read says that instead, rather than pretending it's clear. If you have no repositories set up yet, it points you to the Setup tab.

  This section replaced the older Ready & waiting to land list, which showed only branch names and ages. It shows the same branches plus everything above, so there is one branch list here, never two that could disagree.

• Recent activity — the land history. Each row shows the branch, its repo, the outcome (Landed, Conflict, or Couldn't land — a branch the lander set aside instead of landing, e.g. blocked by a safety check, gave up after retries, or already-merged, with the reason), and when. Click a row to expand it: a landed branch shows the detail (e.g. how many commits) and the new base commit, plus a Go to session button that jumps you to the session that produced the branch; a conflict shows what it conflicted against and the exact files, so you can see which subsystem is stuck. A branch that conflicts again after its author pushes new work gets a fresh Conflict row, while the same conflict re-checked on a later cycle is listed once. Older landed rows show no new base commit — it was not recorded until late September 2026 — and neither does a branch someone landed by hand, unless the lander could check that commit itself.

Where to find it

Where it is. Open the Dev Pipeline panel from the sidebar, then pick Auto-lander on the left rail (the tabs are Live · Timing · Auto-lander · QA Fleet · Setup — plus an Agent Board tab if you have the Agent Status Board switched on, which is off by default). The Dev Pipeline panel has SHIPPED (status: 'shipped') — it is visible to everyone, with nothing to enable first. The tab works on the phone / Web Access too, like the rest of the panel.

What you can do from it (quick actions).

• Pause / resume the whole auto-lander — the button in the status banner. Resuming asks you to confirm, and says plainly what turning it on does: from then on every branch you mark ready-to-merge is merged into your main branch on its own, with no further review step. Pausing is one click — it only stops landing, keeps your watched repositories, and is undone by turning it back on. This is the same on/off switch as the Setup tab and Performance settings — flip it in either place and both agree.
• Pause / resume one repository — the button on each repo's card. Pausing a repo leaves it configured but stops the auto-lander from landing its branches; it stays visible (as Paused) so you can resume it. A paused repo simply drops out of the queue. Resuming one repo confirms too, naming that repository.

The confirmation sits on the arming direction on purpose. Until 2026-08-27 it was the other way round — pausing asked and resuming was a single click — which is backwards: pausing is reversible and loses nothing, while arming starts putting unreviewed code on your main branch. The same rule now applies to the master switch in the Setup tab.

On a fresh setup there is usually nothing to arm. The lander turns on with the Dev Pipeline itself — switching that on is the whole setup step, so it is part of the workflow rather than a second thing to discover — which means the click most people make here first is Pause, not Resuming. Nothing is written into your settings on your behalf: that default is derived, it holds until the day you choose either way, and after that your choice sticks.

Both pause actions write the ordinary auto-lander settings (autoLanderEnabled and the per-repo enabled flag) — there's one source of truth, and the dashboard never disagrees with Setup.

From the command line they have two dedicated routes of their own, not the general settings route. Arming the lander is what decides whether something starts moving your master unattended, so those two keys are deliberately refused by PATCH /settings/:key and can only be changed with your full-trust CLI token:

PATCH http://127.0.0.1:19519/auto-lander/arming            {"enabled": false}   # the master switch
PATCH http://127.0.0.1:19519/auto-lander/repos/<projectId> {"enabled": false}   # one repo

What stays in Setup. The heavier configuration — adding or removing repositories, choosing a repo's integration branch, observe-only (dry-run) — lives in the Dev Pipeline panel's Setup tab, not in this tab. The Auto-lander tab is read-mostly monitoring plus the two pause toggles; it deliberately doesn't re-implement the config editor. This split keeps the pipeline's controls in Setup (a panel rule) while the monitoring gets its own home.

QA Fleet (the other tab on this rail). The same left rail carries a QA Fleet tab, and it is the only tab on the rail with no gate — it is there for everyone. It surfaces the ledger Omniscio's own background QA runs write, so the app's own test coverage is something you can look at rather than take on faith. It shows per-feature end-to-end pass/fail, a ranking of the features that have gone longest without being exercised, and a findings trend over time. The open findings are triaged from right there — resolve, dismiss, or reopen — and closing one offers a one-click undo, so a mis-click costs nothing. The tab carries an amber count whenever findings are open, and it refreshes every 30 seconds on its own.

How it behaves

How it works, briefly. The queue reuses the auto-lander's latest process-local observation instead of launching another Git scan whenever the screen reads it. Marking a worktree ready updates that observation and the session's queue position immediately; once shown, the queue notice remains visible until the durable auto-landed message is available to replace it. A failed display update falls back to the next canonical supervisor scan, and Git remains authoritative. "Next up" reflects the daemon's own selection order (a soft hint — the live per-attempt backoff isn't shown). When the machine is busy, the daemon lands in bounded batches and spreads its attention fairly across your watched repos: each landing cycle is capped to a fixed time budget, and any repo the cycle couldn't get to goes first on the next one — so a repo late in your list can't sit unlanded behind busier ones, and no cycle can run long enough to pile up on itself.

Several branches can land in one move (batch landing, on by default). When more than one branch in the same repository is ready, the daemon checks each one exactly as it always has — every guard, veto and scan — and then merges the ones that fit onto your main branch together, in a single move, instead of one at a time. Each branch still gets its own merge commit, its own "landed" record and its own notice to the session that made it, so nothing about a batch shows up as a batch: the queue, the history and the inbox all count branches, never moves. A branch whose tag changed while it waited, or whose files collide with a sibling's, simply drops out of that move with the same outcome it would have had on its own, and is picked up again next cycle. A busy machine automatically lands fewer branches per move. To go back to one branch per move, turn off autoLanderBatchLandingEnabled in Settings (PATCH /settings/autoLanderBatchLandingEnabled from the command line).

Why one branch can sit still while others in the same repo land. That fairness is between repos; inside one repo each branch carries its own hold, and its row always names it — waiting on you, parked behind a safety check, handed back on a conflict, or simply losing its retry race to the branches that landed ahead of it. A branch being passed over is therefore not by itself a broken lander, and that row is the thing to read. It is a known failure class rather than a normal state of affairs, though — a branch that could only ever lose the race, or whose "ready" marker outlived the commit it was bound to, has stranded there before and been fixed — so if a branch is genuinely stuck while its neighbours keep landing, say so rather than waiting it out.

When a branch needs a person and its author is gone. If a branch hits a conflict, a safety check it can't clear, or a failed check, and the session that wrote it has ended, the lander raises an inbox card — "A branch needs a fix and there is nobody left to do it". That card takes itself down as soon as it stops being true: another session is actively working the branch, it is marked ready again, it lands, or the branch is gone — so a stale card can't send a second session into a folder someone is already working in. It stays up while the only session on the branch is paused or finished. (Until 2026-09-25 that self-clear never actually ran on a machine with plain, non-git folders registered as projects — one unreadable folder kept every card up. It now looks only in the repos the lander lands into, so a landed branch's card comes down on the next sweep.) The card also comes down when someone took the branch out of the queue on purpose — its own session blocked it, a rescue branch that carries its work blocked it, or it was marked superseded because its work already reached master another way. A block by a rescue counts only while that rescue has landed or is still marked ready to land; if the rescue was dropped or sent back, the card stays up so the work isn't lost.

Closing a session doesn't stop it fixing its own conflict (2026-09-25). When a branch conflicts, the lander wakes the session that wrote it to rebase and re-mark it — and that now includes a session you closed after reading its report, because its unfinished branch is still its own to land. A session you paused is left alone, and the "nobody left" card above is what you get then. Branches the lander refused for a committed secret or a mass deletion are not conflicts, so a closed author is not reopened for those — you get the card. Start session on it opens an agent that first claims the branch's folder through the app, and stops without changing anything if another session is working there. And a session whose folder is taken over by another one is told so — which folder, which branch, who has it now — the next time it starts, or straight away if it is still running.

A session you start from a lander card counts as working that card's branches (2026-09-24). When you click Start session on one of these cards, the auto-lander treats that session as working the branches the card handed it:

• the "need a hand to finish landing" card;
• the "blocked by a safety check" card;
• the "review to close" card;
• the parked-branches card (its "nobody is working on" rows only).

While that session is open, those branches don't come back on another card, and the auto-lander doesn't start a rescue session of its own on them. This holds even if the session never makes a working folder. Once the session ends or you archive it, the auto-lander handles those branches as usual again.

The tab refreshes itself while it's open (on the daemon's status push, plus a light timer that catches a branch you tag while the daemon is idle) and costs nothing when the tab is closed. Pausing never interrupts a land already in progress — the setting is read on the next cycle, so an in-flight merge finishes safely first.

After a land, your main project folder can show changes you did not make — that is expected, and it is not work. The lander lands by pointing your main branch at the new commit; it deliberately does not touch the folder you keep open next to it. That folder is therefore left sitting behind its own branch, and git status there reports every path those lands touched as a change — a set that grows with each land, and has been measured in the hundreds and once in the thousands. Nothing was staged, nothing is unsaved, and every byte of it is already committed. Do not clear it with a reset or a discard — that is the one genuinely destructive response, and it is aimed at the wrong folder anyway. To clear it, bring that folder up to date with its branch.

When a file a change added really is missing from that folder (since 2026-10-03). Rare, and worth knowing how to read, because it is the one case in this area where the folder is genuinely short something. A change lands by moving your branch pointer; the files follow separately. If that follow-up cannot be applied — most often because an app is running from the folder and rewriting compiled source under it would restart it — you get one inbox card naming the files that are still absent. The hourly folder check retries by itself, and starting the app from that folder puts them back; while the app stays running, files under src/ are deliberately held back, so a card naming a src/ file is expected to outlast one app session. The card is not a drift report and not a call to act: nothing is staged, nothing is unsaved, and it clears itself the moment the files arrive. If the number it gives looks far larger than what you would expect, say so — an earlier version of this check read the wrong side of git and named every file the folder was merely behind on, rather than the ones actually missing.

When the backlog piles up. If a lot of ready branches stack up unlanded, you get one inbox alert once the ready backlog crosses a threshold (default 20 branches across all repos) AND the lander has stopped draining it — either nothing landed for ~5 minutes, or (since 2026-09-04) the lander landed at most 2 branches across its last six passes while ten or more of the waiting branches were held on the lander's own side (not vetoed, not conflicting, not waiting on you). The card names the recorded cause from the lander's own pass — "git reads were killed for box load (12)", "the pass ran out of time before reaching them (30)", or "the git pack index is poisoned and the lander is working around it" — instead of guessing, and it starts one fixer session ("Fix the auto-lander (backlog stuck)") that diagnoses the lander itself with that evidence, at most once every six hours. You do not have to start a session yourself; the card tells you the fixer is running, or why it was not started (switched off, or one ran within the last six hours). (There is no Open Diagnostics button on this card — that button was deliberately removed on 2026-08-18, along with the one on the lander status alert, because it steered people who aren't developers into a raw diagnostics screen.) One card covers every watched repo, it fires once per episode, and it re-arms after the backlog drops back down.

When finished work never reached master. The auto-lander only ever lands a branch you marked ready-to-merge. Work that was finished but never marked — a session that stopped to ask you something and closed itself before you answered, say — is invisible to it, and it stays invisible once the workspace folder is cleaned up, because every other rescue the lander does starts by walking the folders that still exist. Once an hour the lander now checks the branches instead, and if it finds committed work that has no folder left, was never marked ready, and has sat untouched for at least six hours, it raises one inbox card — "Finished work never reached master". The card names each branch with the repository it is in, why it was never landed (never marked, or marked with a status whose session has since ended), how long it has sat, and how many of its commits are not on master. Branches that are only partly merged are counted separately and never listed for rescue, because re-applying work master already has is worse than leaving it; the same goes for leftover machinery branches, which are counted as debris. Anything it deliberately did not judge is counted too, so a quiet card never hides a population it skipped.

The card reports only — it never marks a branch ready, never lands one, and never deletes anything. That is on purpose: "no folder left" cannot tell finished work apart from work someone abandoned half-done, so the decision stays with a person. Its Start session button opens a triage session with the branch list already loaded and an explicit instruction not to mark anything ready without a green check first. One card covers every watched repository, repeat checks update the same card rather than stacking up, and the check skips itself while the machine is busy (it forces itself through after about six hours, so a permanently busy machine can't silence it).

When the git index is lying. A repository's multi-pack-index can end up pointing at a temporary pack file that a slow fetch is still writing; git then reports objects that exist as unreadable. The auto-lander now re-runs such a read with that index switched off, keeps landing, and raises one card — "Auto-lander: the git pack index is poisoned — landing continues with it switched off" — that clears itself once the faults have been quiet for half an hour. Nothing is missing and nothing needs you unless the card keeps coming back for more than an hour, which means the fetch that owns the temp pack is stuck. And a branch that has gone stale-and-conflicting is always handed back to its author session to rebase and re-mark ready — even if that session was archived or its worktree was cleaned up, the auto-lander finds it by the session id stamped in the branch description and reopens it, so a branch never rots just because nobody was watching it. A branch that gained commits after it was marked ready gets the same treatment: its author session is asked, once, to re-check and re-mark it. Since 2026-09-23, re-marking it at its current commit ends the lander's wait on its next check instead of the rest of a backoff that can reach ~18 minutes, so the author is no longer told "commits were added after it was tagged" about a tag it has already fixed, and is not sent the same request again while it is still working on the branch.

Which auto-lander events reach your inbox (2026-08-23). Routine per-branch churn no longer interrupts you. A branch that ran out of automatic landing retries ("gave up") or is simply waiting to land is recorded here on the dashboard — as a Couldn't land row (with the reason) or in the queue — and the auto-lander keeps retrying it on its own; it does not raise an inbox card. What reaches you instead is the smaller set of things that are genuinely wrong or genuinely need a person: the ready backlog crossing its threshold, the lander stuck or not landing at all, the background service crashing, the git pack index going bad, finished work that never reached master, a branch that changes a dependency and is waiting for your OK, a branch the lander set aside (it stopped retrying, or it cannot retry on its own), and a branch held behind a safety check that needs your judgment. That is a list of the loudest ones, not the whole set — the auto-lander raises well over a dozen distinct cards, and the ones worth knowing about are the ones that ask you to decide something; treat a card you don't recognise as real rather than as noise. inbox-alerts.md gathers the card kinds that need an answer.

"Nothing needed from you" is not forever (2026-09-22). A branch that keeps being retried but never lands — the auto-lander's own attempts timing out one after another — is reported as handled automatically only while it is young. Past roughly four hours of that, the dashboard stops saying the lander has it and the row becomes Needs you, with a plain description instead of a reassuring one. That bound exists so a branch can never sit silently at "being handled" for a whole day while nothing lands it: if a row of yours flips, it means the automatic path ran out of road, not that anything was lost.

A branch that would drop merged work goes to its author first (2026-09-24). When the safety check that runs before every land refuses a branch because landing it would throw away work someone else already merged, the auto-lander tells the session that wrote the branch — or the session that launched it, if that one is still working, and otherwise it wakes the writer if it had archived itself after tagging, which nearly every finished session does — with the files the check named and the fix: rebase onto the main branch, keep both sides, rebuild any generated file, and tag it again. The "blocked from landing — they would drop merged work" card reaches you only when no author could be told (you closed or paused it, or its session can no longer resume) or when a told author has not fixed its branch within four hours. If the author decides the removal is intended, it signs off in its own commit instead, and when that branch lands you get one card — "A blocked branch landed with its author's sign-off" — naming the files and the author's reason.

Stuck branches: the machine goes first (2026-09-23). When a branch stopped landing, the auto-lander used to start a paid AI "rescue" session for almost every one — and on the day this changed, 11 of the 15 branches on the parked card were finished work nobody had marked ready, not conflicts. It now settles the routine cases itself, with no session:

• A branch whose every commit is already on master (under different commit ids) is retired, like any other delivered work.
• A branch whose newest commit is the automatic "save leftover work" snapshot is set aside as blocked, with a plain reason, instead of being "rescued".
• Finished work that was never marked ready goes through the same automatic checks and ready-mark a parked branch gets. Only if a check really fails, or the ready-mark is refused, does one session start — and it is told exactly what failed. A test system that is merely busy never starts one. A branch whose files master has changed since it was started is left to a session, because its work may already be out of date.

Every session the lander still starts begins with what it already measured — which files conflict and since when, and which commits are already on master. The parked branches card now says "merge conflict" only for branches that really hit one, and it no longer suggests the lander will fix a real conflict by itself. Developers can see how many sessions each step saved with node scripts/ops/land-machine-road.mjs.

The dependency one deserves its own line, because it is the likeliest reason a branch of yours is sitting finished but unlanded. The auto-lander will never land a branch on its own, however green it is, when it changes outside packages — a package manifest's dependencies, a lockfile, the package-manager settings, or a patched or bundled package — a manifest's npm scripts, or code the auto-lander runs by itself — its gate-check scripts, the git merge helpers, or the file that tells git to use them. The first carries supply-chain and breakage risk; npm scripts are commands every developer runs; the last would run with nobody watching the next time anything lands. So all three always ask, and the approval card says which the branch changes (since 2026-09-24 — before that, every one of these cards called itself a "dependency change", even for a branch that only touched the auto-lander's own scripts) and how many files moved; the files themselves are listed one per line in the card's details (since 2026-09-26 — before that the card's one-line headline named up to twenty file paths, long enough to push its Approve button off a phone screen). The details also list which packages the branch adds, removes or re-versions, one per line with the old and new version (sharp ^0.35.3 → ^0.35.4), marking new, removed, dev-tool and override entries — and they name any package.json that also changes something the list does not show (an install script, a build-script allowlist), so the list never passes for the whole change (since 2026-09-26). Versions that move only inside a lockfile are not itemized. A branch that only edits npm scripts is worded as exactly that, with no outside package added, removed or re-versioned (since 2026-09-25); if its install hooks or anything that installs packages moved too, the card still says outside packages. The card judges only what the branch itself changed since it started, so an edit master made to the same file in the meantime never mislabels the branch or holds it (since 2026-09-27). Every one of these notices now says when (since 2026-09-28). A note about a branch waiting on your sign-off carries the time its ready tag was set, so you can tell a note written before your decision from one written after it — before this, the two read identically, and a branch you had just approved still looked like it was waiting on you. It names the tag time rather than an "evaluated" time on purpose: a branch is re-checked on every pass, so the hold can be recomputed long after the tag, and calling that instant the evaluation would be its own wrong answer. A branch tagged before this existed simply shows no time, and nothing else about the wording changes. The card says nothing is lost, approving lands the branch within minutes, and leaving it parked is a valid answer: the branch and every commit on it stay exactly where they are, and it simply waits until you decide. A branch that genuinely can't be landed automatically is parked aside (recoverable) and shows here as Couldn't land, rather than nagging you to finish it by hand.

Your approval is never lost (2026-09-24). The approval card names up to 20 of the files the branch changes and counts the rest, so even a large change is one you can approve. If the app closes a card without your answer — it could not record it, or withdrew it — a fresh card comes back for the same branch; only your own approve or decline is final. And once you approve, the branch stops being listed as waiting on you straight away, even while the auto-lander is busy with other work, and lands on its next turn. The "blocked by a safety check" card points you to the approval card for these branches — a session cannot approve one of these changes for you.

A branch that would delete work that already landed is held (2026-09-23). Before anything lands, the auto-lander checks that the branch still carries every line the main branch picked up in the last week. A branch that would quietly remove some of it — usually an older copy of a file restored over newer work — waits with the reason it would remove work that landed on master in the last week. What happens next depends on what the repository can show about that file's copy, which the fix session reads first (npm run audit:dropped-work): it puts the lines back only when the copy is an old version master itself already replaced, or when the session finds a rebase or a replayed resolution lost them. If the drop looks intended it sets the branch aside for you or its author rather than reverting it. If the check cannot finish (a very busy machine), the branch simply waits for the next pass; it is never landed unchecked. Someone who removes that work on purpose records why in a commit (Dropped-work-approved: <why>), and the branch then lands normally. Before anyone signs off, the refusal shows the branch's whole change to each flagged file, not just the flagged lines, so a short code change sitting next to them is seen too.

The other one worth knowing is "a branch that changes a file git runs". Some branches change a file git itself executes the next time it runs — a git hook body, an executable .gitattributes rule, or one of the generated merge drivers. The auto-lander will not land those on its own, because the content would end up running as you in the folder it lands into. Until 2026-09-21 its only answer was "a person has to review this and land it by hand", which nobody ever did, so those branches simply sat — twelve of them had piled up. It now asks you on a card instead: approving one lands that branch within minutes, and nothing is lost either way. If you would rather not be asked again, the card's Always allow answer retires the whole class for good. One thing it will always show you, however often you grant the class: a branch that changes git's own guard on protected branches.

The same file changed on both sides (2026-09-24). A branch whose merge touches a file that the main branch also changed cannot be checked automatically: git can show that both sides edited it, never that combining them kept both. So the auto-lander refuses to land it on its own and asks you on a card — the card lists the files at stake and, for each one, what it actually found: that both sides are still represented in the result, or that one side's work did not survive. Approving clears the check for that exact publication, including anything the card did not list, and the branch lands on the auto-lander's next pass. There is no Always allow on this one, on purpose: every one of these is a different question about different files, so a standing answer would not retire a class — it would switch the check off. Declining costs nothing and changes nothing: the branch stays where it is, and you are not asked about that same commit again.

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-one 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 six checked right before the swap (syntax breakage, unresolved conflict markers, the hook-step re-check, the merged-tree verify, the land-content verify and lost ledger rows). 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.

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.

For agents

Key files. The tab is AutoLanderView.tsx in the Dev Pipeline panel; the queue read is the pure auto-lander-queue.ts behind the read-only AUTO_LANDER_QUEUE_GET IPC (handler); status + history reuse the existing AUTO_LANDER_STATUS_GET / AUTO_LANDER_EVENTS_GET. The daemon itself and its guarantees are in auto-lander-contract.md; the panel + this tab's placement rule are in dev-pipeline-panel-contract.md.

The rejection list. Every standard the lander can refuse a branch for is a row of land-standards-catalog.ts; the mode resolver, the two routes, the landStandardModes setting and the build-failing guard that keeps every refusal in the catalogue are governed by auto-lander-land-standards-contract.md. The out-of-process land:catch-up mover honours the environment switches only.

Related

The tab belongs to the Dev Pipeline panel, whose other tabs and their placement rules are covered in Dev Pipeline panel. The ready marker this dashboard reports on — and what makes a branch landable at all — is set out in Git guardrails, and the inbox cards described above sit alongside the other cards that need an answer in Inbox alerts.