fix(parser-react): decode HTML entities in rendered-text extraction (6F.10, A16)#52
Merged
officialCodeWork merged 1 commit intoJul 15, 2026
Conversation
…6F.10, A16) Self-found validating 0.4.0 on Grafana's frontend: rendered text that is an HTML entity (` `, `"`, `>`, `"`, `·`, `<`, `›`) survived into `renderedText` as a junk token (`nbsp`, `34`, `gt`), creating spurious matches — and a numeric entity like `"`→"34" let a gibberish query sharing those digits ("zzqwxnomatch12345") match. New `entities.ts` decodes the HTML entities React resolves at render time (numeric decimal/hex generically, named entities from a curated map; unknown names left verbatim, matching React). `extractRenderedText` decodes JSX text and quoted attribute values — the surfaces React HTML-decodes — while JS string/template literals stay untouched. Decoded entities become the character React renders, which the normalizer strips as punctuation/whitespace, so an entity-only component yields no discriminating match target. New fixture `a16-html-entities`: the entity-only component produces no target, and the named-entity token, numeric-entity token, and digit-sharing gibberish all decline `no-signal` while a real query still lands on the real component. 7 new parser-react tests (136 total); eval 304/0/0/0, gate OK, metrics 1.000. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Merged
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
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.
Step 6F.10 — HTML-entity rendered-text noise (failure mode A16, new)
Self-found validating 0.4.0 on Grafana's frontend. Rendered text that is an HTML entity —
,",>,",·,<,›— survived intorenderedTextas a junk token ( →"nbsp","→"34",>→"gt"), creating spurious matches. Worse, a numeric entity like"→"34" let a gibberish query that shares those digits ("zzqwxnomatch12345") match. On the Grafana graph there were 26 , 4", plus single"/>/</·/›.Fix — decode in extraction, not scoring
New
packages/parser-react/src/entities.ts—decodeEntities(text)resolves the HTML entities React decodes at render time:") and hex (") generically, with surrogate/range guards.&foobar;literally, so we never guess.extractRenderedTextdecodes JSX text and quoted attribute values (the two surfaces React HTML-decodes); JS string/template literals stay untouched because React renders{" "}literally. Decoded entities become the character React actually renders, which the normalizer then strips: →space→dropped,>/"/·→punctuation that normalizes to empty. So an entity-only component yields no discriminating match target — verified:EntitySpacer.renderedText=["\"", ">", "·", "<", "›"], zero alphanumeric tokens.The core
isLowSignal/hasMatchSignalguards (A14/A15) remain the backstop; the primary fix lives in extraction as the tracker specified.Tests
eval/fixtures/a16-html-entities— entity-onlyEntitySpacer+ realQuotaNotice. Asserts: numeric-entity token34, named-entity tokennbsp, and digit-sharing gibberishzzqwxnomatch12345(which pre-fix matched via"→"34") all declineno-signal; the real query lands onQuotaNoticeand isn't poisoned by the digit-sharing gibberish.Verification
pnpm eval→ 304 pass · 0 fail · 0 xfail · 0 unexpected-pass, gate OK, all metrics 1.000.pnpm test→ all packages green (core 59, parser-react 136, agent-sdk 19, mcp 6, cli 5, vision 3).pnpm -r typecheck→ clean.TRACKER 6F.10 marked done;
docs/failure-modes.mdA16 already documented. Only 6F.6 (test-coverage, data-blocked) remains in phase 6F.🤖 Generated with Claude Code