[BUG] pptx: add/validate accept adjust-value <a:gd> on presets without adjust handles (rect/ellipse) — PowerPoint reports file as corrupt

[jasonwei1002]

Summary

add --type shape happily writes an adjust-value <a:gd> into a preset geometry that has no adjust handles (e.g. rect, ellipse), and validate reports no errors — but PowerPoint refuses to open the file, reporting it as corrupt. This is a silent data-corruption path: all officecli-side checks stay green.

Repro (v1.0.136, macOS)

officecli create repro.pptx
officecli add repro.pptx / --type slide
officecli add repro.pptx '/slide[1]' --type shape \
  --prop geometry=rect --prop x=1cm --prop y=1cm --prop width=4cm --prop height=2cm \
  --prop text="test" --prop adj="adj:val 14000"
officecli validate repro.pptx
# -> "Validation passed: no errors found."

Resulting slide XML:

<a:prstGeom prst="rect"><a:avLst><a:gd name="adj" fmla="val 14000"/></a:avLst></a:prstGeom>

Opening this file in desktop PowerPoint triggers the "repair/corrupt" dialog.

Expected

Two layers of defense, either of which would have caught this:

1. add/set should reject adjust values whose name is not legal for the target prst (e.g. rect/ellipse accept none; roundRect/chevron/homePlate/triangle accept adj; round2SameRect and the arrow family accept adj1/adj2, etc.).
2. validate should flag existing <a:gd> entries whose name is not in the preset's avLst as defined by ECMA-376 presetShapeDefinitions.xml.

The full legal-handle table is mechanical to derive from presetShapeDefinitions.xml (each preset's <avLst> lists its gd names), so this can be a static lookup table.

Impact

High — the file passes validate, unzips fine, and renders fine in view html/screenshot, yet is unopenable in PowerPoint. Agents driving officecli have no way to detect the problem short of regex-auditing the raw XML themselves.

[goworm]

Thanks for the detailed report. We could reproduce the officecli side (the <a:gd name="adj" fmla="val 14000"/> does get written into rect's <a:avLst>, and validate stays green), but not the corruption: the exact file produced by your repro steps opens and renders normally in desktop PowerPoint on Windows in our testing — no repair dialog. That matches ECMA-376 behavior, where adjust values in <a:avLst> that don't correspond to a handle of the preset are ignored rather than treated as invalid.

To move forward, could you provide:

1. Your PowerPoint version and platform (Windows or Mac, build number) that shows the repair/corrupt dialog;
2. The actual .pptx file that triggers the dialog — ideally the original file where you first hit this, not just one regenerated from the repro commands. It's possible the corruption in your real file comes from something else and the minimized repro doesn't capture it.

With a sample that reproducibly fails to open we can pinpoint the real cause. Adding a validate-level warning for adjust names not defined by the preset is still worth considering as a lint, but we'd like to confirm the corruption mechanism first before changing add/set behavior.

[jasonwei1002]

1.macOS，PowerPoint version 16.110.3 (26070318)
2.The version regenerated by reproducing the command can also replicate the corruption issue.
repro235.pptx