# 6. Address routing (including unplanned functions)

NATS **addresses** (subjects) are the extension point. A new search, store, or job type is a new address plus a process that listens — not a new Zapier TCP client.

## Pattern

```text
verae.<area>.<resource>.<action>
verae.<area>.<resource>.reply.<correlationId>
```

| Piece | Example | Meaning |
|-------|---------|---------|
| `verae` | — | Verae bus (not Zapier) |
| `area` | `zapier`, `archive`, `search`, `store` | Product slice |
| `resource` | `jobs`, `hashes`, `blobs` | Noun |
| `action` | `watch`, `query`, `put`, `in` | Verb |
| `reply.<id>` | — | Correlated response |

**Queue group** (work sharing): `area-resource-action` (e.g. `job-poller`).  
**No queue group** (fan-out): archive/tree **query** so every node sees every lookup.

## Adding something that does not exist yet

1. Copy the independent repo **[verae-nats-process](https://git.georgelambert.org/marchon/verae-nats-process)** (`packages/verae-nats-process`).
2. Rename `verae.example.process.in` / `.out` / `.reply.*` in `src/subjects.js`.
3. Add a row to that repo’s `ROUTING.md` and to [INDEX.md](INDEX.md).
4. Register the process in `verae-fleet` (`min`/`max`, machines, roles).
5. If Zapier must call it, add **one HTTPS route** on middleware — Zapier still never sees NATS.

Do **not** invent a public NATS URL for Zapier. Do **not** reuse `verae.archive.query` as a queue group.

![Address expansion](diagrams/routing.svg)