A note named after its project cannot be read by bare identifier (cat refuses it as the project)

[phernandez]

What happens

In project moby-dick, the source text is stored as moby-dick.txt (the layout the literary-analysis skill prescribes: <work>.txt in project <work>). The skill's documented read fails:

bm cat moby-dick.txt --lines 6684-6696 --project moby-dick --plain
Error: cat: 'moby-dick.txt' names a project, not a note

The qualified spelling bm cat moby-dick/moby-dick.txt --project moby-dick … works. Any note whose file stem equals its project's name hits this, with or without an extension.

Mechanism

resolve_project_path_route, rule 3b ("the explicit project's own permalink, spelled as the prefix"), calls split_project_permalink_prefix(candidate, (generate_permalink(explicit),)). The splitter compares generate_permalink("/".join(segments[:depth])) with the project permalink, and generate_permalink drops the file extension: generate_permalink("moby-dick.txt") → moby-dick. So the single segment moby-dick.txt is claimed as the project itself with an empty remainder, and cat refuses "names a project, not a note".

The comparison is meant to absorb case and spacing ("My Project" → "my-project"); a project name never carries a file extension, so extension stripping is an over-match here.

Expected

A bare identifier that is a note in the named project resolves to that note. A prefix claim that would leave an empty remainder should require the raw segment to spell the project permalink (no extension dropped), or fall back to note resolution when a note with that identifier exists in the explicit project.

Found during the #1398 Moby Dick qualitative run; the skill will document the qualified form as a workaround meanwhile.

🤖 Generated with Claude Code

https://claude.ai/code/session_014pmKq6bqCi6Zp6BTHuZjrp

[claude]

Claude finished @phernandez's task in 30s —— View job

---

Triage

Type: Bug — a note whose file stem equals its project's name cannot be resolved as a bare identifier; cat (and presumably other bare-identifier lookups) misclassifies it as a project reference and refuses it.

Component: MCP / CLI path resolution (resolve_project_path_route / split_project_permalink_prefix in src/basic_memory/mcp/project_context_identifiers.py), used by the cat/posix-style tools. No dedicated cloud label — this is local path-resolution logic.

Root cause (confirmed in code): split_project_permalink_prefix compares generate_permalink(segment) against the project's permalink to decide whether a leading path segment names the explicit project. generate_permalink strips file extensions (generate_permalink("moby-dick.txt") → moby-dick), so a single-segment identifier like moby-dick.txt in project moby-dick collapses to the project's own permalink with an empty remainder, and gets rejected as "names a project, not a note" instead of falling through to note resolution.

Priority: Medium — narrow but reproducible trigger condition (note file stem exactly matches its containing project's name); has a documented workaround (qualified project/path spelling), so not blocking, but it silently breaks a layout the literary-analysis skill explicitly prescribes.

Complexity: Simple–Medium — the fix is localized to the permalink-prefix comparison (e.g., require the raw segment to spell the project permalink without extension-stripping when the match would leave an empty remainder, or fall back to note resolution when a note with that identifier exists in the explicit project), plus regression tests in tests/mcp/test_project_path_routing.py / tests/cli/test_cli_posix_verbs.py.

Duplicate check: No duplicate found. #1432 is related (unqualified-name resolution) but covers a different failure mode (cross-workspace leakage vs. this project-name/file-stem collision) — not a duplicate.

Labels applied: bug.