The dependency is legitimate. The introduction is not approved.
An AI refactor adds sqlalchemy. It is a real, useful library—but it is not on this repository's audited allowlist. Mneme raises a structured WARN so someone can make the call instead of letting the dependency drift in unnoticed.
A review signal. Not an automatic veto.
This trace ends at WARN: the policy asks for a decision; it does not quietly wave the package through.
approved-deps · Audited packages only. FastAPI, Pydantic, httpx, pytest, ruff, and internal_* are approved. Everything else requires explicit review.
-
01 Decision
The repository versions an explicit allowlist instead of relying on reviewer memory.
approved-deps · scope: Python packages -
02 GuidanceN/A
This page documents a post-generation check; no pre-flight guidance event is captured.
Not present in this reproduction -
03 Violation
The generated diff adds a package that has not completed the project's approval path.
+ import sqlalchemy · + from sqlalchemy import create_engine -
04 Deny / warnWARN
The dependency matcher emits a reviewable warning with the originating policy.
WARN [approved-deps] · sqlalchemy not in approved list -
05 CorrectionN/A
A reviewer may remove the package, approve it, or record a scoped override. None is shown here.
Outcome pending human review -
06 AllowN/A
Because no resolution is included, this page does not claim a passing state.
Not demonstrated
Run it yourself
Reproduce the warning against your allowlist
Record a dependency-policy rule, save the proposed diff as an input file, and query that policy through the CLI.
pipx install "mneme-hq>=0.5.1"
mneme check --memory .mneme/project_memory.json \
--input proposed-diff.txt --query "dependency policy"
# WARN [approved-deps] ยท sqlalchemy requires reviewThis is a command-level reproduction, not a dedicated bundled fixture. Strict CI can promote the warning to a blocking failure.
What happened
Training-data prevalence cannot substitute for the repository's security and maintenance decision.
A legitimate exception can proceed through review without training teams to disable an indiscriminate hard gate.
Approval, removal, or a scoped exception can be recorded instead of disappearing into a comment thread.
Common questions
Why is this WARN instead of DENY?
New dependencies can have legitimate reasons. WARN surfaces the introduction and policy source while leaving room for explicit review; strict mode can promote it to a hard failure.
Where does the approved list live?
In the repository's project_memory.json as a typed, version-controlled dependency-policy rule.
Why are correction and allow absent?
The original evidence ends at the warning. A reviewer outcome or approved retry is not part of this reproduction, so the page marks those stages unavailable.
Make new dependencies explicit.
Keep the allowlist in the repository and turn quiet package introductions into reviewable decisions.
pipx install "mneme-hq>=0.5.1"