@rubytech/create-siteoffice-code 0.1.256

package/payload/platform/plugins/linkedin-import/.claude-plugin/plugin.json

@@ -0,0 +1,8 @@
+{
+  "name": "linkedin-import",
+  "description": "Import a LinkedIn Basic Data Export into the Maxy Neo4j graph. Skill-only plugin owned by the librarian specialist. Opt-in per brand — not enabled by default.",
+  "version": "0.1.0",
+  "author": {
+    "name": "Rubytech LLC"
+  }
+}

package/payload/platform/plugins/linkedin-import/PLUGIN.md

@@ -0,0 +1,27 @@
+---
+name: linkedin-import
+description: "Import a LinkedIn Basic Data Export into the Maxy Neo4j graph. Skill-only plugin owned by the librarian specialist. Opt-in per brand — not enabled by default."
+tools: []
+always: false
+embed: false
+specialist: librarian
+metadata: {"platform":{"optional":true,"pluginKey":"linkedin-import"}}
+---
+
+# LinkedIn Import
+
+Ingests a LinkedIn Basic Data Export (unzipped directory of CSVs + subdirectories) into the Maxy Neo4j graph. Skill-only plugin — no MCP server, no admin tools added. The skill runs under the `specialists:librarian` specialist, which owns foreground archive and document ingestion.
+
+## When this applies
+
+The admin agent delegates to `specialists:librarian` when the operator drops a `Basic_LinkedInDataExport_*` directory (or references one by path) into chat. The specialist runs the skill's archive-owner confirmation flow before any CSV is read, then ingests the CSVs the skill has references for.
+
+## Intra-plugin growth
+
+A LinkedIn export contains ~20 CSVs. The skill ships references for `Profile.csv` and `Connections.csv` today — additional CSVs (Messages, Positions, Skills, Endorsements, Recommendations, Articles, Education, Certifications, Invitations, etc.) land as **new reference files inside this same plugin** under `skills/linkedin-import/references/` as each is authored. They do not become new plugins.
+
+## Relationship to other plugins
+
+- **contacts** — CRM surface. LinkedIn-imported `:Person` nodes are visible via `contact-list`, but ingestion does not go through contact tools.
+- **memory** — the underlying Cypher-write surface used by the skill (`memory-write`, `memory-update`). The skill is parameterised so all writes carry `source='linkedin'` + `createdByAgent='linkedin-import'` for provenance.
+- **librarian specialist** — owns execution. See [admin/IDENTITY.md](../../../platform/templates/agents/admin/IDENTITY.md) delegation clause.

