Template

Files

Danijel Martinek 2c2375920f docs: reflect tooling-package rename + Turbo boundaries enforcement

- Rename eslint-config → core-eslint, typescript-config → core-typescript
  in all docs (package map, AGENTS.md, overview.md, dependency-flow.md, etc.)
- Document the five-tag model (app, feature, core, core-composition,
  tooling) — refinement of ADR-006's three-tag mention
- Document core-trpc's core-composition tag (transitively reaches features
  through core-api's AppRouter type)
- Note Turborepo boundaries as a second enforcement layer alongside ESLint
- Add ADR-010 explaining the two-layer enforcement decision and
  five-tag refinement

Files updated:
- docs/architecture/overview.md: package map, enforcement layers, five-tag section
- docs/architecture/dependency-flow.md: boundary rules, enforcement strategy
- docs/architecture/vertical-feature-spec.md: package names, five-tag model
- AGENTS.md: package map, boundary rules, commands
- CLAUDE.md: tooling package names, quick-start command
- packages/core-eslint/AGENTS.md: tag clarification
- packages/core-typescript/AGENTS.md: tag clarification
- packages/core-api/AGENTS.md: core-composition tag
- packages/core-cms/AGENTS.md: core-composition tag
- packages/core-trpc/AGENTS.md: core-composition tag + rationale
- docs/decisions/adr-010-turbo-boundaries.md: new ADR

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-05 12:24:04 +02:00

1.8 KiB

Raw Blame History

AGENTS.md — core-cms

Tag: core-composition

Composition-only package that aggregates feature Payload collections and globals into a single Payload config. It does not define its own collections; instead, it imports them from feature packages.

Responsibilities

Compose Payload config — buildConfig() with all collections and globals from features
Type generation — Output generated-types.ts from Payload's TypeScript generator
No collection definitions — all collections owned by their respective features (@repo/auth, @repo/blog, etc.)
No business logic — purely structural assembly

Allowed imports

@repo/<feature>/cms subpath exports only (to get collections/globals)
- e.g., import { articles } from "@repo/blog/cms"
- e.g., import { users } from "@repo/auth/cms"
- e.g., import { pages, siteSettings } from "@repo/marketing-pages/cms"

Must NOT import

Any feature's root package or other subpaths (e.g., NOT @repo/blog/di, NOT @repo/blog/entities)
Any app package
@repo/core-shared, @repo/core-api, @repo/core-trpc, @repo/core-ui

Public exports

From package.json:

. — the Payload config (default export) + buildConfig re-export
./generated-types — Payload-generated TypeScript types

Example usage:

import { buildConfig } from "@repo/core-cms";
// or
import type { Config, User, Article } from "@repo/core-cms/generated-types";

Test conventions

No unit tests (composition layer)
Verify at app boot: pnpm dev --filter @repo/cms succeeds and admin UI loads
Type generation: pnpm generate:types in apps/cms

Structure

src/
  payload.config.ts          # imports feature /cms exports, calls buildConfig()
  generated-types.ts         # auto-generated by Payload
  index.ts                   # re-exports config

1.8 KiB Raw Blame History