← 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

Project working copies use copied snapshots by default, not symlinks. That means coding agents can read project knowledge and propose corrections without directly mutating canonical Lore or your original source files.

Quick Start

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

cd ~/workspace/ridekick
lore context export ridekick

That creates:

.lore/
├── context.md              # Project overview and source list
├── sources/                # Editable copied snapshots
├── base/                   # Last exported 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.

Git And Privacy

Most users should not commit .lore/.

lore context export 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 exported source 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 export 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.

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. Export project context into each active repo or workspace with lore context export <project>.
  3. Agents read .lore/context.md and .lore/sources/ while working.
  4. Corrections are proposed by editing .lore/sources/.
  5. Humans review with lore corrections diff.
  6. Approval updates canonical Lore and re-indexes one source.
  7. Other machines refresh with lore context export <project>.

Unapproved working-copy edits are local. Approved corrections sync through Lore Cloud and become visible through MCP, CLI, Browse, and future exports. 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.