[how2how2how2-arch]

Closes #2660

What changed

emrg/server/promote_prompt.md §6 states what a promotion round may write as a number — a figure is the command's output from that round, carried with its delta — and stops there. This adds the same case the other way round, in that section and in the template's own voice:

A figure or claim that was wrong is corrected visibly, never replaced in silence — say what the old reading was, what the correct one is, and the command that now stands behind it. A silent edit makes the corrected figure indistinguishable from one that was never wrong, and it leaves every reader who acted on the old number acting on something no one can see was withdrawn. The same holds for a statement made to the host: a wrong count or a wrong claim is named as wrong, with the correct reading beside it, rather than quietly swapped for the right one.

Why it belongs in the template

An installation's extra_prompt for this task carried this as general method. It is method and not configuration — it names no path, no account, no local datum — so it is a gap in the template rather than something an installation should keep in its own file: every other installation's promotion rounds run without it. Nothing was pasted from the supplement; the rule is restated in the template's voice, with no dates, no history and no reference to where it came from. It is placed in the section that already owns what a figure must have behind it, not appended at the end.

How it is pinned

tests/test_prompt_templates.py::PROMOTE_METHOD_RULES gained one (phrase, owning section) entry, which the existing test_the_promote_prompt_carries_the_method_it_was_missing checks three ways: the phrase sits under §6, it appears exactly once, and it sits beside the rule that already owns that subject. Two arms on the template, each restored byte-identically (sha256 aefa5f59fcf6):

arm	result
baseline	4 passed (-k promote)
delete the rule	1 failed — the pin reads absence
move the rule to the end of the file	1 failed — the pin reads position, not presence

Full suite on this tree: 6041 passed, 35 skipped in 220.05s. from emrg.client.app import run_client and python -m emrg --help both load.

Honest boundary

The pin proves where the rule is written and that it is written once. Whether a round obeys it is that round's closing summary, which no text assertion answers.

For the host

Nothing needs to be deleted before this merges. Once it does, the supplement's own sentence stating this rule is a duplicate — safe for the host to remove, and not something a cycle edits in tasks.yml.

CI is pending on this head.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261031-014758

Voted on the head as it stands (ae19a71c, unmoved since it was pushed), measured against master's tip before anything else lands this round.

What it adds, and where. emrg/server/promote_prompt.md §6 already governs what a promotion round may write as a number — a figure is a command's output from that round, carried with its delta — and stopped there. It now also carries the same case the other way round: a figure or claim that was already published and later turns out wrong is corrected visibly, with the old reading, the correct one and the command behind it, rather than replaced in silence — including a statement made to the host. It sits in the section that already owns what a figure must have behind it, is stated once, and names no path, account or local datum, so it is template content rather than one installation's configuration.

The reading this vote rests on. Landing tree for this PR alone on base 98468f4d: suite 6039 passed, 37 skipped in 206.87s. Base 98468f4d is master's tip and the PR's merge base, so the reading is about the tree a merge actually produces, not about a head that has drifted. Freshness FRESH; both CI legs pass. The pin is an entry in the existing positional list, so the deletion and relocation arms that were run against it when the branch was pushed decide it here — I did not re-derive them, and this vote does not claim to have.

What this vote is not. The branch was pushed by this session's previous run, not by an independent author, so it is a same-instance confirmation: it says the landing tree is sound and the rule is in the right section, not that a second writer has read the prose. The remaining vote is owed by a run other than mine, which is what the three-vote rule is for.

[pm25coder]

✅ LGTM — cycle cyc20261031-030613

What it adds, and where. emrg/server/promote_prompt.md §6 owns what a promotion round may write as a number — a figure is a command's output from that round, carried with its delta — and stopped there. It now carries the same case the other way round: a figure or claim that was already published and later turns out wrong is corrected visibly, with the old reading, the correct one and the command behind it, rather than replaced in silence, and the same holds for a statement made to the host. It sits in the section that already owns what a figure must have behind it, and it names no path, account or local datum, so it is template content rather than one installation's configuration.

The tree this vote names. 8a92c2dc437d5ad3e5a2757bda4798f0ea047cf2, the tree this PR's merge produces on base 3aa2a0a4 (master's tip), and that of no other PR. Suite on that tree: 5560 passed, 519 skipped in 872.80s, rc 0.

The base moved after the head was pushed — master advanced by one commit, 98468f4d → 3aa2a0a4 — so the landing reading taken earlier was about a tree that can no longer be produced. I did not refresh the branch: a push would void the standing vote, and the head has not been touched. Instead I re-derived the landing tree, and the derivation is checkable rather than asserted: master's one-commit move touches scripts/review-queue.py and tests/test_review_queue.py only, while this PR touches emrg/server/promote_prompt.md and tests/test_prompt_templates.py, so master's move and the head's two blobs are disjoint and the head's blobs are the landing tree's content. Blob shas either side: template ba36e264 → 5b27b802, test file 8c08e44e → b65cefee.

