@rayul/kordis 0.15.0 → 0.15.2

package/assets/memgineering-recall/SKILL.md

@@ -153,6 +153,11 @@ What you must not do is report what came back as everything the brain holds,
 which is exactly what a short answer looks like to anyone who does not read the
 line under it.
 
+When every card with a project came from ONE project and the brain holds
+others, recall says so (`scope_spread`: the project, and up to five others). If
+the user meant one of those, ask again with `--scope <that project>` — the note
+they want may be ranked just below a page full of the one the question named.
+
 ## Whether meaning was searched
 
 A hosted brain can match on meaning as well as words — the same idea in other
@@ -177,6 +182,12 @@ anything about what the user knows.
 If coverage says notes are missing entries, meaning was searched over part of
 the brain. Do not report that as a complete search.
 
+When meaning was used, each card also says what reached it — `matched`:
+`"words"`, `"meaning"`, or `"both"`. A `"meaning"` card (printed as _matched by
+meaning only_) shares no word with the question. That is right for a note in
+another language and wrong for one the model merely found nearby, so read its
+summary before you answer from it — never quote it back on the label alone.
+
 ## Two answers that are answers
 
 **Nothing matched.** Say so, and do not go read their folder yourself to
@@ -194,11 +205,14 @@ next brain, and three of them said it out loud. Reading another brain does not
 move the machine's pointer.
 
 **Cards that are not answers.** A card marked `not filled in yet` is one of the
-five `01_BASE/` files, still byte-for-byte what `init` wrote. Nobody has answered
+five `01_BASE/` files, still exactly what `init` wrote (line endings aside). Nobody has answered
 it, so it is evidence of nothing — do not quote it back as what they think. When
 every card carries that mark, recall says so above them (`--json`:
 `scaffolding: true`), and that is the moment to offer to fill them in rather
-than answer from them — see `memgineering-writing`.
+than answer from them — see `memgineering-writing`. At most two such cards come
+back per answer, plus any that is one side of a conflict, so both sides of a
+conflict always show; the rest are counted (`templates_withheld`), never
+silently dropped, and nothing anyone wrote is ever held back.
 
 The mark disappears once the user writes in the file. A filled-in base note is
 often the best answer in the brain: _who am I_, _what am I not allowed to do_,
