Add pluggable inbound-webhook framework + Granola meeting summarizer

[Miyamura80]

Summary

Two things: a pluggable inbound-webhook framework (with the first source, a Granola meeting summarizer), and the macOS deployment work needed to actually run it as a managed service.

1. Generic webhook framework

Each source is a factory (ctx: { bot }) => { path, handler } exported from webhooks/<name>.ts. index.ts mounts every factory under Bun.serve({ routes }). Adding a new source = drop a file + one line in index.ts.

Shared conventions (documented in CLAUDE.md):

• Auth via X-Webhook-Secret: $WEBHOOK_SECRET.
• Per-source dedup via Redis SET key NX EX 604800 (7-day TTL) — retried deliveries return 200 without re-processing.
• Handlers return 200 immediately and process in the background, so emitter timeouts can't trigger retry storms while Codex is generating.
• On background-processing failure, post a :warning: notice to the same Slack channel so issues are visible instead of silently swallowed.

2. Granola source

POST /api/webhooks/granola accepts { meeting_id, title, transcript, notes?, attendees? }, asks Codex for a Slack-formatted wrap-up (header + 3-5 bullets + optional action items), and streams it into GRANOLA_SLACK_CHANNEL_ID (#edison-os-updates) via bot.channel("slack:Cxxx").post(streamCodex(...)).

Refactor: extracted streamCodex out of index.ts into lib/codex.ts so onNewMention and webhook handlers share one implementation, and it now awaits the subprocess and throws on non-zero exit instead of silently yielding an empty summary.

3. Deployment (launchd)

The bot now runs as a launchd-managed service — auto-starts, auto-restarts on crash, survives reboot. deploy/com.edison.assistant-bot.plist is a checked-in template (no secrets; env comes from .env in WorkingDirectory), and docs/DEPLOY.md covers install/manage plus two non-obvious gotchas that cost real debugging time:

• Repo on an external volume needs Full Disk Access. macOS TCC blocks launchd-spawned processes from read()-ing file contents on external/removable volumes — ls works, read() returns EPERM. Symptom is a PID with an empty log and nothing listening on 3123. Fix is granting FDA to the bun binary.
• codex CLI on a revoked-cert build hangs. v0.129.0 assessed as CSSMERR_TP_CERT_REVOKED and stalled in _dyld_start before main() on every invocation, including --version. npm install -g @openai/codex@latest (0.144.0) fixes it. Includes the spctl --assess diagnostic.

Files

• webhooks/types.ts — WebhookContext, WebhookRoute, WebhookFactory
• webhooks/granola.ts — Granola handler
• lib/codex.ts — shared streamCodex
• index.ts — wires the webhooks array into Bun.serve({ routes })
• deploy/com.edison.assistant-bot.plist — LaunchAgent template
• docs/DEPLOY.md — install, management, and the two gotchas above
• .env.example — adds WEBHOOK_SECRET and GRANOLA_SLACK_CHANNEL_ID
• CLAUDE.md — documents the inbound-webhook conventions + links docs/DEPLOY.md

Setup

1. Add to .env:

   WEBHOOK_SECRET=<something long and random>
   GRANOLA_SLACK_CHANNEL_ID=<Slack channel ID of #edison-os-updates>
   

2. Make sure local Redis is running (brew services start redis).
3. Install the LaunchAgent per docs/DEPLOY.md.

Test plan

• Bot starts cleanly and logs both POST /api/webhooks/slack and POST /api/webhooks/granola.
• Missing/invalid X-Webhook-Secret returns 401.
• Valid request returns 200 immediately and a streamed wrap-up lands in #edison-os-updates.
• Replaying the same meeting_id returns 200 Duplicate (already processed) and does not post a second message.
• Missing required fields returns 400.
• bunx tsc --noEmit is clean.
• Survives a reboot — agent auto-starts without an interactive login, KeepAlive retries while the external volume mounts.
• Existing @mention flow still streams a Codex reply (regression check on the streamCodex extraction) — not yet verified, see below.

Known follow-ups (not in this PR)

• Slack @mention path is unverified. The Slack app's Request URL still needs pointing at the current public endpoint for both Event Subscriptions and Interactivity & Shortcuts, with Socket Mode off.
• Ingress hardening. X-Webhook-Secret is a static, replayable bearer compared non-constant-time, and the JSON body has no size cap. Should move to HMAC-over-body + timestamp.
• Process isolation. The bot currently runs as the primary user account and, because the checkout lives on an external volume, holds Full Disk Access. Planned: move the runtime checkout to the boot volume, run it under a dedicated unprivileged service account as a LaunchDaemon, and drop the FDA grant entirely.

---

Generated by Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[cubic-dev-ai]

3 issues found across 6 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="webhooks/granola.ts">

<violation number="1" location="webhooks/granola.ts:42">
P2: Validate payload types before property access; non-object JSON can currently throw and return 500.</violation>

<violation number="2" location="webhooks/granola.ts:65">
P2: Normalize `attendees` to an array before joining; current code can throw before the catch block.</violation>
</file>

<file name="lib/codex.ts">

<violation number="1" location="lib/codex.ts:35">
P2: Validate the Codex subprocess exit code before returning; non-zero exits are currently treated as success.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Fix all with cubic | Re-trigger cubic}

[Eito-Test-Account]

Deployment captured in-repo (0bb7814)

The bot is now running as a macOS launchd LaunchAgent on the Mac mini — auto-starts on login, auto-restarts on crash, verified across a real reboot (survived ~14h unattended; the post-reboot Granola→Slack summary posted fine).

Added so this isn't tribal knowledge:

• deploy/com.edison.assistant-bot.plist — LaunchAgent template (RunAtLoad + KeepAlive, direct bun run index.ts, no secrets; env still loads from .env).
• docs/DEPLOY.md — install/manage commands + the two gotchas we hit:
  1. External/removable-volume TCC — this checkout lives on a USB volume (/Volumes/Data, via the ~/Github symlink). launchd-spawned processes get EPERM reading file contents there (metadata/ls works), so the agent starts but never binds :3123 and logs nothing. Fix: grant Full Disk Access to /opt/homebrew/bin/bun (re-add after brew upgrade bun).
  2. codex revoked cert — the Granola handler's codex CLI hung on every invocation (stuck in _dyld_start); spctl --assess reported CSSMERR_TP_CERT_REVOKED on the 0.129.0 build. Fix: npm install -g @openai/codex@latest (0.144.0 assesses clean).

No application/runtime code changed — this commit is docs + a plist template only.

[cubic-dev-ai]

All reported issues were addressed across 3 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>