From 80b647a2ed666f6e732c40bc116f9493fa53e2cd Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 16 Oct 2026 02:12:17 +0200 Subject: [PATCH] Name the acceptance tests in the milestone table and say what the review returns (review round 2) --- 00-META/process/01-research.md | 14 +++++++------- 00-META/process/02-graduation.md | 2 +- 00-META/process/04-build-handoff.md | 12 ++++++------ 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/00-META/process/01-research.md b/00-META/process/01-research.md index 673874c2..c1afd96f 100644 --- a/00-META/process/01-research.md +++ b/00-META/process/01-research.md @@ -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. diff --git a/00-META/process/02-graduation.md b/00-META/process/02-graduation.md index a0b9b30a..ad224c30 100644 --- a/00-META/process/02-graduation.md +++ b/00-META/process/02-graduation.md @@ -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. diff --git a/00-META/process/04-build-handoff.md b/00-META/process/04-build-handoff.md index 62423e68..864c6438 100644 --- a/00-META/process/04-build-handoff.md +++ b/00-META/process/04-build-handoff.md @@ -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.