Acceptance: method key 2a marks an answer that leaves the sweep and the fix unordered

CONTRIBUTING.md

@@ -29,7 +29,9 @@ review. It is a patch version when released.
 SHOULD or MAY in a numbered section or appendix. It needs everything a clarity edit needs, plus
 the five tests in SCOPE.md answered in the pull request, and it is at least a minor version when
 released. `tools/changes.py` tells the two apart mechanically and CI runs it on every pull
-request.
+request. A change to the acceptance process, as ACCEPTANCE.md defines one under "Changes to
+this process", is neither: ACCEPTANCE.md says how it is made, and it is recorded in
+`acceptance/CHANGES.md`, not in CHANGELOG.md.
 
 ## What a pull request contains
 
@@ -55,20 +57,26 @@ survives, the change is yours.
    the editor sets the pre-release header.
 2. **Scope.** For an obligation, the editor confirms each SCOPE.md test. A failed test closes the
    pull request with a row in `DECLINED.md`.
-3. **Review and rewrite.** An independent review of the diff against the document, then the
-   editor's rewrite, pushed to the pull request branch where the contributor allows it or to an
-   editor's branch that supersedes it.
+3. **Review and rewrite.** An independent review of the diff against the whole document, by a
+   reviewer who did not draft the change, then the editor's rewrite, pushed to the pull request
+   branch where the contributor allows it or to an editor's branch that supersedes it. The pull
+   request names the reviewer and links or contains the review.
 4. **Keys.** Where the change touches a sentence an acceptance key quotes, or adds a load-bearing
-   obligation, the editor updates the key before the cohort runs, never after.
-5. **The cohort.** The acceptance test in ACCEPTANCE.md runs on the final text. Its record is
-   committed under `acceptance/runs/`, the `Unreleased` changelog line names it, and CI refuses
-   a specification change that lacks one. For an obligation, the editor sets the document's
-   header to `<next version>-dev, unpublished` in the same commit if it still names a published
-   version. A wording change after the run means a fresh run.
+   obligation, the editor updates the key before the cohort runs, never after. The key's
+   required elements stay what its question asks for; `acceptance/README.md` says what a key
+   update may and may not do.
+5. **The cohort.** The acceptance test in ACCEPTANCE.md runs on the final text, one cohort per
+   changed document. Its record is committed under `acceptance/runs/`, the `Unreleased`
+   changelog line names it, and CI refuses a specification change that lacks one. For an
+   obligation, the editor sets the document's header to `<next version>-dev, unpublished` in the
+   same commit if it still names a published version. A change to the document's text after the
+   run means a fresh run, as ACCEPTANCE.md says under "When it runs". A finding the
+   run routes to `acceptance/ROUTED.md` is not fixed in this pull request.
 6. **Merge** into `next` by merge commit, and the branch is deleted.
 
-Steps 2 to 5 are done by a person with a Claude Code session, not by CI, and they happen in
-batches. A quiet pull request is not a declined one; a declined one says so.
+Steps 2 to 5 are the editor's, not CI's, and they happen in batches. The editor may have an
+agent draft, review or mark, as ACCEPTANCE.md allows for marking; every decision in these steps
+stays the editor's. A quiet pull request is not a declined one; a declined one says so.
 
 ## Versions and releases
 

acceptance/CHANGES.md

