The deep dive's verified figures are re-derived by a test, or they are not on the line by Shashankss1205 · Pull Request #105 · CodeGraphContext/GraphARC

Shashankss1205 · 2026-08-13T18:08:07Z

Closes#42.

The rot

The Verified this pass paragraph quotes concrete numbers and nothing checked them, so they drifted — twice:

the page said	the tree had
1,533 passed … 103 submodules	1,754 tests, 116 submodules
1,985 passed, 12 deselected	2,137 selected, 13 live

Both were hand-corrected at the time; the mechanism that let them rot was still there.

The choice the issue offered, and which one this takes

The issue offered two: assert the figures, or remove them. This asserts them — the repo's stated discipline is that prose stating a checkable fact gets a check, the same one tests/test_readme.py and tests/test_cookbook_*.py already enforce by byte-comparing output.

But it rewords first, and the reword is the substance, not cosmetics: the figures are now what one command re-derives — how many tests pytestselects, and how many it holds back as live — rather than a pass count. A pass count cannot be re-derived without running the suite from inside itself, which is precisely how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green.

How it re-derives

One collection pass in a subprocess. In-process is not an option — this module is collected by the session doing the asking, and re-entering the collector from inside it is not supported. -m "" clears the -m 'not live' that pyproject's addopts supplies, and the marker is read off each item, so a single pass yields both figures rather than two passes yielding one each. Cost: ~2s.

Two guards behind the two comparisons

Both close ways a check can pass while proving nothing:

test_the_paragraph_still_quotes_every_figure_this_file_checks — deleting a number from the sentence makes the test red rather than vacuous. Same trap test_the_section_still_holds_the_two_blocks_this_file_checks closes for the README.
test_the_paragraph_quotes_no_figure_that_nothing_re_derives — any bare count with a unit that this file does not own fails, with wording that says to add a check or take it off the line. This is what stops the next "1,985 passed" from being added.

The version the paragraph claims is on PyPI is held against pyproject.toml, for the same reason ci.yml already refuses a grapharc.__version__ that disagrees with it.

Verification

uv run pytest tests/test_deep_dive.py — 5 passed.
uv run ruff check grapharc tests — clean.
Restoring the exact historical drift (1,985 passed, 12 selected) turns two red: the selection comparison and the unowned-figure guard.

🤖 Generated with Claude Code

…e not on the line The **Verified this pass** paragraph closes the deep dive with concrete numbers, and nothing checked them, so they drifted twice: it read "1,533 passed … 103 submodules" against a tree with 1,754 tests and 116 submodules, and it read "1,985 passed, 12 deselected" against a tree with 2,137 selected and 13 live. The paragraph's whole value is that its numbers are real. A reader who spots one stale figure discounts every other verified claim on the page, including the ones the suite genuinely enforces. The figures are now quoted as what one command re-derives — how many tests `pytest` selects, and how many it holds back as `live` — rather than as a pass count. That reword is the point, not cosmetics: a pass count cannot be re-derived without running the suite from inside itself, which is exactly how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green. tests/test_deep_dive.py re-derives both in one collection pass, in a subprocess — this module is collected by the session doing the asking, so re-entering the collector in-process is not on. `-m ""` clears the addopts `-m 'not live'` and the marker is read off each item, so one pass yields both figures instead of two passes yielding one each; it costs about two seconds. Two guards sit behind the two comparisons, both closing ways the check could pass while saying nothing. One asserts the figures are still quoted at all, so deleting a number makes the test red rather than vacuous — the trap `tests/test_readme.py` already closes for its fenced blocks. The other asserts no *unowned* figure has appeared on the line: any bare count with a unit that this file does not re-derive fails, with wording that says to add a check or take the number off. That is the rule the issue settled on. The version the paragraph says is on PyPI is held against pyproject's, for the same reason `ci.yml` already refuses a `grapharc.__version__` that disagrees with it: a release note naming a third number is that failure with no check. Restoring the historical drift turns both the comparison and the unowned-figure guard red. Closes#42 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ht tests Which is the mechanism working as intended — merging a PR that adds tests made the deep dive's figure stale, and the check caught it rather than letting it sit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shashankss1205 · 2026-08-13T18:08:07Z

