# Project map

## Purpose

[Describe the product, its users, and the problem it solves in one paragraph.]

## Technology

- Runtime: [name and exact supported version]
- Framework: [name and version]
- Package manager: [name and version]
- Database: [name and version, if applicable]
- Deployment: [target platform]

## Read before editing

- Architecture: `docs/architecture.md`
- Product behavior: `docs/product.md`
- Security rules: `docs/security.md`
- Current work: `PROGRESS.md`

Remove links that do not exist. Add the missing document before relying on it.

## Repository map

- `[path]`: [responsibility]
- `[path]`: [responsibility]
- `[path]`: [responsibility]

## Standard commands

- Install: `[install command]`
- Development: `[development command]`
- Lint: `[lint command]`
- Type check: `[type-check command]`
- Unit tests: `[test command]`
- End-to-end tests: `[end-to-end command]`
- Production build: `[build command]`

## Working procedure

1. Read this file and `PROGRESS.md`.
2. Inspect the current git status and relevant files.
3. Restate the requested outcome, scope, and acceptance criteria.
4. Make the smallest change that satisfies one bounded task.
5. Run the narrow checks first, followed by the required full-pipeline checks.
6. Review the diff for unrelated changes and exposed secrets.
7. Update `PROGRESS.md` with evidence and the next action.

## Boundaries

- Do not change files outside the requested scope without explaining why.
- Do not edit generated files when a source or generator exists.
- Do not weaken tests, types, authentication, authorization, or validation to
  make a check pass.
- Do not expose, print, or commit secrets.
- Ask before changing billing, authentication, production data, public APIs,
  schemas, infrastructure, or destructive operations.
- Preserve the existing package manager and architecture unless the task
  explicitly authorizes a change.

## Definition of done

- Every acceptance criterion has observable evidence.
- Relevant lint, type, test, and build commands pass.
- User-facing behavior is exercised through the real interface.
- The diff contains no unrelated edits or temporary debug artifacts.
- Documentation matches changed behavior.
- `PROGRESS.md` distinguishes verified work from remaining work.