Specs that survive the session

--- id: payment-processing title: Payment Processing status: active --- # Payment Processing ## Testing Architecture | Framework | Vitest 2.1 | | Isolation | Testcontainers | | Coverage | c8, target 85% | | Mocking | msw for HTTP only | ## Phase 1: Checkout [in-progress] - [x] [TEST-PAY-01] Write checkout session tests - [x] [IMPL-PAY-02] Implement checkout session → satisfies [TEST-PAY-01] - [ ] [TEST-PAY-03] Write webhook handler tests ← current - [ ] [IMPL-PAY-04] Implement webhook handler → satisfies [TEST-PAY-03] ## TDD Log | Task | Red (failing) | Green (passing) | Refactor | |----------------|---------------------------|------------------------|--------------| | [TEST-PAY-01] | 4 tests, 4 failed | — | — | | [IMPL-PAY-02] | — | 4 passed, 0 failed | Extract config| ## Resume Context > TDD phase: RED. Writing webhook handler tests in > tests/payments/webhook.test.ts. Need to test > signature verification, idempotency, and event > routing for checkout.session.completed.

# Research Notes — User Auth System ## Date: 2026-03-28 ## Project Architecture Express.js API with TypeScript, src/ directory structure, Prisma ORM with PostgreSQL. App Router pattern with controllers in src/routes/, middleware in src/middleware/. ## Relevant Code - src/routes/users.ts — existing user CRUD (no auth) - src/middleware/cors.ts — CORS setup, pattern to follow - prisma/schema.prisma — User model exists, no password field - tests/integration/ — supertest-based, Jest runner ## Library Comparison | Need | Pick | Alternative | Rationale | |---------|-------------|-------------|------------------------| | JWT | jsonwebtoken | jose | Simpler API, widely used| | Hashing | argon2 | bcrypt | GPU-resistant, OWASP | | Validation | zod | joi, yup | TypeScript-native | ## Risk Assessment - Token storage: refresh tokens in DB, not cookies - Rate limiting needed on /auth/login to prevent brute force - Password reset flow is out of scope for this spec ## Open Questions - Should refresh tokens be stored hashed or plain? - Session invalidation strategy: single device or multi?

# Interview Round 1 — User Auth System ## Date: 2026-03-28 ## Questions Asked 1. The codebase uses Express middleware pattern for CORS. Should auth follow the same pattern as a middleware? Answer: Yes, same pattern. Middleware in src/middleware/. 2. Prisma User model has no password field yet. Add it directly or create a separate Credentials model? Answer: Add passwordHash directly to User. Keep it simple. 3. Should refresh tokens be stored hashed in the database? Answer: Yes, hash them. Same risk profile as passwords. 4. What does "done" look like for this spec? Answer: Register, login, refresh, logout all working. Protected routes return 401 without valid token. Tests passing for each endpoint. ## Key Decisions - Middleware pattern, same as existing CORS setup - passwordHash on User model, no separate table - Refresh tokens hashed with argon2 ## New Research Needed - argon2 hashing for refresh tokens (same lib as passwords?)

# Spec Registry | ID | Title | Status | Priority | Progress | Updated | |----------------------|--------------------|-------------|----------|----------|------------| | user-auth-system | User Auth System | active | high | 5/7 | 2026-03-30 | | payment-processing | Payment Processing | paused | medium | 2/8 | 2026-03-29 | | notification-system | Notifications | completed | medium | 12/12 | 2026-03-27 | One file, all your specs. Quick lookup without opening each SPEC.md. SPEC.md frontmatter is authoritative — registry is a denormalized index.