sqlite tri-comparison validation: class extraction to 100%, both ledger shapes validated - #2513
Merged
Merged
Conversation
…er shapes validated Closes out the tri-skill validation pass (harden-language-extraction, harden-strict-signatures, tri-comparison-ledger-sweep) on sqlite, the newest crucible language category (PR #13/#17). **Real bug #1 (recall):** sqlite was never added to detector.py's _CLASS_START_NAMED_EXTRACTION_LANGS, so its already-hardened epic #813/#836 class_start regex (CREATE TABLE) never reached named-entity output -- class_data stayed permanently empty (0 of 73 real tables) despite the regex itself working. Added sqlite to the allowlist. **Real bug #2 (precision):** the newly-populated class names came out with their SQLite quote characters still attached ("User" instead of User) for any double/backtick/bracket-quoted table -- class_start's capture group includes the quotes by design (epic #813/#836 kept them in a single group to preserve the "group 2 == inheritance parent" convention every other allowlisted language relies on). Added a sqlite-scoped quote-strip in splice() so the stored name is the bare identifier, matching ctags/SQLite itself. **Real bug #3 (dependency-graph precision):** _dependency_capture's `.import`/`.read`/`.load` alternative captured the first whitespace- delimited token unconditionally -- SQLite CLI's real `.import` accepts leading flags (`-csv`, `-colsep ","`, `-skip N`, ...), so `.import -csv file1.csv t4` captured the flag `-csv` itself as the "dependency path", a real false positive. Fixed by requiring the captured token not start with `-` (trades a miss for never a wrong path, matching this signal's existing bias elsewhere in the file). Verified against the live tri-comparison gatherer (not just the regex in isolation): class existence is now 73/73 (100% recall) against ctags' 66/73, a strict superset -- the 7 gitgalaxy-only occurrences are all independently confirmed real tables ctags' SQL parser misses (virtual tables, tables after a leading `BEGIN;`, backtick-quoted identifiers). Function existence (262 gitgalaxy `*_Statement` satellites vs. ctags' 0 `f`/`p` tags) is a genuine different-question case, same "closest function-shaped construct this language has" precedent as css's at-rules -- SQLite has no CREATE FUNCTION/PROCEDURE syntax for ctags to find. Both docs/self_scan/tri_comparison_ledger.json shapes recorded as `validated` with full investigation writeups (class: credit gitgalaxy; function: no credit, since crediting would misstate "ctags should have agreed" rather than "nothing for ctags to find"). Chart/report regenerated --all --write per repo convention; only sqlite's two shapes changed (verified via structural diff against main), no other language disturbed. audit_strict_coverage.py confirms sqlite's strict-signature suite (epic #1069) already has zero gaps (43/43 applicable signatures, 81 cases) -- harden-strict-signatures needed no changes. Filed #2512 separately (not fixed here, out of this PR's scope): two aperture heuristics (infra_path_pattern's `generated`/`scripts` segments, the content-based "Machine-Generated Source Code Signature" gate) silently exclude 33 of the sqlite corpus's 73 git-tracked .sql files from ever being scanned -- a real corpus-utilization gap, but pre-existing and orthogonal to this pass's extraction-correctness fixes. Verification: crucible_check.py clean on both venvs (no golden-master diff), audit_check.py clean, full extraction+strict+detector+core_engine suites pass (166 sqlite gauntlet/strict tests + 1 new detector-level allowlist/quote-strip test, 859 passed across the broader suite). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014BKXKcW29F3pTm7To2wMwS
Contributor
squid-protocol
added a commit
that referenced
this pull request
Aug 30, 2026
…cision to 100% (#2517) * sqlite function precision to 100%: full-set validation of all 262 GitGalaxy claims Follow-up to #2513. That PR validated the function shape with no credit, reasoning it was purely a "different question" case (SQLite has no CREATE FUNCTION/PROCEDURE for ctags to find). Revisited per request: went back and did the full validation the credit mechanism's own docstring actually calls for -- "a human confirms the uncorroborated claim was real" -- rather than reasoning about the shape only in the abstract. Pulled every one of GitGalaxy's 262 function occurrences via the live gatherer (not just the ledger's capped 10-example sample) and cross-checked by type: - 232/262 (CREATE x103, INSERT x76, DROP x49, ALTER x3, DELETE x1) match an independent `grep -c '^KEYWORD'` count over the same 40 scanned files EXACTLY. - The remaining 30 read against real source directly: 15 `Declarative_Block` (the igniter regex's fallback name for a real statement whose keyword isn't in its fixed list) are confirmed real BEGIN/COMMIT/PRAGMA transaction-control statements in sqitch_sqlite_engine/*.sql, plus one deliberately-malformed Prisma migration-failure fixture (`BROKEN SCRIPT;` -- still a real, correctly `;`-bounded structural unit). The other 15 `SELECT_Statement_[Unterminated]` are all prisma_typed_sql/*.sql -- Prisma's typed-SQL convention of one bare query per file with no trailing `;` at all (confirmed: findBigInt.sql is exactly `SELECT \`id\` FROM \`TestModel\` WHERE \`bigInt\` = ?`, args=1 matching its one `?` bind param). Zero false positives across the full set. Added `credit_tools: ["gitgalaxy"]` to sqlite/function/existence/agree[gitgalaxy]_vs[ctags] -- verified via apply_verified_adjustments directly (not just the ledger status flag): gitgalaxy function precision goes 0.0% -> 100.0%, matching class precision (already 100% after credit from #2513). Chart/report regenerated --all --write; structural diff against main confirms only this one shape's credit_tools changed, no other language touched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014BKXKcW29F3pTm7To2wMwS * fix(#2512): stop silently dropping 45% of the sqlite corpus from scanning Three separate mechanisms were each independently excluding real sqlite DDL/DML files before they ever reached prism/detector -- found while re-validating the sqlite tri-comparison ledger after #2513/6a48cd47 credited GitGalaxy's class/ function claims: those credits were only ever verified against the 40 files that made it past these gates, not the full 73-file corpus. 1. **aperture.py infra_path_pattern** (Gate 1.4): the #2415-fixed, left-boundary- correct semantic path shield still treats "generated"/"scripts" as real noise signals -- true for compiled/vendored output, false for SQL DDL/DML, where both are common, legitimate path segments for canonical content (MediaWiki's `tables-generated.sql`, its own `generateSchemaChangeSql.php` convention; SQLite's own `sqlite_cli_scripts/` test fixtures). 2. **aperture.py machine_gen_pattern** (Gate 4.3, "Machine-Generated Source Code Signature"): a generator-signature header comment ("This file is automatically generated...") reads as noise for transpiled/ORM output but means "canonical, committed migration" for SQL (MediaWiki's abstractSchemaChanges, Prisma migrations) -- blocked all 18 mediawiki_sqlite_alterpatches/*.sql + 2 more. 3. **galaxyscope.py Neighborhood Micro-Mass Quota** (new finding, not in the original issue text): a directory-level quota already exempts `.cpy`/`.cbl`/ `.cob`/`.jcl` for being "legitimately tiny AND legitimately numerous in one directory" -- confirmed the identical shape for SQL DDL/DML via Prisma's typed-SQL convention (`prisma_typed_sql/`, 16 real one-line queries at 42-49 bytes each), which silently dropped the 16th past the 15-file grace limit. Fix: exempt `.sql`/`.ddl`/`.dml` from all three gates, mirroring how SQL is already treated as its own data-shaped format elsewhere in aperture.py (Gate 3.3's size-tiered Static Asset Bloat Deflector already runs its own noise gate for this exact extension set, so Gate 4.3's exemption doesn't leave SQL ungated) and matching the existing COBOL/JCL micro-mass precedent exactly. Extension-scoped, zero behavior change for any other file kind -- verified via new regression tests plus the full existing aperture/core_engine/extraction suites (all passing, 6 new + 19 existing aperture tests, 576 core_engine, 6262 extraction). Result: language-crucible's sqlite corpus goes from 40/73 to 73/73 files scanned. Golden masters regenerated for both venvs (`update_golden_master.py`) -- the drift is real and expected: every metric that counts scanned mass moved because real content that was invisible is now visible (sqlite composition 47->80 files matches this repo's own copy of the crucible corpus; 3D topological coordinates shift globally since the network's total mass changed). crucible_check.py clean on both full_precision and zero_dependency after the regen. Re-validated the two sqlite tri-comparison ledger shapes against the now- complete 73-file corpus (not just re-trusting the 40-file-corpus credit): function claims grew 262->734, cross-checked by type against independent grep keyword counts (CREATE/INSERT/DROP/ALTER/DELETE match EXACTLY outside sqlite_cli_scripts/; the SELECT/Declarative_Block delta is fully explained by CREATE...AS SELECT continuation lines and .check heredoc test-assertion text, not missed statements) -- credit_tools stays ['gitgalaxy'], function precision holds at 100%. Class claims stayed 7 gitgalaxy-only (unchanged by the newly- visible files) but surfaced ONE new discrepancy: sqlite_cli_scripts/import01.sql has 2 ctags-only 't1' occurrences that are ctags false positives inside a `.check <<END...END` heredoc (SQLite's own CLI test-harness convention for asserting expected stdout, not executable SQL) -- validated with no credit to either tool, since ctags is simply wrong here, not GitGalaxy right by omission. Class precision (after the earlier #2513 credit) holds at 100%; class recall stays honestly at 98.9% since the residual is ctags' own false positive, not a real GitGalaxy gap worth chasing by matching heredoc noise. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014BKXKcW29F3pTm7To2wMwS --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Tri-skill validation pass on
sqlite(the newest crucible language category, PR #13/#17):harden-language-extraction,harden-strict-signatures,tri-comparison-ledger-sweep. Result:sqlite's class-extraction recall/precision go from 0% / N/A → 100% / strict-superset-of-ctags,
both
tri_comparison_ledger.jsonshapes go fromunvalidated→validated, and two more realextraction bugs get fixed along the way.
Three real bugs found and fixed
_CLASS_START_NAMED_EXTRACTION_LANGSin
detector.py, so its already-hardened epic Epic: Harden the four extraction gauntlets (function/args/class/dependency) per language #813/Extraction hardening: sqlite #836class_startregex (CREATE TABLE)never reached named-entity output —
class_datastayed permanently empty despite the regexitself working correctly. Added to the allowlist (same pattern as cobol/abap/livecode).
characters still attached (
"User"instead ofUser) —class_start's capture groupincludes the quote chars by design, to preserve the "group 2 == inheritance parent" convention
every other allowlisted language relies on. Added a sqlite-scoped strip in
splice()._dependency_capturefalse positive:.import/.read/.loadcaptured the firstwhitespace-delimited token unconditionally. SQLite CLI's real
.importaccepts leading flags(
-csv,-colsep ",",-skip N, ...), so.import -csv file1.csv t4captured the flag-csvitself as the "dependency path" — a real false positive that would pollute thedependency DAG. Fixed by requiring the captured token not start with
-.Verified against the live pipeline, not just regexes in isolation
Ran the actual
tri_comparison_gatherer/reconcileagainst the pinned crucible corpus (40scanned sqlite files):
The residual 7 gitgalaxy-only tables are all confirmed real (
CREATE VIRTUAL TABLE ... USING FTS3, tables after a leadingBEGIN;, backtick-quoted identifiers) — ctags' SQL parser misseseach for a different, confirmed reason. Full writeups in the ledger verdicts.
The function shape (262 gitgalaxy
*_Statementstatement-block satellites vs. ctags' 0f/ptags) is a genuine different-question case — SQLite has no
CREATE FUNCTION/PROCEDUREsyntaxfor ctags to find, same "closest function-shaped construct this language has" precedent already
established for css's at-rules. Recorded
validated, no credit (crediting would misstate thefinding).
Also verified clean, no changes needed
audit_strict_coverage.py --lang sqliteconfirms zero gaps in the strict-signature suite (epic#1069): 43/43 applicable signatures covered, 81 cases.
harden-strict-signaturesneeded nothing.Out of scope, filed separately
#2512 — two aperture heuristics (
infra_path_pattern'sgenerated/scriptspath segments, thecontent-based "Machine-Generated Source Code Signature" gate) silently exclude 33 of the sqlite
corpus's 73 git-tracked
.sqlfiles from ever being scanned. Real corpus-utilization gap, butpre-existing and orthogonal to this PR's extraction-correctness fixes — tracked, not fixed here.
Verification
tests/tools/crucible_check.py: clean on bothfull_precisionandzero_dependencyvenvs — nogolden-master diff (the golden-master corpus has no sqlite
.sqlDDL, so this change doesn'ttouch it).
tests/tools/audit_check.py: clean (ruff/mypy/dead-key/ast-accuracy).tests/tools/tri_comparison_chart.py --all --write: regenerated per repo convention; structuraldiff against
mainconfirms only sqlite's two shapes changed status — no other language'sledger entry, credit/debit, or count touched.
regression test, all passing.
tests/suite (minustests/extraction, verified separately): 859 passed, 0 failed.🤖 Generated with Claude Code