@@ -10,14 +10,13 @@ effort re-deriving what a green run already proves.
 ## What verify has already proven (do not re-check by hand)
 
 Links sit at or below the L4 floor, nesting agrees with levels, `@status` values are legal,
-references resolve (with dangling allowed on `abandoned`/`superseded`), and named
-`@verifiedBy` tests exist and are not skipped.
+and references resolve (with dangling allowed on `planned`, whose nodes do not exist yet).
 
 ## What only a human or an agent reading the code can catch
 
 **1. Statuses that are false.** The highest-value finding in the whole dimension. A
 requirement marked `live` whose implementation was gutted; one marked `partial` that is now
-complete; one marked `abandoned` whose code is demonstrably still running. Sample the claims
+complete; one marked `planned` that was quietly built months ago. Sample the claims
 and read the nodes. `status` is the only payload with controlled evidence behind it — the
 resurrection protection rides entirely on it being true.
 
@@ -49,7 +48,7 @@ should be simplified rather than defended.
   coverage is explicitly rejected — plumbing members are covered by architectural
   requirements with high fan-out. L5 exists so a member claim *can* be made where it means
   something, never so every member must carry one.
-- **Dangling links on `abandoned` / `superseded`.** Correct, and load-bearing.
+- **Dangling links on `planned`.** Correct — the plan precedes the nodes.
 - **A project with no requirements at all.** The feature is opt-in by declaration; absence is
   not a finding.
 
 
@@ -1007,7 +1007,7 @@ Reach for it when the project needs to answer any of:
 
 - **"Why is this field here?"** — an L5 requirement binds a claim to a specific member. Authoring these exhaustively is what surfaces columns nothing reads and vocabularies nobody documented.
 - **"What is broken but known?"** — `@status: partial` plus `@disposition: accepted | deferred`. Absent disposition means *undecided*, and `meta verify` counts those: the gaps nobody has ruled on.
-- **"What did we build and then retire?"** — `@status: abandoned` is the one status where a dangling `@implementedBy` is *correct*, so the record survives the deletion.
+- **"What did we say we would build and have not?"** — `@status: planned` is the one status where a dangling `@implementedBy` is *correct*, because the entry precedes the nodes.
 - **"What have we committed to build?"** — `@status: planned`. Its references may dangle, and it never counts toward object coverage.
 - **"Which ticket covers this?"** — `@trackedBy`.
 
 
@@ -4,19 +4,18 @@ Capabilities are **metadata**, declared in `metaobjects/` beside the entities th
 describe. Read the existing requirement nodes before designing anything. Two rules matter
 more than the rest.
 
-**1. When you retire something, record it — at that moment.** Set the requirement's
-`status` to `abandoned` (built, then deliberately dropped) or `superseded` (something else
-does it now — name it in `supersededBy`), in the same change that removes the code.
+**1. A requirement is PRESCRIPTIVE — it states what should be true, never what happened.**
+So when a capability is retired, **delete its requirement** in the same change that removes
+the code. `status` is `planned | live | partial`; there is no member meaning "we used to do
+this", because every one of those three describes something meant to be true now or soon.
 
-This is the one thing a requirement does that the rest of the model cannot. Given a brief
-matching a retired feature, agents reading only the model proposed **reviving** it 24 times
-out of 24, each believing it was reusing. A retired feature is *more* attractive than a
-live one: purpose-built for exactly the request, never complicated by production.
+What a deleted entry leaves behind is a diff, which is the right home for it. If something
+about the retirement is worth carrying forward — why it went, what replaced it — put that in
+`notes` on the entry that survives, where a reader looking at today's model will find it.
 
-Leaving a dangling `implementedBy` on an `abandoned` or `superseded` requirement is
-**correct** — those nodes are supposed to be gone, and `verify` allows it deliberately. On
-`live` or `partial` the same dangling reference is an error: the model moved and the
-requirement went stale.
+Leaving a dangling `implementedBy` is **correct only on `planned`**: the entry precedes the
+nodes. On `live` or `partial` the same dangling reference is an error — the model moved and
+the requirement went stale.
 
 **2. When you add an entity, claim it.** Every `object.entity` should appear in some
 requirement's `implementedBy`, or `verify` says so.
@@ -108,8 +107,9 @@ usually one nobody read carefully. Then say what was DECIDED, which is a separat
 - **absent** — undecided, and that is a real state. `verify` counts these, because
   *"which gaps has nobody ruled on?"* is the question a review exists to answer.
 
