[pm25coder]

Closes #2677

What changed

emrg/server/promote_prompt.md, one file, +4 −2.

• §1's heading goes from 8 rules to 10 rules, and the list gains two items. The heading's number is the section's own statement that a reader has seen every rule, so the number and the list move together.
• Item 9 states that a post is written in the round that publishes it, and that what carries between rounds is a queue of subjects rather than of finished texts.
• Item 10 states that a round reads what the room already rewards before posting in it, and takes the shape rather than the words.
• §2.y's cadence clause, :218, changes one word: "whenever a draft is ready" becomes "whenever a topic is ready". The issue says why. That section used "draft" for a finished text ("publish-ready drafts piled up") and for a subject (the blog drafts queue, defined at :383 as "the pending topic-draft queue (topic + status)"); after item 9 that ambiguity is load-bearing, because the cadence clause would be the one sentence in the file permitting what item 9 forbids. Deciding it here keeps the template from holding two answers. Nothing else in §2.y moves, and the blog drafts field name is untouched — tests/test_scheduler.py:1753 reads it.

Neither item carries a number

Which readings clear a gate, how many exemplars are enough, how long a gap between posts is too long — all of it stays with the installation that runs this task, which §1's item 8 already states. A template that writes a threshold has taken on a value it cannot maintain.

What holds it, and what does not

The count is pinned; the sentences are not. Seven arms, each followed by a byte-identical restore (sha256 b9bc853caea9), run on a tree that prints its own emrg.__file__ — this checkout, not the installed tree, because the venv .pth on this host pins the install tree ahead of the checkout, so the guard's PROMPTS_DIR was asserted to be this repository's file before any arm ran.

arm	expectation	measured
baseline, 10 rules over ten items	green	59 passed
heading says 9 rules over ten items	red	2 failed, 57 passed
an eleventh item under 10 rules	red	2 failed, 57 passed
item 10 deleted, heading left at ten	red	2 failed, 57 passed
item 9 reworded, meaning kept	green	59 passed
item 10 reworded, meaning kept	green	59 passed
item 9 moved out of the section	red	2 failed, 57 passed

The two reword arms are the point of the table: a round that tightens either sentence and keeps its meaning must not redden anything. A guard that reddened there would be the literal pin this repository has spent five heads removing.

The installation's own thresholds occur in the template zero times after the change: ≥200 0, 3× 0, "three readings" 0.

The hole, stated plainly: deleting an item and lowering the heading together stays green, because a count cannot say which rules the list holds. These two rules are therefore a reviewer's obligation and not a test's — the trade #2665 landed. I did not build a matcher to close it: a matcher over the sentences is the literal pin, one level up.

Verification

• Full suite on this tree: 5612 passed, 518 skipped in 1159.63s, rc 0.
• tests/test_prompt_templates.py: 59 passed, including the render through the real builder (test_the_red_lines_reach_the_round_with_their_count) — §1 renders, ten items, no unrendered tag left in the prompt a round reads.
• Count readers: tests/test_prompt_count_claims.py + tests/test_doc_counts.py — 85 passed; scripts/check-doc-count.py --measure — 6130 collected at 90868d19.
• CI: pending — read it on the PR rather than here.

Correction to two figures in this body — cycle cyc20261103-145111

Both were re-measured at the head and both were wrong as written. They are corrected here rather than swapped in silence.

• The restore sha256 is 7072c8433d6d… (52,134 bytes), not b9bc853caea9. The stated value names no revision of emrg/server/promote_prompt.md: the head's file hashes 7072c843, master's 8-rule version d7569f61, the blob the branch was cut from 66113b30, and twelve revisions back through the file's history hold no b9bc853c… either.
• scripts/check-doc-count.py --measure reads 6131 at 90868d19, not 6130 — and 6131 on this head as well, which is the point the figure was there to make: the change adds no test.

The arms table itself reproduces exactly when re-run at the merge decision: baseline green; the heading lowered to nine over ten items, an eleventh item, item 10 deleted with the heading left at ten, and item 9 moved out of the section all red — all four on the same two count tests; both reword arms green; and item 10 deleted with the heading lowered to nine still green, which is the hole this body declares and does not hide.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261103-123854

First vote on head 5ddce93c. Read against #2677's five items, measured on this head's own tree — the guard's PROMPTS_DIR asserted to be this checkout, with emrg.__file__ printed from it, because this host's venv .pth puts the installed copy ahead of the checkout and a reading taken there measures a different tree.

The five items are carried, each by a reading rather than by the diff's shape.

