0.24.2 — a retired capability gets its status back, and a JVM nudge that fired forever

Coordinated PATCH across all four registries — npm 0.24.2 · PyPI 0.24.2 · NuGet 0.24.2 · Maven 7.24.2.

Ships metamodelVersion 0.13. The package and metadata axes are separate contracts (ADR-0035 Amendment 2), so a metamodel move does not force a package minor. Everything here is additive — nothing that loads on 0.24.x stops loading.

Highlights

• A retired capability gets its status back: @status: retired (FR-039) — 0.24.0 retired abandoned, superseded and @supersededBy; this reverses that half. The ruling that authorised requirement.* tested six claims and refuted five; the one that held is the retired-capability guardrail — model-only agents flagged a deliberately-retired capability 0 times out of 24, every run proposing to extend it; ledger arms caught it 19 of 40. 0.24.0 removed the survivor and left the five refuted claims in place.
• The finding that removed it is answered structurally, not exempted. One estate carried 29 @implementedBy references that could never resolve across 14 entries while meta verify reported zero — but they dangled because the ruling chartered them as correct, and the real defect was the reporting. So retired forbids @implementedBy outright (ERR_REQUIREMENT_RETIRED_HAS_IMPLEMENTORS, a LOAD error in all five ports). The references cannot dangle because they cannot exist: the bug class is unreachable rather than patched.
• @supersededBy resolves now — what the original ruling asked for and never got. Legal on retired only, resolved package-locally under ADR-0042, so a supersession that is itself superseded chains instead of rotting the way a prose note does.
• meta upgrade --apply does the migration in one command. @status: abandoned used to be the canonical refusal case; the edit is determinate now, and the same run also drops the @implementedBy a retired entry may not carry — so one invocation leaves a loading estate rather than a document that still fails.
• meta verify lints how a requirement is AUTHORED, in a section of its own — seven warnings for a ledger that agrees with the model perfectly and records less than its author thinks (a name that breaks the dotted path or its generated stub filename, prose duplicated across two slots, an id-shaped title). Every finding is a warning and none can fail a build; mute with --no-requirement-lint. Narrowed against three real adopter ledgers — a blanket title check produced 355 findings that were all false, and after narrowing the two well-authored ledgers report zero.
• The JVM agent-context staleness nudge fired forever (#347) — generatedBy is always an npm version (meta agent-docs is the canonical scaffolder for every port) while the JVM read its Maven version, so "7.24.1".equals("0.24.1") was false and always would be. The nudge fired on every mvn metaobjects:generate, in perpetuity, including when the context was perfectly in sync. C# and Python were never affected.
• meta upgrade now repairs the @fields + @expr index key (#342) — 0.24.1 made the key @fields XOR @expr and left the one command that exists to repair refused metadata unaware of it.
• A requirement diagnostic is addressed by its dotted path, not its bare name — hierarchy is nesting, so two branches may reuse a name and a bare one does not locate the node.
• The generated requirements page renders a requirement's title.

What is deliberately NOT claimed

19 of 40 is under half, and there is no documented production prevention case. In the estate audited for it, nothing routed an agent to the ledger at all — no rule file, no always-loaded doc, no generated context cited it. Restoring the status is necessary and not sufficient: if nothing points at the ledger, it buys a coin flip.

Upgrading

A ledger using only planned | live | partial needs no change. A ledger carrying the pre-0.24.0 vocabulary runs meta upgrade --apply; the migration guide is docs/features/migrations/retired-status-restore.md.

---

Full detail, including the reasoning behind each ruling, is in the CHANGELOG.