Say in the file that these five scripts have never run (#410) - #461
Conversation
#413 pinned the five as broken in tests/test_scripts_import.py, which tells the suite. It tells nobody who opens curate_evidence_with_pdfs.py and finds 586 lines of plausible code. Each now carries a docstring warning saying so, and a test asserts every entry in _KNOWN_BROKEN carries one - keyed on that set rather than a fixed list, so a script joining later cannot arrive undocumented. What the warning records, all of it verified: literature_enhanced has never existed in any commit, and the five arrived together with the phantom module in the repo's first commit, so there is no revision at which they worked. Porting is not an import swap - they call fetch_paper(ref, download_pdf=...) and subscript the result, while LiteratureFetcher.fetch_paper(reference, email=...) returns a tuple and has no PDF download, so every call site needs rewriting across 1787 lines. And working equivalents exist, which is what the warning points at. Deleting them is #410's option 1 and the history supports it, but that is ~1800 lines I did not write and the issue frames it as a decision, so it stays open. Writing the test that asserts the pointed-at replacement exists is what caught that it does not. reference_validator.py was deleted in 4dd299a when the custom validators were replaced by the official LinkML ones; only an untracked .pyc remains. CLAUDE.md still named it as the sole occupant of validators/, omitting the seven that are there and that validate_strict.py - the CI gate - runs. Corrected, and filed as #460 along with the broader point that nothing checks that file. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ing right The review found three, and the first is the worst kind - a fresh instance of the error class this PR exists to fix. CLAUDE.md said validate_strict.py runs cross_repo_ids. It does not: that validator has its own script and recipe, and validate_strict imports five, one of which (ncbi_domain) arrives transitively through prokaryotic_lineage. Corrected to say which runs what. Second, all five docstrings said the scripts arrived "in the first commit (7c658e6)". 7c658e6 is the seventh; the first is 79f5196 - and the sentence contradicted itself, claiming the module never existed in any commit and then naming the commit they arrived in. tests/test_scripts_import.py, the file each docstring points at, already had this right. Reworded to say only what is checkable: the file was added in 7c658e6 already importing the phantom module, so no revision exists where it worked. Third, the API paragraph was pasted verbatim into all five, but test_pdf_fetching.py never calls fetch_paper - it calls fetch_pdf_url(doi), which LiteratureFetcher has no equivalent of at all. Its warning now says that, including that the PDF downloading it is built around is implemented nowhere. On the review's fourth point, that docs still advertise these as working: it is mostly wrong. docs/AUTOMATION_TOOLS.md carries the NOT FUNCTIONAL marker directly above the invocation, and docs/pdf_fetching_capability.md opens with one. The real residue is that the latter's banner sits 140 lines above the commands, so a reader landing mid-document misses it - inline markers added at both command sections. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Review round 1 — three wrong facts, in prose whose entire point is accuracyThe worst one is a fresh instance of the error this PR exists to fix
ProvenanceAll five docstrings said the scripts arrived "in the first commit (7c658e6)". Wrong API describedThe API paragraph was pasted verbatim into all five, but On the fourth finding — mostly wrong, and worth saying soThe review said docs "still advertise four of the five as working". They don't: The real residue is narrower and genuine: that banner sits 140 lines above the commands (L149–204), so a reader landing mid-document via search or a section link misses it. Inline markers added at both command sections, one pointing at Confirmed by the review, and worth recordingThe phantom module was checked exhaustively — no path matching
|
…462) * Execute CLAUDE.md's architecture tree instead of trusting it (#460) CLAUDE.md is loaded as authoritative context every session and described as instructions that override default behaviour. Nothing checked it, and it had drifted two ways at once, both found by accident while working #410. It named validators/reference_validator.py as the sole occupant of that directory. That file was deleted in 4dd299a when the custom validators were replaced by the official LinkML ones; only an untracked .pyc survives, so a naive find appears to succeed. The seven validators actually there - the ones the CI gate runs - went undocumented. Fixed in #461. And it said kb/communities/ holds 60 files. It holds 312 - off by a factor of five, fixed here. The test parses the tree rather than grepping it, tracking parents because the tree is nested and a bare cli.py means src/communitymech/cli.py, and asserts every path resolves. A separate check pins the record count the prose quotes. There is a guard on the parser too, so reformatting the tree cannot silently empty the check that depends on it. Verified by injecting a fake path: the parametrised case for it fails and names it. Deliberately narrow. It checks what is mechanically checkable and says nothing about whether the prose is any good, which no test can. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address the #462 review: the parser was blind to the entries it should catch The review found the test checked 12 of the 15 paths the tree declares, and the three it missed were exactly the top-level file entries - conf/oak_config.yaml, NEXT_TASKS.md, NEXT_TASKS_LOOP.md. Demonstrated: replacing two of them with nonexistent files left the suite green, including NEXT_TASKS.md, which the same doc calls the backlog source of truth. A test written to catch a stale path could not see the stale paths most likely to appear. Three line shapes carry a path, and the parser recognised two. It handles the third now, and covers 15 with 0 unconsumed. Verified: faking both top-level entries produces two failures. The `>= 10` guard was the other half of the problem - a lower bound with two of slack, so it reported healthy at 12 while three went unchecked, and could not distinguish a tree that shrank from a parser that went blind. Replaced with the invariant that actually holds: every non-blank, non-comment line is classified, or the test names the ones that were not. Also dropped the ternary that special-cased children starting with kb/ or src/. It was unreachable for the current tree, hardcoded two directory names, and got the paths wrong when I made it fire - a child is relative to its parent, which is what a tree means. And CLAUDE.md said "Python 3.9+ target" while pyproject requires >=3.10 and black, ruff and mypy are all configured for 3.10. Fixed, and pinned - a PR premised on executing this file's checkable facts should not leave one wrong. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
1 participant
Addresses #410. Does not close it — the delete-or-port decision stays open, deliberately.
What was already true
#413 pinned the five in
tests/test_scripts_import.py::_KNOWN_BROKEN. That tells the suite. It tells nobody who openscurate_evidence_with_pdfs.pyand finds 586 lines of plausible code.What this adds
A docstring warning on each, and a test asserting every entry in
_KNOWN_BROKENcarries one — keyed on that set rather than a fixed list, so a script joining later can't arrive undocumented.Everything the warning states, verified:
communitymech.literature_enhancedhas never existed in any commit. The five arrived together with the phantom module in the repo's first commit (7c658e6), so there is no revision at which they worked.fetch_paper(ref, download_pdf=...)and subscript the result (paper["abstract"]); the realLiteratureFetcher.fetch_paper(reference, email=...)returns an(abstract, pdf_url)tuple and has no PDF download. Every call site needs rewriting, across 1787 lines.Why not just delete them
That's #410's option 1 and the history supports it — but it's ~1800 lines I didn't write, and the issue frames the choice as a decision to be made. Left for you. The warning means the cost of leaving them is now near zero: nobody will mistake one for a working tool.
A finding that fell out of it
Writing the test that asserts the replacement named in those docstrings exists is what caught that it doesn't.
src/communitymech/validators/reference_validator.pywas deleted in 4dd299a ("Replace custom validators with official LinkML validators"); only an untracked.pycremains, so a naivefindappears to succeed.CLAUDE.mdstill named it as the sole occupant ofvalidators/— omitting the seven that are there (gtdb_coherence,gtdb_lineage_tree,ncbi_domain,prokaryotic_lineage,shared_taxon_ids,yaml_scalars,cross_repo_ids) and thatscripts/validate_strict.py, the CI gate, runs. So the one directory the gate depends on was the one described entirely wrongly. Corrected here; filed as #460 with the broader point that nothing checks that file (it also claimskb/communities/has 60 files, where it has 333).just qcgreen · 129 passed, 5 skipped in the scripts-import suite.🤖 Generated with Claude Code