docx: `batch` drops the dangling-style warning (stdout, --json, MCP); the resulting pStyle passes validate and view issues

[r3vs]

Summary

add --prop style=Heading1 on a freshly created .docx emits

WARNING: style 'Heading1' not found in styles part — will be referenced as-is

but batch drops that warning on every output channel — plain stdout, --json, and MCP. Since the skills instruct agents to prefer batch for 3+ mutations, and MCP callers only ever see the envelope, the recommended path is exactly the one where the warning is invisible.

The resulting document carries <w:pStyle w:val="Heading1"/> against a styles part that only defines Normal. Word renders it as body text: no heading, no outline, no TOC entry. Nothing downstream catches it — validate reports clean, view issues does not flag it, and view outline actively displays the paragraph as a heading.

Environment

• officecli 1.0.145 (win-x64), Windows 11
• officecli create <f>.docx produces a styles part defining only w:styleId="Normal"

Reproduction

officecli create t.docx
officecli batch t.docx --commands '[{"command":"add","parent":"/","type":"paragraph","props":{"text":"Title","style":"Heading1"}}]'
# -> [1] Added paragraph at /body/p[@paraId=00100000]
# -> Batch complete: 1 succeeded, 0 failed, 1 total
#    (no warning)

officecli close t.docx
officecli raw t.docx /styles   | grep -o 'w:styleId="[^"]*"'   # -> only w:styleId="Normal"
officecli raw t.docx /document | grep -o '<w:pStyle w:val="[^"]*"' # -> <w:pStyle w:val="Heading1"
officecli validate t.docx      # -> Validation passed: no errors found.
officecli view t.docx issues   # -> does not mention the dangling style
officecli view t.docx outline  # -> shows: [1] "Title" (Heading1)

Where the warning survives and where it does not

Path	Warning surfaced
add (plain)	yes, stdout
add --json	yes, in warnings[]
MCP, single add	yes, in the text content
batch (plain)	no
batch --json	no — the envelope has no warnings key at all
MCP, batch	no

add --json returns:

{
  "success": true,
  "data": "Added paragraph at /body/p[@paraId=00100000]",
  "warnings": [
    { "message": "WARNING: style 'Heading1' not found in styles part — will be referenced as-is", "code": "warning" }
  ]
}

batch --json for the equivalent operation returns data.results[] with only index / success / output, and no warnings key on either the per-item object or the envelope.

Why this matters

SKILL.md and the MCP tool description both say: "For 3+ mutations on the same file, use batch (one open/save cycle) instead of separate calls." Any document built the recommended way loses the warning. The mandated delivery gate — validate clean, then view issues clean — then passes the file, so an agent reports a finished document whose headings are inert.

Cross-checked with an independent converter (anydoc): the paragraph converts to plain text, not # Title. After defining the style first it converts to # Title, which confirms the reference is the only thing wrong.

Related

• ## [ENHANCEMENT] Invalid number-format warning is stderr-only, not surfaced in JSON/MCP responses #198 threaded warnings into the JSON envelope for single commands (the warnings[] array above is that work). batch's envelope appears never to have received the same treatment.
• [BUG] xlsx: remove sheet leaves dangling localSheetId in definedNames — file unreadable, validate passes #243 is the same shape in xlsx — a dangling reference that validate passes.

Suggested fix

Two independent parts, either of which alone removes the silent failure:

1. Propagate warnings through batch. Collect per-item warnings and emit them on stdout, in a warnings array on each results[] entry (and/or the envelope), and through the MCP text content — matching what a single add already does.
2. Flag the dangling reference downstream. A pStyle / rStyle whose w:val has no matching w:styleId in the styles part is a defect the document carries after the fact, so validate or view issues should report it regardless of how it got there. view outline should probably not present such a paragraph as a heading.

Worth considering separately: create could seed the built-in heading styles, or --prop style=Heading1 could materialize the definition on demand. The schema for paragraph.style gives --prop style=Heading1 as its first example, which reads as a supported built-in on a blank document.

Workaround

Define the style before referencing it:

officecli add t.docx /styles --type style --prop id=Heading1 --prop name="heading 1" --prop type=paragraph --prop bold=true --prop size=20pt
officecli add t.docx / --type paragraph --prop style=Heading1 --prop text="Title"