← All Docs

Project Context Working Copies

Put Lore project knowledge into code repos for agents, review corrections, and keep canonical Lore coherent across humans and tools.

Lore can be used through MCP, the CLI, the lore browse TUI, direct editor workflows, and repo-local project context. These surfaces are meant to feel different in the hand but share one operating model.

The Model

Canonical Lore = approved truth
Project .lore folder = generated working copy for agents
Working-copy edits = proposed corrections
Approval = apply to canonical Lore and re-index one source
Daemon refresh = update clean snapshots only

Project working copies include all non-deleted sources for the project by default and use copied snapshots, not symlinks. That means coding agents can read project knowledge and propose corrections without directly mutating canonical Lore or your original source files. Use --limit <n> only when you intentionally want a smaller working copy for a narrow task. context add also registers the repo with the Lore daemon, so clean snapshots stay fresh after sync cycles.

Quick Start

From the code repo where you want an agent to work:

cd ~/workspace/ridekick
lore context add ridekick

That creates:

.lore/
├── context.md              # Project overview and source list
├── sources/                # Editable copied snapshots
├── base/                   # Last added base snapshots
├── proposed-corrections/   # Reconcile backups and history
├── manifest.json           # Source IDs and revision hashes
├── AGENTS.md               # Local instructions for agents
├── README.md               # Human workflow guide
└── .gitignore              # Keeps generated context uncommitted by default

Then ask your coding agent to read .lore/context.md before planning or implementing. Use lore context list to see repos with Lore context and their last daemon refresh result.

If the Lore project has no sources yet, lore context add <project> still creates the scaffold and registers the repo. The daemon fills the working copy in after you ingest or sync sources for that project.

A repo-local .lore/ working copy currently tracks one Lore project. Running lore context add <other-project> replaces a clean working copy with the new project. If local proposals exist, Lore refuses to replace them until you review them or pass --force to explicitly discard them. Future multi-context workspaces can layer product, marketing, business, or compliance Lore into one repo with separate sharing and permission boundaries.

Git And Privacy

Most users should not commit .lore/.

lore context add writes .lore/.gitignore containing *, so generated snapshots stay out of the host repo by default without changing the repo's root .gitignore.

If you want the rule to be visible at the repo root, also add:

.lore/

Only commit .lore/ if you intentionally want to share a sanitized context pack. Review every source snapshot first for customer names, transcripts, strategy notes, credentials, or private research.

Review Corrections

If a human or agent spots a factual issue, edit the matching file in .lore/sources/. Then review:

lore context status
lore corrections diff

Approve a reviewed correction:

lore corrections approve <id>

Reject a proposal:

lore corrections reject <id>
# Git-like alias:
lore corrections restore <id>

If canonical Lore changed since the context was added and the working copy also changed, Lore marks the proposal conflicted:

lore corrections reconcile <id>

AI reconcile creates a merged proposal only. It never writes canonical Lore automatically; a user still reviews and approves explicitly.

Turn Off Repo Context

To remove Lore context from a repo:

lore context remove

This unregisters the repo from daemon refresh and deletes only the generated .lore/ working copy. Canonical Lore and your original source files are not changed.

If pending, stale, deleted, missing, or conflicted proposals exist, Lore refuses to remove the working copy until you review them. To intentionally discard local proposals:

lore context remove --force

Browse Inbox

lore browse includes a corrections inbox. If the project working copy is not the current directory:

lore browse --context-target ~/workspace/ridekick

Browse can show pending, stale, conflicted, approved, and rejected proposals; view diffs; approve; reject; manually edit; or run AI reconcile.

Team Workflow

For teams of humans and agents:

  1. Ingest or sync canonical sources into Lore.
  2. Add project context into each active repo or workspace with lore context add <project>.
  3. The Lore daemon refreshes clean snapshots after sync cycles.
  4. Agents read .lore/context.md and .lore/sources/ while working.
  5. Corrections are proposed by editing .lore/sources/.
  6. Humans review with lore corrections diff.
  7. Approval updates canonical Lore and re-indexes one source.
  8. Other machines update automatically through their registered context targets; inspect them with lore context list.

Unapproved working-copy edits are local. Approved corrections sync through Lore Cloud and become visible through MCP, CLI, Browse, daemon-refreshed working copies, and future context adds. To discard a proposal, use lore corrections reject <id> or the Git-like alias lore corrections restore <id>.

Sync Safety

Project .lore/ folders are working views, not canonical sync sources. Do not run:

lore sync add --path ./repo/.lore --project my-project

The sync daemon ignores generated .lore working views during discovery. Canonical sources still come from configured sync folders, MCP/CLI ingest, Browse edits, or approved corrections.

After each daemon sync cycle, registered context targets refresh under Lore's write lock:

  • Clean snapshots update when canonical Lore changes.
  • Locally edited snapshots are preserved as proposals.
  • If local and canonical both changed, the item becomes conflicted and approval is blocked until reject or reconcile.
  • Deleted canonical sources remove clean snapshots, while edited snapshots are preserved and marked deleted.
  • If a user manually deletes .lore/, the target is disabled and is not recreated automatically.

Context refresh runs from Lore Cloud and can proceed even when optional data-dir Git history needs repair. If lore sync status or daemon logs report repair-needed Git state, run lore sync repair; it rebuilds generated caches and leaves real source-content conflicts for manual review.