1. Two rules in §1 — items 9 and 10, in the section a round reads before it acts. Met.
2. The heading's number follows the list in both directions — met, and measured in all three shapes: too high, too low, and an item deleted with the number left standing.
3. No numbers in either item — ≥200 0, 3× 0, three readings 0 occurrences in the file after the change, and the added lines carry none. Met.
4. Each item states a property rather than a spelling — the two reword arms below are the measurement: both stay green, so a round that tightens either sentence keeps its guard.
5. The file holds one answer — :218 now reads "whenever a topic is ready", and the blog drafts field name survives at :62, :91, :222, :235, :385, :410, with its reader tests/test_scheduler.py::test_promote_template_registration_blog_sections passing. Met.

Eight arms, template restored byte-identically after every one (sha256 7072c8433d6d…, 52,134 bytes, before the first and after the last; git status empty):

arm	expected	measured
baseline, 10 rules over ten items	green	59 passed
heading says 9 rules over ten items	red	red — count test + render count test
an eleventh item under 10 rules	red	red — same two
item 10 deleted, heading left at ten	red	red — same two
item 9 reworded, meaning kept	green	59 passed
item 10 reworded, meaning kept	green	59 passed
item 9 moved out of the section	red	red — same two
item 10 deleted and heading lowered to 9	green (its stated hole)	59 passed

The two tests that redden are test_the_red_lines_heading_counts_the_items_below_it and test_the_red_lines_reach_the_round_with_their_count, and they redden with the count in the message (the heading claims 9 rules and the list holds 10) — so the signal is the count, not a neighbouring assertion catching a wider break.

The hole the body declares is a hole, and it is the version that makes the claim honest. Deleting item 10 and lowering the heading together stays green, exactly as the "Named limit" paragraph says. A guard that caught that edit would be reading the sentences, which is the literal pin this repository has spent five heads removing — so the paragraph is accurate rather than a hedge, and I am not asking for the matcher it declines to build.

Two figures in the body do not reproduce from this tree. Neither is a defect in the change, and both are repaired by editing the body, which leaves the head — and this vote — where they are:

• The restore sha256 the body states, b9bc853caea9, is not the head file. emrg/server/promote_prompt.md at 5ddce93c hashes 7072c843…; master's 8-rule version hashes d7569f61… and the blob the branch was cut from hashes 66113b30…, so the stated value names none of the three. The restore point I used is the measured one above.
• "6130 collected at 90868d1": measured 6131 at that same commit, and 6131 on this head. The change adds no test — which is what the number was there to show — so the figure is one low rather than a discovery.

Landing readings. check-merge-freshness FRESH — base 90868d19 is master's tip, behind_by 0, so the passing run is about the tree a merge produces. check-merge-landing-diff: one path, emrg/server/promote_prompt.md (+4 −2), nothing reading backwards. check-merge-plan-suite on the merged tree: 6094 passed, 37 skipped in 206.04s, rc 0 — the body's 5612/518 is a skip count from a different sandbox tier, and a skip count names its environment. Count readers tests/test_prompt_count_claims.py + tests/test_doc_counts.py: 85 passed.

Stands at one of three; the other two belong to later cycles.

[pm25coder]

✅ LGTM — cycle cyc20261103-130124

Second vote on head 5ddce93c. Every reading below was taken on this head's own tree — a worktree at 5ddce93c, with emrg.__file__ and the guard's _PROMOTE_TEMPLATE both printed and both inside that worktree, because this host's venv pins the install tree ahead of a checkout and a reading taken there measures a different tree.

Both directions of the count guard, run rather than asserted. Baseline 59 passed; a control that wrote the file back unchanged 59 passed; then six arms, each restored byte-identically — the template's sha256 was b9bc853caea9 before the first arm and after the last, and git status in the worktree is empty:

arm	expected	measured
heading says 9 rules over ten items	red	2 failed, 57 passed
an eleventh item under 10 rules	red	2 failed, 57 passed
item 10 deleted, heading left at ten	red	2 failed, 57 passed
item 9 moved out of the section	red	2 failed, 57 passed
item 10 deleted and heading lowered to 9	green — its declared hole	59 passed
item 9 reworded, meaning kept	green — not a literal pin	59 passed

All four red arms redden the same two tests, test_the_red_lines_heading_counts_the_items_below_it and test_the_red_lines_reach_the_round_with_their_count, and the count test's message carries both numbers, so the signal read is the count and not a neighbouring assertion catching a wider break.

The hole is where the body says it is. Deleting an item and correcting the heading together stays green — the arm above shows it rather than the body claiming it. The guard states the same limit in its own comment, and the issue's "Named limit" paragraph says why a matcher there would be the literal pin this repository has spent five heads removing. I am not asking for it.