package/payload/platform/plugins/linkedin-import/skills/linkedin-import/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: linkedin-import
+description: Import a LinkedIn Basic Data Export into a {{productName}} Neo4j graph. Triggers when the user asks to import a LinkedIn archive, ingest LinkedIn connections/messages/positions into the graph, or mentions a `Basic_LinkedInDataExport_*.zip` folder. One reference per CSV under `references/`; edges come from what each CSV naturally encodes, never from synthetic "anchor" patterns.
+---
+
+# LinkedIn Import
+
+**Invoked from `specialists:librarian`** when the operator drops a LinkedIn Basic Data Export (`Basic_LinkedInDataExport_*`) directory or references one by path. The admin agent dispatches the librarian; the librarian loads this skill.
+
+**Default parent.** Every `:Person`, `:Organization`, `:Position`, `:Skill`, and `:Message` node this skill writes is anchored to the archive-owner `:Person` (the user whose LinkedIn account produced the export). That Person is itself anchored to the account's `:LocalBusiness`. The archive owner's elementId is the first thing this skill confirms — without it, every row would land as an orphan and the importer refuses to start. Cross-hierarchy edges (`CONNECTED_ON_LINKEDIN`, `WORKS_FOR`, `HAS_SKILL`) describe the relationships; the containment edge from the archive owner is what makes the rows reachable.
+
+Ingests a LinkedIn Basic Data Export (unzipped directory of CSVs + subdirs) into a {{productName}} Neo4j graph. Every edge written corresponds to a real relationship expressed by the data — not a convenience anchor.
+
+## Archive-owner confirmation (mandatory first step)
+
+A LinkedIn archive belongs to exactly one person — the user whose LinkedIn account produced the export. That person is the subject of every row in the archive: every `CONNECTED_ON_LINKEDIN` edge points from them to a contact, every `WORKS_FOR` edge on `Positions.csv` belongs to them, every `HAS_SKILL` edge on `Skills.csv` is theirs.
+
+**Who the archive belongs to is not inferred from who runs the skill.** Joel may be ingesting his own archive today, a business partner's archive next week, or both side-by-side. The skill takes the archive owner as an explicit input and refuses to proceed until it is confirmed.
+
+The confirmation flow:
+
+1. List every `:AdminUser` in the graph and display each as `{userId, name, createdAt, accountId(s) via ADMIN_OF}`.
+2. Ask the operator to name the archive owner. Accept one of:
+   - An existing AdminUser userId from the list (typical — Joel's own archive, or a partner who is already a {{productName}} operator).
+   - A new external Person identity (not-yet-an-AdminUser) — create a fresh `:Person` with `givenName`, `familyName`, `email`/`telephone` (at least one) and use its `elementId` as the owner anchor. This path covers ingesting a non-operator's archive for reference.
+3. Echo the chosen owner back verbatim (`userId=<id> name=<name>`) and require explicit yes/no confirmation before any CSV is touched.
+4. Persist the confirmed owner as `$ownerUserId` (for AdminUser-type owners) or `$ownerPersonId` (for external Person owners) — this parameter flows into every reference.
+
+Refusing to assume is load-bearing: a hard-coded "it's whoever's running this" would misattribute a partner's connections to the operator on first re-use.
+
+## Anchor shape
+
+When the owner is an AdminUser (the common case):
+
+```
+(:AdminUser {userId: $ownerUserId}) -[:HAS_PROFILE]-> (:UserProfile {accountId, userId})
+```
+
+Both nodes already exist for any {{productName}} operator — the HAS_PROFILE edge is MERGEd by [`platform/ui/app/lib/neo4j-store.ts`](../../../../ui/app/lib/neo4j-store.ts) at session start. The LinkedIn import updates these existing nodes; it does not create parallel operator identities.
+
+- **Identity + account-scoped behaviour** → `:AdminUser` and `:UserProfile` (existing, unchanged).
+- **LinkedIn profile enrichment** (headline, summary, websites, industry, geoLocation) → property updates on `:UserProfile`.
+- **LinkedIn activity edges** (`CONNECTED_ON_LINKEDIN`, `WORKS_FOR`, `ATTENDED`, `HAS_SKILL`, `HOLDS_CREDENTIAL`, `FOLLOWS`, `AUTHORED`, `PARTICIPANT_IN`) → subjects are the `:AdminUser` (device-level facts: "I know this person") or `:UserProfile` (account-scoped facts: "in this brand I am skilled at X"). Each reference states which and why.
+
+When the owner is an external Person (non-operator archive), the anchor is the confirmed `:Person` node instead — same edges, different anchor.
+
+## Invariants
+
+1. **Schema first.** The LinkedIn additions (`person_linkedin_url` index, `:Credential` constraint) live in [`platform/neo4j/schema.cypher`](../../../../neo4j/schema.cypher) and are applied by `platform/scripts/seed-neo4j.sh` on every install / upgrade. The skill assumes the schema has been seeded; it does not bootstrap schema itself. If a constraint or index is missing, the operator re-runs `seed-neo4j.sh` from the installer — schema-bootstrap is installer-side, never agent-side.
+2. **Owner confirmed first.** No reference runs until `$ownerUserId` (or `$ownerPersonId`) is persisted and echo-confirmed. The reference set is parameterised — no hard-coded owner.
+3. **Natural edges only.** Every edge written is one the CSV actually expresses. `Connections.csv` encodes "I am connected on LinkedIn to this person" — that becomes `CONNECTED_ON_LINKEDIN`. No synthetic attach-to-owner pattern bolted onto rows that don't describe a relationship to the owner.
+4. **Reuse {{productName}} labels.** Schema-extension is last resort. The LinkedIn set maps onto existing labels wherever semantics align:
+   - LinkedIn companies → `:Organization` (existing, memory-write registered).
+   - LinkedIn schools → `:Organization` with `organizationCategory: 'educational'`.
+   - LinkedIn skills → `:DefinedTerm` with `category: 'linkedin-skill'`.
+   - LinkedIn articles → `:CreativeWork` with `category: 'linkedin-article'`.
+   - LinkedIn recommendations → `:Review`.
+   - LinkedIn DMs → routed to the `conversation-archive` skill (Task 397) as a `--source linkedin-messages` invocation. Each DM thread becomes one `:ConversationArchive` parent with `:Section` chunks; no bespoke LinkedIn sublabels.
+   - Certifications → `:Credential` (genuinely new — no existing {{productName}} label fits `schema:EducationalOccupationalCredential`).
+5. **Schema-base property names.** `givenName` / `familyName` / `telephone` / `dateSent` — not `firstName` / `phone` / `sentAt`. See [`platform/plugins/memory/references/schema-base.md`](../../../../plugins/memory/references/schema-base.md).
+6. **Schema-base edge names.** `(:Person)-[:WORKS_FOR]->(:Organization)` for positions. Custom LinkedIn edges (`CONNECTED_ON_LINKEDIN`, `ENDORSED`) only where schema-base has no canonical name.
+7. **Provenance stamp.** Every new node: `createdByAgent='linkedin-import'`, `createdBySource='linkedin-import'`, `createdBySession=$sessionId` (UUID per skill run), `createdAt=datetime()`, plus `source='linkedin'` as the data-origin marker.
+8. **Idempotent MERGE.** Re-running any reference after a fresh export updates properties without duplicating nodes.
+
+## Execution model
+
+1. Run the owner-confirmation flow, persist `$ownerUserId` / `$ownerPersonId`. The owner identity resolves to a single `ownerNodeId` (elementId of the AdminUser or external Person) used in every write call.
+2. For each file the operator approves, load its reference, parse the CSV into typed `rows[]` matching the reference's row schema.
+3. **Selective-ingest gate.** Before invoking any write tool, check the parsed row count against the reference's `selectiveIngestThreshold`. If the count exceeds the threshold, pause and ask the operator to filter the import along the natural axes named in the reference (for `Connections.csv`: Company, Position, Connected On). Apply the filter to `rows[]` before continuing. Compress on write, never after — a 5,000-row blanket import is a landfill, a 200-row filtered import is signal. See [§Selective-ingest](#selective-ingest-threshold-bulk-archives).
+4. Invoke the deterministic write tool the reference names. For all archive references this is `mcp__plugin_memory_memory__memory-archive-write` with `{archiveType, ownerNodeId, rows}` — the Cypher body is fixed server-side per `archiveType`, so the agent supplies parsed rows, never Cypher. The tool batches rows at 500 per transaction internally.
+5. After each file emit `[linkedin-import] file=<name> rows=<n> created=<n> matched=<n> ms=<elapsed>` using the counters returned by the write tool.
+
+**Doctrine:** raw Cypher and `cypher-shell` invocations are forbidden in this skill and its references. Writes route through `mcp__plugin_memory_memory__memory-archive-write` (bulk archives) or `mcp__plugin_memory_memory__memory-write` / `mcp__plugin_memory_memory__memory-update` (single-node enrichments like `profile.md`). If a CSV needs a write shape no current MCP tool supports, file a task to extend `memory-archive-write` with a new `archiveType` handler — never improvise via Bash. See [librarian's LOUD-FAIL prerogative](../../../../templates/specialists/agents/librarian.md#prerogatives).
+
+**LOUD-FAIL on parse errors (structurally enforced).** When LinkedIn parser tools land that follow the `mcp__*__*-import-parse` naming convention, the harness-level `platform/plugins/admin/hooks/archive-ingest-surface-gate.sh` will record an `isError: true` response and block every subsequent tool call this turn until the operator submits the next prompt. The hook also denies edits to `platform/plugins/*/lib/*` and JavaScript test runners (`vitest`, `bun test`, `npm test`, `npx jest`) unconditionally. The skill's "no Bash improvisation" doctrine above is the contract; the hook is the enforcement. See [.docs/hooks.md](../../../../../.docs/hooks.md) for the full gate surface.
+
+## Selective-ingest threshold (bulk archives)
+
+A LinkedIn export typically contains 3,000–10,000 connections. Writing all of them in one shot defeats compression-on-write — most rows will never be queried, and the noise compounds with every subsequent ingest. The skill compresses by interrogating the operator before bulk writes.
+
+**Threshold:** when a parsed reference's `rows[]` exceeds **100 rows**, pause and ask the operator to filter along the reference's natural axes before invoking the write tool.
+
+For `Connections.csv` the natural filter axes are:
+
+- **Company** — "only people at LargeCorp", "only Female Founders Fund alumni"
+- **Position** — "only Partners", "only Engineering Managers"
+- **Connected On** (date range) — "only my last two years", "since 2024-01-01"
+
+The operator picks one axis or a combination. The agent applies the filter to `rows[]` and writes only the filtered subset.
+
+**Re-importing is idempotent.** Coming back later with a wider filter (`"add anyone at LargeCorp"`, `"include 2022 too"`) hits the same `linkedinUrl` natural key — existing `:Person` nodes are matched and updated; only the new-only delta is created. The operator can grow the slice over time without dedup work.
+
+**Why the threshold lives in the skill, not the server.** Different archive types have different "interesting" thresholds — 100 LinkedIn connections is a lot; 100 LinkedIn skills is small. The MCP tool accepts whatever rows are passed; the conversational gate is the skill's responsibility.
+
+## File roster
+
+What's shipped today:
+
+| File | Reference | Edges produced |
+|------|-----------|----------------|
+| `Profile.csv` | [profile.md](references/profile.md) | enrichment on `:UserProfile` (no new nodes) |
+| `Connections.csv` | [connections.md](references/connections.md) | `(:AdminUser)-[:CONNECTED_ON_LINKEDIN {connectedOn}]->(:Person)` + `(:Person)-[:WORKS_FOR {title}]->(:Organization)` |
+| `messages.csv` (and the three other DM CSVs) | conversation-archive (Task 397) | dispatched to `conversation-archive` skill with `--source linkedin-messages`; one `:ConversationArchive` per DM thread + `:Section` chunks + `(:Person)-[:PARTICIPANT_IN]->(archive)` |
+
+Additional CSVs in the export (Positions, Education, Skills, Endorsements, Recommendations, Company Follows, Articles, Jobs, etc.) land as new references when the operator asks for them — each is its own follow-up.
+
+## Explicitly out of scope
+
+- `Ad_Targeting.csv` — LinkedIn-inferred ad segments, no graph value.
+- `Rich_Media.csv` — time-limited signed LinkedIn CDN URLs; files 404 after expiry.
+- `Private_identity_asset.csv` — duplicates `Profile.csv` summary text.
+- `Profile Summary.csv` — empty in this export.
+- `Job Applicant Saved Screening Question Responses.csv` — ephemeral Q&A, no stable identity.
+
+Add a new reference if any of these later become useful — nothing silently flows in.
+
+## Natural-edge discipline (why this matters)
+
+The rule isn't "every node must have an edge". The rule is "every node must have the edges its source data actually describes, and no synthetic ones bolted on to satisfy a check." A LinkedIn archive satisfies the orphan doctrine trivially: every row expresses a relationship between the archive owner and someone or something else. If a future file turns out to describe entities with no relationship to the owner (an endorsement between two third parties, say), the reference for that file writes the entities with their natural edges and doesn't fabricate a connection to the owner just because the owner supplied the file.

package/payload/platform/plugins/linkedin-import/skills/linkedin-import/references/connections.md

@@ -0,0 +1,135 @@
+# Reference: Connections.csv
+
+Creates a `:Person` for every LinkedIn connection, a `:Organization` for every company named on those rows, `[:WORKS_FOR {title}]` edges from connections to their current employer, and `[:CONNECTED_ON_LINKEDIN {connectedOn}]` edges from the archive owner to every connection.
+
+Every edge in this reference is expressed by the source CSV: connections are explicitly labelled as "connected to the archive owner", and each connection row explicitly names a current position. Nothing synthetic.
+
+## Source
+
+`Connections.csv`.
+
+**Parser note — skip the header preamble.** The file begins with three lines LinkedIn injects:
+
+```
+Notes:
+"When exporting your connection data, …"
+<blank line>
+First Name,Last Name,URL,Email Address,Company,Position,Connected On
+```
+
+The real column header is **line 4**. Either skip the first three lines before parsing, or parse with no header and align columns from row 4 onward.
+
+## Columns → properties and edges
+
+| CSV column | Maps to |
+|------------|---------|
+| First Name | `Person.givenName` |
+| Last Name | `Person.familyName` |
+| URL | `Person.linkedinUrl` (natural key) |
+| Email Address | `Person.email` (only when non-empty) |
+| Company | `Organization.name` |
+| Position | `[:WORKS_FOR].title` AND `Person.currentTitle` (denormalised) |
+| Connected On | `[:CONNECTED_ON_LINKEDIN].connectedOn` (ISO 8601) |
+
+The `Position` column is written **twice**: once on the `[:WORKS_FOR]` edge as the source of truth (preserves the per-employer history when a connection later moves), and again as `Person.currentTitle` so Neo4j's `entity_search` BM25 index reaches it. Edge properties are invisible to a node-only fulltext index, so without the denormalisation an operator searching "director" against 5K connections returns near-zero hits regardless of how many directors are in the graph. The SET is unconditional — re-importing a row with an empty Position clears `currentTitle`, matching the LinkedIn export's "current snapshot" semantics. To filter your import to a specific role before writing, use the [Selective-ingest threshold](#selective-ingest-threshold) gate.
+
+LinkedIn only emits email for connections who opted in, so most rows have a blank email. The MCP tool writes `email` only when non-empty — avoids colliding with `person_email_unique` on empty strings.
+
+## Natural keys
+
+| Entity | Key | Why |
+|--------|-----|-----|
+| `:Person` | `linkedinUrl` (indexed in `platform/neo4j/schema.cypher`) | Stable across exports; display-name collisions are frequent |
+| `:Organization` | `(accountId, name)` | Matches existing `memory-write` convention. Schema-base.md requires `accountId` + `name` on every Organization |
+
+## Anchor
+
+Resolved at skill start via the owner-confirmation flow. The owner is either an `:AdminUser` (the operator's own archive — the common case) or a confirmed `:Person` (an external archive ingested for reference). Both flow through the same write tool — `memory-archive-write` matches by `elementId(owner)` and accepts either label set.
+
+## Selective-ingest threshold
+
+**100 rows.** When the parsed `rows[]` count exceeds this, the skill pauses before the write call and asks the operator to filter by Company, Position, or Connected On range. See [SKILL.md § Selective-ingest threshold](../SKILL.md#selective-ingest-threshold-bulk-archives) for the doctrine. The MCP tool accepts whatever rows are passed; this gate is conversational.
+
+## Write surface
+
+This reference invokes a single MCP tool: `mcp__plugin_memory_memory__memory-archive-write` with `archiveType: "linkedin-connections"`. The Cypher body — Person upsert by `linkedinUrl`, `CONNECTED_ON_LINKEDIN` edge from owner, optional `:Organization` + `WORKS_FOR` when company is non-empty — lives server-side in [`platform/plugins/memory/mcp/src/tools/memory-archive-write.ts`](../../../../memory/mcp/src/tools/memory-archive-write.ts). The agent does not author or pipe Cypher; it parses CSV rows into the tool's row schema and dispatches one (or more, for filtered re-imports) tool call.
+
+### Tool input shape
+
+```json
+{
+  "archiveType": "linkedin-connections",
+  "ownerNodeId": "<elementId of :AdminUser or :Person — from owner-confirmation flow>",
+  "rows": [
+    {
+      "givenName": "Dee",
+      "familyName": "Odus",
+      "linkedinUrl": "https://www.linkedin.com/in/deeodus",
+      "email": null,
+      "company": "Female Founders Fund",
+      "title": "Partner",
+      "connectedOn": "2026-04-23"
+    }
+  ],
+  "sessionId": "<UUID generated once per skill run>"
+}
+```
+
+The parser converts:
+- Blank cells → `null` (especially `email`, `company`, `title`).
+- `Connected On` from `"23 Apr 2026"` → ISO 8601 `"2026-04-23"`. The tool rejects rows with non-ISO dates loudly — never let the agent paper over a parser bug.
+
+### What the server does (informational, not the agent's responsibility)
+
+Per 500-row batch the handler runs one transaction with two phases:
+
+1. Upsert each row's `:Person` (natural key `linkedinUrl`), stamp provenance + email when present, then upsert the owner→Person `CONNECTED_ON_LINKEDIN` edge with `connectedOn` on the edge.
+2. For rows whose `company` is non-empty, upsert the `:Organization` (natural key `accountId + name`), then upsert the Person→Organization `WORKS_FOR` edge with `title` on the edge.
+
+Provenance stamped on every node: `source='linkedin'`, `createdByAgent='linkedin-import'`, `createdBySource='linkedin-import'`, `createdBySession=<sessionId>`, `createdAt=<now>`.
+
+Counters come from the Neo4j driver's per-statement summary (`nodesCreated`, `relationshipsCreated`). The tool returns `{processedRows, createdPersons, mergedPersons, createdOrganizations, createdEdges, errors[]}`.
+
+## Edge semantics — why these and no others
+
+- **`(owner)-[:CONNECTED_ON_LINKEDIN]->(:Person)`** — each row of Connections.csv is a declaration that the archive owner and this person are LinkedIn connections. That's the edge.
+- **`(:Person)-[:WORKS_FOR]->(:Organization)`** — each row's Company/Position columns state where the connection currently works. That's the edge. Schema-base calls this `WORKS_FOR`.
+
+Rows missing a company produce a Person with a `CONNECTED_ON_LINKEDIN` edge and no WORKS_FOR — because the row didn't express a WORKS_FOR relationship. No placeholder Organization gets minted.
+
+Rows missing a position but present with a company produce a `WORKS_FOR` edge with null `title` — the connection works there, we just don't know their role.
+
+## Date parsing
+
+`Connected On` arrives as `"23 Apr 2026"`. Convert to ISO 8601 (`2026-04-23`) in the parser before passing to the tool. The server converts to Neo4j `date()` internally — the agent never invokes Cypher functions.
+
+## Expected shape
+
+- ~3,000–10,000 rows typical for a long-running account. The selective-ingest gate (above) keeps a typical write at well under 1,000 rows.
+- 500 rows per transaction. The MCP tool handles batching internally; the agent passes the full filtered `rows[]` in one call.
+
+## Post-import verification (operator-side, not agent-side)
+
+
+```cypher
+// Owner → connections count
+MATCH (owner:AdminUser {userId: $ownerUserId})-[:CONNECTED_ON_LINKEDIN]->(p:Person)
+RETURN count(p) AS connections;
+
+// LinkedIn-origin organizations count
+MATCH (o:Organization {accountId: $accountId, source: 'linkedin'})
+RETURN count(o) AS organizations;
+```
+
+These are **read queries**, not writes. Cypher writes from the agent are forbidden.
+
+## Failure modes
+
+| Symptom | Cause | Fix |
+|---------|-------|-----|
+| Every row parsed as "Notes:,NaN,…" | Header preamble not skipped | Skip first 3 lines before the CSV parser |
+| Tool error "row connectedOn is not ISO 8601" | Parser left `Connected On` in `"23 Apr 2026"` form | Convert to `YYYY-MM-DD` before passing to the tool |
+| Tool error "ownerNodeId not found" | Owner-confirmation flow not run, or operator typed the wrong id | Re-run owner confirmation; pass the resulting `elementId` as `ownerNodeId` |
+| Tool error `ownerNodeId <id> belongs to account <X>, not <Y>. Cross-account archive ingest refused.` | The confirmed owner lives in a different account than the calling session — typically the operator confirmed a Person/AdminUser from a different brand, or `accountId` was passed wrong | Re-run owner confirmation inside the correct account, or pass the calling session's `accountId` |
+| `WORKS_FOR` count « connection count | Many rows have blank company | Expected — LinkedIn doesn't force connections to list a current employer |
+| Tool not present in `init` frame | `specialists:librarian` spawned without the `mcp__plugin_memory_memory__memory-archive-write` token | Loud-fail per librarian's prerogatives. Do not improvise via Bash. Operator must remediate (re-seed specialist templates) |

package/payload/platform/plugins/linkedin-import/skills/linkedin-import/references/profile.md

@@ -0,0 +1,94 @@
+# Reference: Profile.csv
+
+Enriches the confirmed archive owner's `:UserProfile` with the LinkedIn profile fields. No new nodes, no new edges — `:AdminUser` and `:UserProfile` already exist for any {{productName}} operator and are linked by `[:HAS_PROFILE]` at session start (neo4j-store handles that on session boot, not this skill).
+
+Runs before every other reference because later files display LinkedIn profile fields (headline, summary) on the owner node they search.
+
+## Source
+
+`Profile.csv` — single data row.
+
+## Columns → UserProfile properties
+
+Schema.org camelCase per `platform/plugins/memory/references/schema-base.md`.
+
+| CSV column | Property on `:UserProfile` |
+|------------|----------------------------|
+| First Name | `givenName` |
+| Last Name | `familyName` |
+| Maiden Name | `additionalName` (nullable) |
+| Address | `address` (nullable) |
+| Birth Date | `birthDate` (nullable, ISO 8601) |
+| Headline | `headline` |
+| Summary | `description` |
+| Industry | `industry` (nullable) |
+| Zip Code | `postalCode` (nullable) |
+| Geo Location | `addressLocality` (nullable) |
+| Twitter Handles | `twitterHandles` — array, split on `,` |
+| Websites | `websites` — array, split on `,` |
+| Instant Messengers | `instantMessengers` — array, split on `,` |
+
+## Anchor
+
+The owner-confirmation flow at the start of the skill resolves the operator's `:UserProfile` elementId — not just the `:AdminUser` userId. That elementId (`$ownerProfileElementId`) is the input to this reference. The `[:HAS_PROFILE]` edge between `:AdminUser` and `:UserProfile` is created by `platform/ui/app/lib/neo4j-store.ts` on every session start; it pre-exists by the time any skill runs.
+
+## Write surface
+
+This reference invokes `mcp__plugin_memory_memory__memory-update` once with the parsed row's properties:
+
+```json
+{
+  "nodeId": "<elementId of :UserProfile from owner-confirmation>",
+  "properties": {
+    "givenName": "Joel",
+    "familyName": "Smalley",
+    "additionalName": null,
+    "address": null,
+    "birthDate": null,
+    "headline": "Founder, Rubytech",
+    "description": "Building {{productName}} …",
+    "industry": "Software",
+    "postalCode": null,
+    "addressLocality": "London, UK",
+    "twitterHandles": ["@joelsmalley"],
+    "websites": ["https://getmaxy.com"],
+    "instantMessengers": [],
+    "linkedinProfileUpdatedAt": "<ISO 8601 timestamp>",
+    "source": "linkedin"
+  }
+}
+```
+
+The `memory-update` tool ignores restricted keys (`embedding`, `accountId`, `createdAt`) and recomputes the embedding from the new property set. No raw Cypher, no `MERGE`, no Bash.
+
+The parser converts:
+- Blank cells → `null`.
+- `Twitter Handles`, `Websites`, `Instant Messengers` from comma-delimited strings → arrays.
+- `Birth Date` to ISO 8601 if present.
+
+## Expected outcome
+
+- Zero new nodes.
+- Zero new edges.
+- One existing `:UserProfile` enriched with 10–13 new properties.
+
+## Failure modes
+
+| Symptom | Cause | Fix |
+|---------|-------|-----|
+| Tool error "node not found" | `$ownerProfileElementId` invalid — owner-confirmation flow did not return a UserProfile | Re-run the owner-confirmation flow; verify `:AdminUser`-`HAS_PROFILE`->`:UserProfile` exists for the confirmed userId |
+| `up.websites` written as a single string not an array | Parser didn't split on `,` | Fix parser — LinkedIn comma-delimits these fields |
+| Restricted property silently ignored | `memory-update` rejects `embedding` / `accountId` / `createdAt` overrides | Expected — those fields are managed by the server |
+
+## Post-import verification (operator-side, read-only)
+
+
+```cypher
+MATCH (au:AdminUser {userId: $ownerUserId})-[:HAS_PROFILE]->(up:UserProfile)
+RETURN
+  au.name, au.userId,
+  up.givenName, up.familyName, up.headline, up.description,
+  up.websites, up.linkedinProfileUpdatedAt
+```
+
+Exactly one row. If zero, the owner-confirmation flow returned the wrong elementId — investigate before running any subsequent reference.

package/payload/platform/plugins/memory/.claude-plugin/plugin.json

@@ -0,0 +1,17 @@
+{
+  "name": "memory",
+  "description": "Graph memory plugin. Provides memory-search (with optional `fields` projection for known-shape lookups), memory-write, memory-update, memory-edge (create/delete typed directed edges between pre-existing nodes), memory-update-by-name (repair surface that resolves an elementId from a (label, name, accountId) tuple when search cannot return one), memory-lookup-by-name (deterministic read surface that returns nodes by case-insensitive exact `name` match, optionally constrained by labels, bypassing the memory-search ranking stack so a present entity is never missed because a diluted query ranked it below the cut), and the :Report surface (memory-report-write / memory-report-read-latest / memory-report-list) for reading from, writing to, and updating the Neo4j knowledge graph. Includes conversational memory — organic preference learning, evidence-backed recall, and transparent 'what do you know about me?' responses. Document ingestion goes through memory-ingest; the dispatched specialist produces typed-section JSON in-turn from the loaded ontology. Operator-solicited reclassify of an already-stored thread-shaped KD (today: email-thread KDs) is exposed as `kd-classify <attachmentId>` — runs a body-growth gate (proceed iff body grew ≥25% since the last classify, or first-ever classify), stages the body to a temp file under `$ACCOUNT_DIR/tmp/`, and returns a dispatch envelope for the `librarian`; on success `memory-ingest` replaces the prior :Section children and stamps `lastClassifiedAt` + `lastClassifiedBodyLength` on the parent KD. Two modes: `document` (default) for unstructured PDF/web content → :KnowledgeDocument (keyed on `attachmentId`) + :Section, and `chat` for conversation transcripts → :ConversationArchive (keyed on `conversationIdentity`) + :Section chunks; two parent labels, two writer paths chosen by which identity property is set. Conversation-archive Phase 2 splits across two read-only tools (Task 433): `conversation-archive-list-chunks` pages chunk bodies for the dispatched specialist to read in-turn; `conversation-archive-derive-insights` converts the specialist's per-chunk claims into operator-facing proposals with per-kind cypher. `conversation-archive-enrich-rejection` records (or undoes) durable per-row rejections so already-triaged claims do not re-surface on re-runs. Ships five skills: `conversational-memory`, `document-ingest`, `conversation-archive` (source-agnostic transcript ingest for WhatsApp, Telegram, Signal, LinkedIn DMs, Zoom, meeting minutes, iMessage, Slack), `conversation-archive-mcp` (operator-initiated MCP-driven ingest for Granola, Otter, Circleback meetings — sibling of `conversation-archive` sharing the same writer surface and identity formula), and `conversation-archive-enrich` (per-row operator-gated insight derivation over a named archive's chunks). Ships three thinking-tool skills: `challenge` (adversarial retrieval — strongest counter-evidence from the graph for a given claim), `connect` (bridge-finding between two topics via shared graph neighbors), and `emerge` (clusters uncategorised KnowledgeDocument and Section nodes into operator-approved Concept proposals).",
+  "version": "0.1.0",
+  "author": {
+    "name": "Rubytech LLC"
+  },
+  "mcpServers": {
+    "memory": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${CLAUDE_PLUGIN_ROOT}/mcp/dist/index.js"
+      ]
+    }
+  }
+}