Closes#42.

The rot

The Verified this pass paragraph quotes concrete numbers and nothing checked them, so they drifted — twice:

the page said	the tree had
1,533 passed … 103 submodules	1,754 tests, 116 submodules
1,985 passed, 12 deselected	2,137 selected, 13 live

Both were hand-corrected at the time; the mechanism that let them rot was still there.

The choice the issue offered, and which one this takes

The issue offered two: assert the figures, or remove them. This asserts them — the repo's stated discipline is that prose stating a checkable fact gets a check, the same one tests/test_readme.py and tests/test_cookbook_*.py already enforce by byte-comparing output.

But it rewords first, and the reword is the substance, not cosmetics: the figures are now what one command re-derives — how many tests pytestselects, and how many it holds back as live — rather than a pass count. A pass count cannot be re-derived without running the suite from inside itself, which is precisely how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green.

How it re-derives

One collection pass in a subprocess. In-process is not an option — this module is collected by the session doing the asking, and re-entering the collector from inside it is not supported. -m "" clears the -m 'not live' that pyproject's addopts supplies, and the marker is read off each item, so a single pass yields both figures rather than two passes yielding one each. Cost: ~2s.

Two guards behind the two comparisons

Both close ways a check can pass while proving nothing:

test_the_paragraph_still_quotes_every_figure_this_file_checks — deleting a number from the sentence makes the test red rather than vacuous. Same trap test_the_section_still_holds_the_two_blocks_this_file_checks closes for the README.
test_the_paragraph_quotes_no_figure_that_nothing_re_derives — any bare count with a unit that this file does not own fails, with wording that says to add a check or take it off the line. This is what stops the next "1,985 passed" from being added.

The version the paragraph claims is on PyPI is held against pyproject.toml, for the same reason ci.yml already refuses a grapharc.__version__ that disagrees with it.

Verification

uv run pytest tests/test_deep_dive.py — 5 passed.
uv run ruff check grapharc tests — clean.
Restoring the exact historical drift (1,985 passed, 12 selected) turns two red: the selection comparison and the unowned-figure guard.

🤖 Generated with Claude Code

…e not on the line The **Verified this pass** paragraph closes the deep dive with concrete numbers, and nothing checked them, so they drifted twice: it read "1,533 passed … 103 submodules" against a tree with 1,754 tests and 116 submodules, and it read "1,985 passed, 12 deselected" against a tree with 2,137 selected and 13 live. The paragraph's whole value is that its numbers are real. A reader who spots one stale figure discounts every other verified claim on the page, including the ones the suite genuinely enforces. The figures are now quoted as what one command re-derives — how many tests `pytest` selects, and how many it holds back as `live` — rather than as a pass count. That reword is the point, not cosmetics: a pass count cannot be re-derived without running the suite from inside itself, which is exactly how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green. tests/test_deep_dive.py re-derives both in one collection pass, in a subprocess — this module is collected by the session doing the asking, so re-entering the collector in-process is not on. `-m ""` clears the addopts `-m 'not live'` and the marker is read off each item, so one pass yields both figures instead of two passes yielding one each; it costs about two seconds. Two guards sit behind the two comparisons, both closing ways the check could pass while saying nothing. One asserts the figures are still quoted at all, so deleting a number makes the test red rather than vacuous — the trap `tests/test_readme.py` already closes for its fenced blocks. The other asserts no *unowned* figure has appeared on the line: any bare count with a unit that this file does not re-derive fails, with wording that says to add a check or take the number off. That is the rule the issue settled on. The version the paragraph says is on PyPI is held against pyproject's, for the same reason `ci.yml` already refuses a `grapharc.__version__` that disagrees with it: a release note naming a third number is that failure with no check. Restoring the historical drift turns both the comparison and the unowned-figure guard red. Closes#42 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ht tests Which is the mechanism working as intended — merging a PR that adds tests made the deep dive's figure stale, and the check caught it rather than letting it sit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shashankss1205 · 2026-08-13T18:08:07Z

