This is the engine’s layout in the platform repo as of the Allternit Factory build. The older work-engine and orchestrator crates it replaced are gone; the migration page lists their names.

​
Layout in the platform repo

The Factory is built inside the platform repo, following its convention: binaries in cmd/, substrates as top-level crate directories.

​
The engine binary

allternit-factory replaces the old work-engine, work-engine service and orchestrator binaries (named on the migration page). Nobody types it, but its tree is: The core stores events, IDs and state. The Gate is the only thing allowed to change state. The four parts hold the domain logic. The surfaces (pane, api, remote) are how people and machines reach it. The pane engine is a clean block. The forked Herdr code keeps its Apache-2.0 LICENSE and NOTICE and its internal layout, so upstream Herdr fixes can still be merged. Allternit additions sit beside it, not inside its files. Every terminal is a pane. allternit-mux folded into the pane engine and is gone. A Desktop or web terminal tile (allternit-api’s Terminal API), a Gizzi PTY, a workspace-service pane and a Factory agent pane are all panes in the same pane engine, in the Factory’s agent session. Clients that draw the terminal themselves use the pane engine’s factory.terminal.* socket methods: create, raw write, resize, close, and an output stream that replays the kept scrollback (2 MiB), then streams live output and the exit code. Each pane they open carries a small output tap (factory/pane/src/factory_terminal.rs). People and scripts use allternit-factory pane tty …. So a terminal shows in the agent wall as term-<id>, an agent started in one is detected like any other, and terminals outlive the UI that drew them. Details: allternit-mux (folded into the Factory).

​
Where the old modules go

Kept apart: tickets, graph and sync (the portable ticket tool for foreign repos) stay one tickets area inside the engine, not inside any of the four parts. The old standalone work-engine binaries and their install.sh are removed.

​
Processes and ports

The workspace ledger stays in the workspace’s .allternit/ folder, with its existing layout. Event names are data and aren’t renamed, so old ledgers still replay. The engine starts explicitly: Desktop starts it, or the first gizzi command that needs it starts it and says so.

​
/api/factory

The engine serves /api/factory. All JSON is camelCase, times are RFC 3339, and IDs are opaque strings. Errors use HTTP 400/403/404/409/502/504 with { "error": { "code", "fact", "action" } }, using the same codes as the CLI exit codes. The full contract, with every request and response shape, is the Factory API reference.

​
What allternit-api proxies and what it owns

  • Proxies: the engine’s /api/factory/* routes (agents, teams, send, deliveries, events, templates, runs, dags/:id, campaigns, nodes, health, tasks) go straight to the engine, for Desktop, ai.allternit.com and m.allternit.com (through the fabric relay).
  • Serves in process: the work-engine routes (mail, peers, steer, ledger, plans, leases and the rest, listed below). allternit-api runs them itself against the linked factory/ crates, behind the same auth as the rest of the API.
  • Owns: /api/factory/approvals*, plus the push action endpoint and the inbound channel hooks, because push and channels already live in allternit-api. It resolves approvals as Gate events through the linked factory/ crates.
  • Replaces: the old work-engine route prefixes all move to /api/factory (old → new in the migration page). Gizzi’s /v1/orchestrator (and the platform’s /api/v1/orchestrator passthrough to it) is replaced by the engine. The old routes were removed in the same release that updated every caller; there are no aliases.

​
Routes allternit-api serves in process

These are mounted by allternit-api at /api/factory (factory_core_router()), not proxied. Paths are relative to /api/factory. Every subpath kept its old name except five, which moved because the engine already uses those paths:

​
How each surface reads it