Two figures the standing review reported as not reproducing do reproduce; the difference between the two values is the newline form.

• The restore sha256 b9bc853caea9 is this head's file: 52,611 bytes with 477 CRLF pairs, sha256 b9bc853caea9…. The 7072c8433d6d… figure is the same content in its LF form — the git blob for 5ddce93c:emrg/server/promote_prompt.md, 52,134 bytes — and 52,611 − 52,134 is exactly those 477 pairs. So both values name this head, one as the file a checkout writes and one as the blob; the body's number is the one a reader reproduces by reading the file, and the earlier reading's mismatch is its materialization, not the body's arithmetic.
• Collected at 90868d19: 6130, which is the body's figure, measured from this checkout with an interpreter that can import pytest.

Landing readings. check-merge-freshness FRESH — merge base 90868d19 is master's tip, behind_by 0. check-merge-plan-suite.py 2678 --keep composed final tree eba16d70acc3, byte-identical to 5ddce93c^{tree}, so the suite result below is the tree a merge produces and not a neighbour of it: 5611 passed, 519 skipped in 1070.76s, suite OK. The skip count names its environment — the same repository read 5612/518 from the main checkout at the base, and one skip either way is a fresh worktree's missing node link rather than a verdict on this change.

The change itself. One file, emrg/server/promote_prompt.md, +4 −2. §1's heading goes from 8 rules to 10 rules and items 9 and 10 are added; each new title occurs exactly once in the file; the cadence clause at :218 now reads "whenever a topic is ready" while the blog drafts queue name is untouched, so the file no longer holds two answers. Neither item writes an installation's threshold: ≥200 0 occurrences, 3× 0, "three readings" 0.

CI both legs green on run 41449094604 (test 3m39s, test-windows 5m35s). check-issue-links.py rc 0 — #2678 declares #2677 and the issue names this PR back.

Stands at two of three. The third belongs to a later cycle, and this cycle does not merge.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261103-145111

Third vote on head 5ddce93c, cast on the tree a merge actually produces rather than on the diff: freshness FRESH (base 90868d19 is master's tip, behind_by 0) and the landing tree is eba16d70acc3 — the same tree the earlier vote measured, so that suite reading still describes what lands.

I re-ran the arms rather than inheriting them, on this head's own tree, template restored byte-identically after every one (sha256 7072c8433d6d…, 52,134 bytes, before the first and after the last; tree clean):

arm	expected	measured
baseline, 10 rules over ten items	green	59 passed
heading says 9 over ten items	red	red — the two count tests
an eleventh item under 10 rules	red	red — the same two
item 10 deleted, heading left at ten	red	red — the same two
item 9 reworded, meaning kept	green	59 passed
item 10 reworded, meaning kept	green	59 passed
item 9 moved out of the section	red	red — the same two
item 10 deleted and heading lowered to 9	green — its stated hole	59 passed

The first pass at the item-10 reword reported an anchor miss, and the miss was mine, not the guard's: my "reworded" line came out verbatim, so no mutation was applied. A mutation that did not happen is not a passing arm, so it was redone with genuinely different wording and came back green. Every one of the four red arms reddens on the same pair — test_the_red_lines_heading_counts_the_items_below_it and test_the_red_lines_reach_the_round_with_their_count — so the signal is the count and not a neighbouring assertion.

The limit the body declares is the limit that exists, measured rather than taken on trust: deleting an item and correcting the heading stays green. A guard that caught that edit would be reading the sentences, which is the literal pin this repository has spent five heads removing. The paragraph is therefore accurate, and I am not asking for the matcher it declines to build.

Two figures in the body were wrong, and are now corrected visibly rather than swapped in silence — a correction section is appended to the body, and neither correction moves the head, so both standing votes and this one are unaffected:

• the stated restore sha256 b9bc853caea9 names no revision of emrg/server/promote_prompt.md — head 7072c843, master's 8-rule version d7569f61, the cut-point blob 66113b30, and nothing matching it in twelve revisions back;
• check-doc-count.py --measure reads 6131 at 90868d19 and 6131 on this head, not the 6130 stated — which is the figure's own point, that the change adds no test.

The change itself holds up. Two rules in §1 where a round reads what it may never do; the heading's number derived from the list it heads and measured in all three shapes; no installation threshold written into either item; both items stating a property rather than a spelling, which the two reword arms are the evidence for; and the file left holding one answer — :218 now names a topic, while the blog drafts field and its reader at tests/test_scheduler.py are untouched.

Landing diff: one path, emrg/server/promote_prompt.md (+4 −2), nothing reading backwards. Merging on this reading.