Issue reports carry only opened: the tracker holds every status, so no copy can drift

The import of slice 3 (ADR 0275) was checked against every folder: no report changed since the
commit it read, and the tracker holds each report's status, owner, fix, design amendment, replay
and closing day. The keys are removed from all 361 reports, cycle.py refuses them in any report,
and the playbooks, skills and READMEs that still pointed at them name the tracker instead.

03-DESIGN/01-to-be/45-a-core-that-cannot-fail-silently.md

@@ -664,7 +664,8 @@ replay covers what must not be done to it on purpose, and every rule keeps a liv
 - **Replays live where their incident is**: a component's logic in its repository as `TestReplay<issue>`,
   what the mesh runs (the bus's release, the resolver under musl and glibc) in mesh-lab's `replays/`, all
   named in its register and proved by `replays/cmd/prove`. A core issue opened from 2026-10-07 resolves only
-  with `replay:` or `replay-none:` (`cycle.py`).
+  with `replay` or `replay-none`, refused without one by the issue tracker's `move` (ADR 0275; `cycle.py` held it
+  until then).
 - **The controller's tests run a bus of their own per test**, linked in at the release the mesh runs and held
   to it by a test, so the suite runs in parallel and under the race detector.
 

03-DESIGN/01-to-be/53-the-issue-tracker.md

@@ -145,7 +145,7 @@ the events sees a change as it happens. No event carries a secret, and an issue
 | `wontfix` | a reason |
 
 A refused move changes nothing and says which rule refused it. `cycle.py` checked the folders that carried status until
-slice 3; since then it refuses a status key in a report opened after the import, and judges no issue's status.
+slice 3; since then it refuses a status key in any report, and judges no issue's status.
 
 ## 6. How the operator and agents use it
 
@@ -173,7 +173,7 @@ in one call, from any session, and the responder on a channel answers from it on
 |---|---|---|
 | 1 | The `mesh-issues` module: `open`, `get`, `list`, `move`, `note`, `link`; a counter by compare-and-set in the SDK; playbook 03 takes its numbers from it | an agent opens an issue and gets the next number; two agents opening at the same moment never get the same one |
 | 2 | Decision and research numbers from the tracker, each its own key in `counters`; a number is reserved when a branch starts | two agents writing a decision at once get two numbers, and no hq pull request is renumbered |
-| 3 | `import`: every issue folder in hq read through the records module and written as an issue with its own number, idempotent and showing what it would change before it does (built 2026-10-10; the status keys stay in the reports as a dated snapshot, and one pull request changes playbook 03 and `cycle.py` and adds dated notes to ADR 0019, 0080 and 0275); then the four consolidation passes of research 042 (fixed, duplicates, owners, grouping; the duplicates pass is the duplicate check's `groom`, § 9, judged rather than by shared words), each a list confirmed before it is applied through `move`, `link` and `note`, and an audit of `fixed-by` against the forge | the not-closed list comes from one call and shrinks by what was already fixed or duplicated, each with its reason |
+| 3 | `import`: every issue folder in hq read through the records module and written as an issue with its own number, idempotent and showing what it would change before it does (built and run 2026-10-10; one pull request changed playbook 03 and `cycle.py` and added dated notes to ADR 0019, 0080 and 0275, and once every folder was checked against the tracker a second removed the status keys from every report, as § 3 says); then the four consolidation passes of research 042 (fixed, duplicates, owners, grouping; the duplicates pass is the duplicate check's `groom`, § 9, judged rather than by shared words), each a list confirmed before it is applied through `move`, `link` and `note`, and an audit of `fixed-by` against the forge | the not-closed list comes from one call and shrinks by what was already fixed or duplicated, each with its reason |
 | 4 | Conditions and pull requests linked: an issue links a condition by its key and the controller shows the link; a merged pull request notes every issue it names; after a week of that, the controller opens one issue per `healer-wanted` condition key by itself | a condition shows its issue, and a merge notes the issues it names |
 | 5 | A read-only view onto the `issues` bucket over the bus | the operator reads issues in a browser without an agent |