@rubytech/create-realagent 1.0.406

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

@@ -0,0 +1,102 @@
+# 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).
+
+---
+
+## Node Types
+
+| Entity | Neo4j Label | Schema.org Type | Interchange Standard | Required Properties |
+|--------|-------------|-----------------|----------------------|---------------------|
+| Customer | `Person` | `schema:Person` | vCard (RFC 6350) | `accountId`, `givenName`, `familyName`, `email` or `telephone` |
+| 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` |
+| 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) |
+
+**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"`.
+| AccessGrant | `AccessGrant` | platform-native | — | `accountId`, `agentSlug`, `contactMethod`, `contactValue`, `status` (scope must be `admin`) |
+
+---
+
+## 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)-[:ABOUT]->(:Person|Service|Order|*)
+(:LocalBusiness)-[:HAS_HOURS]->(:OpeningHoursSpecification)
+(:LocalBusiness)-[:HAS_FAQ]->(:FAQPage)
+(:FAQPage)-[:CONTAINS]->(:Question)
+(:LocalBusiness)-[:HAS_BRAND_ASSET]->(:ImageObject)
+(:Person)-[:HAS_ACCESS]->(:AccessGrant)
+```
+
+---
+
+## 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).

package/payload/platform/plugins/memory/skills/conversational-memory.md

@@ -0,0 +1,99 @@
+# Conversational Memory
+
+Memory accumulates from conversation — never from questionnaires, quizzes, or onboarding forms. The owner reveals who they are and how they work through natural interaction. Your role is to notice, store, and recall that knowledge so every session feels continuous rather than starting from scratch.
+
+## Memory Tools
+
+| Tool | Purpose |
+|---|---|
+| `profile-read` | Read profile and preferences. Use `detail: true` for transparency (confidence, evidence, stats). |
+| `profile-update` | Create or update a preference. Modes: `reinforce`, `update`, `contradict`, `merge`. |
+| `profile-delete` | Remove a preference. Use when the owner says to forget something. |
+| `conversation-search` | Semantic search over past messages. Use to recall specific past interactions. |
+| `session-compact` | Write session context to the graph at compaction time. |
+
+## When to Observe
+
+Store a preference when the owner reveals something about how they work — either by telling you directly or by demonstrating it through their behaviour.
+
+**Explicit signals** — the owner states something directly:
+- "I prefer short answers"
+- "Never schedule before 10am"
+- "Always CC my partner on invoices"
+- "I make decisions quickly — just give me the options"
+
+Store these with `source: "explicit"`. They carry high initial confidence because the owner said them intentionally.
+
+**Behavioural signals** — the owner demonstrates a pattern without naming it:
+- They consistently ask for summaries instead of details (→ `communication/response_detail: "prefers summaries over detail"`)
+- They always reschedule Monday tasks to Tuesday (→ `scheduling/monday_preference: "avoids Mondays for deep work"`)
+- They reject formal language in drafts and rewrite casually (→ `content/writing_tone: "casual, direct tone"`)
+
+Store these with `source: "behavioural"`. Only store after observing the pattern at least twice — a single instance is noise, not signal. Use `mode: "reinforce"` on second observation.
+
+**What NOT to observe:**
+- One-off task instructions ("send that email now") — these are commands, not preferences
+- Emotional reactions to external events — transient, not characteristic
+- Anything the owner explicitly asks you NOT to remember
+
+## How to Store
+
+Every `profile-update` call should include:
+- `category` — one of: `communication`, `scheduling`, `decision`, `workflow`, `content`, `interaction`
+- `key` — a stable identifier for this preference (e.g., `response_length`, `meeting_time`, `writing_tone`)
+- `value` — the preference in natural language
+- `source` — `"explicit"` or `"behavioural"`
+- `conversationId` — always include this for evidence linking. The conversation ID is available in the session context.
+
+### Modes
+
+- **First observation**: omit `mode` (creates new preference at confidence 0.5)
+- **Re-observation**: use `mode: "reinforce"` (boosts confidence toward 1.0)
+- **Value changed**: use `mode: "update"` (new value, same confidence)
+- **Contradicted**: use `mode: "contradict"` (drops confidence by 0.3)
+- **Overlapping preferences**: use `mode: "merge"` with `mergeSourceIds` to combine
+
+### Keys
+
+Use consistent, descriptive keys. If a preference already exists for the same concept, reinforce or update it rather than creating a duplicate with a different key.
+
+## Remember and Forget
+
+When the owner explicitly asks you to remember something:
+1. Store it with `source: "explicit"` — this signals high intentionality
+2. Confirm what you stored: "I'll remember that you prefer meetings after 2pm."
+3. Do not embellish — store exactly what they said, not your interpretation
+
+When the owner asks you to forget something:
+1. Call `profile-delete` with the matching `category` and `key`
+2. Confirm: "Done — I've forgotten your preference about meeting times."
+3. If you're unsure which preference they mean, ask before deleting
+
+When the owner corrects a preference:
+1. Call `profile-update` with `mode: "update"` and the new value
+2. Confirm: "Updated — I now know you prefer Tuesdays over Wednesdays for reviews."
+
+## "What Do You Know About Me?"
+
+When the owner asks what you know about them (or any variation — "what have you learned?", "what do you remember?", "do you know my preferences?"):
+
+1. Call `profile-read` with `detail: true`
+2. Present the results conversationally — do not dump raw data
+3. Group by category, include confidence level and how you learned each preference
+4. Offer to correct or remove anything: "Want me to update or forget any of these?"
+
+The detailed response includes confidence labels (strong, moderate, fading, weak) and evidence (which conversations the preference was observed in). Use these to explain your knowledge transparently.
+
+## Memory Precedence
+
+Memory informs the current conversation — it does not override it.
+
+- If the owner's current message contradicts a stored preference, follow the current message. Call `profile-update` with `mode: "contradict"` to adjust the stored preference.
+- If a preference is labelled "fading" (confidence below 0.5), treat it as tentative — do not act on it without checking. Preferences decay over time when not re-observed.
+- If the owner's behaviour has clearly changed, update the preference rather than clinging to the old value. People evolve.
+
+## Session Context
+
+At compaction time, `session-compact` captures the session's key context (decisions, work in progress, open questions, things learned about the owner). This context can be recalled in future sessions via `session-compact-status`.
+
+Preferences captured during a session persist independently of compaction — they are written to the graph as they are observed, not batched at session end.

package/payload/platform/plugins/projects/PLUGIN.md

@@ -0,0 +1,87 @@
+---
+name: projects
+description: "Structured project execution. Phased sprints, operational investigations, deliverable reviews, and retrospectives — backed by graph tasks with dependency tracking and health signals."
+requires:
+  - tasks
+metadata: {"taskmaster":{"always":false,"embed":["admin"],"emoji":"📋","pluginKey":"projects","optional":true,"recommended":true}}
+---
+
+# Projects
+
+Structured execution discipline for business work. When the user has a project — a kitchen refit, a client engagement, a product launch, an operational investigation — this plugin provides phased workflows that create Task nodes, check dependencies, track progress, and produce a structured record of what happened.
+
+## When to Apply
+
+When the user describes work that involves multiple steps, dependencies, or deliverables, offer structured execution. Ask: "Would you like to run this as a structured project, or just handle it as a task?" Learn the user's preference over time — if they consistently choose one mode, stop asking and default to it.
+
+Explicit triggers always apply structured execution without asking:
+- "let's sprint on..."
+- "run a project on..."
+- "investigate why..."
+- "review the deliverables for..."
+- "let's do a retro on..."
+
+## Modes
+
+| Mode | When | Reference |
+|------|------|-----------|
+| Sprint | Multi-step project execution with deliverables | `references/sprint.md` |
+| Investigation | Operational problem that needs root-cause diagnosis | `references/investigation.md` |
+| Review | Deliverable ready for quality check against the brief | `references/review.md` |
+| Retrospective | Project completed, extract learnings for future work | `references/retrospective.md` |
+
+Load the relevant reference via `plugin-read` when entering a mode. Each reference describes outcomes and constraints for that mode — follow them.
+
+## Project Data Model
+
+A project is a Task node with child tasks linked via `PART_OF`. The parent Task is the project; child Tasks are individual work items.
+
+When creating a project:
+1. Create a parent Task with the project name and `[PROJECT:START]` in the first note
+2. Create child Tasks for each work item, linked to the parent via `task-relate` with `PART_OF`
+3. Add `BLOCKS` relationships between child tasks that have sequential dependencies
+4. Add `AFFECTS` relationships to entities the project will modify
+
+The `[PROJECT:START]` note marks this Task as a project (not a regular task). Include the tier and scope summary: `[PROJECT:START] Kitchen Refit — Full tier, 7 tasks planned`.
+
+## Session-Start Awareness
+
+At session start, after surfacing open tasks (per the tasks plugin behaviour), also check for active projects:
+
+1. Call `task-list` with status `active`
+2. Identify project tasks — those with `[PROJECT:START]` in their notes
+3. For each active project, report:
+   - Project name and current phase (from the latest `[PROJECT:PHASE]` note)
+   - Health signal (see below)
+   - What's next — the next actionable step or blocker
+
+If no active projects exist, proceed normally.
+
+## Health Signal
+
+Compute a RAG (Red/Amber/Green) health status for each active project using `task-list` filtered to the project's child tasks:
+
+| Signal | Condition |
+|--------|-----------|
+| Green | All child tasks on track: none overdue, no unresolved blockers, completion rate consistent with timeline |
+| Amber | Warning signs: at least one overdue task OR an unresolved blocker exists OR completion rate is behind schedule |
+| Red | Project at risk: multiple overdue tasks OR critical-path blocker unresolved OR no progress in recent sessions |
+
+When due dates are not set on child tasks, degrade gracefully: report completion count ("3 of 5 tasks done") without RAG colouring.
+
+Surface the health signal at session start and when the user asks about project status.
+
+## Structured Lifecycle Notes
+
+Append structured notes to the parent Task at key lifecycle moments. These notes create a searchable audit trail consumed by the retrospective to reconstruct project timelines.
+
+| Event | Note format |
+|-------|-------------|
+| Project start | `[PROJECT:START] {name} — {tier} tier, {n} tasks planned` |
+| Phase transition | `[PROJECT:PHASE] {phase name} — {brief summary of outcome}` |
+| Project complete | `[PROJECT:COMPLETE] {name} — {n}/{total} tasks done, {n} deferred` |
+| Project abandoned | `[PROJECT:ABANDONED] {name} — Reason: {why}` |
+
+## Dependencies
+
+This plugin requires the `tasks` plugin to be enabled. If task tools are unavailable (tasks plugin not enabled), tell the user: "I need the tasks plugin to run structured projects. Would you like to enable it?" Do not attempt structured execution without task tools — fall back to a regular conversational approach until the dependency is resolved.

package/payload/platform/plugins/projects/references/investigation.md

@@ -0,0 +1,63 @@
+# Investigation
+
+Root-cause diagnosis for operational problems. When something is going wrong — customer complaints spiking, a process is failing, costs are running over, a system isn't working as expected — this mode applies disciplined investigation to find the actual cause before proposing fixes.
+
+The iron rule: **no fixes without root cause.** Speculative fixes mask problems and waste time. One measurement beats three guesses.
+
+## Phases
+
+### Investigate
+
+Gather evidence about the problem. What is actually happening? What should be happening? When did the gap appear?
+
+- Search memory for relevant history — prior incidents, related changes, affected entities
+- Check task history for recent work that may be related
+- Ask the user targeted questions to establish the timeline and scope
+- Create a Task for this investigation with `[PROJECT:START] Investigation: {problem description}`
+
+Record what you find in the investigation task notes — every data point, every observation.
+
+### Analyse
+
+Pattern-match the evidence. What does the data tell you?
+
+- Look for correlations: did the problem start when something changed?
+- Check for scope: is this one instance or a pattern? One customer or many?
+- Test assumptions: is what the user believes about the problem supported by evidence?
+- Identify what you don't know and what evidence would fill the gap
+
+Record the analysis in task notes: `[PROJECT:PHASE] Analysis — {key findings}`.
+
+### Hypothesise
+
+Form one or more hypotheses that explain the evidence. For each:
+
+- **Hypothesis:** What do you believe is the cause?
+- **Evidence for:** What observations support this?
+- **Evidence against:** What observations contradict this?
+- **Test:** What would confirm or disprove this hypothesis?
+
+Rank hypotheses by how well they explain ALL the evidence, not just part of it. Present them to the user with a recommendation.
+
+### Implement
+
+Once the root cause is confirmed (or the most likely hypothesis is agreed), propose and execute the fix:
+
+- Describe the fix and its expected effect
+- Identify any risks or side effects
+- Execute the fix
+- Verify the problem is resolved — check the same evidence that surfaced the problem
+
+Mark the investigation complete: `[PROJECT:COMPLETE] Investigation: {problem} — Root cause: {cause}, Fix: {what was done}`.
+
+If the fix reveals a deeper problem, create a new investigation task rather than expanding this one.
+
+## When to Use
+
+- "Why are we getting so many complaints about..."
+- "Something is wrong with the scheduling..."
+- "Costs are way over what we quoted..."
+- "The process isn't working..."
+- "I keep seeing the same problem with..."
+
+Do not use investigation mode for simple questions with obvious answers. If the user asks "why did invoice X fail?" and the answer is immediately clear from the data, just answer. Investigation mode is for problems that need digging.