Curated, product-agnostic snapshot of the post-story-04 tree: demo content deleted, auth-only reference feature, web-next shell, all gates green. Product-specific docs, ADRs 027-029, PRDs/epics/archive, editor library traces, and product naming are curated out; generic template repairs (coverage provider devDeps, root test:coverage script, live lint fixes, root-only release-please) are kept. See TEMPLATE.md for provenance, curation list, and usage. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK
1004 B
1004 B
ADR-004: Dual-Mode Payload Client (Local + HTTP)
Status: Accepted
Context
Apps need to access Payload CMS data. Payload 3.x offers both Local API (direct) and REST API (HTTP).
Decision
@repo/cms-client supports both modes via createPayloadClient().
Rationale
- Local mode (primary): Direct Payload instance access — no HTTP overhead, full query capabilities (where, sort, limit, depth, page, populate). All server-side apps use this.
- HTTP mode (fallback): REST API for external consumers without access to a Payload process.
- Payload instance is injected at app startup, not imported — keeps cms-client standalone.
- Both modes share the same
PayloadClientinterface — consumers don't know which mode is active.
Status: Superseded by ADR-007 (2026-05-04)
The dual-mode client wrapper was deleted. Feature payload-backed repositories now call getPayload({ config }) directly with the assembled config injected via constructor. See ADR-007 for rationale.