Danijel Martinek
9ee941863d
Veect retrofit (ADR-027): fourth slice of the demo-content removal. Deletes packages/marketing-pages whole and prunes every composition edge in one commit: core-api router mount + dep, core-cms collection/global composition + dep + regenerated Payload types, web-next bindAll (prod + dev-seed) + tests + about page + Tailwind source + transpilePackages + dep, cms/core-cms payload config test assertions, marketing-page e2e spec, tsconfig paths, fallow ignore entry, anchor-guard + generator e2e feature lists, compliance data-map + retention-policy regeneration, lockfile prune, and feature-list doc entries (CLAUDE.md, AGENTS.md, glossary, app/feature AGENTS.md). Event teardown: marketing-pages was the sole consumer of auth.user.signed-up (welcome-email handler + job). The handler, its Payload tasks, and the bus subscription all lived inside the package's own binders, so they die with it — no other package wires the subscription. Auth's manifest `publishes` stays untouched: a publisher with zero consumers is legal (pnpm conformance only fails on orphan consumers, verified green). The app-level sign-up-welcome-email test asserted the marketing-pages mailer stays empty without a bus; it is deleted with the feature, and the now-unused test-only bind-state helpers in web-next bind-production.ts go with it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK
58 lines
2.0 KiB
Markdown
58 lines
2.0 KiB
Markdown
# 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 { header } from "@repo/navigation/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`
|
|
|
|
> Note: `@repo/core-trpc` and `@repo/core-ui` are optional packages scaffolded via `pnpm turbo gen core-package trpc` / `ui`. If not present, these constraints still apply to any future installation.
|
|
|
|
## Public exports
|
|
|
|
From `package.json`:
|
|
|
|
- `.` — the Payload config (default export) + buildConfig re-export
|
|
- `./generated-types` — Payload-generated TypeScript types
|
|
|
|
Example usage:
|
|
|
|
```typescript
|
|
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
|
|
```
|