view issues almost replaces whole-document HTML previews for automated audits — two gaps: xlsx numeric-fit (###) and pptx layout/spacing checks

[PeterZZZ]

Summary

LLM-driven callers (we embed OfficeCLI in MemVerge/MemBox) audit every generated
document before delivering it. The audit needs machine-checkable findings, and
view <file> issues is exactly the right surface: short, and every finding
carries a path and a suggested fix.

Today two families of checks are not in ViewAsIssues, which forces callers to
fall back on whole-document view html dumps. Those are token-expensive for an
LLM caller and get truncated by output caps — and for the most important xlsx
check the fallback does not even work (details below). Both gaps are arithmetic
on data the handlers already parse.

Measured with the v1.0.143 release binary on examples/budget_review_v2.pptx
(8 slides):

Mode	Bytes
view html	107,875
view annotated	4,761
view issues	1,465 (13 findings, each with a path + suggested fix)
view outline	434

Our runtime caps tool output at 64 KiB per stream, so the HTML "ground truth"
arrives truncated at real document sizes; view issues is both ~70× smaller and
more actionable.

Version

• Behavior measured on the v1.0.143 release binary (macOS arm64).
• Source line references are from main at 459b1a47.

Part 1 — xlsx: a numeric-fit (###) check in ViewAsIssues

### is the highest-signal rendering defect in a delivered workbook: Excel
shows it whenever a numeric or date column is too narrow for its formatted
value. Today no OfficeCLI surface can detect it:

1. OfficeCLI never emits ### — it is an Excel rendering behavior, not file
   content.
2. The HTML preview deliberately does not emulate it. GetSpillWidthPt
   reproduces Excel's text behavior only — spill across empty neighbours and
   shrink-to-fit — and bails on numbers explicitly:
   "(a) Must be text/general — NOT a number and NOT a numeric formula result.
   Excel right-aligns numbers and never spills them."
   (src/officecli/Handlers/Excel/ExcelHandler.HtmlPreview.cs, ~line 988)
3. CheckAllCellOverflow skips it by design: "Skips overflow-right on
   non-wrapText cells — that is Excel's normal rendering, not a bug"
   (src/officecli/Handlers/Excel/ExcelHandler.CheckOverflow.cs, header
   comment). Correct for text, which spills; wrong for numbers, which render
   as ###.

So an automated caller reading the HTML preview is scanning for a marker that
is never present.

The pieces already exist. The renderer holds per-column widths in points
(SheetRenderContext.ColWidths) and a glyph-advance text-width model —
"chars × fontPt × 0.62" — used by both the spill and shrink-to-fit paths
(ExcelHandler.HtmlPreview.cs, ~line 1044). A numeric-fit check is the same
comparison with spill disallowed:

for each numeric/date cell: if formatted-value width (glyph model) >
column width and the cell is not shrinkToFit → report.

Suggested finding shape, matching the existing issues format:

[N1] /Sheet1/H7: numeric overflow: '1,234,567.00' at 11.0pt needs 14.2 width, col H is 8.43. suggest.width=15

Part 2 — pptx: layout/spacing checks in ViewAsIssues

PowerPointHandler.ViewAsIssues (PowerPointHandler.View.cs, ~line 515)
already computes the hard geometry checks — text overflow (CheckTextOverflow),
off-slide shapes with cm distances, occlusion (text ≥20% covered by a later
opaque shape), low contrast (fill <30% brightness with text <80%), table
row/grid mismatches. That is most of a professional deck audit already.

The remaining checks a deck audit needs are all arithmetic on coordinates and
text the handler already parses per shape:

• narrow text box — content fits but wraps to many short lines
  (wrap-line-count estimate from the existing text-width model).
• tight margin — element closer than ~0.5" to a slide edge (the off-slide
  check already computes edge distances; this is the same math with a positive
  threshold).
• tight gap — two sibling boxes closer than ~0.3".
• uneven gaps — one large empty region while another side is cramped
  (variance over the gaps between siblings on the same axis).
• column / repeat-element misalignment — shapes that look like a row/column
  of cards but are off baseline or of inconsistent width beyond a tolerance.
• missing arrowheads — connectors between shapes with no head/tail end
  decoration (reads as a plain line in a flowchart).
• decorative-line / title mismatch — an accent bar sized for a one-line
  title under a title that wrapped to two lines (or vice versa).
• footer / citation collision — footer, source line or page number whose
  box intersects content above it (the occlusion pass already does rectangle
  intersection).

Thresholds could ship as defaults (possibly at a distinct severity, or behind
--issue-type layout) so existing consumers of view issues are unaffected.

Why this matters upstream rather than just to us

Any automated or LLM-driven consumer of OfficeCLI has the same shape of
problem: view html is the only whole-document render, it is large, and it is
the only place several of these defects are (partially) visible. Moving the
checks into view issues makes them cheaper, deterministic, and available to
every caller — and each finding arrives with a path and a suggested fix in the
format view issues already established.

Context: MemVerge/MemBox#2880 (token-amplification report that surfaced this)
and MemVerge/MemBox#2909 (our side: the audit gates now drive on
view issues + annotated + get; we kept the docx HTML-preview gate because
docx ViewAsIssues currently reports only empty-paragraph / first-line-indent /
consecutive-spaces findings — a richer docx view issues would let us drop
that one too, but the xlsx and pptx parts above are the high-payoff pieces).

Happy to split this into two issues (xlsx / pptx) if that fits your tracker
better.

[goworm]

Part 1 is in — #323 landed a numeric_overflow subtype for explicit numeric/date formats that can't fit their column. Follow-up 6948ea81 adds general_precision_loss for a case that scan skips: General caps at 11 significant digits and falls back to scientific notation regardless of width, so a 12+ digit number renders as 1.23457E+11 and widening doesn't fix it — the suggestion there is a number format.

pptx layout/spacing checks are still open.