> SALVOR v1.0.0-beta
Your repo remembers.
// THE ENGINEERING PROBLEM
Code, commits, and tests show what exists and what changed. They rarely preserve why one approach won, which failure should not be retried, or what an incident taught the team.
Context rotation, subagents, handoffs, parallel branches, new contributors, and vendor changes each create another chance to rediscover, re-litigate, or quietly lose hard-won engineering knowledge.
Salvor gives decisions, rationale, domain learnings, rejected approaches, operational lessons, SOPs, and deferred findings a durable, reviewable home alongside the source they explain.
// SALVOR'S ANSWER
Agents can remember. Salvor makes the important knowledge belong to the repo.
Selected decisions, rationale, failures, constraints, and deferred findings become durable Markdown in Git: reviewable with the code, available to teammates, and independent of one vendor workspace.
Persistent engineering cognition is Salvor's term for that durable, governed knowledge carrying forward across sessions, contributors, branches, and models.
Knowledge travels with the code instead of depending on one agent's memory or one vendor's Project.
Promotion requires explicit approval; canonical ownership, provenance, contradiction handling, and supersession are defined.
Supported agents and vendor-native project workspaces can consume the same reviewed repository knowledge.
Git preserves what changed. Salvor preserves what the project learned. Salvor externalizes project cognition; it does not modify an agent's intrinsic intelligence.
// HOW SALVOR WORKS
A vendor-agnostic canonical hub holds project-wide context; component spokes keep it focused, while thin multi-vendor adapters route supported agents to the same shared brain.
L1 is a concise current-state cache. L2 preserves deep reasoning and recovery history.
User-gated Continued Learning: Decision / Domain Learning · Learned Failure · Deferred Finding.
The shared brain is repo-owned Markdown. Compatible thin adapters let you switch supported vendors without migrating project knowledge.
RULES.md defines how reviewed project knowledge and component context stay synchronized. Optional Strict defaults can also enforce project-specific version counters and parity rules.
Optional code intelligence: navigate by symbol and analyze impact before editing.
.salvor/ is the namespaced brain: L1/L2 state, DOMAIN_REF.md, infrastructure, deferred findings (DEFERRED_TODOS.md), postmortems, .salvor/domain-learnings/, and .salvor/decisions/ for durable design rationale. Every durable capture receives a self-allocating slug ID (like LF:stale-note-reference) and structured Subject/Claim metadata. At branch boundaries, the protocol requires knowledge to be compared by subject; duplicates and contradictions are surfaced for your decision, never shipped silently.
The protocol calls for Brain Reconcile at merge and pull points, and for a recurring Brain Audit of the reviewed knowledge layer for stale, duplicate, overlapping, or contradictory claims.
Every capture class is user-gated — durable saves need your explicit approval. For a finding, the agent asks: Save this as a domain learning? (yes/no)
An experimental, off-by-default mode additionally lets agents capture provisionally for overnight and multi-agent runs — explicitly flagged, held in a lower trust tier, and ratified item-by-item by you.
// THE SALVOR LOOP
The shared brain supplies context before the work, then receives user-approved knowledge and rationale after it — so a fresh session can start from reviewed knowledge instead of reconstructing it from scratch.
.salvor/
├── active_state.md
├── active_state_verbose.md
├── DOMAIN_REF.md
├── INFRA.md
├── DEFERRED_TODOS.md
├── README.md
├── decisions/
├── domain-learnings/
├── postmortems/
└── archive/
This is what the brain looks like after real work — every file reviewed in Git.
View a populated example
// SALVOR COMPOUNDS
GREENFIELD
Architecture decisions, implementation choices, failures, operating procedures, and domain discoveries accumulate as the project develops.
MATURE + DELIBERATE
Committed docs, ADRs, changelogs, postmortems, runbooks, and project instructions can seed reviewed knowledge through section-level mappings.
MATURE + MINIMAL
Salvor begins with what setup can legitimately derive from available project state. Undocumented historical rationale remains undocumented until evidence surfaces.
Structure can often be derived. Rationale needs evidence.
Existing sources are inspected read-only. Salvor proposes mappings, preserves canonical ownership, and asks before promotion or mutation; it cannot preserve knowledge it has never been given or had a chance to learn.
// USE SALVOR
PRIMARY PATH
Vendor-agnostic and vendor-portable out of the box: a repository-owned canonical hub and focused component spokes hold the shared context. Thin entrypoint adapters for Claude Code, Codex, and GEMINI.md-compatible clients route each supported agent to that same brain; other agents can integrate through compatible thin adapters.
SETUP_PROMPT.md and answer the four setup questions.Core works with repository files alone; setup doesn't fail without the optional enhanced integrations. Upgrading later is the same move: paste a newer SETUP_PROMPT.md and setup reads the install's protocol stamp, proposing only the protocol deltas. The process is designed to preserve accumulated project knowledge; any explicit identifier, header, link, or metadata migration is proposed separately for approval.
$ cat SETUP_PROMPT.md
$ # copy the output; paste into your CLI
$ # answer the setup questions
$ # Salvor scaffolds the restACTIVE DEVELOPMENT · SHIPS WITH v1.1.0
The Claude Code plugin is in active development and is not part of the v1.0.0-beta release; the universal prompt above is the supported path today.
The future plugin is a convenience wrapper over the same canonical prompt and shared files, never a replacement for the vendor-portable foundation.
Codex and Gemini plugin equivalents are open for contributors.
Plugin roadmap →// EVIDENCE & VALIDATION
SALVOR ON SALVOR
Three inspectable examples show project knowledge surviving into later work. They are operational evidence, not an independent benchmark or a universal performance claim.
Each example follows the same path: engineering work triggers a durable capture; later sessions inherit the reviewed result.
DESIGN DECISION
DESIGN DECISION
DOMAIN LEARNING
RESEARCH STATUS
Salvor is designed around engineering knowledge that compounds across real project history: decisions, domain learning, failed approaches, and deferred findings reused by later sessions and contributors.
Long-horizon agent-memory evaluation is advancing quickly. The methods reviewed cover important adjacent settings, including coding and multi-session reliability, but do not directly reproduce this full mature-repository, repository-governed construct.
As suitable coding-oriented longitudinal evaluation methods mature, we will publish reproducible results here.
Earlier exploratory short-horizon experiments remain archived for reproducibility, but they are not treated as longitudinal validation of Salvor.
// CODE INTELLIGENCE INTEGRATIONS
Salvor's core runs on repository files alone. Serena MCP and GitNexus MCP are optional integrations for semantic code navigation and graph-based impact analysis, each under its own license and terms.
Optional open-source integration for semantic code navigation and targeted edits by symbol: understand the relevant structure before you change it.
github.com/oraios/serena →Optional integration providing a code knowledge graph to inspect the likely blast radius before editing or shipping. A third-party project under the PolyForm Noncommercial license; review its terms for your use.
github.com/abhigyanpatwari/GitNexus →Salvage your knowledge before it's lost to the next session.