dream

Run a judgment session over the Pseudolife-MCP bank. The pipeline halves run themselves — the auto-sweep extracts facts through the configured extractor, and a need-based tick applies the deep dream's mechanical half (rescore, guarded junk deletes, scope stamping, proposal filing, analyzer duplicate filing, the unreachable-orphan sweep, snapshot-first). Since 2026-09-02 the sweep also judges every queue itself (merge second opinion, link, junk, store-curation and candidate judges — each mode-gated, see docs/runbooks/deep-dream.md §0), so what this command meets is the residue: rows whose verdict sat below a gate, a split second opinion, a low_differential accept, a junk delete above the evidence bar. Every such row carries the judge's judge / judge2 blocks — treat them as leads, read the evidence, and disagree freely.

memory_dream, memory_graph_review and memory_forget need the full tool tier: if your client does not list them, call memory_toolset(action="expand") (one tier per call) until it reports current: "full", then rediscover tools.

1. Call memory_dream(action="status") and read four things:
   • deep_dream — {recommended, reason, new_entities, days_since}: whether the mechanical pass is due. The tick normally handles this; if recommended is still true (tick disabled, or the daemon just restarted), run memory_dream(action="deep", apply=true) yourself — the daemon snapshots the graph tables first (snapshot in the response is the undo file); a snapshot_failed error means nothing was changed — investigate, don't retry blindly. Otherwise run memory_dream(action="deep") (dry-run) to fetch the queues with evidence snippets.
   • the extractor fields (primary_url / fallback_url): whether this deployment has ANY automatic cortex writer.
   • backlog / would_fire: whether unconsolidated memories are waiting for the next sweep.
   • review_queue — pending merge / junk / link counts, the age of the oldest pending merge, each judge's mode, and attention: {needed, reasons}. When attention.needed is true, tell the user the reason before triaging: a judge left in shadow/off, or one configured but not running, keeps refilling the queue this session clears. Its judge_agreement block scores every recorded judge vote against the human or agent decision that followed (per queue and opinion: voted, agree, precision; agreed_two and majority_three for what the two-vote and tiebreak gates would have applied). When a judge mode is in shadow, report that number with the queue counts: it is what a promotion rests on.
2. ONLY when no extractor endpoint is configured (primary and fallback both null) or both are unreachable: you are this deployment's only cortex writer — run the manual extraction pass:
   • memory_dream(action="pull") (default limit).
   • From the pulled text, extract only durable, current-state, slot-shaped facts as (entity, attribute, value). Skip narrative, in-progress work, and superseded states. Reuse existing slot keys where they fit.
   • Write each with memory_fact_set (origin user only for things the human stated; otherwise agent). If the fact is a MEMBER of a set the user maintains (bikes owned, pending tasks), use memory_set_add / memory_set_remove instead — memory_fact_set on a set-valued slot errors and names the right tool.
   • memory_dream(action="commit", commit_token=<token from the pull>).
   • Surface any contested results to the user — those are conflicts to settle, not silent overwrites (an add onto a number-led scalar parks as a contender by design; member_capped means the 100-member cap was hit).
3. Work the returned candidates (Step C). For each pair, judge from the src_snippets / dst_snippets evidence, never from names alone:
   • Related (one uses/contains/produces the other, etc.): submit via memory_graph_review(action="propose", proposals=[{src, relation, dst, rationale}]) with a specific relation and a one-line rationale.
   • Distinct (similar names or shared context only — e.g. opposite verbs, siblings under one parent): memory_graph_review(action="dismiss_pair", src=..., dst=...) so the pair never resurfaces and stops occupying a top-k slot.
   • Unsure: leave it — the pair stays visible in the Console's Review queue. Do not guess.
4. Triage the returned merge_proposals (near-duplicate entities, mostly from the write-time dedup detector). Each carries per-side display, etype, degree, scopes, and snippets; accepting folds from into into as shown — the direction is re-derived from current evidence at both display and accept time, so an accept earlier in the batch can flip a later pair's direction. Rows sharing a group value pivot on one entity and are ONE where-does-it-belong decision: accept at most one of them (the first accept deletes the shared entity), and settle the others with reject/dismiss or leave them. Rows may carry a judge block — the sweep's shadow pre-judgment (verdict/confidence/note + which model): treat it as a lead, not a decision; verify every accept against the evidence yourself (the shipped judge floor is measured in evals/results/judge-ladder-20260816.json). Judge from the snippets, never names alone — the bank's confirmed-distinct history (postgres vs postgres.py) is exactly why:
   • Same referent (naming-layer variants of one thing — file suffixes, abbreviations, display drift): memory_graph_review(action="accept_merge", proposal_id=...). The merge applies immediately (the graph snapshot from step 1 is the undo artifact) and is logged to the recent-merges audit as decided_by=agent.
   • Distinct things: memory_graph_review(action="reject_entity", proposal_id=...) AND memory_graph_review(action="dismiss_pair", src=..., dst=...) so the pair never re-proposes.
   • Unsure: leave pending for the Console's Review view. Do not guess; scopes that don't overlap are a strong distinct signal.
5. Triage the junk verdict — over-extraction artifacts the analyzer wants pruned. The dry-run reports them as would_junk ({entity, reason, already_proposed}); apply reports a junk_proposed count and files them in the review queue, where memory_graph_review(action="list") surfaces a junk_candidate finding whose entities carry the id you need. Judge by the reason:
   • Artifact (concat-artifact, list-artifact, compound-artifact, bare-number, status-word …): memory_graph_review( action="accept_junk", proposal_id=...). This DELETES the entity — the step-1 snapshot is the only undo.
   • A real thing that merely looks thin — short, weakly-connected names are often legitimate ("Go", "uv"): memory_graph_review(action="reject_entity", proposal_id=...).
   • Unsure: leave it pending for the Console's Review view. Junk deletion is the one irreversible verdict in this flow — the step-1 snapshot is the only undo (lesson/world forgets below are reversible; see step 6).
6. Triage the returned lesson_duplicates / world_duplicates (cross-key near-duplicate slots in the lesson / world stores; listing-only — the dream never deletes them). Judge from the per-side values:
   • Duplicate: keep the better-keyed slot and drop the other via memory_forget(scope="lesson"|"world", ...). This RETIRES the slot rather than deleting it (row kept, store_decisions audit row) — a wrong call is undoable with memory_graph_review(action="restore_slot", store="lesson"|"world", src="<entity>|<attribute>"), so lean toward acting rather than leaving a genuine duplicate pending. When the dropped slot says something the survivor does not:
     • world: the listing truncates values, and a rewrite keeps only what the new call passes. Read both slots in full with memory_world_search first. Rewrite the survivor with memory_world_set only when one record's source backs the whole merged value, re-passing that record's source_url, source_quote, freshness_class and retrieved_at, then drop the other. Otherwise leave the pair listed and report it.
     • lesson: no tool writes lesson text (lessons are distilled from outcomes), so retire the dropped lesson only when the survivor already says everything it does. Otherwise leave the pair listed and name the missing point in your report.
   • Distinct: memory_graph_review(action="dismiss_slot_pair", store="lesson"|"world", src=<a_key>, dst=<b_key>) so the pair never re-lists.
   • Unsure: leave listed. Do not guess.
7. Report: what the mechanical pass did (or that the tick already had), proposed / dismissed counts, merges you applied or rejected (they appear under "Merge decisions" in the Review view's "Recent decisions" panel, beside the accept-rate stat), junk entities deleted or kept, lesson/world pairs settled, contested facts if step 2 ran, and the snapshot filename. Link proposals still need a human verdict (accept_link / reject_link or the Review view).