Summary

Second PR from the same latency/staleness investigation as #2775 (dispatch ordering). This one covers the two remaining pieces: making the playbook documents describe the order that's now actually true, and closing the actual stale-context/duplicate-output gap.

1. Playbook reorder migration , already applied

Moves strategist/next-steps (with their prose, correctly kept attached to whichever ref it precedes) to the tail of every account's <trigger type="any"> block, matching what the orchestrator dispatches at runtime after #2775. Already run for real against the full active cohort: 56/57 succeeded, 1 correctly skipped (an eligibility edge case, not guessed at) and fixed by hand in scripts/manual-fix-jacob-reorder.ts. Every account's before/after state was independently read back from Postgres via a separate DOM-based verifier (not the migration's own logic) , see commit message for full detail.

2. Live pre-output re-validation gate

Traced both incidents to the same underlying gap: a subagent decides to draft or alert from a conversation snapshot frozen at the start of its run, and nothing re-checks it before acting , even though the run can sit queued for minutes. Directly measured: a rep's own reply was sent 2m47s after the trigger and wasn't visible in Cedar's own synced conversation state for another 16m35s , so a re-check against Cedar's own database would have caught nothing. Only a live mailbox fetch, bypassing Cedar's sync pipeline entirely, can catch this in time.

checkThreadForNewerActivity (staleness-check.ts) fetches the live thread and flags a newer non-draft message (the rep already replied) or an existing draft (already asked Cedar via chat) , wired into both places a subagent actually produces output: the drafter dispatch and the generic custom-subagent path (covers inbound-email-notifier and similar). Degrades to null on any failure rather than ever blocking the pipeline. For brand-new threads, added a prompted search-live-emails check to the drafter's own instructions instead, since the deterministic check only covers the thread that triggered the run.

Test plan

• New unit tests (staleness-check.test.ts) , newer-reply, existing-draft, nothing-changed, connection/API failure, unparseable-timestamp cases
• Existing runSubagentTool/drafter-executor-prompt suites (54 tests) pass unchanged
• pnpm --filter @zero/server run types clean
• oxlint --deny-warnings clean on every changed file
• Migration dry-run reviewed before the real --apply run; live DB read back independently afterward for multiple accounts across every distinct shape (simple, custom-subagent-spliced, the most complex multi-sequencer account, and the manually-fixed edge case)
• Deploy to staging and watch a live execution's tool-call trace to confirm the live-thread check actually fires and reads correctly against a real mailbox (unit tests mock getThread)

Related

• #2775 (dispatch ordering , merge first if not already)

🤖 Generated with Claude Code

https://claude.ai/code/session_01WDwXHeMTJKLmcSjj1msiuS

Greptile Summary

This PR adds a playbook-order backfill and injects mailbox staleness context before drafter and custom-subagent execution.

• Reorders strategist and next-steps chunks while preserving adjacent prose.
• Adds a thread-activity helper and wires it into both output-producing dispatch paths.
• Adds prompt guidance for duplicate suppression on existing and new threads.
• The current mailbox read remains cache-first, and the check still precedes potentially lengthy model execution.
• Externally controlled mailbox text is inserted into a trusted prompt block without escaping.

Confidence Score: 1/5

This PR is not safe to merge until the staleness gate performs a genuinely live read at the output boundary and untrusted mailbox fields are safely delimited.

The ca