openup: EA model built + enriched - baseline, associations, joint design package

Windows/EA session per BUILD-CHECKLIST 0-6 (the planned human-gate path,
executed on the EA machine). Baseline built from EABase.eapx via
build-model.ps1 and verified per checklist 4: 3 actors, 12 UCs with
scenarios, 13 associations, 0 include connectors, 7 SS requirements,
12 realization packages / 36 elements; UC-08 MSS (9 steps) and UC-11
learn spell level (3 steps) match use-case-model.md verbatim.

Script fixes (defects 1-3 of the session log): PS 5.1 hashtable parse
error; realization UC lookup now accepts short and full use-case names.

Enrichment after a manual layout pass - model changes are surgical from
now on, re-running build-model.ps1 is forbidden (checklist 6):
- add-analysis-associations.ps1: 24 analysis associations per mapping
  2a (boundary-controller-entity; UC-04 boundary-entity) rendered via
  DiagramLinks without touching manual layout; 4 uses-dependencies to
  DomainError (UC-05/06/08/12 error paths, model-level)
- add-design-package.ps1: Analysis-Design/Design - joint component
  model (skara-brae-client, sb-api, sb-auth, sb-db, sb-core, sb-shared,
  sb-common; 10 dependencies, rule inward). Joint-model decision
  recorded in mapping 1: one model for server+client+common; client-
  side UC realizations are a future work item.

Markdown sources updated first (drift rule): mapping 1 tree + 2a
interactions + 3 design component model; checklist 6. Exports
regenerated from the model: use-case-model.json new,
uc-realizations.json re-exported (useCase full names, notes merged,
crossCutting added; element content verified equal to the
markdown-to-json generator output).

Open: XMI backup - ExportPackageXMI fails via COM (DISP_E_TYPEMISMATCH,
PS 5.1 + cscript); manual EA UI export per model/README.md option 2.

docs/openup/analysis-design/uc-realization-mapping.md

@@ -16,10 +16,18 @@ Model: Skara Brae
 │   └── Supplementary Specifications (from requirements/supplementary-specifications.md)
 └── Analysis-Design
     ├── Architecture Overview       (crate/layer diagram, dependency rule)
-    └── UC-01 Realization … UC-12 Realization   (one package per UC: analysis classes,
-                                                  design elements, realization table below)
+    ├── UC-01 Realization … UC-12 Realization   (one package per UC: analysis classes,
+    │                                               design elements, realization table below)
+    └── Design                      (component model of the joint architecture — server
+                                    crates + skara-brae-client + skara-brae-common; §3)
 ```
 
+Joint-model decision (2026-10-03): one EA model covers the whole product — server, client
+and common — because the use cases are player-facing and Requirement→realization
+traceability spans tiers. Client-side UC realization packages (Vue boundary elements per
+UC) are a future work item: no markdown source exists yet; they are NOT invented here.
+Today the client enters the model via the §4 component model only.
+
 ## 2. UC realization mapping (analysis classes → design elements)
 
 Legend — **Analysis class** (OpenUP stereotype): `«controller»`, `«entity»`, `«boundary»`. **Design element**: crate::module::item (Rust). "WI-2" marks elements introduced or re-homed by this work item; everything else exists at 899fde8.
@@ -67,7 +75,76 @@ Cross-cutting design elements (WI-2): `sb-core::error::DomainError` + `sb-api::r
 
 Dependency rule check (Clean Architecture): all controllers/entities above live in `sb-core`/`sb-shared` (domain side, no HTTP imports); all boundaries live in `sb-api`; the single current violations (ShopService, HealingService, parts of MagicService in sb-api) are recorded as debt with a follow-up question — the model must not paper over them (stale docs are defects).
 