@@ -219,8 +233,11 @@ On a hosted brain the folder counts too, as a name rather than a path: the CLI
 sends the folder's project — `owner/repo` from the git remote, or whatever
 `memgineering project` shows — and the server ranks what was asked about in
 that project first. The response says so itself: `ranked_by` gains `asked about
-in this project`, a card's reason reads `recalled 2× in this project`, and the
-footer names which project those words mean. Trust the footer over your
+in this project`, a card's reason reads `opened 1× · surfaced 2× in this project`
+(or `surfaced 2× …, never opened`), and the footer names which project those
+words mean. Only an open, or being the FIRST card of a recall, counts toward
+the order; a card merely listed further down is counted in words but earns
+nothing. Trust the footer over your
 assumption in the other cases as well — it says when this folder names no
 project (nothing was sent), and when the server does not rank by project yet
 (it was sent and ignored). A path never leaves the machine either way.

package/assets/memgineering-registry/SKILL.md

@@ -2,7 +2,7 @@
 name: memgineering-registry
 description: Use when the user wants judgment somebody else has already settled — "what do other people do about this", "is there a pattern for it", "read that judgment", "adapt that pattern to this repo", "fit it to our setup", "how do others handle X" — or when one of their own decisions should go out: "publish this decision", "share this rule", "put it on memgineering", "send it to the registry". Also when they ask whether what you read gets stored. Covers the public layer: reading somebody else's judgment into context, the transplant brief, publishing one claim out of this brain, lineage, why reading is never copying, and how author-controlled text is fenced.
 type: skill
-version: 0.20.0
+version: 0.21.0
 allowed-tools: Bash(memgineering:*)
 ---
 
@@ -215,10 +215,17 @@ another machine leaves no record here.
 
 ## What is not here
 
-Installing files, stars, follows, comments, and withdrawing a release stay in
-the `kordis` CLI for one release window. The public layer's verbs are
-`registry search`, `registry info`, `registry read`, `registry adapt` and
-`registry publish`.
+Stars, follows, comments, and withdrawing a release are still only in the
+`kordis` CLI. Everything else has moved: the public layer's verbs are
+`registry search`, `registry info`, `registry read`, `registry adapt`,
+`registry publish`, `registry pull`, `registry update`, `registry outdated`,
+`registry versions`, `registry diff` and `registry list`.
+
+Installing has its own guide — `memgineering-installing` — because which tool a
+project installs for, what a range resolves to, and what a merge refuses are a
+different subject from choosing what to read.
 
 `memgineering pull` is unrelated: it is the brain verb for a hosted brain, not
-a registry install.
+a registry install. So is `memgineering update`, which updates this CLI. Both
+have a `registry` twin that means the other thing, which is why the namespace
+exists.

package/assets/memgineering-rules/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: memgineering-rules
-description: Use when the user settles something they expect to hold next time — a colour they will not use, a step never to skip, a way things get named here — or when you want to see what already binds you in this folder. A decision does not have to be announced as a rule to be one. Triggers include "from now on", "always", "never", "don't do that again", "let's go with X from here", "we always do it this way", "what rules do I have". Covers remember --rule, rules, and what the before-edit hook shows.
+description: Use when the user settles something they expect to hold next time — a colour they will not use, a step never to skip, a way things get named here — or when you want to see what already binds you in this folder. A decision does not have to be announced as a rule to be one. Triggers include "from now on", "always", "never", "don't do that again", "let's go with X from here", "we always do it this way", "what rules do I have" — and, for moving one, "that should apply everywhere", "not just this project", "all my projects", "only in this repo from now on". Covers remember --rule, rules, rescope, and what the before-edit hook shows.
 type: skill
 allowed-tools: Bash(memgineering:*)
 ---
@@ -69,6 +69,20 @@ A hosted brain answers this too, and `--rule` writes to one land marked. The
 marking lives in the note's own frontmatter either way, so a brain that was
 pushed from a folder keeps every rule it had.
 
+**A rule saved from a chat app waits for the user.** ChatGPT, Claude.ai and
+other connectors can write notes, but not rules: a rule asked for there is
+kept as an ordinary note, and binds only once the user promotes it at a
+terminal. Promoting binds the note's own text as the chat wrote it — `--claim`
+changes the summary, not the words that bind — so they read it first with
+`memgineering open <id> --detail full` (the card alone shows only the title and
+summary, which a chat app may have rewritten), then `memgineering revise <id> --rule --claim "<what
+the note says>"`. Worded differently, it is a new rule: `memgineering remember
+"<the rule>" --rule`. A connector also cannot change or unmark an existing rule. Once
+promoted, the rule says where its words came from — `(written by the ChatGPT
+connector)` beside it in `memgineering rules` and in the before-edit hook, and
+`written_by` in `--json`. Treat it as their rule; the label says which surface
+it was first said on.
+
 **A rule also wins a tie in `recall` now.** Where an ordinary memory and a
 standing decision matched a query equally well, the decision is ranked first —
 the asymmetry being that a missed fact costs the reader some context, while a
@@ -85,12 +99,23 @@ alone earned — not that the top card is a rule, and not that it never could be
 since the engine noticing a note is decision-shaped is weaker evidence than its
 author saying it binds.
 
-One difference is worth knowing rather than discovering. The before-edit hook
-reads a brain **on this machine**, so on a machine pointed at a hosted brain it
-shows the local folder's rules, not the hosted brain's — a network call on the
-path of every file write is not a trade this makes. `memgineering rules` shows
-whichever brain the machine is pointed at; add `--local` to see what the hook
-will actually deliver.
+**Rules arrive in two budgets, not one list.** What a session is shown is the
+strongest few that hold everywhere, plus the strongest few scoped to the project
+it is standing in — ten in total, and each half gives its unused room to the
+other, so a brain with nothing scoped still fills the list. Rules scoped to a
+DIFFERENT project are not shown to an agent working here at all; they bind
+there. `memgineering rules` lists them separately under "scoped to other
+projects", which is the one place to notice a scope with a typo in it — such a
+rule binds nowhere and would otherwise appear nowhere.
+
+Before the split there was one list ranked by use, and it did not work: measured
+in a real repository, every slot went to rules about other things and a rule
+written that morning about that project's own layout ranked 49th of 54.
+
+The before-edit hook and `memgineering rules` read the same brain — the hosted
+one when this machine is pointed at it, the folder on disk otherwise — so what
+the hook will deliver is what the command shows. Add `--local` to read the
+folder on this disk specifically.
 
 ## What the user's agent actually sees
 
@@ -135,11 +160,30 @@ a long list is fewer rules, not a longer one.
 
 Two consequences worth knowing before you mark things:
 
-- **Global habits crowd out project decisions.** A rule that has been recalled
-  in other folders outranks a project rule written yesterday that nobody has
-  reached for. If a user's own working preferences fill all eight slots, a new
-  a rule written for the folder they are in may never be shown. Keep the
-  standing set small.
-- **A retired rule stops being shown.** `memgineering retire <ref>` is the way
-  out when a decision no longer holds — it stays visible in recall, ranked last
-  and labelled, but it stops binding.
+- **Global habits used to crowd out project decisions**, and the two budgets
+  are why they no longer can: a rule scoped to the project has its own room and
+  cannot lose every slot to whatever the user has been reaching for lately. It
+  still pays to keep the standing set small — ten is what a session reads.
+- **Three ways out, and they are not the same.** `memgineering revise <ref>
+--no-rule --reason "…"` says it was never a rule: it stops being shown before
+  an edit, and stays a perfectly ordinary current memory that recall returns.
+  `memgineering retire <ref>` says it no longer holds: it stops binding AND
+  drops to the bottom of recall, labelled. `memgineering expire <ref> --until
+<date>` says it held until then: it KEEPS binding and recall keeps returning
+  it, ranked below what is current and labelled from that date. Reach for the
+  first when the marking was the mistake, the second when the decision has been
+  overtaken, and the third when it was always going to run out.
+- **`memgineering rescope <ref>` changes WHERE a rule binds, not whether it
+  does.** `--scope <project>` binds it in that project alone — agents working
+  anywhere else stop being shown it. `--global` binds it everywhere, which is
+  the change hardest to notice afterwards, so it has a flag of its own rather
+  than being what happens when you leave the scope off. Nothing the note says
+  changes either way, and `memgineering undo` reverses it.
+  Ask before widening: a rule the user wrote about one repository, made global,
+  arrives in every session they open.
+- **`--no-rule` on its own asks for nothing else.** No claim, no summary — the
+  conclusion, the summary and the title come back byte for byte, which is the
+  whole reason it exists. It used to go through `revise`, which requires a
+  claim, so taking a marking back meant restating a conclusion nobody had
+  changed, from text this CLI hands back truncated. Do not restate anything;
+  `memgineering undo` reverses it.

package/assets/memgineering-setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: memgineering-setup
-description: Use when installing or configuring memgineering, when moving a brain between a machine and an account, when renaming or deleting a hosted brain, or whenever the user asks WHICH of their AI tools can see this memory. Triggers include "set up memgineering", "connect my notes", "rename my brain", "delete that brain", "does my other AI see this too", "which of my tools can read this", "will it work in the app on my phone", "no brain is linked".
+description: Use when installing or configuring memgineering, when moving a brain between a machine and an account, when renaming or deleting a hosted brain, or whenever the user asks WHICH of their AI tools can see this memory. Triggers include "set up memgineering", "connect my notes", "rename my brain", "delete that brain", "does my other AI see this too", "which of my tools can read this", "will it work in the app on my phone", "can I use this in ChatGPT", "does it work in Claude.ai", "no brain is linked".
 type: skill
 allowed-tools: Bash(memgineering:*)
 ---
@@ -12,20 +12,37 @@ allowed-tools: Bash(memgineering:*)
 Answer this from here, not from a guess. The line is capability, not brand, so
 it does not move as products come and go:
 
-|                                           |                                                                                                               |
-| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
-| **Any tool that can run a shell command** | Reads and writes the same brain. Nothing has to be built for a tool that does not exist yet.                  |
-| **Any tool that cannot**                  | **Not yet.** There is no connector. A hosted brain is reachable in principle and is not wired up in practice. |
+|                                                            |                                                                                                                                                                                         |
+| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Any tool that can run a shell command**                  | Reads and writes the same brain. Nothing has to be built for a tool that does not exist yet.                                                                                            |
+| **A chat app that takes a custom MCP connector, no shell** | Reads and writes the **hosted** brain on their account through `https://mcp.memgineering.com/mcp`, once they add that connector in the app and sign in with Google. Not a folder brain. |
+| **Neither**                                                | **Not yet.**                                                                                                                                                                            |
 
 `memgineering setup` writes its guidance into the agent tools it finds on the
 machine, and `setup --dry-run` names the ones it actually found rather than
 guessing from a list.
 
 So when someone names a tool and asks whether it remembers too, work it out from
