From 2a61c572583dfe2d8624f3a4e20419c164ed1357 Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 16 Oct 2026 02:09:22 +0200 Subject: [PATCH] Settle research decisions before proposing versions, and test on the cheapest bed (playbook 01) Research 053's identity part took six versions and about two hours: options that broke the mesh's own rules were offered and argued back, a version was proposed after every answer, and reviews returned findings a pre-check would have caught. A lab run was planned where an in-process test answered. --- 00-META/process/01-research.md | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) diff --git a/00-META/process/01-research.md b/00-META/process/01-research.md index a4118093..8a496528 100644 --- a/00-META/process/01-research.md +++ b/00-META/process/01-research.md @@ -30,6 +30,14 @@ An idea arrives in one of two forms, and the first step differs: 2. **Ask the operator to set it up.** A few questions, one at a time, each answerable with a choice and carrying a recommendation: what comes first, what is out of scope, which options must be tried, what done looks like. Three to five questions is usual; the answers are the effort's first findings. + - **Check every option against the mesh's own rules before offering it.** An option that breaks one + (the core values in [`mission.md`](../mission.md): the mesh owns the truth, few and deliberate outside + dependencies; the rules in [`how-we-build.md`](../how-we-build.md); and the operator's standing word + that everything between modules goes over the bus) is dropped, or offered only with the rule it breaks + named. A recommendation the operator has to argue back costs a round and a version. + - **Explain each question with a concrete picture** in the operator's words: what they would see, do or + lose under each option. No internal names (a record number, a verb, a word the glossary lacks) without + what it is beside it. 3. **Take a number.** `knowledge-base.reserve` with `kind: research` and `for`: the effort's title. The number is spent whether or not the effort is ever proposed; one never proposed is withdrawn after a week. Never pick one by hand. @@ -45,13 +53,28 @@ An idea arrives in one of two forms, and the first step differs: 5. **Do the research.** Try, measure and read, smallest question first. Each finding goes into `04-findings.md`: what was tried, what it showed (with numbers), what it means. Each change of the effort is `knowledge-base.propose` again, whole, with `why`; every version is kept, and `knowledge-base.history` - lists them and gives the difference between two. Until issue 844 is delivered, the knowledge base + lists them and gives the difference between two. + - **Propose a version per settled set, not per answer.** While the operator answers a run of questions, + or while experiments run, keep the answers and findings in the session's save point and propose once + when the set is settled. Each version is reviewed and resent whole, so a version per answer multiplies + 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, or is one of the build's + acceptance tests (step 6); each figure is given as measured (a range, not a rounded claim); no word on a + glossary *Not:* line. + - **Try on the cheapest bed 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. The lab's beds (about 12 to 16 + minutes a fresh run) are for the mesh's own code; before that code exists, a lab run tests nothing an + in-process test does not, and its bed test is written as the build's acceptance test instead. Until issue 844 is delivered, the knowledge base takes a new version of an accepted, active effort only as a progressive insight: give `insight`, saying what the effort held before the new finding, and mark the finding in the text with its date. 6. **Settle the direction with the operator.** When the questions are answered, write `05-direction.md`: - the proposed decisions in a few lines each, the options rejected and why, what is left open. Ask the - operator to confirm or change it, one point at a time. Then the effort graduates through playbook - [02](02-graduation.md). + the proposed decisions in a few lines each, the options rejected and why, and the build's acceptance + tests: what the build must prove before it is done, carried by its milestones (playbook + [04](04-build-handoff.md)). Nothing else is left open: each question closes by a test, by a decision the + effort records with its reason (a small design limit is the lead's), or by the operator. Ask the + operator to confirm or change the direction, one point at a time, then propose it once. Then the effort + graduates through playbook [02](02-graduation.md). ## Bounds and models