Summary
Follow-up to #405 / #417. The single-line + standalone-* fix killed the markdown-bold and cross-heading false positives, but two false-positive paths remain in the EA1 wildcard pattern:
(r"(?:tools?|permissions?)\s*:[ \t]*\[?[ \t]*['\"]?\*(?!\*|\w)['\"]?[ \t]*\]?", 0.85)
Case 1: footnote/legend text still matches
The (?!\*|\w) lookahead only rejects a * followed by another * or a word character. A standalone * followed by a space passes — and documentation legitimately uses a bare * as a footnote marker after a label:
Tools: * = requires authentication
Tools: * marks optional parameters
Both match today (verified with re.IGNORECASE | re.MULTILINE, matched text Tools: * ) and fire EA1/MEDIUM on benign docs — same class of false positive as #405.
Case 2: the gap before the colon still crosses blank lines
#417 bounded the whitespace after the colon to [ \t]*, but the \s* before the colon still matches newlines. A line ending in tools/permissions followed by a blank line and a markdown definition-list line starting with : still bridges paragraphs:
Matched text: tools\n\n: * — the same cross-paragraph disease #405 reported, on the other side of the colon.
Proposed fix
- Bare (unquoted)
* should only count when it ends the line (optionally followed by ] and/or a # comment): a real bare-scalar grant has nothing after the value, a footnote legend always does. Quoted forms ("*", '*') stay as-is — they are unambiguous.
- Bound the pre-colon gap to the same line:
[ \t]*: instead of \s*:. No real YAML/JSON/TOML syntax puts a newline between a key and its colon.
Verified against the full single-line grant matrix (quoted, bracketed, bare, no-space, tab, CRLF, uppercase, trailing comment): no genuine form is lost.
Summary
Follow-up to #405 / #417. The single-line + standalone-
*fix killed the markdown-bold and cross-heading false positives, but two false-positive paths remain in the EA1 wildcard pattern:Case 1: footnote/legend text still matches
The
(?!\*|\w)lookahead only rejects a*followed by another*or a word character. A standalone*followed by a space passes — and documentation legitimately uses a bare*as a footnote marker after a label:Both match today (verified with
re.IGNORECASE | re.MULTILINE, matched textTools: *) and fire EA1/MEDIUM on benign docs — same class of false positive as #405.Case 2: the gap before the colon still crosses blank lines
#417 bounded the whitespace after the colon to
[ \t]*, but the\s*before the colon still matches newlines. A line ending intools/permissionsfollowed by a blank line and a markdown definition-list line starting with:still bridges paragraphs:Matched text:
tools\n\n: *— the same cross-paragraph disease #405 reported, on the other side of the colon.Proposed fix
*should only count when it ends the line (optionally followed by]and/or a#comment): a real bare-scalar grant has nothing after the value, a footnote legend always does. Quoted forms ("*",'*') stay as-is — they are unambiguous.[ \t]*:instead of\s*:. No real YAML/JSON/TOML syntax puts a newline between a key and its colon.Verified against the full single-line grant matrix (quoted, bracketed, bare, no-space, tab, CRLF, uppercase, trailing comment): no genuine form is lost.