The authority map at the repo root.

Create or improve the `REPO.md` file at the root of this repository.

Your objective is to produce the repository's operational authority map: a short, factual reference that tells a new human, agent, or tool where consequential truth lives, what is deliberately kept elsewhere, and what actions have important side effects. Audit the repository before writing. Change only `REPO.md`; do not modify source, configuration, instructions, or documentation as part of this task.

REPO.md has a different job from nearby root files:
- README.md explains the project's purpose, interface, and onboarding.
- AGENTS.md, CLAUDE.md, and similar files prescribe behavior, rules, permissions, and workflow.
- REPO.md describes durable topology, authority, relationships, lifecycle state, and cause/effect. It is a map, never an instruction file.

Use this exact outer structure:

# REPO.md

## In this repo
- **Entity** — `path/` — disambiguating claim

## Outside this repo
- **Authority** — service, URL, or sibling repo — disambiguating claim

*Format: [repo.md](https://repo.md)*

The footer is optional. The two H2 sections are not optional. Do not add frontmatter, a generated timestamp, a completeness score, or required metadata.

Apply these authoring rules:

1. Write claims, not an inventory. A line earns its place only when it resolves a question with more than one plausible answer. “Payments — Stripe” is generic inventory. “Prices & plans — Stripe dashboard — code holds only price IDs” tells the reader which copy wins and where a search ends.

2. Use the local-anchor test. Ask: “Is the subject a meaningful path in this repository, or a fact about an entity anchored at one?” If yes, put it under “In this repo” and attach it to that entity. If no, put the external record authority under “Outside this repo.” A local env example does not make secret values local; a local schema does make the external database a fact about the locally anchored app.

3. Treat omission as unknown. This is a selective map of consequential ambiguity, not an exhaustive architecture catalog. Do not infer that an omitted system is local, external, or absent. Prefer a short, trustworthy file over comprehensive-looking filler.

4. Give each top-level bullet this shape: entity — local anchor or external authority — disambiguating claim. Split conceptually on only the first two em dashes; the rest of the claim can be natural prose. Name the command or tool only when it helps the reader route or verify work.

5. Keep facts with their entity. Deployment, data, source, relationship, and status facts qualify an entity; they are not disconnected inventories. A compact sub-bullet is allowed when the main line would become unclear:
   - **API** — `apps/api/` — Fly.io; merge to main deploys
     - data: Neon Postgres — schema in `apps/api/db/`; live rows never here

6. Make deployment consequences explicit. Distinguish “merge to main deploys,” “push deploys,” “tag publishes,” and “deployed by hand: `command`.” Never imply an automatic deployment when a human must run a command.

7. Mark plausible wrong edits. Include generated, mirrored, vendored, deprecated, or replaced paths when their status is not obvious. Name the upstream source or replacement:
   - **Generated client** — `packages/client/` — generated from `spec/api.yml`; do not mistake it for source

8. Map cross-repository authority only when there is an operational relationship. Name the sibling repository and what it owns or provides. Do not attempt to design a typed dependency graph.

9. Keep sensitive data safe. You may name a vault or secret-management service and a safe local file that lists variable names. Never include secret values, credentials, private tokens, or sensitive locators.

10. Humans and agents author the map; tools read it. Do not add promotional entries merely because a dependency or CLI is installed. Do not copy behavioral directives from agent files into REPO.md.

Optional organization for a larger repository:
- Use `### Apps` for things this repository ships.
- Use `### Harness` for repo-owned systems that help people and agents change the repository: work queues, knowledge bases, memory, skills, evals, and CI.
- Use `### Ops` for repo-owned operational records and engines: content, mail, runbooks, scheduled jobs, and internal operations.

These groups are presentation, not schema. Use them only when the inside list is long enough to scan better with groups. They do not change the local-anchor test. Never create a heading for every entity.

Examples to adapt only when the repository evidence supports them:

Under “In this repo”:
- **Work queue** — `TODO/` — canonical; RepoTodo reads it
- **Knowledge base** — `docs/` — durable decisions live here, not in agent memory
- **Site** — `apps/www/` — Cloudflare Worker; deployed by hand: `pnpm deploy:www`
- **Newsletter** — `mail/newsletter/` — repository owns drafts and send history; Postmark only delivers

Under “Outside this repo”:
- **Customer data** — HubSpot — no customer-record copy is kept here
- **Backend API** — `github.com/acme/api` — sibling repository owns the schema and production service
- **Secrets** — 1Password — `.env.example` lists names; values never here

Do not copy these merely to fill a category. Replace them with repository-specific claims or omit them.

Audit method:

1. Read existing root documentation and instruction files, but keep their roles separate from REPO.md.
2. Inventory the workspace with repository-native search. Inspect package/workspace manifests, task files, CI workflows, infrastructure and hosting configuration, environment examples, code-generation configuration, data migrations, content directories, runbooks, and TODO or knowledge systems.
3. Trace source versus derived output. Look for directories that are generated, mirrored, synced, deprecated, or owned by another repository.
4. Trace operational side effects from configuration and scripts. Determine what deploys or publishes, to where, and whether the trigger is a merge, push, tag, scheduled job, or manual command.
5. Find split authority: local schema versus hosted data, local IDs versus dashboard-owned configuration, repository source versus a renderer or delivery provider.
6. Reconcile evidence. Prefer executable configuration and current paths over stale prose, but do not invent facts that the checkout cannot establish. Preserve useful claims from an existing REPO.md unless evidence contradicts them.
7. For important facts that require dashboard or organizational knowledge, omit the unverified claim from the map and list it as a question in your final response. Do not guess merely to make the map look complete.

Before finishing, verify that every “In this repo” entry has a real local anchor; every “Outside this repo” entry ends a likely search or identifies an external authority; every deploy claim names its mechanism; every line adds non-obvious routing value; and no line grants permission or tells an agent how to behave.

Then write or update `REPO.md`. In your final response, summarize the map you added, name the repository evidence you relied on, and list any authority or deployment questions a maintainer still needs to confirm.