chore(template): clean-slate template snapshot from bb4a0c7

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
This commit is contained in:
2026-07-12 20:40:54 +02:00
commit f77e6ea881
1062 changed files with 105156 additions and 0 deletions

View File

@@ -0,0 +1,85 @@
---
package: "@testing-library/jest-dom"
version: "^6.5.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
socketRisk: clean
verification-commands:
- npm view @testing-library/jest-dom license
- npm view @testing-library/jest-dom version
- pnpm audit --audit-level=moderate
accepted-cves: []
---
## Filter: license
<!-- Result: MIT -->
`npm view @testing-library/jest-dom license` returns `MIT`. MIT is on the allowlist.
## Filter: types
<!-- Result: native -->
`@testing-library/jest-dom` ships its own TypeScript declaration files that extend the vitest/jest `expect` matchers. No separate `@types/` package is needed.
## Filter: maintenance
<!-- Result: active -->
Actively maintained by the Testing Library organization. The 6.x line is the current major. Regular releases tracking vitest and jest compatibility.
## Filter: boundary-fit
<!-- Result: pass -->
`@testing-library/jest-dom` is a dependency of `@repo/core-testing`, which is the workspace's shared testing infrastructure package. Custom DOM matchers (`toBeInTheDocument`, `toHaveTextContent`, etc.) are set up in `core-testing`'s setup file and available to all feature test suites via the `core-testing` dependency. This is the correct placement.
## Filter: shadow-check
<!-- Result: pass -->
`@testing-library/jest-dom` is the sole custom DOM matcher extension in the workspace. No competing matcher library is present.
## Filter: eu-residency
<!-- Result: n/a -->
`@testing-library/jest-dom` is a test utility library with no network communication. EU residency does not apply.
## Filter: cve-scan
<!-- Result: clean -->
`pnpm audit --audit-level=moderate` reports no advisories against `@testing-library/jest-dom` at the time of this trace.
## Filter: named-consumer
<!-- Result: pass -->
`@repo/core-testing` uses `@testing-library/jest-dom` to set up custom DOM assertion matchers. Feature packages that render React components in tests use these matchers via `core-testing`. Named, non-hypothetical consumer exists today.
## Prompt: replaces
`@testing-library/jest-dom` extends vitest's `expect` with semantic DOM matchers, replacing brittle assertion patterns like `expect(el.innerHTML).toContain('text')` with `expect(el).toHaveTextContent('text')`.
## Prompt: migration-cost-out
Low. `@testing-library/jest-dom` is configured in one setup file in `@repo/core-testing`. Removing it requires updating that setup and replacing any DOM-specific matchers in test files with lower-level assertions.
## Prompt: alternatives-considered
1. **Plain vitest `expect` matchers only** — Viable but produces less readable test assertions for DOM state; `toBeInTheDocument()` is significantly clearer than checking element existence manually.
2. **`@vitest/ui` accessibility assertions** — Narrower scope; `@testing-library/jest-dom` covers the full semantic DOM assertion surface.

View File

