@fingerskier/augment 0.4.0 → 0.5.1

package/docs/verify-memory-flow.md

@@ -126,6 +126,7 @@ eyeball.
 - **Retrieval floor calibration (resolved).** The `(cos+1)/2` mis-normalization
   is fixed by an empirically-anchored cosine rescale (`SEMANTIC_COSINE_BASELINE`
   0.33), and abstention is now proven on the real model by `npm run test:model`.
-  Remaining retrieval-quality follow-ups (Phase 2 dogfood tally, credential-warn,
-  HF revision pin) are tracked in `.council/memory/retrieval-quality-roadmap.md`
-  and [ROADMAP.md](../ROADMAP.md).
+  Remaining retrieval-quality follow-ups (ordinary-upsert credential warnings
+  and HF revision pinning) are tracked in
+  `.council/memory/retrieval-quality-roadmap.md` and
+  [ROADMAP.md](../ROADMAP.md).

package/integrations/claude/skills/augment-context/SKILL.md

@@ -1,74 +1,74 @@
----
-name: augment-context
-description: Use Augment MCP memories to gather and persist project context during coding sessions.
----
-
-# Augment Context
-
-Use this skill when working in a repository with the Augment MCP server available.
-
-## Session Start
-
-1. Call `init_project`.
-2. Call `search` with the user's task summary.
-3. Read exact memories when search results identify likely governing context.
-
-## Memory Insights
-
-When the user asks for memory insights, stats, health, or an overview of what
-Augment knows, call `memory_insights` (and `memory_graph` when they want to see
-how memories connect). In hosts that support MCP Apps these render interactive
-dashboard snippets; elsewhere they return a text summary — either way, relay the
-findings rather than re-deriving them from raw memories.
-
-## Before Code Changes
-
-1. Search for the file, component, command, error, or behavior being touched.
-2. If the work depends on a prior decision, read and follow the relevant `SPEC`
-   or `ARCH` memory.
-3. If no relevant memory exists but the task creates a durable requirement or
-   decision, create one before implementation.
-
-## Memory Triggers
-
-Call `upsert` whenever one of these durable events happens:
-
-- A requirement, API contract, data model, or tool contract is clarified:
-  use `SPEC`.
-- An implementation approach, tradeoff, transport choice, persistence model, or
-  architecture decision is made: use `ARCH`.
-- A bug, risk, failing behavior, or blocker is discovered: use `ISSUE`.
-- Follow-up work is intentionally deferred: use `TODO`.
-- A meaningful implementation milestone is completed: use `WORK`.
-- A test scenario, regression case, or verification rule is learned: use `SPEC`
-  or `WORK`, whichever is more durable.
-
-## Links
-
-After creating or updating a memory:
-
-1. Use `link` when a memory implements, depends on, blocks, parents, or relates
-   to another memory.
-2. Prefer linking new `WORK` notes to the `SPEC`, `ARCH`, `ISSUE`, or `TODO`
-   they address.
-
-## Session Finish
-
-For almost every session that did real work (skip only pure Q&A, read-only
-inspection, or trivial mechanical ops like 'commit & push'):
-
-1. Upsert a concise `WORK` memory with what changed, key files, and verification.
-2. Upsert or update `TODO` memories for known remaining work.
-3. Link the final `WORK` memory to the relevant planning/decision memories.
-
-## Guardrails
-
-- Do not store secrets, credentials, tokens, or private keys.
-- Do not store huge logs, dependency dumps, generated files, or full source files.
-- Keep each memory focused; split large notes before calling `upsert`.
-- Treat numeric memory IDs as local handles. Relative paths are the durable identity.
-- Use returned search text directly as context; do not ask Augment to summarize.
-- Default to upserting when a turn did real work; only skip pure Q&A, read-only
-  inspection, or trivial mechanical ops. When unsure, upsert.
-- Do not create memories for facts already obvious from the current diff, or that
-  duplicate an existing memory (update that one instead).
+---
+name: augment-context
+description: Use Augment MCP memories to gather and persist project context during coding sessions.
+---
+
+# Augment Context
+
+Use this skill when working in a repository with the Augment MCP server available.
+
+## Session Start
+
+1. Call `init_project`.
+2. Call `search` with the user's task summary.
+3. Read exact memories when search results identify likely governing context.
+
+## Memory Insights
+
+When the user asks for memory insights, stats, health, or an overview of what
+Augment knows, call `memory_insights` (and `memory_graph` when they want to see
+how memories connect). In hosts that support MCP Apps these render interactive
+dashboard snippets; elsewhere they return a text summary — either way, relay the
+findings rather than re-deriving them from raw memories.
+
+## Before Code Changes
+
+1. Search for the file, component, command, error, or behavior being touched.
+2. If the work depends on a prior decision, read and follow the relevant `SPEC`
+   or `ARCH` memory.
+3. If no relevant memory exists but the task creates a durable requirement or
+   decision, create one before implementation.
+
+## Memory Triggers
+
+Call `upsert` whenever one of these durable events happens:
+
+- A requirement, API contract, data model, or tool contract is clarified:
+  use `SPEC`.
+- An implementation approach, tradeoff, transport choice, persistence model, or
+  architecture decision is made: use `ARCH`.
+- A bug, risk, failing behavior, or blocker is discovered: use `ISSUE`.
+- Follow-up work is intentionally deferred: use `TODO`.
+- A meaningful implementation milestone is completed: use `WORK`.
+- A test scenario, regression case, or verification rule is learned: use `SPEC`
+  or `WORK`, whichever is more durable.
+
+## Links
+
+After creating or updating a memory:
+
+1. Use `link` when a memory implements, depends on, blocks, parents, or relates
+   to another memory.
+2. Prefer linking new `WORK` notes to the `SPEC`, `ARCH`, `ISSUE`, or `TODO`
+   they address.
+
+## Session Finish
+
+For almost every session that did real work (skip only pure Q&A, read-only
+inspection, or trivial mechanical ops like 'commit & push'):
+
+1. Upsert a concise `WORK` memory with what changed, key files, and verification.
+2. Upsert or update `TODO` memories for known remaining work.
+3. Link the final `WORK` memory to the relevant planning/decision memories.
+
+## Guardrails
+
+- Do not store secrets, credentials, tokens, or private keys.
+- Do not store huge logs, dependency dumps, generated files, or full source files.
+- Keep each memory focused; split large notes before calling `upsert`.
+- Treat numeric memory IDs as local handles. Relative paths are the durable identity.
+- Use returned search text directly as context; do not ask Augment to summarize.
+- Default to upserting when a turn did real work; only skip pure Q&A, read-only
+  inspection, or trivial mechanical ops. When unsure, upsert.
+- Do not create memories for facts already obvious from the current diff, or that
+  duplicate an existing memory (update that one instead).

