Address routing

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

verae.access.<plane>.<area>.<resource>.<action>   # ingress (one plane)
verae.access.authz.check                          # authorization step
verae.<area>.<resource>.<action>                  # internal bus
verae.<area>.<resource>.reply.<correlationId>

Planes: zapier | web | api | leaf | staff. Default deny. A leaf cannot balance.adjust; Zapier cannot statement.get; a browser cannot archive.put.

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

Copy the independent repo verae-nats-process (packages/verae-nats-process).
Rename verae.example.process.in / .out / .reply.* in src/subjects.js.
Add a row to that repo’s ROUTING.md and to INDEX.md.
Register the process in verae-fleet (min/max, machines, roles).
If an access plane must call it, add the subject to verae-access-authz policy for that plane only. Zapier still never sees NATS.

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