afx send: builder message routed to the wrong architect in a multi-architect workspace

[pseudoseed]

What happened

builder-experiment-39 sent a status message intended for its architect. It was delivered to the architect named main, not to its spawning architect uiv2. main had to forward it manually, noting it had landed in the wrong inbox.

Why this is a defect either way

The attribution in global.db is correct:

sqlite3 -readonly ~/.agent-farm/global.db \
  "select id, spawned_by_architect from builders where id='builder-experiment-39';"
builder-experiment-39|uiv2

So there are only two possibilities, and both are bugs:

1. The builder used the bare afx send architect form. Documented behaviour is "From a builder: its spawning architect." spawned_by_architect is uiv2 and it resolved to main anyway, so the resolver is ignoring the column and falling back to the main-else-first-registered rule that is meant to apply only to non-builder senders.
2. The builder used afx send architect:main explicitly. That is supposed to be refused. Per CLAUDE.md: "a builder may only use this for its own spawning architect — mismatches are rejected as spoofing." A builder reaching an architect that did not spawn it means the anti-spoofing check did not fire.

I cannot tell which from the outside, since the sent form is not recorded. That is arguably a third small gap.

Why it matters beyond one stray message

This is the multi-architect case the workspace explicitly supports (cluesmith#755, cluesmith#761, cluesmith#786, cluesmith#823). With two architects in one workspace, a builder's messages reaching the wrong one is not cosmetic:

• The wrong architect receives blockers it has no context for and no authority over.
• In this instance the misrouted message carried stale infrastructure state (it claimed a Cloudflare tunnel was live that had already been deleted). The architect that could have corrected it immediately never saw it, and the one that did see it correctly declined to act on another architect's builder. The correction took a manual relay.
• It undermines the ownership boundary between architects, which is the entire point of named architects.

Reproduction sketch

1. afx workspace add-architect --name other in a workspace that already has main.
2. Spawn a builder from other.
3. From the builder, afx send architect "test".
4. Observe which architect receives it. Expected other; observed main in this case.

Suggested fix

• Bare architect from a sender that is a builder must resolve through spawned_by_architect and must never fall back to the main-else-first rule. If the column is null, fail loudly rather than guessing — a message delivered to the wrong architect is worse than one that errors.
• architect:<name> from a builder must be rejected unless <name> equals spawned_by_architect, which is the documented behaviour.
• Record the address form used on the mailbox row, so misroutes are diagnosable after the fact.

Found while running two architects (main, uiv2) against separate builders in codev-1455.

[pseudoseed]

Second occurrence, ~6 minutes after the first, so this is consistent rather than a one-off.

builder-experiment-39 sent a status at 2026-08-22T20:14:41Z. It landed in main's inbox again, not uiv2's. main forwarded it manually a second time and declined to act, correctly, since it is not that builder's architect.

Both messages were ordinary status reports, which is the common case rather than an edge one. Every status this builder produces is currently reaching the wrong architect.

Worth noting for whoever picks this up: between the two occurrences I sent the builder an explicit instruction to use afx send architect:uiv2. The second misroute happened after that instruction was queued, so the workaround is not reliably reaching the builder either. If the fix lands, it should not assume builders can be told to work around it.

[pseudoseed]

Two more occurrences, both landing in main's inbox from builders owned by uiv2. (I filed #59 as a duplicate before seeing this — closed, evidence moved here.)

Time (UTC, 2026-08-23)	Builder	Content
17:34:24	spir-52	Plan review lane summary
17:36:24	spir-52	plan-approval gate ready

Plus the two from experiment-39 the day before (20:08:54 Cloudflare Access block, 20:14:41 gate-1 status). Four total, all uiv2-owned, all reaching main.

Ownership is unambiguous from the CLI side too, which pairs with your spawned_by_architect=uiv2 finding:

  ID                    Owner           Type      Status        Phase
  builder-spir-52       uiv2            spec      implementing  init

So afx status reads the column correctly and afx send's resolver does not.

Why the fourth one raises the severity

The first three were recoverable by forwarding. The fourth is a gate approval request, and gates are the mechanism keeping a human in the loop — CLAUDE.md is explicit that a gate message is a notification, not authorization. A mis-routed gate means:

• the architect who owns the project never learns its gate is ready, and it stalls
• an architect with no context on the work is the one being asked to approve it
• it is silent on both ends: the sender gets delivered, so nothing suggests it went to the wrong party

That last point is the one I'd fix even before the routing itself. delivered currently means "a pane accepted it", not "the intended recipient got it". If the spawning architect cannot be resolved, that should be reported rather than answered with a success that happens to be true about the wrong inbox — "I could not tell" must not be spelled the same way as "delivered".

Worth a test alongside the fix: spawn a builder from a non-main architect, send the bare form, and assert the receiving terminal is the spawning architect's — not merely that the send returned delivered.

[pseudoseed]

I went looking for the resolver bug and could not find one — the leading hypothesis is disproven. Posting the evidence because it redirects the issue rather than closing it.

The resolver honours spawned_by_architect

global.db's mailbox table records every send. Grouped by sender and target, for this workspace:

builder-spir-52        -> uiv2    5
builder-experiment-38  -> uiv2    3
builder-pir-13         -> main    9
builder-pir-4          -> main    7

builder-spir-52 reached uiv2, five times, correctly. There are zero builder-* -> main rows for any uiv2-owned builder. So the bare form is not ignoring the column, and the anti-spoofing path is not the cause either.

What actually reached main

Every one of the 13 messages I forwarded has from_agent = architect, never builder-*. Traced by body:

"Project 63: experiment-complete"   from: architect -> main   (and -> uiv2)
"PR #70 ready for review"           from: architect -> main
"PR #68 is issue #63"               from: architect -> main
"Experiment 62: recorded FR-22"     from: architect -> main   (and -> uiv2)

A sender identified as architect routing to main is the documented, correct behaviour: "From anyone else: the architect named main, else the first registered."

So nothing here misrouted according to the rules. The question becomes how a builder's status message came to be sent by something identifying as an architect.

Gap 1 — builder identity is derived from cwd, and nothing else

detectCurrentBuilderId() (send.ts) resolves identity solely from process.cwd():

const match = cwd.match(/^(.+)\/\.builders\/([^/]+)/);
if (!match) return null;      // -> from = 'architect'

There is no session or environment fallback — I grepped for one. A builder that cds anywhere outside its own worktree while still inside the workspace stops being a builder and becomes architect, silently, and its next afx send architect goes to main by the non-builder rule.

Note the asymmetry, which is why this was hard to see: if cwd is inside .builders/<id>/ but the id can't be verified, cluesmith#1094 made that throw loudly. The remaining silent path is the one where cwd isn't there at all.

(From outside any workspace it fails cleanly — I probed from /tmp and got Cannot resolve agent without project context. So the window is specifically inside the workspace, outside the worktree.)

Gap 2 — every architect collapses to one string, so this is unfalsifiable

distinct architect names:            main, uiv2, entries, org-ui, main2, ade
senders that are an architect NAME:  (none)
literal "architect" used as sender:  true

from_agent is the literal architect for all of them. Nothing records which architect sent, and nothing records the form that was typed (architect vs architect:main).

So I cannot distinguish "a builder lost its identity and was reclassified" from "uiv2 sent these deliberately", and neither could anyone else. That is the finding. Thirteen occurrences produced an unfalsifiable diagnosis because the one field that would settle it isn't written down.

What I'd fix

1. Record the sender's real identity. from_agent should carry the architect's name, and the requested target string should be stored alongside the resolved one. Two columns turn this from argument into query.
2. Give builders an identity that survives cd. Bake the builder id into the environment at spawn, the way CODEV_WORKTREE_ROOT already is for the write-guard, and prefer it over the cwd inference.
3. Reclassification must not be silent. If afx send architect is invoked from within a workspace that has a builder worktree in its ancestry but resolves to a non-builder sender, say so rather than quietly applying the main-else-first rule.

Item 3 is the one that matters most: delivered currently means "a pane accepted it", not "the intended recipient got it".

I have not root-caused the misroute, and I don't want to claim otherwise. I've ruled out the resolver, and found that the instrumentation can't answer the remaining question.