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

@@ -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