docs: green is not the bar, and the list no longer says both (#6)

Step 3 opened by demanding that `python -m pytest` be green and then, two
bullets later, explained that a node which transforms its inputs fails several
of those tests honestly. Both statements were in the same list, and a reader
who acts on the first one never reaches the third: the obvious way to turn a
copies-its-inputs test green is to stop transforming the data, so the
instruction destroyed correct nodes while looking like diligence.

The first bullet now says what the command is and what a green result would
mean; the bar itself is where it belongs, in the bullet that explains which
tests a correct node is allowed to fail.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Author: makseq

CLAUDE.md

@@ -55,10 +55,13 @@ and the stale copy is the one somebody is reading.
    step 2 it is judging **your** container: it builds the image from this repository's own
    `Dockerfile` and never patches it. The commands are in
    [Running the harness](#running-the-harness) — run them from the repository root, as
-   written. The bar, honestly:
+   written. The bar, honestly — and **green is not it**, which is the whole of the third
+   bullet and the only part of this step worth memorising:
 
-   * `python -m pytest` must be green. Exactly one skip is expected and is not about your
-     node: the verbatim-citation check, which needs a checkout of the orchestrator.
+   * `python -m pytest` is how you run it. A green result means your node also behaves
+     like the reference one, which is more than the contract asks of it; a red one is the
+     third bullet's business, not a verdict. Exactly one skip is expected and is not about
+     your node: the verbatim-citation check, which needs a checkout of the orchestrator.
    * `--red-for-real` differs from the plain run only when some test carries
      `expected_red_until_fixed`, and none does today — see
      [the expected-red mechanism](#the-expected-red-mechanism). Run both anyway: the day