Multi-architect support: per-architect identity + builder-to-architect message routing

[waleedkadous]

Context

Some Codev users drive multiple architect agents in the same workspace simultaneously — a pattern we'll call sibling-architect. Each architect is responsible for an orthogonal slice of work (different feature areas, different builder pools, different decision authority). All architects share the same git repo, builder farm, and consult infrastructure but operate on disjoint sets of issues and builders.

This pattern has emerged organically on at least one large customer project running Codev. It's now load-bearing for their workflow.

Current friction

Manual ownership lookup on every builder message

When a builder runs afx send architect "<message>", the message lands in the shared architect terminal pool. The architect has to look up "is this MY builder or my sibling's?" by checking thread-state files, memory, or simply guessing.

This works but is manual and error-prone, especially under cognitive load (many builders in flight, deep technical work in progress, multiple parallel threads of conversation).

Workarounds in the field (convention layer)

Users have adopted thread-state files at codev/<thread-name>-thread.md per active architect thread:

• Active builder roster + current phase/gate
• PR list with merge state
• Pending decisions waiting on architect input
• Pickup checklist for fresh sessions
• Cross-architect coordination rules (e.g., "sibling thread's builders are tracked there; this thread does NOT approve their gates")

Every architect ping requires checking these. Discipline keeps it working but it's brittle.

Feature asks (ranked by priority)

1. Builder-to-architect message routing (LOAD-BEARING)

Currently afx send architect routes to a single shared destination. Proposed:

• The builder's spawn metadata records the spawning architect's identity.
• afx send architect routes to that architect specifically.
• The architect agent sees ONLY messages from builders it spawned (plus a separate "broadcast" channel if explicitly addressed).

This is the biggest single ergonomic win — eliminates the "is this mine?" cognitive overhead on every builder ping. Everything else in this issue composes cleanly with it.

2. Per-architect identity in spawn + status

afx spawn optionally records which architect spawned the builder:

afx spawn 1487 --protocol spir --architect main
afx spawn 1481 --protocol spir --architect sibling-name

afx status filters:

afx status --architect main             # only main's builders
afx status --architect sibling-name     # only sibling's builders
afx status                              # all (current behavior)

3. First-class thread.md template + lifecycle

Codev ships a THREAD.md template (analogous to existing protocol-builder-prompt templates) with the conventions users have informally adopted:

• Headline / current status
• Active builder roster
• PR list with merge state
• Pending decisions
• Pickup checklist
• Cross-architect coordination rules

New CLI:

codev thread new <name>       # creates codev/<name>-thread.md from template
codev thread list             # show active threads
codev thread archive <name>   # move to codev/archive/ when initiative completes

4. Cross-thread visibility (read-only for non-owners)

codev thread show <name> prints another thread's current state so an architect can check what a sibling shipped without re-reading their full markdown.

Useful when a sibling's merge affects yours (e.g., a config change in their thread that breaks your e2e tests).

5. Thread-aware consult

Currently consult resolves project IDs from worktree path or "exactly one project exists." When two architects work in the same workspace, the second condition fails. A --thread flag (or auto-detection from a .thread file in the worktree) lets consult disambiguate.

Suggested rollout

Item #1 (message routing) is the load-bearing ask and should ship first. Items #1 + #2 compose cleanly — once architects have identity, message routing is identity-aware. Items #3-5 are nice-to-have follow-ups.

This issue tracks all 5 asks. First implementation work should scope to #1 only; #2-5 become follow-up issues after #1 lands.

Suggested protocol

SPIR — touches Tower message routing, spawn metadata, and afx send routing. Needs design decisions:

• Where does architect identity live (terminal ID, named identity in config, something else)?
• Backward compat: how do existing builders (spawned without an architect-identity field) route their messages?
• Broadcast channel semantics — what's the address that goes to ALL architects?
• Migration path if/when items Context Window Optimization - AI Needs Project Knowledge Without Breaking Limits #2-5 land.

Reporter

External Codev consumer running Codev on a large project where the sibling-architect pattern is load-bearing for daily operation. Sanitized for upstream filing.