[BUG] write_note lowercases note_type while type matching stays case-sensitive, splitting one logical type into two populations

[cabras-co]

Bug Description

write_note(note_type="Task") stores type: task (lowercased) in the note's frontmatter, but type matching in schema_validate and search_notes (note_types=[...]) is case-sensitive. Notes whose frontmatter says type: Task (hand-written or migrated) and notes created through write_note end up as two separate populations that no single query covers, so type-wide validation silently reports only partial results.

Steps To Reproduce

1. Install Basic Memory 0.22.1 and set up a local project.
2. Create a schema note for entity Task (schema/Task.md).
3. Create note A by hand with frontmatter type: Task.
4. Create note B via the MCP tool write_note(title=..., note_type="Task", ...): its stored frontmatter reads type: task.
5. Run schema_validate(note_type="Task"), then schema_validate(note_type="task").

Expected Behavior

One logical type is one population: either write_note preserves the capitalization it was given, or type matching is case-insensitive across schema_validate / search_notes / metadata filters. Either way, a single call validates all notes of the type.

Actual Behavior

schema_validate(note_type="Task") validates only note A; schema_validate(note_type="task") validates only note B. Neither call reports the other population, and there is no warning that a differently-capitalized sibling type exists.

Environment

• OS: Windows 11 Home (10.0.26200)
• Python version: 3.14.6
• Basic Memory version: 0.22.1
• Installation method: uv tool
• Claude Desktop version: n/a (MCP tools called from Claude Code CLI)

Additional Context

Hit on 2026-08-03 while batch-migrating 25 task notes into a project that already had 8 hand-migrated notes with type: Task: validating "all tasks" required two separate calls with different capitalizations, and it is easy to believe everything was validated when only half was visible.

Possible Solution

Normalize type on write AND compare case-insensitively on read, or preserve the given capitalization end to end. Consistency in either direction fixes the split; the current mix (normalize on write, exact-match on read) is what creates the two populations.

[ebarkhordar]

Reproduced on current main (d1d6f273), so this is not something 0.22.1 has since grown out of. Below is where the two halves diverge, plus one correction to the search_notes part of your report and one place where the fix you are asking for already exists in the same file.

Write side normalizes, and with more than lowercase.

schemas/base.py:240 declares note_type: NoteType, and NoteType at :163 is Annotated[str, BeforeValidator(to_snake_case), ...]. to_snake_case (:54) also turns spaces, hyphens, dots and camelCase boundaries into underscores. Building the real schema object:

Entity(note_type='Task'     ).note_type -> 'task'
Entity(note_type='Task Item').note_type -> 'task_item'
Entity(note_type='TaskItem' ).note_type -> 'task_item'
Entity(note_type='task-item').note_type -> 'task_item'

So the split is wider than capitalization. Three different spellings collapse onto one stored value, and none of them is retrievable by the string the caller passed.

Read side does not normalize at all.

schema_router.py:140 types the parameter note_type: str | None = Query(...), plain str rather than NoteType, so nothing runs to_snake_case on the way in. The batch branch at :198 then calls _find_by_note_type, which is a raw equality at :460:

query = entity_repository.select().where(Entity.note_type == note_type)

Against a real SQLite database holding your two rows (one hand-written Task, one written through write_note and therefore stored as task):

Entity.note_type == 'Task'      -> 1 row: ['Task']
Entity.note_type == 'task'      -> 1 row: ['task']
Entity.note_type == 'Task Item' -> 0 rows

That is your two populations, and the third line is the same defect for a type nobody can reach from either spelling.

The same router already solves this, one branch over.

_schema_covered_note_types at :400 returns dict[target_type, list[stored_note_type]], and its docstring states the problem outright:

Stored note types are snake_case while schema authors may write "Person" or "person", so both sides are compared through generate_permalink normalization

:223 then iterates every stored spelling for a target. So schema_validate() with no arguments covers both of your populations today; only schema_validate(note_type="Task") misses. That normalization arrived in #1060, which was scoped to the no-argument path, so the note_type= branch at :198 was simply never in its blast radius. Whatever shape you prefer, the precedent for it is 60 lines above the line that needs it.

Correction on search_notes: it is no longer case-sensitive, but it uses a different normalizer.

search.py:1002 has lowercased since 63e4bcdf ("Lowercase note_types values at filter time so Chapter matches stored chapter", 2026-03-05), so the casing half of your report is already fixed there. The residual is that .lower() and to_snake_case are not the same function:

given          write stores    search_notes looks for    match
'Task'         'task'          'task'                    yes
'Task Item'    'task_item'     'task item'               no
'TaskItem'     'task_item'     'taskitem'                no
'task-item'    'task_item'     'task-item'               no

Single-word types work; anything with a space, hyphen or camelCase boundary still splits, silently, the same way you describe.

Verification detail, so you can weigh it: HEAD d1d6f273, Python 3.12, clean container. The write side ran through the real schemas.base.Entity; the read side ran the :460 filter expression against the real models.knowledge.Entity mapper on real SQLite. I did not stand up the full API server or the MCP layer, so I have exercised the query and the validator rather than an end-to-end schema_validate call.