Closes#42.

The rot

The Verified this pass paragraph quotes concrete numbers and nothing checked them, so they drifted — twice:

the page said	the tree had
1,533 passed … 103 submodules	1,754 tests, 116 submodules
1,985 passed, 12 deselected	2,137 selected, 13 live

Both were hand-corrected at the time; the mechanism that let them rot was still there.

The choice the issue offered, and which one this takes

The issue offered two: assert the figures, or remove them. This asserts them — the repo's stated discipline is that prose stating a checkable fact gets a check, the same one tests/test_readme.py and tests/test_cookbook_*.py already enforce by byte-comparing output.

But it rewords first, and the reword is the substance, not cosmetics: the figures are now what one command re-derives — how many tests pytestselects, and how many it holds back as live — rather than a pass count. A pass count cannot be re-derived without running the suite from inside itself, which is precisely how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green.

How it re-derives

One collection pass in a subprocess. In-process is not an option — this module is collected by the session doing the asking, and re-entering the collector from inside it is not supported. -m "" clears the -m 'not live' that pyproject's addopts supplies, and the marker is read off each item, so a single pass yields both figures rather than two passes yielding one each. Cost: ~2s.

Two guards behind the two comparisons

Both close ways a check can pass while proving nothing:

test_the_paragraph_still_quotes_every_figure_this_file_checks — deleting a number from the sentence makes the test red rather than vacuous. Same trap test_the_section_still_holds_the_two_blocks_this_file_checks closes for the README.
test_the_paragraph_quotes_no_figure_that_nothing_re_derives — any bare count with a unit that this file does not own fails, with wording that says to add a check or take it off the line. This is what stops the next "1,985 passed" from being added.

The version the paragraph claims is on PyPI is held against pyproject.toml, for the same reason ci.yml already refuses a grapharc.__version__ that disagrees with it.

Verification

uv run pytest tests/test_deep_dive.py — 5 passed.
uv run ruff check grapharc tests — clean.
Restoring the exact historical drift (1,985 passed, 12 selected) turns two red: the selection comparison and the unowned-figure guard.

🤖 Generated with Claude Code

…e not on the line The **Verified this pass** paragraph closes the deep dive with concrete numbers, and nothing checked them, so they drifted twice: it read "1,533 passed … 103 submodules" against a tree with 1,754 tests and 116 submodules, and it read "1,985 passed, 12 deselected" against a tree with 2,137 selected and 13 live. The paragraph's whole value is that its numbers are real. A reader who spots one stale figure discounts every other verified claim on the page, including the ones the suite genuinely enforces. The figures are now quoted as what one command re-derives — how many tests `pytest` selects, and how many it holds back as `live` — rather than as a pass count. That reword is the point, not cosmetics: a pass count cannot be re-derived without running the suite from inside itself, which is exactly how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green. tests/test_deep_dive.py re-derives both in one collection pass, in a subprocess — this module is collected by the session doing the asking, so re-entering the collector in-process is not on. `-m ""` clears the addopts `-m 'not live'` and the marker is read off each item, so one pass yields both figures instead of two passes yielding one each; it costs about two seconds. Two guards sit behind the two comparisons, both closing ways the check could pass while saying nothing. One asserts the figures are still quoted at all, so deleting a number makes the test red rather than vacuous — the trap `tests/test_readme.py` already closes for its fenced blocks. The other asserts no *unowned* figure has appeared on the line: any bare count with a unit that this file does not re-derive fails, with wording that says to add a check or take the number off. That is the rule the issue settled on. The version the paragraph says is on PyPI is held against pyproject's, for the same reason `ci.yml` already refuses a `grapharc.__version__` that disagrees with it: a release note naming a third number is that failure with no check. Restoring the historical drift turns both the comparison and the unowned-figure guard red. Closes#42 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ht tests Which is the mechanism working as intended — merging a PR that adds tests made the deep dive's figure stale, and the check caught it rather than letting it sit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shashankss1205 · 2026-08-13T18:08:07Z

Closes#42.

The rot

