@memoarchitect/ontology 0.12.0 → 0.12.1

package/README.md

@@ -23,7 +23,7 @@ pin an exact release; the package has no repository or runtime dependency on Mem
 Tools or Memo Architect.
 
 ```bash
-pnpm add @memoarchitect/ontology@0.12.0
+pnpm add @memoarchitect/ontology@0.12.1
 ```
 
 > **Pre-1.0 notice:** ontology names, relationships, and package layout may

package/examples/gpca-pump/memo.identity.yaml

@@ -461,6 +461,33 @@ elements:
   "memo_examples_gpca_pump_gpca_behavior_modes::basalConfiguration":
     shortId: "MDX-2"
     uuid: "c501579e-f7cc-568a-9e83-e54046d0fb14"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modeACTIVE":
+    shortId: "MMX-38"
+    uuid: "bbbdaf77-0e92-5dbf-8a8c-02f18f0d2857"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modeBASAL":
+    shortId: "MMX-39"
+    uuid: "7b953a4f-32f9-54cc-b909-c8188115a532"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modeIDLE":
+    shortId: "MMX-40"
+    uuid: "035e94ba-3ef4-530a-8b08-d61644cab121"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modeOFF":
+    shortId: "MMX-41"
+    uuid: "34db9680-371a-5858-9065-658612f43847"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modeON":
+    shortId: "MMX-42"
+    uuid: "48516c5a-a57a-536f-8a6f-2a4be84a82dc"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modePAUSED":
+    shortId: "MMX-43"
+    uuid: "80fdccb6-6db3-51ea-935b-5d7e739a210e"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modePBOLUS":
+    shortId: "MMX-44"
+    uuid: "9fe2a51c-3088-51a9-9581-27d8a5e49561"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modeSQUARE":
+    shortId: "MMX-45"
+    uuid: "3d52c9ef-3fb3-56be-9894-114d41350103"
+  "memo_examples_gpca_pump_gpca_behavior_modes::modeTHERAPY":
+    shortId: "MMX-46"
+    uuid: "662b3289-5569-5866-9485-d16704975f12"
   "memo_examples_gpca_pump_gpca_behavior_modes::patientBolusConfiguration":
     shortId: "MDX-3"
     uuid: "8bf0ae11-2409-5e5f-9bac-02cfd2832fc0"

package/examples/sysml-diagram-samples/README.md

@@ -33,7 +33,17 @@ accepts its decision, merge, accept/send, termination and guard syntax, and
 | `requirements_view.sysml` | `req` | general | Requirements — stakeholder needs deriving into system requirements. |
 | `use_case_view.sysml` | `ucd` | general | Use case — relationship-driven actors, include/extend links, and model-owned `usecase:level` / `edge` presentation hints. |
 | `state_transition_view.sysml` | `stm` | statetransition | State machine — pump operating modes and their triggered transitions. |
+| `sequence_view.sysml` | `seq` | sequence | Sequence — a functional flow's ordered steps, each allocated to its performing lifeline. |
+| `grid_view.sysml` | `fmea` | grid | FMEA worksheet — three FailureMode rows, one table section with columns auto-derived from their attributes. |
 
 SysML v2 standardizes the model semantics; a diagram is a presentation of those
 semantics. The Architect renderer selects the template from each view's
 `viewKind`, so the same model can be re-presented in any compatible kind.
+
+Six of the eight standard view kinds are covered above (general, interconnection,
+actionflow, statetransition, sequence, grid). `browser` and `geometry` still have
+no sample here — both are reached by an explicit `viewKind` declaration with no
+legacy `diagramType` to demonstrate one against (a document-backed view resolves to
+`browser` by default; `geometry` has no legacy mapping at all — see
+memo-tools view-kinds.ts), so each needs its own small worked example rather than
+following this table's `diagramType` pattern directly.

package/examples/sysml-diagram-samples/dashboards/README.md

@@ -0,0 +1,17 @@
+# Dashboards
+
+Markdown pages with live diagrams, opened in MEMO Architect under **Dashboards**.
+
+| Folder | Who sees it | In git? |
+| --- | --- | --- |
+| `dashboards/` | everyone on the project | committed |
+| `dashboards/user/` | only you, on this machine | ignored — listed in `.gitignore` |
+
+Each `.md` file is one dashboard; its file name is its id. Every viewpoint also
+has a generated dashboard until a file named `viewpoint-<viewpoint id>.md`
+replaces it — `viewpoint-vp-demo-ibd.md` here is a filled-in example.
+
+Embed a live, read-only diagram with a directive on its own line:
+
+    {{diagram:<view id or name>}}
+    {{diagram:<view id or name> height=640}}

package/examples/sysml-diagram-samples/dashboards/viewpoint-vp-demo-ibd.md

@@ -0,0 +1,61 @@
+---
+title: Internal Block Diagram
+viewpoint: VP-DEMO-IBD
+---
+# Internal Block Diagram
+
+A worked example of a **viewpoint dashboard**: the same page MEMO Architect
+generates for every viewpoint, with the placeholders filled in. Compare it with
+any other viewpoint's Dashboard entry, which still shows the generated prompts.
+
+> **Purpose** — Lets a design reviewer confirm, from the logical structure
+> alone, that water can only reach the cup through the heater, and that every
+> heater fault is observable from outside the machine.
+
+## Stakeholders and concerns
+
+| Stakeholder | Concern | How the views below address it |
+| --- | --- | --- |
+| Design reviewer | **Safety** — no path delivers unheated or overheated water | The machine view shows the single water path: tank → heater → brew group |
+| Service engineer | **Reliability** — faults can be diagnosed without disassembly | The heater views show heater status bound out to the service interface |
+| Firmware lead | **Performance** — the control loop is closed inside one assembly | The heater assembly view keeps the thermostat and element loop internal |
+
+These rows are commentary. To make them part of the model, set `stakeholders`
+and `framedConcerns` on `ibdViewpoint` in the viewpoint package.
+
+## Views
+
+The model currently has {{model.views}} views; three conform to this viewpoint.
+
+### Beverage machine
+
+{{diagram:beverageMachineIBD height=560}}
+
+**Commentary** — Mains water enters on `mainsWaterIn` and is *bound*, not
+flowed, to the reservoir: a delegation through the boundary is not a transfer.
+The only route to `beverageOut` passes the Thermal Control Assembly. The service
+interface nests a `diagnostics` port, which is where a fault becomes visible.
+
+### Heater assembly
+
+{{diagram:heaterAssemblyIBD}}
+
+**Commentary** — The thermostat and the heating element form a closed loop:
+power command out, heater status back in. Nothing outside the assembly drives
+the element directly, which is the property the firmware lead relies on.
+
+### Heating element
+
+{{diagram:heatingElementIBD}}
+
+**Commentary** — The coil and the temperature sensor are the element's only
+parts. The sensor reads heat, not water temperature — an assumption worth
+confirming before this structure is reused for a safety argument.
+
+## Open questions
+
+- Should the reservoir have a level sensor port, so an empty tank can inhibit heating? *Owner: design reviewer.*
+
+## Decisions and rationale
+
+- Heater status is exposed through the service interface rather than a dedicated port, so the machine boundary stays at three external ports.