Task GC in long sessions leaves TaskGet returning 'Task not found' — metadata reads break

[michael-wojcik]

Symptom

In a long orchestration session (~2h, many agents/tasks), completed tasks get GC'd from the platform task store. TaskGet(<id>) then returns "Task not found", breaking PACT flows that read task metadata (metadata.handoff, metadata.teachback_submit, metadata.intentional_wait, completion-authority reads).

Evidence

Observed in a reflectica webapp-frontend session (PACT 4.4.53):

• TaskGet(#20) returned "Task not found" after the sec-reviewer completed its review — the secretary recovered the HANDOFF from the session journal (the durable source), not from the task.
• A teammate repeatedly reported its task view as "No tasks found" after completing tasks.
• TaskUpdate(#14) on an already-completed task also returned "Task not found."

Impact

PACT protocols that rely on TaskGet for metadata silently fail once the task GCs. The durable fallbacks exist — the raw task file (cat ~/.claude/tasks/{team}/{id}.json | jq .metadata.handoff) and the session journal — but agents/leads hit the bare "Task not found" error first and must rediscover the fallback.

Asks (any)

1. Better error: when a task is GC'd, surface a hint ("task GC'd — read the session journal / raw task file at …") instead of a bare "Task not found," so the fallback path is discoverable.
2. Docs: document the GC behavior + journal-as-source-of-truth fallback more prominently in the agent-teams / completion-authority protocols.
3. Durability pin: agent_handoff_emitter.py already journaled handoffs at write-time (which saved us here) — consider extending that guarantee to teachback_submit / intentional_wait so every metadata read has a durable source even post-GC.