Nested task-spawned builders are send-only ghosts: no registry row, affinity NOT_FOUND, sends fall through to MAIN — an instruction-injection surface

[waleedkadous]

Found in the shannon workspace, 2026-07-26. Mechanism details + evidence from two architects.

Setup: a strict builder (builder-spir-3276) spawned a task builder from INSIDE its own worktree; the child landed nested at .builders/spir-3276/.builders/task-w-yI with branch builder/task-w-yI, a live shellper session — and no row in the Tower registry (afx status lists 18 builders, no match).

Three resulting defects, all observed:

1. Send-only ghost: the nested builder can afx send successfully, but afx send task-w-yi from an architect returns NOT_FOUND — it cannot be reached or redirected.
2. Affinity broken: from its worktree, afx send architect returns NOT_FOUND (no spawner affinity registered).
3. Fallback misroute: the workspace-qualified form it fell back to resolves to the architect named main — NOT its lane's architect. Its full work verdict was delivered to an unrelated architect verbatim.

Security framing (agreed by both architects involved): an unregistered sender falling through to main carrying a legitimate-looking builder-* name is an instruction-injection surface, not just noise — the spoofing check that governs registered builders never applies to a sender with no registry row. Today the payload was a benign stall-recovery probe; the same path delivers arbitrary instructions with apparent builder provenance.

Evidence: main architect's failed reach-back (afx send task-w-yi → NOT_FOUND) is the receive half; the misdelivered verdict (received by main 2026-07-26T16:58Z, sender builder-task-w-yi) is the send half.

Likely related: #1224 (registry family).

[waleedkadous]

Attribution correction + a sharper defect, from continued investigation (2026-07-26):

The sender was NOT the nested task builder — it was the parent builder builder-spir-3276 itself, whose worktree had silently LOST Tower registration ('Workspace: not active in tower'; both afx send architect and afx send architect:main return NOT_FOUND from inside it). The nested task builder was verified inactive (no file mtimes, no commits) during the sends.

The sharpest defect this reveals — wrong-name stamping: Tower delivered the deregistered sender's fallback messages to main labeled [BUILDER builder-task-w-yi] while they were authored by builder-spir-3276. So the unregistered-sender fallback path doesn't just misroute — it mis-attributes, stamping another (plausible) builder identity onto the message. That upgrades the injection surface from 'a fake name could be used' to 'the infrastructure itself applies a wrong name in the wild, by accident.'

Also worth investigating as one story: the registration loss followed a ~15h builder-session wedge and an external wake nudge — wedge → wake → registration dropped.

(Correcting rather than editing the original body so the wrong attribution stays visible as part of the record.)

[waleedkadous]

Forensic evidence from the affected builder (passive reads of afx tower log + afx status only), architect-verified:

• Tower did not restart — uptime 3.71 days spans both the last working affinity send and the first NOT_FOUND. The behavior changed while Tower was continuously up.
• Registration is intact for delivery and explicit addressing: messages TO the builder deliver correctly; afx send architect:cost from its worktree sends with the CORRECT sender name.
• Only affinity paths fail: afx send architect and architect:<name-of-non-spawner> → NOT_FOUND; explicit builder/architect addressing → OK; <workspace>:architect → OK but stamped with the wrong sender name (a nested builder's). afx status from the worktree simultaneously reports 'Workspace: not active in tower' and 12 active workspaces.
• Correction to an earlier framing: the terminal IDs in the log lines are the recipient's terminal (verified against afx status), so the defect is wrong-sender-NAME on the fallback path — no evidence of sender-terminal misresolution.
• Labeled hypothesis (not measured): sender identity on non-explicit paths resolves from the filesystem and walks to the nearest/newest NESTED builder registration (both nested task builders live at .builders/spir-3276/.builders/task-*); that one mechanism explains both the wrong name AND the NOT_FOUND (the nested builder's spawner is a builder, not an architect, so spawner-affinity has no architect to resolve).
• Honest caveat that weakens the hypothesis: bare architect still worked ~7h AFTER both nested builders existed; onset coincides with a ~15h idle period — suggesting a workspace-registration lapse during idle, with the path-walk fallback only taking over after the lapse. TTL-eviction vs wake-time re-resolution not distinguishable without active probes, which we are not running against live infrastructure.