mlx-bun 0.0.7 → 0.0.9

package/src/web/skills/memory/SKILL.md

@@ -20,26 +20,49 @@ the user's machine. Nothing about their memory leaves the device.
 
 When the answer depends on personal continuity — an explicit memory/recall
 request, or a named project, person, decision, preference, or history that is
-not explained in the current chat — consult memory before answering or asking
-the user to re-explain.
+not explained in the current chat — look it up **before** answering or asking
+the user to re-explain. Doing the lookup first, instead of answering from first
+principles, is itself the helpful move.
 
 Do **not** use memory for weather, current public facts, generic web research,
 or ordinary coding/file tasks when the current files or the web tools answer the
 question. Memory is for user-specific context, not for performing familiarity.
 
-1. **Search.** Call `memory_search` with the topic (plain phrasing is fine —
-   a name or key noun). It returns ranked articles and sample lines.
-2. **Read enough.** For short or central articles, call `memory_read`. For long
-   articles, use `memory_toc` then `memory_section` to read the relevant part.
-   The article is the answer — read it rather than reconstructing the user's
-   position from scattered fragments. Treat it as their current view.
-3. **Follow nearby context when useful.** Use `memory_links` if backlinks or
-   related concepts matter. `memory_list` gives an overview when search comes up
-   short. mlx-bun reference docs are separate from personal memory; use
-   `reference_search`, `reference_read`, and `reference_list` for those.
-   `memory_status` answers setup/schedule/location questions.
-4. **Use it silently, as a prior.** Let what you find shape your response like
-   a long-time colleague would — don't announce "I searched your memory."
+The read path is **FIND the article → READ it small → answer**. It is
+deterministic navigation — never a vector search, and there is no way to
+query/sort articles by an infobox field (the infobox is facts you *read*, via
+`memory_infobox`, not a filter).
+
+1. **FIND the article.**
+   - When the user names a specific thing, person, or project, call
+     `memory_resolve` with the name as said ("S5 IIX", "the Lumix"). It returns
+     the matched stem, title, kind, and lead — no search, no guessing.
+   - For "what do I have about X", call `memory_category` with a `category`
+     (e.g. `Lenses`), `type`, or `series`. This is membership, not search: it
+     lists the articles that are actually about X.
+2. **READ it small (the default).** Call `memory_read` to get the article's TOC
+   + lead, then `memory_section` to read just the **one** section you need. The
+   whole article is the exception — pass `force=true` only when you truly need
+   all of it. The article is the user's consolidated current position; read it
+   rather than reconstructing their view from scattered fragments.
+3. **Follow the graph / read the infobox when useful.** `memory_links` shows
+   outgoing links grouped by origin (infobox / series / see also / prose) plus
+   backlinks — use it to hop to a neighbour (e.g. from a camera's infobox
+   `mount: [[L-Mount]]` to the mount article). `memory_infobox` surfaces the
+   structured facts to read. `memory_list` is a bare overview;
+   `memory_status` answers setup/schedule/location questions. mlx-bun reference
+   docs are separate from personal memory; use `reference_search`,
+   `reference_read`, and `reference_list` for those.
+4. **`memory_search` is the LAST resort.** Only fall back to it when
+   `memory_resolve` / `memory_category` have failed across a couple of
+   phrasings. It is a plain substring scan that doesn't understand meaning.
+5. **Use it silently, as a continuation.** Let what you find shape your response
+   like a long-time colleague who already knows the state of things. Speak as a
+   continuation, never as a retrieval report: do not preface answers with "per
+   the wiki…", "according to the article…", "I checked your memory…", or
+   "welcome back, I see you're working on X". Cite an article by name only if
+   the user asks where something came from, or to distinguish "the wiki says X"
+   from "I think Y".
 
 Use memory as an invisible prior: it should narrow relevance and improve the
 answer, not become the topic of the answer. Avoid performative recall — do not
@@ -85,8 +108,8 @@ wiki, scheduling nightly synthesis). Confirm before each persistent action.
 
 ## What not to do
 
-- Don't claim a fact "from memory" that you didn't read in an article — search
-  and read first, or say you don't have it.
+- Don't claim a fact "from memory" that you didn't read in an article — find
+  and read the article first, or say you don't have it.
 - Don't write to or edit the wiki during a normal conversation; the read tools
   are read-only by design. Synthesis is a separate, deliberate step.
 - Do open the wiki or a specific article in Obsidian/Finder if the user asks to