Repository navigation
fix(core): webfetch HTML→Markdown renumbers hex-spelled ordered lists — bare parseInt reads start="0x10" as item 16 instead of 0 #743
Description
Problem
The HTML→Markdown converter used by webfetch reads an ordered list's start and an item's value with a bare Number.parseInt(...) (no radix). parseInt auto-detects a 0x prefix as hexadecimal, so a hex-spelled attribute is reinterpreted as a hex number — while HTML's own integer parsing (optional sign, then ASCII digits only, stop at the first non-digit) reads the same attribute as 0. The converted markdown silently renumbers the list.
Evidence (verified this run, 2026-10-28)
packages/core/src/tool/html-markdown.ts:403—const start = Number.parseInt(attributes.start ?? "1")(no radix argument).packages/core/src/tool/html-markdown.ts:411—const value = Number.parseInt(attributes.value ?? "")(no radix argument).- Laptop probe (probe dir
~/git/fleet/probe-2026-10-28-htmlmd/on the laptop; imports the realconvertHTMLToMarkdownfrom the laptop clone, whosehtml-markdown.tssha25649333c55…is byte-identical to sandbox mainb0633cc697; run with bun frompackages/core):- control
<ol start="3">→"3. a\n\n4. b"✓ <ol start="0x10">→"16. a\n\n17. b"— HTML parsing reads0x10as 0, so a browser renders this list starting at 0<ol start="-0x10">→"-16. a\n\n-15. b"— HTML parsing reads it as 0 (-0)<ol><li value="0x20">→"32. a\n\n33. b"— HTML parsing reads0x20as 0- controls that agree either way:
start="1e2"→ 1,start="08"→ 8
- control
- The converter is the webfetch path:
packages/core/src/tool/plugin/webfetch.ts:9importsconvertHTMLToMarkdownfrom this module, so fetched pages reach the model with the renumbered lists. - Dedup: searched open/closed issues for
parseInt, "ordered list",htmlparseron 2026-10-28 — fix(tui): editor SSE and IDE lock-file ports parsed with bare parseInt — malformed values silently connect to the wrong port #246 covers TUI editor/IDE ports parsed withparseInt, a different surface; nothing covers html-markdown list numbering.
Why it matters
Webfetch output is ground truth the model reasons from. A page whose list is numbered from 0 (or whose items carry explicit values) comes back numbered from 16/32 instead, with no error anywhere — cross-references in the page text ("see step 16") then point at the wrong items, and quoted numbering is silently corrupted.
Acceptance criteria
-
start/valueattributes are parsed with HTML integer grammar (optional sign + decimal digits; trailing non-digits ignored the way the HTML parser ignores them), never radix auto-detection:0x10→ 0,-0x10→ 0,0x20→ 0. - Ordinary values are unchanged:
start="3"→ 3,start="08"→ 8,start="1e2"→ 1, negative decimal starts keep working, and a missing/unparseablestartstill defaults to 1 while an unparseablevaluestill leaves the counter untouched. - New tests in the html-markdown test set pin the hex-spelled
startandvaluecases plus the decimal controls. - No change to unordered lists, nested-list counters, or the markdown byte budget behaviour.
Activity
dezren39 commentedon Oct 28, 2026
🤖 Agent note · filed
b0633cc697thatpackages/core/src/tool/html-markdown.ts:403,411parseol start/li valuewith bareNumber.parseInt(no radix), so0x-spelled attributes are read as hexadecimal while HTML integer parsing reads them as 0. Laptop probe of the realconvertHTMLToMarkdown(module sha256 identical to main):start="0x10"→ items 16/17,start="-0x10"→ -16/-15,value="0x20"→ 32/33; controlsstart="3","08","1e2"correct.packet-743.json(repo-health-opencode-pilot, small_fix); probe~/git/fleet/probe-2026-10-28-htmlmd/(laptop); evidence bodyhidden_files/issue-opencode-htmlmd-list-hex-body.mddeveloping-today commentedon Oct 28, 2026
OPENCODE-155
dezren39 commentedon Oct 28, 2026
🤖 Agent note · parked on CI
2a6acf8ba1packages/core/src/tool/html-markdown.ts—ol start/li valuenow parse via aparseHTMLIntegerhelper (HTML integer grammar: optional sign + decimal digits, stop at first non-digit), so0x10→ 0,-0x10→ 0,0x20→ 0 instead of 16/-16/32. Missing/unparseablestartstill defaults to 1; unparseablevaluestill leaves the counter untouched.~/git/fleet/2003-743-html-int):bun test test/tool-webfetch.test.ts89 pass / 0 fail (incl. new hex-spelled + decimal-control test),bun test test/tool-html-markdown-budget.test.ts9 pass / 0 fail, core typecheck clean.dezren39 commentedon Oct 28, 2026
🤖 Agent note · merged
fe5c15758c6acf1357e50ace9ba47e2d9161079d; this issue closed by the PR.packages/core/src/tool/html-markdown.ts,packages/core/test/tool-webfetch.test.ts), and no html-markdown/webfetch test appears in either unit run's failures. Merged per the standing merge directive after verifying the change itself is sound.