You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] move_note's cross-project guard does not apply to is_directory=True, and rejects legitimate same-project moves #1607
move_note's cross-project guard is skipped entirely for directory moves, so the
same destination is refused for a file and accepted for a directory.
_detect_cross_project_move_attempt is called at move_note.py:807, after the if is_directory: branch has already returned at line 590. The separate source_project vs active_project check above the branch still applies, so it is
specifically the leading-segment heuristic that directory moves never reach.
Reproduction
Projects foundry and work both exist. From a session scoped to foundry, with a
note in it:
Rows 1 and 3 disagree about the identical destination. Row 2 is a control: one letter
in the leading segment is the whole difference from row 1, confirming the trigger is
the project-name collision rather than anything structural about the path.
The false positive itself
Row 1 is a legitimate same-project move into an existing local folder. I understand
from #904 and #914 that this is Detection 1 behaving as designed, so this half is a
question about the tradeoff rather than a claim that something is broken.
#914 removed Detection 2 because "the structural heuristic is fundamentally ambiguous
— it cannot distinguish the cloud workspace routing shape from a legitimate
same-project nested folder", leaving MOVE_OUTCOME_MISMATCH as the backstop.
Detection 1 seems to have the same property: work/ is an ordinary folder name, and a
knowledge base organised by domain will have folders named after sibling projects as a
matter of course. In our case the destination folder already existed in the current
project, and the only workaround was git mv, which bypasses Basic Memory and leaves
the index to be reconciled separately.
Since #904 describes the post-move outcome check as the robust protection against the #881 failure, it may be that the heuristic is now costing more in false positives than
it adds.
What would resolve it
At minimum, make the two code paths agree — whatever the rule is, a file and a
directory should not disagree about the same destination.
If Detection 1 is kept, skipping it when the destination folder already exists in
the current project would remove this class of false positive, since an existing
local folder is good evidence of local intent.
Activity