AADMI
Navigator
Planned delivery
Cursor scopes and implements net-new work. AADM provides the workflow language for what “ready” looks like before you ship.
▸ How responsibility divides
Standard as coaching.
Cursor as editor.
The division
AADM defines the workflows, layer language, and evidence discipline. Cursor is the harness — it and the model inside it open your project and apply that standard to real code.
Understanding the division makes both more useful. AADM doesn't read or patch your repo. Cursor doesn't define what “done” means. Wire them together and your agent's first PR matches the team's bar.
What AADM actually does.
AADM — the standard plus MCP — is guidance and guardrails: workflows (Navigator / Investigator / Sentinel), layer language, evidence-before-fix discipline, templates, and tools that return structured prompts and checklists.
It is not your app and does not run inside your product codebase.
“Application repos prove AADM through code, tests, and evidence.” — AGENTS.md
What the MCP does not do
- 01 No repo scan The MCP server does not read your codebase or issue a “certified compliant” verdict.
- 02 No pass/fail score Real behavioral proof stays with your repo · tests, CI, traces, review.
- 03 No app patching AADM shapes what agents demand (e.g. “pair mutations with invalidation”). It doesn't patch your branch.
What Cursor / the AI does.
Cursor and the model can open your project, grep, read files, and change code. That is normal engineering work in your workspace — not “AADM certifying” anything.
If the model ever said it violated AADM by reading code, that was an over-correction. AADM never says “don't read the repo.” It says the MCP isn't the authority that scanned everything — and you shouldn't treat tool output as a compliance score without your own evidence.
II
Investigator
Defect work
Cursor reads traces, greps code, and applies fixes. AADM enforces evidence-before-fix — recon first, remediation only after the failure is classified.
III
Sentinel
Assurance
Cursor traces AUTH and UDALI seams across your codebase. AADM defines what evidence is required to attest alignment — not a vibes check.
Cursor in action (illustrative).
The transcript is fictional. Real MCP payloads follow tools/list contracts on your server build.
workspace-api · Cursor
Agent · MCP enabled
Slice audit · L7 DTO / serialization · Sentinel framing
You
Run a Sentinel-style slice on our workspace API: trace critical fields from request → schema → domain → DB → DTO → JSON response. Flag leakage, rename mismatches, and silent truncation — not just “is auth enforced.” Use AADM MCP for workflow + audit scaffolding.
Agent
On it. I'll pull the orchestrator snapshot, then kick an assurance-shaped audit run so we inherit the section spine and suggested AUTH pulls — then I'll summarize data-flow risks for your team.
MCP tools/call
standard_brief {
"capabilities_schema_version": "…",
"sentinel_assurance": { "workflow_id": "assurance", "stages": [ … ] },
"follow_on_catalog": [ { "id": "audit_run_nl", "suggested_tool": "audit_run" }, … ]
} MCP tools/call
audit_run {
"request": "Assess workspace API for response leakage, camelCase vs snake_case mismatches, date/string drift in DTOs, and silent batch truncation.",
"app_name": "Workspace API (illustrative)"
} Agent · readout
Slice readout — framed as data-flow bugs (harder than “is the filter present?” enforcement checks):
Representative risks (illustrative)
- Field leakage — response includes internal-only columns because the list DTO mirrors the persistence model.
- Format mismatch —
deleted_atstored correctly but serialized as a plain string where clients expect ISO-8601. - Silent truncation — batch accepts 100 rows; mapper drops half with no error surface.
These are contract / observability problems across hops — not a substitute for gateway AUTH, which still has to be proven in your repo.
Next: paste the coding_agent_markdown brief from a real audit_run response, pair it with two HAR or test fixtures, and we'll turn this into repo-specific file paths and fixes — still evidence-first.
Common questions, short answers.
01 Question
Does AADM “do adherence”?
Short answer
It defines adherence expectations and process. Your repo and tests demonstrate adherence.
02 Question
Does Cursor fix the code?
Short answer
Yes — fixes happen in your codebase via the agent (or you). AADM doesn't patch your repo by itself.
03 Question
Should Cursor read the repo?
Short answer
Yes. Verifying alleged gaps with Read/grep is appropriate. Claiming “no remediation needed” must be justified by behavior (repro, GET before/after) — not line reads alone.
Three pieces. Three jobs.
A
AADM
Standard + coaching. Defines what “done right” looks like and what to demand from every agent turn.
B
Your app + CI
Proof. Tests, traces, and review that confirm the branch actually does what AADM coaching demanded.
C
Cursor
Editor / agent. Applies the coaching to real code in your workspace — reads, greps, ships the fixes.
Model inconsistency (e.g. “gaps don't exist” from a line read, then “I shouldn't verify in code”) is not a faithful reading of AADM. The standard asks for behavioral proof — not permission to avoid reading your repo.