The Verified this pass paragraph quotes concrete numbers and nothing checked them, so they drifted — twice:

the page said	the tree had
1,533 passed … 103 submodules	1,754 tests, 116 submodules
1,985 passed, 12 deselected	2,137 selected, 13 live

Both were hand-corrected at the time; the mechanism that let them rot was still there.

The choice the issue offered, and which one this takes

The issue offered two: assert the figures, or remove them. This asserts them — the repo's stated discipline is that prose stating a checkable fact gets a check, the same one tests/test_readme.py and tests/test_cookbook_*.py already enforce by byte-comparing output.

But it rewords first, and the reword is the substance, not cosmetics: the figures are now what one command re-derives — how many tests pytestselects, and how many it holds back as live — rather than a pass count. A pass count cannot be re-derived without running the suite from inside itself, which is precisely how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green.

How it re-derives

One collection pass in a subprocess. In-process is not an option — this module is collected by the session doing the asking, and re-entering the collector from inside it is not supported. -m "" clears the -m 'not live' that pyproject's addopts supplies, and the marker is read off each item, so a single pass yields both figures rather than two passes yielding one each. Cost: ~2s.

Two guards behind the two comparisons

Both close ways a check can pass while proving nothing:

test_the_paragraph_still_quotes_every_figure_this_file_checks — deleting a number from the sentence makes the test red rather than vacuous. Same trap test_the_section_still_holds_the_two_blocks_this_file_checks closes for the README.
test_the_paragraph_quotes_no_figure_that_nothing_re_derives — any bare count with a unit that this file does not own fails, with wording that says to add a check or take it off the line. This is what stops the next "1,985 passed" from being added.

The version the paragraph claims is on PyPI is held against pyproject.toml, for the same reason ci.yml already refuses a grapharc.__version__ that disagrees with it.

Verification

uv run pytest tests/test_deep_dive.py — 5 passed.
uv run ruff check grapharc tests — clean.
Restoring the exact historical drift (1,985 passed, 12 selected) turns two red: the selection comparison and the unowned-figure guard.

🤖 Generated with Claude Code

…e not on the line The **Verified this pass** paragraph closes the deep dive with concrete numbers, and nothing checked them, so they drifted twice: it read "1,533 passed … 103 submodules" against a tree with 1,754 tests and 116 submodules, and it read "1,985 passed, 12 deselected" against a tree with 2,137 selected and 13 live. The paragraph's whole value is that its numbers are real. A reader who spots one stale figure discounts every other verified claim on the page, including the ones the suite genuinely enforces. The figures are now quoted as what one command re-derives — how many tests `pytest` selects, and how many it holds back as `live` — rather than as a pass count. That reword is the point, not cosmetics: a pass count cannot be re-derived without running the suite from inside itself, which is exactly how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green. tests/test_deep_dive.py re-derives both in one collection pass, in a subprocess — this module is collected by the session doing the asking, so re-entering the collector in-process is not on. `-m ""` clears the addopts `-m 'not live'` and the marker is read off each item, so one pass yields both figures instead of two passes yielding one each; it costs about two seconds. Two guards sit behind the two comparisons, both closing ways the check could pass while saying nothing. One asserts the figures are still quoted at all, so deleting a number makes the test red rather than vacuous — the trap `tests/test_readme.py` already closes for its fenced blocks. The other asserts no *unowned* figure has appeared on the line: any bare count with a unit that this file does not re-derive fails, with wording that says to add a check or take the number off. That is the rule the issue settled on. The version the paragraph says is on PyPI is held against pyproject's, for the same reason `ci.yml` already refuses a `grapharc.__version__` that disagrees with it: a release note naming a third number is that failure with no check. Restoring the historical drift turns both the comparison and the unowned-figure guard red. Closes#42 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ht tests Which is the mechanism working as intended — merging a PR that adds tests made the deep dive's figure stale, and the check caught it rather than letting it sit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shashankss1205 · 2026-08-13T18:08:07Z

Closes#42.

The rot

The Verified this pass paragraph quotes concrete numbers and nothing checked them, so they drifted — twice:

the page said	the tree had
1,533 passed … 103 submodules	1,754 tests, 116 submodules
1,985 passed, 12 deselected	2,137 selected, 13 live

Both were hand-corrected at the time; the mechanism that let them rot was still there.

The choice the issue offered, and which one this takes

The issue offered two: assert the figures, or remove them. This asserts them — the repo's stated discipline is that prose stating a checkable fact gets a check, the same one tests/test_readme.py and tests/test_cookbook_*.py already enforce by byte-comparing output.

But it rewords first, and the reword is the substance, not cosmetics: the figures are now what one command re-derives — how many tests pytestselects, and how many it holds back as live — rather than a pass count. A pass count cannot be re-derived without running the suite from inside itself, which is precisely how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green.

How it re-derives

One collection pass in a subprocess. In-process is not an option — this module is collected by the session doing the asking, and re-entering the collector from inside it is not supported. -m "" clears the -m 'not live' that pyproject's addopts supplies, and the marker is read off each item, so a single pass yields both figures rather than two passes yielding one each. Cost: ~2s.

Two guards behind the two comparisons

Both close ways a check can pass while proving nothing:

test_the_paragraph_still_quotes_every_figure_this_file_checks — deleting a number from the sentence makes the test red rather than vacuous. Same trap test_the_section_still_holds_the_two_blocks_this_file_checks closes for the README.
test_the_paragraph_quotes_no_figure_that_nothing_re_derives — any bare count with a unit that this file does not own fails, with wording that says to add a check or take it off the line. This is what stops the next "1,985 passed" from being added.

The version the paragraph claims is on PyPI is held against pyproject.toml, for the same reason ci.yml already refuses a grapharc.__version__ that disagrees with it.

Verification

uv run pytest tests/test_deep_dive.py — 5 passed.
uv run ruff check grapharc tests — clean.
Restoring the exact historical drift (1,985 passed, 12 selected) turns two red: the selection comparison and the unowned-figure guard.

🤖 Generated with Claude Code

…e not on the line The **Verified this pass** paragraph closes the deep dive with concrete numbers, and nothing checked them, so they drifted twice: it read "1,533 passed … 103 submodules" against a tree with 1,754 tests and 116 submodules, and it read "1,985 passed, 12 deselected" against a tree with 2,137 selected and 13 live. The paragraph's whole value is that its numbers are real. A reader who spots one stale figure discounts every other verified claim on the page, including the ones the suite genuinely enforces. The figures are now quoted as what one command re-derives — how many tests `pytest` selects, and how many it holds back as `live` — rather than as a pass count. That reword is the point, not cosmetics: a pass count cannot be re-derived without running the suite from inside itself, which is exactly how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green. tests/test_deep_dive.py re-derives both in one collection pass, in a subprocess — this module is collected by the session doing the asking, so re-entering the collector in-process is not on. `-m ""` clears the addopts `-m 'not live'` and the marker is read off each item, so one pass yields both figures instead of two passes yielding one each; it costs about two seconds. Two guards sit behind the two comparisons, both closing ways the check could pass while saying nothing. One asserts the figures are still quoted at all, so deleting a number makes the test red rather than vacuous — the trap `tests/test_readme.py` already closes for its fenced blocks. The other asserts no *unowned* figure has appeared on the line: any bare count with a unit that this file does not re-derive fails, with wording that says to add a check or take the number off. That is the rule the issue settled on. The version the paragraph says is on PyPI is held against pyproject's, for the same reason `ci.yml` already refuses a `grapharc.__version__` that disagrees with it: a release note naming a third number is that failure with no check. Restoring the historical drift turns both the comparison and the unowned-figure guard red. Closes#42 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ht tests Which is the mechanism working as intended — merging a PR that adds tests made the deep dive's figure stale, and the check caught it rather than letting it sit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shashankss1205 · 2026-08-13T18:08:07Z

Closes#42.

The rot

The Verified this pass paragraph quotes concrete numbers and nothing checked them, so they drifted — twice:

the page said	the tree had
1,533 passed … 103 submodules	1,754 tests, 116 submodules
1,985 passed, 12 deselected	2,137 selected, 13 live

