Codebase Awareness

quint-code doesn't just track decisions — it understands your codebase. It knows which modules exist, how they depend on each other, and which parts of your architecture are governed by decisions.

Module detection

When you run /q-status or quint_query(action="coverage"), quint-code scans your project and detects modules using language-specific conventions:

Language	What counts as a module	How it's detected
Go	Every directory with `.go` files	Uses Go's stdlib `go/parser`
JS/TS	`package.json` boundaries + directories with `index.ts`	Monorepo workspaces + barrel file detection
Python	Directories with `__init__.py`	Package marker detection
Rust	`Cargo.toml` crates + `mod.rs` modules	Crate boundary + module tree detection
C/C++	Directories with `.c`, `.cpp`, `.h`, `.hpp` files	`compile_commands.json` (CMake, Bazel, Meson) with directory-based fallback

Module scanning respects .gitignore (local and global) and an optional .quintignore file for project-specific exclusions.

Decision coverage

Coverage answers: "which parts of my architecture have engineering decisions, and which are blind spots?"

## Module Coverage (9 modules, 77% governed)
  ✓ src/internal/artifact   — 3 decisions
  ✓ src/internal/codebase   — 2 decisions
  ✗ src/assurance            — no decisions (blind)
  ✗ src/cmd/indexer          — no decisions (blind)

Coverage uses three states:

✓ Covered — at least one active decision with R_eff ≥ 0.5 covers files in this module
~ Partial — has decisions, but all evidence is degraded (R_eff < 0.5)
✗ Blind — no decisions reference any file in this module

Only DecisionRecord artifacts count as governance. Notes are observations, not architectural contracts — they don't inflate coverage.

Dependency graph

quint-code parses import statements to build a module dependency graph. For Go, it uses the stdlib go/parser. JS/TS, Python, Rust, and C/C++ use regex-based import detection. C/C++ resolves #include "..." paths using -I flags from compile_commands.json when available.

The dependency graph powers impact propagation: when drift is detected in module A, quint-code checks which modules depend on A and flags their decisions too.

Drift detected in auth/:
  auth/middleware.go — MODIFIED (+8 -2)

Impact propagation:
  → api/ depends on auth/ — governed by dec-003 "API rate limiting"
  → payments/ depends on auth/ — governed by dec-007 "Payment auth flow"
  ⚠ billing/ depends on auth/ — no decisions (blind, potential unmonitored impact)

Drift detection

After a decision is implemented, the agent snapshots the SHA-256 hashes of affected files (the baseline). On every /q-refresh scan, quint-code recomputes hashes and detects:

MODIFIED — file changed since baseline
FILE MISSING — file deleted or moved
No drift — file unchanged

Drift is a signal, not automatic invalidation. The agent reads the actual diff and judges whether the change is material (broke an invariant) or cosmetic (comments, formatting).

Using it in practice

When	What to do
After `/q-onboard`	Check coverage — which modules are blind? Prioritize the critical ones.
During code review	If a PR touches files under a decision, the drift report will flag it.
Before a release	`/q-refresh scan` — see all stale decisions and code drift in one view.
New team member	`/q-status` shows the full architecture decision landscape at a glance.