Roadmap
Six ordered stages to GridWork 1.0, with shipped, current, and planned work stated separately.
GridWork is built in public, pre-1.0. Stages land in order, and each stage exits with working, tested code — there are no aspirational branches.
No dates. A stage is done when its gates are green, not when a calendar says so.
1 · Contract (shipped)
The shared language everything else speaks. Published to crates.io under Apache-2.0 with
live docs.rs pages — five crates at 0.0.1, six at 0.0.2 once the kernel itself went up,
which is what made cargo install gridwork work.
- Domain types, event schemas, and four state machines in
gwk-domain. Each machine is an enum plus a fixed edge table, and the table is the contract: terminality is derived from it, so a state and its legal moves cannot drift apart. The invariant suite walks those tables exhaustively and a mutation battery proves the suite actually catches a tampered edge - One pure transition function every writer goes through. It returns what happened as a value — applied, illegal edge, stale version, unauthorized actor — and never panics
- A storage port with a conformance suite any backend runs against its own event store,
plus
gwk-cert: a checker that replays an exported event stream against the contract - A generated TypeScript contract for non-Rust consumers, CI-checked against the committed artifact, with a golden round trip that decodes in Bun and re-verifies in Rust by value
- A SQL DDL that CI applies to a pinned PostgreSQL and then attacks: truncating a state table must fail, and clearing a set lease fence must fail
2 · Kernel (shipped)
- A daemon owning an append-only event store — the sole writer. One writer row, locked for the length of each append, so sequence order is commit order across processes; a fence token deposes a previous writer and omitting it is refused, not skipped
- Projections written in the same transaction as their events, so a committed log and its projections cannot disagree. Rebuildable — into a scratch database, compared by hash, never swapped as a side effect
- Content-addressed blobs: a chunked AEAD container sealed against truncation, envelope encryption, and pin / unpin / sweep / crypto-shred retention
- The attention queue: one prioritized feed of everything that needs a human
- Authority policy as data — evaluated under the writer lock, every decision leaving an immutable receipt; a page raises attention and changes nothing
- A framed protocol over a Unix socket: strict decoding, bounded frames, bounded queues, per-connection byte rates, and event subscriptions that tell a cut-off consumer the cursor it actually received
gw, the headless CLI over that same protocol — the one the TUI will use — with stable exit codes and canonical JSON on stdout
Certified against a real PostgreSQL 16, including crash, race and process-boundary cases, with the performance envelope measured and receipted per run.
3 · Engines (shipped)
- PTY engine: authoritative server-side virtual terminal, render-state deltas, detach/reattach, recording
- Agent adapters for Claude Code, Codex, and opencode over ACP + engine hooks — control never rides synthetic keystrokes
- A parity matrix per engine, including permission-prompt relay — defined in Engine parity, certified green across all twelve cells at pinned engine versions (2026-08-06)
Shipped means the stage's gates are green, not that its crates are published: the engine crates stay in-tree, unpublished until 1.0 packaging.
4 · Console (shipped)
- The orchestration TUI, ruled as five lenses over one estate — hall, work, fleet,
flow, term (the design record lives in-tree:
crates/gwk-tui/tests/mockups/DESIGN-NOTES.md); the Board dissolved into them, andgw board,gw event tail, andgw term attachopen the one console shell - Replay of persisted terminal recordings as a deterministic timeline in the console
Shipped with named residue: the ledger-synced, exportable-as-evidence half of replay is not built, and two stage-3 leftovers — consumer-routed resize/stop and request-driven session starts — are still open.
5 · Workspace (current)
- A full terminal multiplexer: workspaces, tabs, splits, scrollback, detach
- Daily-driver quality — the stage where GridWork becomes the terminal you live in
6 · Context runtime
- The instruction and intelligence plane: skills, memory, and knowledge as first-class, measured surfaces — what an agent is told becomes an inspectable, receipted artifact instead of loose convention
- The last stage before 1.0: packaging and the ignition kit follow its exit
1.0
All planes complete and packaged: kernel + protocol + CLI; the five-lens console; mux;
and Context Runtime. Single-command install (cargo install gridwork and friends), and
distribution stops assuming you run your own postgres — a zero-setup embedded backend
is part of 1.0 packaging, not before.
Principles that won't move
- One append-only log owns every truth; user interfaces are projections of it.
- The kernel is the sole writer; clients are thin.
- Control never rides keystrokes.
- Terminal only. No web console.