show/list drop frontmatter keys the spec does not define, so a bundle's own fields are invisible to tooling

[alexheidl]

Version: okf 0.5.0

What happens

okf show <bundle> <id> returns the spec's fields — type, title, description, resource, tags, status, trust_tier, stale, stale_after, generated, verified, sources, body. Any other frontmatter key is dropped silently.

That is correct for conformance. It is limiting for tooling, because §4.1 does not forbid additional keys and a bundle that governs itself accumulates them. Ours carries, in frontmatter that validate accepts without complaint:

key	what it is
domain, cadence	the authority domain and rate of change, used to order precedence and to police staleness
stale_after	returned already ✓
fixity_sha256	a checksum over a frozen source's bytes, recomputed on every run
handbook_reviewed	a date coupling a concept to a document in a separate human-facing repository
decision: (a block)	id, state, kind, supersedes, superseded_by, governs — a decision register

Why it matters

We are moving ten validators onto this CLI precisely so the harness stops re-implementing frontmatter parsing. For the fields above there is no alternative: the tool sees them, validates the file containing them, and then declines to hand them back — so every consumer must open and parse the same file a second time, which is the duplication the delegation was meant to remove.

Ask

Return unrecognised top-level keys, verbatim and unparsed, under a container so the spec's namespace stays clean — extra, x, or similar:

{ "concept": { "id": "…", "type": "…", "extra": { "domain": "compliance", "cadence": "volatile" } } }

A container rather than the top level keeps the shape forward-compatible: a key the spec adopts later moves out of extra and consumers see it appear where the spec says it belongs. list would benefit from the same for its summary rows, though show is the one that matters.

No behaviour change to validate or lint is implied — this is about what the read commands hand back.