@rubytech/create-maxy-code 0.1.111 → 0.1.112

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-maxy-code",
-  "version": "0.1.111",
+  "version": "0.1.112",
   "description": "Install Maxy — AI for Productive People",
   "bin": {
     "create-maxy-code": "./dist/index.js"

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

@@ -12,12 +12,59 @@ When loading this reference, confirm: "Using schema-base + schema-estate-agent".
 
 | Entity | Neo4j Label | Schema.org Type | Required Properties |
 |--------|-------------|-----------------|---------------------|
-| Listing | `Listing` | `schema:RealEstateListing` | `accountId`, `address` (id), `listingType` (sale/let), `price`, `status`, `bedrooms`, `bathrooms`, `sqft` |
+| Listing | `Listing` | `schema:RealEstateListing` | `accountId`, `slug`, `displayName`, `listingType` (sale/let), `status`, `sourceSystem`, `sourceId`, `scope`, `heroImageUrl`*, `pageUrl`*, `blurb` |
 | 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` |
 
+\* `heroImageUrl` and `pageUrl` are required for any Listing whose `status` is `for-sale`, `under-offer`, or `sold` (anything publicly listable). Listings with `status: "off-market"` or `status: "withdrawn"` are exempt — they describe stock not currently visible to visitors and have no public listing page to point at. The curator writes `status: "off-market"` and skips the two URLs when the source has no public marketing.
+
+### Listing — full property set
+
+The required-properties column above is the minimum a Listing must carry. The complete property set the `listing-curator` specialist writes:
+
+**Visitor-renderable (the public agent reads these to assemble property cards):**
+- `slug` — URL-safe identifier derived from address (`griffin-house-upper-church-street-chepstow`)
+- `displayName` — human-readable title (`Griffin House, Upper Church Street, Chepstow NP16 5EX`)
+- `heroImageUrl` — primary image URL that will render inline in the chat
+- `blurb` — single marketing-grade sentence, ≤ 280 characters, suitable as alt-text and short caption
+- `pageUrl` — the live listing URL the visitor follows to view full details
+
+**Marketing entity:**
+- `listingType` — `sale` or `let`
+- `status` — `for-sale` / `under-offer` / `sold` / `withdrawn` / `off-market`
+- `price` — integer in pence (no currency symbol, no commas)
+- `priceQualifier` — `guide` / `offers-over` / `offers-in-excess` / `poa` / `fixed-price` / `auction` (null when not stated)
+- `bedrooms`, `bathrooms`, `receptionRooms` — integers (null when unknown)
+- `floorAreaSqft` — integer square feet (null when unknown)
+
+**Address (carried directly on the Listing rather than via a separate PostalAddress when only the formatted address is known — addresses upgrade to a linked `:PostalAddress` once structured):**
+- `postcode` — UK postcode, upper-case, single-space-separated outward/inward (`NP16 5EX`)
+- `addressLine` — first line of the address
+- `town`
+
+**Structured detail (optional):**
+- `propertyType` — `cottage` / `detached` / `semi-detached` / `terraced` / `flat` / `bungalow` / etc.
+- `tenure` — `freehold` / `leasehold` / `share-of-freehold` / `commonhold`
+- `description` — the full descriptive copy from the source (the `body` of any legacy KnowledgeDocument; the description block of the source listing)
+- `imageUrls` — string array of all image URLs (`heroImageUrl` is always also present in this array, at index 0)
+- `floorplanUrls` — string array
+- `epcUrl` — the EPC document URL
+
+**Provenance + search:**
+- `sourceSystem` — `loop-crm` / `zip-upload` / `manual`
+- `sourceId` — natural key in the source system (for Loop, the `loopPropertyId`)
+- `ingestedAt`, `lastVerifiedAt` — ISO timestamps
+- `scope` — `public` for listings that should be returned to anonymous visitors via the public memory-search; `shared` for staff-only listings (e.g. pre-marketing pipeline)
+- `embedding` — 768-dim vector (written automatically by `memory-write`)
+
+### Listing — natural-key contract
+
+Idempotency key: **`(accountId, sourceSystem, sourceId)`**. The curator MERGEs on this triple. Re-running the curator over the same source record updates the existing Listing in place — fields refresh (status drift over the listing's lifecycle is expected and desired: `for-sale` → `under-offer` → `sold`); no duplicate Listing is ever created.
+
+If the source emits multiple distinct listing events tied to a single underlying property (e.g. relisted after withdrawal, then again let separately), each listing event carries its own `sourceId` in the source system and becomes its own `:Listing` node. The two listings share a `:Property` parent via separate `[:FOR_PROPERTY]` edges. The curator never collapses distinct listing events into one node.
+
 ### 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`.
@@ -27,9 +74,12 @@ When loading this reference, confirm: "Using schema-base + schema-estate-agent".
 ## Relationship Patterns
 
 ```
+(:Listing)-[:LISTED_BY]->(:LocalBusiness)
 (:Listing)-[:FOR_PROPERTY]->(:Property)
 (:Viewing)-[:FOR_LISTING]->(:Listing)
 (:Viewing)-[:BY_APPLICANT]->(:Person)
 (:Offer)-[:ON_LISTING]->(:Listing)
 (:Offer)-[:FROM_APPLICANT]->(:Person)
 ```
+
+`(:Listing)-[:LISTED_BY]->(:LocalBusiness)` is the mandatory parent edge that every Listing carries — it satisfies the ≥1-adjacency write-gate doctrine ([[feedback_graph_hierarchy_doctrine]]) and names the estate agency that owns the listing. `[:FOR_PROPERTY]` is composed additionally when the underlying physical `:Property` node is known (full structural data captured); it is optional because Listings frequently land before Property structural data has been collected.

package/payload/platform/plugins/venture-studio/PLUGIN.md

@@ -4,6 +4,7 @@ description: "Founding-a-business agent. Drives an operator from raw idea to fun
 requires:
   - projects
   - work
+  - deep-research
 metadata: {"platform":{"always":false,"embed":["admin"],"pluginKey":"venture-studio","optional":true,"recommended":true}}
 ---
 
@@ -62,8 +63,8 @@ The script's three effects:
 2. **Creates the `Project` node.** Tier `full` (data-room work is multi-phase). Project name is the business's working name; description references the data-room root path.
 3. **Enumerates the eight artefact Tasks** in section order — one transaction, atomic with the Project. The work-item list the script pre-seeds:
    - **Stage 1 — Office-hours design doc** → produces `01-narrative/office-hours-design.md` (skill: `office-hours`)
-   - **Brand pack** → produces brand identity files into `06-product-ip/brand/` (skill: `brand-pack`)
    - **Stage 2 — Wedge validation + landing page + PRD** → produces `01-narrative/{PMF, LANDING, PRD}.md` (skill: `zero-to-prototype`)
+   - **Brand pack** → produces brand guidelines + summary + color palette + typography system + tone-of-voice (voice/messaging/copy) + logo guidelines into `06-product-ip/brand/` (skill: `brand-pack`)
    - **Stage 3 — Business plan** → produces `01-narrative/business-plan.md` (skill: `investor-data-room` Stage 3)
    - **Stage 3b — Term sheet** → produces `html/prospectus/term_sheet.html` (skill: `investor-data-room` Stage 3b)
    - **Stage 4 — Deck blueprint** → produces `01-narrative/deck-blueprint.md` (skill: `investor-data-room` Stage 4)
@@ -96,6 +97,10 @@ When the operator's intent matches a row but the scaffold does not yet exist, ru
 - If a section reveals a new artefact the operator wants (e.g. a competitor-claims-rebuttal in `08-market/`), `work-create` a new Task under the same Project, then proceed.
 - The Project's health signal (green/amber/red) is computed from Task state. Use `project-get` at the start of each turn to surface what's outstanding.
 
+## Research routing
+
+Every structured-research task — market sizing (TAM/SAM/SOM + CAGR), compliance research (DMCC / ICO ADM / EU AI Act), competitor scans, comparable rounds and exit comparables, named-acquirer enumeration — routes through the `research-assistant` specialist with the five `deep-research` skills (`deep-research`, `book-mirror`, `strategic-reading`, `academic-verify`, `data-research`). Dispatch the specialist; do not call `WebSearch` or `WebFetch` directly from a venture-studio skill. The specialist returns structured findings with citations the data-room artefacts can quote verbatim.
+
 ## Tone
 
 Founder-facing. Direct, evidence-based, no flattery. You are the chief of staff for a one-person founding team — your job is to keep every artefact tracked and every deadline visible, while the operator focuses on the parts only they can do (customer conversations, founder signal, vision).

package/payload/platform/plugins/venture-studio/bin/scaffold.sh

@@ -64,8 +64,8 @@ PAYLOAD=$(cat <<JSON
   "tier": "full",
   "workItems": [
     {"name": "Stage 1 — Office-hours design doc", "description": "Produces 01-narrative/office-hours-design.md via the office-hours skill."},
-    {"name": "Brand pack", "description": "Produces brand identity (palette, typography, logo) into 06-product-ip/brand/ via the brand-pack skill."},
     {"name": "Stage 2 — Wedge validation + landing page + PRD", "description": "Produces 01-narrative/{PMF,LANDING,PRD}.md via the zero-to-prototype skill."},
+    {"name": "Brand pack", "description": "Produces brand guidelines + summary + color palette + typography system + tone-of-voice (voice/messaging/copy) + logo guidelines into 06-product-ip/brand/ via the brand-pack skill."},
     {"name": "Stage 3 — Business plan", "description": "Produces 01-narrative/business-plan.md via investor-data-room Stage 3."},
     {"name": "Stage 3b — Term sheet", "description": "Produces html/prospectus/term_sheet.html via investor-data-room Stage 3b."},
     {"name": "Stage 4 — Deck blueprint", "description": "Produces 01-narrative/deck-blueprint.md via investor-data-room Stage 4."},

package/payload/platform/plugins/venture-studio/skills/brand-pack/SKILL.md

@@ -39,7 +39,7 @@ Before generating anything, gather the following. Ask all questions in a single
 - Website URL (fetch it if provided — extract existing colors, fonts, tone)
 - Inspiration brands (brands they admire aesthetically)
 
-If the user provides a URL, use the fetch tool to read it and extract: dominant colors (check CSS or visual description), font choices, tone of copy, and any existing brand signals. Pre-fill your recommendations based on this research.
+If the user provides a URL — their own site, a competitor brand, or an inspiration brand — dispatch the `research-assistant` specialist (with `deep-research` for site copy + visual scan, `WebFetch` available through the specialist) rather than calling `fetch` or `WebFetch` directly from this skill. The specialist returns: dominant colors (CSS or visual description), font choices, tone of copy, and any existing brand signals. Pre-fill your recommendations from the specialist's structured findings.
 
 ---
 

package/payload/platform/plugins/venture-studio/skills/investor-data-room/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: investor-data-room
-description: Use when a UK-domiciled founder needs to produce a full seed-raise pack from idea to deliverables: graph-structured data room, 15-section business plan, persuasive prospectus + formal term sheet (with FCA self-certification appendices), 12-slide deck blueprint, print-ready HTML+PDF for each. Trigger phrases include "build me a data room", "draft a business plan", "deck from the business plan", "draft an investment prospectus", "generate a term sheet", "from office hours to investor pack", "set up the fundraise repo". The skill never speculates on financial figures or cap-table values: every number traces to a Companies House filing, a financial model worksheet, or a source citation. Public-facing artefacts contain zero internal workings (no "reconciliation pending", no "open Q" markers, no comparison-to-baseline commentary). Design tokens are harmonised across business plan, prospectus, term sheet, and deck via the operator's project design-tokens spec.
+description: Use when a UK-domiciled founder needs to produce a full seed-raise pack from idea to deliverables: graph-structured data room, 16-section business plan, persuasive prospectus + formal term sheet (with FCA self-certification appendices), 13-slide deck blueprint, print-ready HTML+PDF for each. Trigger phrases include "build me a data room", "draft a business plan", "deck from the business plan", "draft an investment prospectus", "generate a term sheet", "from office hours to investor pack", "set up the fundraise repo". The skill never speculates on financial figures or cap-table values: every number traces to a Companies House filing, a financial model worksheet, or a source citation. Public-facing artefacts contain zero internal workings (no "reconciliation pending", no "open Q" markers, no comparison-to-baseline commentary). Design tokens are harmonised across business plan, prospectus, term sheet, and deck via the operator's project design-tokens spec.
 allowed-tools:
   - Bash
   - Read
@@ -25,13 +25,15 @@ Complete when the data room contains:
   README.md                                 # data-room index, status snapshot, doctrine
   01-narrative/
     office-hours-design.md                  # ideation working scratchpad
-    business-plan.md                        # 15-section business plan
-    deck-blueprint.md                       # 12-slide blueprint
+    business-plan.md                        # 16-section business plan
+    deck-blueprint.md                       # 13-slide blueprint
+    exit-thesis.md                          # named acquirers + recent exit comparables
   02-corporate-legal/
     README.md                               # incorporation filings, articles, board minutes
     incorporation-<co-house-no>-<date>.pdf  # IN01 + statement of capital + cap table
   03-cap-table/
     README.md                               # pre/post-investment cap table with PSC notes
+    comparables.md                          # recent comparable rounds (company / pre-money / post-money / multiple / source) cited by the term-sheet valuation
   04-financials/
     README.md
     model_worksheet.md                      # opening cash, capex, burn, MRR ramp, two-round
@@ -78,7 +80,9 @@ Skip stages that are already complete; do not regenerate stale artefacts blindly
 
 ## Stage 1 — Office-hours ideation
 
-Drive a conversational discovery session using the sibling `office-hours` skill. Output a single `office-hours-design.md` capturing:
+Drive a conversational discovery session using the sibling `office-hours` skill. Market sizing and competitor recon during discovery dispatch the `research-assistant` specialist with `deep-research` + `data-research` rather than calling `WebSearch` directly — every market figure that ends up in `08-market/sources.md` must trace to a structured-research citation.
+
+Output a single `office-hours-design.md` capturing:
 
 - Problem statement
 - Demand evidence (with numbers and dates)
@@ -113,22 +117,23 @@ References: `references/data-room-structure.md` for the section-by-section purpo
 
 ## Stage 3 — Business plan synthesis
 
-Generate `01-narrative/business-plan.md` with **15 sections** following the canonical structure:
+Generate `01-narrative/business-plan.md` with **16 sections** following the canonical structure:
 
 1. Executive Summary
 2. Vision and Mission (Vision / Mission / Doctrine triad)
 3. The Company (legal entity table + pre-investment cap table)
-4. The Market (TAM/SAM/SOM + structural tailwind + self-employed wedge + domestic adjacency + international upside + pricing)
+4. The Market (TAM/SAM/SOM bottoms-up with geography-tier floor + CAGR with citation + 3-yr market-expansion thesis + market-share trajectory to 3–8% SAM in 5 yrs + structural tailwind + self-employed wedge + domestic adjacency + international upside + pricing)
 5. The Product (what it is + wedge product + upsell path + substrate moat + conversation ingestion + network + Anthropic asymmetric capture + human-services layer)
-6. The Business Model (revenue streams + unit economics)
+6. The Business Model (revenue streams + unit economics — ACV, CAC, LTV, **LTV:CAC**, gross margin, **burn multiple**, churn — each a named line)
 7. Go-to-Market (Wedge → Beachhead → Blitzscale framework + demand evidence + GTM partners + horse-before-cart logic + geography)
 8. Competition (three failing categories + RANL differentiation + most-direct-competitor counter)
 9. Operations (technology stack + data sovereignty + IP ownership chain + compliance posture summary)
 10. Compliance and regulatory positioning (UK consumer protection + UK data/AI regime + EU AI Act + adjacent UK obligations + moat-not-tax close)
 11. Team (founders + strategic shareholders + hiring plan)
-12. Financial Plan (12.1 opening balance sheet through 12.7 use of funds)
+12. Financial Plan (12.1 opening balance sheet through 12.7 use of funds; valuation per round cites `03-cap-table/comparables.md`)
 13. Risks and Mitigations
 14. Milestones (the N-month thesis)
+14b. Exit thesis (target exit value + 5–8-year horizon + exit routes — strategic / PE / IPO — + 3–5 named acquirers with one-line rationale each)
 15. The bottom line (summary table + close)
 + Appendices (titled documents only; no internal-only file pointers)
 
@@ -140,7 +145,14 @@ Generate `01-narrative/business-plan.md` with **15 sections** following the cano
 - **Financial figures derive from the model worksheet.** Cite "Appendix A" by title.
 - **No em-dashes between alphabetic words** in user-facing prose (recurring style violation in this project's history; see `references/internal-workings-scrub.md`).
 
-Compliance research is mandatory before drafting Section 10. WebSearch (or equivalent) for: DMCC Act (UK consumer protection for estate-agency), ICO ADM framework (Articles 22A–22D under UK GDPR + ICO 2025 strategy), EU AI Act (force date, high-risk classification for property-financing decisions). Cite each.
+**Research routing across Stage 3.** Every figure sourced from the wider world routes through the `research-assistant` specialist — never raw `WebSearch` / `WebFetch` from this skill:
+
+- **Section 4 (Market)** — TAM/SAM/SOM citations, CAGR sourcing, market-share trajectory baselines, competitor rebuttal facts: dispatch `research-assistant` with `data-research`.
+- **Section 10 (Compliance)** — DMCC Act (UK consumer protection for estate-agency), ICO ADM framework (Articles 22A–22D under UK GDPR + ICO 2025 strategy), EU AI Act (force date, high-risk classification for property-financing decisions): dispatch `research-assistant` with `academic-verify` to retrieve the primary regulatory texts. Cite each in the body.
+- **Section 12 (Financial — valuation comparables)** — recent comparable rounds that feed `03-cap-table/comparables.md`: dispatch `research-assistant` with `data-research`.
+- **Section 14b (Exit thesis)** — 3–5 named acquirers (strategic / PE / IPO) with one-line rationale each, plus recent comparable exits (company / acquirer / multiple / year / source) that feed the exit section of `03-cap-table/comparables.md`: dispatch `research-assistant` with `data-research`.
+
+The specialist returns structured findings; the skill quotes those findings verbatim into the relevant section and into `08-market/sources.md` / `03-cap-table/comparables.md`.
 
 References: `references/business-plan-template.md` for the section-by-section template; `references/compliance-research-checklist.md` for the UK + EU regulatory regimes to verify.
 
@@ -172,20 +184,21 @@ References: `references/termsheet-template.md`.
 
 ## Stage 4 — Deck blueprint synthesis
 
-Generate `01-narrative/deck-blueprint.md` as a **12-slide brief** the deck designer can execute. Each slide has Purpose, Headline (one-line message), Body (bullets + figures pulled from the business plan), Visual suggestion, and Source reference. The 12 slides:
+Generate `01-narrative/deck-blueprint.md` as a **13-slide brief** the deck designer can execute. Each slide has Purpose, Headline (one-line message), Body (bullets + figures pulled from the business plan), Visual suggestion, and Source reference. The 13 slides:
 
 1. Cover (raise headline + founders)
 2. Vision (Vision / Mission / Doctrine)
-3. The Market (TAM + tailwind + wedge)
+3. The Market (TAM + tailwind + wedge + **CAGR with citation**)
 4. Business Model (subscription + service layer + unit economics)
 5. Go-to-Market (Wedge → Beachhead → Blitzscale + named partners)
 6. The Product (substrate + wedge + network + asymmetric capture + services layer)
 7. Competition (three failing categories + most-direct counter)
 8. The Team (founders + strategic shareholders)
-9. Economics (P&L summary + cash flow + break-even)
+9. Economics (P&L summary + cash flow + break-even + **LTV:CAC and burn multiple**)
 10. The Raise (size, valuation, dilution, instrument, use of funds, IP transfer, follow-on round)
-11. Milestones (M0 to M-final timeline)
-12. Other Information (compliance + platform dependency + contact)
+11. Exit (target exit value + 5–8-year horizon + routes — strategic / PE / IPO — + 3–5 named acquirers with one-line rationale)
+12. Milestones (M0 to M-final timeline)
+13. Other Information (compliance + platform dependency + contact)
 
 Production notes attached: format (16:9 landscape, PDF + source deck), design tokens reference (the operator's project design-tokens spec, path supplied at Stage 5 invocation), chart-source consistency with the financial model, speaker-note attribution.
 

package/payload/platform/plugins/venture-studio/skills/investor-data-room/references/business-plan-template.md

@@ -1,4 +1,4 @@
-# Business plan template — 15-section structure
+# Business plan template — 16-section structure
 
 The canonical structure used by `01-narrative/business-plan.md`. Every public-facing artefact (deck, prospectus, term sheet) derives from this file. Apply the internal-workings scrub (see `internal-workings-scrub.md`) on every revision.
 
@@ -14,13 +14,13 @@ Three blocks. **Vision.** Where the company ends up at full execution. **Mission
 Legal entity table (legal name, Companies House number, incorporation date, registered office, SIC, PSC status, sole proposed director on IN01) + pre-investment cap table (sourced from the IN01 verbatim) + post-investment dilution pointer.
 
 ### 4. The Market
-Subsections: Size of the addressable market (TAM with citation per figure); Structural tailwind (margin squeeze, regulatory tailwind, or equivalent); Self-employed wedge or analogous high-growth segment; Domestic adjacency (next-vertical expansion); International upside (channel partner enabling it); Pricing and TAM (per-customer ACV × addressable count = TAM number).
+Subsections: Size of the addressable market (TAM with citation per figure, bottoms-up construction; geography-tier floor — **late pre-seed TAM is expected to clear $1B US / $500M UK / $500M EU**, flag if the named geography sits below its floor); Market growth rate (single CAGR figure with citation + a one-line 3-year market-expansion thesis stating why the market gets bigger and why this company captures more share as it does); Market-share trajectory (path to 3-8% of SAM within 5 years, reconciled line-by-line against the ARR target in Section 12); Structural tailwind (margin squeeze, regulatory tailwind, or equivalent); Self-employed wedge or analogous high-growth segment; Domestic adjacency (next-vertical expansion); International upside (channel partner enabling it); Pricing and TAM (per-customer ACV × addressable count = TAM number).
 
 ### 5. The Product
 Subsections: What it is (substrate description, CRM-agnostic / data-sovereign positioning); The wedge product (narrowest unit of value, public-by-default if applicable); The upsell path (wedge → high-value output → full substrate); The substrate moat (operator-data + ontological graph + flywheel); Conversation ingestion (or equivalent lock-in mechanic); The network (federation thesis); Asymmetric-capture position (the LLM-binary wrap argument, with commercial-practice insurance); Human-services layer (training, support, white-glove, anti-fragile-against-frontier-AI).
 
 ### 6. The Business Model
-Revenue streams (subscription tiers + future network-effect revenue), unit economics (ACV, CAC, gross margin, churn placeholder), compute-mark-up doctrine ("never mark up the LLM compute; customer pays the LLM provider directly").
+Revenue streams (subscription tiers + future network-effect revenue). Unit economics — each metric is a named line: **ACV**, **CAC**, **LTV**, **LTV:CAC ratio** (target ≥ 3:1 by Month 12), **gross margin** (target ≥ 70% steady-state), **burn multiple** (net burn ÷ net new ARR; target ≤ 2× during wedge, ≤ 1× post-PMF), **churn** (logo + revenue). Compute-mark-up doctrine ("never mark up the LLM compute; customer pays the LLM provider directly").
 
 ### 7. Go-to-Market
 Wedge → Beachhead → Blitzscale framework (with months and funding source per phase), demand evidence (40+ EOIs, paid intents, founder dogfood, partnership status — every number cited), GTM partners (one row per named partner with role and source), horse-before-cart logic (public-first wedge that earns trust for the private high-value upsell), geography.
@@ -38,7 +38,7 @@ Three regulatory regimes: UK consumer protection (DMCC Act for estate agency / e
 Founders (foregrounded) with role + concise career summary + key credentials + pre-investment shareholding. Strategic shareholders from incorporation (advisors, family, JV partners on the cap table from day one). Hiring plan table with month-triggered roles + salary + trigger condition.
 
 ### 12. Financial Plan
-12.1 Opening balance sheet (M0 after capex). 12.2 Year-1 Income Statement (revenue + COGS + every opex line + depreciation + EBIT + corp tax + net loss). 12.3 Year-1 cash flow summary table (period-by-period opening, net flow, closing cash). 12.4 Closing balance sheet (M12). 12.5 Two-round funding strategy (timing, size, pre-money, purpose, gating evidence per round). 12.6 Contingency levers. 12.7 Use of funds (this round) by bucket.
+12.1 Opening balance sheet (M0 after capex). 12.2 Year-1 Income Statement (revenue + COGS + every opex line + depreciation + EBIT + corp tax + net loss). 12.3 Year-1 cash flow summary table (period-by-period opening, net flow, closing cash). 12.4 Closing balance sheet (M12). 12.5 Two-round funding strategy (timing, size, pre-money, purpose, gating evidence per round) — **valuation per round cites `03-cap-table/comparables.md`** (recent comparable rounds: company / pre-money / post-money / multiple / source). 12.6 Contingency levers. 12.7 Use of funds (this round) by bucket.
 
 ### 13. Risks and Mitigations
 Two-column table: risk + mitigation. Cover Loop / Anthropic / competitor-ships-earlier / wedge-fails-to-convert / founder-transition / counsel-delays / Round-2-market / investor-structure.
@@ -46,6 +46,9 @@ Two-column table: risk + mitigation. Cover Loop / Anthropic / competitor-ships-e
 ### 14. Milestones (the N-month thesis)
 Month-by-month table: M0 close + closing conditions; M1 first paying customer; M3 product-engineer hire + ~10 customers; M6 wedge phase complete; M7 Round 2 raise opens; M9 Round 2 closes; M12 break-even.
 
+### 14b. Exit thesis
+Target exit value (£m), horizon (5–8 years), exit routes considered (strategic acquisition, PE rollup, IPO) with a one-line view on which route is most likely and why. **3–5 named acquirers**, each with a one-line rationale (why they would buy: distribution gap, technology gap, defensive play, vertical entry). Sourced from `08-market/sources.md` and `03-cap-table/comparables.md` (recent exit comparables: company / acquirer / multiple / year / source). Body references "Appendix B" by title.
+
 ### 15. The bottom line
 Summary table of headline numbers (raise size, pre-money, post-money, dilution, runway, Y1 revenue/loss/cash-burn/closing-cash/ARR, break-even month, Round 2 timing/size). Closing paragraph.
 

package/payload/platform/plugins/venture-studio/skills/investor-data-room/references/data-room-structure.md

@@ -9,8 +9,9 @@ Standard ten numbered sections plus root README, internal-narrative subdirectory
 
 **Currently present.**
 - `office-hours-design.md` — APPROVED office-hours output (internal).
-- `business-plan.md` — 15-section public business plan.
-- `deck-blueprint.md` — 12-slide brief.
+- `business-plan.md` — 16-section public business plan.
+- `deck-blueprint.md` — 13-slide brief.
+- `exit-thesis.md` — target exit value, 5–8-year horizon, exit routes (strategic / PE / IPO), 3–5 named acquirers with one-line rationale each.
 
 ### 02-corporate-legal
 **Purpose.** Statutory documentation. First section any investor's lawyer asks for.
@@ -20,12 +21,12 @@ Standard ten numbered sections plus root README, internal-narrative subdirectory
 ### 03-cap-table
 **Purpose.** Who owns what, before and after the round. Most-scrutinised number in seed-stage diligence.
 
-**Standard contents.** Pre-investment cap table (per IN01), post-investment cap table (with dilution math), fully-diluted including option pool, founder vesting schedule (if any), share register, subscription letters.
+**Standard contents.** Pre-investment cap table (per IN01), post-investment cap table (with dilution math), fully-diluted including option pool, founder vesting schedule (if any), share register, subscription letters, `comparables.md` (recent comparable rounds — company / pre-money / post-money / multiple / source — that the term sheet's valuation cites).
 
 ### 04-financials
 **Purpose.** The investability of the raise: runway, burn, revenue ramp, break-even, contingency.
 
-**Standard contents.** `model_worksheet.md` (opening cash, capex, monthly burn, MRR ramp, two-round funding strategy, contingency levers), historical accounts (if any), bank statements, unit economics, VAT status.
+**Standard contents.** `model_worksheet.md` (opening cash, capex, monthly burn, MRR ramp, two-round funding strategy, contingency levers), historical accounts (if any), bank statements, unit economics (must include **LTV:CAC ratio** and **burn multiple** as named lines alongside ACV / CAC / LTV / gross margin / churn), VAT status.
 
 ### 05-commercial
 **Purpose.** Customer pipeline, demand evidence, GTM partners, route-to-revenue.
@@ -45,7 +46,7 @@ Standard ten numbered sections plus root README, internal-narrative subdirectory
 ### 08-market
 **Purpose.** Size of the prize, shape of demand, competitive landscape. Every market figure in the business plan must trace to a row in this section.
 
-**Standard contents.** `sources.md` (every figure with citation), `competitor-value-claims-rebuttal.md` (vendor-by-vendor rebuttal framework), TAM/SAM/SOM file, customer-segmentation analysis, regulatory landscape, international-expansion potential.
+**Standard contents.** `sources.md` (every figure with citation), `competitor-value-claims-rebuttal.md` (vendor-by-vendor rebuttal framework), TAM/SAM/SOM file (bottoms-up; **geography-tier floor** — late pre-seed TAM is expected to clear $1B US / $500M UK / $500M EU; flag any named geography that sits below its floor), `market-growth-rate.md` (single CAGR figure with citation + one-line 3-year market-expansion thesis), `market-share-trajectory.md` (path to 3–8% SAM within 5 years, reconciled to the ARR target in the business plan), customer-segmentation analysis, regulatory landscape, international-expansion potential.
 
 ### 09-operations
 **Purpose.** Day-to-day regulatory, compliance, and operational infrastructure.

package/payload/platform/plugins/venture-studio/skills/investor-data-room/references/deck-blueprint-template.md

@@ -1,23 +1,24 @@
-# Deck blueprint template — 12 slides
+# Deck blueprint template — 13 slides
 
 Each slide is specified by Purpose, Headline (one-line message), Body (bullets + figures pulled from the business plan), Visual suggestion, and Source reference. The deck is the presentation surface; the business plan is the source of truth.
 
-## 12-slide layout
+## 13-slide layout
 
 | # | Slide | What it lands |
 |---|---|---|
 | 1 | Cover | Company name, raise headline, three foregrounded founders, Companies House identifier. |
 | 2 | Vision | Vision / Mission / Doctrine triad. |
-| 3 | The Market | TAM with citation, structural tailwind (margin-squeeze / regulatory / equivalent), self-employed or analogous wedge, domestic adjacency, international upside, pricing band. |
+| 3 | The Market | TAM with citation, structural tailwind (margin-squeeze / regulatory / equivalent), self-employed or analogous wedge, domestic adjacency, international upside, pricing band, **CAGR with citation**. |
 | 4 | Business Model | Subscription tiers + hardware + service layer + future network-effect revenue + unit economics + compute-no-markup doctrine. |
 | 5 | Go-to-Market | Wedge → Beachhead → Blitzscale framework, demand evidence numbers, named GTM partners, horse-before-cart logic. |
 | 6 | The Product | Substrate description, wedge, upsell path, substrate moat, conversation ingestion, network, asymmetric capture, services layer. |
 | 7 | Competition | Three failing categories + most-direct-competitor counter (CRM-agnostic vs migration-required). |
 | 8 | The Team | Founders + strategic shareholders, with one-line credential per person and shareholding %. |
-| 9 | Economics | Y1 revenue, P&L loss, cash burn, M11 cash low, M12 closing cash, closing ARR, break-even month. Two-panel chart: MRR ramp with burn overlay + monthly cash balance. |
+| 9 | Economics | Y1 revenue, P&L loss, cash burn, M11 cash low, M12 closing cash, closing ARR, break-even month, **LTV:CAC and burn multiple**. Two-panel chart: MRR ramp with burn overlay + monthly cash balance. |
 | 10 | The Raise | Size, pre-money, post-money, dilution, instrument, use of funds, IP transfer at close, Round 2 size + timing, pre-emption. Pie chart of post-investment cap table. |
-| 11 | Milestones | M0 to M-final timeline with MRR curve and Round-1 / Round-2 close markers. |
-| 12 | Other Information | Compliance (DMCC + UK ICO + EU AI Act), platform-dependency disclosure with the commercial-practice-insurance answer, contact card (founders + email + web). |
+| 11 | Exit | Target exit value, 5–8-year horizon, exit routes (strategic / PE / IPO), 3–5 named acquirers with one-line rationale each. Sourced from `01-narrative/exit-thesis.md`. |
+| 12 | Milestones | M0 to M-final timeline with MRR curve and Round-1 / Round-2 close markers. |
+| 13 | Other Information | Compliance (DMCC + UK ICO + EU AI Act), platform-dependency disclosure with the commercial-practice-insurance answer, contact card (founders + email + web). |
 
 ## Production notes attached to the blueprint
 

package/payload/platform/plugins/venture-studio/skills/office-hours/SKILL.md

@@ -32,14 +32,13 @@ You are a **YC office hours partner**. Your job is to ensure the problem is unde
 
 ## Phase 1: Context Gathering
 
-Understand the project and the area the user wants to change.
+Understand the operator's business and the area they want to change.
 
-1. Read `CLAUDE.md`, `TODOS.md` (if they exist).
-2. Run `git log --oneline -30` and `git diff origin/main --stat 2>/dev/null` to understand recent context.
-3. Use Grep/Glob to map the codebase areas most relevant to the user's request.
-4. **List any prior office-hours design docs on disk** under the operator's project (e.g. the data-room `01-narrative/` directory when invoked from `venture-studio`, or the operator-supplied path otherwise). If prior designs exist, list them: "Prior designs for this project: [titles + dates]"
+1. Read any operator-supplied notes path the caller passed in (a brief, a market scan, a prior memo). If no path was passed, skip.
+2. **List any prior office-hours design docs on disk** under the operator's project: the data-room `01-narrative/` directory when invoked from `venture-studio`, or the operator-supplied project root otherwise. If prior designs exist, list them: "Prior designs for this project: [titles + dates]"
+3. For market, competitor, or prior-art recon, dispatch the `research-assistant` specialist with the `deep-research` skill rather than calling `WebSearch` directly. The specialist returns structured findings the design doc can cite.
 
-5. **Ask: what's your goal with this?** This is a real question, not a formality. The answer determines everything about how the session runs.
+4. **Ask: what's your goal with this?** This is a real question, not a formality. The answer determines everything about how the session runs.
 
    Via AskUserQuestion, ask:
 
@@ -56,7 +55,7 @@ Understand the project and the area the user wants to change.
    - Startup, intrapreneurship → **Startup mode** (Phase 2A)
    - Hackathon, open source, research, learning, having fun → **Builder mode** (Phase 2B)
 
-6. **Assess product stage** (only for startup/intrapreneurship modes):
+5. **Assess product stage** (only for startup/intrapreneurship modes):
    - Pre-product (idea stage, no users yet)
    - Has users (people using it, not yet paying)
    - Has paying customers
@@ -275,7 +274,7 @@ If no matches found, proceed silently.
 
 ## Phase 2.75: Landscape Awareness
 
-Read ETHOS.md for the full Search Before Building framework (three layers, eureka moments). The preamble's Search Before Building section has the ETHOS.md path.
+**Search Before Building — three layers, eureka moments.** Before proposing solutions, you check what the world already thinks about this space, so you can spot where conventional wisdom is wrong. The three layers are: (1) **existing solutions** — what people already use to solve this exact problem; (2) **adjacent solutions** — what they use to solve neighbouring problems that hint at the same job-to-be-done; (3) **eureka moments** — places where layers 1 and 2 reveal a shared assumption everyone is making that this session's evidence shows is wrong. A eureka moment is a single sentence: "Everyone does X because they assume Y, but the evidence we have suggests Y is wrong here." Layer 3 is the only layer that justifies building something different.
 
 After understanding the problem through questioning, search for what the world thinks. This is NOT competitive research (that's /design-consultation's job). This is understanding conventional wisdom so you can evaluate where it's wrong.
 
@@ -302,7 +301,7 @@ Read the top 2-3 results. Run the three-layer synthesis:
 - **[Layer 2]** What are the search results and current discourse saying?
 - **[Layer 3]** Given what WE learned in Phase 2A/2B — is there a reason the conventional approach is wrong?
 
-**Eureka check:** If Layer 3 reasoning reveals a genuine insight, name it: "EUREKA: Everyone does X because they assume [assumption]. But [evidence from our conversation] suggests that's wrong here. This means [implication]." Log the eureka moment (see preamble).
+**Eureka check:** If Layer 3 reasoning reveals a genuine insight, name it: "EUREKA: Everyone does X because they assume [assumption]. But [evidence from our conversation] suggests that's wrong here. This means [implication]." Record the eureka moment in the design doc's Premises section so it travels with the artefact.
 
 If no eureka moment exists, say: "The conventional wisdom seems sound here. Let's build on it." Proceed to Phase 3.
 

package/payload/platform/plugins/venture-studio/skills/zero-to-prototype/SKILL.md

@@ -284,6 +284,10 @@ For go-to-market planning:
 4. **Progress over perfection** — Ship, measure, iterate
 5. **Synthesis over summary** — Connect dots, don't just list facts
 
+## Research routing
+
+Customer-discovery prior-art lookups, prospect-finding (`references/boolean-search.md` invocations, Earlyvangelist identification), citation-backed claims (PMF benchmarks, market signal precedents), and academic-grade evidence all route through the `research-assistant` specialist with the `deep-research`, `data-research`, and `academic-verify` skills. Dispatch the specialist; do not call `WebSearch` or `WebFetch` directly from this skill. The specialist returns structured findings with citations the PMF, Landing, and PRD artefacts can quote.
+
 ## Framework Reference Files
 
 All frameworks are in `references/` directory:

package/payload/premium-plugins/real-agent/BUNDLE.md

@@ -1,6 +1,6 @@
 ---
 name: real-agent
-description: "UK estate agency skills + Loop CRM + PropertyData market analytics + single-address preval — 12 sub-plugins covering sales, listings, vendor management, buyer management, lead generation, coaching, business operations, teaching, Loop CRM, PropertyData, property brochures, and preval. 3 specialist roles (negotiator, valuer, compliance). 34 skills + 45 MCP tools."
+description: "UK estate agency skills + Loop CRM + PropertyData market analytics + single-address preval — 12 sub-plugins covering sales, listings, vendor management, buyer management, lead generation, coaching, business operations, teaching, Loop CRM, PropertyData, property brochures, and preval. 4 specialist roles (negotiator, valuer, compliance, listing-curator). 34 skills + 45 MCP tools."
 plugins:
   - estate-sales
   - listings
@@ -18,7 +18,7 @@ plugins:
 
 # Real Agent
 
-Premium plugin bundle for UK estate agency professionals. Shipped on every non-Maxy brand install (today: Real Agent); Maxy installs do not receive it. All 12 sub-plugins ship as a set, each independently activatable via `enabledPlugins`. Every admin boot walks every bundle under `premium-plugins/` (brand-gated — Maxy short-circuits) and reconciles `account.json` `enabledPlugins` against on-disk presence: any sub-plugin from the `plugins:` list above whose `platform/plugins/<sub>/PLUGIN.md` exists gets stamped via an idempotent set-union, so `mcp__loop__*` tools and the other sub-plugin surfaces are visible to the admin agent from the first turn after install — and on first boot post-deploy for accounts that already had the bundle on disk from a prior install. Disable individual sub-plugins with `plugin-toggle-enabled`. The bundle also delivers three specialist roles (negotiator, valuer, and compliance) that embed domain knowledge from the sub-plugins and operate autonomously with Loop CRM tools.
+Premium plugin bundle for UK estate agency professionals. Shipped on every non-Maxy brand install (today: Real Agent); Maxy installs do not receive it. All 12 sub-plugins ship as a set, each independently activatable via `enabledPlugins`. Every admin boot walks every bundle under `premium-plugins/` (brand-gated — Maxy short-circuits) and reconciles `account.json` `enabledPlugins` against on-disk presence: any sub-plugin from the `plugins:` list above whose `platform/plugins/<sub>/PLUGIN.md` exists gets stamped via an idempotent set-union, so `mcp__loop__*` tools and the other sub-plugin surfaces are visible to the admin agent from the first turn after install — and on first boot post-deploy for accounts that already had the bundle on disk from a prior install. Disable individual sub-plugins with `plugin-toggle-enabled`. The bundle also delivers four specialist roles (negotiator, valuer, compliance, listing-curator) that embed domain knowledge from the sub-plugins and operate autonomously with Loop CRM and memory tools.
 
 ## Specialist Roles
 
@@ -27,6 +27,7 @@ Premium plugin bundle for UK estate agency professionals. Shipped on every non-M
 | Negotiator | `agents/negotiator.md` | All Loop CRM tools + memory-search | Buyer pipeline, viewings, feedback, offers, deal progression |
 | Valuer | `agents/valuer.md` | Loop property/people tools + memory-search | Market appraisal preparation, comparable evidence analysis |
 | Compliance | `agents/compliance.md` | All Loop CRM tools + memory-search + perplexity-search | UK estate agency law, listing audit, AML/KYC, regulatory compliance |
+| Listing Curator | `agents/listing-curator.md` | memory-search + memory-write + memory-update + Loop property/team tools | Ingestion of property listings into typed `:Listing` nodes — maps Loop CRM records, published zip-site directories, and manual operator dumps to renderable graph entities so the public agent can surface them as property cards |
 
 ## Sub-Plugins
 

package/payload/premium-plugins/real-agent/agents/listing-curator.md

@@ -0,0 +1,133 @@
+---
+name: listing-curator
+description: "Property listing ingestion. Maps any property-shaped input — a Loop CRM record, a published zip-site directory, or a manual operator dump — to one typed :Listing node that the public agent's memory-search can return as a renderable property card. Delegate when a property listing needs to enter the graph, when an existing Listing's status drifts (for-sale → under-offer → sold), or when a hosted property site has been published and the graph has no record of it yet."
+summary: "Your listing curator — maps property inputs to typed :Listing nodes that visitor-facing chat can render."
+model: claude-sonnet-4-6
+tools: mcp__memory__memory-search, mcp__memory__memory-write, mcp__memory__memory-update, mcp__loop__loop-property-search, mcp__loop__loop-property-detail, mcp__loop__loop-property-listed, mcp__loop__loop-property-sold, mcp__loop__loop-key-list, mcp__loop__loop-team-info
+---
+
+# Listing Curator
+
+You are the listing curator. You own one outcome: any property-shaped input that crosses the realagent boundary leaves the graph as a `:Listing` node carrying the renderable contract from `schema-estate-agent.md`. Generic ingestion specialists (`database-operator`) and hosting flows are not allowed to mint property data — that work routes here so the doctrine is enforced in one place.
+
+You receive a brief from the admin agent. You read the source, map it field-by-field, and write the Listing. You return the new `:Listing`'s `slug` and the action you took (`create` / `update` / `no-op`).
+
+## Outcome contract
+
+For every property-shaped input the curator returns one `:Listing` node satisfying `schema-estate-agent.md`'s required-property set, idempotent on `(accountId, sourceSystem, sourceId)`. The Listing always carries the parent edge `(:Listing)-[:LISTED_BY]->(:LocalBusiness)` naming the estate agency; when a structural `:Property` node is known, additionally `(:Listing)-[:FOR_PROPERTY]->(:Property)`.
+
+Three legal action outcomes:
+
+- **`create`** — no Listing existed at `(accountId, sourceSystem, sourceId)`; one was written.
+- **`update`** — a Listing existed; its mutable fields were refreshed (status, price, blurb, images, lastVerifiedAt). The `slug`, `sourceSystem`, and `sourceId` are immutable on update.
+- **`no-op`** — the source record could not be mapped to a complete Listing (see "Source rejection" below). No write occurred. The brief is returned to the admin agent with an explanation.
+
+Anything else — emitting a `:KnowledgeDocument` instead of a `:Listing`, leaving renderable fields null on a `for-sale` listing, creating a second Listing for a re-ingested source record — is a defect.
+
+## Source mapping
+
+### Loop CRM record → Listing
+
+The Loop CRM record format you receive (either piped in by the brief or fetched via `mcp__loop__loop-property-detail`) carries a flat `body` text plus structured `loopPropertyId`. Parse with these rules:
+
+| Listing field | Source |
+|---|---|
+| `accountId` | inherited from the curator's session env |
+| `slug` | derived from address: lowercase, ASCII-only, dash-separated; collapse repeated dashes; strip leading/trailing dashes. Example: `griffin-house-upper-church-street-chepstow` |
+| `displayName` | the `name` field on the source record (already human-formatted), e.g. `Listing Particulars — Griffin House, Upper Church Street, Chepstow NP16 5EX` — strip the `Listing Particulars — ` prefix if present |
+| `sourceSystem` | literal `"loop-crm"` |
+| `sourceId` | the `loopPropertyId` field as string |
+| `listingType` | from the FACTS block `Type of listing:` (`sale` or `let`); default `sale` when absent |
+| `status` | from FACTS `Status:` value normalised — `Available` → `for-sale`, `Under Offer` → `under-offer`, `Sold STC` / `Sold` → `sold`, `Withdrawn` → `withdrawn`. When absent default `for-sale` |
+| `price` | from FACTS `Price:` — strip `£` and commas, parse integer (pounds, not pence; convert if necessary) |
+| `priceQualifier` | from any `Guide Price` / `Offers Over` / `OIEO` / `POA` keyword preceding the price |
+| `bedrooms`, `bathrooms`, `receptionRooms` | integers from FACTS `Bedrooms:`, `Bathrooms:`, `Receptions:` |
+| `floorAreaSqft` | from FACTS `Square Feet:` or `Floor Area:` — parse integer |
+| `propertyType` | from FACTS `Type:` — lowercase the value (`cottage`, `detached`, `flat`, etc.) |
+| `tenure` | from FACTS `Tenure:` — normalise to `freehold` / `leasehold` / `share-of-freehold` / `commonhold` |
+| `postcode` | extracted from `displayName` by the trailing UK postcode regex `[A-Z]{1,2}[0-9][A-Z0-9]? ?[0-9][A-Z]{2}` — normalised to upper-case with a single space before the inward code (`NP16 5EX`) |
+| `addressLine`, `town` | parsed from the `displayName` minus the postcode tail |
+| `description` | the full source `body` text, with the FACTS block stripped (keep the narrative paragraphs only) |
+| `imageUrls`, `heroImageUrl`, `floorplanUrls`, `epcUrl` | from the Loop property-detail call — `mcp__loop__loop-property-detail` returns these arrays; `heroImageUrl` is `imageUrls[0]` |
+| `pageUrl` | from the Loop property-listed call — the Rightmove / Zoopla / OnTheMarket / agent-website URL for the listing |
+| `blurb` | derived from `description` by a single Haiku call: "Write a single marketing-grade sentence (≤ 280 characters) summarising this UK property listing to a prospective buyer. No estate-agent clichés (no 'rare opportunity', 'must-see', 'stunning'). Plain English. Return only the sentence." Fallback when the LLM fails or returns >280 chars: take the first 280 characters of `description`, normalise whitespace, end on a word boundary |
+| `sourceSystem`, `sourceId`, `ingestedAt`, `lastVerifiedAt` | provenance — set on every write |
+| `scope` | `"public"` for any Listing with `status` in `for-sale` / `under-offer` / `sold` (visitor-renderable). `"shared"` for off-market / withdrawn / pre-marketing pipeline (staff-only) |
+
+### Zip-site / hosted-page directory → Listing
+
+When a property site has been published from operator-supplied assets, the directory follows the format produced by `property-brochure:property-extract`:
+
+```
+<property-slug>/
+  property.json        # structured fields
+  hero.jpg | hero.png  # primary image
+  photos/              # full image set
+  floorplans/          # floorplan images
+  epc.pdf | epc.png    # EPC document
+  description.md       # full descriptive copy
+```
+
+Map directly:
+
+| Listing field | Source |
+|---|---|
+| `slug` | the directory basename |
+| `displayName`, `addressLine`, `town`, `postcode`, `priceGBP` (`→ price`), `priceQualifier`, `bedrooms`, `bathrooms`, `receptionRooms`, `floorAreaSqft`, `propertyType`, `tenure` | `property.json` keys with the same names (Schema.org camelCase already enforced upstream) |
+| `description` | `description.md` body |
+| `heroImageUrl` | the published URL of `hero.jpg` (passed in by the hosting agent, never invented) |
+| `imageUrls` | published URLs of `photos/*` in directory order — `heroImageUrl` is included at index 0 |
+| `floorplanUrls` | published URLs of `floorplans/*` |
+| `epcUrl` | published URL of `epc.pdf` |
+| `pageUrl` | the live URL the hosting agent emits for `<property-slug>/index.html` |
+| `sourceSystem` | literal `"zip-upload"` |
+| `sourceId` | the directory basename (the slug) — directory basename is the operator-chosen natural key |
+| `blurb` | same LLM rule as the Loop path; same fallback |
+| `status` | from `property.json#status`; default `for-sale` |
+| `scope` | `"public"` |
+
+### Manual operator dump → Listing
+
+Format: operator pastes a property brief into chat. The curator parses with the same rules as the Loop path (key-value FACTS-style extraction), then asks the operator for any missing required field before writing. `sourceSystem: "manual"`; `sourceId` is whatever natural key the operator gives — they confirm uniqueness.
+
+## Source rejection — when not to write
+
+Write a `no-op` (no Listing produced; admin agent informed) when:
+
+- The source has no FACTS block AND no parseable address — there is no `slug` to derive and no `displayName`. The source is metadata about a property the curator hasn't yet been given.
+- The source declares `status: "off-market"` AND no `pageUrl` is known. These records describe stock not visible to visitors; they belong as `:KnowledgeDocument`-style notes on the linked Property, not as Listings. The admin agent is told to route to the database-operator if the operator wants the note retained.
+- The source's `accountId` cannot be resolved (no LocalBusiness in session env). Listings without a `LISTED_BY` parent cannot be written.
+
+`no-op` is loud — the curator returns a one-sentence explanation of which field was missing. Silent skips are defects.
+
+## Idempotency and update semantics
+
+Every write executes `MERGE (l:Listing {accountId, sourceSystem, sourceId})`. On match, mutable fields are SET to the new values; immutable fields (`slug`, `sourceSystem`, `sourceId`, `createdAt`) are left untouched. The `lastVerifiedAt` timestamp is updated on every run; `ingestedAt` is set only on the first write.
+
+`status` is mutable and expected to drift over the listing's life — `for-sale` → `under-offer` → `sold` / `withdrawn`. Repeat curation runs are how that drift lands in the graph.
+
+`slug` is immutable on update. If the source's `displayName` changes after first ingest (e.g. an address typo was fixed in Loop), the slug stays at its first-write value to keep the visitor-facing URL stable. If a slug truly must change, that's an operator decision routed via `memory-update`, not a silent curator rewrite.
+
+## Migration of legacy `KnowledgeDocument(source: "loop-crm")` records
+
+The realagent-code Pi (`192.168.88.16`, Neo4j `bolt://localhost:7688`) holds 29 historical `KnowledgeDocument` nodes with `source: "loop-crm"` carrying the flat `body` text. These predate the curator and must be migrated to `:Listing` nodes.
+
+The migration choice: **delete the source `KnowledgeDocument` after the matching `:Listing` is written.** The full `body` text is preserved as the Listing's `description` property — no information is lost — so a parallel raw-record node would be duplicate content. The `KnowledgeDocument` had no incoming edges (per the existing graph state) so deletion is safe; if a future ingestion path needs the raw body retained, the curator's `description` field already holds it.
+
+The migration cypher is run once via SSH against the Pi as a manual backfill step; it is not part of the curator's per-record write path. The doctrine the curator carries forward is: any future Loop record passes through the curator on the first write, not as a `:KnowledgeDocument`.
+
+## Observability
+
+One structured log line per write, emitted by the curator before returning to the admin agent:
+
+```
+[listing-curator] event=property-curated slug=<slug> sourceSystem=<system> sourceId=<id> action=<create|update|no-op> fieldsFilled=<comma-separated-list> fieldsMissing=<comma-separated-list> scope=<scope>
+```
+
+`fieldsMissing` is the load-bearing signal. Operators reading the log see at a glance which curations landed incomplete (e.g. `epcUrl` missing on a Loop record means the EPC asset wasn't uploaded to Loop yet; `pageUrl` missing on a zip-site Listing means the hosting agent didn't pass the published URL through to the curator). Each missing field is a discoverable defect upstream of the curator, not a curator failure.
+
+## Out of scope
+
+- Producing the visitor-facing markdown card from a `:Listing`. That's the public agent's job (a separate skill, blocked on this curator's existence; see `.tasks/`).
+- Inferring missing market-data fields (sold-price comps, demand) — that's the `property-data` MCP, not curator.
+- Writing Property structural fields when the source only carries listing data — Properties are created by the curator only when the source actually provides `tenure`, `epcRating`, etc.; otherwise the Listing stands on its own with the `LISTED_BY` parent edge.