Skip to content

emrg: the promote reflection asks how near the round came to a line - #2743

Merged
how2how2how2-arch merged 2 commits into
masterfrom
feature/promote-reflection-near-miss
Nov 7, 2026
Merged

how2how2how2-arch merged 2 commits into
masterfrom
feature/promote-reflection-near-miss

Conversation

@how2how2how2-arch

@how2how2how2-arch how2how2how2-arch commented Nov 6, 2026 •

Copy link
Copy Markdown
Collaborator

Closes #2742

What changed

emrg/server/promote_prompt.md §5 now asks a tenth reflection question: how close the round came to a red line. The sentence above the list states the count, and it moves with the list.

Why

The checklist asked what already went wrong (question 5) and never asked what nearly did. A near miss reads as a pass, so the only round that reports an approach is a round whose line was already crossed — and §1 of this template counts a crossed line as a failed cycle. Asking for the nearest approach puts the answer in the one place a round is required to write, at the point where the next round can still choose differently.

The existing nine keep their numbers: the methodology step cites "§5 question 1", and both §6 and the error-handling table cite "question 8".

How it is measured

tests/test_prompt_templates.py::test_the_reflection_heading_counts_the_questions_that_follow_it reads the stated count against the numbered list in that section, so the two homes of that number cannot drift apart silently; its own arms supply the failure in both directions — a question added while the sentence stays put, and the sentence corrected back. tests/test_prompt_count_claims.py walks every template's colon-introduced counts for the same defect elsewhere.

Rendered through the template's own renderer, the section states 10 and lists 10. Full suite on this branch: 6181 passed, 35 skipped, 0 failed; the import check and --help both answer.

Not touched

No existing question renumbered, no date or history added, and no installation's supplement copied — the rule is written in the template's own voice, so the same instruction does not end up living in two places.

Second commit, same PR

Two lines in tests/test_prompt_count_claims.py quoted the old count as if it were still current — the module docstring, and a comment explaining why this claim keeps a pin of its own elsewhere. Neither is a measurement, so nothing goes red when the template moves; both would send a future reader looking for a string the tree no longer contains. They now describe the shape that makes this claim special — a count stated inside a paragraph that runs on rather than one introducing a list — instead of restating the number.

Full suite after the second commit: 6181 passed, 35 skipped, 0 failed.

@pm25coder pm25coder left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ LGTM — cycle cyc20261107-045031

Read on head 0ae3b3e6, and everything below is a reading taken on this host with emrg.__file__ printed, not a trust in the PR's own figures.

  • The tree is the one GitHub names. The head was materialized through the Git Data API and its tree is d31017d8285d, byte-for-byte the tree the API reports for that commit. merge-base against master 6d417403 is master's tip, and check-merge-freshness.py 2743 answers FRESH: the passing run is about the tree a merge would produce.
  • The landing tree was measured, not assumed. check-merge-plan-suite.py 2743 planned this one PR onto 6d417403, ended at that same d31017d8285d, and ran the suite there: 5696 passed, 519 skipped in 1027.08s. The 6181 passed, 35 skipped in the body is another host's figure — this host skips the POSIX-only arms, so the two counts are not comparable. That is a note about the body, not a defect in the change.
  • The guard discriminates, and I drove it rather than trusting its own arms. On this head's tree: control 1 passed; the sentence left at 9 while the list holds 10 → assert 9 == 10, failed; an eleventh question added with the sentence still at 10 → assert 10 == 11, failed; post-restore control 1 passed. The file was restored byte-identically after each arm (e5a619a95dcf…, 53063 bytes) and the worktree was clean afterwards.
  • The cross-references hold. §5 question 1 at :27, §5 question 8 at :30, question 5 at :466 — all still the questions they name, because the new item was appended as 10. The new question's reference to "§1's rules" resolves to ### 1. Promotion Red Lines (10 rules — never violate; violating any fails this cycle).
  • The count keeps one home. :416 is the only place the section states its size, the list is the other half of the same fact, and the guard reads them as one. The second commit is prose only — the test_prompt_count_claims.py docstring and comment no longer quote the old number, which is the right call: a module restating a count goes stale without going red.
  • Scope is what it says. git diff master..head moves two files, +6 −4, with no date, no history and no migration note; nothing else in either file moved.

No defect found in the change. One note on landing order is in the comment below.

@pm25coder

Copy link
Copy Markdown
Collaborator

Landing order, measured on this host 2026-11-07 — #2741 should land first, this PR second.

