Offline Office Editor

Overview

The C:/office project is a single-page, zero-backend Office editor. Three editors
(Excel grid, Word page, PPT stage) share one index.html + per-format engine
(excel.js, word.js, ppt.js). A build step inlines every library and script
into office-standalone.html (≈5.7 MB) so it runs by double-clicking — no
server, no CDN, no network.

The hard part is not the UI; it is making Excel/Word/PPT files round-trip
correctly. SheetJS (libs/xlsx.full.min.js) reads/writes the zip/XML but silently
drops many features (conditional formatting, comments, data validation, charts,
styles, freeze panes, hyperlinks). The project's solution is a OOXML post-processing
layer: SheetJS produces a baseline file, then small injectXxx functions rewrite
specific XML parts (worksheet, rels, [Content_Types].xml) to add what SheetJS
missed; reverse readXxx functions parse those parts back on open. Regression is
guaranteed by a jsdom harness that loads the real engine and asserts behavior.

When to use this skill

• The user asks to add/fix any feature in the C:/office editors.
• Any task to generate or edit .xlsx / .docx / .pptx offline, especially:
  conditional formatting (color scale, data bar, formula/cellIs rules), formula
  engine (absolute/cross-sheet refs, VLOOKUP/HLOOKUP/MATCH/INDEX/IFS), cell
  comments, data validation, charts, hyperlinks, freeze panes, row/column
  insert/delete, merged cells, custom styles.
• When writing or debugging the jsdom regression tests for these features.

Core architecture (read this before editing)

Keep one mental model — it is the same for every feature:

• Single source of truth = plain JS structures, NOT the OOXML. For Excel:
  data is a 2D array (ROWS × COLS); everything else is a parallel Map or
  array keyed by r + ',' + c (per-cell: styleMap, fmtMap, commentMap,
  borderMap, hyperlinks) or by a range/{r1,c1,r2,c2} (conditional
  formatting cfRules, data validation dvRules, merges). Word/PPT use analogous
  sheets[]/elements[] structures.
• The editor renders from these structures (renderCell, renderAll). The
  file format is a serialization of them, never the source.
• Two chain functions own the file boundary:
• Save: buildAndSaveBuffer() → produces a Blob. Feature logic lives in
  injectXxx(zip, sheetsArr) helpers (see references/ooxml_paradigm.md).
• Open: openWorkbook(buf) → reads via SheetJS for cell values, then calls
  readXxx(buf) helpers to recover dropped features into the JS structures.
• Test/debug hooks: window.__excelDeep exposes internals
  (setCellValue, getCfRules, addCfRule, cfMatchCell, renderAll,
  saveToBuffer, openWorkbook, evaluate, …). The jsdom harness drives these
  to test real engine behavior without a browser.

Workflow: adding a new Excel feature

1. Model it. Add the field to the per-cell Map or to cfRules/dvRules/
   sheets[]. Decide the in-memory shape first (e.g. a CF rule is
   {r1,c1,r2,c2,type, ...}).
2. Render it in renderCell/renderAll (and add CSS in styles.css).
   Text must always stay above overlay elements — give .cell-input
position:relative; z-index:1 and overlays (cf-bar, markers) a lower
   z-index with pointer-events:none.
3. Export it via an injectXxx function that rewrites the OOXML part, and
   wire it into buildAndSaveBuffer at the right CT_Worksheet child order.
4. Import it via a readXxx function parsing the same part; wire into
   openWorkbook (wrap in try/catch — a missing part must not break open).
5. Expose hooks on window.__excelDeep so the harness can set state and
   read state.
6. Write a regression test _excel_<feature>_test.js (see
   references/regression_harness.md and scripts/regression_harness.js).
7. Rebuild + smoke: node build-standalone.js, then run
   _standalone_smoke.js to confirm 0 load-time errors.

OOXML inject/read paradigm (the non-obvious core)

This is the most important reusable knowledge. Full code patterns, buffer-type
rules, [Content_Types].xml override mechanics, rels wiring, and a worked
conditional-formatting example live in references/ooxml_paradigm.md. Read it
before writing any injectXxx/readXxx function. Key rules (do not skip):

• Injectors take a JSZip instance and return an arraybuffer (NOT a Blob) so
  the next injector can JSZip.loadAsync it. Only the final buildAndSaveBuffer
  wraps the last buffer in new Blob([out]).
• Always pair escapeXml with unescapeXml when round-tripping formulas or any
  text containing <, >, &, " (e.g. >A1>10< in a CF formula).
• Keep the model type names distinct from the OOXML type names. Example: the
  in-memory CF rule uses type:'scale'|'bar'|'formula', while the OOXML
  <cfRule type="colorScale"|"dataBar"|"expression">. Map both directions; a
  mismatch silently drops the rule on save.
• XLSX.write(..., {cellStyles:true}) then JSZip.loadAsync the array result.

jsdom regression harness

Every feature ships with a test that loads the real engine in jsdom and asserts
behavior (including full save→reopen round-trips). The template, the exact
NODE_PATH, the jsdom ^24 pin, and the two classic harness bugs (un-awaited
async in setTimeout; || -1 turning a legitimate 0 into -1) are detailed in
references/regression_harness.md and the ready-to-copy
scripts/regression_harness.js.

Resources

• references/ooxml_paradigm.md — save/read chain, buffer types, Content_Types
  overrides, rels, worked conditional-formatting + comments examples.
• references/regression_harness.md — jsdom harness template, env setup, gotchas.
• scripts/regression_harness.js — copy-paste harness skeleton for a new test.