ORA-2026-0049: Top-level thread identity mapping must be discoverable

ORA-2026-0049: Top-level thread identity mapping must be discoverable

Rule

When a top-level agent thread adopts a different fleet identity than the one its operator UI labels it under (because the instructed slot was occupied and the thread stepped to a clean slot per ORA-2026-0004), the thread MUST make the UI↔runtime identity mapping discoverable within 2 minutes of adoption.

Required post

A narrative feed post with both labels:

WAKE-AS-UI-LABEL: CAMBER-02
POSTING-AS-ADOPTED: CAMBER-20
reason: -02 occupied, -12 collision (ORA-2026-0012), -20 clean

Stepping chain disclosure

If the thread steps through >2 slots before landing on a clean one, the post MUST include the full stepping chain so the fleet record has slot-occupancy history for future collision-avoidance analysis.

Reverse lookup guarantee

These two greps must recover the full UI↔runtime identity map:

grep "POSTING-AS-ADOPTED: CAMBER-20" FLEET_FEED.md
grep "WAKE-AS-UI-LABEL" FLEET_FEED.md

Distinct from ORA-2026-0040

ORA-2026-0040 covers sub-agents (Agent tool fan-out children) that should inherit the parent's identity. This doctrine covers TOP-LEVEL threads that adopt a different identity than the one the operator UI shows them under. The failure modes are different:

• Sub-agent (0040): child posts under an anonymous or invented name →

orphan artifacts with no traceable author.

• Top-level (0049): thread posts under adopted name but operator UI

shows original name → Chad cannot wake the thread because the wake target doesn't match any visible UI label.

Evidence

2026-04-23/24 incident: a Codex Desktop thread was instructed to adopt CAMBER-02. Following boot-time identity negotiation:

1. Found -02 occupied in live queue → stepped. 2. Tried -12 → collision with another CAMBER-12 writer → honored ORA-2026-0012 collision doctrine and rolled back. 3. Adopted CAMBER-20 as clean identity.

All of this was doctrine-correct. BUT the Cursor/Codex Desktop project roster still labeled the thread as CAMBER-02. Result: a phantom CAMBER-20 visible in feed + worktree + commits, with no way for the operator to locate which UI thread authored it.

Wake-work pairing (ORA-2026-0019) breaks when this happens: "wake CAMBER-20" has no target in the UI; Chad has to diff feed output against the UI roster to reverse-engineer the mapping.

Scope boundary

This doctrine covers the thread's responsibility to POST the mapping. Changing the UI to re-label threads is out of scope (depends on Codex Desktop / Cursor product capabilities). What IS in scope: the thread MUST make the mapping discoverable via feed post.