A runnable application scaffold and reference implementation for Quirk Systems. This repository is not Quirk OS.
The canonical repository identity remains
Quirk-Systems/project-scaffold.
It exists to provide a reusable baseline for starting, testing, and evolving
Quirk projects without forcing every generated project to become the same
product.
See Project Scaffold Identity for the boundary, ownership rules, and change-control contract.
Quirk Wrap specifies how consequential conversation deltas become typed,
source-backed, evaluated repository changes. The proposed runner binds output
to host-owned source hashes, exact canon grants, pinned repository state,
scoped mutation authority, and executor receipts; it preserves corrections and
contradictions and returns an honest no-op when no durable artifact is
justified. See the
capability pack.
- a working Next.js application baseline with TypeScript, Tailwind, testing, CI, security checks, database wiring, and common integrations;
- executable examples of Quirk-domain modules and agent patterns;
- project-start conventions, validation commands, and extraction seams;
- a reference implementation that downstream templates and generated repositories may reuse, fork, replace, or omit.
- Quirk OS canon, kernel authority, or organization-wide runtime governance;
- the central catalog and lifecycle for templates, variables, boilerplates, playbooks, agents, apps, capabilities, or cross-platform skills;
- permission to rename itself because Quirk OS-shaped capabilities happen to be implemented here.
Capability does not imply authority. A reference module can prove a pattern without promoting its containing repository into the system it demonstrates.
The current scaffold includes a substantial asset-lifecycle example:
capture → annotate → mutate → diff → experiment → promote → publish
It includes versioned assets, annotations, semantic diffs, experiments, pipelines, media storage, agent roles, voice composition, billing, email, analytics, and authentication. These modules are deliberately inspectable working examples. Their presence does not change the repository identity.
bun install
cp .env.example .env
bun run devMost integrations are lazy-initialized so the scaffold can build with no secrets. Individual features become active when their required environment variables are configured.
| Command | Description |
|---|---|
bun run dev |
Run the development server |
bun run identity:check |
Verify the repository identity invariants |
bun run validate |
Identity guard, lint, type-check, tests, and build |
bun run db:migrate / db:seed |
Apply migrations / seed example data |
bun run test:e2e |
Run the Playwright suite |
bun run email:dev |
Preview email templates |
The repository is a single application with extraction-ready module boundaries. See Architecture for the implemented reference application's topology and CLAUDE.md for working conventions.
See CONTRIBUTING.md and SECURITY.md.