# 0.9.0-A round-trip validation — status

See `0.9.0-A_results.json` for the machine-readable detail this summarizes.

## What's verified

All 5 fixtures, authored in real Microsoft Excel for Mac (16.108), edited via elixcee,
saved both ways (save-as and in-place), reopened in real Excel:

| fixture | content | VBA | result |
|---|---|---|---|
| 1 | values, formula, style, merge, hidden row/col | no | clean, formula recalculated live to correct value |
| 2 | VBA macro | yes | clean; macro *execution* not evaluated (see below) |
| 3 | table, data validation, conditional formatting | yes (incidental) | clean; all three silently dropped (known gap) |
| 4 | hyperlink, comment, defined name | yes (incidental) | clean; all three silently dropped (known gap) |
| 5 | chart, image, print area | no | clean; chart/image/print-area silently dropped (known gap) |

**No repair warning, no "cannot open" error, no `vbaProject` loss, no relationship
breakage, no in-place-save failure — for any of the 5 fixtures, either save mode.**

**Excel-authored `.xlsm` save, reopen, and structural preservation are verified against
real Excel. Macro re-execution after a save is NOT verified** — see the dedicated section
below. Do not describe this round as having verified macro compatibility, or as having
confirmed VBA still works post-save.

## Bugs found and fixed this round

All three found by fixture 1 specifically — none of the pre-existing hand-built Rust test
fixtures happened to include a formula cell, a theme part, or a non-macro `.xlsm` output,
so nothing caught them until real Excel refused to open the file.

1. **Formula flattening** (`de2ee3f`) — every untouched formula cell silently lost its
   formula on save. `ELIXCEE_DATA_LOSS`.
2. **Orphaned relationships** (`1ea4066`) — `xl/theme/theme1.xml` and
   `docProps/{app,core}.xml` passed through byte-identical but their relationships were
   dropped from the regenerated `.rels` files. `ELIXCEE_RELATIONSHIP_BREAK`.
3. **Wrong `.xlsm` content type** (`1ea4066`) — the dominant cause of the "cannot open"
   error: a non-macro `.xlsm` output declared the plain (non-macro) content type instead
   of the macro-enabled one the `.xlsm` extension requires, regardless of content.

All three fixed, covered by new Rust regression tests (`cargo test --workspace`: 828+
passing) and `mechanical_check.py`'s self-test (7 negative-calibration cases).

## Known gap confirmed, not a new bug

Fixtures 3, 4, and 5 all hit the **same root cause**: `build_xlsx_sheet` fully regenerates
`xl/worksheets/sheetN.xml` from `Vm`'s cell state on every save, and only knows how to
emit `<cols>`/`<sheetData>`/`<mergeCells>`. Anything else embedded in worksheet XML —
tables, data validation, conditional formatting, hyperlinks, comments — is silently
dropped. `xl/workbook.xml` being fully regenerated the same way also drops defined names.
The underlying *part* (e.g. `xl/tables/table1.xml`, a chart, an image) usually survives as
inert bytes, orphaned rather than deleted.

