selvedge 0.3.17

selvedge.sh  ·  DevHunt  ·  PyPI  ·  GitHub

Persistent decision memory for AI agents.

Save why you chose an approach, what you rejected, and what would change your mind. Retrieve that context in the next coding session, using a function, database column, API route or dependency as the lookup key.

Selvedge is for anyone using a compatible agent. Connect through local MCP over stdio, or use the CLI from an agent with shell access. Decisions stay in the same SQLite store in .selvedge/ when you switch tools. No hosted account is required; core storage and retrieval make no LLM calls.

Get started · Documentation · Agent compatibility

uv tool install --upgrade selvedge
selvedge demo

Requires uv and Python. Python 3.11–3.14 is recommended; Python 3.10 remains compatible but is end of life. The demo uses a temporary database. Follow the quickstart to connect your agent to a real project.

Use selvedge demo --mcp to save through a local stdio MCP server, restart it and retrieve the same record. Add --json for the checked IDs and versions. This tests the Python installation running Selvedge with disposable data; your agent's configuration, activation and hooks still need a separate check.

Who Selvedge is for

• Solo developers returning to a project after the original conversation is gone.
• Teams that need to pass recorded decisions between sessions and coding tools.

The problem

Code shows the chosen approach. It may leave out the constraint that shaped it or the alternative you ruled out. Selvedge gives those explanations a place in the project and tools to retrieve them before the next edit.

Only explicitly saved decisions can be recalled. A saved explanation is an account supplied by a person or agent; Selvedge does not verify that it is true or guarantee that an agent will consult it. Verify one decision across two sessions to test your setup.

What's new in v0.3.17

Check recorded decisions before a review. Generate a Markdown digest, then run selvedge export --format markdown -o DECISIONS.md --check to catch drift. An identical digest exits 0 silently; a stale or missing digest exits 1 with a unified diff and regeneration guidance. Check mode preserves the digest and stored records. Review exported reasoning before publishing it.

selvedge demo --mcp saves a synthetic rejection through a real local MCP server, restarts it and retrieves the same record. It uses disposable state; it does not verify your agent's configuration or hook activation.

CLI output now preserves literal brackets in user data, and blame and Markdown exports distinguish rejected approaches from changes that were tried and reverted. Python 3.10 compatibility remains for this patch, but that runtime is now upstream end of life; use tested, supported Python 3.11–3.14 for new installations. No new runtime dependencies, migrations or MCP tools.

What's new in v0.3.16

Bring recorded decisions into code review. selvedge ledger shows who recorded each decision and which later record explicitly revised it. The optional PR review Action adds reasons and rejected alternatives for touched files from publication-approved base history. Attribution is self-reported; the Action is opt-in and never executes PR-head code.

selvedge doctor --agent CLIENT checks project hook configuration for all six setup targets, with concrete next steps. Configuration checks do not prove that a client has activated its hooks.

The matched injection pilot completed 24 synthetic trials: still-valid rejected choices recurred in 4/6 eligible runs without memory and 0/6 with injected records. Both conditions passed the stale and unrelated controls. Two synthetic tasks do not establish general coding performance or superiority over maintained files; the earlier four-arm tie is still disclosed. No new runtime dependencies, migrations or MCP tools.

Where Selvedge fits

1. Save a decision. You or your coding agent record a choice, its reason, and any rejected approaches through MCP or the CLI.
2. Keep it with the project. Selvedge stores the record in local SQLite, keyed to the function, column, route or other entity it concerns.
3. Recall it before the next edit. A later session queries the same store and checks whether the earlier constraint still applies.

Git keeps the code history; review tools check changes; observability shows runtime behavior. Selvedge adds the recorded reasons behind decisions. How it works · Agent Trace interchange

How Selvedge compares

Choose the simplest memory mechanism that fits your workflow:

These approaches can be used together. Read the source-linked comparison and instructions versus ADRs versus decision memory for specific selection criteria and limitations.

Why entity history matters. users.email, env/STRIPE_SECRET_KEY, api/v1/checkout and deps/stripe remain useful query targets when their code moves. Explicit rejection and superseding records let a later session inspect what was tried and whether the original constraint still applies.

Why capture time matters. Recording a reason while the context is available can preserve information a diff does not contain. It does not make the reason infallible. Retrieval uses stored records; the coding agent remains responsible for checking applicability and testing its change.

Why changesets matter. Tag events with a shared changeset such as add-stripe-billing to retrieve a task's decisions across tables, environment variables, routes and functions.