-A `partial` nobody intends to finish is usually `abandoned` — built then deliberately
-retired, the one status where a dangling reference is correct.
+A `partial` nobody intends to finish is `partial` + `@disposition: accepted` — the gap is
+understood and deliberately not being closed. If the capability itself is gone, delete the
+requirement instead.
 
 **`status: planned` locks in work you have not started.** Its references may dangle (write
 the requirement before the entity), and it never counts toward object coverage — otherwise
@@ -125,13 +125,13 @@ ambition rather than work.
     violation: "A scene that advances on a clock rather than on the story"
     children:
       - requirement.functional:
-          name: TurnTimer
+          name: BeatProgression
           level: 4
-          status: abandoned          # retired deliberately -- do NOT revive
-          statement: "Pacing was driven by a per-turn wall-clock timer"
-          violation: "Pacing driven by elapsed time instead of beat completion"
-          supersededBy: BeatProgression
-          implementedBy: ["game::turn::TurnTimer"]   # gone, and that is the point
+          status: planned            # not built yet -- refs may dangle
+          statement: "A scene advances when its beat completes"
+          violation: "A scene that advances with its beat unresolved"
+          trackedBy: ["acme/game#412"]
+          implementedBy: ["game::turn::BeatProgression"]   # does not exist YET
 
 - requirement.architectural:
     name: UuidPrimaryKeys
 
@@ -28,7 +28,7 @@ cite. (3) Whether anyone fills the ledger in is itself untested; advertising it
 is the brochure failure this skill exists to avoid.
 
 TRIGGER to revisit — the release carrying `requirement.*` has shipped, AND either:
-  Arm A  a dogfooded project's `abandoned`/`superseded` entries are shown, retrospectively,
+  Arm A  a dogfooded project's retired capabilities are shown, retrospectively,
          to have been discoverable PRE-adoption from repo evidence at file:line standard
          (removal commit, dead flag, do-not-reintroduce comment);
   Arm B  a team that adopted via this assessment hits a resurrection the ledger would have
 
