[BUG] edit_note with memory:// URL silently creates phantom notes instead of routing to the target project

[phernandez]

Summary

edit_note with a memory:// URL identifier does not route to the target workspace/project — it treats the URL path as a relative file path and, because append creates missing notes, silently creates a phantom note in the session's default project. Found while editing a spec note during a working session (dogfood).

Repro (against cloud workspace basic-memory-7020…, note living in project specs at active/SPEC-55- Agent Memory Pipeline (Producer Framework).md)

1. read_note(identifier="memory://<ws>/basic-memory-llc/specs/active/spec-55-agent-memory-pipeline-producer-framework") → resolves and returns the note (fuzzy fallback finds it even though the project segment is wrong — read is forgiving).
2. edit_note(identifier=<same memory:// URL>, operation="append", …) on the local MCP server → "Ambiguous Identifier" error whose suggested retry list includes the plain memory:// form.
3. Retrying with exactly that suggested memory:// form → fileCreated: true — a new note is created in the session's default project with the entire URL path as its file path. Same behavior via the cloud MCP server.
4. edit_note(identifier="specs/active/spec-55-…", workspace="<ws>", project="basic-memory-llc") → Entity with external_id 'e25141e2-…' not found (resolution produced an id that then 404s, instead of a "no such note in this project" message).
5. Only edit_note(identifier="active/spec-55-…", project_id="<specs project uuid>") worked.

Problems

1. Silent wrong-project note creation (worst): append's create-if-missing combined with an unrouted memory:// identifier writes a phantom note into whatever project the session defaults to. An identifier that looks like a memory:// URL but fails to route should be an error, never a relative-path create. (Cleanup required deleting two phantom notes.)
2. The ambiguity error recommends the form that then misbehaves: step 2's suggestion list offers the plain memory:// identifier as a valid retry, which is exactly the form that creates phantoms in step 3.
3. Unhelpful failure in the legit-params path: step 4 surfaces a raw external_id … not found instead of telling the user the note doesn't exist under that project (the note was in a sibling project; a "not found in project X — did you mean project Y?" or at least a clean not-found would have redirected immediately).

Expected

• edit_note routes memory:// URLs exactly like read_note does, or rejects them with a clear error.
• append/prepend never create a note when the identifier was a routing-style URL that failed to resolve.
• Cross-project not-found errors name the project searched rather than leaking an internal external_id.

[claude]

Claude finished @phernandez's task in 22m 31s —— View job

---

Summary

Root-caused and fixed both problems in the issue. edit_note was falling back to a silent, unsafe default whenever a memory:// URL failed to route to the project/workspace it named, and a separate cross-project match was leaking an internal error.

Todo list:

• Gather context, read issue body
• Read edit_note, read_note tools and shared identifier-resolution code
• Root-cause the phantom-note bug in resolve_project_and_path()
• Investigate cross-project not-found error message (external_id leak)
• Implement fix for both problems
• Add regression tests
• Run lint/typecheck/tests — blocked, see note below
• Push branch + provide PR link — blocked, see note below

Root cause

1. Phantom note creation (the "worst" problem): resolve_project_and_path() (src/basic_memory/mcp/project_context.py) tries the leading path segment of a memory:// URL as a project route. When that lookup 404s ("project not found"), it silently fell through and returned the raw, unstripped identifier path scoped to the active/default project. Combined with append/prepend's auto-create, edit_note then wrote a brand-new note using the bogus workspace/project segment as part of its file path — exactly the phantom-note behavior reported.
2. Leaked internal error on cross-project match: the shared link resolver has a deliberate fallback that, when a plain identifier isn't found in the active project, tries the identifier's leading segment as a different project's name. edit_note's resolve_entity only kept the resolved external_id, discarding which project it actually belonged to, so the follow-up patch_entity call — scoped to the active project — 404'd with a raw Entity with external_id '...' not found instead of a clean message.

Fix

• resolve_project_and_path() now returns an extra project_prefix_unresolved flag, set exactly when this silent fallback would fire. edit_note checks it immediately and returns a clear # Edit Failed - Unresolved Project Route error instead of falling back — so append/prepend can never auto-create a phantom note from a routing-style URL that failed to resolve. (Read-oriented tools are unaffected — they ignore the flag and keep their existing forgiving fallback, since that behavior is desired for reads.)
• Added KnowledgeClient.resolve_entity_response(), which preserves project_external_id from the resolve response. edit_note now compares it against the active project and, on a mismatch, returns # Edit Failed - Note Not Found In This Project naming the actual project (with a working retry using project= or project_id=) instead of leaking a raw entity external_id.
• Added regression tests: two in tests/mcp/test_tool_edit_note.py covering the phantom-note case (text + JSON modes) and one covering the cross-project-match case (confirms the sibling note is untouched and no external_id leaks into the message), plus a focused unit test for the new project_prefix_unresolved flag in tests/mcp/test_project_context.py.

Verification blocked

This sandbox's permission mode requires interactive approval for just/uv run/any code-execution command, which isn't available in this automated run — so I could not execute just fast-check, just fast-test, or the test suite. I did a careful manual line-by-line re-review of every diff (including tracing all call sites of the changed resolve_project_and_path return signature across 7 tool modules and updating every test mock accordingly), but please run just fast-check and the relevant edit_note/project_context tests before merging.

Push blocked

The commit is made locally on claude/issue-1066-20260715-1447, but pushing failed with a 403: Permission to basicmachines-co/basic-memory.git denied to github-actions[bot]. This looks like a repo/Action permissions issue unrelated to the code change — the bot's token doesn't have write access to this repo. Someone with push access will need to fetch this branch from the local checkout or re-run with elevated permissions; I can't push it myself.