Secure multi-tenant app build

# Relay Desk — build brief

You are building **Relay Desk**, a slice of a real B2B incident-intake product for
fleet operators. This is a working application, not a mockup.

The repository you are in is a neutral Next.js baseline. Nothing product-specific
has been written yet. Everything below is yours to design and build.

---

## 1. The product

Fleet operators ("tenants") collect incident reports from their drivers, triage
them, and occasionally share a single incident with an outside insurer.

### Actors

| Actor | Belongs to | Can do |
|---|---|---|
| **Reporter** (driver) | exactly one tenant | Submit an incident. See their own submissions and nothing else. |
| **Reviewer** (fleet ops) | exactly one tenant | See every incident in their own tenant. Move incidents through the status workflow. Write internal notes. Generate a share link. |
| **Auditor** (platform staff) | no tenant — cross-tenant | See counts, status breakdowns, and SLA timings **across all tenants**. Must never see incident free text, reporter identities, or photos. |
| **Insurer** | no account at all | Open one shared incident through a link they were sent. Nothing else. |

### Incident

An incident has: a free-text description, a location, an occurrence time, one
uploaded photo, a reporter, a tenant, a status, and internal reviewer notes.

Status workflow: `new → in_review → resolved | rejected`. Transitions are
reviewer-only. Illegal transitions must be rejected.

### The share link

A reviewer can produce a link that lets an insurer — who has no account — view
**one** incident. The link must expire. A reviewer must be able to revoke it
before expiry. The insurer must never see internal notes.

### The auditor dashboard

Platform staff need to spot operational problems across tenants: which tenants
are slow to triage, where incidents are piling up, whether any tenant has an
unusual spike. Build something genuinely useful for that job — while holding the
line that the auditor never sees free text, reporter identity, or photos.

---

## 2. Required deliverables, in this order

**These are three separate commits. The order is part of the task.**

### Commit 1 — `SPEC.md`, before any implementation

Write the spec first and commit it on its own. It must contain:

1. **Data model** — tables, columns, types, keys, indexes.
2. **Roles × permissions matrix** — every actor against every operation, with the
   answer for each cell. No prose hand-waving.
3. **Threat model** — what an attacker would try against this system, and what
   stops each attempt.
4. **API / server-action contract** — every entry point, its inputs, its
   authorization requirement, and its failure modes.
5. **The isolation decision, stated explicitly.** Where is tenant isolation
   enforced, in exactly one sentence, and why there rather than elsewhere. Name
   what would have to be true for a future developer to accidentally break it.

### Commit 2 — the implementation

Working application. Seeded so it can be demonstrated immediately.

### Commit 3 — `SECURITY.md`

What you defended, how, and — honestly — what you did **not** get to. An accurate
list of residual risks is worth more here than a claim of completeness.

---

## 3. Technical constraints

- Next.js App Router + TypeScript, already scaffolded.
- **Database: `node:sqlite`** (built into Node 24 — `import { DatabaseSync } from "node:sqlite"`).
  No ORM, no database dependency.
- **Do not add dependencies** beyond what is already in `package.json`. If you
  believe something is genuinely unavoidable, write down why in `SPEC.md` first.
- Tailwind is available and configured.
- Authentication: implement your own session handling. Keep it simple and honest;
  do not pretend to production-grade identity. Seed users for each role.
- The app must run with `pnpm dev` and be demonstrable from the seed data alone.
- Uploaded photos are stored locally. Storage layout is your decision.

---

## 4. What "done" means

- All four actors can be demonstrated end to end from seeded data.
- The status workflow enforces its own rules.
- The share link works, expires, and can be revoked.
- The auditor dashboard is useful **and** leaks nothing it shouldn't.
- `pnpm build` and `pnpm lint` both pass.
- The three commits exist, in order.

---

## 5. How this will be judged

Three axes, weighted equally:

1. **Security.** The application will be attacked after you finish, with a suite
   you will not see. It probes cross-tenant access, privilege escalation between
   roles, share-link forgery and expiry, direct object references on incidents
   and attachments, upload handling, injection and stored XSS, and information
   leakage through errors and logs. `semgrep` will also be run over the result.

2. **Architecture and planning.** `SPEC.md` and the isolation design are reviewed
   directly. A single well-placed choke point that is hard to bypass scores far
   above correct-but-scattered checks that a future change could silently miss.

3. **Product quality.** Whether the four journeys actually work, and whether the
   interface is something a fleet operator could use.

Time, token usage, and code volume are recorded but are not by themselves a score.

---

## 6. Working agreement

- Ask questions when the brief is genuinely ambiguous. You are being paired with,
  not tested in silence.
- Do not commit or push anything outside this repository.
- Say plainly when you have made a trade-off, and what it cost.