# docs/openup/model/ — EA Model Home (WI-2 status)

Per `design-wi-2-architecture-cleanup.md` §11 (decision reversal 2026-10-03): the binary
EA model lives here at `skara-brae.eapx` with generated exports under `exports/`; generator
scripts live in `scripts/openup/` (repo root). Markdown stays the content source of truth;
exports are generated, never hand-edited.

## Status after COD session 2 (2026-10-03, Linux agent)

| Design item (§11.b/c) | Status |
|---|---|
| §11.b.1 clone keyfob-station read-only | done — studied `add-wi19-uc11.ps1` (scenario embedding: `Name/Type/Notes/Steps` arrays with per-step `Actor`) and `export-model-json.ps1` (COM walk → JSON); patterns reused in the scripts below |
| §11.b.3 `.eapx` skeleton from EA's `EABase.eapx` | **not done — platform gap.** No `EABase.eapx` exists on this Linux machine (searched `~`, `~/.wine`, `/mnt`, `/media`, `/opt`, `/usr/local`); EA is a Win32 application. The binary is deliberately NOT committed and NOT derived from keyfob's model (it carries keyfob content). Copy it during the Windows session (see BUILD-CHECKLIST §0). |
| §11.b.4 build checklist | done — `BUILD-CHECKLIST.md` (packages, actors, use cases, scenarios, associations, realization packages — complete and clickable) |
| §11.c `build-model.ps1` / `export-model.ps1` | committed, adapted from the keyfob patterns; **Windows-gated** — this machine has no EA COM automation (and no `pwsh`), so they could not be executed here. They are prepared, not proven. |
| §11.c machine-readable intermediates | `exports/uc-realizations.json` generated (by `scripts/openup/markdown-to-json.py`, tested locally) from mapping §2 — 12 realizations, 36 elements. `exports/use-case-model.json` is **not** generated here: the markdown carries no per-step actor tags, so a faithful JSON intermediate cannot be produced mechanically. Per §11.c's recorded fallback, `build-model.ps1` embeds the scenario content as PowerShell arrays (keyfob pattern); the human gate verifies it against `use-case-model.md` via the checklist. |

## Linux constraint and the two options

The EA pipeline is PowerShell + COM automation (`New-Object -ComObject EA.App`) against a
`.eapx` (MS Access/Jet) file — Windows-only. This session ran on Linux. Options:

1. **Run the pipeline on the Windows/EA machine (planned path).** `BUILD-CHECKLIST.md`
   §0–§5 is the session script: copy `EABase.eapx` → `skara-brae.eapx`, run
   `build-model.ps1`, verify per checklist §4, run `export-model.ps1`, commit
   `.eapx` + `exports/` + `scripts/openup/` as `openup: EA model WI-2 baseline`.
2. **EA manual XML export → agent-side transform.** If the COM scripts hit friction in EA,
   export the package manually from the EA UI (`Publish → XML / XMI`), drop the file into
   `exports/`, and the agent side can transform/validate it into the JSON intermediates
   with a small local script (same role as `markdown-to-json.py`). The committed scripts
   remain the reproducible path of record.

## Drift rule

Markdown (`use-case-model.md`, `uc-realization-mapping.md`) and the model must agree;
exports are generated; a mismatch is a defect fixed in the same cycle (stale docs are
defects). The human gate (design §11.d) owns `.eapx` editing/verification — never the agent.