Critical Pathing Inconsistency: lore stale Failures and lack of Monorepo Isolation

[c-ferrier]

The Problem
In its current state, Lore uses Git’s default repo-relative paths for storage but executes commands from the user’s current working directory (CWD). This leads to a critical silent failure in the protocol's "Context Decay" detection (lore stale) and prevents correct behavior in monorepos. Furthermore, Lore currently lacks isolation boundaries, allowing it to "leak" context across different Git repositories.

A Concrete Case: The lore stale Silent Failure
The stale command is intended to detect "drift" (when code has changed significantly since a decision was made). In any nested directory structure, this is currently broken:

• The Setup: A Lore project exists at /repo/project/.
• The Storage: When a commit is made, Git returns a path like project/src/file.ts. Lore stores this repo-relative path in the knowledge atom.
• The Failure: When a user runs lore stale from inside project/, Lore asks Git for the history of project/src/file.ts. Because the command executes from the CWD, Git looks for project/project/src/file.ts and finds nothing.
• The Result: Lore falsely reports 0 drift, leaving the user unaware that their context has decayed.

The Proposal: Strict Lore-Root Centricity
Lore must adopt a Lore-Root Centric model. Every path Lore handles internally—whether stored in an atom or used in a query—must be relative to the directory containing the .lore/ folder.

The Rules of Discovery (Isolation Boundaries)
To ensure project integrity, Lore must implement strict resolution rules. This is a departure from the current behavior, where Lore "climbs" to the system root to find a configuration.

1. Strict Boundary Halts: Root discovery must stop walking up the directory tree immediately upon hitting a .git/ folder. Lore must never "leap" across a Git boundary to find a .lore/ folder in a parent directory.
2. Fallback Rule: If no .lore/ directory is found within the current Git repository boundary, the Git root itself becomes the default Lore root.
3. Containment: A Lore root must always reside within (or at the root of) its own Git repository.

User Experience vs. Internal Protocol
This change does not change how users interact with the CLI.

• User Experience: Users can still use CWD-relative paths for all commands (e.g., lore context ./file.ts).
• The Internal Shift: Lore handles the translation. It normalizes CWD-relative user inputs into Lore-root relative paths before communicating with Git or storing data in atoms.

Required Architectural Changes:

1. Anchor Git Execution: Initialize GitClient with the loreRoot instead of the CWD.
2. Normalize via --relative: Add the --relative flag to git diff-tree in GitClient. This forces Git to return paths relative to the loreRoot (e.g., src/file.ts instead of project/src/file.ts).
3. Path Translation: Ensure PathResolver translates CWD-relative user inputs into Lore-root relative paths for all commands.
4. Conditional Path Scoping:
   • In Monorepos (loreRoot != gitRoot): Every Lore query (even a global lore log) must implicitly become a path-scoped query tied to the Lore root (e.g., git log -- .). This provides automatic isolation between projects.
   • In Standard Repos (loreRoot == gitRoot): No implicit path scoping is required, preserving current behavior for simple repositories.

Benefits

• Functional Correctness: lore stale becomes reliable because stored paths perfectly align with the anchored execution context.
• Professional Monorepo Support: Projects become isolated by default. lore log stays focused on the current project's decisions.
• Total Portability: Knowledge atoms become strictly tied to their project folder. You can move the project to any other Git repository, and its history remains valid.
• Safety & Security: Prevents accidental "leakage" where Lore might try to apply one Git repository's decisions to a completely unrelated parent or sibling repository.

Looking forward to your feedback on this architectural shift, @Ian-stetsenko