Danijel Martinek
98d96d2e19
Amends ADR-022 §9 with the `is-sub-processor` / `processes-pii` discriminated union spec, including the five conditional fields required when a library is a true GDPR sub-processor. Updates the evaluate-library skill to prompt for these fields during every trace authoring pass and adds the updated frontmatter template. Backfills all nine existing library-decision traces with the new fields; payload gets `processes-pii: true` (self-hosted CMS that stores user data); all pure in-process libraries get `false / false`. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.4 KiB
package, version, tier, decision, date, deciders, adr, lastRevalidated, is-sub-processor, processes-pii, filter-results, verification-commands, accepted-cves
| package | version | tier | decision | date | deciders | adr | lastRevalidated | is-sub-processor | processes-pii | filter-results | verification-commands | accepted-cves | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| payload | ^3.14.0 | core | approved | 2026-05-14 |
|
null | null | false | true |
|
|
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.