feat(daemon): Slack thread-to-agent bidirectional linking (FRI-47)

[sethvoltz]

Summary

Implements bidirectional Slack thread ↔ agent linking (FRI-47). Once connected, a user can converse directly with a running Builder or Helper in a Slack thread without routing every message through the Orchestrator.

What changed

New files:

• packages/shared/src/db/threads.ts — Drizzle query helpers for thread_connections
• packages/shared/drizzle/0001_aromatic_shocker.sql — migration adding thread_connections table
• services/friday/src/slack/thread-registry.ts — in-memory maps + SQLite persistence, idle timers, startup recovery
• services/friday/src/slack/thread-tools.ts — orchestrator-only MCP server: thread_connect / thread_disconnect
• services/friday/src/slack/thread-registry.test.ts — 13 registry tests
• services/friday/src/slack/thread-tools.test.ts — 6 tool handler tests

Modified files:

• packages/shared/src/db/schema.ts — adds threadConnections table definition
• packages/shared/src/db/index.ts — exports threads query helpers
• services/friday/src/agent/tools.ts — adds optional thread_ts param to slack_reply
• services/friday/src/agent/lifecycle.ts — adds notifyThreadConnect / notifyThreadDisconnect
• services/friday/src/agent/worker.ts — self-constructs createSlackTools(new WebClient(SLACK_BOT_TOKEN)) in allMcpServers (workers run in child_process.fork — live objects can't cross IPC)
• services/friday/src/agent/prime.ts — thread connection docs in orchestrator, builder, helper prompts
• services/friday/src/slack/events.ts — thread message routing: if thread_ts is connected, forward to agent via mail, skip orchestrator queue
• services/friday/src/slack/helpers.ts — adds addReaction / removeReaction with permanent/transient error classification, 6 new tests
• services/friday/src/index.ts — wires initThreadRegistry (with onIdleDisconnect callback) and friday-threads MCP server
• docs/architecture.md — new modules, thread message flow path, thread_connections table, updated test coverage
• docs/decisions.md — ADR-023: why thread_connections lives in existing friday.db

Message flow examples

Initial connect: Orchestrator calls thread_connect → :link: added → thread post "Connected to builder-foo" → agent receives mail with channel_id + thread_ts

User message + agent reply: User types in thread → events.ts detects thread_ts → mailSend [thread] hello → agent wakes → calls slack_reply with thread_ts → reply lands in thread

Idle timeout (2h): Timer fires → thread post "Disconnected (idle timeout)." → :link: removed → agent notified

Manual disconnect: thread_disconnect("builder-foo") → thread post "Disconnected." → :link: removed → agent notified

Stolen connection: New thread_connect for same agent → old thread gets "Disconnected — agent connected to new thread: " → :link: removed from old anchor → new connection established

Architecture decisions

• No new packages / db file. thread_connections is a Drizzle migration on the existing friday.db — agent_name PK + thread_ts UNIQUE enforce 0-or-1 at the DB level (see ADR-023 in decisions.md).
• Workers self-construct Slack tools. worker.ts runs in child_process.fork() — live WebClient objects cannot be passed over IPC. Each worker creates new WebClient(process.env.SLACK_BOT_TOKEN).
• Thread tools are orchestrator-only. friday-threads is injected only into the orchestrator's MCP server maps. Builders/helpers receive thread connections via mail and reply via slack_reply.

Test plan

• pnpm test — 374 tests, 27 test files, all pass
• pnpm --filter @friday/daemon exec tsc --noEmit — clean
• pnpm --filter @friday/shared build — clean
• thread-registry: connect/disconnect, 0-or-1 constraint, stolen-connection, touchActivity, idle timer, startup recovery
• helpers: reaction success, permanent errors (message_not_found, already_reacted, no_reaction), transient errors (ratelimited, request_timeout)
• thread-tools: happy paths for connect/disconnect, agent-not-found, thread-owned, stolen-connection

🤖 Generated with Claude Code