-
-
After governed review, the audit passes and superseded history remains visible.
-
Strict audit blocks an unreviewed, unsourced cross-project memory conflict.
Inspiration
Coding agents are getting better at remembering, but persistence creates a new failure mode: a stale, unsourced, contradictory, or agent-invented note can quietly steer every future session. The problem becomes harder when Project A depends on a contract owned by Project B while each agent sees only its own repository.
Most memory tools optimize recall. I wanted a system that asks a different question: is this memory allowed to be trusted, why, and what happens when projects collide?
What it does
MiniPMDB is a local-first trust and provenance layer for coding-agent memory, effectively CI for cross-project agent memory.
MongoDB is the canonical store across five collections: projects, memories, sources, links, and touchpoints. A touchpoint connects two or more projects and validates that every referenced memory belongs to a participating project. Context for either project can then include the other project's governed memory with an explicit project label and inclusion reason. Broken contracts and unresolved warnings cannot disappear from compact context.
The MCP server defaults to project-draft. A connected agent can read governed context, propose only unreviewed candidates for the repository matching its working directory, and attach evidence only to those candidates. It cannot approve, reject, supersede, register projects, write another project's truth, or edit shared touchpoints. Humans retain those controls through the loopback dashboard and CLI. Strict read-only mode exposes no write tools.
The demo
The prepared demo uses two entirely synthetic projects that disagree about a shared release-auth contract. A long-lived token claim conflicts with a reviewed OIDC requirement. The shared touchpoint makes that collision visible to both projects.
The strict audit begins blocked. Applying the governed fix creates a reviewed resolution, supersedes the unsafe claim, repairs the touchpoint, and makes the identical audit pass without deleting or rewriting history.
Run it with:
npm ci --ignore-scripts
npm run judge:demo
No account, API key, model call, preinstalled database, or container is required. Managed mode is tested on Windows, macOS, and Ubuntu. The repository also includes a complete bring-your-own-project prompt so judges can let Codex propose repository-grounded candidates, attach evidence, and stop at the human review gate.
How I built it
I defined MiniPMDB's overall product architecture and functional decisions: MongoDB as the canonical store, project-draft permissions, human-owned review and touchpoint controls, cross-project context behavior, local-first operation, and the deliberately bounded public scope.
Codex with GPT-5.6 accelerated implementation of those choices, sanitization, test coverage, cross-platform hardening, documentation, open-source packaging, and production of the live demo. Final product and release decisions remained with me.
The application uses Node.js, the official MongoDB driver, and a pinned managed MongoDB runtime. The dashboard is dependency-light HTML, CSS, and JavaScript. The same audit logic powers the API, CLI, MCP server, dashboard, automated judge dry run, and a dependency-free snapshot-v2 GitHub Action. External MongoDB can run locally or through Podman or Docker, while the Node application stays outside the container.
Challenges
The hardest part was preserving cross-project truth without quietly rebuilding isolated JSON stores. Touchpoints had to be canonical relationships with strict referential validation, not copies that drift between repositories.
The permission boundary also had to remain meaningful: an agent may propose useful memory, but it must never manufacture reviewed truth or cross a project boundary. Finally, the managed MongoDB path had to feel like a real product on first run while remaining localhost-only, persistent, credential-safe, and testable across operating systems.
Accomplishments
- A working MongoDB-backed application rather than a static prototype
- Deterministic fail-review-resolve-pass auditing with preserved superseded history
- Genuine reciprocal cross-project context through shared touchpoints
- Project-scoped MCP drafting plus strict read-only mode
- Managed and external MongoDB runtime paths
- A dependency-free GitHub Action over portable, derived snapshots
- Public Windows, macOS, Ubuntu, Compose, and Podman validation
- A fresh-clone judge flow using only synthetic data
- My first deliberately small open-source developer tool, released under MPL-2.0
What I learned
Durable agent memory is less a retrieval problem than a governance problem. Provenance, lifecycle, project ownership, supersession, and explicit human authority matter more than simply returning a plausible note. Cross-project context is where those distinctions stop being theoretical.
Build Week scope
A larger private concept existed before Build Week, but this repository is a new, deliberately bounded public implementation created during the event. None of the private code, data, integrations, history, credentials, or project material is included. Every public project and memory is synthetic.
What's next
MiniPMDB will remain a small open-source tool. Near-term work is focused on onboarding feedback, additional audit policies, and maintaining the public action and managed runtime. Remote hosting, automatic task execution, transcript capture, and unauthenticated network exposure remain intentionally out of scope.
Log in or sign up for Devpost to join the conversation.