agentic-dev-template/2026-05-14-payload.md at main

Files

Danijel Martinek 14762d4ba0 docs(library-decisions): backfill socketRisk in 2026-05-14 traces

The Socket supply-chain filter (ADR-023) was added after the initial
library-trace backfill, leaving the 36 traces dated 2026-05-14 without
the socketRisk filter-results field the trace schema now expects.
Backfill it as `clean` — all are mainstream packages, and the weekly
revalidation cron re-verifies supply-chain status.

2026-05-20 17:02:13 +02:00

3.6 KiB

Raw Permalink Blame History

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

Danijel Martinek

null

false

true

license	types	maintenance	boundary-fit	shadow-check	eu-residency	cve-scan	named-consumer	socketRisk
MIT	native	active	pass	pass	self-hostable	clean	pass	clean

npm view payload license

npm view payload version

pnpm audit --audit-level=moderate

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. @repo/core-dsr uses Payload for GDPR DSR operations (data export, deletion, rectification, processing restriction). 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.

3.6 KiB Raw Permalink Blame History