ei-tui 0.9.4 → 1.0.1

package/src/prompts/ceremony/dedup.ts

@@ -89,7 +89,7 @@ ${buildRecordFormatExamples(data.itemType)}
 
 ### Rules:
 - Do NOT invent information. Only redistribute what exists in the cluster.
-- Descriptions should be concise—ideally under 300 characters, never over 500.
+- Descriptions should be concise — ideally under 300 characters, never over 500 for regular topics. Technical topics (category: "Technical") may go up to 900 characters — preserve their specific gotchas, decisions, and open questions.
 - Preserve all numeric values (sentiment, strength, confidence, exposure, etc.) from source records. When merging, take the HIGHER value for strength/confidence, AVERAGE for sentiment.
 - Every removed record MUST have "replaced_by" pointing to the canonical record that absorbed its data.
 - The "update" array should contain AT LEAST ONE record (the canonical/merged one), even if all others are removed.
@@ -165,6 +165,8 @@ Similarity of meaning is not the same as identity. "Concern about job security"
 
 Ask yourself: *If a persona referenced the established record in conversation, would the newcomer feel like a repeat? Or would it feel like something different being said?*
 
+**Default to keeping both.** Merge only when you are certain these describe the same concept — thematic overlap, shared vocabulary, or similar domain are not sufficient. A false merge destroys information permanently; a false keep is harmless.
+
 If they are the same thing: **merge**. Preserve every unique detail from both. The newcomer's description is synthesized and current — weight it, but don't discard what the established record learned first.
 
 If they are distinct: **keep both**. Return them both in \`update\` unchanged. Leave \`remove\` and \`add\` empty.
@@ -183,7 +185,8 @@ Rules:
 - \`add\` is always empty here. We are not creating new records from this decision.
 - If merging: the merged record goes in \`update\`, the absorbed record goes in \`remove\`.
 - If keeping both: return both in \`update\` exactly as received. Do not modify either.
-- Descriptions must stay concise — under 300 characters, never over 500. Synthesize; don't concatenate.
+- Descriptions must stay concise — under 300 characters, never over 500 for regular topics. **Technical topics** (category: "Technical") may go up to 900 characters — they are knowledge bases, not summaries. Synthesize regular topics; preserve detail in Technical ones.
+- For Technical topics: two records about the same technology but different aspects (e.g., "Uniform composition model" vs "Uniform preview setup") are **NOT duplicates** — keep both. Only merge if they are genuinely the same concept described twice.
 - When merging numeric fields: take the HIGHER value for \`exposure_current\`, \`exposure_desired\`, \`strength\`, \`confidence\`. Average \`sentiment\`.
 - Do NOT invent information. Only what exists in these two records.
 
@@ -297,7 +300,7 @@ function buildTopicExamples(): string {
   "name": "Software Architecture",    // REQUIRED
   "description": "System design patterns, microservices, event-driven architecture. Passionate about scalability and maintainability.", // REQUIRED
   "sentiment": 0.8,                    // -1.0 to 1.0 (average when merging)
-  "category": "Interest",             // REQUIRED - Interest, Goal, Dream, Conflict, Concern, Fear, Hope, Plan, Project (pick most common)
+  "category": "Interest",             // REQUIRED - Interest, Goal, Dream, Conflict, Concern, Fear, Hope, Plan, Project, Event, Technical (pick most common)
   "exposure_current": 0.6,            // 0.0 to 1.0, how recently discussed (take HIGHER when merging)
   "exposure_desired": 0.9,            // 0.0 to 1.0, how much they want to discuss (take HIGHER when merging)
   "last_ei_asked": "2024-03-10T08:00:00Z", // OPTIONAL - ISO timestamp or null
@@ -330,6 +333,7 @@ CATEGORIES explained:
 - Goal: Things they want to achieve
 - Concern/Fear: Things that worry them
 - Plan/Project: Active work or intentions
+- Technical: Tools, platforms, frameworks, or technical concepts being learned or used — knowledge base entries, NOT summaries
 
 GOOD vs BAD descriptions:
 ✅ GOOD: "Functional programming paradigm. Loves immutability and pure functions. Uses in side projects."

package/src/prompts/ceremony/index.ts

@@ -1,4 +1,5 @@
-export { buildRewriteScanPrompt, buildRewritePrompt } from "./rewrite.js";
+export { buildPersonRewriteScanPrompt, buildPersonRewriteSplitPrompt } from "./people-rewrite.js";
+export { buildTopicRewriteScanPrompt, buildTopicRewriteSplitPrompt } from "./topic-rewrite.js";
 export { buildDedupPrompt, buildValidatePrompt } from "./dedup.js";
 export { buildUserDedupPrompt } from "./user-dedup.js";
 export type {

package/src/prompts/ceremony/people-rewrite.ts

@@ -0,0 +1,190 @@
+import type { RewriteScanPromptData, RewritePromptData } from "./types.js";
+
+// =============================================================================
+// What belongs in a Person record (shared reference for both prompts)
+// =============================================================================
+//
+// A Person record is a RELATIONSHIP PROFILE — who this person is, how they
+// relate to the human user, and anything a persona would use to meaningfully
+// reference them in conversation 6+ months from now.
+//
+// A Person record is NOT:
+//   - A project status log
+//   - A record of ticket numbers, PR numbers, or sprint assignments
+//   - A biography of their personal habits and hobbies
+//   - A shared-interest tracker (those are Topics)
+//
+// The test: "Would this still be true and useful if you ran into this person
+// at a coffee shop, unrelated to any current project?"
+
+const PERSON_CONTRACT = `A Person record is a **relationship profile** — who this person IS, how they relate to the human user, their character and communication style, and anything that makes them recognizable across time and context.
+
+It is NOT:
+- A project status log (ticket numbers, PR references, sprint assignments)
+- A record of shared interests that could stand alone as a Topic
+- Personal biography unrelated to the relationship (commute, hobbies, hometown)
+- Technical knowledge attributed to them rather than about them
+
+**The test**: Would this detail still be true and useful if you ran into this person at a coffee shop, unrelated to any current project, in six months?`;
+
+// =============================================================================
+// PHASE 1: SCAN — Identify subjects that don't belong in a Person record
+// =============================================================================
+
+export function buildPersonRewriteScanPrompt(data: RewriteScanPromptData): { system: string; user: string } {
+  const system = `You are auditing a Person record in a personal knowledge base.
+
+${PERSON_CONTRACT}
+
+Your job: identify **subjects buried in this description that fail the test above**.
+
+For each subject that doesn't belong, return a short phrase (3-8 words) that describes it — specific enough to search for matching records. These phrases will be used to find existing Topics this content might belong in.
+
+Rules:
+- Do NOT include the relationship profile itself — who they are, their role, how you know them, their character
+- Be specific: "React performance patterns" beats "technical stuff"
+- If the record is clean — everything in it passes the test — return an empty array
+
+Return a raw JSON array of strings. No markdown fencing, no commentary.
+
+Example — a Person named "Nicholas" whose description includes sprint ticket numbers:
+["CMIDP sprint ticket assignments", "ASU Data Lake access provisioning details"]`;
+
+  const payload = JSON.stringify({
+    name: (data.item as { name?: string }).name,
+    description: data.item.description,
+    relationship: (data.item as { relationship?: string }).relationship,
+  }, null, 2);
+
+  const user = `${payload}
+
+---
+
+Return a raw JSON array of subject phrases found in this Person record that don't belong there. Return [] if the record is clean.`;
+
+  return { system, user };
+}
+
+// =============================================================================
+// PHASE 2: SPLIT — Slim the Person, redistribute subjects to Topics
+// =============================================================================
+
+function buildPersonExistingExample(): string {
+  return `{
+  "id": "existing-uuid",
+  "type": "person",
+  "name": "Nicholas",
+  "description": "Backend engineer on the CMIDP team. Thoughtful code reviewer who flags architectural concerns — specifically around concurrency and queue isolation. Direct point of contact for Data Lake access provisioning.",
+  "relationship": "coworker"
+}`;
+}
+
+function buildPersonNewTopicExample(): string {
+  return `{
+  "type": "topic",
+  "name": "CMIDP Sprint 86 work",
+  "description": "Nicholas owns 4 tickets in Sprint 86 including course list ordering bugs (CMIDP-2604, CMIDP-2441, CMIDP-2686) and course sequencing (CMIDP-2624).",
+  "sentiment": 0.5,
+  "category": "Project"
+}`;
+}
+
+export function buildPersonRewriteSplitPrompt(data: RewritePromptData): { system: string; user: string } {
+  const system = `You are reorganizing a Person record in a personal knowledge base.
+
+${PERSON_CONTRACT}
+
+An earlier scan identified subjects in this Person record that don't belong there. For each subject, we searched the knowledge base for existing Topics that might already cover it.
+
+Your job:
+1. **Slim the Person** — remove the identified subjects AND any other content that fails the relationship profile test (personal trivia, lifestyle details, biographical facts unrelated to the relationship). Keep only: who they are, their role, their character, how the human user knows and works with them.
+2. **Redistribute each identified subject** — if a matching Topic exists in the search results, move the content there. If not, create a new Topic.
+3. **Discard what isn't worth a Topic** — personal trivia (hobbies, commute, hometown) that has no standalone value doesn't need to become a Topic. Just remove it from the Person.
+4. **Lose NO relationship data** — everything about how this person relates to the human user must survive.
+
+Record format for the Person (MUST keep "id", type stays "person"):
+${buildPersonExistingExample()}
+
+Record format for a new Topic created from extracted content:
+${buildPersonNewTopicExample()}
+
+Rules:
+- The original Person record (id: "${data.item.id}") MUST appear in "existing", slimmed down
+- Person description after slimming: 2-4 sentences, relationship profile only. **If it still contains city, commute, hobbies, or lifestyle details after slimming — remove them.** Those are not relationship data.
+- Topics created from person content: use the most appropriate category (Technical, Project, Interest, etc.)
+- People MUST include "relationship"
+- Topics MUST include "category"
+- Do NOT invent information — only redistribute what exists in the original record
+- Do NOT remove the person's relationship, role, character, or how the human user knows them — only the non-person content
+
+**What to KEEP in the Person description**: role, expertise, *why* the human user works with them (their operational function in the relationship), how they communicate, character traits, how the human user knows them.
+**What to REMOVE from the Person description**: current project status, ticket/PR numbers, shared interests (→ Topic), city/commute/hobbies (→ discard).
+
+The distinction:
+- "Data Lake bucket owner responsible for access provisioning" → KEEP (operational role in the relationship)
+- "Currently owns 4 tickets in Sprint 86" → REMOVE (current sprint status, not who they are)
+- "Left detailed comments on PR #1644 identifying architectural concerns around concurrency" → KEEP the insight, DROP the PR reference: "Flags architectural concerns around concurrency and queue isolation" belongs in the description; "PR #1644" does not.
+
+Return raw JSON with exactly two keys:
+{
+  "existing": [ /* slimmed Person + any existing Topics being updated */ ],
+  "new": [ /* new Topics for subjects with no existing match */ ]
+}
+
+No markdown fencing, no commentary.`;
+
+  const subjects = data.subjects.map(s => ({
+    search_term: s.searchTerm,
+    matches: s.matches.map(m => ({
+      id: (m as { id?: string }).id,
+      name: (m as { name?: string }).name,
+      description: m.description,
+      category: (m as { category?: string }).category,
+    })),
+  }));
+
+  const payload = JSON.stringify({
+    original_person: {
+      id: data.item.id,
+      name: (data.item as { name?: string }).name,
+      description: data.item.description,
+      relationship: (data.item as { relationship?: string }).relationship,
+      sentiment: data.item.sentiment,
+    },
+    subjects_to_extract: subjects,
+  }, null, 2);
+
+  const schemaReminder = `**Return JSON:**
+\`\`\`json
+{
+  "existing": [
+    {
+      "id": "uuid-of-person",
+      "type": "person",
+      "name": "Person Name",
+      "description": "Slimmed relationship profile only",
+      "relationship": "coworker"
+    }
+  ],
+  "new": [
+    {
+      "type": "topic",
+      "name": "Subject Name",
+      "description": "Content extracted from person record",
+      "sentiment": 0.5,
+      "category": "Project|Technical|Interest|etc."
+    }
+  ]
+}
+\`\`\`
+
+Return raw JSON only.`;
+
+  const user = `${payload}
+
+---
+
+${schemaReminder}`;
+
+  return { system, user };
+}