@@ -0,0 +1,85 @@
---
package: "@testing-library/react"
version: "^16.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
socketRisk: clean
verification-commands:
- npm view @testing-library/react license
- npm view @testing-library/react version
- pnpm audit --audit-level=moderate
accepted-cves: []
---
## Filter: license
<!-- Result: MIT -->
`npm view @testing-library/react license` returns `MIT`. MIT is on the allowlist.
## Filter: types
<!-- Result: native -->
`@testing-library/react` ships its own TypeScript declaration files. No separate `@types/` package is needed.
## Filter: maintenance
<!-- Result: active -->
Actively maintained by the Testing Library organization. The 16.x line targets React 19. Regular releases; strong community and ecosystem adoption.
## Filter: boundary-fit
<!-- Result: pass -->
`@testing-library/react` is a dependency of `@repo/core-testing`, the workspace's shared testing infrastructure. It provides `render`, `screen`, `fireEvent`, and related utilities for component tests. Feature packages that test UI components use these utilities via `core-testing`. This is the correct placement for shared test infrastructure.
## Filter: shadow-check
<!-- Result: pass -->
`@testing-library/react` is the sole React component testing utility in the workspace. No competing library (Enzyme, React Test Renderer) is present.
## Filter: eu-residency
<!-- Result: n/a -->
`@testing-library/react` is a test utility library with no network communication. EU residency does not apply.
## Filter: cve-scan
<!-- Result: clean -->
`pnpm audit --audit-level=moderate` reports no advisories against `@testing-library/react` at the time of this trace.
## Filter: named-consumer
<!-- Result: pass -->
`@repo/core-testing` uses `@testing-library/react` to provide the `render` utility and `screen` query API for component tests. Feature packages with UI components use these via `core-testing`. Named, non-hypothetical consumer exists today.
## Prompt: replaces
`@testing-library/react` replaces Enzyme and React Test Renderer. Testing Library's philosophy of testing from the user's perspective (querying by role, label, text) produces more resilient tests than implementation-detail-aware approaches.
## Prompt: migration-cost-out
Hard. `render`, `screen`, `fireEvent`, and `userEvent` APIs from Testing Library are used in all component tests. Migrating to a different testing approach requires rewriting all component tests and changing the query strategy (from accessibility-tree queries to DOM selectors or component internals).
## Prompt: alternatives-considered
1. **Enzyme** — Deprecated and no longer maintained for React 18+; Testing Library is the ecosystem standard.
2. **`react-dom/test-utils`** — Lower-level API without the accessibility-query helpers; more verbose and less idiomatic for testing user behavior.

View File

@@ -0,0 +1,85 @@
---
package: "@testing-library/user-event"
version: "^14.5.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
socketRisk: clean
verification-commands:
- npm view @testing-library/user-event license
- npm view @testing-library/user-event version
- pnpm audit --audit-level=moderate
accepted-cves: []
---
## Filter: license
<!-- Result: MIT -->
`npm view @testing-library/user-event license` returns `MIT`. MIT is on the allowlist.
## Filter: types
<!-- Result: native -->
`@testing-library/user-event` ships its own TypeScript declaration files. No separate `@types/` package is needed.
## Filter: maintenance
<!-- Result: active -->
Actively maintained by the Testing Library organization. The 14.x line is the current major. Regular releases.
## Filter: boundary-fit
<!-- Result: pass -->
`@testing-library/user-event` is a dependency of `@repo/core-testing`, the workspace's shared testing infrastructure. It provides realistic user interaction simulation (`userEvent.click`, `userEvent.type`, etc.) that more accurately models browser behavior than `fireEvent`. This is the correct placement for shared test infrastructure.
## Filter: shadow-check
<!-- Result: pass -->
`@testing-library/user-event` is the sole user interaction simulation library in the workspace. No competing library is present.
## Filter: eu-residency
<!-- Result: n/a -->
`@testing-library/user-event` is a test utility library with no network communication. EU residency does not apply.
## Filter: cve-scan
<!-- Result: clean -->
`pnpm audit --audit-level=moderate` reports no advisories against `@testing-library/user-event` at the time of this trace.
## Filter: named-consumer
<!-- Result: pass -->
`@repo/core-testing` uses `@testing-library/user-event` to provide realistic interaction utilities for component tests. Feature packages with interactive UI components use these via `core-testing`. Named, non-hypothetical consumer exists today.
## Prompt: replaces
`@testing-library/user-event` replaces `@testing-library/dom`'s `fireEvent` for interaction tests. `userEvent` simulates the full browser event sequence (pointerdown → mousedown → focus → click → pointerup → mouseup) rather than dispatching a single synthetic event, producing more faithful integration tests.
## Prompt: migration-cost-out
Low. `@testing-library/user-event` is used in component tests alongside `@testing-library/react`. Removing it requires downgrading interaction tests to `fireEvent` calls — a mechanical change but a loss of test fidelity.
## Prompt: alternatives-considered
1. **`fireEvent` only** — Simpler but fires only one synthetic event per interaction; misses focus/blur and keyboard event sequences that real browsers emit.
2. **Playwright component testing** — Full browser testing is reserved for e2e (`pnpm test:e2e`); `userEvent` is the right tool for unit/integration component tests.