ric/omnimem

Watch

Fork 0

reindex() docstring lists three namespaces but handles four (preference is undocumented) #29

New issue

Closed

opened 2026-09-08 13:28:59 +00:00 by ric · 1 comment

ric commented

2026-09-08 13:28:59 +00:00

Owner

Observed on: 6.7.0

Problem

The reindex() tool docstring says:

'episodic', 'project', or 'knowledge'. If omitted, reindexes all three.

It actually handles four namespaces. Calling reindex() with no argument returned:

"reindexed": [
  {"namespace": "episodic",   "removed_phantoms": 145},
  {"namespace": "project",    "removed_phantoms": 53},
  {"namespace": "knowledge",  "removed_phantoms": 530},
  {"namespace": "preference", "removed_phantoms": 34}
]

preference was reindexed and 34 phantoms cleared, despite not being listed as a valid value or counted in "all three".

Why it matters

The behaviour is right; the docs are wrong, and in the direction that causes work. Anyone reading the docstring would conclude preference indexes need a separate path and go hunting for one that doesn't exist. It also undercounts what the call does, which matters because this is a drop-and-recreate on a live index.

The description is also what an agent sees when deciding how to call the tool. An LLM reading "or 'knowledge'" as the enum won't try namespace='preference', and won't know the unscoped call already covered it.

Fix

Update the docstring to list all four namespaces and say "all four". Worth a grep for the same three-namespace assumption elsewhere in tool descriptions and docs — health returns five indexes including skill, so it's worth confirming whether skill is deliberately excluded from reindex or just missed.

**Observed on:** 6.7.0 ## Problem The `reindex()` tool docstring says: > `'episodic', 'project', or 'knowledge'. If omitted, reindexes all three.` It actually handles four namespaces. Calling `reindex()` with no argument returned: ```json "reindexed": [ {"namespace": "episodic", "removed_phantoms": 145}, {"namespace": "project", "removed_phantoms": 53}, {"namespace": "knowledge", "removed_phantoms": 530}, {"namespace": "preference", "removed_phantoms": 34} ] ``` `preference` was reindexed and 34 phantoms cleared, despite not being listed as a valid value or counted in "all three". ## Why it matters The behaviour is right; the docs are wrong, and in the direction that causes work. Anyone reading the docstring would conclude preference indexes need a separate path and go hunting for one that doesn't exist. It also undercounts what the call does, which matters because this is a drop-and-recreate on a live index. The description is also what an agent sees when deciding how to call the tool. An LLM reading "or 'knowledge'" as the enum won't try `namespace='preference'`, and won't know the unscoped call already covered it. ## Fix Update the docstring to list all four namespaces and say "all four". Worth a grep for the same three-namespace assumption elsewhere in tool descriptions and docs — `health` returns five indexes including `skill`, so it's worth confirming whether `skill` is deliberately excluded from reindex or just missed.

ric referenced this issue from a commit

2026-09-08 14:20:27 +00:00

fix: relevance floors for recall and find_skills, phantom guard (#28, #29, #30, #31)

ric commented

2026-09-08 15:11:13 +00:00

Author

Owner

Fixed in 6.7.1 (f9e8f64 on v6.7.x).

reindex() now handles five namespaces and says so. skill is included: it is a real index that health already reports on, and rebuilding it is as safe as any other because the SKILL.md body lives in the hash, not the index — so to answer your question, it was missed rather than deliberately excluded.

The grep you asked for turned up the same three-namespace assumption twice more, and one of them was not just a doc bug:

recall()'s tool description listed 'episodic', 'project', 'knowledge' and omitted preference — exactly the failure mode you described, since that description is what an agent reads when deciding how to call the tool.
memory_audit() built its unscoped prefix list by hand and skipped mem:preference: entirely, while still accepting preference as a filter value. So an unscoped audit silently under-reported the namespace — the same shape as this issue, but costing wrong numbers rather than wasted effort.

Both now derive their prefixes from the accepted set instead of repeating it, so the list and the behaviour can't drift apart again.

Fixed in 6.7.1 (`f9e8f64` on `v6.7.x`). `reindex()` now handles five namespaces and says so. `skill` is included: it is a real index that `health` already reports on, and rebuilding it is as safe as any other because the SKILL.md body lives in the hash, not the index — so to answer your question, it was missed rather than deliberately excluded. The grep you asked for turned up the same three-namespace assumption twice more, and one of them was not just a doc bug: - `recall()`'s tool description listed `'episodic', 'project', 'knowledge'` and omitted `preference` — exactly the failure mode you described, since that description is what an agent reads when deciding how to call the tool. - **`memory_audit()` built its unscoped prefix list by hand and skipped `mem:preference:` entirely**, while still accepting `preference` as a filter value. So an unscoped audit silently under-reported the namespace — the same shape as this issue, but costing wrong numbers rather than wasted effort. Both now derive their prefixes from the accepted set instead of repeating it, so the list and the behaviour can't drift apart again.

ric closed this issue

2026-09-08 15:12:32 +00:00

No labels

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

ric/omnimem#29

No description provided.

Rows
Columns