**This was already disclosed** in the 0.8.0 safe-round-trip milestone's own Non-goals
section ("anything embedded in a regenerated `xl/worksheets/sheetN.xml` does not
survive"). 0.9.0-A's real-Excel testing didn't discover a new defect here — it confirmed,
with concrete real-Excel evidence, exactly what was already documented as out of scope,
and confirmed the important secondary fact: **none of this causes a repair warning**.
Excel just silently has less content than before.

Fixing this is real feature work — re-injecting known worksheet-embedded elements into the
regenerated XML, or moving to a diff/merge writer instead of full regeneration — matching
the scope of a future milestone, not attempted this round.

**Addendum, 2026-08-23 (0.10.0-A):** the "orphaned rather than deleted" description above
is now backed by a dedicated automated check —
`compat/oracle-excel-com/mechanical_check.py`'s `check_source_references()` — which
formalizes the r:id-bearing subset of this gap (table/drawing/hyperlink/vmlDrawing) as a
named verdict, `SOURCE_REFERENCE_LOSS`, distinct from the pre-existing `ORPHANED_PART`/
`DANGLING_RELATIONSHIP` verdicts. Re-running it against fixtures 3, 4, and 5 reproduces
`SOURCE_REFERENCE_LOSS` in all three (fixtures 1/2, which have no worksheet-level
relationships, correctly report `CLEAN`). This is not a new bug and not a change in
elixcee's behavior since this file was written — only a more precise, automated
restatement of what this section already disclosed in prose. See
`docs/xlsx-worksheet-preservation-0.10.0-design.md` and
`fixtures/pristine/INVENTORY.md` for the full design.

## Macro execution: not evaluated — neither a pass nor a fail

Running `fixture2`'s macro fails with "Microsoft Visual Basic: license information for
this component was not found" — reproduced **identically from Excel's own Macro dialog
(⌥F8), against the untouched original file, before elixcee ever touched it.**

Diagnostic facts, offered without a root-cause conclusion: not a `codeName`/binding issue
(the macro resolves and lists correctly in the Macro dialog); not specific to external
`run VB macro` invocation (fails from inside Excel's UI too); the same error reproduces on
a file elixcee never wrote. This is the same class of unexplained instability the prior
session's `MACOS_APPLESCRIPT_EXPLORATION.md` already flagged and left unresolved.

**This result must not be reported as either a success or a failure for elixcee.** It does
not confirm elixcee's round-trip broke macro execution, and it does not confirm elixcee's
round-trip preserves working macros. It is simply unevaluated — an open gap in the
evidence, not a passed check absorbed into "0 macro execution failures." Not chased
further this round; flagged for a fresh environment/session per
`MACOS_APPLESCRIPT_EXPLORATION.md`'s own recommendation.

## Harness

- `compat/oracle-excel-com/mechanical_check.py` — structural OOXML validator (ZIP entries,
  content-types, relationship completeness in both directions, vbaProject byte-identity)
  plus a semantic formula-preservation check. Self-test corrupts 7 different ways before
  trusting any real result.
- `compat/oracle-excel-com/fixtures/{pristine,work}/` — pristine fixtures committed,
  read-only; `work/` (gitignored) is where every actual test run edits/saves.

## The 10-consecutive-cycle requirement: superseded, not met literally

Every fixture ran 1 cycle per save mode. Fixture 1 additionally ran a **5-cycle chained
in-place stress test** — the same file edited and saved in place 5 times consecutively
(not 5 fresh copies), a stricter check than 5 independent cycles since any
accumulating-corruption bug (XML/ZIP degradation across repeated regeneration, cumulative
style/merge/formula loss, an in-place-overwrite bug that only surfaces on the second write)
would compound. `mechanical_check.py` reported clean after every one of the 5 cycles, and a
real Excel reopen after cycle 5 confirmed values, the live-recalculated formula, and the
merge were all still correct.

**Decision: this is judged sufficient evidence in place of running all 5 fixtures to the
full 10 cycles.** A writer bug that survives 5 identical chained saves clean and only
manifests on cycle 6–10 is possible but judged low-probability and low-value to chase
mechanically; the next-highest-value work is different worksheet-feature coverage
(`0.10.0`), not more repetitions of the same fixture. This is recorded as a superseded
exit criterion, not a met one — the literal "10 or more" was not run.

## What's still open

- **AppleScript cannot create tables, data validation, conditional formatting,
  hyperlinks, or charts** — confirmed empirically (`-50` parameter errors), despite being
  documented in Excel's own `.sdef`. All 5 fixtures' non-trivial content (fixtures 2–5)
  was authored manually by the user in Excel's UI instead.
- **Macro execution verification** — see above. Not evaluated, not classified.
- **Fixture count**: 5 of the roadmap's 10+ target. Not pursued further this round.

## Status

`0.9.0-A`'s file-preservation round-trip claim is supported by concrete real-Excel
evidence: 5 fixtures, both save modes, 0 repair warnings, 0 `vbaProject` loss, 0
relationship breakage, 0 in-place-save failures, 3 real bugs found and fixed, a 5-cycle
chained stress test clean throughout. Macro execution and the full 10-cycle/10-fixture
counts remain open and should not be described as met. Version bump and `0.9.0` release
are a separate, later review.
