@rubytech/create-realagent 1.0.823 → 1.0.825

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

@@ -1,21 +1,22 @@
 ---
 name: whatsapp-import
-description: Phase 1 of the WhatsApp `_chat.txt` ingest contract — deterministic, LLM-free. Preview the archive (parsed counts, date range, sender histogram), ask the operator to choose a filter (`all`, `senders=<csv>`, `date-range=<isoFrom>..<isoTo>`), then write Conversation + Messages + NEXT chain + auto-Person participants via the single Bash entry `whatsapp-ingest.sh`. NO observations and NO LLM at this phase — semantic enrichment lives in the `whatsapp-import-enrich` skill (Phase 2). Triggers when the user asks to import a WhatsApp chat, ingest a `_chat.txt` file, or drops the contents of an "Export Chat" folder into chat. Distinct from the live `whatsapp` plugin (Baileys); this is import-from-export only.
+description: Phase 1 of the WhatsApp `_chat.txt` ingest contract — deterministic, LLM-free. Preview the archive (parsed counts, date range, sender histogram), confirm the owner + third-party `:Person`, ask the operator to choose a filter (`all`, `senders=<csv>`, `date-range=<isoFrom>..<isoTo>`), then write Conversation + Messages + NEXT chain via the single Bash entry `whatsapp-ingest.sh`. The writer binds participants to the owner + subject pair: any parsed senderName outside that closed set LOUD-FAILs (Task 887 §A0). NO observations and NO LLM at this phase — semantic enrichment lives in the `whatsapp-import-enrich` skill (Phase 2). Triggers when the user asks to import a WhatsApp chat, ingest a `_chat.txt` file, or drops the contents of an "Export Chat" folder into chat. Distinct from the live `whatsapp` plugin (Baileys); this is import-from-export only.
 ---
 
 # WhatsApp Import — Phase 1 (Load)
 
 Phase 1 of the two-phase WhatsApp ingest contract. Deterministic only: parse → preview → operator-supplied filter → archive-write. NO LLM is invoked at this phase. The chunked Haiku insight pass moved to Phase 2 (`whatsapp-import-enrich` skill) so one ingest cannot blow the operator's context window with `:Observation` enumeration prose.
 
-## Owner confirmation (mandatory first step)
+## Owner + subject confirmation (mandatory first step)
 
-A WhatsApp export belongs to exactly one operator (the person whose phone produced the export). The owner is metadata stamped on the `:Conversation` node — the row-level participants are auto-created by the script and promoted in Phase 2.
+A WhatsApp DM has exactly two participants. The **owner** is the operator who exported the `_chat.txt`; the **subject** is the third party in the conversation. Both must resolve to existing graph nodes (`:AdminUser` or `:Person`) before the script runs — Task 887 §A0 closes the auto-Person leak by binding the writer to that closed pair.
 
-1. List every `:AdminUser` in the graph via `mcp__graph__maxy-graph-read_neo4j_cypher`:
+1. List every `:AdminUser` and the senders surfaced by Step 1 preview via `mcp__graph__maxy-graph-read_neo4j_cypher`:
    `MATCH (u:AdminUser) RETURN elementId(u) AS elementId, u.name AS name, u.userId AS userId, u.accountId AS accountId`
 2. Ask the operator: "Who exported this `_chat.txt`?" — accept either an existing `:AdminUser` elementId or, if the operator names someone not in the graph, surface that as a blocker (auto-creating an unknown owner is refused).
-3. Echo the chosen owner back verbatim. Require explicit yes/no confirmation.
-4. Persist the resolved owner's `elementId` for the script invocation as `--owner-element-id`.
+3. Identify the third party from the preview's sender histogram. Look up the matching `:Person` (by name); if no match, ask the operator to confirm a `:Person` elementId or block until one exists. **Auto-creating the third-party `:Person` is forbidden** — the operator must confirm the canonical node.
+4. Echo both back verbatim and require explicit yes/no confirmation.
+5. Persist the owner's `elementId` as `--owner-element-id` and the subject's as `--subject-person-id`.
 
 ## Step 1 — preview (mandatory before any write)
 
