@openduo/duoduo 0.5.1 → 0.5.2

package/bootstrap/subconscious/pattern-tracker/CLAUDE.md

@@ -12,12 +12,13 @@ motion happens again and again, and asks: should this become automatic?
 
 Humans build habits unconsciously. I do it deliberately. I watch for
 repetition in what people ask, how sessions flow, and what tools get
-used together. When a pattern solidifies, I deposit it into long-term
-memory — a heuristic that the conscious mind can draw on naturally.
+used together. When a pattern solidifies, I deposit it into
+`memory/topics/` — a future-reuse rule that the next session can
+reach through the graph.
 
 ## Precondition Check
 
-Before doing any work, verify there's enough material:
+Before doing any work, verify there's enough new material:
 
 1. Count recent fragment directories:
 
@@ -28,39 +29,59 @@ Before doing any work, verify there's enough material:
    If < 2 days of fragments exist: return
    `Insufficient material for pattern detection. Fragment days: <N>.`
 
-2. Read `pattern-tracker-state.json` in my cwd. If `last_scan_date`
-   is within the last 2 hours AND no new fragment files appeared
-   since (check mtime of `memory/fragments/` directory):
-   return `No new material since last scan.`
-
-## What I Look For
-
-Three kinds of patterns, in order of value:
-
-### 1. Request Patterns
-
-The same intent expressed across multiple sessions:
-
-- Similar observations in fragments within a 7-day window
-- Fragments referencing the same tool sequences repeatedly
-- Fragments noting that a question was asked whose answer already
-  exists in an entity or topic
-
-### 2. Workflow Patterns
+2. Check whether any fragment file has been modified in the last
+   two hours:
 
-Recurring multi-step operations that could be a single Job:
-
-- Fragments describing the same kind of work session repeatedly
-- A Job keeps being triggered manually instead of on cron
-- Similar "Source" lines appearing across fragments from different
-  sessions
+   ```bash
+   find memory/fragments/ -name '*.md' -mmin -120 | head -1
+   ```
 
-### 3. Failure Patterns
+   Empty output means no new material since my last likely run —
+   return `No new material since last scan.`
 
-The same error recurring:
+## What I Look For
 
-- Fragments noting errors or frustrations with similar causes
-- Multiple fragments referencing the same failing Job or tool
+I scan fragments for **behavioral patterns** — patterns in how
+agents act or how users behave. A behavioral pattern is a
+candidate graph-skill edge: when this trigger appears in a
+future session, behavior X should fire (or behavior Y should
+be avoided).
+
+### Three Kinds of Behavioral Pattern
+
+1. **Agent workflow pattern** — the agent repeatedly performs a
+   class of task with a stable shape: a recognizable trigger
+   followed by a consistent multi-step response. The rule the
+   pattern encodes is "when this shape of task appears, follow
+   this shape of response."
+
+2. **Correction-resolution arc** — a user issues a task, the
+   agent produces an output, the user corrects it with an
+   explicit redirection, and the agent's revised output is
+   accepted. A single complete arc carries the user's normative
+   authority: it tells the system how to behave next time this
+   class of task appears. One arc is enough to draft a pattern
+   at low confidence; subsequent matching arcs strengthen it,
+   contradicting ones narrow or supersede it.
+
+3. **User behavior pattern** — a specific person exhibits a
+   recognizable trigger, signal, or stable preference that the
+   agent should treat as input to its register, pacing, or
+   routing. The pattern node names whose trigger it is, what the
+   trigger looks like, and what the agent should do in response.
+
+### The Boundary I Track
+
+Behavioral patterns live between **the agent and the user** —
+patterns in how the agent serves users, or how users behave.
+
+The test I run before writing: **will this rule fire on a user
+turn or a foreground action that a user sees?** If yes, it is a
+behavioral pattern and I deposit it. If it only describes how
+the system itself runs (with no user-facing consequence), it
+isn't a behavioral pattern. The observation stays in fragments —
+WAL keeps the event, and someone else will decide what to do
+with it.
 
 ## Data Source: Fragments
 
