Skip to main content

Design overview

Forward-looking design for this project's content-browse platform direction. Hand-written; separate from the auto-generated API reference (../api-reference/) and the auto-generated architecture (../generated/), both of which are produced from source by scripts/gen-docs.sh.

When implementation drifts from these docs, fix one or the other — never leave them inconsistent.

Structure

Three tiers:

  1. Philosophy & contracts — what we're building; what the HTTP shapes look like.
  2. Cross-cutting architecture & ops — how the code is organized, run, and secured.
  3. Per-feature implementation notes (features/) — focused answers to "I'm building or touching X; what do I need to know?"

Tier 1 — Philosophy & contracts

DocRead when
AgnosticUIThinking about the browse UX. Single-kind, Chrome-extension-adapted.
TaxonomyBefore adding an entity or index. Content, Tag, Surface, Group, Channel, Platform.
APIBefore adding an endpoint. Response envelope, pagination, slugs, errors, catalog, search.
AuthBefore adding a guard or role/permission. JWT + refresh, Chrome storage.
ConfigBefore adding an env variable, or when renaming the project. /meta endpoint.

Tier 2 — Cross-cutting

DocRead when
DevelopmentSetting up locally, running tests, seeding, debugging.
OperationsDeploying or operating. Secrets, logging, backups, runbooks.
SecurityThreat model, secrets catalog, rate limits, incident response.
ExtensionBuilding or debugging the Chrome extension. MV3, surfaces, messaging.

Tier 3 — Features

See the features overview. One doc per well-bounded feature or mechanism, each following the same section headings: Purpose → Contract → Implementation → Required variables/services → Gotchas → Testing.

Reading paths

  • Brand-new contributor → this page → Development → pick a feature doc.
  • Building a new endpoint → API → the feature doc for the domain you're touching.
  • Operator → Operations → Security → Config.
  • Extension developer → Extension → Auth → features/catalog → features/content-search.

Relationship to current implementation

The project's current state (User/Role CRUD, no auth) is documented at the repo root in docs/ARCHITECTURE.md and docs/RUNBOOK.md. The design here describes where the project is heading, not what runs today. CLAUDE.md carries a direction-shift banner pointing to this directory.