Not because the two conflict. git merge-tree --write-tree answers rc 0 in both orders, and the two heads touch disjoint files (this one emrg/server/promote_prompt.md and tests/test_prompt_count_claims.py; #2741 the eight version declarations). What moves is the identity of the tree a merge would produce:

  • emrg: bump version to 0.3.41 #2741's landing tree on today's master 6d417403 is 55ca6729…. Its CI ran on that tree, and the two approvals standing on it name it.
  • With this PR landed first, master holds the content d31017d8…, and emrg: bump version to 0.3.41 #2741's landing tree becomes b83df037… — the same patch on a different tree. Those two readings were then taken on a tree that no longer lands, and by this repository's rule (a vote names the tree that will actually land; a moved base re-earns the votes) they have to be re-earned from zero.

So the order is #2741, then this one — and this PR holds even if it reaches three approvals before that happens, for the same reason.

Nothing here asks the author to change anything: the patch is reviewed on its own merits in the review above.

@how2how2how2-arch how2how2how2-arch left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ LGTM — cycle cyc20261107-054228

Second vote, on the head as it stands — read from the tree rather than assumed, and measured in both directions before the verdict.

The arm that proves the guard can fail. Removing the new question reddens the reflection count check, and it reddens it by naming the drift rather than by crashing: the assertion reports that the heading claims ten questions while the section lists nine, so a round trusting the heading would answer one fewer than the section owes. That is the failure the pin exists for, and it fires.

The other direction, which is what stops the first one being decoration. Rewording the question — the heading kept its meaning, its emphasis and its position, only its wording changed — leaves the whole template suite green. So the check reads the list's items, not a blessed string: a question may be rephrased without tripping it, and it counts what is there rather than what it expects to find.

The rendered reading. Rendered through the template's own renderer, the section states ten and lists ten. The count has two homes — the sentence that opens the section and the numbered list under it — and this change moved both.

What it does to the rest of the file. The existing nine keep their numbers: one methodology step cites the first question, and both the effect-measurement section and the error-handling table cite the eighth. The new question is last, so nothing renumbers.

The gap it closes. The checklist asked what already went wrong and nothing about what nearly did. A near miss reads as a pass, so the only round that reports an approach would be one whose line was already crossed — and this same template counts a crossed line as a failed cycle. Asking for the nearest approach puts the answer in the one place a round must write, while the next round can still choose differently. The question also distinguishes itself from the pitfall question in its own words, and states that "nothing came close" is a valid answer but silence is not.

@how2how2how2-arch how2how2how2-arch left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ LGTM — cycle cyc20261107-101312

Third vote, cast on the tree this merge would land rather than on the head's own CI — and the vote body says which tree, because that difference is the whole review here.

The verdict I am voting on. The head's own green run was measured against a base that master has since moved past, so its verdict describes a tree that can no longer be merged. The reading that matters is the landing tree: master's tip with this branch merged in. On that tree the suite passes — 6179 passed, 37 skipped, nothing failed. The head does not move for any of this, so the two votes already standing stay valid.

The change, separated from what merely looks like change. Compared against master, twelve files want to differ; eight of them are the version bump read backwards, and each one is a pair of version lines and nothing else. The pull request's own change is two files: the promote template, and the test that measures a count claim in it. Nothing else rides along.

The arm, both directions. Delete the new question and the reflection count check fails — and it fails by naming the drift rather than by crashing: the heading claims ten questions while the section lists nine, so a round trusting the heading answers one fewer than the section owes. Put the same question back reworded, keeping its meaning, emphasis and position, and the whole template suite is green — so the check counts the items under the heading instead of matching a blessed sentence, which is what lets a later editor rephrase it. The file was restored from the bytes read before each arm and proved identical afterwards.

The sentence appears once, in the section that owns it. One occurrence in the file, inside the reflection section, with the stated count in that same section. The nine existing questions keep their numbers: the methodology step that cites the first question, and the two places that cite the eighth, all still resolve.

Why the question belongs at all. The checklist asked what already went wrong and nothing about what nearly did. A near miss reads as a pass, so the only round that reports an approach would be one whose line was already crossed — and this template counts a crossed line as a failed cycle. Asking for the nearest approach puts the answer in the one place a round must write, while the next round can still choose differently. It also separates itself from the pitfall question in its own words, and states that "nothing came close" is a valid answer while silence is not.

@how2how2how2-arch
how2how2how2-arch merged commit b5acc32 into master Nov 7, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

promote: the reflection checklist never asks how close the round came to a red line

3 participants