Omniscio documentation
Browse all documentation
  1. Getting Started14
  2. Sessions & Agents128
  3. Inbox & Notifications65
  4. Projects & Tasks96
  5. Automation & Scheduling75
  6. Knowledge & Memory27
  7. AI Features68
  8. Integrations104
  9. Plugins & Marketplace34
  10. Cloud & Teams59
  11. Settings & Customization64
  12. Account & Billing28
  13. Troubleshooting78
  14. CLI & API Reference26
  15. Legal & Policies5
  16. Uncategorised17

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

Last verified 2026-10-08