Danijel Martinek
1108e24ea0
Add approved trace files for payload, @trpc/server, @trpc/client, zod, superjson, @payloadcms/db-postgres, @payloadcms/richtext-lexical, globals, react, react-dom, vitest, @tanstack/react-query, and all @testing-library/* packages. All traces dated 2026-05-14, decision: approved, adr: null. Establishes the baseline so the pre-commit library-decisions gate is additive (new deps require traces) rather than disruptive (old deps fail immediately). All 34 trace files pass validateTrace() from schema.mjs. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.4 KiB
package, version, tier, decision, date, deciders, adr, filter-results, verification-commands, accepted-cves
| package | version | tier | decision | date | deciders | adr | filter-results | verification-commands | accepted-cves | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| payload | ^3.14.0 | core | approved | 2026-05-14 |
|
null |
|
|
Filter: license
npm view payload license returns MIT. MIT is on the allowlist.
Filter: types
Payload CMS is authored in TypeScript and ships its own .d.ts declaration files. No separate @types/payload package is needed.
Filter: maintenance
Actively maintained by the Payload CMS team. The 3.x line is the current major and receives regular releases. Last release < 18 months, active issue tracker.
Filter: boundary-fit
Payload CMS is the workspace CMS and repository backend. Feature packages (@repo/auth, @repo/blog, etc.) use Payload as the data layer via the repository pattern (ADR-002). core-cms and core-shared use Payload directly. ESLint boundary rules restrict direct Payload queries to repository implementations only — feature packages MUST NOT call payload.* outside their repository files.
Filter: shadow-check
Payload is the sole CMS and ORM-like data layer in the workspace. No competing headless CMS or database abstraction (Strapi, Sanity, Prisma, etc.) is present or proposed.
Filter: eu-residency
Payload CMS is a fully self-hosted solution. No data is transmitted to Payload-controlled endpoints at runtime. EU residency is inherent; the deployment environment controls data location.
Filter: cve-scan
pnpm audit --audit-level=moderate reports no advisories against payload at the time of this trace.
Filter: named-consumer
All five feature packages (@repo/auth, @repo/blog, @repo/media, @repo/marketing-pages, @repo/navigation) use Payload for repository access. @repo/core-cms configures the Payload instance. @repo/core-shared receives Payload config at constructor time. Named, non-hypothetical consumers exist today.
Prompt: replaces
Payload CMS replaces hand-rolled REST API + ORM patterns that would require maintaining a separate data layer, schema migrations, and admin UI from scratch. No parallel CMS is running.
Prompt: migration-cost-out
Hard. Payload is the data store for all content (articles, users, media, navigation). Migrating out requires replacing every repository implementation across five feature packages, the CMS configuration in core-cms, the admin UI, and all database schema definitions. The repository interface boundary (ADR-002) limits the feature-layer surface to repository implementations only, reducing blast radius, but the volume and data-format dependencies make migration substantial.
Prompt: alternatives-considered
- Strapi — Evaluated but rejected; weaker TypeScript support at the time and less flexible content modeling for mixed structured + rich-text content.
- Sanity — SaaS-first model raises EU residency concerns without a self-hosted plan; Payload's self-hosted model is a better fit for the compliance profile.