GridWork

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, and gw board, gw event tail, and gw term attach open 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.

On this page