edit_note doesn't parse workspace-qualified permalinks

[phernandez]

Summary

edit_note does not parse workspace-qualified permalinks when passed as the identifier parameter. Instead of routing to the correct workspace, it treats the full qualified permalink as a literal file path in the default (personal) workspace and creates a new note there.

Reproduction

1. Create a note in an org workspace — returns permalink like basic-memory-xxx/project/path/note-name
2. Call edit_note with that full permalink as the identifier:

   edit_note(
     identifier="basic-memory-xxx/project/path/note-name",
     operation="append",
     content="new content"
   )
   

3. Expected: Edits the existing note in the org workspace
4. Actual: Creates a new note in the personal/default workspace at path basic-memory-xxx/project/path/note-name.md

Workaround

Using project_id + a short (unqualified) identifier works correctly:

edit_note(
  identifier="path/note-name",
  project_id="<uuid>",
  operation="append",
  content="new content"
)

Context

This is the same class of bug as #799 (build_context workspace routing). read_note and delete_note correctly parse workspace-qualified permalinks, but edit_note does not.

Environment

• Production (verified 2025-05-08)
• Also likely affects development

[claude]

Claude finished @phernandez's task in 8m 58s —— View job • claude/issue-810-20260508-2305 • Create PR ➔

---

Triage & Fix: edit_note workspace-qualified permalink parsing

Type: Bug (MCP tool) | Priority: High | Complexity: Simple

• Analyze issue and gather context
• Explore edit_note, read_note, delete_note implementation
• Identify the workspace-qualified permalink parsing logic
• Apply fix to edit_note
• Add/update tests
• Commit and push changes
• Add labels and provide PR link

Root Cause

edit_note used detect_project_from_memory_url_prefix with an identifier.startswith("memory://") guard. This meant workspace-qualified plain permalinks (e.g. team-slug/project/path/note — no memory:// prefix) bypassed project detection entirely, so the call was routed to the default project. For append/prepend, when the note wasn't found there, a stray note was auto-created in the wrong workspace.

read_note already uses detect_project_from_identifier_prefix (no guard) which handles both memory:// URLs and workspace-qualified plain permalinks.

Changes

src/basic_memory/mcp/tools/edit_note.py:

• Switched import from detect_project_from_memory_url_prefix → detect_project_from_identifier_prefix
• Removed the startswith("memory://") guard — detection now runs for any identifier when no explicit project/project_id is provided (matches read_note)
• Fixed auto-create fallback: use entity_identifier (workspace prefix already stripped by resolve_project_and_path) instead of the raw identifier for deriving the new note's title/directory

tests/mcp/test_tool_edit_note.py:

• Updated 3 existing tests to reference detect_project_from_identifier_prefix
• Added test_edit_note_workspace_qualified_plain_permalink_routes_correctly — mocks detect_project_from_identifier_prefix returning the correct project name (as cloud detection would in production) and verifies the edit succeeds in the right project