emrg: the promotion template never says a post is written in the round, or that a room's exemplars are read first #2677

What the template states now

emrg/server/promote_prompt.md §1 announces its own completeness — :97 reads "Promotion Red Lines (8 rules — never violate; violating any fails this cycle)" — and then lists eight items, :99–:110. §2 settles the form each channel asks for in advance (:133, "The form comes from the channel, not from the subject") and sends a round to the room's own rules before it acts (:152, "Read the target's own rules before the first action there"). §2.y orders blog work as persona → research → experiment → write (:204) and keeps a blog drafts queue that holds subjects rather than texts (:383).

What it does not say, anywhere in the file

1. Nothing forbids publishing a text that was written earlier. The statements nearby are about which channel a subject fits and in what order the material is assembled; both are silent on whether the words themselves were produced in the round that posts them. The one sentence that can be read as licensing the other thing is §2.y's cadence clause, :218: "Publish within 1-3 days whenever a draft is ready."
2. Nothing sends a round to the accounts the room already rewards before its first post there. :120 says "Lurk first to learn the rules" and :152 says "Read the target's own rules before the first action there" — both are about a community's stated rules, not about the posts it visibly rewarded. So the one observation that tells a round what a room in fact accepts, as distinct from what it declares, is not part of the procedure.

What a round therefore does wrong

A round that carries a finished text across rounds posts an answer to a question the thread had already moved past, and nothing it reads tells it not to — the material was gathered honestly, which is exactly why the text looks ready. A round posting in a channel for the first time writes from §2's table of forms alone: it has read that room's rules and none of the posts that room rewarded, so it knows what the table says a form is and not what the room accepts.

What the fix must satisfy

• Two rules, stated in §1 — where a round reads what it may never do, and where the announced count is derived from the list it heads.
• The heading's number follows the list in both directions: too high reddens, too low reddens, and an item added or removed without the number moving reddens.
• No numbers in either item. Which readings clear a gate, and how many of them are enough, belong to the installation that runs this task; §1's existing item 8 already says so, and a template that states a threshold has taken on a value it cannot maintain. The same applies to a count of exemplars, posts or reads.
• Each item states a property rather than a spelling: an item reworded with its meaning kept must not redden any guard. A guard that pins the sentence instead of the count is the defect this repository has spent five heads removing.
• The file must not be left holding two answers. :218's "whenever a draft is ready" is decided with the rest: the queue carries subjects, so the cadence clause names a topic and a finished text is no longer one of the things it can be read as licensing.

Why this is one issue and not two

Both are one class: a method this task's rounds are run by, which the versioned template omits while installations supply it as their own configuration. An installation that never writes that configuration runs without the method, so the gap is in the template rather than in any one host's setting.

Named limit. The count cannot say which rules the list holds, so deleting an item and lowering the heading together stays green. That hole is a reviewer's obligation, not a test's, and no matcher should be built to close it — a matcher over the sentences is the literal pin, one level up.