An issue's status lives in the issue tracker: playbook 03, cycle.py and the notes slice 3 of ADR 0275 asked for

00-META/process/00-overview.md

@@ -60,17 +60,22 @@ the expensive half.
 
 The flow above is a rule, and a rule states how it is checked:
 [`00-META/checks/cycle.py`](../checks/cycle.py) refuses a to-be design that names no
-decision, an `in-progress`/`implemented` design that names no owning code, an issue marked
-`located`/`fixed` with no owner or `fixed`/`resolved` with no fix, and a `graduated`
+decision, an `in-progress`/`implemented` design that names no owning code, two issue folders
+sharing a number or an issue report carrying a status key, and a `graduated`
 research overview that does not say what it became. Run it with `records.py`, `index.py` and
-`words.py` before any HQ merge (`sh merge-check.sh` runs all four). What the checks cannot see — that code work actually started from a
+`words.py` before any HQ merge (`sh merge-check.sh` runs all four). The issue rules the check
+once held — `located` with an owner, `resolved` with a fix, a core issue with its replay — are
+refused at the write by the issue tracker's `move`
+([ADR 0275](../../02-DECISIONS/0275-the-mesh-numbers-and-tracks-its-issues-in-a-module-of-its-own-and-hq-keeps-only-the-narrative-of-a-design-or-governance-issue.md)). What the checks cannot see — that code work actually started from a
 handoff — is held by playbooks [04](04-build-handoff.md) and [07](07-feature-branches.md):
 a feature branch exists because a design or an issue sent it.
 
-## Status lives in frontmatter
+## Status lives in frontmatter, an issue's in the tracker
 
-Research overviews, design docs, issue reports and decision records each carry their status as
-YAML frontmatter (schemas in the section READMEs and playbooks). There are **no central status
+Research overviews, design docs and decision records each carry their status as
+YAML frontmatter (schemas in the section READMEs and playbooks). An issue's status lives in the
+issue tracker, which refuses a wrong status at the write, and its report here carries only
+the day it was opened (playbook [03](03-issues.md)). There are **no central status
 files** and no decision ledger. **Every decision is a record in
 [`02-DECISIONS`](../../02-DECISIONS/)** — if it is worth recording it is worth a record, and if
 it is not worth a record it is not recorded. Cross-cutting views, the decision index included,

00-META/process/03-issues.md

@@ -19,7 +19,7 @@ The knowledge base already holds the operational record and is indexed on sympto
 folder is not a second copy of it. An issue here is a question HQ must **answer**, not an
 incident someone must **clear**.
 
