---
title: Auto-lander dashboard
---

# 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](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](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 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](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_, and an automatic fix session puts those lines back. 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](../../.claude/memory/contracts/auto-lander-invariants-engine-part1-contract.md).

## For agents

**Key files.** The tab is
[`AutoLanderView.tsx`](../../src/renderer/src/features/dev-pipeline/AutoLanderView.tsx) in the
Dev Pipeline panel; the queue read is the pure
[`auto-lander-queue.ts`](../../src/main/services/auto-lander/auto-lander-queue.ts) behind the
read-only `AUTO_LANDER_QUEUE_GET` IPC
([handler](../../src/main/ipc/auto-lander-handlers.ts)); 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](../../.claude/memory/contracts/auto-lander-contract.md); the
panel + this tab's placement rule are in
[dev-pipeline-panel-contract.md](../../.claude/memory/contracts/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`](../../src/shared/land-core/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](../../.claude/memory/contracts/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](dev-pipeline-panel.md). The ready marker this dashboard reports on — and what makes a branch landable at all — is set out in [Git guardrails](git-guardrails.md), and the inbox cards described above sit alongside the other cards that need an answer in [Inbox alerts](inbox-alerts.md).