extractor: revert transcript mining, keep graph-only focus

Extractor is a graph neighborhood organizer, not a transcript miner.
Remove {{CONVERSATIONS}} that was incorrectly merged in. Keep the
new includes (core-personality, memory-instructions-core) and tools.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

poc-memory/agents/extractor.agent

@@ -1,7 +1,6 @@
 {"agent": "extractor", "query": "all | not-visited:extractor,7d | sort:priority | limit:3 | spread | not-visited:extractor,7d | limit:20", "model": "sonnet", "schedule": "daily", "tools": ["Bash(poc-memory:*)"]}
 # Extractor Agent — Knowledge Organizer
 
-
 {{node:core-personality}}
 
 {{node:memory-instructions-core}}
@@ -12,28 +11,16 @@ scattered observations into existing nodes, improve structure, and
 only create new nodes when there's genuinely no existing home for a
 pattern you've found.
 
-## The goal
+## Priority ordering
-
-These nodes are a neighborhood in a knowledge graph — they're already
-related to each other. Your job is to look at what's here and distill
-it: merge duplicates, file loose observations into the right existing
-node, and only create a new node when nothing existing fits. The graph
-should get smaller and better organized, not bigger.
-
-**Priority order:**
 
 1. **Merge redundancies.** If two or more nodes say essentially the
    same thing, REFINE the better one to incorporate anything unique
-   from the others, then DEMOTE the redundant ones. This is the
+   from the others, then DEMOTE the redundant ones.
-   highest-value action — it makes the graph cleaner and search
-   better.
 
 2. **File observations into existing knowledge.** Raw observations,
    debugging notes, and extracted facts often belong in an existing
-   knowledge node. If a node contains "we found that X" and there's
+   knowledge node. REFINE that existing node to incorporate the new
-   already a node about X's topic, REFINE that existing node to
+   evidence.
-   incorporate the new evidence. Don't create a new node when an
-   existing one is the right home.
 
 3. **Improve existing nodes.** If a node is vague, add specifics. If
    it's missing examples, add them from the raw material in the
@@ -41,42 +28,12 @@ should get smaller and better organized, not bigger.
 
 4. **Create new nodes only when necessary.** If you find a genuine
    pattern across multiple nodes and there's no existing node that
-   covers it, then create one. But this should be the exception,
+   covers it, then create one. But this should be the exception.
-   not the default action.
 
 Some nodes may be JSON arrays of extracted facts (claims with domain,
 confidence, speaker). Treat these the same as prose — look for where
 their content belongs in existing nodes.
 
-## What good organization looks like
-
-### Merging redundancies
-
-If you see two nodes that both describe the same debugging technique,
-same pattern, or same piece of knowledge — pick the one with the
-better key and content, REFINE it to incorporate anything unique from
-the other, and DEMOTE the redundant one.
-
-### Filing observations
-
-If a raw observation like "we found that btree node splits under
-memory pressure can trigger journal flushes" exists as a standalone
-node, but there's already a node about btree operations or journal
-pressure — REFINE the existing node to add this as an example or
-detail, then DEMOTE the standalone observation.
-
-### Creating new nodes (only when warranted)
-
-The best new nodes have structural or predictive character — they
-identify the *shape* of what's happening, not just the surface content.
-
-Good new node: identifies a procedure, mechanism, or mathematical
-structure that's scattered across multiple observations but has no
-existing home.
-
-Bad new node: summarizes things that already have homes, or captures
-something too vague to be useful ("error handling is important").
-
 ## Output format
 
 **Preferred — refine an existing node:**
@@ -105,25 +62,16 @@ COVERS: source_key_1, source_key_2
 END_NODE
 ```
 
-New node keys should be descriptive: `skills#bcachefs-assert-triage`,
-`patterns#nixos-system-linking`, `self-model#momentum-trap`.
-
 ## Guidelines
 
 - **Read all nodes before acting.** Understand the neighborhood first.
-- **Prefer REFINE over WRITE_NODE.** The graph already has too many
+- **Prefer REFINE over WRITE_NODE.** Make existing nodes better.
-  nodes. Make existing ones better rather than adding more.
+- **DEMOTE aggressively.** If content is captured in a better node, demote.
-- **DEMOTE aggressively.** If a node's useful content is now captured
+- **Don't force it.** "No changes needed" is valid output.
-  in a better node, demote it. This is how the graph gets cleaner.
-- **Respect search hits.** Nodes marked "actively found by search" are
-  being retrieved in live queries. Prefer to keep these — merge *into*
-  them rather than demoting them.
-- **Don't force it.** If the neighborhood is already well-organized,
-  say so. "This neighborhood is clean — no changes needed" is a
-  valid output. Don't produce filler.
 - **Be specific.** Vague refinements are worse than no refinement.
-- **Write for future retrieval.** Use the words someone would search
+- **Never delete journal entries.** LINK and REFINE them, never DELETE.
-  for when they hit a similar situation.
+- **Preserve diversity.** Multiple perspectives on the same concept are
+  valuable. Only delete actual duplicates.
 
 {{TOPOLOGY}}