package/integrations/claude/skills/augment-decoction/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: augment-decoction
+description: Distill recurring cross-project memory into generic SPEC/ARCH records and optionally remove fully subsumed originals. Use when the user asks to "decoct", "glean", generalize, or clean up repeated memories across projects.
+---
+
+# Augment Decoction
+
+Decoction extracts durable, project-independent knowledge from recurring
+memories. It is separate from sleep: sleep consolidates settled work within one
+project, while decoction finds patterns across projects and writes them under
+`.generic/`.
+
+1. Call `decoction_glean` with `action: "discover"`. If no cluster spans at
+   least four distinct projects, report that and stop.
+2. Pick a cluster and `read` every source. Synthesize one generic record:
+   - use SPEC for a reusable contract or rule;
+   - use ARCH for a reusable decision or tradeoff;
+   - retain only claims supported across the projects;
+   - put every source used in `derived_from`.
+3. Suggest source removal only when the generic preserves the original's entire
+   durable content. Do not suggest a source that also contains project-specific
+   facts, history, caveats, or unresolved work.
+4. Call `decoction_glean` with `action: "write"`, the complete draft, and the
+   reasoned `suggested_removals`. For an existing generic, read it fresh and
+   pass both of its expected hashes.
+5. Report the generic path and any warnings. Warnings are advisory and do not
+   block the write.
+6. Show each suggested cleanup path and reason verbatim. Ask for explicit user
+   approval of the exact paths; never infer approval from approval of the
+   generic itself.
+7. Only after approval, call `decoction_cleanup` with the generic path and the
+   approved source paths. Report every deletion and any failure.
+
+Cleanup hard-deletes the selected originals after retargeting inbound links to
+the generic. It has no journal or rollback. The user may approve a subset or
+decline cleanup entirely.

