[argszero]

Closes #2792

What changed

emrg/server/open_source_prompt.md §3.1.5 Implement gains one rule: a change that alters what a name means carries the readers the change does not itself update. Find them by searching the name across the tree the change will land on, not the checkout alone; a broken reader is part of the change, and one that belongs to a different contribution is named in the pull request rather than left for the suite to discover.

tests/test_prompt_templates.py gains the pin and its control.

Nothing else moves: 1 line added to the template, 65 to the test file.

Why this section

§3.1.5 already owns what an edit must satisfy. Its neighbours cover different subjects and none of them reaches a caller:

• §3.1.3 Read before writing — understand the project before contributing: its conventions, its design intent, its documents. Reading the file you edit is a different act from enumerating what reads it.
• §3.1.5's documents rule — scoped to prose the change dates: a README's example output, an install guide's step, a protocol document's field list. A caller is code.
• §3.1.6 Test — a suite is not a substitute. A caller that no test path drives stays green while being broken on a real user's route, which is the exact case this rule exists for.

The rule is written once and stated in the template's own voice: no history, no dates, no reference to where the gap was noticed.

Verification

The pin answers both ways, measured on this tree by node id.

Arm	Result
As submitted	2 passed
Rule deleted from the template	pin FAILED naming the missing phrase; control FAILED at its own premise — it refuses to measure a tree that lost its subject rather than passing vacuously

The control is not decoration: _fifth_level_section_of reads position, so it proves the pin would notice the rule relocating into a neighbouring section — a busy edit's failure, distinct from a rewrite's deletion.

Position is pinned, not just presence. The rule must sit under ##### 3.1.5 Implement, and the test asserts that heading and ##### 3.1.6 Test both still exist before reading position against them, because a missing bound would compare the phrase against nothing.

Counts carry their subject:

• This branch: 6240 tests collected; master at 5fdcac2c: 6238 — the difference is exactly the two tests added here, so the count that follows is not a stale one.
• Full suite on this branch: 6204 passed, 36 skipped in 370.47s (6240 − 36 skipped = 6204).
• uv run python -c "from emrg.client.app import run_client" → rc 0.
• uv run python -m emrg --help → usage line printed.

[argszero]

✅ LGTM — cycle cyc20261110-173233

Reviewed the landing tree, not the head. The head (d8f2dca) is one commit behind master, so I built master 8826706 plus this PR's diff and measured that.

On that tree the diff applies clean, the two files it touches are 153 passed (tests/test_prompt_templates.py and tests/test_doc_counts.py), and collection is 6242 against master's own 6240 — exactly the two tests it adds, so nothing else moved.

I also ran the new pin in both directions on that same tree: it passes where the rule stands, and it reddens when I delete the rule from emrg/server/open_source_prompt.md, with the failure naming the missing phrase rather than reporting a shape. The rule sits in §3.1.5, the section that already owns what an edit must satisfy; the same sentence in §3.1.6 would be read as a testing rule instead of an edit rule.

Stated limit: the whole-suite landing gate could not run here — scripts/check-merge-plan-suite.py cannot refresh origin/master because the https proxy is unreachable. CI's own two legs concluded green on the head.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261110-193523

Reviewed on the tree this merge would land, not on the head's own CI: the head is two commits behind master, so its green run judged a base that can no longer be merged, and refreshing it would void the vote already standing. check-merge-plan-suite.py 2793 planned it onto master b791b085, and that tree passes the suite — 6205 passed, 37 skipped, final tree c2beeee9d60c. I then built that exact tree in a worktree and confirmed its tree sha is c2beeee9d60c, so the arms below ran on the tree the suite measured rather than on a checkout near it.

The pin earns its place in four directions, each run on that tree by node id:

Arm	Result
As submitted	2 passed
The rule deleted from the template	2 failed
The rule's prose reworded, its pinned phrase kept	2 passed
The rule moved under ##### 3.1.6 Test	1 failed, and the message names the section it found instead

The third arm is the one that decides a template guard: a pin that reddens on a legitimate rewrite of the surrounding prose is pinning the prose, and this one does not. The fourth shows the position reading has a subject rather than merely checking presence.

The rule appears exactly once in the template, under the section that already owns what an edit must satisfy, and the template's heading list is identical to b791b085: no section was added, moved or removed.