quint-code

FAQ

Is this just ADRs with extra steps?

ADRs are static markdown files. Nobody checks if they're still valid. Nobody knows when reality diverged from the decision. quint-code adds: computed trust scores (R_eff), evidence decay, code drift detection, module coverage, cross-project recall, and a verification gate that challenges decisions before recording. ADRs are the starting point; quint-code makes them live.

What happens to decisions after they're recorded?

A markdown file appears in .quint/decisions/ — commit it with your code. The decision tracks affected files: if those files change, drift detection flags it. Evidence can be attached over time (test results, benchmarks). R_eff is computed from evidence quality. When R_eff drops below 0.5, the decision surfaces as stale in /q-status. You review and either waive (still valid), reopen (needs reconsideration), or supersede (replace with new decision).

Can I use this on an existing project?

Yes. Run quint-code init then /q-onboard. The agent scans your codebase for READMEs, ADRs, architecture docs, and captures what it finds as notes. It also runs module coverage to show which parts of your architecture have no decisions.

I have existing specs in a gitignored folder. Can quint-code read them?

Yes. Tell the agent: "scan the docs in .specs/ and record what you find." The agent can read any file in your project. It's not limited to git-tracked files.

My artifacts ended up in a different project

This happens when the MCP config points to the wrong project. Common causes:

  • You added quint-code to a global MCP config instead of running init per project — the project path in the config stays fixed to whatever directory you set, regardless of which project is open.
  • In an IDE-based tool (Cursor, Windsurf): you opened a new project window without running init, and the tool reused the MCP connection from a previously opened project.

Fix: run quint-code init in the correct project directory, then restart your AI tool (or reload the MCP connection). The init command writes a per-project MCP config with the correct path and project ID. This is an inherent constraint of the MCP plugin architecture — quint-code runs inside your tool, not as an independent agent, so it relies on the tool passing the right config.

Does this work with Cursor?

Yes. Run quint-code init --cursor. This creates .cursor/mcp.json and installs commands in ~/.cursor/commands/. After init, enable the MCP server in Cursor Settings → MCP → find quint-code → toggle on.

Is this useful for solo developers?

Yes — you'll thank yourself in 3 months when you can search "why did I pick PostgreSQL over SQLite?" and find the full reasoning, not a vague memory. Decisions accumulate across projects too: when you frame a similar problem in a new project, decisions from old projects surface automatically.

Is this useful for teams?

Decision records commit to git — team members see them in PRs. Reviewers can challenge decisions alongside code. Module coverage shows the team which parts of the architecture are governed and which are blind spots. Team collaboration features (shared server, real-time sync) are on the roadmap.

What if I just want quick decisions?

Use /q-reason — the agent picks tactical mode (frame → explore → decide, no characterization or comparison). Or just code normally — the agent captures micro-decisions as notes automatically. You don't have to use the full cycle for every choice.

What's the overhead?

A tactical decision takes 30-60 seconds. A standard decision takes 3-5 minutes. The time investment pays back when someone (including future you) asks "why?" and the answer is there, with rationale, alternatives, and evidence.

What's FPF?

First Principles Framework — a formal specification for engineering reasoning by Anatoly Levenchuk. The FPF spec is public on GitHub. quint-code implements the practical parts: the ADI reasoning cycle (Abduction-Deduction-Induction), evidence-based trust scoring (R_eff), weakest link aggregation (WLNK), and the decide-measure-reframe loop. You don't need to read the spec to use Quint.

Where's the data stored?

Database: ~/.quint-code/projects/<project-id>/quint.db (SQLite, local, never leaves your machine). Markdown projections: .quint/ in your project (git-tracked, for code review). Cross-project index: ~/.quint-code/index.db (for cross-project recall).