@@ -0,0 +1,46 @@
+# Changes to the acceptance process
+
+Changes to the acceptance process, as [ACCEPTANCE.md](../ACCEPTANCE.md) defines one under
+"Changes to this process", recorded here as it describes: a line is added at the top for each
+change, naming its pull request. The process is not a specification and is not versioned, and a
+change to it is not tested by a cohort. Changes to the three specifications are recorded in
+[CHANGELOG.md](../CHANGELOG.md).
+
+- [Pull request #26](https://github.com/Defence-Before-Fix/defence-before-fix.github.io/pull/26): the method key's 2a says how an answer is marked when it says that the
+  defect handed is fixed after some steps and, elsewhere, that every instance is swept and fixed,
+  without saying which comes first. The question asks in what order, so the order is the point of
+  element (2), and such an answer does not state it. The key now says that "the fix" in element
+  (2) is the fix of the defect handed, that a quotation such as clause 3.4's "before fixing anything" states it, and that an answer
+  putting the fix before the sweep is wrong whatever it quotes. Run 89, on the gap-terms change,
+  recorded the point as open and marked it for the reader under the open-point rule. This applies
+  to runs whose readers start after it merges, and changes no mark already given.
+- [Pull request #22](https://github.com/Defence-Before-Fix/defence-before-fix.github.io/pull/22):
+  the test is made to prove what it exists to prove, the clarity of the
+  document to a cold reader, after thirty-three runs on two changes (19 to 30, 31 to 33 and 35
+  to 52) in which keyed answers reached five of five and the runs still failed. Five defects in
+  the process were found. Keys required elements the question never asked for (detector 2b's
+  "need not remove or forbid", detector 2c's "at a version tracked together", and on pull
+  request 14 method 2d's order of the kinds), so readers who answered the question as put were
+  marked wrong: now each key lists, per item, the elements an answer must state, one for
+  each part of the question, and the questions are reworded to ask for exactly those; anything
+  else in the key only catches a wrong assertion. A passage two readers found confusing stayed
+  open whilst any single reader of a later cohort named any part of its paragraph, so cleared
+  passages kept coming back: now a finding is settled run by run, raised by two readers of one
+  run and clear when the next names it by fewer than two. A finding landed on text the change
+  never touched, so a change's cohort acted as a review of the whole document and could not
+  converge: now a finding in text the change wrote or altered blocks the change, and a finding
+  elsewhere is routed to `acceptance/ROUTED.md` and to a change of its own, whilst the keyed
+  questions still prove the whole document on every run. Markers invented judgements the rules
+  left open and later runs cited them as precedent: now an open point is marked for the reader
+  and settled in this file or the key before the next run, and a run record states no judgement
+  the rules do not. The rule that any miss whose reasoning quoted the document was a finding
+  whatever the count is replaced by the key naming the wrong readings the text invites, which
+  count against the document on one reader, every other single miss being tolerated by the
+  all-but-one threshold. Question 2's instruction asks for the sentence or sentences relied on,
+  since three keys rest on two. The cohort, the packet, set-aside readers, the posted sheets,
+  the fuller record and the route for a process change are kept from the earlier proposal in
+  pull request 13, which this change supersedes. Relative to the rules on `next`, the
+  traceable-miss row is narrower and the confusion row is applied to the change rather than
+  the document; both are recorded here as the reason the earlier rules could not converge, and
+  neither changes a mark already given. Prompted by runs 19 to 30 on pull request 14 and runs
+  31 to 33 and 35 to 52 on the defined-terms change.

acceptance/README.md

@@ -2,8 +2,10 @@
 
 The question sets and answer keys that [ACCEPTANCE.md](../ACCEPTANCE.md) requires. One directory per
 specification document, each holding the fixed questions a cold reader answers and the key an
-editor marks against. The fixture cases the application question uses live in `fixtures/`, and
-the record of every run lives in `runs/`.
+editor marks against. The fixture cases the application question uses live in `fixtures/`, the
+record of every run lives in `runs/`, findings routed out of a run to a change of their own are
+listed in [ROUTED.md](ROUTED.md), and changes to the acceptance process itself are recorded
+in [CHANGES.md](CHANGES.md).
 
 | Document           | Questions                                        | Key                                  |
 | ------------------ | ------------------------------------------------ | ------------------------------------ |
@@ -14,24 +16,61 @@ the record of every run lives in `runs/`.
 ## How a run works
 
 1. The editor identifies which documents the change touched. Only those are tested.
-2. For each, five or more fresh low-strength readers each receive the document's current text,
-   its `QUESTIONS.md`, and the fixture the questions name. Nothing else: no key, no changelog, no
-   critique findings, no other reader's answers.
-3. The editor marks each answer sheet against `KEY.md` and applies the pass criteria in
-   `ACCEPTANCE.md`.
-4. The result is recorded as a file under [runs/](runs/), with cohort size, model, run number,
-   marks and the findings applied, and the change's `Unreleased` changelog line names that file.
-   A run that fails is followed by a change to the text, never to the questions, and a fresh
-   cohort.
+2. For each, an odd number of fresh low-strength readers, at least five, each isolated as
+   `ACCEPTANCE.md` describes, receive the document's current text, its `QUESTIONS.md`, and the
+   fixture the questions name. Nothing else: no key, no changelog, no critique findings, no other
+   reader's answers.
+3. The editor, or a separate marker the editor delegates to, marks each answer sheet against
+   `KEY.md` under the marking rules in `ACCEPTANCE.md` and applies its pass criteria.
+4. The result is recorded as a file under [runs/](runs/), stating what `ACCEPTANCE.md` lists,
+   with the answer sheets posted on the pull request and linked from it, and the change's
+   `Unreleased` changelog line names that file. A run that fails is followed by a change to the
+   text its misses and findings name and a fresh cohort; a finding on text the change did not
+   write or alter is added to [ROUTED.md](ROUTED.md) instead.
+
+## How a key is written
+
+A key says, for each keyed item, exactly what is marked and nothing a marker has to guess:
+
+- **Question 1**: the obligations a bullet may name, the assertions that make a bullet wrong,
+  and the wrong readings the text invites, if any.
+- **Question 2**: for each item, the elements an answer is required to state, numbered, one for
+  each part of the question; the assertions that make an answer wrong; and the sentence or
+  sentences of the document the answer rests on, quoted verbatim, which show the marker where
+  the elements come from and which `spec-qa.py` checks against the document; a reader's
+  quotation need not be that one. The required elements are what the question asks for, no
+  more: an element the question does not ask for is not required, however load-bearing, until
+  the question is reworded to ask for it.
+- **Question 3**: for each item, the grade or grades accepted, any condition on the reasoning,
+  and the wrong readings the text invites, which count against the document when one reader
+  takes them.
+
+Everything else in a key is explanation for the marker and never marks an answer down.
 
 ## Keeping the keys honest
 
 A key quotes the document. When a clause is reworded, the key line that quotes it is updated in
 the same commit, and the change is one the acceptance run itself then tests. A key that no longer
 matches the document is a defect in this directory, not a reason to mark a reader wrong.
 
+A key, a question set or a fixture changes by one of two routes, as `ACCEPTANCE.md` says under
+"Changing the test", always before the readers of the next run start, and an open point a run
+recorded is settled by whichever route it needs:
+
+- **In a specification pull request, under step 4 of `CONTRIBUTING.md`**: a quotation follows
+  the text it quotes; a keyed item is added for a new load-bearing obligation together with the
+  question that asks for it; or, where the change alters or removes the obligation an existing
+  item tests, that item and its question follow the text, which is the text changing and not
+  the test. The pull request's own changelog line records it. Such an update does not change
+  what an item requires of an obligation the change leaves as it was, nor the wording of a
+  question whose obligation is unchanged.
+- **In a process change, with its own pull request**: what an existing item requires, the
+  wording of a question, a fixture, or the rules of marking. It is recorded in
+  [CHANGES.md](CHANGES.md) with its reason.
+
 Questions are fixed so that runs can be compared across versions. Adding a keyed question is
-allowed when a new clause is load-bearing; removing or softening one to make a run pass is not.
+allowed when a new clause is load-bearing; removing or softening one to make a run pass is not;
+rewording one is allowed so that it asks for what its key requires, and for no other reason.
 The reader may quote a passage it found confusing; it is never asked to rate the document, say
 what would make a passage clearer, or propose a change: the cohort confirms comprehension and
 does not design the text.