Agent Trace interchange. selvedge export --format agent-trace and selvedge import --format agent-trace exchange Agent Trace v0.1.0 records. Reasoning and entity history travel in the dev.selvedge metadata. The mapping and limits document the format; Selvedge vendors the schema and has no runtime dependency on the upstream project.

Quickstart

Connect your agent

With uv installed:

uv tool install --upgrade selvedge
selvedge demo
cd your-project
selvedge setup

Setup detects supported clients. To select a preset explicitly, use --agent with claude-code, codex, copilot, cursor, gemini or windsurf; repeat the flag for multiple clients. These presets are conveniences, not a compatibility limit. For another agent with local stdio MCP support, follow manual setup. Agents with shell access can use the CLI. Prefer pip? Use python -m pip install --upgrade selvedge in a virtual environment. The selvedge-server executable must be on your editor's PATH; launch the editor from that environment or use the executable's absolute path in its MCP config.

Setup asks before changing files, backs up existing content, installs MCP and agent instructions, initializes the project, and offers a Git post-commit hook. Configuration files and lifecycle hooks vary by client. See the compatibility guide for preset paths, activation requirements and limitations.

Restart your agent in the project and approve Selvedge's tools if prompted. Follow your client's project-trust requirements. Ask the agent:

Use Selvedge to record one real approach we considered and rejected in this project. Include the entity, why, and what would change our mind. Do not invent a decision. Show the saved entity path and record ID.

Start a new session and look up the same entity to verify that the decision carries forward. Follow the first-decision verification guide and cross-agent handoff guide for observable checks. MCP access does not automatically capture every decision: the installed instructions guide the agent to use it. Native lifecycle adapters cover supported client events; startup delivery, watched-edit checks and compaction notifications vary by harness. See the agent hook guide before enabling them.

For CI bootstrap or devcontainer.json postCreateCommand:

selvedge setup --non-interactive --yes

Verify the wiring — open a second terminal in the same project:

selvedge watch

Make any change in your AI tool — add a column, rename a function, add an env var. selvedge watch should print the new event within a second of the agent calling log_change. If nothing arrives, run selvedge doctor for a single-command health check that tells you which step is silently broken.

Query your history:

selvedge status                        # recent activity + missing-commit count
selvedge diff users                    # all changes to the users table
selvedge diff users.email              # changes to a specific column
selvedge blame payments.amount         # what changed last and why
selvedge history --since 30d           # last 30 days of changes
selvedge history --since 15m           # last 15 minutes ('m' = minutes)
selvedge changeset add-stripe-billing  # all events for a feature/task
selvedge search "stripe"               # full-text search
selvedge stats                         # observed tool calls and explanation quality
selvedge import migrations/            # backfill from migration files
selvedge export --format csv           # dump history to CSV

cd your-project
selvedge init

selvedge prompt --install path/to/agent-instructions.md

selvedge prompt

selvedge install-hook

Works with compatible agents

Selvedge has no required agent brand or model provider. Its MCP interface uses local stdio: a compatible client must be able to launch selvedge-server and call its tools. Remote-HTTP-only clients need a separate stdio bridge; Selvedge does not provide a hosted endpoint. An agent with shell access can instead use selvedge log and the read commands.

The integrations below are examples. Choose the one matching your client, or configure another stdio MCP client using its own settings format:

/plugin marketplace add masondelan/selvedge
/plugin install selvedge@selvedge

claude mcp add selvedge -- selvedge-server

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

[mcp_servers.selvedge]
command = "selvedge-server"

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

How it works

Selvedge runs as a local MCP server or CLI. Compatible agents call its tools as they work, logging structured change events to a local SQLite database.

Each event records:

