Deterministic Context

Your AI assistant should read facts from a database, not guess.

AI coding agents start every session cold and re-infer project state. The dc tools replace that guessing with persistent, queryable memory — deterministic facts served over MCP.

$ uv tool install 'dctracker[mcp]'
$ dct init
# package: dctracker · command: dct

The problem

Every session starts cold. You re-explain, or the assistant guesses.

What was decided, what's mid-flight, how the code hangs together — re-inferred from scratch, every time. That rebuild isn't just slow: it burns tokens on files the agent already read yesterday. TODO.md rots. GitHub Issues track a repo, not your working state — per-repo, remote, and blind to what's mid-flight across your projects.

Guessing
  • “Let me re-read the codebase…”
  • Stale TODO.md as memory
  • Decisions lost between sessions
  • Hundreds of reads to rebuild context
  • Plausible ≠ true
Facts
  • One user-scoped database
  • Read & written over MCP
  • Append-only ledger of decisions
  • State read once, not re-inferred
  • Same input, same answer

What it saves

Tokens

Context comes from one compact database read instead of re-inferring the repo every session.

File reads

Recent changes are a query: changelog, items, decisions, no blind grep expedition across the repo.

File writes

State goes to the ledger over MCP, so there is no TODO.md churn and no status docs to keep in sync.

dct · Deterministic Context Tracker

End the day with /handoff. Start the next with /pickup.

The next session picks up the same open threads, decisions and plan — the outgoing session wrote the handoff while it still had the context, so nobody re-explains in the morning. Nothing to memorize, either: plain conversation drives it, and the slash commands below are optional shortcuts.

# one working session
/track fix invoice rounding  → issue #142 opened
/commit → blocked: no changelog entry
         → agent adds changelog entry: "fix invoice rounding"
/commit → ok, changelog + commit recorded
/handoff → sprint flagged, prompt for next session stored
# next morning, cold start
/pickup → resumes #142: 2 todos open,
          review gate pending, plan loaded
# shown as Claude Code skills — any MCP client calls the
# same tools: create_item · pickup_work · handoff_work
  • Cross-project trackerIssues, todos and features with priorities, notes and checkpoints — one database across every repo, read and written by the agent over MCP.
  • Session handoffs/handoff flags the sprint — what's in flight now — and leaves a prompt for the next session; /pickup reads both and resumes, across projects.
  • Markdown plans, indexedPlan, spec and ADR files stay markdown; dct anchors their sections and checkpoints in the DB — promotable to items and sprints.
  • Append-only ledgerNotes and decisions are soft-deleted, never dropped.
  • Gate checkpointsA feature can't resolve while its gates are pending — dogfood, security, review, approval. Enforced in code.
  • Changelog-firstA Claude Code hook (wired at init with your consent, then on by default per project) blocks agent commits until a changelog entry exists — one line per change, written while the diff is still on screen; /release is one command.
  • One-read pickup/pickup restores recorded state in a single structured read, cutting the repeat discovery reads.
  • Local dashboarddct web — a read-only web viewer over the same database.
52 MCP tools13 Claude Code skills4 Claude Code hooks~1180 testsPython 3.11+SQLite / PostgresMIT
dct web — the local read-only dashboard: sprint stats, item tables and project navigation dct web — the local read-only dashboard in dark mode: sprint stats, item tables and project navigation
dct web — the local read-only dashboard, on the same database the agent uses.
dcg · Deterministic Context Graph

The blast radius of a change, visible before the damage.

dcg parses your codebase into a graph database and serves it to agents over MCP — 17 tools, Go single binary, Neo4j storage, Python and Go parsers, Django-aware.

> get_impacted billing/models.py::Invoice.total

Invoice.total ─ impacted (14 nodes, depth ≤3)
├─ billing/views.py
│  ├─ InvoiceDetail.get_context_data  [dj:view]
│  └─ export_csv                      [fn]
├─ billing/serializers.py
│  └─ InvoiceSerializer.get_total     [drf:fld]
├─ reports/monthly.py
│  └─ build_revenue_report            [fn] ⚠ entry pt
└─ templates/billing/detail.html      [dj:tpl]

coverage: py 96% · dj 91% · tpl 78%
unparsed: 3 files (listed on request)
Same input, same graph, every time.
Every parser reports coverage — it tells you what it doesn’t know.
One graph query instead of a grep-and-read expedition.
Coming soon — watch github.com/fotodeveloper.

Philosophy

Deterministic

Facts come from a database, not from a model's best guess: same query, same answer. Where a model does help — classifying an ambiguous plan heading — its verdict is written down once and becomes a stored fact, never re-guessed. Determinism here means retrieval: once recorded, state is never inferred again.

Append-only

A ledger, not a whiteboard. Notes, checkpoints and decisions are soft-deleted at most; nothing is ever hard-deleted.

Enforced, not suggested

Gates and hooks live in code, not in convention. An agent commit without a changelog entry doesn't happen — a Claude Code hook blocks it at the tool boundary; a feature with pending gates doesn't resolve.

Local-first

Your tracking data lives in your own database — SQLite in your platform's data directory by default, first-class PostgreSQL when you want a server — and is never uploaded. The only network touchpoints are explicit and optional: a daily PyPI version probe (opt-out) and LLM plan-classification through the claude CLI you already use.

Honest about limits

dcg's parsers report coverage; across the family, the tools tell you what they don't know, so you never mistake a partial answer for a complete one.

Open source

Built in the open.

dct ships under the MIT license and takes issues and pull requests today; dcg opens to contributions with its first public release. Bug reports, docs fixes and framework ideas are all welcome.

Contribute on GitHub →