@@ -53,6 +54,7 @@ Single Bash call:
 ```bash
 bash platform/plugins/whatsapp-import/bin/whatsapp-ingest.sh <archive.zip|dir|_chat.txt> \
   --owner-element-id <id> \
+  --subject-person-id <id> \
   --scope <admin|public> \
   --filter <all|senders=<csv>|date-range=<isoFrom>..<isoTo>>
 ```
@@ -64,9 +66,9 @@ Optional flags:
 
 The script:
 - Unzips the archive if needed; locates `_chat.txt`.
-- Parses the file deterministically (year shape, sender/body grammar, timezone offset).
+- Parses the file deterministically (year shape, sender/body grammar, timezone offset, U+200E/U+200F leading-bidi-strip).
 - Applies the operator-supplied filter to `parseResult.parsedLines` BEFORE archive-write.
-- Auto-creates one `:Person {participantStatus:'auto-created'}` per distinct senderName in the filtered set, scoped to the account, MERGEd on `(accountId, source, name)`.
+- Validates every distinct parsed senderName against the canonical-name candidates of `{owner, subject}` (NFKC-trim-lower normalisation). Any miss LOUD-FAILs with `[whatsapp-ingest] FAIL parser-miss reason="senderName=<verbatim> not in preview histogram (parser failure — re-export or report)"` and exits non-zero. **Never auto-creates a participant** — Task 887 §A0 deleted that fallback path.
 - Writes the Conversation + Messages + edges + NEXT chronology via `memoryArchiveWrite` directly (no MCP envelope between steps).
 
 NO insight pass runs. The `--no-insight` flag of older releases is gone — Phase 1 always means parse + filter + archive-write, nothing else.
@@ -87,7 +89,7 @@ Stdout JSON shape (success — full diagnostic counters per Task 871 success cri
   "messagesAlreadyExisted": 0,
   "nextEdgesProcessed": 1706,
   "nextEdgesCreated": 1706,
-  "participantsAlreadyExisted": 0,
+  "participantsAlreadyExisted": 2,
   "ms": 6800
 }
 ```

package/payload/platform/templates/agents/admin/IDENTITY.md

@@ -186,7 +186,7 @@ You learn about the owner through conversation — never through questionnaires
 - When the owner says "remember this" or "forget that", use `profile-update` or `profile-delete` accordingly and confirm what you did.
 - When the owner asks "what do you know about me?", call `profile-read` with `detail: true` and present the results conversationally — preferences grouped by category, with confidence levels and where you learned each one. Offer to correct or remove anything.
 - Memory informs but does not override. If the current conversation contradicts a stored preference, follow the current conversation and call `profile-update` with `mode: "contradict"` to adjust.
-- The `## About the Owner` block in your system prompt is the per-turn signal source. Its `### Coverage` sub-block, when present, lists the canonical Preference categories that are absent (`communication`, `scheduling`, `decision`, `workflow`, `content`, `interaction`). While ≥1 category is absent, bias one organic question per turn toward an absent category — never a questionnaire, never more than one elicitation per turn, never a category already covered. When no `### Coverage` block appears, the profile is full — go silent on elicitation entirely. The bias never overrides a more pressing concern (a pending owner question, a tool-failure acknowledgement, an in-flight task) — it shapes what you ask when you would otherwise ask a generic question.
+- The `## About the Owner` block in your system prompt is the per-turn signal source. Its `### Coverage` sub-block, when present, lists the absent canonical Preference fields as `category.field` rows (e.g. `communication.preferredChannel, scheduling.workdayStartTime, …`) — these names are the agent's elicitation targets AND the canonical key source for `profile-update` writes. While ≥1 field is absent, bias one organic question per turn toward an absent field — never a questionnaire, never more than one elicitation per turn, never a field already covered. When you store a Preference satisfying a Missing field, use that exact `category` and `key` on `profile-update` (the Coverage list is the canonical key dictionary; ad-hoc keys never shrink Coverage and the user gets re-asked). On user declination ("doesn't apply", "I don't have one"), call `profile-update({category, key, value: "", notApplicable: true})` — this counts as covered AND stops re-prompting; declination is immutable (the tool rejects `mode: merge|contradict` for notApplicable rows). When no `### Coverage` block appears, the profile is full — go silent on elicitation entirely. The bias never overrides a more pressing concern (a pending owner question, a tool-failure acknowledgement, an in-flight task) — it shapes what you ask when you would otherwise ask a generic question.
 
 ## Premium Plugin Delivery
 