-that line and answer **not yet, and here is what does** — not a hedge, not a
-promise. "You are signed in, so it works everywhere" is the specific wrong
-answer: the account syncs the brain between machines, it does not add a surface
-that can read it.
+those rows and answer plainly — not a hedge, not a promise:
+
+- **ChatGPT** — Settings → **Developer mode** → add an MCP server with
+  `https://mcp.memgineering.com/mcp`, then sign in with Google when it asks.
+- **Claude.ai, Claude Desktop, Cowork** — **Customize** → **Connectors** →
+  **Add custom connector** → the same URL. One connector covers all three, and
+  custom connectors are on every plan, the free one included.
+- It reaches the brain **on their account**. A brain that lives only as a folder
+  on this machine is out of its reach until it is moved up (see "Moving a brain
+  between this machine and their account").
+- Moving it up does NOT make it appear in the chat app by itself. When their
+  brain is still a folder, the answer is both steps, in order: move it up, then
+  add the connector above in their app. An answer that stops at the first step
+  leaves them with an account brain and no way in.
+- `npx memgineering-mcp` — the local, stdio server — is **registry-only**. It has
+  no memory tools; for memory from a chat app, the URL above is the way.
+
+"You are signed in here, so it works everywhere" is still the wrong answer: the
+account syncs the brain between machines, and each chat app needs the connector
+added in that app, once.
 
 ## 1. Register with the agents
 
@@ -49,6 +66,17 @@ Three things to do after running it:
    picks it up on its own when they do. There is nothing to poll and nothing
    to wait for.
 
+The link is the key to that screen, not the code: whoever holds the whole link
+can drive it. Give it only to them, never paste it anywhere else — with
+`--json`, `setup_url` is printed only when no browser opened.
+
+If they chose to upload existing notes on the screen, this machine does NOT
+upload them on its own: the next `memgineering` command shows which folder and
+which account would receive them, with the `push` that sends them. Check with
+them that the account is theirs before running it. And a machine already
+signed in to a different account is never switched by `setup --web` — the
+terminal says so; `logout` first if they really mean to switch.
+
 The screen asks everything `--agent` takes from flags — sign in, where the
 memory lives, which brain, which tools, auto-update, the session hook — with
 the recommended answer pre-selected. A person who is already signed in to
@@ -93,8 +121,16 @@ restart. (Measured: a fresh agent relayed "restart required" as fact, the user
 checked, and it was not one.)
 
 **Ask before setting policy for them.** Auto-update means the tool updates
-itself; `--hook on` means note summaries and their standing rules reach an agent
-unasked. Recommend both, but they are theirs to decide.
+itself: once a day, when a newer version exists, a global install starts
+`memgineering update` in the background and the next run uses it (a project-local
+or npx copy is never touched — it only gets the notice; nor is anything installed
+from a session hook or under CI). One install runs at a time: `memgineering
+update` run while a background install is going answers `update_in_progress`
+and installs nothing — wait a few minutes and run it again; it reports whether
+that install worked. `update_claim_stuck` means a crashed install's leftover
+could not be cleared; its hint names the folder to delete. `--hook on` means note
+summaries and their standing rules reach an agent unasked. Recommend both, but
+they are theirs to decide.
 
 **Error telemetry is theirs to decide too, and defaults to off.** With
 `--error-telemetry on`, the CLI sends an anonymous report when it ITSELF
@@ -146,6 +182,15 @@ answered, and the trust is recorded per hook CONTENT
 so an upgrade that changes a hook asks again. Somebody who is not told this
 reads the silence as an install that did not take.
 
+**An update brings the hooks along.** The first `resurface` (session start)
+after an update — or the next command anybody types — replaces memgineering's
+own hook commands with the new version's, in both Claude Code and Codex, and
+says so once. It replaces only a command memgineering itself shipped: a hook
+someone edited (an absolute path, say), a removed hook, a symlinked or
+unreadable settings file are left exactly as they are, and the last two are
+named once. When a Codex hook changed this way, Codex asks for the review
+above again at its next start — relay that, with the key.
+
 Grok is the case worth knowing, because the obvious guess is wrong: it has
 hooks, more events than either of those two, and `~/.grok/hooks/` needs no
 trust prompt — but a hook there cannot say anything to the model. Measured
@@ -441,9 +486,12 @@ as a next step rather than running it.
 
 ### What a hosted brain does that a folder does not
 
-Every verb works on either kind now, consolidation included. Two things are
+Every verb works on either kind now, consolidation included. Three things are
 only true of a hosted brain.
 
+**A chat app with no shell can reach it** — through the connector at the top of
+this file. A folder brain is reached only by tools that can run `memgineering`.
+
 **Meaning is searched, if a model is configured for it.** That is what lets an
 English question reach a Korean note. It needs `BRAIN_EMBEDDING_URL` and
 `BRAIN_EMBEDDING_MODEL` set on the server; with neither, the brain searches text
@@ -475,7 +523,7 @@ answers without changing its name and the index has to be laid down again.
 ## Turning things off
 
 ```
-memgineering setup --agent --auto-update off
+memgineering setup --agent --auto-update off   # the hook stays as this machine recorded it
 memgineering unlink            # stop reading a brain; notes untouched
 memgineering unlink --purge    # also delete the local index and undo snapshots
 ```

package/assets/memgineering-writing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: memgineering-writing
-description: Use when you learn something durable and should record it, when a conclusion you already recorded turns out to have changed, when something needs undoing or retiring, when the brain has filled up with near-duplicates that want tidying, or when the user's `01_BASE/` files are still empty and only a conversation can fill them. Triggers include "remember this", "that didn't work", "this worked instead", "that's not right anymore", "undo that", "looks good", "set up my memory", "fill in my profile", "stop reading that note", "clean up my notes", "these two say the same thing", "is this a duplicate", "move my memories over", "bring my notes from the other tool", "don't save that", "never store that". Covers remember, revise, undo, log, retire, exclude, onboard, the consolidate/propose/approve flow, carrying facts in from another store, storage boundaries, and what to say before writing.
+description: Use when you learn something durable and should record it, when a conclusion you already recorded turns out to have changed, when something needs undoing or retiring, when the brain has filled up with near-duplicates that want tidying, or when the user's `01_BASE/` files are still empty and only a conversation can fill them. Triggers include "remember this", "that didn't work", "this worked instead", "that's not right anymore", "undo that", "looks good", "set up my memory", "fill in my profile", "stop reading that note", "clean up my notes", "these two say the same thing", "is this a duplicate", "move my memories over", "bring my notes from the other tool", "don't save that", "never store that", "that's only true until <date>", "it stops being true after", "don't tell me that forever". Covers remember, revise, undo, log, retire, expire, exclude, onboard, the consolidate/propose/approve flow, carrying facts in from another store, storage boundaries, and what to say before writing.
 type: skill
 allowed-tools: Bash(memgineering:*)
 ---
@@ -23,24 +23,47 @@ reverse it. Do not ask permission for ordinary observations — write them, and
 mention it in a sentence.
 
 **A note born in a project folder carries that project as its `scope`** — the
-name comes from the git remote (`owner/repo`), or from the folder's binding
-(`memgineering project` shows it). The stamp is automatic; an explicit
-`--scope` beats it; a folder that names no project writes exactly what it
-always wrote. Two flags are worth reaching for on purpose:
+name comes from the folder's binding (`memgineering project` shows it), else the
+git remote (`owner/repo`), else — in a repository with no remote — the checkout
+folder's name. `remember` prints the scope and which of those it came from
+(`scope_via` in `--json`); when it is the folder name, say so, because that is
+the one nobody predicts. The stamp is automatic; an explicit `--scope` beats it;
+a folder that names no project writes exactly what it always wrote. Two flags
+are worth reaching for on purpose:
 
 ```
 memgineering remember "we always squash before merging" --rule --no-scope \
   --reason "they said from now on, about every repo — not this one"
 ```
 
-- `--no-scope` for anything meant to hold machine-wide, rules especially: a
-  rule stamped with one project's scope drops out of another project's
-  `recall --scope` answers.
+- `--no-scope` for a decision that genuinely holds in every project — a
+  security rule, a way of writing commits, something about the person rather
+  than the work. It is a real answer, not the safe one: use it when it is true.
 - `--scope <name>` when the note is ABOUT a project you are not standing in.
 
+**Prefer the project scope for a rule that is about one project.** `--no-scope`
+used to be the advice for rules in general, on the reasoning that a scoped rule
+drops out of other projects' answers — it does, and that is now the point. Rules
+reach a session in two budgets, one for what holds everywhere and one for the
+project in front of it, so a scoped rule is no longer competing with every other
+rule in the brain for the same few slots. Measured before the split: in a real
+repository all the slots went to rules about other things, and a rule written
+that morning about that project's own layout ranked 49th of 54 — present,
+enforced by nothing, invisible to the session it existed to stop.
+
 `--scope` and `--no-scope` together are refused — they answer the same
 question both ways.
 
+**A rule has to say what it binds, and one of the two is required.** A `--rule`
+write is refused when nothing names a scope and nothing can be derived — a
+folder that is not a repository and has no bound project. Add `--scope "<the
+project>"` or `--no-scope`, and retry; nothing was written. On the hosted API
+(`brain_remember`, or `POST /remember` directly) the same refusal applies with
+no derivation at all: send `scope`, or `"scope": "global"` for one that really
+does hold everywhere. `global` is reserved and is stored as no scope, which is
+what a machine-wide rule already looks like — so there is only ever one
+spelling of it to search for.
+
 **`--reason` on every write.** It goes in the ledger and is the only part of the
 record that still means anything six months later. Every write verb takes it:
 `remember`, `revise`, `retire`, `exclude`, `undo`. The one on `undo` matters
@@ -183,17 +206,26 @@ it>"`.
 This rewrites only the memory block in frontmatter. The prose is the user's;
 neither the command nor you should rewrite it uninvited.
 
-## Retiring versus excluding
+## Retiring versus expiring versus excluding
 
 ```
 memgineering retire <ref> --reason "the date moved"   # no longer current, still visible
+memgineering expire <ref> --until 2026-10-31 --reason "the phase ends then"  # NOT retired
 memgineering exclude path/to/note.md --reason "it has someone's phone number in it"   # stop reading it
 memgineering retract --actor "mcp:ChatGPT" --since 2026-09-01        # SHOWS what one writer / window wrote
 memgineering retract --actor "mcp:ChatGPT" --since 2026-09-01 --yes  # retires all of it, one ledger row each
 ```
 
 Retiring keeps the note in recall, ranked last and labelled. Excluding takes it
-out of the index and never touches the file. If the user says "delete", ask
+out of the index and never touches the file.
+
+**`expire` is not a retirement, and the difference only shows up later.** It
+gives a memory an end date: until then it is current, and after it recall still
+returns it — one step below what is current, labelled with the date. Reach for
+it when the memory was always going to run out ("Phase 1 lands by the end of
+October", a key that rotates, a plan with a deadline in it) rather than when a
+decision has been overtaken. Retiring such a note says something untrue about
+it; leaving it says something untrue too. If the user says "delete", ask
 which they mean.
 
 ## Tidying up a brain: detect, draft, approve
@@ -215,11 +247,30 @@ it is about without opening them. It does not carry their claims, so deciding
 which of a pair is right still means reading them: two notes can share a title
 and hold opposite conclusions, which is exactly the case a proposal exists for.
 It returns them with the evidence that caught them and the action it would
-suggest, under six rules: `declared_supersession`, a replaced note still active;
-`contradiction`, a disagreement nobody settled; `semantic_similarity`, indexed
-meaning agreeing reciprocally; `shared_context`, one scope naming the same
-thing; `similar_title`; and `kind_promotion`, a binding note filed as something
-other than a decision. Semantic detection reuses a complete, calibrated hosted
+suggest, under eight rules: `declared_supersession`, a replaced note still
+active; `contradiction`, a disagreement nobody settled; `semantic_similarity`,
+indexed meaning agreeing reciprocally; `shared_context`, one scope naming the
+same thing; `similar_title`; and three that read a note against itself, where
+its `binding` flag and its `kind` disagree. `rule_demotion` is a binding note
+the author classified as a fact, a procedure, an episode or a goal — two
+deliberate fields contradicting each other, and the marking is the one to
+doubt. `binding_unclassified` is a binding note with no kind at all, and it
+names BOTH moves rather than picking one, because the tool reads fields and not
+prose: it is either a decision nobody classified or something that was never a
+rule, and only somebody who reads it can say which. (`kind_promotion` remains
+in the vocabulary and no longer fires.)
+
+That neutrality was measured rather than chosen for balance. On a real brain,
+55 of 57 binding notes had no kind and every one was answered "promote this to
+a decision" — including the thirteen that turned out not to be rules, where
+approving the suggestion would have hardened the mistake.
+
+**The page is shared between the signals.** One rule used to take the whole
+list — 55 of 57 candidates — so the duplicate and the contradiction underneath
+got a line each. Candidates now round-robin across the rules that found
+something, and `by_rule` reports how many each found in total, which the page
+can no longer tell you. Raising `--limit` widens the page rather than returning
+more of one rule. Semantic detection reuses a complete, calibrated hosted
 vector generation and never calls a model during consolidation. Authored
 scope/entity context permits reciprocal neighbours; without it, evidence must
 form a stricter three-note semantic triangle.
@@ -308,7 +359,7 @@ so an empty one costs something every time.
 memgineering onboard
 ```
 
-Says which are still untouched and what to ask for each. Run it first rather
+Says which still have no body written and what to ask for each. Run it first rather
 than working from a script — asking somebody a question they already answered is
 its own kind of forgetting. They may also ask outright ("set up my memory", "fill in my profile"); same job.
 
@@ -353,7 +404,7 @@ always true and you have only just been told them, so dating them today is wrong
 in the one field a memory store exists to get right.
 
 **This is the ONE place you edit a brain file directly** — `01_BASE/` only, and
-only while it is still the template. After that first pass these are theirs like
+only while its body has not been written yet. After that first pass these are theirs like
 any other note.
 
 **Do not invent an answer to move on, and do not fill a file because it is
@@ -493,3 +544,12 @@ and mention it in a sentence.
   passage that says those words. See `memgineering-recall`.
 - **Store full ids, not short handles**, anywhere durable. `open` prints the
   full `id:` for exactly this.
+
+## Where a durable fact goes
+
+Durable user facts never go in this tool's own memory files — the brain is the
+store every tool they use shares. A note written into one assistant's private
+memory is invisible to every other tool the user talks to, which is the whole
+problem the brain exists to solve. Moved here from the hub when the public
+layer grew an install verb and the hub ran out of room; it is a rule about
+writing, and this is the file about writing.