core: retirement is final only for findTeamBot — five host paths still wake, extend or edit a retired Bot, and its timers stay armed #1709

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 8f54f90c091646518888ac1d2cf69102
Branch: dev/3-retired-bot-remaining-paths
Base: 742e06c
At: 2026-10-29T15:00:44Z

Written-by: FlyBot Lead

What — #1700 / PR #1707 makes retirement final for the seven team tools that resolve a Bot through findTeamBot (message_bot, stop_bot, update_bot, create_group, update_group ×3 shapes, archive_bot). Five host paths resolve a Bot by name without going through it, so a Bot that was just archived is still woken, still edited, or still fires its own timer:

1. track_tasks assignee — wakes it. core/src/host/tasks.js:438 memberBot picks the assignee out of liveParticipants(room) (:265), which filters only leftSeq, never retired; the call site is :731. The card is created ownerBotId=<retired bot> / status:claimed, and core/src/host/task-drive.js:276 then rt.deliver({ toId: <retired bot>, … }) — the exact thing #1700 exists to stop.

2. A group @Name turn — wakes it. core/src/host/groups.js:446 callMembers builds callees from room members; a retired Bot still seated in the room gets a turn (:520, :661, :788 are the three call sites).

3. attach_capability / detach_capability — edits it. core/src/host/capabilities.js:157 rt.findBot(targetRef) takes no retirement into account, so attach_capability {name, bot:'<retired>'} writes state.bots[id].capabilities.

4. remember / recall scope: — writes into it. core/src/host/memory.js:511 namedScope (the rt.findBot(value) call sits at :516).

5. A schedule targeting it — wakes it on a timer. core/src/host/schedules.js:319-327 contentOf() accepts any body.target that exists in state.bots, without reading fields['flybot-tree'].retired; the copy target (:349-352) is the same. The row is bound to rt.chatOf(bot.id) (sessionFor, :206) and that Session is still alive, so DSH delivers for it and a turn starts on the retired Bot. Nothing disarms it either: core/src/host/roster.js:514-535 archiveBot writes the retired flag, hidden and saves — it never touches the Bot's Session, while deleteBot (:580-592) and deleteRoom (:473-477) both call archiveSession(part,{stopActivity:true}) with the comment "left armed, their scheduled tasks would keep running". state.retiredSessions is filled only by deleteBot (:548-554), so a retired Bot's Session is not in it.

Reproduction at live main 742e06cce128b6a16fb37406881a53bd29ea5d64 for paths 1-4 (found independently by FlyBot Test and FlyBot Security, both reproduced on that base), and at 2213b4ca3ad26e0372446fb8eb8d3973835d7150 for path 5 (FlyBot Product):

• Bot Writer (b2) in group Duo, then archive_bot Writer, then track_tasks {group:'Duo', overall:true, title:'Ship it'} and track_tasks {group:'Duo', title:'Write docs', parent:'Ship it', assignee:'Writer'} → card created with ownerBotId: 'b2', status: 'claimed', and b2 receives [Continue task] Continue task-… Write docs. A retired Bot was woken.
• Same setup, then attach_capability {name:'probe-skill', bot:'Writer'} → Attached probe-skill to Writer., state.bots.b2.capabilities = ['probe-skill'].
• Same setup, then remember {text:'…', scope:'Writer'} → Saved to Writer's memory, in MEMORY.md ….
• Group @Writer in a room it still sits in → it takes a turn.
• Bot w1 carrying the exact shape archive_bot writes (hidden:true, fields:{'flybot-tree':{retired:true}}), then schedule-create {target:'w1', title:'Nightly writing'} → ok:true, sessionId:'w1'; schedules now lists {id:'schedule-1', botId:'w1'} and the retired Bot's chat Session is w1. The timer will fire on an archived Bot.

Expected — retirement is a property of resolving a Bot, not of one lookup helper. One resolution boundary (retiredBot applied where the Bot is resolved: memberBot, callMembers' callee resolution, capabilities' rt.findBot use, memory' namedScope) so a retired Bot cannot be woken (rt.deliver never runs, no session is started), cannot gain or lose capabilities, and cannot receive memory writes. Where a name was given, refuse with the same shape the tools already use: No Bot named Writer. Team: Chief, Coder.

For path 5 the fix has two halves, and the second one matters more:

• A. No new armed schedule for a retired target. schedule-create, schedule-copy and schedule-update refuse a retired target with the same No Bot named … shape (existing rows of a live Bot are untouched).
• B. Retiring disarms what is already armed. archiveBot pauses the active schedule rows of its own chat Session before it saves — the same semantics pauseSchedule uses (write state.pausedSchedules, then service.delete), exposed as rt.pauseBotSchedules?.(id); schedules installs after roster in MODULES, so the runtime call is available. If B turns out out of reach, the minimum is that archive_bot's result text says how many schedule rows it left armed — today it is silent, which is the worse failure.

Do not patch each call site with its own copy of the predicate — that is how #1700 grew this follow-up.

Scope — core/src/host/tasks.js (memberBot), core/src/host/groups.js (callee resolution in callMembers), core/src/host/capabilities.js:157, core/src/host/memory.js:516, core/src/host/schedules.js (contentOf, copySchedule, updateSchedule) and core/src/host/roster.js (archiveBot → pause own Session rows); one test per path; docs/subsystems/core-host.md #638 sentence; regenerated patches/ds-bot/** mirror. No new endpoint, no new store, no authz change, no change to the archive/unhide path.

Not in scope, on purpose — restoring a retired Bot. Nothing in the repo writes retired: false; the sidebar/palette "restore" only clears hidden (core/src/client/new-chat.js:104, core/src/client/palette.js:60), so "it can be restored" is a promise the code does not keep. PR #1707 narrows that wording; whether un-retiring should exist at all is a product decision, not part of this issue.

Acceptance

1. Five red-first tests on the then-live main, each reproducing one path above and failing behaviourally (delivery attempted / capability written / memory written / turn taken / a schedule row armed on a retired Bot), not on a missing export.
2. After the fix: retired Bot receives 0 deliveries and starts 0 sessions; capabilities unchanged; no memory entry; the three @Name/assignee/scope: refusals all use the No Bot named <name>. Team: … shape.
3. A live Bot keeps working on all five paths (one delivery, one capability attach, one memory write, one group turn, one accepted schedule).
4. archive_bot on a Bot with two active rows: afterwards that chat has no status:'active' row (paused, visible in state.pausedSchedules), and schedule-create/copy/update targeting it are refused.
5. Live-Bot schedules keep firing after an unrelated archive.
6. TZ=UTC ARCH_DOCS_BASE=<live main> npm run verify exit 0, counts reported; node scripts/ds-bot-patches.mjs check green.

Duplicate check (before opening, per Chief's rule): searched open and closed issues for retired, retire, unreachable, archive → only #1700 (this issue's parent, PR #1707) and #1674 (archive_bot introduction, closed). grep -rn 'retired' core/src/host/ on live main shows retiredBot used only by tools.js. No duplicate; this is the part #1700's absolute sentence does not cover. Path 5 was added 2026-10-29 from FlyBot Product's audit at 2213b4ca (P-169) — it is the same defect shape (a retired Bot still addressable), so it belongs here rather than in a second issue.