Tower: workspace deregisters spontaneously and identity map scrambles — architect terminal misidentified as one of its own builders

[waleedkadous]

What happened

On a long-running Tower (uptime ~4.3 days, never restarted), a workspace with 6 architects + ~9 builders spontaneously dropped out of Tower's active set (afx status → 'Workspace: not active in tower') while every agent process kept running. Around the same window, Tower's terminal-identity map scrambled: an ARCHITECT terminal began resolving as one of its own BUILDERS —

$ afx whoami
workspace: <ws>
type: builder
name: builder-spir-NNNN     # actually the architect terminal that SPAWNED this builder
architect: <arch-name>

Observed correlates: the 'Unregistered Shellpers' count rose (36 → 40) across the window; no Tower restart; the affected workspace had heavy builder churn that day (multiple spawns + one cleanup).

Impact

• afx send architect:<name> from the misidentified terminal is rejected by the builder-spoofing check ('builder builder-spir-NNNN may only address its own spawning architect') — architect↔architect messaging fully broken for that terminal.
• Builder→architect affinity routing becomes untrustworthy (reports may land on the wrong terminal or nowhere).
• Workaround that held: afx send <builder-id> (the by-id form, allowed from any sender) still delivers both directions, so lanes kept moving with an in-message identity preface.

What we did NOT do (please advise)

Did not run afx workspace start on the degraded state until the operator authorized it, because it was unclear whether re-registration ADOPTS live PTY sessions or spawns fresh ones alongside them — with live builders, guessing wrong is expensive. Docs could state this explicitly either way.

Asks

1. Root-cause the identity-map scramble (PID/terminal re-binding after shellper churn? cleanup of one builder re-keying the map?).
2. Make afx whoami mismatches self-healing or at least loudly detectable Tower-side.
3. Document whether afx workspace start is safe on a workspace with live sessions.
4. Consider the by-id send form's 'any sender' permissiveness — it was the saving workaround here, but it also means a scrambled identity can still inject builder-addressed messages; a signed/verified sender identity would close both gaps.