rc.5 cannot load a requirements ledger rc.3 accepted: @verifiedBy unregistered, and abandoned/superseded dropped from @status

[dmealing]

Summary

0.24.0-rc.5 cannot load a requirements ledger that 0.24.0-rc.3 loaded without complaint. Both
meta verify and meta gen fail at metadata load, so the RC is a hard block for this adopter — not
a warning, not a gate failure, a refusal to read the model.

Two independent root causes, both in the requirement metamodel, both cases where the shipped
documentation still describes what the loader now rejects. Happy to split into two issues if you'd
rather track them separately.

1. @verifiedBy is rejected as undeclared, but it is your attribute

meta: failed to load metadata: Unknown attribute '@verifiedBy' on requirement.architectural
'auditRowNamesItsTrigger' — not declared by any registered provider for requirement.architectural
meta: meta verify is strict (ADR-0023): every authored @attr must be declared.

@verifiedBy is not something this project invented. In the rc.5 tarball itself:

• documented in @metaobjectsdev/sdk/agent-context/skills/metaobjects-verify/references/requirements.md
  — "@verifiedBy asked you to name a test, and verify checked that the name …"
• read by your own CLI: @metaobjectsdev/cli/dist/src/commands/verify.js (and src/commands/verify.ts)

So strict-attr enforcement landed without registering an attribute that the tool documents and its
own verify command consumes. Any ledger that followed the documentation now fails to load.

Used 12 times in this project's ledger.

2. @status: abandoned and superseded are no longer allowed values

With --lax (which gets past #1) the load fails differently:

meta: failed to load metadata: requirement.functional 'recallMeasurement' attribute '@status'
has value 'abandoned' which is not one of the allowed values: planned, live, partial

abandoned and superseded are gone from the enum. But your shipped docs in the same tarball still
reference both (abandoned` and `superseded`, abandoned`/`superseded), and rc.3 counted
them without issue — its own summary line read:

requirements: 75 entries (52 functional, 23 architectural) — 14 planned, 56 live, 2 partial, 3 abandoned

This one has a semantic cost beyond the load error. abandoned records that a requirement was
retired on purpose. The alternative — deleting the node — destroys exactly the history the status
exists to preserve, so "just remove them" is not a migration, it is data loss. This project has three,
each with a recorded reason.

Reproduction

Any project with a requirements ledger using @verifiedBy or @status: abandoned:

$ bunx meta verify --db <url>      # exit 1, fails at load (cause 1)
$ bunx meta verify --lax --db <url> # exit 1, fails at load (cause 2)
$ bun run gen                       # exit 2, same load failure

Same project on rc.3: meta verify exit 0, meta gen clean, 877 tests green.

Suggested fix

1. Register @verifiedBy on the requirement provider, alongside whatever registration @trackedBy
   / @disposition / @notes already have.
2. Restore abandoned and superseded to the @status enum — or, if their removal is deliberate,
   say so in the CHANGELOG with a migration path that preserves the retirement record, and update
   the agent-context docs that still name them.

Worth noting the class: both are cases where ADR-0023's strictness outran the metamodel's own
registrations and its documentation. A conformance check that every attr and enum value appearing in
the shipped docs and fixtures actually loads under strict mode would catch this family.

Environment

• Broken on 0.24.0-rc.5; clean on 0.24.0-rc.3
• Adopter: TypeScript + Bun + Postgres, meta migrate-owned schema, 75-node requirements ledger
• Also blocks meta gen, not just verify