plan: endgame — the whole platform (store/events/orders) as a typed domain

The metamodel targets the entire rose-ash domain model, not just the blog — the finish
line of the host-on-sx strangler off Quart: define the domain schema as data instead of
porting each service's bespoke models. Records the three honest additions store/events
surface beyond a/b/c+d: (1) typed scalar ATTRIBUTES (datatype properties: price:Money,
stock:Int) alongside entity relations — a real addition, likely Slice 8; (2) behaviour/
lifecycle composes from the substrate loops (flow/commerce/events), not reinvented;
(3) integrations (payments/federation/media) stay referenced services. Structure+validation
from the metamodel, behaviour from substrates, integrations as services.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

plans/relations-as-posts.md

@@ -36,6 +36,35 @@ Sequence: finish the schema language (Slices 6–7) → the two UI surfaces + re
 data and define a real domain through the UI. The slices below are the schema language; this is
 what it's *for*.
 
+### Endgame — the whole platform as a typed domain (the strangler's finish line)
+
+Not just the blog: the entire rose-ash platform — **store, events, orders, cart, …** — is
+expressible as type + relation definitions in this one metamodel. `Product`, `Event`, `Order`,
+`Ticket` are types; "cart has line-items", "order for an event", "ticket of an event" are
+relations with signatures (cardinality = a cart has many line-items, a ticket belongs to one
+event). This is the completion of the host-on-sx strangler off Quart (`[[project_host_on_sx]]`):
+define the domain schema as data instead of porting each service's bespoke models.
+
+Three honest additions store/events surface (the blog didn't need them):
+
+1. **Typed scalar ATTRIBUTES, not just entity relations.** A `Product` needs `price: Money`,
+   `sku: String`, `stock: Int`; these are *values*, not edges to posts. We've built RDF
+   *object properties* (edges to resources); this needs *datatype properties* (literals with
+   value-types + validation). So a type declares **fields** `{field, value-type, card, required,
+   validation}` alongside relations; instances carry typed values; value-types (`Money`, `Int`,
+   `DateTime`) are primitive types. Same shape as a role — a role points at a *type*, a field
+   holds a *value-type*. **This is a real addition to a/b/c+d** and likely Slice 8.
+2. **Behaviour / lifecycle** (order `pending→paid→shipped`) is NOT structure — it's the
+   substrate loops: `[[project_flow_on_sx]]` (durable workflows), `[[project_commerce_on_sx]]`,
+   `[[project_events_on_sx]]`. The metamodel *attaches behaviour to types by composing those*,
+   not reinventing them.
+3. **Integrations** (SumUp payments, ActivityPub federation, artdag media) — types *reference*
+   these services; they don't dissolve into posts.
+
+So the complete picture: the metamodel expresses **structure + validation** of the whole
+platform's domain model uniformly; **behaviour composes from the substrate loops**;
+**integrations stay referenced services**. It's the convergence point of every loop in the repo.
+
 ## Why (the wrinkle that started this)
 
 Candidates for `is-a`/`subtype-of` were `instances-of("type")` — the *instances* that are