@rubytech/create-maxy-code 0.1.0

package/payload/platform/plugins/memory/references/schema-base.md

@@ -0,0 +1,234 @@
+# Schema Reference — Base
+
+Universal node types shared across all business verticals. Load this reference before any structured write to the graph. If a vertical reference is also loaded, it extends these types — it never replaces them.
+
+When loading this reference, confirm which schema files were consulted by noting: "Using schema-base" (and the vertical file name, if loaded).
+
+> **Role of this file.** It declares **property-shape rules** — required properties, naming conventions, and relationship patterns — for documented labels. It is **not** the label-existence gate. Label existence is established by the live `db.labels()` ∪ `schema.cypher` declarations. Platform-native labels (`LocalBusiness`, `AdminUser`, `Conversation`, `KnowledgeDocument`) live in `platform/neo4j/schema.cypher` and are accepted by the validator without a markdown row here; their property shape is the agent's responsibility until a row is added. A label appearing in this file is the agent's commitment that writes carry the listed required properties. A label absent from this file is not a write blocker.
+
+---
+
+## Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Interchange Standard | Required Properties |
+|--------|-------------|-----------------|----------------------|---------------------|
+| Customer | `Person` | `schema:Person` | vCard (RFC 6350) | `accountId` |
+| Supplier | `Organization` | `schema:Organization` | vCard (RFC 6350) | `accountId`, `name`, `telephone` or `email` |
+| Staff | `Person` | `schema:Person` + `cdm:Contact` | vCard (RFC 6350) | `accountId`, `givenName`, `familyName`, `jobTitle`, `permissions` |
+| Job | `Order` | `schema:Order` + `cdm:Opportunity` | — | `accountId`, `orderNumber`, `customer` (id), `orderStatus` |
+| Event | `Event` | `schema:Event` | iCalendar (RFC 5545) | `accountId`, `name`, `startDate`, `endDate` |
+| Invoice | `Invoice` | `schema:Invoice` | UBL 2.1 + PDF/A | `accountId`, `confirmationNumber`, `customer` (id), `totalPaymentDue`, `paymentStatus` |
+| Service | `Service` | `schema:Service` | Schema.org JSON-LD | `accountId`, `name`, `description`, `offers` (price) |
+| PriceRule | `PriceSpecification` | `schema:PriceSpecification` | — | `accountId`, `price`, `priceCurrency` |
+| Communication | `Message` | `schema:Message` + `cdm:Activity` | — | `accountId`, `sender`, `recipient`, `dateSent`, `channel` |
+| Document | `DigitalDocument` | `schema:DigitalDocument` | Original format preserved | `accountId`, `name`, `dateCreated`, `encodingFormat` |
+| Address | `PostalAddress` | `schema:PostalAddress` | — | `streetAddress`, `addressLocality`, `postalCode` |
+| Task | `Task` | `schema:Action` (semantics) | — | `accountId`, `taskId`, `name`, `status`, `priority` |
+| UserProfile | `UserProfile` | platform-native | — | `accountId`, `userId` |
+| Lead | `Lead` | `cdm:Lead` | CDM only | `accountId`, `subject`, `customer` (id), `status` |
+| Case | `Case` | `cdm:Case` | CDM only | `accountId`, `title`, `customer` (id), `status`, `priority` |
+| OpeningHours | `OpeningHoursSpecification` | `schema:OpeningHoursSpecification` | Schema.org JSON-LD | `accountId`, `dayOfWeek`, `opens`, `closes` |
+| FAQ | `FAQPage` | `schema:FAQPage` | Schema.org JSON-LD | `accountId`, `name` |
+| Question | `Question` | `schema:Question` | Schema.org JSON-LD | `accountId`, `name` (question text), `acceptedAnswer` |
+| BrandAsset | `ImageObject` | `schema:ImageObject` | — | `accountId`, `name`, `contentUrl`, `encodingFormat`, `purpose` (logo/hero/icon) |
+| CreativeWork | `CreativeWork` | `schema:CreativeWork` | — | `accountId`, `title`, `abstract` |
+| DefinedTerm | `DefinedTerm` | `schema:DefinedTerm` | — | `accountId`, `name`, `description` |
+| AccessGrant | `AccessGrant` | platform-native | — | `accountId`, `agentSlug`, `contactMethod`, `contactValue`, `status` (scope must be `admin`) |
+| CloudflareTunnel | `CloudflareTunnel` | platform-native | — | `accountId`, `tunnelId`, `tunnelName` |
+| CloudflareHostname | `CloudflareHostname` | platform-native | — | `accountId`, `hostnameValue`, `tunnelId` |
+| Position | `Position` | platform-native (analogue of `schema:OrganizationRole`) | — | `accountId`, `title`, `startDate` |
+| WhatsApp Conversation (legacy) | `WhatsAppConversation` | extends `schema:Conversation` | — | `accountId`, `conversationId`, `archiveSourceFile`, `firstMessageAt`, `lastMessageAt`, `participantCount`, `messageCount`, `scope`, `createdByAgent`, `createdBySession`, `createdAt` |
+| WhatsApp Message (legacy) | `WhatsAppMessage` | extends `schema:Message` | — | `accountId`, `conversationId`, `messageId`, `dateSent`, `body`, `senderName`, `sequenceIndex`, `scope`, `createdByAgent`, `createdBySession`, `createdAt` |
+| ConversationArchive | `ConversationArchive` | platform-native (chunked conversation archive parent) | — | `accountId`, `conversationIdentity`, `archiveSourceFile`, `summary`, `keywords`, `lastIngestedMessageHash`, `lastIngestedMessageAt`, `lastIngestedArchiveSha256`, `scope`, `createdByAgent`, `createdBySession`, `createdAt` |
+
+**Branding properties on LocalBusiness:** `primaryColor`, `accentColor`, `backgroundColor`, `tagline` — optional, used to brand the public chat endpoint. Written via `memory-update` on the LocalBusiness node. Hex color values must match `#[0-9a-fA-F]{3,8}`. Logo and icon are linked via `HAS_BRAND_ASSET → ImageObject` with `purpose: "logo"` or `"icon"`.
+
+**Personal-profile role on Person:** the optional `role` property on a `Person` node carries the value `"admin-personal"` when the node is the operator's personal-profile bootstrap (onboarding step 9 personal mode). The platform accepts `Person {role: "admin-personal"}` in lieu of a `LocalBusiness` so personal-mode users can complete onboarding without registering a business. Do not set `role: "admin-personal"` on customer or staff Person nodes — it's the personal-profile discriminator and only the bootstrap node should carry it.
+
+**Person is open by default.** Any Person property the agent judges useful is permitted; the set is comprehensive, not enumerated. The only hard requirement is `accountId` (the universal account-scoping property — see [feedback_accountid_must_be_uuid.md](../../../../.claude/projects/-Users-neo-getmaxy/memory/feedback_accountid_must_be_uuid.md)). Identifying fields (`givenName`, `familyName`, `email`, `telephone`, …) are agent-judged: a single field is enough to create a Person; the agent and operator manage dedup and conflicts downstream. Forbidden Properties (e.g. `Person.name` rejects in favour of `givenName` + `familyName`) and Schema.org synonyms (e.g. `phone` rejects in favour of `telephone`) still apply. The `profile-update` tool's `personFields` parameter is the personal-profile conversational surface, validating in `mode: "update"` so SET-only writes skip the (now-empty) required-property check (givenName/familyName were established at PIN setup).
+
+**CreativeWork** covers long-form textual records written by the platform: session summaries (`session-compact`), workflow digests (e.g. public chat review), and skill definitions saved by `skill-builder`. The `title` is a short identifier; the `abstract` carries the full content that drives the embedding.
+
+**DefinedTerm** covers reusable concepts, learnings, and glossary entries — e.g. project retrospective learnings (`name` is a short handle, `description` is the full learning). Additional properties like `category` are encouraged but not required.
+
+**Position** carries a single role held by a `UserProfile` at an `Organization` — its title, dates, and per-role properties (e.g. achievement bullets in `description`, `endDate` for a finished role). Each role is its own node so it can carry its own structure; multiple Positions per UserProfile (career history); one Organization may host many Positions across many UserProfiles. Written by the `document-ingest` skill when a CV section classifies as `Position`. The natural pattern is `(:UserProfile)-[:HAS_POSITION]->(:Position)-[:AT]->(:Organization)` — never set the employer name as a property on Position; always create the AT edge to the (MERGEd) Organization.
+
+**Durable-action properties on Task:** `kind` (string discriminator, e.g. `"onboarding-establish-owner"`, `"cloudflare-tunnel-login"`), `steps` (string[], append-only as the action progresses), `startedAt` (ISO timestamp, set when status transitions to `running`), `completedAt` (ISO timestamp, set when status transitions to `completed` or `failed`), `errorMessage` (string, set when status=`failed`; cleared to `null` when the same Task transitions to `completed`), `inputsProvided` (string[] of property names supplied at action start — the canonical "call shape" record), `inputs.<field>` (Record of arbitrary non-secret JSON values from the action's form payload, redacted at write time per the schema declared at the form definition). All optional. Per-kind value-field enumeration is intentionally absent — values vary by what the action records, governed by the central `redactSecrets` primitive rather than per-kind allow-lists. The `running` status value joins the existing `pending|active|completed|failed|cancelled` enum to discriminate "an action is mid-flight in this conversation" from `active` ("a commitment the operator has accepted").
+
+---
+
+## Forbidden Properties
+
+Properties listed here are **rejected at write-time** by the schema validator on the listed label. Rejection runs after the synonym pass, so a `firstName → givenName` rewrite still happens before the forbidden-property check. The rule is per-label: `name` is forbidden on `Person` only; `Organization`, `Event`, `Conversation`, `Service`, etc. retain `name` as a canonical property.
+
+| Label | Property | Rationale |
+|-------|----------|-----------|
+| `Person` | `name` | Use `givenName` + `familyName`. The rendered display name is composed at read time; persisting `name` denormalises the canonical pair and creates a divergence trap when `name` truncates to `givenName` ("Dan") while the pair holds the full identity ("Dan Brett"). |
+
+---
+
+## Property Naming Rules
+
+Schema.org property names are camelCase. Use them exactly as defined — no synonyms, no abbreviations:
+
+| Correct | Wrong |
+|---------|-------|
+| `givenName` | `firstName`, `first_name` |
+| `familyName` | `lastName`, `last_name`, `surname` |
+| `telephone` | `phone`, `phoneNumber`, `mobile` |
+| `startDate` / `endDate` | `start`, `end`, `from`, `to` |
+| `totalPaymentDue` | `amount`, `total`, `invoiceTotal` |
+| `orderStatus` | `status` (on Order nodes — use the qualified name) |
+| `dateSent` | `timestamp`, `date`, `sentAt` (on Message nodes) |
+| `confirmationNumber` | `invoiceNumber`, `invoiceNo` |
+| `addressLocality` | `city`, `town` |
+| `postalCode` | `postcode`, `zipCode`, `zip` |
+
+---
+
+## accountId Scoping
+
+Every node except `PostalAddress` must carry `accountId`. No write may omit it. No query result without `accountId` should be treated as valid. There is no default value and no fallback — if `accountId` is unknown, the write must not proceed.
+
+`PostalAddress` nodes are exempt because addresses are shared across entities (a customer and their orders may share the same address node).
+
+---
+
+## Embedding
+
+Every write that creates or updates a structured node produces a 768-dimension embedding via `nomic-embed-text` (Ollama). The `memory-write` tool handles embedding generation automatically. The agent's responsibility is to provide complete, meaningful property values so the embedding accurately represents the node's content.
+
+Do not write placeholder values ("TBD", "unknown", empty strings) for properties that will be embedded — they degrade search quality.
+
+---
+
+## Relationship Patterns
+
+```
+(:Person)-[:WORKS_FOR]->(:Organization)
+(:Order)-[:ORDERED_BY]->(:Person)
+(:Invoice)-[:REFERENCES_ORDER]->(:Order)
+(:Invoice)-[:BILLED_TO]->(:Person|Organization)
+(:Event)-[:ATTENDED_BY]->(:Person)
+(:Message)-[:SENT_TO]->(:Person|Organization)
+(:DigitalDocument)-[:ABOUT]->(:*)
+(:Task)-[:RAISED_BY]->(:Person)
+(:Task)-[:RAISED_DURING]->(:AdminConversation|:PublicConversation|:WhatsAppConversation)
+(:Task)-[:PRODUCED]->(:Person|:UserProfile|:AdminUser|:Organization|:LocalBusiness|:CloudflareTunnel|:CloudflareHostname|:KnowledgeDocument|:*)
+(:Task)-[:ABOUT]->(:Person|Service|Order|*)
+(:AdminUser|:Person)-[:HAS_PROFILE]->(:UserProfile)
+(:LocalBusiness)-[:HAS_HOURS]->(:OpeningHoursSpecification)
+(:LocalBusiness)-[:HAS_FAQ]->(:FAQPage)
+(:FAQPage)-[:CONTAINS]->(:Question)
+(:LocalBusiness)-[:HAS_BRAND_ASSET]->(:ImageObject)
+(:Person)-[:HAS_ACCESS]->(:AccessGrant)
+(:LocalBusiness)-[:OFFERS]->(:Service)
+(:UserProfile)-[:HAS_POSITION]->(:Position)
+(:Position)-[:AT]->(:Organization)
+(:UserProfile)-[:ATTENDED]->(:Organization {organizationCategory:'educational'})
+(:UserProfile)-[:HOLDS]->(:Credential)
+(:UserProfile)-[:HAS_SKILL]->(:DefinedTerm {category:'skill'})
+(:KnowledgeDocument)-[:REFERENCES]->(:*)
+(:KnowledgeDocument)-[:HAS_SECTION]->(:Section)
+(:Message)-[:PART_OF]->(:Conversation)
+(:Person|:AdminUser)-[:SENT]->(:Message)
+(:Person|:AdminUser)-[:PARTICIPANT_IN]->(:Conversation)
+(:Message)-[:NEXT]->(:Message)
+```
+
+### WhatsApp ingest natural-key contract
+
+Live nodes carry compound labels: `:Conversation:WhatsAppConversation` and `:Message:WhatsAppMessage`. The Node Types table registers `WhatsAppConversation` and `WhatsAppMessage` individually — the schema validator matches on the more-specific sublabel. Base `Conversation` and `Message` rules (e.g. `dateSent` on Message) still apply via the base label.
+
+`:Message:WhatsAppMessage` natural key is `messageId = whatsapp-export:msg:<conversationSha256>:<dateSentISO>:<NFKC-trim-lower(senderName)>:<sha256-hex(body)>`. Re-imports of the same archive — same operator-confirmed timezone — collapse to the same Message identity. The chain `(:Message)-[:NEXT]->(:Message)` is rebuilt deterministically by ordering on `(dateSent, sequenceIndex, messageId)`; `sequenceIndex` is preserved on the node only as a tiebreaker, never as part of `messageId`.
+
+### Document-ingestion section kinds
+
+The `document-ingest` skill maps unstructured-document sections onto a closed enumeration of `kind` values. Every section becomes one `:Section` node; recognised kinds carry a secondary label so the same node serves as both the document section and the typed entity. Identity-kind anchor edges point from the document subject directly at the multi-labeled section node — there is no parallel "Section vs typed-node" concept.
+
+The closed enumeration:
+
+**Identity kinds (anchor edge from the document subject, usually `UserProfile`):**
+
+| `kind` | Section labels | Anchor pattern |
+|---|---|---|
+| `Position` | `:Section:Position` | `(:UserProfile)-[:HAS_POSITION]->(:Section:Position)`; section `-[:AT]->` `:Organization` |
+| `Education` | `:Section:Education` | `(:UserProfile)-[:ATTENDED {degree, startDate, endDate}]->(:Section:Education)`; section `-[:ATTENDED]->` `:Organization {organizationCategory:'educational'}` |
+| `Credential` | `:Section:Credential` | `(:UserProfile)-[:HOLDS]->(:Section:Credential)` |
+| `Skill` | `:Section:Skill` | `(:UserProfile)-[:HAS_SKILL]->(:Section:Skill)` |
+| `Biography` | `:Section:Biography` | `(:UserProfile)-[:DESCRIBED_BY]->(:Section:Biography)` |
+
+**Standalone (non-Section) node kind:**
+
+| `kind` | Node label | Anchor pattern |
+|---|---|---|
+| `Project` | `:Project` | `(:UserProfile)-[:CREATED]->(:Project)`; optional `(:Project)-[:UNDER]->(:Organization)` |
+
+**Document-structural kinds (HAS_SECTION + NEXT only — no anchor edge):**
+
+`Preface`, `Abstract` (alias for Summary / ExecutiveSummary), `Introduction`, `TableOfContents`, `Chapter`, `Conclusion`, `Appendix`, `Bibliography` (alias for References), `Glossary`, `Acknowledgments` — each becomes `:Section:<Kind>` linked to the document via `(:KnowledgeDocument)-[:HAS_SECTION]->` and chained to siblings via `(:Section)-[:NEXT]->(:Section)` in reading order.
+
+`Conversation` — chat-mode chunks emitted by `memory-classify` with `mode='chat'`. Becomes `:Section:Conversation` linked via `(:ConversationArchive)-[:HAS_SECTION]->` (a different parent than KnowledgeDocument). Properties beyond the base section shape: `summary`, `keywords`, `firstMessageAt`, `lastMessageAt`, `participantNames`, `messageCount`, `archiveSha256`. The `:Section` validator rules (embedding, body, position) apply uniformly.
+
+**Contract-clause kinds (HAS_SECTION + NEXT, plus special-case extras for two kinds):**
+
+`Parties`, `Recitals`, `Definitions`, `Scope`, `Term`, `Payment`, `Confidentiality`, `IntellectualProperty`, `Warranties`, `Indemnification`, `Liability`, `Termination`, `GoverningLaw`, `ForceMajeure`, `Notices`, `EntireAgreement`, `Amendment`, `Assignment`, `Severability`, `Signatures`.
+
+Two contract-clause kinds carry additional structure:
+- `:Section:Parties` — the classifier additionally emits `documentEdges` of type `PARTY` so the writer creates `(:KnowledgeDocument)-[:PARTY]->(:Person|:Organization)` for each party named.
+- `:Section:Definitions` — the classifier additionally emits `related` entries with edge type `DEFINES` so the writer creates `(:Section:Definitions)-[:DEFINES]->(:DefinedTerm)` for each defined term.
+
+**Label fallback:**
+
+| `kind` | Section labels | Notes |
+|---|---|---|
+| `Other` | `:Section:Other` | Classifier ran but the section's content fits no listed kind. The `classifierReason` property carries the one-line description. Distinct from a classifier *crash* (which aborts ingest entirely). Distinct from edge-orphan-candidate (which is a node-level concept). |
+
+The classifier returns `kind` strings from the closed enumeration above. `kind` values not in the list collapse to `Other` server-side — `memory-ingest` never invents a label or accepts an unrecognised kind silently.
+
+**Edges introduced by document-ingest:**
+
+| Edge | From → To | Notes |
+|---|---|---|
+| `HAS_SECTION` | `KnowledgeDocument` → `Section` | Always, every section. |
+| `NEXT` | `Section` → `Section` | Reading-order chain; one per pair of consecutive sections within a single document. |
+| `HAS_POSITION` | `UserProfile` → `Section:Position` | Identity anchor. |
+| `ATTENDED` | `UserProfile` → `Section:Education` and `Section:Education` → `Organization` | Anchor + related-entity. |
+| `HOLDS` | `UserProfile` → `Section:Credential` | Identity anchor. |
+| `HAS_SKILL` | `UserProfile` → `Section:Skill` | Identity anchor. |
+| `DESCRIBED_BY` | `UserProfile` → `Section:Biography` | Identity anchor. |
+| `CREATED` | `UserProfile` → `Project` | Standalone-node anchor. |
+| `UNDER` | `Project` → `Organization` | Optional Project context. |
+| `AT` | `Section:Position` → `Organization` | Position's employer. |
+| `PARTY` | `KnowledgeDocument` → `Person` or `Organization` | Contract Parties — written from `documentEdges` when a `Parties` section is detected. |
+| `PARTICIPANT` | `KnowledgeDocument` → `Person` or `Organization` | Meeting / call attendees — written from `documentEdges` when the document is a multi-party transcript or meeting notes. |
+| `FROM` | `KnowledgeDocument` → `Person` | Email sender — written from `documentEdges` when the document carries email headers. |
+| `TO` | `KnowledgeDocument` → `Person` or `Organization` | Email direct recipient — written from `documentEdges` per recipient. |
+| `CC` | `KnowledgeDocument` → `Person` or `Organization` | Email cc'd recipient — written from `documentEdges` per cc. |
+| `SPEAKER` | `KnowledgeDocument` → `Person` | Voice-note / single-speaker transcript speaker — written from `documentEdges`. |
+| `MENTIONS` | `KnowledgeDocument` → `Person`, `Organization`, `Service`, `Task`, `Event`, `KnowledgeDocument`, `BrandingData` | Catch-all for entities the dispatch brief named that the document references but for which no document-shape-specific edge applies — written by `specialists:database-operator` in the `wire-brief-entities` pipeline step. |
+| `DEFINES` | `Section:Definitions` → `DefinedTerm` | Contract definitions — written from per-section `related`. |
+
+**Ontology-growth review query.** When a document accumulates several `:Section:Other` nodes, the operator (or admin agent) can run the following Cypher to surface candidate ontology additions:
+
+```cypher
+MATCH (s:Section:Other)
+WHERE s.accountId = $acc
+RETURN s.title, s.classifierReason, count(*) AS occurrences
+ORDER BY occurrences DESC
+```
+
+Patterns with high occurrence count are candidates for new section-kind labels. Adding a kind = adding a row to `schema-base.md` (and any relevant vertical schema) — never per-account.
+
+---
+
+## Order Node — Disambiguation
+
+The base `Order` label is used for general jobs and orders. Several vertical schemas define specialised subtypes that also map to `schema:Order` but use different Neo4j labels:
+
+- **Trades:** `Quote` (quote/estimate before acceptance)
+- **Professional Services:** `Retainer` (recurring service agreement)
+- **Food & Beverage:** `Order` with F&B-specific properties (table, servedBy)
+- **Retail:** `PurchaseOrder` (supplier-facing order)
+
+When a vertical is loaded, use its specific label for domain-specific orders. Use the base `Order` label only for general-purpose jobs or when no vertical-specific type applies.

package/payload/platform/plugins/memory/references/schema-creator.md

@@ -0,0 +1,35 @@
+# Schema Reference — Creator
+
+Vertical schema for `businessType: "creator"` — content creators, influencers, YouTubers, podcasters, writers, coaches.
+
+This reference extends the base schema. All base node types remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-creator".
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| Content | `Content` | `schema:CreativeWork` | `accountId`, `title`, `format` (video/blog/podcast/post), `platform`, `publishedDate`, `status` |
+| Campaign | `Campaign` | `cdm:Opportunity` | `accountId`, `brand` (id), `deliverables`, `fee`, `deadline`, `status` |
+| Audience | `Audience` | `schema:Audience` | `accountId`, `platform`, `followerCount`, `engagementRate`, `demographics` |
+| BrandDeal | `BrandDeal` | `schema:Order` (subtype) | `accountId`, `brand` (id), `campaign` (id), `fee`, `deliverables`, `contractDate` |
+
+### BrandDeal vs base Order
+
+`BrandDeal` is the creator-specific label for paid partnerships and sponsorships. Use `BrandDeal` (not `Order`) for brand collaboration agreements. The base `Order` is used for general commercial transactions.
+
+---
+
+## Relationship Patterns
+
+```
+(:Content)-[:PART_OF_CAMPAIGN]->(:Campaign)
+(:Campaign)-[:WITH_BRAND]->(:Organization)
+(:BrandDeal)-[:DELIVERS]->(:Content)
+(:Audience)-[:ON_PLATFORM]->(:Service)
+```
+
+The `(:Audience)-[:ON_PLATFORM]->(:Service)` relationship models the platform (YouTube, Instagram, etc.) as a `Service` node from the base schema.

package/payload/platform/plugins/memory/references/schema-estate-agent.md

@@ -0,0 +1,35 @@
+# Schema Reference — Estate Agent
+
+Vertical schema for `businessType: "estate-agent"` — estate agents, letting agents, property managers.
+
+This reference extends the base schema. All base node types remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-estate-agent".
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| Listing | `Listing` | `schema:RealEstateListing` | `accountId`, `address` (id), `listingType` (sale/let), `price`, `status`, `bedrooms`, `bathrooms`, `sqft` |
+| Property | `Property` | `schema:Accommodation` | `accountId`, `address` (id), `propertyType`, `tenure`, `epcRating`, `features` |
+| Viewing | `Viewing` | `schema:Event` (subtype) | `accountId`, `listing` (id), `applicant` (id), `date`, `feedback`, `outcome` |
+| Applicant | `Applicant` | `schema:Person` (extended) | Base Person properties + `budget`, `tenure`, `moveDate`, `requirements` |
+| Offer | `Offer` | `schema:Offer` | `accountId`, `listing` (id), `applicant` (id), `amount`, `conditions`, `status`, `date` |
+
+### Applicant vs base Person
+
+`Applicant` extends the base `Person` type with property-search-specific properties. Use `Applicant` as an additional label on the `Person` node — the applicant is still a `Person` for base queries, but the extra label carries estate-agent-specific fields like `budget` and `requirements`.
+
+---
+
+## Relationship Patterns
+
+```
+(:Listing)-[:FOR_PROPERTY]->(:Property)
+(:Viewing)-[:FOR_LISTING]->(:Listing)
+(:Viewing)-[:BY_APPLICANT]->(:Person)
+(:Offer)-[:ON_LISTING]->(:Listing)
+(:Offer)-[:FROM_APPLICANT]->(:Person)
+```

package/payload/platform/plugins/memory/references/schema-food-beverage.md

@@ -0,0 +1,32 @@
+# Schema Reference — Food & Beverage
+
+Vertical schema for `businessType: "food-beverage"` — restaurants, cafes, bars, food trucks, catering.
+
+This reference extends the base schema. All base node types remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-food-beverage".
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| TableReservation | `TableReservation` | `schema:FoodEstablishmentReservation` | `accountId`, `guest` (id), `partySize`, `date`, `time`, `tableNumber`, `reservationStatus` |
+| MenuItem | `MenuItem` | `schema:MenuItem` | `accountId`, `name`, `description`, `price`, `category`, `allergens`, `available` |
+| Menu | `Menu` | `schema:Menu` | `accountId`, `name`, `validFrom`, `validThrough`, `items` |
+| DiningOrder | `DiningOrder` | `schema:Order` (F&B subtype) | `accountId`, `table` (id), `items`, `orderStatus`, `totalPrice`, `servedBy` (id) |
+
+### DiningOrder vs base Order
+
+`DiningOrder` is the food-and-beverage-specific label for table orders. Use `DiningOrder` (not `Order`) for orders placed at a table or counter. The base `Order` is used for general jobs — `DiningOrder` carries F&B-specific properties like `table` and `servedBy`.
+
+---
+
+## Relationship Patterns
+
+```
+(:Menu)-[:CONTAINS]->(:MenuItem)
+(:DiningOrder)-[:FROM_TABLE]->(:TableReservation)
+(:DiningOrder)-[:INCLUDES]->(:MenuItem)
+```

package/payload/platform/plugins/memory/references/schema-hospitality.md

@@ -0,0 +1,31 @@
+# Schema Reference — Hospitality
+
+Vertical schema for `businessType: "hospitality"` — hotels, B&Bs, guesthouses, serviced apartments.
+
+This reference extends the base schema. All base node types remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-hospitality".
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| Reservation | `Reservation` | `schema:LodgingReservation` | `accountId`, `guest` (id), `checkInDate`, `checkOutDate`, `roomType`, `totalPrice`, `reservationStatus` |
+| Room | `Room` | `schema:Accommodation` | `accountId`, `name`, `roomType`, `capacity`, `pricePerNight`, `amenities` |
+| GuestProfile | `GuestProfile` | `schema:Person` (extended) | Base Person properties + `dietaryRequirements`, `preferences`, `loyaltyPoints` |
+
+### GuestProfile vs base Person
+
+`GuestProfile` extends the base `Person` type with hospitality-specific properties. When creating a guest record, use `GuestProfile` as an additional label on the `Person` node — the guest is still a `Person` for base queries, but the extra label allows hospitality-specific property queries.
+
+---
+
+## Relationship Patterns
+
+```
+(:Reservation)-[:FOR_ROOM]->(:Room)
+(:Reservation)-[:BOOKED_BY]->(:Person)
+(:Invoice)-[:FOR_RESERVATION]->(:Reservation)
+```

package/payload/platform/plugins/memory/references/schema-logistics.md

@@ -0,0 +1,30 @@
+# Schema Reference — Logistics
+
+Vertical schema for `businessType: "logistics"` — couriers, freight, delivery services, fleet operators.
+
+This reference extends the base schema. All base node types remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-logistics".
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| Shipment | `Shipment` | `schema:ParcelDelivery` | `accountId`, `sender` (id), `recipient` (id), `origin` (id), `destination` (id), `status`, `trackingNumber`, `estimatedDelivery` |
+| Vehicle | `Vehicle` | `schema:Vehicle` | `accountId`, `registration`, `type`, `driver` (id), `capacity`, `nextService` |
+| Route | `Route` | `cdm:Activity` | `accountId`, `vehicle` (id), `driver` (id), `date`, `stops`, `startTime`, `endTime` |
+| Stop | `Stop` | `schema:DeliveryEvent` | `accountId`, `route` (id), `address` (id), `shipments`, `arrivalTime`, `signature` |
+
+---
+
+## Relationship Patterns
+
+```
+(:Shipment)-[:CARRIED_ON]->(:Route)
+(:Route)-[:USES_VEHICLE]->(:Vehicle)
+(:Stop)-[:PART_OF_ROUTE]->(:Route)
+(:Stop)-[:AT_ADDRESS]->(:PostalAddress)
+(:Shipment)-[:DELIVERED_TO]->(:Person|Organization)
+```

package/payload/platform/plugins/memory/references/schema-professional-services.md

@@ -0,0 +1,33 @@
+# Schema Reference — Professional Services
+
+Vertical schema for `businessType: "professional-services"` — consultants, agencies, accountants, solicitors, advisors.
+
+This reference extends the base schema. All base node types remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-professional-services".
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| Engagement | `Engagement` | `cdm:Opportunity` | `accountId`, `client` (id), `scope`, `startDate`, `endDate`, `value`, `status` |
+| Retainer | `Retainer` | `schema:Order` (subtype) | `accountId`, `client` (id), `monthlyValue`, `hoursIncluded`, `renewalDate` |
+| Deliverable | `Deliverable` | `schema:DigitalDocument` | `accountId`, `engagement` (id), `name`, `dueDate`, `status`, `version` |
+| TimeEntry | `TimeEntry` | `cdm:Activity` | `accountId`, `engagement` (id), `date`, `hours`, `description`, `billable` |
+
+### Retainer vs base Order
+
+`Retainer` is the professional-services-specific label for recurring service agreements. Use `Retainer` (not `Order`) for ongoing client contracts with monthly billing. One-off project work uses a base `Order` linked to an `Engagement`.
+
+---
+
+## Relationship Patterns
+
+```
+(:Engagement)-[:FOR_CLIENT]->(:Person|Organization)
+(:Deliverable)-[:PART_OF]->(:Engagement)
+(:TimeEntry)-[:LOGGED_AGAINST]->(:Engagement)
+(:Invoice)-[:FOR_ENGAGEMENT]->(:Engagement)
+```

package/payload/platform/plugins/memory/references/schema-retail.md

@@ -0,0 +1,33 @@
+# Schema Reference — Retail
+
+Vertical schema for `businessType: "retail"` — shops, boutiques, online stores, product sellers.
+
+This reference extends the base schema. All base node types remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-retail".
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| Product | `Product` | `schema:Product` | `accountId`, `name`, `sku`, `description`, `price`, `category`, `stockLevel` |
+| StockMovement | `StockMovement` | `cdm:Activity` | `accountId`, `product` (id), `quantity`, `direction` (in/out), `reason`, `date` |
+| PurchaseOrder | `PurchaseOrder` | `schema:Order` (subtype) | `accountId`, `supplier` (id), `lineItems`, `orderDate`, `expectedDelivery`, `orderStatus` |
+| StoreLocation | `StoreLocation` | `schema:Store` | `accountId`, `name`, `address` (id), `openingHours` |
+
+### PurchaseOrder vs base Order
+
+`PurchaseOrder` is the retail-specific label for supplier-facing orders (restocking, procurement). Use `PurchaseOrder` (not `Order`) when ordering from a supplier. Customer-facing orders use the base `Order` label.
+
+---
+
+## Relationship Patterns
+
+```
+(:Order)-[:CONTAINS_PRODUCT]->(:Product)
+(:Product)-[:SUPPLIED_BY]->(:Organization)
+(:StockMovement)-[:AFFECTS]->(:Product)
+(:PurchaseOrder)-[:FROM_SUPPLIER]->(:Organization)
+```

package/payload/platform/plugins/memory/references/schema-trades.md

@@ -0,0 +1,36 @@
+# Schema Reference — Trades
+
+Vertical schema for `businessType: "trades"` — home services, construction, and tradespeople (plumber, electrician, builder, decorator).
+
+This reference extends the base schema. All base node types (Person, Organization, Order, Event, Invoice, Service, etc.) remain valid. Load `schema-base.md` first.
+
+When loading this reference, confirm: "Using schema-base + schema-trades".
+
+---
+
+## Additional Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Required Properties |
+|--------|-------------|-----------------|---------------------|
+| Quote | `Quote` | `schema:Order` + `cdm:Opportunity` | `accountId`, `quoteNumber`, `customer` (id), `lineItems`, `validUntil`, `totalPrice` |
+| SiteVisit | `SiteVisit` | `schema:Event` (subtype) | `accountId`, `address` (id), `engineer` (id), `startDate`, `purpose` |
+| Inspection | `Inspection` | `cdm:Case` (subtype) | `accountId`, `address` (id), `findings`, `recommendations`, `photos` |
+| Certification | `Certification` | `schema:DigitalDocument` | `accountId`, `type` (gas safe, NICEIC, etc.), `issuedDate`, `expiryDate` |
+| Material | `Material` | `schema:Product` | `accountId`, `name`, `sku`, `unitCost`, `supplier` (id) |
+
+### Quote vs base Order
+
+`Quote` is the trades-specific label for estimates and quotes before acceptance. Use `Quote` (not `Order`) when the work is proposed but not yet confirmed. Once a quote is accepted, create a base `Order` node linked to it, or update the Quote's `orderStatus` to reflect acceptance.
+
+---
+
+## Relationship Patterns
+
+```
+(:Order)-[:REQUIRES_VISIT]->(:SiteVisit)
+(:Order)-[:USES_MATERIAL]->(:Material)
+(:SiteVisit)-[:AT_ADDRESS]->(:PostalAddress)
+(:Certification)-[:HELD_BY]->(:Person)
+```
+
+The `(:Certification)-[:HELD_BY]->(:Person)` relationship tracks which staff member holds a trade certification (e.g., Gas Safe, NICEIC, Part P).