ThesisOS
Org-scoped academic workspace: framing from the brief, section structure, references, and export discipline, not a generic chat wrapper.
The Problem
Serious coursework and thesis work scatter across Word, Zotero, email, and ad-hoc AI chats. ThesisOS keeps the brief, outline, sections, citations, and governance in one tenant-bound workspace. Assistance is task-scoped and labelled; the writer approves framing before structure becomes real.
Architecture
Turborepo: Vite SPA (apps/web), shared packages (api, db with ElectroDB, types), AWS CDK infra
HTTP API: six module Lambdas (auth, orgs, workspaces, content, jobs, billing) with an in-process router
DynamoDB single-table app data + separate collab table for Y.js ops; S3 for snapshots and uploads; SQS workers (context docs, cohesion, export, integrity, events)
Cognito (Google + email OTP), refresh token in HttpOnly cookie; API uses Bearer access JWT and path-scoped org membership checks
Intelligence Lambda: AWS Bedrock for framing (outline + confidence gaps), gap patches, directed assist; DNA packs for institution defaults
Engineering Decisions
Why DynamoDB and Lambda modules instead of a always-on database?
ThesisOS is multi-tenant and serverless-first: pay-per-use storage and compute, org isolation in the key design, and the same plane already holds Y.js op chunks. ElectroDB keeps single-table access patterns typed.
Why is framing a hard gate?
Downstream rubric, drift, and export checks only make sense against an approved frame. The API creates sections from the outline only after explicit approve, so the workspace does not pretend structure exists before the user commits.
Why WebSocket + Lambda relay for collaboration instead of a long-lived server?
Clients merge Y.js CRDT updates locally; the server relays ops and awareness. That avoids a fixed Fargate bill at low traffic while keeping collaboration acceptable for thesis-scale editing.