Both were hand-corrected at the time; the mechanism that let them rot was still there.

The choice the issue offered, and which one this takes

The issue offered two: assert the figures, or remove them. This asserts them — the repo's stated discipline is that prose stating a checkable fact gets a check, the same one tests/test_readme.py and tests/test_cookbook_*.py already enforce by byte-comparing output.

But it rewords first, and the reword is the substance, not cosmetics: the figures are now what one command re-derives — how many tests pytestselects, and how many it holds back as live — rather than a pass count. A pass count cannot be re-derived without running the suite from inside itself, which is precisely how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green.

How it re-derives

One collection pass in a subprocess. In-process is not an option — this module is collected by the session doing the asking, and re-entering the collector from inside it is not supported. -m "" clears the -m 'not live' that pyproject's addopts supplies, and the marker is read off each item, so a single pass yields both figures rather than two passes yielding one each. Cost: ~2s.

Two guards behind the two comparisons

Both close ways a check can pass while proving nothing:

test_the_paragraph_still_quotes_every_figure_this_file_checks — deleting a number from the sentence makes the test red rather than vacuous. Same trap test_the_section_still_holds_the_two_blocks_this_file_checks closes for the README.
test_the_paragraph_quotes_no_figure_that_nothing_re_derives — any bare count with a unit that this file does not own fails, with wording that says to add a check or take it off the line. This is what stops the next "1,985 passed" from being added.

The version the paragraph claims is on PyPI is held against pyproject.toml, for the same reason ci.yml already refuses a grapharc.__version__ that disagrees with it.

Verification

uv run pytest tests/test_deep_dive.py — 5 passed.
uv run ruff check grapharc tests — clean.
Restoring the exact historical drift (1,985 passed, 12 selected) turns two red: the selection comparison and the unowned-figure guard.

🤖 Generated with Claude Code

…e not on the line The **Verified this pass** paragraph closes the deep dive with concrete numbers, and nothing checked them, so they drifted twice: it read "1,533 passed … 103 submodules" against a tree with 1,754 tests and 116 submodules, and it read "1,985 passed, 12 deselected" against a tree with 2,137 selected and 13 live. The paragraph's whole value is that its numbers are real. A reader who spots one stale figure discounts every other verified claim on the page, including the ones the suite genuinely enforces. The figures are now quoted as what one command re-derives — how many tests `pytest` selects, and how many it holds back as `live` — rather than as a pass count. That reword is the point, not cosmetics: a pass count cannot be re-derived without running the suite from inside itself, which is exactly how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green. tests/test_deep_dive.py re-derives both in one collection pass, in a subprocess — this module is collected by the session doing the asking, so re-entering the collector in-process is not on. `-m ""` clears the addopts `-m 'not live'` and the marker is read off each item, so one pass yields both figures instead of two passes yielding one each; it costs about two seconds. Two guards sit behind the two comparisons, both closing ways the check could pass while saying nothing. One asserts the figures are still quoted at all, so deleting a number makes the test red rather than vacuous — the trap `tests/test_readme.py` already closes for its fenced blocks. The other asserts no *unowned* figure has appeared on the line: any bare count with a unit that this file does not re-derive fails, with wording that says to add a check or take the number off. That is the rule the issue settled on. The version the paragraph says is on PyPI is held against pyproject's, for the same reason `ci.yml` already refuses a `grapharc.__version__` that disagrees with it: a release note naming a third number is that failure with no check. Restoring the historical drift turns both the comparison and the unowned-figure guard red. Closes#42 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ht tests Which is the mechanism working as intended — merging a PR that adds tests made the deep dive's figure stale, and the check caught it rather than letting it sit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shashankss1205 · 2026-08-13T18:08:07Z

Closes#42.

The rot

The Verified this pass paragraph quotes concrete numbers and nothing checked them, so they drifted — twice:

the page said	the tree had
1,533 passed … 103 submodules	1,754 tests, 116 submodules
1,985 passed, 12 deselected	2,137 selected, 13 live

Both were hand-corrected at the time; the mechanism that let them rot was still there.

