Joshua Belke de4cfec61e feat: rebrand Codebase Chat to Meridian

Renames the product to Meridian across 1826 files: 24 crates
(codebase-chat-* -> meridian-*), the Flutter package, env vars
(CODEBASE_CHAT_* -> MERIDIAN_*), the deep-link scheme (meridian://),
Postgres GUCs, Helm charts, skills, and the agent surface.

White-labels every external identity onto self-hosted infrastructure:
hosts move from *.codebase.design to *.meridian.r2d2.office.ilab.zone,
images to registry.r2d2.office.ilab.zone/meridian-*, the repo slug to
r2d2/meridian, and bundle IDs to zone.ilab.office.r2d2.meridian.*.
The Block staging relay and the four Block-internal build repos are not
reachable from a self-hosted deployment and are no longer referenced.

The mark becomes a pixel M. It is 5x6 rather than a square 5x5 because
the avatar-pile mask asserts the hole clears the glyph's right edge:
at 5x5 that edge moves from 68.4% to 73% of the tile, which overruns the
56px team-card hole outright and leaves the other three piles under a
pixel. At 5x6 the aspect is 0.833 against the retired C's 0.800, so all
four masks clear it unchanged. All 59 materializations are regenerated
from the generators; `just check-brand` passes.

Four things are deliberately NOT renamed, because they match what was
*stored* rather than what now ships. Rewriting any of them makes a
migration no-op on exactly the installs it exists to repair:

- Frozen migrations 0001-0030. Their SHA-256 digests are pinned in
  n-minus-one-pins.json and embedded in the attested N-1 image. The new
  vocabulary lands as forward migration 0031, which dual-reads all three
  generations' GUCs, lock names, app profiles and mesh d_tags. The
  push-gateway's own 0001 is likewise restored byte-identical, with
  0002 widening its app_profile CHECK.
- Legacy namespace chains. xyz.block.codebasechat.app is *prepended* to
  LEGACY_RELEASE_IDENTIFIERS and its dev/localStorage twins, per the rule
  in legacy_dirs.rs that a previous rename already broke once.
- Bead IDs (codebaseChat-*), which are cited from commits and docs.
- CHANGELOG history and upstream issue links.

The Codebase-era persona ids are added to RETIRED_PERSONAS with their
prompts verbatim, but deliberately NOT to RETIRED_PERSONA_REPLACEMENTS:
that map drives migration::retire_agents, which deletes deployed
instances, and its safety argument is that the successor is already
deployed alongside. That held for Buzz->Codebase; nothing provisions a
Meridian agent on an install that already onboarded, so mapping these
would delete a working agent and leave nothing in its place.

The brand-guard self-test changes axis: the M is symmetric about its
vertical axis, so a mirrored M *is* the canonical M and asserting a
rejection there would assert a bug. It now flips top-to-bottom (the mark
reads as a W) and pins the horizontal symmetry so the coupling is visible
if the mark ever becomes asymmetric again.

Verified: cargo check --workspace --all-targets clean, just fix-all
clean, flutter analyze clean, just check-skills pass, check-brand 59/59,
brand-core 9/9, avatarPileMask 4/4, starter-avatar contrast 2/2.

Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>

2026-08-04 14:06:04 -04:00

4.4 KiB

Raw Permalink Blame History

Vision: meridian-agent + meridian-dev-mcp

The Problem

A coding agent should be small enough to hold in your head. If you cannot trace a failure from symptom to root cause in minutes, the system is too complex. If you cannot run ten instances in parallel without worrying about resource overhead, the system is too heavy.

We wanted something we could read in an afternoon and audit with confidence.

What We Built

Two binaries, two protocols, no coupling between them.

meridian-agent is an ACP agent. It speaks the Agent Client Protocol over stdio, calls an LLM, and uses MCP tools. Multiple concurrent sessions, each with its own MCP servers, history, and context. When context fills up, a session summarizes its own history and continues. It works with Zed, JetBrains, meridian-acp, or anything else that speaks ACP.

meridian-dev-mcp is an MCP server. It gives any agent a shell and a file editor. Ephemeral processes with process-group kill on every exit path. Bounded output. File edits resolve against the working directory. It works with any agent or client that speaks MCP.

Together: two crates of Rust purpose-built for headless autonomous coding work.

When agents run behind Meridian, the relay URL they connect to selects their community. A hosted operator may run many communities on shared infrastructure, but an agent's profile, presence, DMs, memories, jobs, channel memberships, and audit trail are still scoped to the community behind that URL. The same npub can join another community and repost a profile there, but no agent state is inherited across hosts.

Why We Built Our Own

Auditability. A senior engineer can read both binaries in a sitting. There are no abstractions reserved for future flexibility. When the agent does something unexpected, the path from symptom to cause is short.

Correctness at the boundary. ACP compliance is not a checkbox. We report a concrete protocol version. We emit every required notification. We handle cancellation on every path. We kill process trees on timeout. Key safety properties have regression tests that lock them down.

Composability through standards. The agent does not know what MCP server it talks to. The MCP server does not know what agent is calling it. They compose through protocols, not imports. Run ten agents behind Meridian with different MCP configurations. Swap the LLM provider with one environment variable. Point Zed at meridian-agent and you get the same tool-calling behavior in your editor.

The Architecture

Any ACP client (Zed, JetBrains, meridian-acp, custom)
        |
        | stdio ACP (JSON-RPC 2.0)
        v
  meridian-agent (up to 8 concurrent sessions)
        |
        | stdio MCP (JSON-RPC 2.0) — one per session
        v
  meridian-dev-mcp (or any MCP server)
        |
        v
  shell, str_replace, todo; rg + tree on PATH

Two pipes. Two protocols. Each session gets its own MCP server instances — fully isolated. The agent's useful output is its tool calls; text is reasoning the client can stream but the work happens in the tools.

Design Principles

Minimal. If you can delete it, delete it; if it stays, it pays rent in performance, safety, or clarity.
Hardened. Zero unsafe. Zero panics. Bounded process lifetime, bounded output sizes, bounded history. Process-group kill on every exit path. File edits resolve against the working directory. The shell runs at the operator's trust level, like bash itself. History validity is maintained on every cancellation path. The system degrades gracefully, with bounded failure modes.
Protocol-native. ACP is the only interface to the agent. MCP is the only interface to the tools. No runtime coupling. No shared state. No custom wire formats.
Honest. The agent is a loop: prompt the LLM, execute tool calls, repeat. When context fills, it hands off to itself. When it cannot proceed, it stops.

What This Enables

Multiple concurrent sessions in one process — each with independent MCP servers, history, and context (configurable cap, default 8)
Ten agents in parallel behind Meridian, each with their own MCP configuration
The same agent key can participate in multiple Meridian communities while keeping membership, jobs, DMs, profile, and presence community-local
Any ACP client gets a coding agent without a custom adapter
Any MCP server gets a capable caller without a custom adapter
A codebase small enough to fork, modify, and understand in a day — two crates, no coupling between them

4.4 KiB Raw Permalink Blame History