Danijel Martinek
7b238e401c
Closes the last two staleness threads from the docs audit: 1. data-flow-explainer.html had four "Plan-9" / "post-Plan-9" references in the masthead, lede, fix-up bullet, and bindDevSeed blurb. Stripped — the architecture is now just "vertical-feature". No content changes beyond the noun rename. 2. audit-and-compliance-explainer.html had a footer link to ../superpowers/specs/2026-05-11-audit-and-compliance-design.md (archived to .archive/ earlier). Replaced with a link to ADR-018, which is the durable design record. 3. data-flow-explainer.html + di-explainer.html were inter-linked with audit + conformance explainers, but had no markdown entry point — they were orphans from any guide or architecture doc. architecture/overview.md gains a new "Interactive explainers" section listing all four single-file HTML walkthroughs with one sentence each, so they're discoverable from the documented entry point. The four pages already cross-link to each other. Final state (verified by repo-wide grep): zero "Plan-N" / "Phase-N" / "docs/superpowers/" references in docs/ (excluding .archive/ which is gitignored). Legitimate `superpowers:brainstorming` skill refs in agent-first-workflow-and-conformance.md are preserved — those reference an external plugin, not a repo path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
147 lines
8.3 KiB
Markdown
147 lines
8.3 KiB
Markdown
# Architecture Overview
|
|
|
|
A vertical-feature monorepo. Business capabilities are top-level packages; non-business foundations are `core-*`.
|
|
|
|
## Package map
|
|
|
|
```
|
|
packages/
|
|
# Must-have foundation (no business logic)
|
|
core-shared/ Generic primitives — Payload field/block helpers, tRPC init/context,
|
|
instrumentation interfaces, audit protocol + truncate-ip + AuditEntry shape,
|
|
BindContext + protocol types for optional cross-cutting cores
|
|
core-cms/ Composition only: assembles feature CMS exports into one Payload config
|
|
core-api/ Composition only: aggregates feature tRPC routers into one appRouter
|
|
|
|
# Optional cross-cutting cores (scaffold on demand via `pnpm turbo gen core-package <name>`)
|
|
core-trpc/ Frontend tRPC client + per-framework providers (Next.js, TanStack)
|
|
core-ui/ Design-system primitives (atoms, molecules, generic organisms, templates)
|
|
core-realtime/ Socket.IO server + broadcaster + handler registry (ADR-016)
|
|
core-events/ In-memory + Payload-backed event bus + job queue (ADR-015)
|
|
core-audit/ DPA-compliant audit logging — sinks, hook factories, eraseSubject (ADR-018)
|
|
|
|
# Business capabilities
|
|
auth/ Users + sign-in/sign-up/sign-out + session/cookie domain
|
|
blog/ Articles collection + publishing flow
|
|
media/ Media upload collection (skeleton; expand with optimization, CDN, etc.)
|
|
marketing-pages/ Pages collection + SiteSettings global
|
|
navigation/ Header global + menu items
|
|
|
|
# Tooling
|
|
core-eslint/ Shared ESLint flat config + boundary rules
|
|
core-typescript/ Shared tsconfig + vitest base
|
|
```
|
|
|
|
See `docs/architecture/template-tiers.md` for the must-have/optional split and the scaffold commands.
|
|
|
|
## Data flow
|
|
|
|
```
|
|
React component
|
|
↓ useQuery(trpc.blog.articleBySlug.queryOptions({slug})) ← @repo/<feature>/ui (queries)
|
|
HTTP /api/trpc
|
|
↓
|
|
tRPC procedure (xProcedure.input(xInputSchema)) ← integrations/api/router.ts
|
|
↓ xProcedure has defineErrorMiddleware applied ← integrations/api/procedures.ts
|
|
↓ container.get<IXController>(SYMBOL)
|
|
Controller factory (xInputSchema.safeParse) ← interface-adapters/controllers/<verb-noun>.controller.ts
|
|
↓ (useCase) => async (input: unknown) => Promise<view>
|
|
Use case factory ← application/use-cases/<verb-noun>.use-case.ts
|
|
↓ (deps) => async (input: XInput) => XOutput
|
|
↓ ends with xOutputSchema.parse(result)
|
|
Repository implementation ← infrastructure/repositories/<noun>.repository.ts
|
|
↓ getPayload({ config })
|
|
Payload Local API → Postgres
|
|
↓ on throw:
|
|
domain error → defineErrorMiddleware → TRPCError(code, cause)
|
|
↓ on success:
|
|
controller's `function presenter(value: XOutput)` shapes the view
|
|
↓
|
|
tRPC response
|
|
```
|
|
|
|
Use cases and controllers are **factory functions** — they take their dependencies
|
|
as arguments and return the callable. The container wires them via
|
|
`.toDynamicValue((ctx) => factoryFn(ctx.container.get(...)))`. Each exports
|
|
`export type I*UseCase = ReturnType<typeof xUseCase>` (and the analogous
|
|
`I*Controller`) so consumers can depend on the type without importing the impl.
|
|
Controllers are **one per use case** — no multi-method controller files.
|
|
|
|
**Schemas live in the use-case file**: every use case exports
|
|
`xInputSchema` (a `z.ZodObject` with `.strict()`; `z.object({}).strict()` for
|
|
void inputs) and, for non-void use cases, `xOutputSchema`. Controllers and tRPC
|
|
procedures import the schema — never redefine it. The use case body validates
|
|
its output via `xOutputSchema.parse(...)` before returning, so a misbehaving
|
|
repository fails loudly at the layer that owns the contract.
|
|
|
|
**Controllers reshape via a co-located presenter**: every non-void
|
|
controller defines a top-level `function presenter(value: XOutput)` and returns
|
|
`Promise<ReturnType<typeof presenter>>`. Identity is fine — `return value;` —
|
|
but the function form is always present so adding a transform later is a
|
|
one-line edit. Void controllers (e.g. `signOutController`,
|
|
`deleteMediaController`) return `Promise<void>` and skip the presenter.
|
|
|
|
**Domain errors map to `TRPCError` per feature**: each feature owns
|
|
`integrations/api/procedures.ts` exporting `xProcedure = t.procedure.use(
|
|
defineErrorMiddleware([[Ctor, "TRPC_CODE"], ...]))`. Routers use `xProcedure`
|
|
instead of bare `publicProcedure`. `core-shared` provides the
|
|
`defineErrorMiddleware` factory but never enumerates a feature's errors —
|
|
each feature passes its own constructors in.
|
|
|
|
## Three enforcement layers
|
|
|
|
1. **`package.json` deps** — only declare allowed deps
|
|
2. **`exports` map** — each package exposes a small public surface (`.`, `./cms`, `./api`, `./di/bind-production`)
|
|
3. **Two parallel automated checks**:
|
|
- **ESLint `eslint-plugin-boundaries`** (lint-time) — enforces boundary rules at linting
|
|
- **Turborepo `boundaries`** (build-graph time) — validates entire workspace dependency graph, including transitive reaches
|
|
|
|
Both use the same five-tag model; see "Five tags" section below.
|
|
|
|
## Five tags
|
|
|
|
The workspace is organized into five mutually exclusive tags:
|
|
|
|
- **app** (4 packages): `apps/cms`, `apps/web-next`, `apps/web-tanstack`, `apps/storybook`
|
|
- **core-composition** (2 must-have): `packages/core-api`, `packages/core-cms`. Plus `packages/core-trpc` when scaffolded via `pnpm turbo gen core-package trpc` (optional).
|
|
- **core** (1 must-have): `packages/core-shared`. Plus `packages/core-ui`, `packages/core-realtime`, `packages/core-events`, `packages/core-audit` when scaffolded via `pnpm turbo gen core-package <name>` (optional).
|
|
- **feature** (5 packages): `packages/auth`, `packages/blog`, `packages/media`, `packages/marketing-pages`, `packages/navigation`
|
|
- **tooling** (2 packages): `packages/core-eslint`, `packages/core-typescript`
|
|
|
|
See `docs/architecture/template-tiers.md` for the must-have/optional split and the scaffold commands.
|
|
|
|
**Allowed dependency directions:**
|
|
|
|
| Tag | May depend on |
|
|
| ---------------- | --------------------------------------------- |
|
|
| app | app, core, core-composition, feature, tooling |
|
|
| core-composition | core, core-composition, feature, tooling |
|
|
| core | core, core-composition, tooling |
|
|
| feature | core, tooling |
|
|
| tooling | tooling |
|
|
|
|
**Composition exceptions:**
|
|
|
|
- `core-api` may import from `@repo/<feature>/api` subpath exports only
|
|
- `core-cms` may import from `@repo/<feature>/cms` subpath exports only
|
|
- `core-trpc` reaches features transitively through `core-api`'s `AppRouter` type
|
|
|
|
## Per-feature DI containers
|
|
|
|
Each feature owns its own InversifyJS `Container` + symbol table. No shared symbols, no cross-feature DI coupling. Tests rebind per feature without touching others. Apps call `bindProduction*(config)` per feature at boot to swap the default mock implementations for Payload-backed ones.
|
|
|
|
## Spec reference
|
|
|
|
`docs/architecture/vertical-feature-spec.md` is the canonical design.
|
|
|
|
## Interactive explainers
|
|
|
|
Four single-file HTML walkthroughs sit alongside this overview. They're self-contained (no build step) and best viewed locally in a browser.
|
|
|
|
- [`data-flow-explainer.html`](./data-flow-explainer.html) — request and event flow through one feature, with the DI binding mode toggle and feature swap controls.
|
|
- [`di-explainer.html`](./di-explainer.html) — the full container + symbols + binder lifecycle.
|
|
- [`feature-conformance-explainer.html`](./feature-conformance-explainer.html) — companion to ADR-020-adjacent conformance design (also linked from `agent-first-workflow-and-conformance.md` and `runbook.md`).
|
|
- [`audit-and-compliance-explainer.html`](./audit-and-compliance-explainer.html) — companion to ADR-018 (also linked from `dependency-flow.md` and `guides/audit-and-compliance.md`).
|
|
|
|
The four pages cross-link to each other; entering any of them surfaces the others.
|