Three uuids on one arrival, three different answers

Asked of the row the feed actually returns.

site_id had a reference all along and the feed was not sending it. A
client could read the shop's NAME off an arrival and still had no way to
ask for that shop except by uuid - the exact gap the reference scheme
exists to close. site_slug now travels with it.

visit_id stays a uuid and needs no reference: no route takes it, it is a
key a client de-duplicates on because delivery is at-least-once, and
nobody says a visit id out loud.

The uuid in a face URL must STAY random. visit_faces.id is
gen_random_uuid() and a derived or sequential one would let somebody
walk a shop's customers by date - the same reason bucket keys are random
rather than derived from the event id. A readable identifier is right
for a customer and wrong for the thing that points at their photograph.

And seq is now json:"-". visits.seq is a plain bigserial, so it counts
every visit on the PLATFORM, and shipping it put the total footfall of
every customer we have on every row of every tenant's feed - the same
German-tank estimate that decided visitors.number had to be per client.
It was a convenience for "have I fallen behind", nothing ever read it,
and the cursor answers that without disclosing a number. The SSE event
id was never the raw value; it has always been the opaque cursor.

The one test that broke was reading seq back off the wire to assert the
cursor pointed at the last row of a burst. It asserts against the seeded
position now: the property is unchanged, and the test can no longer see
what a client cannot.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HViLj9gYNRtSr7YVZmW5sn

CLAUDE.md

@@ -2047,6 +2047,36 @@ the engine's own diagnostic dashboard.
   human name. The prop carrying it is `customerRef`, not `ref` — React reserves
   that name, so it would never have reached the component.
 
+### Three uuids on one arrival, three different answers
+
+Asked of the row the feed actually returns, and they do not get the same reply:
+
+- **`site_id`** had a reference all along and the feed was not sending it. A
+  client could read the shop's *name* off an arrival and still had no way to ask
+  for that shop except by uuid, which is the exact gap the scheme exists to
+  close. `site_slug` now travels with it.
+- **`visit_id` stays a uuid, and needs no reference.** No route takes it; it is
+  a key a client de-duplicates on, because delivery is at-least-once. Nobody
+  says a visit id out loud.
+- **The uuid in a face URL must STAY random.** `visit_faces.id` is
+  `gen_random_uuid()` and a derived or sequential one would let somebody walk a
+  shop's customers by date — the same reason object keys in the bucket are
+  random rather than derived from the event id. A readable identifier is right
+  for a customer and wrong for the thing that points at their photograph.
+
+And one field left with it: **`seq` is now `json:"-"`**. `visits.seq` is a plain
+bigserial, so it counts every visit on the *platform*, and shipping it put the
+total footfall of every customer we have on every row of every tenant's feed —
+the same German-tank estimate that decided `visitors.number` had to be per
+client. It was there as a convenience for *"have I fallen behind"*, nothing ever
+read it, and the cursor already answers that question without disclosing a
+number. The SSE event id was never the raw value; it has always been the opaque
+cursor.
+
+The one test that broke was reading `seq` back off the wire to assert the cursor
+pointed at the last row of a burst. It asserts against the seeded position now —
+the property is unchanged, and the test can no longer see what a client cannot.
+
 Fixture note: `embedding(seed)` fills every dimension with one value, so after
 L2 normalisation 0.31 and 0.62 are the **same direction** and the matcher
 correctly calls them one person. Tests that need several different people use