The choice the issue offered, and which one this takes

The issue offered two: assert the figures, or remove them. This asserts them — the repo's stated discipline is that prose stating a checkable fact gets a check, the same one tests/test_readme.py and tests/test_cookbook_*.py already enforce by byte-comparing output.

But it rewords first, and the reword is the substance, not cosmetics: the figures are now what one command re-derives — how many tests pytestselects, and how many it holds back as live — rather than a pass count. A pass count cannot be re-derived without running the suite from inside itself, which is precisely how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green.

How it re-derives

One collection pass in a subprocess. In-process is not an option — this module is collected by the session doing the asking, and re-entering the collector from inside it is not supported. -m "" clears the -m 'not live' that pyproject's addopts supplies, and the marker is read off each item, so a single pass yields both figures rather than two passes yielding one each. Cost: ~2s.

Two guards behind the two comparisons

Both close ways a check can pass while proving nothing:

test_the_paragraph_still_quotes_every_figure_this_file_checks — deleting a number from the sentence makes the test red rather than vacuous. Same trap test_the_section_still_holds_the_two_blocks_this_file_checks closes for the README.
test_the_paragraph_quotes_no_figure_that_nothing_re_derives — any bare count with a unit that this file does not own fails, with wording that says to add a check or take it off the line. This is what stops the next "1,985 passed" from being added.

The version the paragraph claims is on PyPI is held against pyproject.toml, for the same reason ci.yml already refuses a grapharc.__version__ that disagrees with it.

Verification

uv run pytest tests/test_deep_dive.py — 5 passed.
uv run ruff check grapharc tests — clean.
Restoring the exact historical drift (1,985 passed, 12 selected) turns two red: the selection comparison and the unowned-figure guard.

🤖 Generated with Claude Code

…e not on the line The **Verified this pass** paragraph closes the deep dive with concrete numbers, and nothing checked them, so they drifted twice: it read "1,533 passed … 103 submodules" against a tree with 1,754 tests and 116 submodules, and it read "1,985 passed, 12 deselected" against a tree with 2,137 selected and 13 live. The paragraph's whole value is that its numbers are real. A reader who spots one stale figure discounts every other verified claim on the page, including the ones the suite genuinely enforces. The figures are now quoted as what one command re-derives — how many tests `pytest` selects, and how many it holds back as `live` — rather than as a pass count. That reword is the point, not cosmetics: a pass count cannot be re-derived without running the suite from inside itself, which is exactly how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green. tests/test_deep_dive.py re-derives both in one collection pass, in a subprocess — this module is collected by the session doing the asking, so re-entering the collector in-process is not on. `-m ""` clears the addopts `-m 'not live'` and the marker is read off each item, so one pass yields both figures instead of two passes yielding one each; it costs about two seconds. Two guards sit behind the two comparisons, both closing ways the check could pass while saying nothing. One asserts the figures are still quoted at all, so deleting a number makes the test red rather than vacuous — the trap `tests/test_readme.py` already closes for its fenced blocks. The other asserts no *unowned* figure has appeared on the line: any bare count with a unit that this file does not re-derive fails, with wording that says to add a check or take the number off. That is the rule the issue settled on. The version the paragraph says is on PyPI is held against pyproject's, for the same reason `ci.yml` already refuses a `grapharc.__version__` that disagrees with it: a release note naming a third number is that failure with no check. Restoring the historical drift turns both the comparison and the unowned-figure guard red. Closes#42 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ht tests Which is the mechanism working as intended — merging a PR that adds tests made the deep dive's figure stale, and the check caught it rather than letting it sit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shashankss1205 · 2026-08-13T18:08:07Z

Closes#42.

The rot

The Verified this pass paragraph quotes concrete numbers and nothing checked them, so they drifted — twice:

the page said	the tree had
1,533 passed … 103 submodules	1,754 tests, 116 submodules
1,985 passed, 12 deselected	2,137 selected, 13 live

Both were hand-corrected at the time; the mechanism that let them rot was still there.

The choice the issue offered, and which one this takes

