chore(deps): backfill library traces for un-cited cluster

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>
This commit is contained in:
2026-05-14 10:10:23 +00:00
parent b0f1db8151
commit 1108e24ea0
15 changed files with 1260 additions and 0 deletions

View File

@@ -0,0 +1,84 @@
---
package: "@trpc/client"
version: "^11.0.0"
tier: core
decision: approved
date: 2026-05-14
deciders: [Danijel Martinek]
adr: null
filter-results:
license: MIT
types: native
maintenance: active
boundary-fit: pass
shadow-check: pass
eu-residency: n/a
cve-scan: clean
named-consumer: pass
verification-commands:
- npm view @trpc/client license
- npm view @trpc/client version
- pnpm audit --audit-level=moderate
accepted-cves: []
---
## Filter: license
<!-- Result: MIT -->
`npm view @trpc/client license` returns `MIT`. MIT is on the allowlist.
## Filter: types
<!-- Result: native -->
`@trpc/client` is authored in TypeScript and ships its own `.d.ts` declaration files. No separate `@types/` package is needed.
## Filter: maintenance
<!-- Result: active -->
Actively maintained alongside `@trpc/server` by the tRPC team. Versioned and released together with the server package.
## Filter: boundary-fit
<!-- Result: pass -->
`@trpc/client` is used in `@repo/core-testing` to provide a mock tRPC client for test setups. This is the correct tier for test infrastructure utilities. No boundary rule restricts `@trpc/client` usage here.
## Filter: shadow-check
<!-- Result: pass -->
`@trpc/client` is the sole tRPC client implementation in the workspace. No competing client adapter is present.
## Filter: eu-residency
<!-- Result: n/a -->
`@trpc/client` is a pure client-side RPC library with no vendor-controlled network endpoints. EU residency does not apply.
## Filter: cve-scan
<!-- Result: clean -->
`pnpm audit --audit-level=moderate` reports no advisories against `@trpc/client` at the time of this trace.
## Filter: named-consumer
<!-- Result: pass -->
`@repo/core-testing` uses `@trpc/client` to build the mock tRPC client used in integration test setups. Named, non-hypothetical consumer exists today.
## Prompt: replaces
`@trpc/client` is the natural companion to `@trpc/server`; no alternative client approach was evaluated separately. Using `@trpc/client` ensures the test setup mirrors the production client configuration.
## Prompt: migration-cost-out
Low. `@trpc/client` is confined to `@repo/core-testing`'s test utilities. Migrating out requires updating the mock client setup in one package. Feature packages reference tRPC types from `@trpc/server`, not `@trpc/client`.
## Prompt: alternatives-considered
1. **Direct HTTP fetch in tests** — Rejected: bypasses tRPC middleware and type inference, making tests less representative of real client behavior.
2. **`@trpc/server` `createCaller` (server-side calling)** — Valid alternative for pure unit tests; `@trpc/client` is used where the test needs to exercise the actual HTTP transport or client link chain.

View File

@@ -0,0 +1,84 @@
---
package: "@trpc/server"
version: "^11.0.0"
tier: core
decision: approved
date: 2026-05-14
deciders: [Danijel Martinek]
adr: null
filter-results:
license: MIT
types: native
maintenance: active
boundary-fit: pass
shadow-check: pass
eu-residency: n/a
cve-scan: clean
named-consumer: pass
verification-commands:
- npm view @trpc/server license
- npm view @trpc/server version
- pnpm audit --audit-level=moderate
accepted-cves: []
---
## Filter: license
<!-- Result: MIT -->
`npm view @trpc/server license` returns `MIT`. MIT is on the allowlist.
## Filter: types
<!-- Result: native -->
`@trpc/server` is authored in TypeScript and ships its own `.d.ts` declaration files. No separate `@types/` package is needed.
## Filter: maintenance
<!-- Result: active -->
Actively maintained by the tRPC team. The 11.x line is the current major. Regular releases; strong community adoption in the Next.js ecosystem.
## Filter: boundary-fit
<!-- Result: pass -->
`@trpc/server` is the workspace-standard RPC layer for type-safe client-server communication (ADR-019 references tRPC as the transport for use-case exposure). Feature packages export their tRPC routers; `core-api` aggregates them; apps mount the root router. Feature packages own their error middleware (`integrations/api/procedures.ts`). No boundary rule restricts `@trpc/server` to a specific tier.
## Filter: shadow-check
<!-- Result: pass -->
`@trpc/server` is the sole RPC framework in the workspace. No competing API layer (REST, GraphQL, gRPC) is present for the same purpose.
## Filter: eu-residency
<!-- Result: n/a -->
`@trpc/server` is a pure server-side routing library with no network communication to vendor-controlled endpoints. EU residency does not apply.
## Filter: cve-scan
<!-- Result: clean -->
`pnpm audit --audit-level=moderate` reports no advisories against `@trpc/server` at the time of this trace.
## Filter: named-consumer
<!-- Result: pass -->
All five feature packages export a tRPC router that uses `@trpc/server`. `@repo/core-api` aggregates these routers. `@repo/core-shared` provides the tRPC base instance and error middleware utilities. Named, non-hypothetical consumers exist today.
## Prompt: replaces
`@trpc/server` replaces a hypothetical hand-written REST API layer. tRPC enables end-to-end type safety between the server use cases and the Next.js client without a separate OpenAPI spec or code generation step.
## Prompt: migration-cost-out
Hard. tRPC router types propagate from the server to the client via TypeScript inference. Every feature package's tRPC router, the root `AppRouter` type in `core-api`, and every client-side query in the apps reference `@trpc/server` types. Migrating to REST would require replacing all router definitions, regenerating types (e.g., via OpenAPI), and updating all client call sites.
## Prompt: alternatives-considered
1. **GraphQL (Apollo/Pothos)** — More complex schema layer required; the resolver pattern does not map cleanly onto the factory-function use-case pattern mandated by CLAUDE.md.
2. **OpenAPI + Zodios** — Requires a separate schema definition step and code generation; tRPC's type inference is more direct for a monorepo where client and server share the same TypeScript project.