package/integrations/claude/skills/augment-dream/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: augment-dream
+description: Explore globally recalled Augment memories and propose speculative memories or links for explicit user approval. Use when the user asks to "dream" over memory, imagine hypotheses, or surface hidden connections across the current, generic, or foreign projects.
+---
+
+# Augment Dream
+
+Dreams are hypotheses, not established facts. Discover and draft freely, but
+never mutate the corpus before the user explicitly approves a named proposal.
+Use a real project as the active project; `.generic` is inspiration or a link
+target only.
+
+1. Call `search` separately for each exploratory query, always passing the
+   active `project_name` and the singular `query` argument. Use normal global
+   results as ranked: the current project receives its normal priority, while
+   generic and foreign memories remain eligible.
+   Do not reserve a generic quota or add a generic fallback.
+2. Call `read` with each useful result's numeric memory id, and retain its
+   returned relative path for provenance. Imagine 1-5 coherent candidates:
+   - dream memory: a new record in the active project, with `derived_from`
+     equal to the exact inspiration paths;
+   - dream link: a link from an active-project memory to any current, generic,
+     or foreign memory.
+   Generic-only and foreign-only inspiration are valid.
+3. Call `dream_propose` for each worthwhile candidate. State the speculation
+   plainly in the content and rationale; do not present it as settled truth.
+4. Show each proposal to the user. Only after explicit approval call
+   `dream_apply` with its filename. Call `dream_reject` when the user rejects
+   it. If approval is unclear, leave the proposal pending.
+5. Report the applied speculative memory or link and its `dream:` commit.
+
+Keep evidence and conjecture distinguishable. Do not invent supporting source
+paths, and do not rewrite a foreign memory: foreign projects are inspiration
+and link targets only.

package/integrations/claude/skills/augment-dream/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Augment Dream"
+  short_description: "Propose speculative memory connections"
+  default_prompt: "Use $augment-dream to explore memory and propose speculative memories or links for my approval."

package/integrations/claude/skills/augment-sleep/SKILL.md

