fix(#2512): sqlite corpus scanning 40/73 -> 73/73 files; function precision to 100% - #2517
Merged
Merged
Conversation
…Galaxy 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
…ning 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
Contributor
squid-protocol
added a commit
that referenced
this pull request
Aug 30, 2026
…fixed (#2519) * sqlite earns its function precision badge; new ledger-validated badge path sqlite's function panel had 100% precision (credited in #2517) but no winner badge: `_winner_or_tie` needs 2+ tools with real (non-None) `rate_pct` data, and ctags is structurally always 0/0 for sqlite functions (no CREATE FUNCTION/PROCEDURE syntax exists to find), so there's never a real 2-tool comparison to rank. The existing 1-tool-language bypass (`_manual_verification_winner`) doesn't apply either -- sqlite has ctags "available" (it covers the class panel), and that function's own docstring deliberately excludes func/class precision from any manual-record bypass: "a 2-3 tool language's real 0/N must stay visible, not be quietly replaced by a manual record" -- a guard against papering over an unroot-caused parser gap. sqlite's case clears that guard's own bar, though: it's not an unconfirmed gap, it's a specifically ledger-validated confirmation (universal-ctags' SQL parser CAN emit `f`/`p` kinds for dialects that have them -- PL/SQL, T-SQL -- SQLite just has none to find). That's the identical "no comparison could ever exist here" justification the `args` metric already gets its own narrower carve-out for (`ARGS_GRANULARITY.get(lang) in ("proxy", "program_level")`), just evidenced by an actual investigated verdict instead of a static per-language flag -- stronger evidence than that carve-out already requires, not weaker. Added `_ledger_credited_lone_claimant_winner()`: a third, narrow fallback (after `_winner_or_tie` and `_manual_verification_winner` both return None) that awards GitGalaxy's badge only when it's the sole tool with real data for that exact (language, symbol_type, metric) AND a `status: "validated"` ledger entry with `agreeing_tools == ["gitgalaxy"]` and `"gitgalaxy" in credit_tools` exists for it -- requires the same investigation rigor a real cross-tool win or full manual verification already requires, never a bare "nobody else has data" observation. 7 new unit tests cover the gating (credited+validated awards; unvalidated, uncredited, a second real-data tool, GitGalaxy itself lacking data, a mismatched language/metric, or a shared-agreement shape all correctly withhold it). Verified via a full `--all --write` regen: structural diff against main confirms the ledger itself is untouched (this is a pure chart-rendering change) and exactly one badge was added chart-wide -- sqlite's function panel -- confirmed by counting badges per language before/after, not just eyeballing the sqlite row. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014BKXKcW29F3pTm7To2wMwS * tcl: fix ctags namespace-qualified proc names, clear the ledger backlog Investigated the one currently-reproducing, unvalidated tcl shape: tcl/function/existence/agree[ctags]_vs[gitgalaxy,tree_sitter] (93 occurrences, all in macports_port_api/*.tcl -- MacPorts' Tcl Portfile API). Root cause confirmed via `ctags --output-format=json --fields=+znS`: every occurrence is a namespace-qualified proc (`proc portfetch::percent_encode {str} {`). GitGalaxy's func_start and tree-sitter-tcl both read the qualified identifier straight out of the source text (`portfetch::percent_encode`), matching each other exactly on all 93 -- ctags instead splits it into a bare `name:percent_encode` tag plus a separate `scope:portfetch`/ `scopeKind:namespace` field, and this repo's ctags_reader.py was dropping that scope field on the floor for tcl. Not a real recall gap or disagreement about whether these procs exist -- a pure ctags-reader naming mismatch. Fixed by adding "tcl" to `_QUALIFY_NAME_WITH_SCOPE`, reusing the identical scope-joining + verbatim-source-line-guard mechanism already proven for C++'s `Class::method` out-of-class-definition convention -- Tcl's `namespace` scope kind was already in `_CTAGS_SCOPE_KIND_KEYS` and its `::` separator is identical to C++'s, so no new parsing logic was needed, only the language gate. Also scoped `_normalize_cpp_operator_name` to cpp only (it was applying unconditionally inside the now-shared branch) so a Tcl proc literally named `operator` isn't mistaken for a C++ operator-overload tag. Verified: 0 ctags-only misses remain for tcl functions corpus-wide (was 93). cpp's own qualification behavior (the only other consumer of this mechanism) is unchanged -- confirmed byte-for-byte identical shape counts on all 4 of its existence discrepancy shapes before and after. 3 new regression tests (qualified-name join, the bare-proc-inside-namespace-eval guard staying unqualified, and the operator-name-normalization scoping guard). No credit/debit needed on the ledger verdict -- all three tools already agreed on the underlying fact; only the ctags reader's name extraction was wrong. tcl's function panel now earns its precision badge (100% 3-way tie, broken by GitGalaxy's higher validated claim count: 352 vs. 337 vs. 334) and its ledger backlog is fully cleared (0 remaining currently-reproducing unvalidated shapes). 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
Two follow-ups to #2513, both requested directly: get sqlite function precision to 100% by
validating what GitGalaxy found, and fix #2512.
Part 1: function precision to 100%
#2513 validated the sqlite function shape (
*_Statementsatellites vs. ctags' 0f/ptags)with no credit — reasoning it was purely a different-question case. Revisited: went back and
did the full validation the credit mechanism's own docstring calls for ("a human confirms the
uncorroborated claim was real"). Pulled every one of GitGalaxy's 262 occurrences (pre-#2512 corpus
size) via the live gatherer and cross-checked by type — 232/262 match an independent
grep -c '^KEYWORD'count exactly; the other 30 read against real source directly (BEGIN/COMMIT/PRAGMAtransaction-control, one deliberately-malformed test fixture, and Prisma's one-query-per-file
typed-SQL convention). Zero false positives.
credit_tools: ["gitgalaxy"]→ function precision0.0% → 100.0%, matching class precision (already 100% via #2513's credit).
Part 2: #2512 — 45% of the sqlite corpus was never being scanned
Investigating the credit's validity surfaced a bigger problem: the credit was only ever checked
against the 40 files that survived scanning, not the full 73-file corpus. Three separate
mechanisms (not the two #2512 originally named) were silently excluding real
.sqlfiles beforeprism/detector ever saw them:
aperture.py'sinfra_path_pattern(Gate 1.4) —tables-generated.sql(-generated.), all 11sqlite_cli_scripts/*.sql(_scripts/)aperture.py'smachine_gen_pattern(Gate 4.3, "Machine-Generated Source Code Signature") — all18
mediawiki_sqlite_alterpatches/*.sql+ 2 more (their header literally says "This file isautomatically generated using maintenance/generateSchemaChangeSql.php")
galaxyscope.py's Neighborhood Micro-Mass Quotaalready exempts
.cpy/.cbl/.cob/.jclfor being "legitimately tiny AND legitimatelynumerous in one directory" — the identical shape hits
prisma_typed_sql/, 16 real one-linetyped-SQL queries (42-49 bytes each), silently dropping the 16th past the 15-file grace limit
Fix: exempt
.sql/.ddl/.dmlfrom all three gates — extension-scoped, mirrors how SQL isalready treated as its own data format elsewhere in
aperture.py(Gate 3.3's own size-tiered noisegate already covers this exact extension set), and matches the existing COBOL/JCL micro-mass
precedent exactly. Zero behavior change for any other file kind.
Result: sqlite corpus scanning goes 40/73 → 73/73 files.
Re-validation at the new scale (not just re-trusting the old credit)
match an independent grep count exactly outside
sqlite_cli_scripts/; the SELECT/Declarative_Blockdelta inside it is fully explained (verified against real source) byCREATE ... AS SELECTcontinuation lines and.check <<END...ENDheredoc test-assertion text(SQLite's own CLI test-harness convention), not missed statements. Precision holds at 100%.
discrepancy surfaced:
sqlite_cli_scripts/import01.sqlhas 2 ctags-onlyt1occurrences thatare ctags false positives inside a
.checkheredoc (matching the CLI's own printed-outputtext, not executable SQL). Validated with no credit to either tool — ctags is simply wrong here.
Class precision (from sqlite tri-comparison validation: class extraction to 100%, both ledger shapes validated #2513's credit) holds at 100%; class recall stays honestly at 98.9%
since the residual is ctags' own mistake, not a real GitGalaxy gap worth chasing.
Verification
crucible_check.py: clean on bothfull_precisionandzero_dependencyafter regenerating bothgolden masters (
update_golden_master.py) — the drift itself was large but fully expected(every metric counting scanned mass moved because real, previously-invisible content is now
visible; this repo's own copy of the crucible corpus shows the same
sqlitefile-count jump).audit_check.py: clean (ruff/mypy/dead-key/ast-accuracy).tests/core_engine/test_aperture.pytests, fullcore_engine(576) andextraction(6262) suites,tools/(23) — all passing.tri_comparison_chart.py --all --write: structural diff againstmainconfirms only sqlite'sledger entries changed (one new discrepancy validated, one credit added) — no other language's
status/credit/debit touched.
🤖 Generated with Claude Code