Template

Files

Danijel Martinek 9ee941863d refactor(marketing-pages)!: delete marketing-pages demo feature

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

2026-07-12 17:23:08 +02:00

2.0 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 { 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:

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

2.0 KiB Raw Blame History