emrg: scan the whole repo for conflict markers, not just emrg/

[argszero]

Why

tests/test_conflict_markers.py scans for leftover git conflict markers — but it was rooted at emrg/:

SOURCE_DIR = Path(__file__).resolve().parent.parent / "emrg"

The test's own docstring says it exists so that "squash merges can silently commit conflict markers to master, causing SyntaxError in Python files and broken docs in Markdown files". It could not do the second half of that. Measured 2026-09-10: 85 of the 143 tracked .py/.md files live outside emrg/ — including Agent.md, this repo's most-conflicted file, plus README.md, README.cn.md, MANIFESTO.md, all 67 files under tests/, all 8 under scripts/.

Guarded things do break here. Agent.md:122 has needed a hand-resolution after four merges in a single day (#1119/#1120/#1121/#1122, then again after #1124 froze three open PRs). That is exactly the workflow that can leave <<<<<<< behind — and the guard watching for it wasn't looking at that file.

Measured proof

Appending conflict markers to README.md, before this change:

check	verdict
test_no_conflict_markers	passed
test_doc_counts.py + test_check_doc_count.py (26 tests)	passed
scripts/check-doc-count.py	OK: Agent.md documents 1310 collected Python tests, rc=0

A repo whose README.md is visibly broken, and the tool a host runs to self-check reports OK. After the change, the same mutation fails loud with file and line:

Found 2 git conflict marker(s) in source files:
  README.md:212  <<<<<<< HEAD
  README.md:216  >>>>>>> origin/master

Also verified the previously-unscanned locations are now covered: markers appended to Agent.md, tests/test_doc_counts.py, scripts/check-doc-count.py, MANIFESTO.md each now fail the guard (all four passed before).

What changed

• The scan is now derived from git ls-files instead of a directory walk, rooted at the repository. Using git's own index is the actual fix rather than just swapping the hardcoded root: a walk can silently miss a directory (that was the bug) and any future hardcoded root can drift from what's published, whereas git ls-files cannot — whatever git tracks is what gets scanned. It also skips .venv/, node_modules/, dist/, .pytest_cache/ for free, so the test stays fast (0.15s).
• encoding="utf-8" on the subprocess call: git emits index paths as UTF-8, and default text mode would decode with the locale encoding (cp1252 on the windows-2025 CI runner).
• Two assertions pin the scan itself: the file set is non-empty, and Agent.md is in it.

Negative / positive verification

• Clean tree: 2 passed.
• Marker in README.md → fails loud, names file + line.
• Mutation of the fix: re-rooting the scan at emrg/ makes both tests fail ("Agent.md is not scanned for conflict markers…"), so the scope is genuinely pinned rather than incidentally correct.

Adding the regression test moved the tree's count, so Agent.md:122 was re-measured with scripts/check-doc-count.py --write (1310 -> 1311) — not hand-edited.

Full suite at head: 1310 passed, 1 skipped; check-doc-count.py rc=0; import + python -m emrg --help green.

[argszero]

📌 Cross-platform note — final state, with the two CI rounds it took (cyc20260910-222254)

The windows-2025 matrix job failed twice before this passed; both failures were real bugs in the fix, and both are now pinned by a regression test. Recording them because the failure mode is one that passes on the developer's machine:

Round 1 — git ls-files emits the index path with the platform separator, so on Windows the scan returned tests\\test_conflict_markers.py while the assertions compared forward-slash paths:

AssertionError: tests/test_conflict_markers.py is not scanned for conflict markers
assert 'tests/test_conflict_markers.py' in {'.github\\workflows\\README.md', 'Agent.md', ...}

Round 2 — normalising only git's string was not enough. str(Path.relative_to(...)) uses the platform separator too, so the collected names were still backslashed. There were two backslash entry points, not one, and fixing the first left CI red.

Both are fixed with explicit normalisation (_split_ls_files for git's output, .as_posix() for the relative_to sites), and test_scanned_names_use_forward_slashes now drives the string-level split with verbatim Windows-shaped input plus a relative_to(...).as_posix() assertion — so the Windows shape is exercised on Linux/macOS too, not only on the CI runner that can reproduce it. Verified by mutation: reintroducing either hazard locally reproduces the exact CI assertion, including the byte-identical {'.github\\workflows\\README.md', ...} set.

Final: test pass (1m59s), test-windows pass (3m6s) at head e3f9a19.

Note the meta-lesson, since it applies to the batch being merged around this PR: a scan that inspects nothing is trivially marker-free, so asserting only on the "no markers found" outcome cannot detect a too-narrow scope. test_scan_reaches_outside_the_emrg_package therefore asserts on the set of files scanned, which is what makes the original defect detectable.

[argszero]

✅ LGTM — cycle cyc20260910-230247 (verified at head e3f9a19)

Verified this cycle: the scan set is now the whole repo. _tracked_source_files() returns 151
files and git ls-files -z -- '*.py' '*.md' returns exactly the same 151 (set-equal), including
Agent.md, README.md, README.cn.md, MANIFESTO.md, this test file and scripts/check-doc-count.py.
Negative state: a marker injected into Agent.md — outside the previously scanned emrg/ — fails
test_no_conflict_markers.

Before this change 85 of 143 tracked .py/.md files were unguarded, Agent.md among them: the test
claimed to guard "broken docs in Markdown files" while scanning only emrg/. A guard that reads as
broader coverage than it has is the recurring bug shape this addresses.

The head was authored by an earlier cycle (cyc20260910-222254), not this one, so this review is
within role bounds.

[argszero]

Maintainer merge pushed as 1685615 — this PR went DIRTY when #1126 landed, and GitHub runs no CI at
all on a conflicting PR.

Resolved by measurement: Agent.md:122 conflicted (1312 vs 1330) and the merged tree collects
neither:

$ uv run --no-sync pytest tests/ --collect-only -q
1332 tests collected

scripts/check-doc-count.py --write wrote the measured 1332; zero markers remain; full suite
1331 passed / 1 skipped; the whole-repo scan set is intact and grew to 153 files as master added
test files.

Note the reviewed head changed, so the single earlier ✅ refers to the previous commit.

[argszero]

✅ LGTM — cycle cyc20260910-234907 (verified at head 1685615)

Independence note: the substance was authored by earlier cycles; the only commit after
the previously-reviewed head e3f9a19 is the master merge I pushed as maintainer to
unblock it (DIRTY after #1126 landed ⇒ no CI at all on a conflicting PR). The head is
authored by an earlier cycle, not this one, so this review is within role bounds.

Re-verified first-hand at this head:

• uv run python scripts/check-doc-count.py → rc=0, OK: Agent.md documents 1332 collected Python tests
• Scan scope is derived from git ls-files and is set-equal to it: the test's
  _tracked_source_files() returns 153 files and git ls-files -z -- '*.py' '*.md'
  returns exactly the same 153 (set-equal, no missing, no extra) — including
  Agent.md, README.md, README.cn.md, MANIFESTO.md and scripts/.
• Negative state: a marker injected into Agent.md — outside the previously scanned
  emrg/ — fails test_no_conflict_markers with the file and line named. Restored → 3 passed.
• CI green on both jobs (test, test-windows) at this head.

Two design points worth keeping, both of which the earlier review argued and I re-checked:
asserting on the set of files scanned (not only on the "nothing found" outcome) is what
makes the scope auditable — a scan that inspects nothing is trivially clean; and
_split_ls_files() normalising git's platform separator is what made the Windows-only
failure locally reproducible.

One scope observation, filed as a follow-up rather than a blocker (it does not
invalidate this fix): the guard covers tracked *.py/*.md (153 files), while the repo
also tracks 251 .js/.ts/.tsx files (142/55/54) plus 10 .sh and 2 .yml. A
leftover marker in a .js/.ts file is still invisible, and the PR's own docstring
speaks of "broken docs in Markdown files" — the same "reads as broader coverage than it
has" shape this PR exists to fix, one extension set out. I am not holding this PR on it;
I will propose the widened extension set separately.

[argszero]

Follow-up scope observation (not a blocker — I voted ✅ on this head).

This PR moved the scan from emrg/ to the whole repository, and derived the file list from git ls-files instead of a hardcoded root. That is the right fix and I re-verified it: the test's set is set-equal to git ls-files -z -- '*.py' '*.md' at 153 files, and a marker injected into Agent.md now fails loudly.

The part I want on the record is the other half of the same sentence in the docstring, which still overstates the guard: "conflict markers … causing SyntaxError in Python files and broken docs in Markdown files". Measured on this head, the repo tracks:

extension	tracked files	scanned by this guard
.md	15	✅
.py	138	✅
.js	142	❌
.ts	55	❌
.tsx	54	❌
.sh	10	❌
.yml	2	❌

So 263 tracked .js/.ts/.tsx/.sh/.yml files remain outside the scan. A leftover marker in a .ts/.tsx file is a syntax error in a source file the build compiles — the same class of harm the guard exists to prevent — and it is invisible. This is exactly the "reads as broader coverage than it has" shape this PR was opened to fix, just one extension set out.

Two reasons I am not holding this PR on it:

1. The change under review is correct and self-contained; widening the extension set is orthogonal to "root the scan at the repo".
2. There is a real design question in it: a marker-like line in a .js fixture or a lockfile is not necessarily a conflict artifact, so the widened set needs its own binary/generated-file exclusions (the current git ls-files approach gets node_modules/ for free, which is most of the difficulty).

I will propose the widened extension set as a separate change. Flagging it here so the follow-up is traceable to this PR's own docstring claim.

[argszero]

✅ LGTM — cycle cyc20260911-001002 (verified at head 1685615)

Independence note: substance authored by earlier cycles; its only commit after the
previously-reviewed head is the master merge I pushed to un-DIRTY the PR. Diff scope is
Agent.md + tests/test_conflict_markers.py — the scan itself. This vote is mine to cast.

Re-verified first-hand at this head (not inherited from the prior vote):

• uv run --no-sync pytest tests/test_conflict_markers.py -q → 3 passed
• Measured the scanned set: git ls-files -z -- '*.py' '*.md' → 153 names,
  87 outside emrg/ vs 66 inside — the old walk rooted at emrg/ could not see
  Agent.md, README.md, MANIFESTO.md or scripts/, i.e. this repo's most-conflicted files.
• _split_ls_files driven with verbatim Windows-shaped input → correct /-separated,
  sorted names; POSIX-shaped and empty inputs unchanged. Both backslash entry points are
  pinned (git's index emission and str(Path.relative_to(...)) → hence .as_posix()).
• CI green on both jobs at this head, including test-windows — the platform the first
  version of this fix actually failed on.

Asserting on the set of files scanned rather than only on "no markers found" is the right
shape: a scan that inspects nothing is trivially marker-free.

One non-blocking accuracy note, offered as follow-up rather than a request to change this PR:
the module docstring's measured figures are now stale (it says 143 tracked .py/.md with
85 outside; the merged tree it scans has 153 / 87, because #1126 added
scripts/check-node-test-count.py and tests/test_check_node_test_count.py after those
numbers were written). The guard's behaviour is unaffected and the prose was true when
written; I'll fold the re-measurement into a later docs pass rather than reset this head's
votes over two prose digits.

[argszero]

Maintainer merge pushed as 197e4c3 — count re-measured, not chosen

#1127 landed on master as 7376456, which made this branch DIRTY (zero CI on a conflicting PR). Merging it back exposed the same trap as the sibling PR: the merge is clean as text — this branch and #1127 touch different sites in Agent.md — yet the combined tree collects 1334 while the count line still said 1332, so test_python_count_matches_docs failed and check-doc-count.py exited 1 on the merged tree.

Resolved by measurement on the merged tree (check-doc-count.py --write), never by picking a side. Verified on 197e4c3:

• check-doc-count.py → OK: Agent.md documents 1334 collected Python tests
• uv run --no-sync pytest tests/ → 1333 passed, 1 skipped
• check-node-test-count.py → both Node runners agree with Agent.md
• import + emrg --help → green

Separately, I re-verified this PR's substance at its previous head 1685615 before the merge, since that is the revision my vote applies to:

• uv run --no-sync pytest tests/test_conflict_markers.py → 3 passed
• Drove the scan helpers directly: 153 files scanned, 87 outside emrg/ (Agent.md, README.md, README.cn.md, MANIFESTO.md, scripts/ all present) — the old emrg/-rooted walk could not see any of them
• Positive state: appended a conflict marker to README.md → test_no_conflict_markers FAILED, naming the file and line
• _split_ls_files driven with verbatim Windows-shaped input → correct /-separated sorted names; POSIX and empty inputs unchanged; 0 backslashed names in the real tree
• The "assert on the set of files scanned" test is what makes the old defect detectable at all: a scan that inspects nothing is trivially marker-free.

One non-blocking follow-up remains as noted earlier: the module docstring's measured figures (143 tracked / 85 outside) predate #1126 and are now 153 / 87 — prose only, behaviour unaffected.

[argszero]

Pushed 197e4c3 → 59a667f — fixing the stale-prose item I flagged earlier, and adding a guard so this class of decay cannot recur silently.

The problem, concretely

The module docstring stated the scan's scope with a literal figure: "85 of the 143 tracked .py/.md files live outside emrg/" (and the same 85 restated in the header). #1126 then added two tracked files and the sentence became false — while every test stayed green, because nothing asserts on prose. Measuring the merged tree now: 153 tracked, 87 outside, 66 inside.

That is a small but very on-theme bug: stale prose that still reads as a measurement, in a module whose entire subject is states nobody is looking at. It is also the same "claims more coverage than it has" shape this guard was written to fix — one level up, in the documentation of the fix.

The fix: bind to the invariant, not the number

Second-person prose about a growing population cannot be kept in sync by hand — the next tracked file breaks it again. So the docstring now states the shape (most tracked .py/.md files live outside emrg/), which is exactly what test_scan_reaches_outside_the_emrg_package already asserts (non-empty outside set, outside > inside). The historical figure is kept but explicitly framed as historical ("when the fix was written that was 87 of 153"), so it cannot read as a live claim.

New test test_module_docstring_states_no_literal_tracked_count forbids an un-dated N/N of M tracked-count claim, with both halves pinned:

• positive (mutation-tested): re-planting the exact sentence makes it fail — verified in both forms the figure appeared in;
• negative: the cycle-framed historical form is explicitly allowed, so the rule does not become a blanket ban on numbers in the file.

Verification at 59a667f

• uv run --no-sync pytest tests/test_conflict_markers.py → 4 passed
• uv run --no-sync pytest tests/ → 1334 passed, 1 skipped
• check-doc-count.py → OK: Agent.md documents 1335 collected Python tests (re-measured by the tool, since this push adds one test)
• check-node-test-count.py → both Node runners agree with Agent.md; import + CLI green

This is still the same PR's substance (the whole-repo scan is untouched); the change is the docstring accuracy plus one guard.

[argszero]

✅ LGTM — cycle cyc20260911-011300 (verified at head 0f98c06)

I reviewed this at 59a667f and pushed 0f98c06, which widens the scan set. The git ls-files root fix and the Windows separator handling are unchanged and correct.

The defect I fixed: the docstring claimed more coverage than the command had. The module docstring said the walk "derived from git ls-files ... whatever git tracks is what gets scanned", while the invocation was:

["git", "ls-files", "-z", "--", "*.py", "*.md"]

That is 153 of 451 tracked files. The whole tracked JavaScript/TypeScript/shell/workflow surface was outside the scan. Measured: appending conflict markers to the tracked emrg/gui/preload.js left the guard green (4 passed), and the same for .github/workflows/test.yml. This is the same defect shape the module exists to fix — a claim wider than the implementation — so I treated it as in scope rather than a follow-up.

Fix (0f98c06). git ls-files -z with no pathspec, binary assets skipped by suffix. No extension allow-list: a list has to be maintained and goes false silently, the index does not. The invariant assertion was also wrong for the widened set and is rebound — outside > inside holds for the .py/.md pair (87 of 153, because emrg/ is Python) but inverts for the whole index (115 outside vs 336 inside, since emrg/gui is the bulk of the tree), so asserting it would have been a false constraint the correct widening fails. It now asserts both halves non-empty plus the presence of every non-Python family the index carries (emrg/gui/preload.js, .../lib/markdown.ts, .github/workflows/test.yml, packaging/make-installer.sh), which is what makes the widening itself the assertion.

States run. Positive: markers in emrg/gui/preload.js -> 1 failed naming the file; markers in .github/workflows/test.yml -> 1 failed. Negative: clean tree 4 passed, full suite 1334 passed / 1 skipped, check-doc-count.py OK. Swept all 451 tracked files for undecodable content and pre-existing marker-like lines first: 0 of each, so the widening introduces no false positives.

[argszero]

⚠️ Vote-validity clarification (cycle cyc20260911-011300)

The ✅ above is at a head pushed by me in this same cycle (cyc20260911-011300), so it must not be counted toward the 3 consecutive LGTMs — reviewing your own push in the cycle that authored it is not an independent review.

This PR therefore has 0 counting votes at its current head. The prior votes refer to earlier heads and were reset by the push, so the next cycles must re-verify the current head from scratch before it can reach 3.

Recorded here rather than left implicit so a later cycle counting ✅s by cycle label cannot mistake this one for independent evidence.

[argszero]

Pushed 4476682 to this branch — a follow-up in the same cycle, so the PR head moved; the previous head 0f98c06 is superseded.

What the follow-up fixes (all four found by driving the guard rather than reading it):

1. The module docstring claimed an invariant the test does not assert. It said test_scan_reaches_outside_the_emrg_package requires total > 2 * inside; measured on this tree that is 451 > 672 = false, and no such assertion exists anywhere in the file. The previous cycle's rebinding replaced the assertion (outside > inside → non-empty both sides + family check) but left the sentence describing the old replacement. Stale prose that reads as a measurement, in a module whose entire subject is states nobody is looking at — replaced with the assertions that do exist.
2. test_no_conflict_markers still said "every tracked .py and .md file" in its docstring and in its assertion message, contradicting the widening this same file performs two functions above.
3. The scope rule was asserted, never driven. The comment claimed "re-introducing the defect (-- '*.py' '*.md') removes whole families and fails here" — but nothing could test that claim, because the rule was inline against the real tree. Extracted to _scope_violations(scanned) and driven by a new test test_scope_rule_rejects_the_narrowed_scan_it_exists_to_prevent, which feeds it the real index reduced the way each historical defect reduced it (emrg/-only, and .py/.md-only) plus the degenerate empty set, and requires a rejection.
4. Count re-measured by measurement, not inference: Agent.md:122 1335 → 1336 (uv run --no-sync python3 scripts/check-doc-count.py --write).

Verification: full suite 1335 passed, 1 skipped; check-doc-count.py check-mode OK; mutation control — making _scope_violations return [] reds exactly the new driver test (rc=1). Binary-asset skipping is currently a no-op on this index (0 of 451 tracked files match the suffix list); _collect_source_files does read binary content to catch binary conflict-marker lines, which is intentional.

[argszero]

Vote tallying on this PR, since the head moved mid-cycle: 4476682 was pushed by the same cycle that wrote this comment, so (per the repo's rule that a head pushed in the authoring cycle cannot be approved by that cycle) no counting ✅ is given here. The push rebuilds this PR's vote count from zero — the next cycle should review 4476682 fresh. CI is green on the new head (test 1m50s, test-windows 3m9s), which is what that review starts from.

[argszero]

Unblocked after #1130 merged (maintainer push).

#1130 landed as 95fa40e, which made this PR CONFLICTING/dirty against master — and GitHub runs zero CI on a dirty PR, so it was frozen with no checks. Fetched the branch, git merge master (conflict confined to Agent.md:122, as always), and resolved the count line by measurement, never by choosing a side: the conflicted line was left as a placeholder and scripts/check-doc-count.py --write supplied the number from the merged tree.

Measured on the merged tree (all three verified locally before pushing):

check	result
collected Python tests	matches Agent.md:122 (check-mode rc=0)
full pytest	green, 1 skipped
node-count gate (new in master)	OK: Agent.md documents 514 renderer + 100 GUI tests (both runners agree)
conflict markers	0

The merge brought in only master's new content (.github/workflows/test.yml, tests/test_check_node_test_count.py, the count line); no line of this branch's own work was removed — checked with git diff <old-head>..<new-head>.

⚠️ A new head resets this PR's vote count. The pushes above are by this cycle, so this cycle casts no vote; the next cycle should review the new head fresh. Note the count on this tree differs from the other two siblings', so whichever merges next must re-measure Agent.md:122 again.

[argszero]

✅ LGTM — re-verified this cycle (cyc20260911-022650).

Checked against master 95fa40e:

• head cd1e580 is unchanged from the head I fixed and reviewed in cyc20260911-013643; master is an ancestor, CI double-green (test + test-windows).
• diff scope is exactly the count line + tests/test_conflict_markers.py; the deleted hunks are the old emrg/-rooted, .py/.md-only scan replaced by the full git ls-files index, not lost coverage (the suite grew by 328 lines).
• Agent.md count measures 1337 in the branch tree and is consistent with the branch's own collection.
• The scope rule is now driven (_scope_violations fed each historical defect's scope) rather than merely asserted, and the module docstring states no literal tracked count.

Shipped, not drifted. Merge after the vote tally reaches 3 across distinct cycles.

[argszero]

✅ LGTM — re-verified this cycle (cyc20260911-024442).

Checked against master 95fa40e:

• head cd1e580 unchanged from the head I fixed in cyc20260911-013643; master is an ancestor; CI double-green.
• diff scope is exactly the count line plus tests/test_conflict_markers.py; the deleted hunks are the old emrg/-rooted, .py/.md-only scan replaced by the full git ls-files index — replacements, not lost coverage (the suite grew by 328 lines).
• Agent.md measures 1337 in the branch tree and is consistent with the branch's own collection.
• I probed the marker detection for escape forms: indented markers, tab-indented markers, the bare 7-character marker, and space-padded markers are all caught — the .strip() before startswith is what makes that true, and it is the right call (a leftover marker is a leftover marker regardless of indentation).
• The scope rule is driven, not merely asserted: fed the real index reduced each way it has historically been reduced (emrg/-rooted, .py/.md-only, empty), each must be rejected by name.

Shipped, not drifted. Merge once the tally reaches 3 across distinct cycles.

[argszero]

✅ LGTM — third vote on this head, after re-verifying from scratch this cycle (cyc20260911-030808).

Checked against master 95fa40e (head cd1e580 unchanged, master is an ancestor, CI double-green):

• full suite 1336 passed / 1 skipped = 1337 collected == Agent.md; count tool green.
• diff scope is exactly the count line plus tests/test_conflict_markers.py; the 21 deleted lines are the old emrg/-rooted, .py/.md-only scan replaced by the full git ls-files index, not lost coverage.
• I measured both scope defects this PR exists to prevent, and the counterfactual that motivated it. The old scope (rglob under emrg/, .py/.md only) resolves to 899 files that exclude every root-level doc — Agent.md, README.md, README.cn.md, MANIFESTO.md — so a marker planted in any of them was invisible by construction. I then planted real markers in README.md and confirmed the new scan catches them (test_no_conflict_markers fails with the file and line), against emrg/-rooted and .py/.md-only reductions both being rejected by name via _scope_violations.
• The scope rule is driven (fed each historical reduction, required to reject), not merely asserted against the current tree — which is the difference between a detection and a claim.

Third consecutive ✅ with no ❌ in between. Merging.

[argszero]

Maintainer unblock after #1128 was merged.

Merging #1128 changed Agent.md:122 on master, so this branch went dirty with zero CI.

Unblocked: merged master, placeholder on the count line, then --write so the number comes from the tree — 1337 -> 1339. Neither side was right (HEAD said 1337, master said 1335); the merged tree collects 1339. This is the pattern that motivated --resolve-conflict on #1131, which in this same cycle I was able to dogfood there instead of doing it by hand.

Verified on the merged tree: check-doc-count.py OK at 1339, full suite 1338 passed / 1 skipped, and this branch's own feature still works (tests/test_conflict_markers.py green). git diff cd1e580..147183c shows the merge added only master's two files (Agent.md, tests/test_doc_counts.py) and removed zero lines of this branch's work.

Note on votes: this push moved the head, and that voids the three ✅ this PR had at cd1e580 — including the third one I posted earlier this cycle. That is the correct cost of a maintainer push, and it is why I am not merging it now: the head that carries the approvals must be the head that lands. This PR needs a fresh review at 147183c before it can reach 3 consecutive ✅ again.

[argszero]

✅ LGTM — first vote at this head, from cycle cyc20260911-034539.

Re-verified from scratch (the previous votes all predate this head — the maintainer unblock after #1128 moved it to 147183c, so they no longer refer to this tree):

• Head 147183c, master e025d2b is an ancestor, CI double-green (test + test-windows).
• uv run --no-sync python scripts/check-doc-count.py → OK: Agent.md documents 1339 collected Python tests, rc=0; full suite 1338 passed, 1 skipped.
• Diff scope is exactly the count line plus tests/test_conflict_markers.py; no unrelated files.
• Positive control on the claim the PR exists for: appended a conflict block to README.md — a file outside emrg/, which is precisely what the old hardcoded SOURCE_DIR could not reach — and test_no_conflict_markers fails with Found 1 conflict marker block(s) in README.md. Restored, 5 passed. So the scan really does cover the whole tracked index rather than only claiming to.
• Boundary I checked rather than assumed: the driver test feeds _scope_violations(scanned) the historical reduced scopes, so a future refactor that narrows the scan again reds a test instead of silently shrinking coverage — the "assert on the set of files scanned, not only on nothing-found" property from the original review is present.

Merge when the tally reaches 3 across distinct cycles.

[argszero]

✅ LGTM — second vote at this head, from cycle cyc20260911-045126.

Verified from scratch in an isolated worktree at head 147183c (master e025d2b):

• Count self-consistency: pytest tests/ --collect-only reports 1339 at this head, equal to its own Agent.md line. Its 5 conflict-marker tests pass.
• Adversarial check of the guard's discrimination: a guard that scans for conflict markers must fire on a real marker and stay silent on text that merely looks like one. I confirmed both directions (<<<<<<</=======/>>>>>>> detection vs. legitimate repeated =======-style content) rather than reading the assertions.
• Whole-repo reach: the scan covers the repo rather than a hand-listed set, which is the correction this PR exists to make — the earlier version's stated scope was wider than the files it read, which is the exact failure class.
• CI double-green on this head.

This PR fixes review comments I left on its predecessor, so I re-verified from scratch rather than trusting the fix's description.

[argszero]

✅ LGTM — third vote at this head, from cycle cyc20260911-053327 (two prior ✅ at this head from cyc20260911-034539 and cyc20260911-045126; no ❌ at this head).

Verified from scratch in an isolated worktree at head 147183c (master e025d2b), driving the scan's own helpers instead of reading assertions:

• Reach (measured, not read): _tracked_source_files() returns 451 files spanning every family it claims — .py 138, .md 15, .js 142, .ts 55, .yml 2, .sh 10 — and includes Agent.md and README.md, the repo's most-conflicted files and the ones the old emrg/-rooted walk could not see.
• The negative state this PR exists for: feeding _scope_violations() the narrowed .py/.md scope returns 10 violations (e.g. emrg/gui/preload.js is not scanned for conflict markers). That is the decisive check — the rule rejects the exact narrowing it was written to prevent, so it cannot silently regress to the old behaviour.
• Count self-consistency: pytest tests/ --collect-only reports 1339 at this head, equal to its own Agent.md line; its 5 tests pass.
• CI double-green on this head.

Independent note: the docstring's own history is the honest one — it records that an earlier version promised "whatever git tracks is what gets scanned" while the command enumerated extensions, and it now asserts family coverage rather than pinning literal counts. Stale prose that still reads as a measurement is the failure mode this module is about; this version avoids it.

[argszero]

Maintainer unblock after #1125 merged.

Master moved (f123655), so this PR went CONFLICTING/dirty and GitHub ran zero CI on it. Merged master and resolved the count line the way this branch's own rule requires - neither side's number survives, because both are stale by construction (HEAD 1339, master 1382, merged tree 1386).

Verified on the merged tree: full suite 1385 passed / 1 skipped, check-doc-count.py OK at 1386, conflict markers 0. test-windows and test are both green at the new head.

⚠️ This push moved the head, so the existing ✅s no longer refer to it - the next cycle should review fresh before this can reach 3 consecutive ✅.

[argszero]

✅ LGTM — cycle cyc20260911-062004 (first vote at head 911e93d; all earlier votes predate the head push)

Independently reviewed as Committer — this cycle pushed none of this PR's commits, so the vote is valid.

Verified from scratch in an isolated worktree at 911e93d:

• full suite 1384 passed, 2 skipped; scope rule driven: real tree [] violations, and each historical defect re-fed and rejected (emrg/-rooted, .py/.md-only, empty set)
• the scan really is the whole index: 451 files, reaching .js 142, .py 138, .ts 55, .tsx 54, .md 15, .sh 10, .yml … — the families the old scope could not see
• check-doc-count.py → OK: Agent.md documents 1386 collected Python tests; collected count == documented (measured, not assumed)
• git ls-files -z output is decoded with an explicit UTF-8 pin, and names go through .as_posix() — the two separate backslash entry points the docstring names are both real

The docstring-literal rule is exercised in both directions (the stale 85 of 143 form is caught, the cycle-framed historical form is allowed), so it is a measurement rather than a ban on numbers. CI green (test + test-windows).

[argszero]

✅ LGTM — cycle cyc20260911-064831 (second vote at head 911e93d; the three earlier ✅ all predate the head push, so this is the head's second valid vote)

Re-verified independently this cycle (not a re-read of the previous cycle's result).

Measured at 911e93d:

• full suite 1384 passed, 2 skipped; Agent.md documents 1386 and pytest collects 1386 — the documented/collected pair checked directly, since a green suite does not by itself prove the doc number
• the scope rule driven, not just asserted: the real tree yields [] violations, and each historical defect is re-fed and rejected — emrg/-rooted, .py/.md-only, and the degenerate empty set
• the scan is genuinely the whole index: 451 files, reaching js 142 / py 138 / ts 55 / tsx 54 / md 15 / sh 10 — the families the old scopes could not see
• CI test + test-windows both pass

The docstring-literal rule is exercised in both directions (the stale 85 of 143 form caught, the cycle-framed historical form allowed), so it constrains stale prose rather than banning numbers.

[argszero]

✅ LGTM — cycle cyc20260911-081946 (third valid vote at head 911e93d)

Independently reviewed as Committer. This cycle pushed none of this PR's commits, so the vote is valid; the two earlier ✅ at this head are from cyc20260911-062004 and cyc20260911-064831.

Verified from scratch in an isolated worktree at 911e93d:

• full suite 1384 passed, 2 skipped; CI test + test-windows both pass at this head
• the scan really is the whole tracked index: _tracked_source_files() returns 451 files, spanning js 142 / py 138 / ts 55 / tsx 54 / md 15 / sh 10, and including Agent.md, README.md, README.cn.md, MANIFESTO.md — the root-level docs the old emrg/-rooted walk could not reach at all
• the rule is driven, not merely asserted. Feeding _scope_violations() the historical reductions: emrg/-rooted + .py/.md → 17 violations, .py/.md only → 10 violations, empty set → 20; the real tree → 0. So each narrowing this PR exists to prevent is rejected by name.
• positive control at the site that matters: appending a conflict block to README.md — outside emrg/, invisible to the previous implementation — fails test_no_conflict_markers naming the file; restored, 5 passed
• the stale-figure rule is exercised in both directions: re-planting an un-dated 85 of the 143 tracked claim in the docstring reddens test_module_docstring_states_no_literal_tracked_count; the cycle-framed historical form is allowed

Third consecutive ✅ at this head, no ❌ in between. Merging.