ResolveNumPrFromStyle drops child-style ilvl when numId is inherited via basedOn

[skyeanything]

Summary

ResolveNumPrFromStyle (src/officecli/Handlers/Word/WordHandler.StyleList.cs) resolves a paragraph's effective numbering by walking the basedOn style chain, but it treats numId and ilvl as a single unit. When a child style declares only w:ilvl and inherits w:numId from its basedOn parent, the walk skips the child (it has no numId) and returns the parent's (numId, ilvl) — silently discarding the child's ilvl.

Repro

A common Word-generated multilevel list linked to heading styles:

• style 2 (heading 1): numPr = <w:ilvl val="0"/><w:numId val="1"/>
• style 3 (heading 2): basedOn=2, numPr = <w:ilvl val="1"/> — no numId, inherited from style 2
• style 4 (heading 3): numPr = <w:ilvl val="2"/><w:numId val="1"/>

A paragraph with pStyle=3 should resolve to (numId=1, ilvl=1).
But officecli get <doc> /body --json reports numLevel=0 for it (the parent's ilvl), not 1.

Impact

Everything relying on ResolveNumPrFromStyle: paragraph numLevel emission (get /body), HtmlPreview rendering, Navigation counters. A downstream consumer that computes numbering values from numId+numLevel gets the wrong level, so all H1/H2 collapse onto one counter and values come out wrong.

Root cause

In the basedOn walk, the first style with a non-null numId is returned wholesale as (numId, ilvl). A child style that declares ilvl without numId is never consulted for its ilvl.

Confirmed still present on main (v1.0.131).

Suggested fix

Track numId and ilvl independently while walking the chain: remember the first-seen numId and the first-seen ilvl (they may come from different styles in the chain), break once numId is resolved, and return (resolvedNumId, resolvedIlvl ?? 0). The direct-numPr branch (step 1) has the same latent issue when a paragraph's own numPr carries ilvl but not numId.

[goworm]

Confirmed and fixed — the analysis was exactly right, including the latent direct-numPr case. Reproduced with your three-style shape (H1: ilvl 0 + numId 1; H2: basedOn H1, ilvl 1 only; H3: ilvl 2 + numId 1): the H2 paragraph resolved to numLevel=0 before the fix, numLevel=1 after, and the two explicit-numId styles are unchanged.

Implemented as you suggested: the basedOn walk now tracks numId and ilvl independently (first-seen value of each wins, they may come from different links in the chain), still terminating on the first resolved numId and preserving the numId=0 cancellation short-circuit. The paragraph's own bare-ilvl numPr feeds the same merge, covering the direct-numPr variant. Since everything routes through this one resolver, numLevel readback, the HTML preview and the numbering counters all pick up the fix together. Will be in the next release.

[goworm]

Fixed in v1.0.132 — numId and ilvl now inherit independently through the basedOn chain, so a child style declaring only w:ilvl keeps it while inheriting numId from its parent. Please upgrade (brew upgrade officecli / npm update -g officecli) and let us know if anything still looks off.