test: assert the entity spec table holds together

[skeeeon]

This repo had no tests at all — CI's go test ./... ran over nothing. The entity table is the right place to start: it's the CLI's entire surface (registerCRUD builds a command tree per spec, pull/apply enumerate the same list), and it's hand-maintained on purpose since it isn't derived from the platform's schema.json.

Every failure mode that table has is silent. Concretely:

• addFieldFlags and collectFields both switch on Type without a default, so a typo'd type registers no flag and the field quietly cannot be set.
• A verb spelled "list" makes hasVerb answer false for every verb the spec meant to allow — the command just goes missing.
• A duplicated alias isn't an error in cobra; one command shadows the other and an entity stops being reachable.
• A LookupKey naming a field the collection lacks turns every natural-key lookup into an opaque 400.

What's asserted

Types are dispatchable · verbs known and unique · LookupKey names a declared field · select/multiselect carry Values and nothing else does · flags unique within a spec and not colliding with what ls/get/delete/create register themselves (--filter, --sort, --fields, --yes/-y, --random-password) or with root.go's persistent flags · Required only where create exists · no command name or alias claimed twice across the whole table · every entity reachable by at least ls or get.

Plus unit coverage of the helpers behind those checks — aliases, flagName, hasVerb, composeOrgFilter, splitFields — and a short explicit list of the non-org-scoped collections, which is the one place the CLI's model of platform tenancy is written down.

These were verified to fail

A passing test that cannot fail isn't evidence, so I planted each defect, confirmed the failure, and reverted:

planted defect	caught by
Type: "strng" on a field	addFieldFlags does not dispatch on
locations given Plural: "things"	alias "things" is claimed by both
Verbs: ["list", …]	unknown verb "list"
LookupKey: "host_name"	not a declared field
a field named fields	the ls command registers itself
FSelect with Values removed	rejects every value passed to it
Values on an FString	declares Values, which nothing reads

composeOrgFilter's parenthesisation is pinned for the reason it exists: an OR inside a user's --filter must not escape the org scope.

Two notes for you rather than for the code:

1. This closes chore test: assert the entity spec table holds together #3. Chore test: guard the entity table against the platform's schema #4 — a guard against the field table drifting behind schema.json — is still open and still needs your call on vendoring vs fetching.
2. While reading the table I noticed the docs understate it: platform-docs/docs/stone-cli.md §4 lists nats-account and nebula-ca as ls / get, but both specs declare ls, get, update, edit. The server rejects tenant writes either way, so it's a docs inaccuracy rather than a hole — say the word and I'll fix that page.

🤖 Generated with Claude Code