Omniscio documentation
Browse all documentation
  1. Getting Started19
  2. Sessions & Agents133
  3. Inbox & Notifications68
  4. Projects & Tasks98
  5. Automation & Scheduling74
  6. Knowledge & Memory28
  7. AI Features71
  8. Integrations111
  9. Plugins & Marketplace39
  10. Cloud & Teams51
  11. Settings & Customization74
  12. Account & Billing28
  13. Troubleshooting77
  14. CLI & API Reference27
  15. Legal & Policies5
  16. Uncategorised17

Lander V3 (the train lander)

Lander V3 lands finished branches onto your local master in trains — many branches merged together and published in one step — instead of one at a time. It trusts the ready tag, checks only that a merge cannot erase someone else's newer work, and holds a branch back whenever it is unsure. One switch decides whether V3 or the old lander moves master, and flipping it back is the whole rollback.

What it is

When an agent finishes a branch, the ready check judges it once and stamps it ready at an exact commit. The lander's job is to get those stamped branches onto master. The old lander spends most of its time on bookkeeping around each merge. V3 keeps its own small record, does the merging in memory, and moves master once for a whole train, so it can land well over a thousand branches an hour.

V3 runs as its own background process, so it keeps working across an app restart, and only one copy of it can act at a time.

Where to find it

V3 has no screen of its own yet. Its state is read from the Omniscio control server's Lander V3 status route, and the existing lander pause and freeze controls stop it the same way they stop the old lander.

How it behaves

  • It ships switched off, then runs in shadow. V3 does nothing until it is deliberately turned on in shadow. In shadow it builds every train it would land and counts where it would have chosen differently from the old lander, but moves nothing.
  • Cut-over is one switch. When the owner turns the landing-v3-own lander switch on, the old lander stops moving master and V3 takes over on its next train, with no restart. A hand catch-up then queues the branch into V3 as urgent instead of landing it directly.
  • Rollback is the same switch. Turning it off hands master straight back to the old lander; no data needs moving either way.
  • Doubt means wait. If V3 cannot read something it needs, the branch stays ready and is tried again later, and an alarm is raised instead of bothering the author. A branch with a real conflict, or a proven check failure, goes to the conflict resolver.
  • A bad land is reverted only with proof. If master goes red after a train, V3 reverts a branch only when it can reproduce the failure with that branch and not without it, and the author is always told.

For agents

  • The rules and every slice's interface: .claude/memory/contracts/lander-v3-contract.md. The parts and the path of one train: .claude/memory/lander-v3-map.md.
  • The code lives in src/main/services/lander-v3/ and never imports the old auto-lander.
  • The switch is landing-v3-own, flipped by the owner only through the lander switch command (npm run lander:switch). It is not the old lander's landing-v3 or landing-v3-on switch.

Related

The auto-lander dashboard page describes the old lander's cards and controls, which keep working while V3 runs in shadow.

Last verified 2026-10-15