Name the acceptance tests in the milestone table and say what the review returns (review round 2)

2026-10-16 02:12:17 +02:00
parent a4c5ef69bb
commit 80b647a2ed
3 changed files with 14 additions and 14 deletions
@@ -63,8 +63,8 @@ An idea arrives in one of two forms, and the first step differs:
     the reviews.
   - **Pre-check before proposing**, against what the review sends back most: every record, issue or design
     the text names is in `links`; work put off names the issue that tracks it (an acceptance test is not
-     put-off work: it is what the build proves, step 6); each figure is given as measured (a range, not a rounded claim); no word on a
-     glossary *Not:* line.
+     put-off work: it is what the build proves, step 6); each figure is given as measured (a range, not a
+     rounded claim); no word on a glossary *Not:* line.
   - **Try at the cheapest level that answers the question.** A program's own behaviour (a library, a
     server, a protocol) is tried in process, on the machine's loopback, in minutes. Lab runs (about 12 to
     16 minutes fresh) are for the mesh's own code; before that code exists, a lab run tests nothing an
@@ -125,8 +125,8 @@ and why, is the more expensive half to rediscover.
 The rules on an effort are the knowledge base's: `propose` refuses one that breaks a rule that judges one
 record (the module's table test holds one case per rule), and the rules that judge the whole record set run
 after every acceptance and raise a condition when one fails. The habits of steps 2, 5 and 6 (options checked
-against the rules, one version per settled set, the cheapest level, nothing left open) are the lead's, read
-by the reviewer; of the pre-check, `propose` refuses a link to nothing and a retired word, and the review
-returns the rest. That this repository holds no effort is
-`records.py`'s `no-records` check, on every pull request. An active effort with no new version for seven
-days is the smell of research left behind: its lead closes or continues it.
+against the rules, one version per settled set, the cheapest level, nothing left open) are the lead's, read by
+the reviewer; of the pre-check, `propose` refuses a link to nothing and a retired word, and the review returns
+a record named but not linked, an untracked deferral and a figure not as measured. That this repository holds
+no effort is `records.py`'s `no-records` check, on every pull request. An active effort with no new version
+for seven days is the smell of research left behind: its lead closes or continues it.
@@ -155,4 +155,4 @@ when one fails. In this repository, `records.py` checks that a design's `decisio
 "ADR NNNN" in the text are well formed, and that no record is written here; `index.py` checks the reading
 order's six topics, which the knowledge base reads. The three habits of graduating step 2 (side by side, clauses
 from the direction, the pre-check) are the lead's, read by the reviewer; `propose` refuses a link to nothing,
-a deferral no issue tracks and a retired word.
+a deferral no issue tracks and a retired word, and the review returns a record named but not linked.
@@ -29,10 +29,10 @@ A design becomes **milestones**, and each milestone becomes **issues**:
   behaviour gets lost.
 4. **Break it into milestones.** Write them into the design, in a section *Milestones*: for each, its number,
   its one-sentence outcome, the acceptance tests of the design it proves, the repositories it touches, and
-   what it depends on. Order them so each is
-   usable as soon as it is delivered, the smallest useful one first.
-5. **Ask the operator to confirm the milestones**, in a short table: number, outcome, repositories, the
-   parts each repository builds. Change what they change.
+   what it depends on. Order them so each is usable as soon as it is delivered, the smallest useful one
+   first.
+5. **Ask the operator to confirm the milestones**, in a short table: number, outcome, the acceptance tests it
+   proves, repositories, the parts each repository builds. Change what they change.
 6. **Open the issues.** For each confirmed milestone, `issue-tracker.open` one issue per repository part, its
   title the symptom or capability in plain words, its report naming the design, the milestone and the
   decisions it builds with; link the order with `depends-on`. Write the issue numbers into the milestone's
@@ -62,5 +62,5 @@ Read by the lead and the reviewer today; a check in hq's merge-check is tracked
  issues; an in-progress design without one is the smell of building without a breakdown.
 - Every issue a milestone names exists in the tracker (`issue-tracker.get`), and an issue in `fixing` names
  its milestone in its report.
- A milestone whose issues are all `resolved` has had its delivery plan done; its outcome sentence and acceptance tests are
-  proven on the mesh before the next milestone starts.
+- A milestone whose issues are all `resolved` has had its delivery plan done; its outcome sentence and
+  acceptance tests are proven on the mesh before the next milestone starts.