+**The `0.24.2` line is a coordinated PATCH across all four registries** (npm `0.24.2` · PyPI `0.24.2` · NuGet `0.24.2` · Maven `7.24.2`) — **a retired capability gets its status back.** `@status` gains a fourth member, **`retired`**, and `@supersededBy` is registered again, this time as a reference the loader RESOLVES (FR-039). `0.24.0` had retired `abandoned`, `superseded` and `@supersededBy`; this reverses that half, and it is **additive — nothing that loads on `0.24.x` stops loading**, so a ledger using only `planned | live | partial` sees no change at all. **Why it came back is the measurement:** the ruling that authorised `requirement.*` tested six claims under control across five rounds and 52 agents with pre-registered kill conditions, 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 "each believing it was reusing rather than reviving", against ledger arms catching it **19 of 40**. `0.24.0` removed the survivor and left the five refuted claims standing. **The finding that removed it was real and is answered STRUCTURALLY rather than 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 deliberately chartered them as correct, so the defect was in the REPORTING and was answered by deleting vocabulary. `retired` therefore **forbids** `@implementedBy` outright (`ERR_REQUIREMENT_RETIRED_HAS_IMPLEMENTORS`, a LOAD error in all five ports, not a `verify` check — every other requirement check lives only in the TS CLI, so a Java or Python estate would otherwise author the shape freely): a retired capability has no implementation by definition, so the references cannot dangle because they cannot exist, and the bug class is unreachable rather than patched. It stays **PRESCRIPTIVE**, which is what makes it admissible under the rule that removed it — a `retired` entry states *"this must not be rebuilt"*, a prohibition in force falsifiable by one observable, not a diary entry about the past. It is a **status member, not a subtype**, because the claim that held is literally *"a status field prevents reviving retired features"* and what was proven works *because the retired entry sits where the live one sat*. **`@supersededBy` resolves now** — point 4 of the original ruling, which `0.24.0` deregistered without ever building — legal on `retired` only and resolved package-locally under ADR-0042, so a supersession that is itself superseded chains where a prose note rots. Migration is **one command**: `meta upgrade --apply` now repairs the case it used to refuse, and the same run drops the `@implementedBy` a retired entry may not carry, so one invocation leaves a LOADING estate rather than a document that still fails — the #342 failure exactly. `metamodelVersion` moves `0.12` → `0.13`. **What is deliberately NOT claimed: 19 of 40 is under half, there is no documented production prevention case, and in the audited estate nothing routed an agent to the ledger at all** — the restore is necessary and *not sufficient*. Also ships a **`meta verify` requirement-authoring lint** 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 a WARNING that can never fail a build, muted with `--no-requirement-lint`, narrowed against three real adopter ledgers after a blanket title check produced 355 findings that were all false); requirement diagnostics addressed by **dotted path** rather than bare name; **`meta upgrade` repairs the `@fields` + `@expr` index key** ([#342](https://github.com/metaobjectsdev/metaobjects/issues/342)), which `0.24.1` made illegal while leaving the one repair command unaware of it; the generated requirements page rendering a requirement's `title`; and **the JVM agent-context staleness nudge, which fired forever** ([#347](https://github.com/metaobjectsdev/metaobjects/issues/347)) — `generatedBy` is always an **npm** version because `meta agent-docs` is the canonical scaffolder for every port, while the JVM compared its **Maven** version, so `"7.24.1".equals("0.24.1")` was false and always would be and the nudge fired on every `mvn metaobjects:generate` in perpetuity, including when the context was perfectly in sync. This is also the release that satisfies **`docs/1.0-readiness.md` §G3's quiet period** — additive, adopter-edit-free, one coordinated release after `0.24.1`. See `CHANGELOG.md` [0.24.2].
0 commit comments