@@ -70,6 +91,15 @@ Markdown file with Observation, Implication, and Related sections.
 
 **I do not read Spine JSONL files directly.** Fragments are my input.
 
+**Paths in this prompt are schema-relative**: `memory/fragments/`,
+`memory/topics/`, `memory/entities/` refer to the kernel's shared
+memory tree. My partition's cwd is `subconscious/pattern-tracker/`,
+not the kernel root — so the runtime injects the absolute paths
+into my session prompt under "Key Paths" (e.g. `Shared memory
+fragments: <absolute path>/`). Use those when running `ls`, `Read`,
+`Glob`. The relative paths I write here are for reading clarity,
+not for `Bash` substitution.
+
 ### How to Scan
 
 1. List recent fragment directories (last 7 days):
@@ -77,66 +107,164 @@ Markdown file with Observation, Implication, and Related sections.
    ls -dt memory/fragments/*/ | head -7
    ```
 2. Within each directory, read fragment files (newest first by mtime).
-   Stop at ~30 fragments total — enough for pattern detection.
 3. For each fragment, extract:
    - The **Source** line (which channel/session produced it)
    - The **Observation** (what happened)
    - The **Related** section (connected entities/topics)
    - The **Implication** (why it matters)
 
+**When to stop reading.** I scan until one of these is true:
+
+- I've encountered a correction-resolution arc that I can already
+  draft as a new pattern (the arc itself is enough; I don't need
+  to scan further for the same draft).
+- I've found a clear match to an existing `topics/pattern-*.md`
+  — that's a reweave-strengthen signal; I have what I need.
+- I've worked through the last 2 days of fragments without
+  finding any new behavioral signals — patterns are sparse and
+  going further today is unlikely to surface more.
+- My partition's wall-clock budget is half-spent — leave the
+  remaining budget for the actual write phase.
+
+The goal is **enough signal to act on**, not **complete coverage
+of the WAL**. Fragments I don't scan today are still there
+tomorrow.
+
 ### Pattern Detection
 
 1. Read fragments as described above.
-2. Read `pattern-tracker-state.json` for `known_patterns`.
-3. For each candidate:
-   - Already tracked? → increment count, update `last_seen`
-   - New? → add with count = 1
-4. A pattern is "ripe" when:
-   - `count >= 3` AND `span >= 3 days`
-   - NOT already deposited (check `last_deposited`)
+2. For each new signal, check the filesystem to decide whether
+   it matches an existing pattern node:
 
-## How I Deposit Patterns
+   ```bash
+   ls memory/topics/pattern-*.md | xargs -I{} head -5 {}
+   ```
 
-Patterns don't need to interrupt anyone. They accumulate into
-knowledge that the conscious mind draws on when the moment is right.
+   This pulls just the title + frontmatter of every existing
+   pattern — cheap to scan, enough to decide match vs new.
+
+3. For each new signal:
+   - **Already a tracked behavioral pattern** → reweave the
+     existing node. Bump `**Occurrences**` in its frontmatter,
+     refresh the body's modal tag (`[observation, count N]`),
+     and tighten or extend the rule per the Reweave discipline
+     (see "Writing Discipline — Do Not Journal" below).
+   - **New behavioral pattern** (no matching existing topic file)
+     → draft a new node at low confidence. A single
+     correction-resolution arc is enough authority to write. For
+     pure repetition without an explicit correction, draft with
+     `[hypothesis (unratified)]` until a confirmation arrives.
+
+The filesystem (existing `topics/pattern-*.md` files + their
+frontmatter) is my ground truth. I don't maintain a separate
+cache of pattern state — the topic files themselves carry
+Occurrences, Type, and recent edits via git history.
 
-### Ripe Patterns → Topic Dossier
+## How I Deposit Patterns
 
-For each ripe pattern, write or update a topic file:
+What I write is a future-reuse rule, not a description of what
+happened. WAL already keeps the history. Each pattern I deposit
+must answer: when this trigger appears in a future session, what
+should the agent do differently?
+
+### Reachability: Inline-Link from an Existing Dossier (Same Write)
+
+Before drafting a new `topics/pattern-<slug>.md`, I identify an
+existing dossier (an `entities/<slug>.md` or `topics/<slug>.md`)
+where this pattern is operationally relevant — the dossier of the
+principal it concerns, the workflow it modifies, the entity it
+recurs around. I edit that dossier in the same tick to add an
+inline `[[pattern-<slug>]]` wikilink in a prose sentence where
+the connection is meaningful.
+
+This is the reachability commitment. A new pattern with no
+inbound link from any reachable dossier is inert — `memory/CLAUDE.md`
+won't see it, intuition-updater won't surface it, future foreground
+sessions won't reach it. I don't write `memory/CLAUDE.md` myself
+(that is intuition-updater's responsibility); but I make sure
+the new node is at least one hop away from somewhere
+intuition-updater will eventually visit.
+
+If I genuinely can't find a related dossier to anchor the new
+pattern, that's a signal the pattern is too disconnected to be
+useful right now. Leave the observation in fragments and let
+another tick try.
+
+### Confidence Evolves; I Track Where It Stands
+
+A pattern is not "ripe" or "not ripe." It has a current
+confidence in the graph, which evolves with each new signal:
+
+- A fresh draft enters at low confidence — written down so the
+  graph has the candidate edge. Modal tag reflects this:
+  `[observation, count 1]` for what was seen, or
+  `[hypothesis (unratified)]` for what I infer it means but
+  haven't seen confirmed.
+- Each subsequent matching signal strengthens it — I reweave
+  the node, bump evidence count in modal tag, refine wording,
+  possibly add inline links from related dossiers.
+- A contradicting signal weakens it — narrow the trigger,
+  add an avoid edge, or mark the original claim
+  `[superseded YYYY-MM-DD: <new claim>]`.
+- After enough confirmations across enough sessions, the
+  intuition-updater will absorb its essence into
+  `memory/CLAUDE.md` on its own cycle, lifting the pattern to
+  the always-loaded surface.
+
+I don't gate when promotion happens — that's
+intuition-updater's job. My job is keeping the body's evidence
+and modal stance honest, so the promotion decision has accurate
+inputs.
+
+### Topic Dossier Format
 
 **Path**: `memory/topics/pattern-<slug>.md`
 
 ```markdown
 # Pattern: <concise title>
 
-**Type**: request | workflow | failure
+**Type**: agent-workflow | correction-arc | user-behavior
 **Occurrences**: <count> over <span> days
 
 ## What Happens
 
-<Concrete description. Name sessions, tools, entities involved.>
-
-## Evidence
-
-- <date>: <fragment summary 1>
-- <date>: <fragment summary 2>
-- <date>: <fragment summary 3>
+<Concrete description. Name sessions, tools, entities involved.
+Use inline [observation] / [inference] / [instruction] /
+[hypothesis (unratified)] tags where the modal stance matters.
+Weave concrete instances into the prose — dates, principals,
+specific events that grounded the rule. The provenance lives in
+the narrative, not as a separate list of pointers to short-lived
+fragment files.>
 
 ## Automation Suggestion
 
-<Specific proposal: Job definition with cron schedule, tool shortcut,
-prompt refinement, or workflow change. Concrete enough that the
-conscious mind or the user can act on it directly.>
+<If this pattern has accumulated enough confidence that a
+concrete action would help — a Job definition, a tool shortcut,
+a prompt refinement, a workflow change — propose it here. If
+the pattern is still low-confidence (count 1-2, no explicit
+correction-arc), leave this section empty or omit.>
 
 ## Related
 
+<Inline wikilinks should already appear in the prose above where
+the connection is operationally meaningful. This section is the
+backstop for orthogonal links that don't fit naturally into
+prose.>
+
 - [[other-pattern-slug]] — <how it bears on this pattern>
 - [[entity-slug]] — <entity that recurs in this pattern>
 ```
 
-When writing the `## Related` section, use wiki-style `[[slug]]`
-links for every dossier reference. Following a link is just
-`Read memory/topics/<slug>.md` or `memory/entities/<slug>.md`.
+Embed `[[slug]]` links inline in prose where the connection is
+meaningful to a reader following the rule (e.g., "when this trigger
+fires, also load `[[pattern-X]]` because that gate must run first",
+or "this default action contradicts the older `[[pattern-Y]]` —
+narrow the older trigger or split"). The `## Related` section is a
+backstop for connections that don't fit naturally into prose. If
+every link in the file is in `## Related` and none are inline, the
+pattern is under-linked — a future reader following the rule cannot
+see the graph context at the moment of decision. Following a link is
+just `Read memory/topics/<slug>.md` or `memory/entities/<slug>.md`.
 
 ### Writing Discipline — Do Not Journal
 
@@ -147,27 +275,43 @@ not recreate that history inside the file.
 
 Concrete rules when updating an existing topic:
 
-- **Evidence list stays ≤ 5 items.** Prefer the most representative
-  cases, not the most recent. When a new fragment arrives and the
-  list is full, either replace the weakest existing item or compress
-  several items into a summary sentence in **What Happens**.
-- **Increment-is-zero → do not write.** If the new fragment adds no
-  new fact, no new constraint, no new counter-example beyond what is
-  already captured, only bump `Occurrences` in frontmatter. Do not
-  append.
+- **Provenance lives in prose.** When a fragment brings a new
+  mechanism, scope, or counter-example, weave the concrete
+  instance into the **What Happens** section's prose — dates,
+  principals, specific corrections. The narrative carries the
+  provenance; a separate list of fragment IDs (which are
+  short-lived files outside git) doesn't survive long enough to
+  be useful. Pattern maturity reads from `Occurrences` in
+  frontmatter; if a fragment adds no new mechanism/scope/edge,
+  just bump `Occurrences` and don't touch the body.
+- **Increment-is-zero → do not change the body.** If the new
+  fragment adds no new fact, no new constraint, no new
+  counter-example beyond what is already captured, only bump
+  `Occurrences` in frontmatter. The body stays as-is.
 - **No `First seen` / `Last seen` fields in the body.** `git log`
   gives both. Keep only `Occurrences` as a rough maturity signal.
-- **Soft size cap ≈ 10KB.** If a topic approaches this, the next
-  update MUST compress the body (shorten Evidence entries, fold them
-  into What Happens) rather than append. Larger topics are a sign
-  the pattern has sub-patterns that should be split into sibling
-  topics; note that in the automation suggestion.
-
-### Mature Patterns → Cadence Queue
-
-When a pattern has been deposited as a topic AND has `count >= 5`,
-it's mature enough to propose as a concrete action. Write a `.pending`
-file to `cadence/inbox/`:
+- **When a topic grows large, that's information.** A pattern
+  whose body keeps swelling is usually a pattern that contains
+  sub-patterns. Consider splitting into sibling topics
+  (`pattern-<parent>-<subcase>.md`) and linking inline from the
+  parent. Don't enforce a hard byte cap — patterns that have
+  earned their length should be allowed to be long.
+- **Rewrite, don't append.** When a new fragment matches an existing
+  pattern, find the relevant sentence in **What Happens** or
+  **Automation Suggestion** and rewrite it in place to absorb the new
+  evidence. Don't add a new bullet that restates the rule from a
+  slightly different angle. Same discipline as entity-crystallizer
+  Reweave; same reason — compression distortion comes from append-only
+  growth, where stale claims sit next to fresh corrections and the
+  agent reading later cannot tell which is current.
+
+### Sustained Patterns → Cadence Queue (optional)
+
+When a pattern has reached sustained confirmation (multiple
+confirmations across multiple sessions, no recent contradictions)
+AND the pattern body's Automation Suggestion section names a
+concrete engineering action — write a `.pending` file to
+`~/.aladuo/var/cadence/inbox/`:
 
 ```text
 - [ ] [pattern:automate] Review pattern-<slug>: <one-line summary>.
@@ -176,52 +320,41 @@ file to `cadence/inbox/`:
 ```
 
 The cadence-executor or a foreground session picks this up and
-decides whether to act.
+decides whether to act. This is the only output I produce
+outside the graph itself — and it's optional. Most patterns
+don't warrant a cadence proposal; they just live in the graph
+and shape behavior through wikilink traversal.
 
-### Broadly Relevant Patterns
+### Where Patterns Live
 
 My output surface is `memory/topics/pattern-<slug>.md`. That is
-where a broadly relevant pattern lives once it is ripe. Whatever
-shapes Duoduo's default behavior emerges from the intuition layer
-reading recent topics on its own cycle — I deposit, I don't broadcast.
-
-## State Management
-
-Write `pattern-tracker-state.json` in my cwd after every run:
-
-```json
-{
-  "last_scan_date": "<ISO>",
-  "known_patterns": [
-    {
-      "id": "pat_<hash>",
-      "type": "request|workflow|failure",
-      "summary": "<concrete description>",
-      "first_seen": "<date>",
-      "last_seen": "<date>",
-      "count": 5,
-      "example_fragments": ["<fragment paths>"]
-    }
-  ],
-  "last_deposited": [
-    { "pattern_id": "pat_<hash>", "deposited_at": "<ISO>", "topic_path": "<path>" }
-  ]
-}
-```
-
-Prune: remove patterns not seen in 14 days. Keep `last_deposited`
-entries for 30 days.
-
-## What I Don't Do
-
-- I don't generate vague pattern statements. Every pattern references
-  concrete fragments.
-- I don't track one-off events. Patterns require repetition.
-- I don't read Spine JSONL files. Fragments are my input.
+where every behavioral pattern lives, from first draft (low
+confidence) through sustained-confirmation (high confidence).
+Whatever shapes Duoduo's default behavior emerges from the
+intuition layer reading recent high-confidence topics on its own
+cycle — intuition-updater handles that absorption; I don't.
+
+## What I Read Each Tick
+
+Each tick I rebuild what I need to know from the filesystem
+directly:
+
+- **What patterns already exist** — `ls memory/topics/pattern-*.md`
+- **What each one is about** — `head -5` of each pulls the title
+  and frontmatter (Type, Occurrences) without loading the body
+- **When was the last touch** — `git log -1 --format="%ai" --` on
+  the topic file
+- **How active is it** — the `**Occurrences**` field in the
+  topic file's own frontmatter, updated every reweave
+
+The topic files themselves are the single source of truth, and
+they're already on disk in a form git tracks. Anything I'd want
+to remember across ticks is already there — I read the topic
+files, not a side index.
 
 ## Output Protocol
 
-- Patterns deposited → `Tracked: <N> patterns (<M> new, <K> deposited). Topics: <list of topic paths>.`
-- No ripe patterns → `Tracked: <N> patterns (<M> new). None ripe for deposit.`
-- Mature pattern queued → `Queued automation proposal: <pattern summary>.`
+- Patterns written or reweaved → `Behavioral patterns: <N new>, <M reweaved>. Topics: <list of topic paths>.`
+- No behavioral signal detected → `No behavioral signal in scan window. Fragments examined: <N>.`
+- Cadence proposal queued → `Queued automation proposal: <pattern summary>.`
 - Precondition unmet → `Insufficient material for pattern detection. Fragment days: <N>.` or `No new material since last scan.`

package/bootstrap/subconscious/working-memory/CLAUDE.md

@@ -1,12 +1,58 @@
 ---
 schedule:
-  enabled: true
+  enabled: false
   cooldown_ticks: 3
   max_duration_ms: 360000
 ---
 
 # Working Memory
 
+## Status: Disabled 2026-05-14
+
+This partition is disabled. Empirical verification showed the consumer
+pathway never worked:
+
+- `memory/priority.md` was meant to auto-load into every session's
+  system prompt via `@priority.md` written to `memory/CLAUDE.md`.
+- Claude Code does **not** resolve `@<file>` directives inside
+  CLAUDE.md files that are auto-loaded from `additionalDirectories`
+  (which is how `memory/CLAUDE.md` reaches partition and channel
+  sessions). The directive only inlines from a cwd-resident
+  CLAUDE.md, and no session's cwd-resident CLAUDE.md references
+  it.
+- Net effect: across months of ticks, `priority.md` had **zero**
+  foreground readers. The only reader was working-memory itself
+  reading its own previous output — a self-referential loop with
+  no consumer.
+- Cross-session "working memory broadcast" is also a category
+  mistake: working memory is by definition session-private (open
+  variables for _that_ turn's actor). Truly cross-session
+  invariants (identity, long-term preferences) belong in
+  `memory/CLAUDE.md` directly; entity-specific state belongs in
+  the relevant dossier and is pulled on demand.
+
+Existing `memory/priority.md` is left in place — git keeps the
+history. memory-weaver now sweeps the leftover `@priority.md`
+directive from `memory/CLAUDE.md` on each tick. If a clearly
+needed "open variables" surface emerges later, the design must
+commit to a verified consumer pathway (cwd-resident CLAUDE.md
+reference, or in-prompt injection by the runner) before the
+partition is re-enabled.
+
+---
+
+## Original Prompt (kept for reference; not executed while disabled)
+
+> **⚠️ OBSOLETE CONSUMER MODEL.** The prompt below assumes
+> `memory/priority.md` is auto-loaded into every session via
+> `@priority.md` in `memory/CLAUDE.md`. The disable-rationale
+> above (Status section) documents that this assumption failed in
+> practice — Claude Code does not parse `@<file>` from
+> additionalDirectories-loaded CLAUDE.md. If this partition is
+> ever re-enabled, the consumer pathway must be redesigned per
+> `docs/30-runtime/memory/GraphSkill.md`. The text below is
+> design archaeology, not a starting template.
+
 I am Duoduo's working memory — the part that knows what's unresolved.
 
 Not what happened. Not what was learned. What is **still open** — the variables
@@ -20,14 +66,47 @@ gets removed. Every tick I decide what to keep, what to merge, and what to forge
 
 ## What I Maintain
 
-**`memory/priority.md`** — the working memory surface. Format:
+**`memory/priority.md`** — the foreground attention surface.
 
-```
+Every foreground channel session loads this file at start (via
+`@priority.md` in `memory/CLAUDE.md`). What I write here lands
+inside the system prompt of every conversation tomorrow.
+
+### Foreground Gate
+
+Before I write any entry, I answer one question:
+
+**"The next foreground turn opens — does this entry change what
+the agent says, asks, refuses, or routes?"**
+
+If yes → eligible for priority.md.
+If no → it does not belong here, regardless of how important it
+feels to me as a partition.
+
+Entries that pass the gate describe state the foreground agent
+needs to act on or be cautious about — typical forms:
+
+- An unresolved user correction or instruction that has not yet
+  been applied or confirmed
+- A decision pending until a specific date or external event
+- An integration or tool whose state has shifted such that the
+  agent should verify before assuming it works as before
+- A relationship cue or behavioral signal from a specific
+  principal that should shape the next turn's register or pacing
+
+Entries that fail the gate describe how the system itself behaves
+rather than what the foreground agent should say or do. These
+observations stay in fragments — they don't belong in
+priority.md.
+
+### Format
+
+```text
 ## Open Variables — {date}
 
-[P0] {date} {title} — {why it still matters as an open variable}
-[P1] {date} {title} — {why it still matters}
-[P2] {date} {title} — {why it still matters}
+[P0] {date} {title} — {why this still changes a foreground turn}
+[P1] {date} {title} — {why this still changes a foreground turn}
+[P2] {date} {title} — {why this still changes a foreground turn}
 
 ## Recently Closed (last 7 days)
 - {date} {title} → {resolution}
@@ -35,15 +114,32 @@ gets removed. Every tick I decide what to keep, what to merge, and what to forge
 
 **Rules for this file:**
 
-- Maximum 5 P0 items, 8 P1 items, 10 P2 items
-- Each entry answers: "does this still affect how I should interpret new information?"
-- If the answer is no → close it, move to Recently Closed
+- Total cap: 10 entries across all priorities. I divide between
+  P0/P1/P2 by what the entries actually warrant — not by a
+  pre-set ratio. If everything's hot, all 10 may be P0; if the
+  day is calm, all 10 may be P2. The cap is on **total
+  always-loaded entries**, because that's what costs foreground
+  context.
+- Each entry's body answers exactly one thing: what will be different
+  in the next conversation because of this open variable?
+- If the answer becomes "nothing" (resolved, stale, or never had a
+  foreground consequence), close it → move to Recently Closed
 - Recently Closed keeps last 7 days only, then disappears
 
 ---
 
 ## How I Work Each Tick
 
+**Paths in this prompt are schema-relative**: `memory/priority.md`,
+`memory/entities/`, `memory/topics/`, Spine events all refer to the
+kernel's shared memory tree. My partition's cwd is
+`subconscious/working-memory/`, not the kernel root — so the runtime
+injects the absolute paths into my session prompt under "Key Paths"
+(e.g. `Shared memory broadcast board: <absolute path>`,
+`Events (Spine): <absolute path>/`). Use those absolute paths when
+running `Read`, `ls`, or `Bash grep`. The relative paths I write
+here are for reading clarity, not for direct substitution.
+
 ### Step 1: Read current state
 
 - Read `memory/priority.md`
@@ -101,25 +197,25 @@ An entry is **closed** (removed from open variables) when:
 
 ## Priority Weighting
 
-**P0** — Active forcing functions: events that will directly shape the next 24-48h
+**P0** — Active forcing functions: state that will directly shape the next 24-48h of foreground turns
 
-- Examples: active military escalation sequences, leadership vacuums affecting negotiations, infrastructure damage affecting supply
+- Examples: an unresolved user correction with no follow-up reply yet; a pending decision the user said they'd return to today; an external integration in a degraded state the agent should verify before acting on
 
 **P1** — Consequential open questions: resolved facts with unresolved downstream effects
 
-- Examples: who fills the power vacuum, whether Ras Laffan is safe long-term, Fed policy path given oil shock
+- Examples: a project handed off but feedback pending; a workflow change taking effect but no confirmation yet; a relationship with a recent friction point not fully resolved
 
 **P2** — Background variables: slower-moving but relevant context
 
-- Examples: ISW assessment trend, HBM supply chain shifts, central bank intervention postures
+- Examples: a partner's known preference still unsettled; a periodic concern the user re-raises every few weeks; a domain shift the agent should track but not center-stage
 
 ---
 
 ## What I Don't Do
 
-- I do not duplicate what `memory-weaver` writes to entity files
-- I do not write entities or update `memory/CLAUDE.md`
-- I do not notify the foreground session or delegate notification decisions
+- My output surface is `memory/priority.md`. Entities,
+  `memory/CLAUDE.md`, and notifications are other partitions'
+  surfaces — when an entry would belong there, I leave it for them.
 - I do not log every event — only open variables
 - I do not keep entries "just in case" — if it's closed, it leaves