Discrepancy between lore doctor and lore trace lookup (ID Poisoning)

[c-ferrier]

Description

There is a fundamental discrepancy in how Lore handles atom discovery versus how it validates history health.

• Lookup: lore trace (via AtomRepository.findByLoreId) uses git log --all. This ensures references can be followed across branches, but it picks the latest commit by date globally across all refs.
• Validation: lore doctor uses AtomRepository.findAll(), which currently does not use --all and only scans the current branch's history.

Impact

A user can be misled by lore doctor into thinking their decision history is unique. However, a commit on a different branch (e.g., a dead branch or a faked future-dated commit) can share the same Lore-id. Because lore trace picks the newest commit globally, it may "shadow" the legitimate decision on the current branch with poisonous or outdated data from another ref.

Reproduction Script

#!/bin/bash
set -e

# Initialize a clean repo
mkdir -p repro-lore && cd repro-lore
git init -q
git config user.email "you@example.com"
git config user.name "Your Name"

echo "Initial" > initial.txt
git add initial.txt
git commit -m "initial commit" -q
DEFAULT_BRANCH=$(git branch --show-current)

# Use absolute path to lore binary if needed
node ../bin/lore.js init

# 1. Create a "Poison" commit with a future date on a side branch
git checkout -q -b poison-branch
echo "Poison data" > poison.txt
git add poison.txt

# Use a specific Lore-id and a future date
GIT_AUTHOR_DATE="2030-01-01T00:00:00" \
GIT_COMMITTER_DATE="2030-01-01T00:00:00" \
git commit -m "feat: poison commit

Lore-id: deadbeef
Constraint: This is poison context" -q

# 2. Create a "Legitimate" commit on default branch with the SAME Lore-id
git checkout -q "$DEFAULT_BRANCH"
echo "Legit data" > legit.txt
git add legit.txt

# Normal date, same ID
git commit -m "feat: legit commit

Lore-id: deadbeef
Constraint: This is legitimate context" -q

echo "--- Running lore doctor (on branch $DEFAULT_BRANCH) ---"
node ../bin/lore.js doctor

echo -e "\n--- Running lore trace deadbeef ---"
node ../bin/lore.js trace deadbeef --json | grep -i "\"intent\":"

Ideas / Discussion:

1. Should lore doctor have a mode to use the --all flag?
   If it did, it would catch duplicates across branches. However, we have to be careful: if a user amends a commit and the old commit is still reachable (e.g., in a backup branch or tag), doctor might become noisy with false positives.

2. Should lore trace (findByLoreId) only use the current branch?
   Almost every other command in Lore is branch-local. If trace dropped the --all flag, it would strictly respect the history of the current branch, eliminating the "poisoning" risk. However, this might break the ability to trace dependencies that exist in unmerged side branches.

3. Should lore commit guard against ID collisions?
   When amending a commit, should Lore check if that Lore-id already exists in a "protected" branch (like main)? This would prevent a developer from accidentally (or intentionally) "cloning" a decision ID or amending a commit that has already been merged into the canonical history, which is what leads to these shadowing issues.