@cerefox/memory 0.9.3 → 0.9.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/AGENT_GUIDE.md CHANGED
@@ -229,6 +229,36 @@ Cheap and idempotent. Call it any time you're uncertain about a convention (link
229
229
 
230
230
  ---
231
231
 
232
+ ## Choosing a retrieval tool: `cerefox_search` vs `cerefox_metadata_search`
233
+
234
+ These two tools have **different contracts**. Picking the wrong one is the most common retrieval mistake.
235
+
236
+ | Reach for `cerefox_search` when… | Reach for `cerefox_metadata_search` when… |
237
+ |---|---|
238
+ | You want the *most relevant* docs for a topic or question | You want *every* doc matching exact criteria |
239
+ | The query is fuzzy or conceptual (it blends full-text + semantic) | You're filtering by structured metadata (`type`/`status`/tags), project, or date |
240
+ | Top-N ranked hits are enough to answer | You need a complete, exhaustive set (e.g. an inventory or a catch-up) |
241
+
242
+ - **`cerefox_search` is relevance-ranked top-N.** It returns the best `match_count` matches (**default 5** — raise it via `match_count`). It is **not** an enumeration tool: if more docs match than `match_count`, the rest sit silently below the cutoff — and the one you most want (e.g. the *newest*) may be exactly the one dropped.
243
+ - **`cerefox_metadata_search` is exhaustive enumeration by criteria.** No text query. Filters by `metadata_filter` (plus `project_name`, `updated_since` / `created_since`). It returns **metadata only by default** (`include_content=false`) — ids + titles + tags, which is cheap — so raise `limit` (**default 10**) freely to get the whole set. Discover available keys with `cerefox_list_metadata_keys`.
244
+
245
+ ### Examples
246
+
247
+ - *"Find our OAuth design notes"* (relevance) → `cerefox_search(query="OAuth design", match_count=5)`
248
+ - *"List every decision-log doc"* (enumeration) → `cerefox_metadata_search(metadata_filter={"type":"decision-log"}, limit=50, include_content=false)`
249
+ - *"What changed since I last looked?"* → `cerefox_metadata_search(metadata_filter={"type":"decision-log"}, updated_since="2026-05-01T00:00:00Z")`
250
+ - *"Just the ids of all active research docs"* → `cerefox_metadata_search(metadata_filter={"type":"research","status":"active"}, limit=100)`
251
+
252
+ ### Pattern: finding the newest item in a growing series
253
+
254
+ Don't lean on `cerefox_search` ranking to find "the latest X" — as the series grows, the newest item is the one most likely to fall outside the top-N window. Instead, tag exactly one doc with a pointer (e.g. `latest:"true"`) and fetch it directly:
255
+ ```
256
+ cerefox_metadata_search(metadata_filter={"type":"<your-type>", "latest":"true"})
257
+ ```
258
+ Metadata is matched as **strings**, so store the flag as the string `"true"` (not a boolean). When the current item is superseded, set the new one's flag first, then clear the old one's — so a reader never sees zero matches.
259
+
260
+ ---
261
+
232
262
  ## Key Workflows
233
263
 
234
264
  ### Search then update (ID-based -- preferred)
@@ -7184,7 +7184,7 @@ var exports_meta = {};
7184
7184
  __export(exports_meta, {
7185
7185
  PKG_VERSION: () => PKG_VERSION
7186
7186
  });
7187
- var PKG_VERSION = "0.9.3";
7187
+ var PKG_VERSION = "0.9.4";
7188
7188
  var init_meta = () => {};
7189
7189
 
7190
7190
  // ../../node_modules/.bun/tslib@2.8.1/node_modules/tslib/tslib.js