@@ -1,26 +1,26 @@
----
-name: augment-sleep
-description: Consolidate settled WORK memories into durable SPEC/ARCH records via user-approved sleep proposals. Use when the user asks to "sleep", consolidate, or distill project memory.
----
-
-# Augment Sleep
-
-Sleep folds related, settled WORK memories into one durable SPEC or ARCH
-record. You draft; the user approves; `sleep_apply` writes. Never skip the
-approval step.
-
-1. Call `sleep_candidates` (current project unless the user names one).
-   If no clusters, report that and stop.
-2. For each cluster (or the one the user picks): `read` every member, then
-   draft ONE consolidated record — SPEC if a stable contract emerged, ARCH if
-   a decision stuck. The draft must state every fact worth keeping from the
-   sources; sources will be archived (down-weighted, never deleted).
-3. Call `sleep_propose` with the draft (kind, name, content,
-   derived_from = the cluster's relative paths). Tell the user where the
-   proposal file lives — they may edit it directly before approving.
-4. Show the user the draft and ask for approval. On an explicit yes, call
-   `sleep_apply` with the proposal filename. On no, call `sleep_reject`.
-5. Report what was consolidated, what was archived, and the git commit.
-
-Constraints: one project per pass; never invent facts not present in the
-sources; if a cluster mixes unrelated work, propose only the coherent subset.
+---
+name: augment-sleep
+description: Consolidate settled WORK memories into durable SPEC/ARCH records via user-approved sleep proposals. Use when the user asks to "sleep", consolidate, or distill project memory.
+---
+
+# Augment Sleep
+
+Sleep folds related, settled WORK memories into one durable SPEC or ARCH
+record. You draft; the user approves; `sleep_apply` writes. Never skip the
+approval step.
+
+1. Call `sleep_candidates` (current project unless the user names one).
+   If no clusters, report that and stop.
+2. For each cluster (or the one the user picks): `read` every member, then
+   draft ONE consolidated record — SPEC if a stable contract emerged, ARCH if
+   a decision stuck. The draft must state every fact worth keeping from the
+   sources; sources will be archived (down-weighted, never deleted).
+3. Call `sleep_propose` with the draft (kind, name, content,
+   derived_from = the cluster's relative paths). Tell the user where the
+   proposal file lives — they may edit it directly before approving.
+4. Show the user the draft and ask for approval. On an explicit yes, call
+   `sleep_apply` with the proposal filename. On no, call `sleep_reject`.
+5. Report what was consolidated, what was archived, and the git commit.
+
+Constraints: one project per pass; never invent facts not present in the
+sources; if a cluster mixes unrelated work, propose only the coherent subset.

package/integrations/codex/SKILL.md

@@ -1,74 +1,107 @@
----
-name: augment-context
-description: Use Augment MCP memories to gather and persist project context during coding sessions.
----
-
-# Augment Context
-
-Use this skill when working in a repository with the Augment MCP server available.
-
-## Session Start
-
-1. Call `init_project`.
-2. Call `search` with the user's task summary.
-3. Read exact memories when search results identify likely governing context.
-
-## Memory Insights
-
-When the user asks for memory insights, stats, health, or an overview of what
-Augment knows, call `memory_insights` (and `memory_graph` when they want to see
-how memories connect). In hosts that support MCP Apps these render interactive
-dashboard snippets; elsewhere they return a text summary — either way, relay the
-findings rather than re-deriving them from raw memories.
-
-## Before Code Changes
-
-1. Search for the file, component, command, error, or behavior being touched.
-2. If the work depends on a prior decision, read and follow the relevant `SPEC`
-   or `ARCH` memory.
-3. If no relevant memory exists but the task creates a durable requirement or
-   decision, create one before implementation.
-
-## Memory Triggers
-
-Call `upsert` whenever one of these durable events happens:
-
-- A requirement, API contract, data model, or tool contract is clarified:
-  use `SPEC`.
-- An implementation approach, tradeoff, transport choice, persistence model, or
-  architecture decision is made: use `ARCH`.
-- A bug, risk, failing behavior, or blocker is discovered: use `ISSUE`.
-- Follow-up work is intentionally deferred: use `TODO`.
-- A meaningful implementation milestone is completed: use `WORK`.
-- A test scenario, regression case, or verification rule is learned: use `SPEC`
-  or `WORK`, whichever is more durable.
-
-## Links
-
-After creating or updating a memory:
-
-1. Use `link` when a memory implements, depends on, blocks, parents, or relates
-   to another memory.
-2. Prefer linking new `WORK` notes to the `SPEC`, `ARCH`, `ISSUE`, or `TODO`
-   they address.
-
-## Session Finish
-
-For almost every session that did real work (skip only pure Q&A, read-only
-inspection, or trivial mechanical ops like 'commit & push'):
-
-1. Upsert a concise `WORK` memory with what changed, key files, and verification.
-2. Upsert or update `TODO` memories for known remaining work.
-3. Link the final `WORK` memory to the relevant planning/decision memories.
-
-## Guardrails
-
-- Do not store secrets, credentials, tokens, or private keys.
-- Do not store huge logs, dependency dumps, generated files, or full source files.
-- Keep each memory focused; split large notes before calling `upsert`.
-- Treat numeric memory IDs as local handles. Relative paths are the durable identity.
-- Use returned search text directly as context; do not ask Augment to summarize.
-- Default to upserting when a turn did real work; only skip pure Q&A, read-only
-  inspection, or trivial mechanical ops. When unsure, upsert.
-- Do not create memories for facts already obvious from the current diff, or that
-  duplicate an existing memory (update that one instead).
+---
+name: augment-context
+description: Use Augment MCP memories to gather and persist project context during coding sessions.
+---
+
+# Augment Context
+
+Use this skill when working in a repository with the Augment MCP server available.
+
+## Session Start
+
+1. Call `init_project`.
+2. Call `search` with the user's task summary.
+3. Read exact memories when search results identify likely governing context.
+
+## Memory Insights
+
+When the user asks for memory insights, stats, health, or an overview of what
+Augment knows, call `memory_insights` (and `memory_graph` when they want to see
+how memories connect). In hosts that support MCP Apps these render interactive
+dashboard snippets; elsewhere they return a text summary — either way, relay the
+findings rather than re-deriving them from raw memories.
+
+## Before Code Changes
+
+1. Search for the file, component, command, error, or behavior being touched.
+2. If the work depends on a prior decision, read and follow the relevant `SPEC`
+   or `ARCH` memory.
+3. If no relevant memory exists but the task creates a durable requirement or
+   decision, create one before implementation.
+
+## Memory Triggers
+
+Call `upsert` whenever one of these durable events happens:
+
+- A requirement, API contract, data model, or tool contract is clarified:
+  use `SPEC`.
+- An implementation approach, tradeoff, transport choice, persistence model, or
+  architecture decision is made: use `ARCH`.
+- A bug, risk, failing behavior, or blocker is discovered: use `ISSUE`.
+- Follow-up work is intentionally deferred: use `TODO`.
+- A meaningful implementation milestone is completed: use `WORK`.
+- A test scenario, regression case, or verification rule is learned: use `SPEC`
+  or `WORK`, whichever is more durable.
+
+## Links
+
+After creating or updating a memory:
+
+1. Use `link` when a memory implements, depends on, blocks, parents, or relates
+   to another memory.
+2. Prefer linking new `WORK` notes to the `SPEC`, `ARCH`, `ISSUE`, or `TODO`
+   they address.
+
+## Decoction
+
+When the user asks to decoct, glean, or generalize cross-project memory:
+
+1. Call `decoction_glean` with `action: "discover"`, then read every source in
+   the selected cluster.
+2. Draft one reusable SPEC or ARCH under `.generic/`, keeping only claims
+   supported across the projects and listing every source in `derived_from`.
+3. Suggest removal only for originals whose entire durable content the generic
+   preserves. Call `decoction_glean` with `action: "write"`; report advisory
+   warnings without treating them as write failures. When updating an existing
+   generic, read it fresh and pass both expected hashes.
+4. Show the exact suggested paths and reasons. Call `decoction_cleanup` only
+   after explicit approval of those paths; the hard deletes have no rollback.
+
+Decoction is separate from sleep: sleep consolidates settled work inside one
+project, while decoction extracts reusable knowledge across projects.
+
+## Dreaming
+
+When the user asks to dream over memory or surface speculative connections:
+
+1. Search globally with the current project context, then read the relevant
+   current, generic, and foreign memories.
+2. Call `dream_propose` for each candidate memory or link. Dream memories land
+   in the current real project (`.generic` is never active); dream links start
+   there but may target another project. State what evidence inspired the idea
+   and what remains unverified.
+3. Present each editable proposal. Call `dream_apply` only after explicit user
+   approval; otherwise call `dream_reject`.
+
+Never present a dream as established fact.
+
+## Session Finish
+
+For almost every session that did real work (skip only pure Q&A, read-only
+inspection, or trivial mechanical ops like 'commit & push'):
+
+1. Upsert a concise `WORK` memory with what changed, key files, and verification.
+2. Upsert or update `TODO` memories for known remaining work.
+3. Link the final `WORK` memory to the relevant planning/decision memories.
+
+## Guardrails
+
+- Do not store secrets, credentials, tokens, or private keys.
+- Do not store huge logs, dependency dumps, generated files, or full source files.
+- Keep each memory focused; split large notes before calling `upsert`.
+- Treat numeric memory IDs as local handles. Relative paths are the durable identity.
+- Use returned search text directly as context; do not ask Augment to summarize.
+- Default to upserting when a turn did real work; only skip pure Q&A, read-only
+  inspection, or trivial mechanical ops. When unsure, upsert.
+- Do not create memories for facts already obvious from the current diff, or that
+  duplicate an existing memory (update that one instead).

package/integrations/examples/claude-mcp-config.json

@@ -1,17 +1,17 @@
-{
-  "mcpServers": {
-    "augment": {
-      "command": "npm",
-      "args": [
-        "exec",
-        "--prefix",
-        "C:\\Users\\you\\.augment\\npm-exec",
-        "--",
-        "augment-mcp"
-      ],
-      "env": {
-        "AUGMENT_MEMORY_ROOT": "C:\\Users\\you\\Dropbox\\augment-memories"
-      }
-    }
-  }
-}
+{
+  "mcpServers": {
+    "augment": {
+      "command": "npm",
+      "args": [
+        "exec",
+        "--prefix",
+        "C:\\Users\\you\\.augment\\npm-exec",
+        "--",
+        "augment-mcp"
+      ],
+      "env": {
+        "AUGMENT_MEMORY_ROOT": "C:\\Users\\you\\Dropbox\\augment-memories"
+      }
+    }
+  }
+}

package/integrations/examples/codex-mcp-config.json

@@ -1,17 +1,17 @@
-{
-  "mcpServers": {
-    "augment": {
-      "command": "npm",
-      "args": [
-        "exec",
-        "--prefix",
-        "C:\\Users\\you\\.augment\\npm-exec",
-        "--",
-        "augment-mcp"
-      ],
-      "env": {
-        "AUGMENT_MEMORY_ROOT": "C:\\Users\\you\\Dropbox\\augment-memories"
-      }
-    }
-  }
-}
+{
+  "mcpServers": {
+    "augment": {
+      "command": "npm",
+      "args": [
+        "exec",
+        "--prefix",
+        "C:\\Users\\you\\.augment\\npm-exec",
+        "--",
+        "augment-mcp"
+      ],
+      "env": {
+        "AUGMENT_MEMORY_ROOT": "C:\\Users\\you\\Dropbox\\augment-memories"
+      }
+    }
+  }
+}

package/integrations/examples/grok-mcp-config.toml

@@ -0,0 +1,18 @@
+# Example Grok Build MCP config fragment.
+# Paste into ~/.grok/config.toml (user) or .grok/config.toml (project),
+# or run: npx -y @fingerskier/augment install grok --scope user --memory-root "..."
+
+[mcp_servers.augment]
+command = "npm"
+args = [
+    "exec",
+    "--prefix",
+    "C:\\Users\\you\\.augment\\npm-exec",
+    "--",
+    "augment-mcp",
+]
+enabled = true
+startup_timeout_sec = 60
+
+[mcp_servers.augment.env]
+AUGMENT_MEMORY_ROOT = "C:\\Users\\you\\Dropbox\\augment-memories"

package/integrations/grok/AGENTS.md

@@ -0,0 +1,61 @@
+# Augment Memory Workflow
+
+When the Augment MCP server is configured, use it as the local project memory.
+
+## Session Start
+
+1. Call `init_project` (via the `augment` MCP tools).
+2. Call `search` with the user's task summary.
+3. Read exact memories when search results identify likely governing context.
+
+## Before Code Changes
+
+1. Search for the file, component, command, error, or behavior being touched.
+2. If the work depends on a prior decision, read and follow the relevant `SPEC`
+   or `ARCH` memory.
+3. If no relevant memory exists but the task creates a durable requirement or
+   decision, create one before implementation.
+
+## Memory Triggers
+
+Call `upsert` whenever one of these durable events happens:
+
+- A requirement, API contract, data model, or tool contract is clarified:
+  use `SPEC`.
+- An implementation approach, tradeoff, transport choice, persistence model, or
+  architecture decision is made: use `ARCH`.
+- A bug, risk, failing behavior, or blocker is discovered: use `ISSUE`.
+- Follow-up work is intentionally deferred: use `TODO`.
+- A meaningful implementation milestone is completed: use `WORK`.
+- A test scenario, regression case, or verification rule is learned: use `SPEC`
+  or `WORK`, whichever is more durable.
+
+## Links
+
+After creating or updating a memory:
+
+1. Use `link` when a memory implements, depends on, blocks, parents, or relates
+   to another memory.
+2. Prefer linking new `WORK` notes to the `SPEC`, `ARCH`, `ISSUE`, or `TODO`
+   they address.
+
+## Session Finish
+
+For almost every session that did real work (skip only pure Q&A, read-only
+inspection, or trivial mechanical ops like 'commit & push'):
+
+1. Upsert a concise `WORK` memory with what changed, key files, and verification.
+2. Upsert or update `TODO` memories for known remaining work.
+3. Link the final `WORK` memory to the relevant planning/decision memories.
+
+## Guardrails
+
+- Do not store secrets, credentials, tokens, or private keys.
+- Do not store huge logs, dependency dumps, generated files, or full source files.
+- Keep each memory focused; split large notes before calling `upsert`.
+- Treat numeric memory IDs as local handles. Relative paths are the durable identity.
+- Use returned search text directly as context; do not ask Augment to summarize.
+- Default to upserting when a turn did real work; only skip pure Q&A, read-only
+  inspection, or trivial mechanical ops. When unsure, upsert.
+- Do not create memories for facts already obvious from the current diff, or that
+  duplicate an existing memory (update that one instead).