fix(console): a store's write counter is not a record's revision

[stormer78]

Reported straight after #163 went live: adding attributes made the version number climb.

phone.mobile	v1 · 07/09/2026, 10:48:29
name	v2 · 07/09/2026, 10:48:44

Two different attributes, each written once, in a column headed Updated. It reads as "revision 2".

The agent is right; the console was wrong

version is a value of the store's monotonic write counter, not the record's own. The schema is explicit — "a value of the store's monotonic write counter. Server-assigned; a producer never chooses one" — and vta-persona/src/store.rs explains why it has to be store-wide:

One monotonic counter for the store. A record's version is the counter value its most recent write took, which makes the same number serve as both the optimistic-concurrency token and the change-feed watermark. Per-record counters could do the first but not the second, because two records' counters are not comparable to each other.

So v2 on a freshly created record is correct: it is the second write to the pool. The console was reporting the pool's write history as the record's own — the same failure format.ts was written for (a value the console did not have, rendered as a confident wrong one), and worse here, because the number is plausible and nothing on screen tells it apart from the revision count it resembles.

The fix

The counter is no longer displayed, in either the Attributes or the Profiles table. It is still read and still matters: every edit sends it back as expectedVersion, which is exactly what an opaque concurrency token is for. A value to carry, not a value to show.

Why a rule and not a one-line fix

vta/app-state's version is the same shape — a namespace-wide counter — so this is a trap the next pane can fall into. manager-version-display.test.mts sweeps src/manager/** for a version given a v prefix and set beside a timestamp, which is the specific form that reads as a revision. It deliberately permits the two legitimate uses: carrying it as expectedVersion, and showing it under its own name next to an explanation, the way the app-state and policy editors show what they are compare-and-swapping against.

Mutation-checked: restoring the v{a.version} render fails it.

One note worth keeping. The guard builds its regex per use rather than sharing one. A global regex carries lastIndex, and both assert.match and .test() advance it, so a shared instance resumes mid-string on the next call and silently skips matches — in a guard, indistinguishable from finding none. That caught the test's own self-check before it caught anything real.

Not covered: app-state.tsx renders the same kind of counter, but under a column headed "Version" with no prefix and no adjacent timestamp — the schema's own name for the field, standing alone. It reads as less of a claim, and the guard permits it deliberately rather than by omission. Worth a look separately if it misleads anyone.

Verification

npm run lint, npm run build, npm test — 787 across four workspaces. Every ci.yml assert step run locally against a real build.