test: guard the entity table against the platform's schema

[skeeeon]

Chore #4, with vendoring. The field table is hand-maintained rather than generated, and the docs have always warned it can lag a platform release — but nothing would ever tell you it had. PocketBase silently discards writes to fields a collection doesn't have, so a flag for a removed field keeps reporting success and doing nothing. That has already happened in this repo: nebula-ca --rotate-keys existed for a while against a collection with no such field.

The guard

cmd/testdata/schema.json is a vendored copy of the platform's collection schema, and the tests fail in both directions:

• Spec → schema. A field (or KeyColumn, or LookupKey) the platform doesn't have. Catches writing into the void.
• Schema → spec. A platform field the CLI neither exposes nor records a reason for. Catches lagging behind a release — this is the one chore test: guard the entity table against the platform's schema #4 was really about.

Refresh is one command, documented in the README and in the test itself:

cp ../platform/schema.json cmd/testdata/schema.json
go test ./...

Why vendored and not fetched in CI: the drift being guarded against is exactly the kind you want to see in a diff and approve, and a stale copy fails loudly the same way a missing one would. Fetching the platform's default branch would instead let an unrelated platform commit turn this repo's CI red. cmd/testdata/schema-source.txt records the version the copy came from (currently platform v0.2.0).

Two lists carry the judgement, and a third test stops them rotting — a stale entry hides the next real drift:

• deliberatelyOmitted — per-collection, with the reason. Secrets (private_key, seed, creds_file), file uploads the CLI can't do (floorplan, logo), operator-only account keys, and nats_users.active, which is omitted because pb-nats consults it nowhere.
• libraryOwnedFields — see below.

One finding worth your attention

nats_roles carries allow_response, allow_response_max and allow_response_ttl in this CLI, and the platform's schema.json declares none of them. The CLI isn't wrong — pb-nats creates that collection with those fields (internal/collections/manager.go, createRolesCollection) and reads them back when generating a user JWT (internal/types/converters.go). So they exist on a live database while being absent from the platform's dump, which is why they're listed as library-owned rather than as an error.

The part worth a second look is in the comment: createRolesCollection returns early when the collection already exists, so a database created before those fields were added never acquires them — and since the platform's schema.json doesn't declare them either, migrate up won't add them. That's the same shape as the system_account_id bug the platform fixed in v0.2.0, where record.Set on an undeclared field persisted nothing on every boot. If a database is in that state, allow_response reads back false forever and role-driven response permissions never reach the JWT. I haven't touched it — it's a platform/pb-nats question, not a CLI one.

Verified to fail

planted	caught by
spec field absent upstream	PocketBase discards the write
new platform field, unexplained	neither exposes nor explains
omission entry for a removed field	drop the entry
library-owned field now declared upstream	no longer library-owned
collection missing from the schema	is not in the platform schema

Companion: the docs fix for the verb columns is stone-age-io/platform-docs#4.

🤖 Generated with Claude Code