@@ -8,7 +8,7 @@ subverb**: requirements are metadata, so they are checked on *every* `meta verif
 | | owns |
 |---|---|
 | **loader** | `@status` enum, required attrs, child rules, levels — unconditional |
-| **`verify`** | `@implementedBy` / `@verifiedBy` resolution — **severity depends on `@status`** |
+| **`verify`** | `@implementedBy` resolution — **severity depends on `@status`** |
 
 A typo'd `@status` fails the **load** ("failed to load metadata"), before verify runs. If you
 see that, no other diagnostic in the run is trustworthy — fix it first and re-run.
@@ -18,25 +18,21 @@ see that, no other diagnostic in the run is trustworthy — fix it first and re-
 The **same** unresolved `@implementedBy` reference is:
 
 - an **error** on `live` / `partial` — the model moved and the requirement is stale;
-- **allowed** on `abandoned` / `superseded` — those nodes are *supposed* to be gone. That is
+- **allowed** on `planned` — those nodes do not exist YET. That is
   the entry doing its job, not drift.
 
-So do not "fix" a dangling reference on an abandoned requirement by deleting it. Deleting it
-destroys the record that something was deliberately retired, which is the single thing this
-mechanism exists to preserve.
+So on a `planned` entry a dangling reference is the entry doing its job, not drift — do not
+"fix" it by deleting the reference, or you delete the plan.
 
 ## Exit codes
 
 | situation | exit |
 |---|---|
 | clean tree, or no `requirement.*` nodes at all | 0 |
 | dangling `@implementedBy` on `live`/`partial` | 1 |
-| the same reference on `abandoned`/`superseded` | 0 |
+| the same reference on `planned` | 0 |
 | `@implementedBy` above the L4 link floor | 1 |
 | live `requirement.architectural` claimed by nothing | 1 |
-| `@verifiedBy` naming a test that exists nowhere | 1 |
-| `@verifiedBy` naming a name found only in an **unrecognised** test file | 0 (warning) |
-| `@verifiedBy` naming a test that is **skipped** | 0 (warning) |
 | an entity no requirement claims | 0 (warning) |
 
 ## The error codes, and the fix for each
@@ -53,34 +49,30 @@ name the remedy; this table exists so you can act on one without re-deriving the
 | `ERR_REQUIREMENT_ARCH_NO_IMPLEMENTERS` | a `live`/`partial` `requirement.architectural` that nothing implements | a policy declared and applied to nothing. Claim the nodes it governs, or drop it to `planned` — which is exempt, because it is not applied yet by definition. |
 | `ERR_REQUIREMENT_LEVEL_NESTING` | a node's `@level` disagrees with the level of the parent it nests under | nesting IS the hierarchy. Move the node to the right parent rather than editing the level to match where it happens to sit. |
 | `ERR_REQUIREMENT_BAD_LEVEL` | `@level` is not an integer inside the allowed range | levels are L1–L5 and nothing else. |
-| `ERR_REQUIREMENT_TEST_MISSING` | `@verifiedBy` names a test found nowhere | the test was renamed or deleted. If your project's test convention is simply unrecognised, declare it in `verify.testFiles` rather than deleting the claim. |
 | `ERR_MISSING_REQUIRED_ATTR` | a required attr is absent | `@statement`, `@status` and `@violation` are required on both subtypes; `@level` is required on `functional` and optional on `architectural`. |
 | `ERR_BAD_ATTR_VALUE` | a closed-enum attr has an unknown value | `@status` and `@disposition` are enforced by the LOADER, so a typo fails the load in every port rather than passing in some. |
 
 **A note on the L4/L5 pair.** They are enforced at the same site and fail for opposite
 reasons, so reading only the code you hit can send you the wrong way. The question is not
 "is this ref valid?" — usually it is — but "does the LEVEL match the shape of the ref?"
 
-## What counts as a test file is YOUR project's call
+## `verify` does not look at your tests
 
-The scan ships patterns for jest/vitest/bun, JUnit, Maven Failsafe (`*IT`), xUnit/NUnit,
-pytest and Kotlin. Those are a convenience, **not an authority** — a built-in list is a guess
-about your repository, and a wrong guess reports a real test as a broken claim. Declare your
-conventions and they are added to the built-ins:
+It used to. `@verifiedBy` asked you to name a test, and `verify` checked that the **name**
+occurred somewhere in your test sources. That is existence evidence, never proof — an audit of
+one real 19-name ledger opened every named test and found **4 that did not verify their
+claim**: one matched a comment, one a dependency-injection key, one a real test of a
+*different* claim, and one a test of the entry's output where the claim was about its source
+text. `verify` reported zero errors throughout. The author picks the string, so the cheapest
+way to satisfy the check is to find any name that already exists.
 
-```ts
-// metaobjects.config.ts
-export default defineConfig({ verify: { testFiles: ["**/*IT.kt", "**/*.feature"] } });
-```
-
-If a named test is missing from the corpus but present in some other source file, `verify`
-warns and names that file rather than failing — an unrecognised convention is the tool's
-ignorance, not your mistake.
+The attribute is retired. Tying a requirement to a test is the job of a generator that emits
+the test **from** the requirement, so the link is structural rather than a name someone chose.
 
 ## What a green run does NOT prove
 
 It proves **referential integrity**: statuses parse, levels are in range, links sit at or
-below the floor, references resolve, named tests exist and are not skipped.
+below the floor, references resolve.
 
 It cannot prove a status is **true**, or that a node genuinely implements the requirement
 claiming it. No test can. That judgement is yours.
 
@@ -87,14 +87,19 @@ in any port implemented the other half — two ports shipping halves of one prom
 fixture that could see it. A split is deliberate when no port makes a claim the corpus would
 have to check; it is a gap when some port already made one.
 
-**A hazard for whoever ships the scheduled removal.** Contract prose lives *inside* attr
-descriptions in `expected-registry.json`, where five ports byte-match it and nothing else
-gates it — `@verifiedBy` carries "verify checks each name EXISTS and is not skipped; it
-never runs them", and `@trackedBy` carries "NOT resolved by verify, which does not reach the
-network". Deleting an attribute deletes its description, and with it the only gated
-statement of that guarantee. Sweep every description being removed for contract prose and
-rehome it in the **same** change, not after — the same class as the ADR-0047 renumbering
-trap, where a string that reads like prose is actually a gated artifact.
+**A hazard for whoever removes an attribute — and it has now fired once.** Contract prose
+lives *inside* attr descriptions in `expected-registry.json`, where five ports byte-match it
+and nothing else gates it. `@trackedBy` still carries "NOT resolved by verify, which does not
+reach the network". `@verifiedBy` carried "verify checks each name EXISTS and is not skipped;
+it never runs them" — and that attribute was **retired in `0.24.0` (FR-038)**, which deleted
+the only gated statement of that guarantee along with it.
+
+That removal was done to the rule: the sentence was rehomed **in the same change**, to
+[`spec/capability-ledger.md`](../spec/capability-ledger.md) (§ "`verifiedBy` — RETIRED") and
+to the migration guide, before the description was deleted. Do the same for the next one.
+Sweep every description being removed for contract prose and rehome it in the **same**
+change, not after — the same class as the ADR-0047 renumbering trap, where a string that
+reads like prose is actually a gated artifact.
 
 Per-port runners + commands: