Skip to main content
This is the one-page index of the system: which module owns what, which sealed contracts join them, and how each level is proven. Every module entry links to its in-tree README — the README is the source of truth; this page is the map. Why the system has this shape: a module owns exactly one concern and is the single source of truth for it; every service is a modular monolith built from such modules; modules join only through sealed contracts that CI refuses to let drift. The payoff is debuggability at every scale — a module alone against its fixtures, or a chain of modules at the scale a bug lives at — and a verify loop (code + adversarial tests + goldens, deterministic ports, fixtures from real meetings) simple enough for AI agents to own. The narrative: What 0.12 is.

​
The module tree

Five core domains, a client, and the composition layer. Each domain owns its contracts + the services that honour them.

​
Contract registry

The sealed seam between modules. 16 *.v1 contracts are frozen in contracts.seal.json — a sha256 per contract; CI fails if a sealed schema drifts. Grouped by owning module, with owner → consumers.
The agent domain also defines six unsealed control-plane contracts still in flight — event.v1, unit.v1, invoke.v1 (UNSEALED), task.v1, routine.v1, tool.v1, proactive-card.v1. Only the 16 below carry a seal hash today.

​
core/agent

​
core/meetings

​
core/gateway

​
core/identity

​
core/runtime

​
deploy

​
Eval levels — the validation pyramid

Every change is proven at the lowest level that can catch it. Governed by the architecture constitution; the live gate lives at core/meetings/eval.

​
Gates, harness & fixtures

The eval levels are enforced, not aspirational: an artifact “exists” only when it is gate-green (P9). Three terms separate the concern:
  • a gate is a runnable check that turns CI red when a rule is crossed;
  • the harness is the machinery that stands a real (or faked) system up so a gate can run;
  • fixtures are the inputs and lifecycle plumbing the harness runs against.

​
The gate

In this tree the runnable bar is pnpm typecheck build test, the compose stack-readiness proof — make -C deploy/compose stack-test (it stands the whole stack up, proves it, and tears it down) — and the gate suite (scripts/gates.mjs, invoked as pnpm gates / pnpm gate:*): readme · isolation · exports · graph · schema · contract-version · python · licenses in CI, plus the two architecture gates — pnpm gate:dataflow (model↔disk completeness, single-writer / render-only ownership, a reality diff against the code, and view staleness) and pnpm gate:calm (Architecture as Code). Contracts and the architecture chart are sealed (pnpm seal:contracts / pnpm seal:arch) — drift from a seal is deliberate-only.

​
The harness — three tiers

Two rules run through every tier: poll with bounded timeouts, never sleep-and-hope, and green-or-skip — when Docker is absent the stack proof skips rather than fails, so the gate stays honest on a machine that cannot run it. The slow, real-bot lanes (a ~7GB browser image) are opt-in behind COMPOSE_BOT=1; the always-on subset never spawns one.

​
Fixtures

  • Golden vectors — committed example envelopes that are the spec (P8). Tests load them by path from the published contract (e.g. the transcript.v1 and lifecycle.v1 goldens), never by importing the producing domain’s code — which preserves the same meetings ⊥ agent boundary the production code keeps.
  • Lifecycle fixtures — the session-scoped stack fixture owns the whole compose up → healthy → down -v cycle; the unit tier uses ephemeral testcontainers (Postgres / Redis), in-process fakes (fakeredis, a fake authorizer, a fake webhook receiver), and a FakeClock so time-based logic is deterministic.
  • Replay fixtures — captured transcript material (a scripted call) plus a VTT→fixture converter, so an agent turn can be re-driven offline without a live meeting.