• What changed (entity path, change type, diff)
• When (timestamp)
• Who (agent, session ID)
• Why (reasoning — captured from the agent's context in the moment)
• Where (git commit, project)

The diff is git's job. The why is Selvedge's.

Selvedge tracks its own history

This repo dogfoods Selvedge: its .selvedge/selvedge.db is committed, so a fresh clone ships with Selvedge's own why-history. Clone it and ask why any part of Selvedge changed:

git clone https://github.com/masondelan/selvedge
cd selvedge
selvedge status                       # recent changes to Selvedge itself
selvedge search "telemetry"           # why the opt-in heartbeat shipped
selvedge blame selvedge/semantic.py   # why semantic search was added

Every event was logged by the agents that built Selvedge — the same log_change calls this README asks you to make in your own project.

Entity path conventions

users.email           DB column (table.column)
users                 DB table
src/auth.py::login    Function in a file (path::symbol)
src/auth.py           File
api/v1/users          API route
deps/stripe           Dependency
env/STRIPE_SECRET_KEY Environment variable

Prefix queries work everywhere: users returns users, users.email, users.created_at, and any other entity under the users. namespace.

MCP tools

When connected as an MCP server, Selvedge exposes:

CLI reference

selvedge init [--path PATH]               Initialize in project
selvedge status                           Recent activity summary
selvedge diff ENTITY [--limit N]          Change history for entity
selvedge blame ENTITY                     Most recent change + context
selvedge history [--since SINCE]          Browse all history
              [--entity ENTITY]
              [--project PROJECT]
              [--changeset CS]
              [--summarize]
              [--limit N]
selvedge changeset [CHANGESET_ID]         Show events in a changeset
                  [--list]                or list all changesets
                  [--project NAME]
                  [--since SINCE]
selvedge search QUERY [--limit N]         Full-text search
selvedge prior-attempts ENTITY            Prior attempts + inferred outcome,
                       [--description T]   with the tried → reverted →
                       [--all]             re-opened trail + status line
                       [--window 7d]       (--all widens recall)
                       [--fuzzy TEXT]      add semantic matches (needs the
                                           semantic extra; substring fallback)
selvedge supersede ENTITY                 Re-open a reverted decision —
                  --reasoning TEXT         append-only, links the prior
                  [--constraint TEXT]      reverted event (or --supersedes ID)
                  [--stale-when TEXT]
                  [--supersedes ID]
selvedge index [--model NAME]             Build/update the optional semantic
              [--json]                     embeddings index (selvedge[semantic])
selvedge stale [--entity ENTITY]          Decisions due for a revisit: past
              [--project NAME]            revisit_after + still in use, or
              [--agent NAME]              stale_when matched by a later change
              [--json]                    ("review suggested")
selvedge stats [--since SINCE]            Tool call coverage report (per-tool, per-agent)
selvedge doctor [--agent CLIENT] [--json] Health check; optional project agent-hook diagnostics
selvedge install-hook [--path PATH]       Install git post-commit hook
                     [--window MIN]       (default 60 minutes)
selvedge backfill-commit --hash HASH      Backfill git_commit on recent events
                        [--window MIN]    (default 60 minutes)
selvedge import PATH                      Import migrations (SQL / Alembic) or
              [--format auto|sql|         an Agent Trace file (agent-trace)
                 alembic|agent-trace]
              [--from-git]                or walk git history for reverts:
              [--since REF|DATE]          revert-message commits + deletions
              [--project NAME]            become change_type="revert" events
              [--dry-run]                 (idempotent on commit + entity)
selvedge export [--format json|csv|       Export history (agent-trace =
                 markdown|agent-trace]      Agent Trace v0.1.0 records;
                                            markdown = reviewable digest)
              [--since SINCE]
              [--entity ENTITY]
              [--ndjson]                  agent-trace: one record per line
              [--collapse-by-session]     agent-trace: merge a session into one
              [--output FILE]
selvedge log ENTITY CHANGE_TYPE           Manually log a change
             [--diff TEXT]                CHANGE_TYPE: add, remove, modify,
             [--reasoning TEXT]           rename, retype, create, delete,
             [--agent NAME]               index_add, index_remove, migrate,
             [--commit HASH]              revert, supersede
             [--project NAME]
             [--changeset CS]
             [--revisit-after WHEN]       ISO date or offset (e.g. 90d)
             [--rename-from OLD]          OLD path when CHANGE_TYPE is 'rename'
             [--constraint TEXT]          the principle behind the decision
             [--stale-when TEXT]          what would invalidate it
             [--supersedes ID]            with CHANGE_TYPE 'supersede'
selvedge migrate-paths                    Re-canonicalize stored entity paths
                      [--apply]           (dry-run by default; --apply writes)
                      [--json]

All read commands support --json for machine-readable output.

Relative time in --since:

• 15m → last 15 minutes (m = minutes)
• 24h → last 24 hours
• 7d → last 7 days
• 5mo → last 5 months (mo or mon = months)
• 1y → last year

Unparseable inputs (e.g. --since yesterday) exit with a clear error rather than silently returning empty results. ISO 8601 timestamps are also accepted and normalized to UTC.

Configuration

.selvedge/config.toml

Every key is optional; a missing file means the defaults below. Precedence is CLI flag → env var → project .selvedge/config.toml → global ~/.selvedge/config.toml → default. SELVEDGE_DB is the one exception: it always wins for database resolution, because the config file is found by resolving that path. selvedge doctor prints the effective value and the step that produced it for every setting.

retention_days_events     = 0       # 0 = never delete events (the default)
retention_days_tool_calls = 90      # local telemetry retention
backup_keep_last          = 7
diff_bytes                = 65536   # truncate oversized diffs at log time
reasoning_bytes           = 32768   # truncate oversized reasoning
db_size_warn_mb           = 500     # doctor warns above this
stale_days                = 0       # 0 = off
digest_max_bytes          = 4096    # cap on the session-start digest
redaction_patterns        = []      # extra secret shapes to warn about

[hook]
watch_globs = ["**/migrations/**", "db/**/*.sql"]

Every key also has an env override (SELVEDGE_DIFF_BYTES, SELVEDGE_RETENTION_DAYS_EVENTS, …).

Reviewing captured intent in a pull request

.selvedge/selvedge.db is a SQLite file, so the reasoning inside it doesn't show up in a diff. If you want a reviewable copy, export a Markdown digest:

selvedge export --format markdown -o .selvedge/DECISIONS.md
git add .selvedge/DECISIONS.md

The digest is grouped by entity with reverted and rejected decisions first. Explicit reject events appear under Considered and rejected, separate from Tried and reverted. The latest event determines the section; a later supersede moves either kind to Re-opened while retaining the full history. Human-readable blame also labels explicit rejections as "rejected". For API compatibility, JSON status and trail phase keep the existing reverted negative-verdict category; change_type: "reject" identifies a rejection.

The digest is deterministic — regenerating with no new events produces a zero-line diff, so it stays reviewable instead of becoming noise everyone learns to skip. Heading anchors derive from the entity path, so links into it keep working as it grows. Regenerate it in the same commit as the code, or from a pre-commit hook.

To catch a stale or missing digest in a hook or CI, use the same filters and output path with --check:

selvedge export --format markdown -o .selvedge/DECISIONS.md --check

The check exits 0 silently when the UTF-8, LF-terminated bytes match, 1 with a unified diff when stale or missing (or an error when unreadable), and 2 for invalid arguments. It requires Markdown and an explicit file; stdout and other formats are rejected. It does not rewrite the digest, create or migrate a database, change stored records, or start background update and telemetry checks. Use an existing initialized store in CI, selected through the normal database resolution or SELVEDGE_DB. SQLite may maintain its normal WAL locking files while reading. Regenerate without --check to update the digest.

Publishing either the digest or database is optional. Review captured reasoning and metadata for secrets and private information before committing or sharing them; a generated diff can also expose that information in CI logs.

Coverage checking

Wondering how often your agent actually calls log_change? Two ways to check:

# Quick summary in the terminal
selvedge stats

# Cross-reference against git commits
python scripts/coverage_check.py --since 30d

The coverage script compares your git log against Selvedge events and shows which commits have associated change events. Low coverage usually means the system prompt needs strengthening — see docs/fallbacks.md for guidance.

In CI (GitHub Action)

The same check ships as the Selvedge Coverage Check composite Action, so you can track agent coverage on every push — and optionally fail the build when it drops:

# .github/workflows/selvedge-coverage.yml
name: Selvedge coverage
on: [push, pull_request]
jobs:
  coverage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0            # full history so commits can be matched
      - uses: masondelan/selvedge@v0.3.17   # pin to a release tag (or @main for latest)
        with:
          since: 30d
          fail-under: "0.5"         # optional: fail below 50% coverage; omit to report only

It writes a coverage summary to the job summary and exposes coverage-ratio, covered, and total as step outputs. The action cross-references your git history against the Selvedge event log, so the runner needs the project's .selvedge/selvedge.db (commit it, or restore it before this step) and full git history (fetch-depth: 0). Inputs: since, window, limit, fail-under, selvedge-version, python-version, working-directory, db-path.

Contributing

Read the feedback and review process for reporting problems, evaluating feature requests and following up on discussions.

git clone https://github.com/masondelan/selvedge
cd selvedge
pip install -e ".[dev]"
pytest

See CLAUDE.md for architecture details and the phase roadmap.

License

MIT — see LICENSE.

Decision context for reviewers

The shared ledger and PR review Action shows recorded reasons, rejected paths, actor/session attribution and integrity for touched entities. The matched injection pilot reports every trial and limits its conclusion to the tested synthetic tasks.