Summary
Expose the authoritative previous note path from the accepted move transaction even when the old note version was never materialized to storage.
Regression context
Basic Memory Cloud issue basicmachines-co/basic-memory-cloud#1500 and PR basicmachines-co/basic-memory-cloud#1506 need to publish a canonical note.moved activity event with previousNotePath.
The accepted move runner already captures entity.file_path as existing_file_path inside the same transaction that loads and commits the move. However, the accepted result only exposes that path through cleanup_after_write, and cleanup_after_write is intentionally absent when the old object was never materialized.
Cloud cannot recover the missing path safely with a separate pre-read: another accepted move can land between that read and the core move transaction, causing activity to report a stale source path.
Ownership
This is a Basic Memory accepted-mutation contract gap, not a Cloud routing or persistence bug. The authoritative value exists in basic_memory.indexing.accepted_note_mutation_runner._run_accepted_note_move and must be carried out of that transaction.
Suggested fix
- Add an optional previous_file_path field to the accepted write/move result contract, preferably RuntimePendingNoteMaterialization or RuntimeAcceptedNoteChange.
- In _run_accepted_note_move, set it from the transaction-local existing_file_path regardless of whether previous_file_delete is planned.
- Preserve cleanup_after_write for storage deletion only; do not overload cleanup presence as move provenance.
- Propagate the field through response replacement and queue-neutral runtime helpers without changing non-move behavior.
- Add regressions for:
- materialized move: previous_file_path and cleanup are both present;
- never-materialized move: previous_file_path is present and cleanup is absent;
- update/create: previous_file_path remains absent.
Cloud follow-up
After the Basic Memory dependency is updated, Cloud PR #1506 should consume this accepted-result field, remove its separate pre-read, and keep committed cleanup metadata only as backward-compatible deployment handling if needed.
Summary
Expose the authoritative previous note path from the accepted move transaction even when the old note version was never materialized to storage.
Regression context
Basic Memory Cloud issue basicmachines-co/basic-memory-cloud#1500 and PR basicmachines-co/basic-memory-cloud#1506 need to publish a canonical note.moved activity event with previousNotePath.
The accepted move runner already captures entity.file_path as existing_file_path inside the same transaction that loads and commits the move. However, the accepted result only exposes that path through cleanup_after_write, and cleanup_after_write is intentionally absent when the old object was never materialized.
Cloud cannot recover the missing path safely with a separate pre-read: another accepted move can land between that read and the core move transaction, causing activity to report a stale source path.
Ownership
This is a Basic Memory accepted-mutation contract gap, not a Cloud routing or persistence bug. The authoritative value exists in basic_memory.indexing.accepted_note_mutation_runner._run_accepted_note_move and must be carried out of that transaction.
Suggested fix
Cloud follow-up
After the Basic Memory dependency is updated, Cloud PR #1506 should consume this accepted-result field, remove its separate pre-read, and keep committed cleanup metadata only as backward-compatible deployment handling if needed.