Fix dockerfile func_start recall: route to Mode A, not brace search

[squid-protocol]

Summary

Manually verified dockerfile's tri-comparison numbers via the tri-comparison-ledger-sweep skill's manual-verification fallback (dockerfile is one of 5 languages -- abap, dockerfile, jcl, livecode, yaml -- with neither a tree-sitter grammar nor ctags support). Found and fixed a real function-existence recall bug, plus surfaced/filed three narrower follow-ons.

• The bug: dockerfile has no ScopeParsingRegistry entry and no brace-delimited instruction bodies at all (RUN/CMD/ENTRYPOINT/HEALTHCHECK end at the next instruction, never at {/}), so it silently fell through to Mode_B_Braces in detector.py's _function_slice. That mode only produces a named function when a literal { happens to appear by coincidence within its search window -- in practice almost always an unrelated later instruction's ${VAR} template brace, not anything belonging to the matched instruction's own body.
• Evidence: the raw func_start regex was 100% correct in isolation (71/71 matches vs. an independent grep, zero discrepancies across the 4-file language-crucible/data/dockerfile/moby/test_targets/ corpus). But the real pipeline's named function list (function_data/function_count) only captured 15/71 of them pre-fix, with bogus body-boundary/impact numbers borrowed from unrelated later lines on top of that.
• The fix: routes dockerfile to Mode A (_slice_by_labels), the same "greedy to the next func_start match" heuristic already proven for abap/cobol/fortran/assembly (abap's own identical bug shape was detector.py: ABAP unregistered in ScopeParsingRegistry falls through to brace-based function slicing, dropping ~87% of real methods #1899). This is a direct, correct fit -- every Dockerfile instruction, including a RUN <<EOF ... EOF heredoc body, really does span exactly from its own keyword to the next instruction or EOF.

Verification chain

• dockerfile extraction gauntlet + strict tests: 120 passed
• core detector tests: 141 passed
• ruff_audit.py --ci / mypy_audit.py --ci: clean against baseline
• crucible_check.py against the full ~80-repo corpus: confirmed the fix generalizes -- a 5th real occurrence (shell/brew/Dockerfile, embedded in an unrelated repo whose dominant language is shell) was also corrected, with zero diffs in any other language/file
• Both golden master fixtures re-blessed (update_golden_master.py --yes, both full_precision and zero_dependency venvs)

Docs / papertrail

• docs/language_status/dockerfile.md (new) -- full coverage doc + §9 manual-verification writeup, including why there's no class entry in manual_verification.json (dockerfile's class_start raw signal is 100% accurate, but named build-stage extraction doesn't exist yet -- see dockerfile has no named class (build-stage) extraction -- class_start regex captures the FROM keyword, not the stage alias #1974)
• docs/self_scan/manual_verification.json -- new dockerfile.function entry (71/71 verified), earns dockerfile's **/badge on the tri-comparison chart's Functions Found panel
• docs/self_scan/tri_comparison_chart.svg / tri_comparison_points_of_interest.md -- regenerated (routine --all --write refresh; only dockerfile's own row and the summary counts changed content-wise, rest is timestamp churn)

Follow-on issues filed (not bundled here -- each has its own, broader blast radius)

• file_data.class_count sourced from raw class_start signal, not the real named class list #1972 -- file_data.class_count is sourced from the raw class_start signal instead of len(classes), unlike function_count which correctly uses len(functions). General record_keeper.py bug affecting every language, not dockerfile-specific.
• Mode A (_slice_by_labels) generic args-count search is unbounded, can attribute unrelated text to a function's parameter count #1973 -- Mode A's generic per-function args search is unbounded (searches the whole greedy block, not just the matched instruction's own line), so it can spuriously attribute an unrelated ARG line swept into a RUN's body span as that RUN's "parameter count." Pre-existing, shared by cobol/fortran/assembly too -- just far less visible under dockerfile's old, badly-broken routing. Confirmed live in the regenerated chart's own "Args Found: 52‡" reading (should be 0 for a none-granularity language).
• dockerfile has no named class (build-stage) extraction -- class_start regex captures the FROM keyword, not the stage alias #1974 -- dockerfile has no named build-stage (class) extraction at all -- a missing feature, not a bug in an existing implementation. Needs a class_start regex change (to capture the AS <alias> name, not just the literal FROM keyword) before it can be added to _CLASS_START_NAMED_EXTRACTION_LANGS.
• jcl and m4 (and possibly makefile) have the same Mode B brace-search func_start recall bug as dockerfile/abap/scheme #1975 -- the same Mode B brace-search recall bug, confirmed via the identical direct measurement, also affects jcl (3→0 recall) and m4 (39→1 recall); makefile's corpus sample was too small (1 match) to confirm either way.

🤖 Generated with Claude Code

[github-actions]

🐦‍⬛ Muninn Security Scan

Severity	Count
🔴 Critical	0
🟠 High	0
🟡 Medium	0
🟢 Low	0
ℹ️ Info	3

ℹ️ Info Findings

[checkov] Ensure that a user for the container has been created

File: /docs/language_status/dockerfile.md:1
Rule: CKV_DOCKER_3
Ensure that a user for the container has been created

[checkov] Ensure that HEALTHCHECK instructions have been added to container images

File: /docs/language_status/dockerfile.md:1
Rule: CKV_DOCKER_2
Ensure that HEALTHCHECK instructions have been added to container images

[checkov] Ensure the base image uses a non latest version tag

File: /docs/language_status/dockerfile.md:157
Rule: CKV_DOCKER_7
Ensure the base image uses a non latest version tag

🐦‍⬛ Powered by Muninn · Skald Lab