CedarCopilot wants to merge 2 commits into staging from feat/slack-style-reactions
Live on prod, no production signal yet
OTEL fallback found no prod spans matching apps/mail root meta function since deploy.
OTEL fallback found no prod spans matching ThreadContextCards TasksCard since deploy.
OTEL fallback found no prod spans matching stripQuotedForEditing since deploy.
OTEL fallback found no prod spans matching constructReplyBody since deploy.
OTEL fallback found no prod spans matching cedar-os slackThread empty-chat layout since deploy.
OTEL fallback found no prod spans matching ThreadContextCards selectContextCardsConversationId since deploy.
single_user
Libra has verdicts on 0 of 14 tracked behaviors on prod; 14 are still being checked. Libra checks hourly for 3 days after each deploy.
27 commits off staging. The newest , and the reason this opened now , is the round-2 fix for "threads marked done come back to the inbox"; the rest is the task-ticket view, Slack container scoping, and the daily-agenda split that accumulated on this branch.
Round 1 treated the optimistic removal as an edit and repaired the one window it could name , a listThreads response issued inside the archive round-trip , by re-applying the removal once, the instant the mutation settled. That assumed a 227,380 ms round-trip. Staging measures mail.markDone at up to 7381 ms, and all three resurrections prod ever recorded landed 15.7,18.2 s after the click, every one a fetch-response , seconds after the one-shot repair had already run, with nothing left to oppose them.
So the removal becomes an invariant instead of an edit. While a thread is guarded, any write to a mail.listThreads query that reintroduces it is repaired immediately , late fetch response, IndexedDB restore, side-inbox prefetch and fetchNextPage alike , so we no longer have to name the guilty write. The guard is time-boxed at 60 s; markActive, undo and mutation rollback each call releaseArchivedThreads first, so a legitimate return still lands.
Suppressions now report server-side. The previous round's diagnostic was PostHog-only and the browser reporting the bug sends PostHog nothing , 66 archives on staging produced zero client events , so the fix could never be verified. mail.reportListSuppression writes a structured log:
filter @message like /"message":"mail.listSuppression"/
Two new regression tests cover the exact prod timing (a stale response landing after the mutation settles) and the bulk-archive case; the harness installs the guard the same way QueryProvider does.
Task-ticket view (phases 1,6), Drive files grouped by folder, Slack channel access by membership + container-scoped reads, user_id dropped from the Slack/LinkedIn message tables, meeting visibility follows the deal rather than row ownership, the daily agenda moved to its own automation-only skill so creating a task no longer messages the user, and assorted table/document/notify fixes.
pnpm run autofix:local green on the merged tree: oxlint clean, deps:check clean, 2515 Jest tests, 7265 Vitest tests.origin/staging (4 conflicts resolved: task-update processor field merge, agenda-format.md, tasks/SKILL.md , staging's morning-run edits ported into the new daily-agenda skill , and the saveDraftTool drafting mocks, which follow this branch's applySignature rename).mail.listSuppression to confirm whether late writes are still arriving and from which source.🤖 Generated with Claude Code
The PR introduces a durable archived-thread suppression guard and combines substantial task-ticket, agenda, channel-scoping, Drive, drafting, and schema work.
user_id columns.The PR is not safe to merge until the conversation hydration and LinkedIn suggestion queries are migrated away from the user_id columns being dropped.
Removing the Slack and LinkedIn message user_id
Libra has not measured any production surfaces for this change yet.