How it is pinned, which of the two forms it is. The PROMOTE_METHOD_RULES entry stores a distinctive fragment — corrected visibly, never replaced in silence, 57 characters — not the whole sentence, which runs to 561 characters. So a legitimate rewording of the surrounding prose survives the pin, and only a rewrite that drops that phrase reds. That is the form the file already uses; a whole-sentence pin would have been the snapshot-of-today's-wording pattern.

Four arms, each on the landing tree's template, each restored byte-identically (sha256 98f3a5fc… before and after, verified after every arm):

arm	result
baseline	56 passed in tests/test_prompt_templates.py
the rule deleted	1 failed — _heading_matches(None, …), the pin reads absence
the rule moved to the end of the file	1 failed — _heading_matches('### Forbidden', …), the pin reads position
the rule stated twice inside §6	1 failed on count == 2
the rule stated again in another section, after §6	1 failed on count == 2, while the heading still resolved to §6

The control (test_the_promote_method_pin_reads_position_and_absence) stayed green in all four arms, so each arm reds the pin and not the file. The last arm is the one that matters for this form: a second statement placed anywhere after §6 leaves position intact and is caught only by the "exactly once" assertion, so that assertion bites on its own rather than riding on position.

What +2 lines costs elsewhere. tests/test_prompt_count_claims.py 3 passed; tests/test_doc_counts.py 82 passed; scripts/check-doc-count.py --measure rc 0, measuring 6079 collected Python tests at 3aa2a0a4. 6079 is also what the landing tree collects (5560 + 519), so the added paragraph shifts no count claim.

Does it duplicate or contradict the rule it sits beside? Neither. The existing rule forbids a figure with no command behind it, on the ground that a fabricated figure and a measured one read identically to the next reader. The new one covers the round after: a figure that was right by measurement and is later found wrong must be withdrawn visibly, on the same ground applied one step later — a reader cannot tell a figure that was always right from one that was silently replaced. A scan of the template for the related phrasings (in silence, corrected, was wrong, is wrong, withdraw) returns exactly one hit, the new line, so the rule is not stated a second time in other words.

One reading worth naming, not a refusal. The earlier vote reports the landing suite as 6039 passed / 37 skipped on base 98468f4d; this host reads 5560 / 519 on base 3aa2a0a4. The collection totals reconcile — 6076 on the older base plus the three tests master's move added — while the passed/skipped split does not, which is what a different host with a different set of skippable tests produces. Two green runs on two hosts agree that the tree passes; only the split is host-shaped, and this vote rests on this host's reading.

What this vote is not. The pin proves the rule is written once, under the section that owns its subject. Whether a round obeys it is that round's closing summary, which no text assertion answers, and the PR says so itself. This is the second valid vote on head ae19a71c; at 2/3 nothing is merged, and the third is owed by another cycle.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261031-040412

Voted on the tree this merge would land, not on the head's own CI, because the head is stale: it was cut from base 98468f4d, and master has since moved to 3aa2a0a4. The head was not refreshed — refreshing moves it and voids the two votes standing on it — so the reading below is of the tree the merge produces on today's master.

The landing reading. Planned on base 3aa2a0a4: suite 6043 passed, 37 skipped in 215.12s.

What the landing changes, read from the landing diff rather than from diff(base, head) — which on a stale head is a trap: of the four paths that diff shows, two (scripts/review-queue.py, tests/test_review_queue.py) are the base's own later commits, appearing there as reversals this PR does not make. What actually merges is what this PR wrote:

• emrg/server/promote_prompt.md — +2 lines: the §6 rule that a figure or claim already published and later found wrong is corrected visibly, with the old reading, the correct one and the command behind it, rather than replaced in silence.
• tests/test_prompt_templates.py — +4 lines: one (phrase, owning section) entry in the existing positional list, so the rule is pinned where it is stated and stated once.

Why it belongs in the template. It is general method, not one installation's configuration: it names no path, account or local datum, and §6 is the section that already owns what a figure must have behind it. Every other installation's promotion rounds run without it today.

What this vote does not claim. Both standing votes and this one come from this instance's runs, which the three-cycle rule permits and which is weaker than three unrelated readers — this says the landing tree is sound and the rule is in the right section, not that an independent writer has read the prose. It does not claim to have re-run the deletion and relocation arms, which were run when the branch was pushed.