Repository navigation
Strict parsing tests: blp structural signatures #576
Description
Update: the lexical-delimiter checklist item originally in this issue (_line_anchor/_inline_comment/_block_start/_block_end) has been removed -- those 4 rule keys are dead config, never read anywhere in gitgalaxy/ (confirmed via grep -rn across the whole package). The real comment-stripping engine (prism.py's _strip_segment_comments) dispatches purely on lexical_family against a separate family-level table in gitgalaxy_config.py. See the epic (#518) for the new issue tracking that real gap instead.
Part of #518.
Language: blp
- Lexical family:
standard_block - Extensions:
.blp - 0 of the baseline structural signatures are defined (non-
None) for this language ingitgalaxy/standards/language_standards.py.
Reference
gitgalaxy/standards/how_to_add_a_language.md is the canonical doc for what each signature is supposed to capture/exclude, the 5 lexical parsing families, and (recently added) the AI/ML and literate-programming extension packs. Read the INCLUDES/EXCLUDES wording there for any signature before writing its test -- the one-line descriptions below are a quick-reference copy, not the full spec.
A rule being None here is not a gap
Only write tests for the checklist below. If a signature isn't in this language's rules dict, or is explicitly None, that's an intentional "doesn't apply to this language" per the doc's Strict Feature Parity rule (#4) -- don't invent a synthetic match for it just to have a test.
Checklist (this language's non-None structural signatures)
Test template
For each checked signature: (1) a positive-match test against its documented includes, capturing exact group text where applicable; (2) a negative-match test against its documented excludes; (3) any cross-rule ambiguity check flagged above; (4) a ReDoS immunity test (reuse assert_redos_immune from tests/core_engine/test_language_standards_strict.py) sized to this rule's actual quantifiers. Group multiple signatures that share the same simple pattern into one parametrized test rather than writing near-duplicates -- don't force one test per key if several are trivially similar for this language.
New tests land in tests/core_engine/test_language_standards_strict.py, the existing home for this style of test.
Activity
squid-protocol commentedon Jul 28, 2026
Reminder added retroactively (2026-07-28): closing this issue requires actually running
pytest -m golden_cruciblein both a full-precision and a true zero-dependency venv, and walking through the resulting diff file-by-file (pergitgalaxy/standards/how_to_add_a_language.md's Step 5) -- not just checking that it passes, and not skipping it if the corpus isn't locally available.Context: PR #681 (yaml, #617) closed this exact issue type without running
golden_crucible("not run, the language-crucible corpus isn't checked out in this environment"). That PR's regex fixes were real and correctly verified at the unit level, but skipping the crucible run meant a real, separate pipeline bug went undetected --detector.py's "Prose Deflection" gate was (and for yaml/json/csv, still is -- see #694) silently discarding that language's entire structural-signature output before it ever reached a real scan, regardless of how correct the regexes were. #617 had to be reopened once this was discovered. A zero-diff crucible result is also not automatically a clean bill of health -- confirm why it's zero (does the corpus even contain the fixed construct?) rather than assuming a pass means nothing changed.If
LANGUAGE_CRUCIBLE_PATH/thelanguage-cruciblecorpus genuinely isn't available when this issue is worked, say so explicitly in the PR rather than silently checking the box -- and flag it back for a follow-up crucible pass before considering the issue fully closed.squid-protocol commentedon Jul 28, 2026
Confirmed via direct inspection of
LANGUAGE_DEFINITIONS: this language has zero non-Nonestructural signatures defined ingitgalaxy/standards/language_standards.py. Per the issue's own "A rule beingNonehere is not a gap" note and the doc's Strict Feature Parity rule (#4), there is nothing to adversarially test -- an empty checklist, correctly.Closing as complete/not-applicable. If this language should eventually get real structural signatures defined (a feature addition, not a testing gap), that's separate work outside this issue's scope -- happy to file a fresh issue for that if wanted.