The issue offered two: assert the figures, or remove them. This asserts them — the repo's stated discipline is that prose stating a checkable fact gets a check, the same one tests/test_readme.py and tests/test_cookbook_*.py already enforce by byte-comparing output.

But it rewords first, and the reword is the substance, not cosmetics: the figures are now what one command re-derives — how many tests pytestselects, and how many it holds back as live — rather than a pass count. A pass count cannot be re-derived without running the suite from inside itself, which is precisely how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green.

How it re-derives

One collection pass in a subprocess. In-process is not an option — this module is collected by the session doing the asking, and re-entering the collector from inside it is not supported. -m "" clears the -m 'not live' that pyproject's addopts supplies, and the marker is read off each item, so a single pass yields both figures rather than two passes yielding one each. Cost: ~2s.

Two guards behind the two comparisons

Both close ways a check can pass while proving nothing:

test_the_paragraph_still_quotes_every_figure_this_file_checks — deleting a number from the sentence makes the test red rather than vacuous. Same trap test_the_section_still_holds_the_two_blocks_this_file_checks closes for the README.
test_the_paragraph_quotes_no_figure_that_nothing_re_derives — any bare count with a unit that this file does not own fails, with wording that says to add a check or take it off the line. This is what stops the next "1,985 passed" from being added.

The version the paragraph claims is on PyPI is held against pyproject.toml, for the same reason ci.yml already refuses a grapharc.__version__ that disagrees with it.

Verification

uv run pytest tests/test_deep_dive.py — 5 passed.
uv run ruff check grapharc tests — clean.
Restoring the exact historical drift (1,985 passed, 12 selected) turns two red: the selection comparison and the unowned-figure guard.

🤖 Generated with Claude Code

…e not on the line The **Verified this pass** paragraph closes the deep dive with concrete numbers, and nothing checked them, so they drifted twice: it read "1,533 passed … 103 submodules" against a tree with 1,754 tests and 116 submodules, and it read "1,985 passed, 12 deselected" against a tree with 2,137 selected and 13 live. The paragraph's whole value is that its numbers are real. A reader who spots one stale figure discounts every other verified claim on the page, including the ones the suite genuinely enforces. The figures are now quoted as what one command re-derives — how many tests `pytest` selects, and how many it holds back as `live` — rather than as a pass count. That reword is the point, not cosmetics: a pass count cannot be re-derived without running the suite from inside itself, which is exactly how "1,985 passed" came to be a number no test owned. The suite being green is asserted by the suite being green. tests/test_deep_dive.py re-derives both in one collection pass, in a subprocess — this module is collected by the session doing the asking, so re-entering the collector in-process is not on. `-m ""` clears the addopts `-m 'not live'` and the marker is read off each item, so one pass yields both figures instead of two passes yielding one each; it costs about two seconds. Two guards sit behind the two comparisons, both closing ways the check could pass while saying nothing. One asserts the figures are still quoted at all, so deleting a number makes the test red rather than vacuous — the trap `tests/test_readme.py` already closes for its fenced blocks. The other asserts no *unowned* figure has appeared on the line: any bare count with a unit that this file does not re-derive fails, with wording that says to add a check or take the number off. That is the rule the issue settled on. The version the paragraph says is on PyPI is held against pyproject's, for the same reason `ci.yml` already refuses a `grapharc.__version__` that disagrees with it: a release note naming a third number is that failure with no check. Restoring the historical drift turns both the comparison and the unowned-figure guard red. Closes#42 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ht tests Which is the mechanism working as intended — merging a PR that adds tests made the deep dive's figure stale, and the check caught it rather than letting it sit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shashankss1205and others added 2 commits August 13, 2026 23:49

Shashankss1205 force-pushed the fix/issue-42-verified-numbers branch from e25ecaf to 95d7ed9Compare August 13, 2026 18:20

Shashankss1205 merged commit ac3270e into mainAug 13, 2026
6 checks passed

Shashankss1205 deleted the fix/issue-42-verified-numbers branch August 13, 2026 18:24

Shashankss1205 mentioned this pull request Aug 13, 2026
Release 0.1.6 #107
Merged