-## 3. Research summary — keyfob-station EA pipeline (reference)
+### 2a. Analysis interactions (associations + dependencies, added 2026-10-03)
+
+Within each realization package the analysis classes collaborate per the robustness rule
+boundary ↔ controller ↔ entity (boundary never touches entity directly — exception: UC-04
+has no controller, its boundary reads the static catalogue entity). Each association serves
+the UC's Basic Path steps (boundary receives the actor request, controller applies the
+rules, entities hold the state). Cross-cutting: the four `«uses»` dependencies realize the
+error paths (Alternate/Exception flows) named in the cross-cutting paragraph above.
+
+| UC | From | To | Type | Serves |
+|---|---|---|---|---|
+| UC-01 | AuthBoundary | AccountRegistry | Association | MSS steps 1–4 |
+| UC-01 | AccountRegistry | UserAccount | Association | MSS steps 3–4 |
+| UC-02 | TokenService | Authenticator | Association | MSS steps 1–3 |
+| UC-03 | CharacterCatalog | CharacterFactory | Association | MSS (create) steps 1–4 |
+| UC-03 | CharacterFactory | Character | Association | MSS steps 3–4 |
+| UC-03 | CharacterFactory | ResourceRegenerator | Association | list/view (regen on return) |
+| UC-04 | CatalogueBrowser | GameData | Association (no controller in this realization) | MSS steps 1–2 |
+| UC-05 | GymBoundary | TrainingService | Association | MSS steps 1–5 |
+| UC-05 | TrainingService | TrainingGrounds | Association | MSS steps 3–4 |
+| UC-06 | EquipmentBoundary | EquipmentService | Association | MSS (equip) + unequip |
+| UC-06 | EquipmentService | Equipment/Inventory | Association | MSS steps 2–3 |
+| UC-07 | ShopBoundary | ShopService | Association | MSS (buy) + sell |
+| UC-07 | ShopService | ShopStock | Association | MSS steps 3–4 |
+| UC-08 | AdventureBoundary | AdventureService | Association | MSS steps 1–9 |
+| UC-08 | AdventureService | CombatEngine | Association | MSS step 5 |
+| UC-08 | AdventureService | Combatant | Association | MSS step 5 |
+| UC-08 | AdventureService | SpellEffect / BardSong | Association | MSS steps 5, 8 |
+| UC-09 | TempleBoundary | HealingService | Association | MSS steps 1–3 |
+| UC-10 | SongBoundary | SongService | Association | MSS steps 1–2 + clear |
+| UC-10 | SongService | BardSong | Association | MSS steps 1–2 |
+| UC-11 | MagicBoundary | MagicService | Association | view + learn + activate |
+| UC-11 | MagicService | Spell | Association | learn + activate steps |
+| UC-12 | ReviewBoundary | ReviewBoard | Association | MSS steps 1–3 |
+| UC-12 | ReviewBoard | Progression | Association | MSS step 2 |
+
+The authoritative connector count is **24 associations** (UC-01:2, UC-02:1, UC-03:3,
+UC-04:1, UC-05:2, UC-06:2, UC-07:2, UC-08:4 — its realization has one boundary, one
+controller and three entities, UC-09:1, UC-10:2, UC-11:2, UC-12:2) plus **4 cross-cutting
+dependencies** below — 28 connectors in total.
+
+| UC | From (controller) | To | Type | Serves |
+|---|---|---|---|---|
+| UC-05 | TrainingService | DomainError (Architecture Overview) | Dependency «uses» | Alternate flows (error paths) |
+| UC-06 | EquipmentService | DomainError (Architecture Overview) | Dependency «uses» | Alternate flows (error paths) |
+| UC-08 | AdventureService | DomainError (Architecture Overview) | Dependency «uses» | Exception (unknown enemy → 500) |
+| UC-12 | ReviewBoard | DomainError (Architecture Overview) | Dependency «uses» | Alternate flows (error paths) |
+
+## 3. Design component model (joint architecture, added 2026-10-03)
+
+Package `Analysis-Design / Design` — components of the three repos and their dependency
+rule (sources: design note §2–3, mapping §2 dependency paragraph, client repo @ 34dc02f,
+common repo @ wi-2-openup-docs). Every component note carries the UCs it serves.
+
+| Component | Kind | Notes (traceability) |
+|---|---|---|
+| skara-brae-client | Component (presentation tier) | Vue 3.5 SPA (TypeScript, Pinia, Vite); monolithic App.vue @ 34dc02f; JWT bearer; REST via Vite proxy to :8080. Serves UC-01…12 as the player-facing boundary. |
+| sb-api | Component (boundary/adapter) | Axum routes/handlers, `domain_status`, `responses` (wire-format freeze). May import sb-core, sb-shared, sb-common, sb-db, sb-auth (design §3). Serves all UC boundaries per §2. |
+| sb-auth | Component (adapter) | argon2 hashing + JWT (UC-01/02). Imports sb-shared. |
+| sb-db | Component (adapter) | persistence via `sb-db::Database`. Imports sb-shared. |
+| sb-core | Component (domain) | controllers/entities: adventure (UC-08), services (UC-05/06), character (UC-03/12), combat, spells (UC-11), songs (UC-10), data/items (UC-04). Must not reference axum/http/serde_json::json!/tokio/sb-db/sb-api (design §3). |
+| sb-shared | Component (domain types) | `User`, `Character`, `Item`, response types. Zero HTTP imports. Entities of all UCs. |
+| sb-common | Component (data) | bilingual data package: data/ JSON (items, enemies, spells, zones), rust/ crate, ts/ package, codegen/. UC-04 data source; consumed by sb-core + sb-api; future client codegen. |
+
+Dependencies (arrows = depends on): skara-brae-client → sb-api (REST/JSON);
+sb-api → {sb-core, sb-shared, sb-db, sb-auth, sb-common}; sb-core → {sb-shared, sb-common};
+sb-db → sb-shared; sb-auth → sb-shared. The dependency rule: inward toward
+sb-core/sb-shared (domain); adapters (sb-api/sb-db/sb-auth) and the client at the edge.
+
+## 4. Research summary — keyfob-station EA pipeline (reference)
 
 Source: read-only clone `http://192.168.1.10:3000/jan/keyfob-station.git` (inspected 2026-10-03; no modifications).