package/payload/platform/templates/specialists/agents/database-operator.md

@@ -123,7 +123,7 @@ Per-source archive imports keep their own skill because their CSVs already encod
   - **Phase 1 — preview-then-filtered-write** (`whatsapp-import` skill). Phase 1 is LLM-FREE. Three steps:
     1. **Preview** via `mcp__memory__whatsapp-export-preview` — read-only parse that returns `{conversationSha256, parsed, mediaSkipped, systemSkipped, dateRange:{first,last}, senders:[{name,messageCount}], totalMessages, archiveBytes}`. No Cypher writes.
     2. **Operator chooses a filter.** Surface the preview to the operator and ask: "Filter to apply: `all`, `senders=<csv>`, or `date-range=<isoFrom>..<isoTo>`?". `--filter` is mandatory — the deterministic Bash entry refuses to write without it (`feedback_compress_at_ingest_for_bulk_archives.md`).
-    3. **Archive-write** via `bash platform/plugins/whatsapp-import/bin/whatsapp-ingest.sh <archive> --owner-element-id <id> --scope <admin|public> --filter <chosen>`. Parses, applies the filter, writes Conversation + Messages with chronological NEXT chain, auto-creates one `:Person {participantStatus:'auto-created'}` per distinct senderName. ZERO `:Observation` writes — the LLM insight pass moved to Phase 2.
+    3. **Archive-write** via `bash platform/plugins/whatsapp-import/bin/whatsapp-ingest.sh <archive> --owner-element-id <id> --subject-person-id <id> --scope <admin|public> --filter <chosen>`. Parses, applies the filter, writes Conversation + Messages with chronological NEXT chain. Writer is bound to the `{owner, subject}` pair from the preview histogram — any parsed senderName outside that closed set LOUD-FAILs (Task 887 §A0); the script does NOT auto-create participant `:Person` nodes. ZERO `:Observation` writes — the LLM insight pass moved to Phase 2.
 
     Phase 1 agent-return is COUNTERS ONLY — no inline enumeration of mention/task/preference counts, no multi-paragraph "ask to enrich" prose. Surface as one chat message: the JSON shape `{conversationElementId, conversationId, parsed, written, alreadyExisted, nextEdgesCreated, ms}` plus one sentence: "Preview before any future re-import via `mcp__memory__whatsapp-export-preview`; enrich semantically when ready via the `whatsapp-import-enrich` skill." The legacy `mcp__memory__whatsapp-export-parse` / `whatsapp-export-insight-write` / `memory-archive-write{archiveType:whatsapp-export}` MCP tools remain blocked at the harness; the Bash script is the only supported archive-write invocation. SKILL: `platform/plugins/whatsapp-import/skills/whatsapp-import/SKILL.md`.
   - **Phase 2 — enrich** (`whatsapp-import-enrich` skill). Operator-triggered ("enrich the X chat"). First runs `mcp__memory__whatsapp-export-insight-pass` against the already-loaded Conversation (chunkSize=50, overlap=5, server-side `confidence>=0.8` gate) to lay down `:Observation {observationStatus:'auto-extracted'}` rows. Then walks the auto-created participants and auto-extracted observations, surfacing evidence per row, and writes operator-confirmed wiring (`apoc.refactor.mergeNodes` for participant promotion/merge, `:MENTIONS` and `:RELATED_TO` edges with `evidenceSnippet`/`evidenceMessageIds`, `:Task` via `mcp__tasks__task-create`, `:Preference` via `memory-write`). Idempotent — re-running surfaces only items still in `auto-created`/`auto-extracted` state. SKILL: `platform/plugins/whatsapp-import/skills/whatsapp-import-enrich/SKILL.md`.