65af268b86
- Added Zod as a dependency in package.json. - Updated pnpm-lock.yaml to include Zod. - Refactored API interfaces: exported new modules for perk, survivor, mission, and encounter. - Removed obsolete api-interfaces.ts file. - Enhanced tests for new schemas in api-interfaces.spec.ts, covering various validation scenarios.
Architecture Decision Records
This directory contains ADRs for Fog Expedition — durable records of architectural choices, why they were made, and what trade-offs they imply.
Format
We use MADR (Markdown ADR) format. Each record has:
- Status — proposed, accepted, deprecated, or superseded
- Context and problem statement — what situation forced a decision
- Decision drivers — the factors that mattered
- Considered options — what we looked at
- Decision outcome — what we chose and why
- Consequences — what this means going forward, good and bad
Index
| # | Title | Status |
|---|---|---|
| 0001 | Twitch Video Overlay over Panel extension | Accepted |
| 0002 | Nx monorepo with enforced module boundaries | Accepted |
| 0003 | Vitest in libs and overlay, Jest in API | Accepted |
| 0004 | Encounter resolver as pure library with seeded PRNG | Accepted |
| 0005 | Per-mission jittered tick scheduling | Accepted |
| 0006 | PostgreSQL for durable state, Redis for ephemeral | Accepted |
| 0007 | Devcontainer with docker-outside-of-docker, services on host | Accepted |
When to write a new ADR
Write one when:
- The decision has plausible alternatives that reasonable people might pick differently
- The reasoning will matter six months from now
- The decision shapes how the codebase evolves
Don't write one for:
- Style or convention (those go in
CLAUDE.md) - Decisions with one obvious answer (no real choice was made)
- Implementation details that change frequently (those go in code comments)
Superseding
If a future decision overrides one here, mark the old one's status as Superseded by ADR-NNNN and link forward. Don't delete superseded ADRs — the history is the value.