-## The issue tracker holds the number
+## The issue tracker holds the number and the status
 
 Every issue is opened in the **issue tracker**, the module `mesh-issues` holding the seat `issue-tracker` on the
 control-node ([ADR 0275](../../02-DECISIONS/0275-the-mesh-numbers-and-tracks-its-issues-in-a-module-of-its-own-and-hq-keeps-only-the-narrative-of-a-design-or-governance-issue.md),
@@ -28,16 +28,22 @@ compare-and-set, so two authors opening at the same moment never get the same on
 reading `main` or the open pull requests** — that is how numbers collided (issue 155: two records sharing a number
 reached `main` with every check passing). A session that cannot reach the tracker takes no number and says so.
 
+**The tracker is the truth for every issue's status, owner, fix and links**, whether or not the issue has a folder
+here. `issue-tracker.get NNN` says where an issue stands; `issue-tracker.list` says what is open. Nothing here
+says it: a report's frontmatter carries no status.
+
 An issue takes one of two shapes:
 
 - **With a folder here** — a design or governance issue, whose narrative belongs in this public record and is
-  reviewed in a pull request. The tracker holds its number, title, notes and links; its status stays in the folder's
-  frontmatter until slice 3 of to-be 53 has imported the folders and been checked, and until then the tracker's
-  `move` refuses it, saying its status lives in its folder.
-- **Wholly in the tracker** — every other issue. Its status, owner, notes and links live in the tracker from the
-  start, and nothing is written here.
+  reviewed in a pull request. The folder holds the report and the diagnosis; the tracker holds everything else.
+- **Wholly in the tracker** — every other issue. Nothing is written here.
 
-No status is ever kept in two places for one issue.
+**The reports written before the tracker** (the folders numbered 001 to 364) still carry `status:`, `located-in:`,
+`fixed-by:`, `amended-design:`, `replay:` and `replay-none:` in their frontmatter. Those keys are the snapshot the
+import of slice 3 took from `main` on the day it ran (the note in ADR 0275 says which day and which commit), and
+they are not kept up to date: the tracker is. They are left in place because they are the record of what was known
+then, reviewed in pull requests at the time, and because removing 361 keys would say nothing the tracker does not.
+Nobody edits them.
 
 ## Steps
 
@@ -52,34 +58,31 @@ No status is ever kept in two places for one issue.
 
    ```yaml
    ---
-   status: open
    opened: YYYY-MM-DD
-   located-in: []       # owning repo(s)/module(s), filled by diagnosis
-   fixed-by:            # PR or commit reference, filled at resolution
-   amended-design:      # design doc path, when the root cause was a design gap
    ---
    ```
 
-   Then the symptom as observed, as in the tracker's report.
+   Then `# NNN. The title`, the title as the tracker holds it, and the symptom as observed, as in the tracker's
+   report. **No status key**: `cycle.py` refuses `status:`, `located-in:`, `fixed-by:`, `amended-design:`,
+   `replay:` or `replay-none:` in a report opened after the import, because the tracker holds them and two places
+   holding one fact drift.
 
-   **An issue wholly in the tracker** is done at this step: what follows happens through the tracker's verbs.
-2. Investigate. For a folder-backed issue, the trail goes in `01-diagnosis.md` in the same folder — dated,
-   including what was ruled out — and `status:` moves to `diagnosing`, then `located` once the owner is known. For an
-   issue wholly in the tracker, the trail goes in `issue-tracker.note` and the status changes through
-   `issue-tracker.move`, which refuses `located` without a registered owner in `located-in`.
-3. Resolve. Set `status: resolved` (in the frontmatter, or through `issue-tracker.move` for an issue wholly in the
-   tracker), fill `fixed-by:`, and if the root cause was a design gap,
-   run playbook [02](02-graduation.md) and fill `amended-design:`. **A core issue** — its `located-in`
+   **An issue wholly in the tracker** is done at this step.
+2. Investigate. The trail goes in `issue-tracker.note`, and, for a folder-backed issue, in `01-diagnosis.md` in the
+   same folder as well — dated, including what was ruled out. The status moves through `issue-tracker.move`:
+   to `diagnosing`, then to `located` with `located-in`, which the tracker refuses without a registered owner.
+3. Resolve. `issue-tracker.move` to `resolved` with `fixed-by`, and, if the root cause was a design gap,
+   run playbook [02](02-graduation.md) and give `amended-design`. **A core issue** — its `located-in`
    names the controller, the node-engine, the tool runner, the SDK, or the catalogue's bus, forge or build
-   agent — resolves with `replay:`, the id of its replay in mesh-lab's replays register, proved to fail on
-   the commit before the fix and pass on it, or with `replay-none:` saying why none is possible
-   ([ADR 0237](../../02-DECISIONS/0237-a-change-is-judged-against-the-mesh-that-runs-before-it-merges-on-the-build-seat.md);
-   `cycle.py` checks it on a folder, and `issue-tracker.move` refuses the move without it).
+   agent — resolves with `replay`, the id of its replay in mesh-lab's replays register, proved to fail on
+   the commit before the fix and pass on it, or with `replay-none` saying why none is possible
+   ([ADR 0237](../../02-DECISIONS/0237-a-change-is-judged-against-the-mesh-that-runs-before-it-merges-on-the-build-seat.md));
+   `issue-tracker.move` refuses the move without it. `wontfix` needs a `reason`.
 
 ## Rules
 
 - Closed issues are never deleted — they are the mesh's symptom-to-component memory.
-- `fixed-by:` names something that will still exist: a commit or a pull request, never a branch. A
+- `fixed-by` names something that will still exist: a commit or a pull request, never a branch. A
   branch is deleted when it merges, so a branch name there is a pointer that resolves to nothing by
   the time anybody follows it.
 - A fix that turns out to have broken something else is written back into the record that asked for
@@ -90,4 +93,9 @@ No status is ever kept in two places for one issue.
   sharing a number.
 - An issue whose answer is a general lesson should also be written to the knowledge base, so
   the next person searching a symptom finds it. Both, not either.
-- `status: wontfix` is legitimate and requires a sentence saying why.
+- `wontfix` is legitimate and requires a sentence saying why; the tracker refuses it without one.
+- **A rule states how it is checked.** The cycle's rules on an issue — a status one of the five, `located` with an
+  owner, `resolved` with a fix, a core issue with its replay, `wontfix` with a reason — are refused at the write by
+  `issue-tracker.move` (mesh-catalog `modules/mesh-issues`, its table test over the rules). `cycle.py` checks what
+  this repository still holds: no two folders share a number, every report has frontmatter, and a report opened
+  after the import carries no status key.