Implement meeting transcript platform

[himself65]

Summary

Full implementation of the take-home: a meeting transcript platform built with Next.js 16 (App Router) + TypeScript + Prisma 7 + SQLite — no Docker needed.

npm install
npm run setup   # prisma generate + migrate + seed (3 demo events, one per meeting type)
npm run dev     # http://localhost:3000
npm test        # 63 tests

See DESIGN.md for the data model, async pipeline design, per-type format organization, trade-offs, and what I'd build next.

The four capabilities

1. Calendar events — create/list with title, meeting type, timezone-aware start/end (entered as wall-clock time + IANA zone, stored as UTC instant + zone; conversion is DST-correct via a double-offset lookup, no date library), and status.
2. Two transcript kinds, visible in the data model — RawTranscript (1:1 per event, immutable: no update path, re-attach → 409) and append-only ProcessedTranscriptVersion rows with PIPELINE | MANUAL_EDIT source and a unique (eventId, version). Attach by paste, .txt upload, or one-click sample loading.
3. Automatic async processing — attaching a raw transcript atomically creates a TranscriptJob (PENDING → PROCESSING → COMPLETED | FAILED). Atomic conditional-update claims, an in-process drain loop, and a sweeper (via instrumentation.ts) that recovers PENDING jobs after restarts and resets orphaned PROCESSING rows. Job status is visible in the UI with retry for failed jobs. A transcript containing [[FLAKY]] deterministically fails its first attempt and succeeds on retry — for demoing the failure path.
4. Per-meeting-type formats — a Record<MeetingType, Summarizer> registry: Q&A pairs + key takeaways (expert call), overview/remarks/investor Q&A (roadshow), topics/decisions/action items with owners (weekly group call). All summarizers emit a shared block vocabulary, so storage, API, and rendering are type-agnostic; a fourth type is one enum value + one summarizer file, and forgetting to register it is a compile error.

The processor is a deterministic rule-based mock (parse → clean → summarize); an LLM-backed implementation would replace one function behind the same signature.

Tests (63)

Parser edge cases, cleaner meaning-preservation and idempotence, all three summarizers against the real sample files, job lifecycle (success / parse failure / flaky-retry / atomic claims under concurrency / one-active-job guard for enqueue and retry), sweeper crash recovery, version monotonicity, DST boundary characterization, input validation, and the HTTP route contract (handlers called directly as functions).

🤖 Generated with Claude Code