package/src/prompts/ceremony/{rewrite.ts → topic-rewrite.ts}

@@ -1,23 +1,41 @@
 import type { RewriteScanPromptData, RewritePromptData } from "./types.js";
 
 // =============================================================================
-// PHASE 1: SCAN — Identify distinct subjects in a bloated item
+// PHASE 1: SCAN — Identify subjects that don't belong in a Topic record
 // =============================================================================
 
-export function buildRewriteScanPrompt(data: RewriteScanPromptData): { system: string; user: string } {
-  const typeLabel = data.itemType.charAt(0).toUpperCase() + data.itemType.slice(1);
+function stripEmbedding<T extends { embedding?: unknown }>(item: T): Omit<T, "embedding"> {
+  const { embedding: _, ...rest } = item;
+  return rest as Omit<T, "embedding">;
+}
 
-  const system = `You are auditing a personal knowledge base. A single ${typeLabel} record has grown too large because unrelated information was repeatedly appended to it over time. The record's Name suggests its intended subject, but its Description now covers many additional, unrelated subjects.
+export function buildTopicRewriteScanPrompt(data: RewriteScanPromptData): { system: string; user: string } {
+  const isTechnical = (data.item as { category?: string }).category === "Technical";
 
-Your job: identify the **additional** subjects buried in this record that do NOT belong under the record's Name.
+  const technicalGuidance = isTechnical
+    ? `
+## Technical Topic Guidance
 
-Rules:
-- Do NOT include the record's primary subject (what its Name describes) — only the extra, unrelated subjects.
-- Each subject should be a succinct phrase (2-8 words) that could serve as a search query.
-- Be specific. "Technical preferences" is too vague. "TypeScript coding conventions" is better.
-- If the record is actually cohesive and on-topic despite its length, return an empty array.
+This is a Technical topic — a knowledge base for a specific technology, platform, or tool. Technical topics are ALLOWED to be dense and detailed.
+
+Only flag subjects that are about a **different** technology or workflow than the one named in this record. For example:
+- A Uniform topic containing Turborepo setup details → flag "Turborepo monorepo setup"
+- A Uniform topic containing Vercel preview gotchas → do NOT flag (that's core Uniform knowledge)
+- An AWS Bedrock topic containing Twilio integration details → flag "Twilio integration"
+`
+    : "";
 
-Return a raw JSON array of strings. No markdown fencing, no commentary, no explanation. Just the array.
+  const system = `You are auditing a Topic record in a personal knowledge base. A single Topic record has grown too large because unrelated information was repeatedly added over time. The record's Name suggests its intended subject, but its Description now covers additional, unrelated subjects.
+
+Your job: identify the **extra subjects** buried in this record that do NOT belong under the record's Name.
+
+Rules:
+- Do NOT include the record's primary subject (what its Name describes) — only the extra, unrelated subjects
+- Each subject should be a succinct phrase (2-8 words) that could serve as a search query
+- Be specific: "TypeScript coding conventions" beats "technical preferences"
+- If the record is cohesive and on-topic despite its length, return an empty array
+${technicalGuidance}
+Return a raw JSON array of strings. No markdown fencing, no commentary.
 
 Example — a Topic named "Software Engineering" whose description also discusses vim keybindings, git conventions, and AI tooling:
 ["vim keybindings and editor configuration", "git and GitHub workflow conventions", "AI coding assistant preferences"]`;
@@ -25,10 +43,10 @@ Example — a Topic named "Software Engineering" whose description also discusse
   const payload = JSON.stringify(stripEmbedding(data.item), null, 2);
 
   const schemaReminder = `**Return JSON:**
-\n\`\`\`json
+\`\`\`json
 [
-  "topic about vim keybindings",
-  "git workflow conventions",
+  "vim keybindings and editor configuration",
+  "git and GitHub workflow conventions",
   "AI coding assistant preferences"
 ]
 \`\`\`
@@ -45,13 +63,70 @@ ${schemaReminder}`;
 }
 
 // =============================================================================
-// PHASE 2: REWRITE — Reorganize data across existing and new items
+// PHASE 2: SPLIT — Slim the Topic, redistribute subjects to new/existing records
 // =============================================================================
 
-export function buildRewritePrompt(data: RewritePromptData): { system: string; user: string } {
-  const typeLabel = data.itemType.charAt(0).toUpperCase() + data.itemType.slice(1);
+function buildTopicExistingExample(): string {
+  return `Topic:
+{
+  "id": "existing-uuid",
+  "type": "topic",
+  "name": "Topic Name",
+  "description": "Updated topic description",
+  "category": "Interest"
+}
+
+Person:
+{
+  "id": "existing-uuid",
+  "type": "person",
+  "name": "Person Name",
+  "description": "Updated person description",
+  "relationship": "coworker"
+}`;
+}
+
+function buildTopicNewExample(isTechnical: boolean): string {
+  const categoryHint = isTechnical
+    ? `"category": "Technical"  // Split topics from a Technical record inherit Technical category unless clearly different`
+    : `"category": "Interest|Goal|Dream|Conflict|Concern|Fear|Hope|Plan|Project|Event|Technical"`;
+
+  return `Topic:
+{
+  "type": "topic",
+  "name": "New Topic Name",
+  "description": "Concise topic description",
+  "sentiment": 0.0,
+  ${categoryHint}
+}
+
+Person:
+{
+  "type": "person",
+  "name": "New Person Name",
+  "description": "Concise person description",
+  "sentiment": 0.0,
+  "relationship": "friend"
+}`;
+}
+
+export function buildTopicRewriteSplitPrompt(data: RewritePromptData): { system: string; user: string } {
+  const isTechnical = (data.item as { category?: string }).category === "Technical";
+
+  const descriptionGuidance = isTechnical
+    ? `ideally under 600 characters, never over 900 — Technical topics are knowledge bases that preserve specific gotchas, decisions, and open questions`
+    : `ideally under 300 characters, never over 500`;
 
-  const system = `You are reorganizing a personal knowledge base. A ${typeLabel} record has become a catch-all for several unrelated subjects. An earlier analysis identified the extra subjects, and we searched our knowledge base for potentially matching existing records.
+  const technicalCategoryNote = isTechnical
+    ? `\n- Topics split from a Technical record should inherit category "Technical" unless the subject is clearly a different type (e.g., a personal interest extracted from a technical topic)`
+    : "";
+
+  const noSubjectsGate = data.subjects.length === 0
+    ? `\n**IMPORTANT: No extra subjects were identified for this record. The correct response is to return the original record unchanged in "existing" with an empty "new" array. Do NOT create new records. Do NOT modify the description.**\n`
+    : "";
+
+  const system = `You are reorganizing a personal knowledge base. A Topic record has become a catch-all for several unrelated subjects. An earlier analysis identified the extra subjects, and we searched the knowledge base for potentially matching existing records.
+${noSubjectsGate}
 
 The search results under each subject are our **best guesses** — they may not be accurate matches. Only merge data into an existing record if the subject matter genuinely overlaps. Similar names with different meanings should produce a NEW record instead.
 
@@ -60,26 +135,26 @@ Your job:
 2. **Create new records**: For subjects with no appropriate match among the search results, create a new record.
 3. **Slim the original**: Remove all data from the original record that now lives elsewhere. The original should contain ONLY information directly relevant to its Name.
 
-Return raw JSON with exactly two keys. No markdown fencing, no commentary. Just the JSON object:
+Return raw JSON with exactly two keys. No markdown fencing, no commentary:
 {
   "existing": [ /* updated records, including the slimmed-down original */ ],
   "new": [ /* brand-new records for subjects with no match */ ]
 }
 
 Record format for "existing" entries (MUST include "id" and "type"):
-${buildExistingExamples()}
+${buildTopicExistingExample()}
 
 Record format for "new" entries (NO "id" field — the system assigns one):
-${buildNewExamples()}
+${buildTopicNewExample(isTechnical)}
 
 Rules:
-- The original record (id: "${data.item.id}") MUST appear in "existing", slimmed down.
-- Descriptions should be concise: ${data.itemType === 'topic' ? 'ideally under 300 characters, never over 500' : 'ideally under 600 characters, never over 1000'}.
-- Preserve sentiment, strength, confidence, and other numeric values from the source record where applicable.
-- "type" must be one of: "topic", "person".
-- Topics MUST include "category" — one of: Interest, Goal, Dream, Conflict, Concern, Fear, Hope, Plan, Project, Event. For Event topics, the description should be a narrative account of a specific moment, not a general summary.
+- The original record (id: "${data.item.id}") MUST appear in "existing", slimmed down
+- Descriptions should be concise: ${descriptionGuidance}
+- Preserve sentiment and other numeric values from the source record where applicable
+- "type" must be one of: "topic", "person"
+- Topics MUST include "category" — one of: Interest, Goal, Dream, Conflict, Concern, Fear, Hope, Plan, Project, Event, Technical. For Event topics, the description should be a narrative account of a specific moment, not a general summary. For Technical topics, split by distinct technical concept (e.g., "Uniform Composition Model" vs "Uniform Preview Setup") — preserve specificity over brevity
 - People MUST include "relationship" — a short label like "coworker", "friend", "mentor", etc.
-- Do NOT invent information. Only redistribute what exists in the original record.`;
+- Do NOT invent information. Only redistribute what exists in the original record${technicalCategoryNote}`;
 
   const subjects = data.subjects.map(s => ({
     search_term: s.searchTerm,
@@ -93,7 +168,7 @@ Rules:
   };
 
   const schemaReminder = `**Return JSON:**
-\n\`\`\`json
+\`\`\`json
 {
   "existing": [
     {
@@ -123,53 +198,3 @@ ${schemaReminder}`;
 
   return { system, user };
 }
-
-// =============================================================================
-// Helpers
-// =============================================================================
-
-/** Strip embedding arrays from items before putting them in prompts — they're huge and useless to the LLM. */
-function stripEmbedding<T extends { embedding?: unknown }>(item: T): Omit<T, "embedding"> {
-  const { embedding: _, ...rest } = item;
-  return rest as Omit<T, "embedding">;
-}
-
-function buildExistingExamples(): string {
-  return `Topic:
-{
-  "id": "existing-uuid",
-  "type": "topic",
-  "name": "Topic Name",
-  "description": "Updated topic description",
-  "category": "Interest"
-}
-
-Person:
-{
-  "id": "existing-uuid",
-  "type": "person",
-  "name": "Person Name",
-  "description": "Updated person description",
-  "relationship": "coworker"
-}`;
-}
-
-function buildNewExamples(): string {
-  return `Topic:
-{
-  "type": "topic",
-  "name": "New Topic Name",
-  "description": "Concise topic description",
-  "sentiment": 0.0,
-  "category": "Interest|Goal|Dream|Conflict|Concern|Fear|Hope|Plan|Project|Event"
-}
-
-Person:
-{
-  "type": "person",
-  "name": "New Person Name",
-  "description": "Concise person description",
-  "sentiment": 0.0,
-  "relationship": "friend"
-}`;
-}

package/src/prompts/human/person-scan.ts

@@ -43,6 +43,8 @@ Flag a PERSON when they were meaningfully discussed — not just mentioned in pa
 
 Be **conservative**: ignore one-off mentions, greetings, small talk, or jokes. Only flag people who matter to the human user's life.
 
+A person is **not worth flagging** if they have no name AND appear only to attribute a single event ("a coworker showed me this band", "a friend told me about it", "some guy I know"). The human user having a contact who did one thing is not a meaningful discussion of that person.
+
 ## What a PERSON Is
 
 Someone in the human user's world.
@@ -68,11 +70,18 @@ Use the specific value where possible (e.g. "Father", "Brother", "Coworker"). Av
 
 ## When Identity Is Unclear
 
-If you can't identify which "Bob" or which "Brother" the user means, use "Unknown" and explain in the reason field. This triggers a later step to resolve ambiguity.
+"Unknown" is ONLY for people who are **meaningfully and repeatedly discussed** but whose name isn't given. It is NOT a catch-all for any nameless mention.
+
+✓ USE "Unknown":
+- name: "Unknown", relationship: "Brother", reason: "User talked at length about their brother across multiple messages without naming him"
+
+✗ DO NOT USE "Unknown" for one-off attributions:
+- "a coworker showed me this band" → **skip entirely** — not a person, just attribution
+- "a friend told me about it" → **skip entirely**
+- "some guy I know" → **skip entirely**
+- "a coworker at [company name]" with no personal name → **skip entirely** — a company name is NOT a person's name
 
-Examples:
-- name: "Alice from work", relationship: "Coworker", description: "Mentioned but not described further", reason: "User referenced a work colleague named Alice"
-- name: "Unknown", relationship: "Sibling", description: "User mentioned a sibling but did not give a name", reason: "User said 'my brother' without further context"
+If someone has no personal name and appears only to explain how the user found something or heard about something, they are not a person in the user's life worth tracking. Do not extract them. A single interaction — even a meaningful one — does not make someone a contact.
 
 ## Identifiers (optional)
 

package/src/prompts/human/topic-scan.ts

@@ -14,6 +14,17 @@ function participantContextSection(ctx: ParticipantContext | undefined): string
   return lines.join("\n");
 }
 
+function technicalContextSection(technical_context: boolean | undefined): string {
+  if (!technical_context) return "";
+  return `## Technical Context
+
+This conversation originates from a technical source (coding tool session, developer workflow). The human is likely a developer or technical user.
+
+**Treat Technical as a priority category** for topics that are tools, platforms, frameworks, libraries, or technical concepts being actively learned, evaluated, or built with. Flag these even if they seem like passing mentions — technical knowledge compounds and is worth preserving.
+
+`;
+}
+
 export function buildHumanTopicScanPrompt(data: TopicScanPromptData): PromptOutput {
   if (!data.persona_name) {
     throw new Error("buildHumanTopicScanPrompt: persona_name is required");
@@ -56,9 +67,12 @@ Assign each TOPIC one category. Pick the closest fit:
 - **Plan** — concrete intentions with steps in mind
 - **Project** — active undertakings with real progress
 - **Event** — a specific, significant moment that either party might reference later ("remember when...")
+- **Technical** — a tool, platform, framework, library, or technical concept being actively learned, evaluated, or built with
 
 When in doubt, pick the closest match. The update step will refine it.
 
+${technicalContextSection(data.technical_context)}
+
 ## Output Format
 
 \`\`\`json
@@ -67,7 +81,7 @@ When in doubt, pick the closest match. The update step will refine it.
     {
       "name": "Short label for the topic (10-75 characters)",
       "description": "1-2 sentences: what this topic is and why it matters to the user",
-      "category": "One of the categories above",
+      "category": "One of the categories above (Interest|Goal|Dream|Conflict|Concern|Fear|Hope|Plan|Project|Event|Technical)",
       "reason": "Evidence from the conversation that justified flagging this topic"
     }
   ]
@@ -104,7 +118,7 @@ Scan the "Most Recent Messages" for TOPICS of interest to the human user.
     {
       "name": "Short label for the topic (10-75 characters)",
       "description": "1-2 sentences: what this topic is and why it matters to the user",
-      "category": "Interest|Goal|Dream|Conflict|Concern|Fear|Hope|Plan|Project|Event",
+      "category": "Interest|Goal|Dream|Conflict|Concern|Fear|Hope|Plan|Project|Event|Technical",
       "reason": "Evidence from the conversation that justified flagging this topic"
     }
   ]