n-shadloo secure-code-auditor
A backend security skill. It reviews server-side code, and it applies secure
defaults while new code is written. Django and DRF are the deep specialty. A
stack-neutral layer under them suits any backend. The scope is the backend:
server-side code, data, configuration, and the deployment the backend owns.
Browser and frontend concerns stay out, except where the server controls the
output. Other agents (Codex, Cursor, Gemini CLI) reuse this content through
AGENTS.md, with Claude as the primary integration.
How the reference material is organized
Everything sits on the OWASP Top 10:2025 spine. Each reference has two
layers. The principle layer states the vulnerability and the defense in
stack-neutral terms. The Django & DRF layer holds the settings, the code
patterns, the correct and wrong examples, and the gotchas. A sub-topic
checklist splits the same way, into #### Stack-neutral and #### Django & DRF. A file's final ## Review checklist may stay unsplit, and neither form
is a defect.
Every control is stated in two grammars. The review form says what to flag.
The write-time form says what to write, in a paragraph that opens
**Write-time.** directly under the control it completes. Every reference
that owns a control carries at least one. The two that do not are the
methodology file and the library index.
Load only the file for the concern in front of you. Pick the group, then the row. Where two rows could both match, the ownership table below decides which file is authoritative.
Start here
| Concern | Reference file |
|---|---|
How a codebase is swept: the phase order and per-phase artifacts, the entry-point inventory (URLconf chains at their resolved prefixes, DRF routers and @action methods, Django Ninja, GraphQL, gRPC, Channels, Celery and beat, management commands, signals, admin, webhooks, MCP tools, middleware), principals and trust boundaries, source-to-sink pairing, hypothesis order, the budget rule for a large tree, the six-item verification gate, the cross-cutting benign-pattern catalog, the coverage ledger, attack chains, the security regression harness and scanner gating, the WSTG section mapping |
references/01-audit-workflow.md |
| How a finding is scored and written: the severity rubric and the baseline table under it, the confidence scale, the finding schema and its evidence line, the report structure, the ASVS 5.0 chapter mapping and its non-goals, mode selection, the standing write-time contract with its per-moment index, the conflict rule, the security-decisions note | references/00-methodology-and-severity.md |
The OWASP Top 10:2025 spine
| Concern | Reference file |
|---|---|
A01 Object- and function-level authorization, IDOR/BOLA, generic relations and the client-chosen content type, URL resolution (missing anchors, shadowed routes, reverse() against resolve()), multi-tenancy and tenant freshness, caching and authorization with the 2026 cache CVEs, SSRF and egress control, path traversal on a read the request names, open redirect, locale redirects and language negotiation, admin exposure |
references/a01-broken-access-control.md |
A02 DEBUG and ALLOWED_HOSTS, the SECURE_*/SESSION_*/CSRF_* matrix, __Host- and __Secure- cookie prefixes and cookie tossing, the signed-cookie legacy salt fallback, CSRF trusted origins, wildcard allowlist entries, Fetch Metadata, CORS and origin regexes, compression and BREACH, CSP, mail authentication (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, MAILERS), CAA and dangling DNS, security.txt, check --deploy and its blind spots, project guardrail checks, configuration drift, the expiring exception |
references/a02-security-misconfiguration.md |
A03 Supported Django lines, pins and hash verification, index resolution and dependency confusion, pip-audit, the SBOM from the lockfile, the scan gate read as configuration, build provenance and verification, SLSA claim levels, the artifact boundary, third-party vetting, the development-only package in the production requirements file, migration and data-integrity safety |
references/a03-software-supply-chain.md |
| A04 Password-hashing families and parameters, the wrapped-hasher migration for dormant accounts, peppering, randomness and token generation, constant-time comparison, signing and per-purpose salts, data in transit and at rest, key lifecycle and envelope encryption against a KMS, cryptographic agility and the four-step algorithm migration, post-quantum posture | references/a04-cryptographic-failures.md |
| A05 The sink inventory the whole skill defers to, source-to-sink tracing, SQL and the ORM escape hatches, dictionary-expansion column aliases, GeoDjango raster and spatial lookups, OS command and argument injection, template injection and server-rendered output, Markdown renderers, LDAP filters and distinguished names, header and email injection, CSV and workbook formula injection, XML external entities | references/a05-injection.md |
| A06 Which flows need a rate limit or anti-automation, the inventory of money, credit, entitlement, and status writers (commands, tasks, admin actions, signals, migrations, bulk writes), database-held invariants, amount and currency binding, capture, refund, and reversal, entitlement grant against revocation, side-effecting actions, email and notification abuse, algorithmic resource exhaustion and its per-surface bounds | references/a06-insecure-design.md |
A07 The user model as an identity contract (identifier, normalization, collation, is_active), password policy and breached-corpus screening, sessions and session engines, rotation and revocation, JWT and SimpleJWT, token storage, brute force and enumeration, password reset, email change and purpose-bound tokens, MFA and TOTP seed storage, OAuth2/OIDC and social login with the mix-up attack, passkeys and WebAuthn, REMOTE_USER header authentication, API keys |
references/a07-authentication-failures.md |
A08 Insecure deserialization (pickle, yaml, and the cache, session, and fixture paths Django runs unasked), Celery task messages and the remote-control channel, Django's built-in tasks framework and its inline default backend, signed cookies and data, inbound webhook integrity (raw body, signature, timestamp, replay, per-provider schemes, tenant binding), outbound webhook delivery, pipeline and artifact integrity |
references/a08-integrity-and-deserialization.md |
| A09 The never-log list, error-report scrubbing, the security event set, lifecycle hooks and audit guarantees, log injection and integrity, forensic readiness (append-only sinks, hash chains and their limits, clocks, correlation identifiers), decoy records and canary tokens | references/a09-logging-and-alerting.md |
A10 Fail-open against fail-closed checks, error views and stack-trace leakage, races and TOCTOU, constraints against row locks, the select_for_update() failure modes, get_or_create(), state-transition enforcement, side effects and the commit boundary, idempotency-key design, ReDoS and regular-expression cost |
references/a10-exceptional-conditions.md |
Cross-cutting surfaces
These span several categories, so this group sorts by the surface in front of you rather than by OWASP number.
| Concern | Reference file |
|---|---|
The privilege model (RBAC/ABAC/ReBAC), what Django's permission layer does, has_perm with an object, the DRF object-hook table, admin permission hooks and custom admin views, default-deny and the URLconf audit test, field-level authorization (BOPLA), search indexes and denormalized copies, authorization test suites, permission decay, the joiner, mover, and leaver lifecycle |
references/authorization-architecture.md |
| Impersonation and "log in as user", django-hijack, break-glass and just-in-time elevation, the operator audit identity | references/privileged-access-and-impersonation.md |
Where DRF runs the object check and the routes that skip it, @action and function-level authorization (BFLA), serializer over-exposure and mass assignment (ModelForm and formsets included), writable relations, pagination, filter, and ordering leakage, throttling mechanics and the owned atomic counter, schema and browsable-API exposure, the endpoint inventory and shadow routes, versioning and deprecation, bulk endpoints, unsafe DRF defaults, DRF and CSRF, payment webhook bodies |
references/api-drf-specific.md |
GraphQL resolver authorization and nested traversal, all-fields types, document depth, alias, token, and cost limits, introspection and error masking, mutations and nested writes, batching, persisted operations, Django Ninja routes with no auth=, gRPC servicers, interceptors, and protobuf limits, reflection and channelz |
references/graphql-and-alternative-api-surfaces.md |
| Async and ASGI boundaries, sync ORM access, request and tenant context, WebSocket origin checks, per-connection authentication and authorization, long-lived consumer limits, subscriptions on the subscribe and publish paths | references/async-and-channels.md |
| File uploads from the request to the reader: type and content validation, filenames and storage keys, object-storage configuration, per-tenant buckets against shared prefixes, delegated upload URLs across S3, GCS, and Azure, quarantine and promotion, scan verdict caching and CDR, callback trust, SVG, image and archive bombs, size and quota limits, private downloads, CDN caching of private objects | references/file-uploads.md |
| AI agents and MCP tool surfaces: DRF viewsets republished as tools, agent token audience validation, tool scope intersected with user permissions, model output and retrieved content as untrusted input, per-agent cost and concurrency limits, server-enforced confirmation, tool-call audit, the LLM and Agentic Top 10 mapping | references/agent-and-llm-interfaces.md |
| The auditing agent's own access: the credential files it must never open, the name-by-location rule for every output it writes, the kind, scope, and life of its own repository credential, CI token, and deploy key, instructions inside content as data, the confirmation gate on a recommended rotation or revocation, the command and change record a layer the agent cannot edit has to author | references/agent-operator-security.md |
| Database roles and privilege separation, row-level security, tenant context on pooled connections, verified database TLS, field-level encryption and blind indexes, raw SQL as an isolation bypass, NoSQL and Redis injection, read-replica staleness, transaction isolation and the serialization-failure retry, connection exhaustion, copies of production data | references/data-layer-and-database.md |
| Deletion completeness and erasure, soft-delete tombstones and the traversals they leak through, files left after a row is deleted, retention that can be shown to have run, anonymization against pseudonymization, the personal-data inventory in the model layer, export and subject-access endpoints, audit history against erasure, lower environments | references/data-lifecycle-and-privacy.md |
Service-to-service identity: machine-token validation (algorithm pinning, iss, aud, required claims), JWKS caching and rotation, sender-constrained tokens, client-certificate identity behind a proxy, network position as authentication, downstream token exchange, secret storage and delivery, SECRET_KEY rotation, the leaked-secret response |
references/service-identity-and-secrets.md |
TLS, HSTS, and hybrid post-quantum key exchange at the edge, the reverse proxy and X-Forwarded-* trust, the client IP behind proxies, header ownership, request smuggling and the parser chain, operational and development endpoints in production, Gunicorn and systemd hardening, container images and secrets in layers, static and media, cache and queue exposure |
references/deployment-and-runtime.md |
Package decisions
| Concern | Reference file |
|---|---|
| Vetted security-library choices, compatibility, minimum-safe floors, conditional, existing-install-only, and rejected candidates (current as of 9 Aug 2026) | references/security-hardening-libraries.md |
Ownership and boundaries
Overlap between these files is designed. Each contested topic below has exactly one owner. Every other file names the topic and points at the owner, rather than restates its rules. Each reference also repeats its own half of the rule in its opening paragraph, which is why a row can carry the decision here. The three splits below the table turn on an axis a row would misstate, so they keep their sentences.
| Contested topic | Owner | Deciding distinction |
|---|---|---|
| Sweeping a codebase: phase order, the entry-point inventory, principals, hypothesis order, the budget rule, the coverage ledger, a chain as one finding | references/01-audit-workflow.md |
Procedural — what gets opened, and in what order |
| Scoring and writing a finding: the rubric, confidence, the schema, the ASVS mapping, the report, the write-time contract | references/00-methodology-and-severity.md |
Evaluative — what an opened file is worth. The ledger's not-examined lines become the limitations section, whose shape belongs here |
| The test that holds a closed finding, and the pipeline step that runs it | references/01-audit-workflow.md |
Procedural, and the sweep's forward half. references/authorization-architecture.md still owns the authorization matrix, and A03 the dependency scan gate |
| A suppression, an ignore entry, or a silenced check, and its expiry | references/a02-security-misconfiguration.md |
An exception is a configuration decision wherever it is written. A03 keeps what a pipeline does with a suppressed scanner result |
| The per-request access-control failure | references/a01-broken-access-control.md |
The request that reached what it should not, and how to recognize it in code |
| The privilege model behind it, field-level authorization, and which DRF paths invoke the object hook | references/authorization-architecture.md |
The model rather than the failure. The bypass-path table lives only here |
| The identity's own lifecycle: joiner, mover, leaver, and what a provider-side disable leaves running | references/authorization-architecture.md |
The principal and its grants over time. A07 owns each credential's own rules |
| The call sites where a correct model still fails to run | references/api-drf-specific.md |
DRF routes, actions, and defaults rather than the model behind them |
| Which view a path reaches when two patterns match it | references/a01-broken-access-control.md |
The request that arrived at the wrong code. references/api-drf-specific.md owns producing the route inventory; the pass that groups it by resolved path is here |
| Operator privilege | references/privileged-access-and-impersonation.md |
Impersonation and break-glass, and the accountable operator identity both have to carry |
| Which flows need a rate limit or anti-automation | references/a06-insecure-design.md |
The design question, never the mechanism |
| Throttling mechanics, and the reasons a configured rate is not the effective one | references/api-drf-specific.md |
The mechanism every other file defers to |
| Login lockout | references/a07-authentication-failures.md |
The limit belonging to a human credential |
| Per-agent cost and concurrency limits | references/agent-and-llm-interfaces.md |
Budget per caller rather than requests per window |
| Whether a limit holds under concurrent requests | references/a10-exceptional-conditions.md |
Race and idempotency mechanics |
| Algorithmic resource exhaustion: which inputs multiply work and need a bound | references/a06-insecure-design.md |
Its own table names the surface that enforces each bound. Each of those files keeps its mechanics, down to A10 for the regular expression alone |
| The injection-sink inventory for the whole skill | references/a05-injection.md |
Exhaustive by design, so no other file keeps a partial copy. SQL, the shell, and server-side output are owned outright; every other row points outward |
| SSRF, including the cloud metadata endpoint | references/a01-broken-access-control.md |
Absorbed into A01 in the 2025 list; every file that reaches it defers here |
| The choice of cryptographic primitive, its parameters, and the life of a key | references/a04-cryptographic-failures.md |
The primitive, not the place it is consumed |
Where a secret lives, how it reaches the process, and how it rotates, SECRET_KEY included |
references/service-identity-and-secrets.md |
A02 owns the settings module that names it, and references/deployment-and-runtime.md how the environment is injected |
| What happens when the expected sequence does not hold: concurrency, idempotency keys, fail-closed error handling | references/a10-exceptional-conditions.md |
The mechanics and the fixes. A06 keeps the inventory of flows worth attacking. A08's event de-duplication is the same design as the idempotency key here |
| What must be recorded, what must never be, and whether the record survives as evidence | references/a09-logging-and-alerting.md |
The record, not the failure being recorded. references/data-lifecycle-and-privacy.md keeps the erasure obligation the retained record reconciles with |
| The receiving end of cross-system trust: the inbound webhook, the task message, both task systems, every path that turns bytes back into objects | references/a08-integrity-and-deserialization.md |
Only the integrity of what the project itself produces and consumes. A03 keeps dependency vetting, A01 the delivery worker's SSRF, references/deployment-and-runtime.md broker exposure, references/service-identity-and-secrets.md where signing secrets live |
| The file from the request to the reader: delegated upload URLs, quarantine and promotion, proxied against signed private downloads | references/file-uploads.md |
A08 keeps the callback's signature and replay rules. A01 keeps import-from-URL SSRF and the cache-mediated leak. references/data-lifecycle-and-privacy.md keeps whether the bytes are gone |
| The database as a boundary: roles, row-level security, verified transport, encrypted columns, isolation, pooling | references/data-layer-and-database.md |
The serialization-failure retry a raised level requires is here. The constraint-against-lock choice that usually makes raising it unnecessary is A10's |
| The record over time: deletion completeness, soft delete, retention, anonymization, every copy an erasure has to reach | references/data-lifecycle-and-privacy.md |
Existence rather than access. references/authorization-architecture.md owns who may read a denormalized copy, and A09 what must be logged |
| The surface where the client composes the request, and every API surface that is not a DRF route | references/graphql-and-alternative-api-surfaces.md |
Resolver-edge authorization, document cost, and schema exposure, plus Django Ninja and gRPC defaults a DRF engineer assumes are present |
| The tool-call threat model and the MCP-specific controls | references/agent-and-llm-interfaces.md |
What changes when the caller is a program driving the backend on someone's behalf; it restates none of the machinery it reuses |
| Agent-operator access | references/agent-operator-security.md |
The auditing agent's own access rather than the audited backend's surface. references/agent-and-llm-interfaces.md keeps the serving side, and references/service-identity-and-secrets.md the project's own secrets |
| The container image | references/deployment-and-runtime.md |
Stops at the artifact the repository produces. Orchestrator enforcement is a cross-team recommendation, and where a secret comes from at run time is references/service-identity-and-secrets.md's |
Path traversal. The split between A01 and references/file-uploads.md is
by direction rather than by file type. A01 owns the read whose path the
request named, with what Django does and does not protect there. Those flows
are the report download, the export, and the artifact or log viewer, with no
upload in them. references/file-uploads.md owns the name an upload brought
and the key it landed under. It also owns the private download of a file the
application stored, because the application chose that path. A05's inventory
row for the filesystem path points at A01, and it names
references/file-uploads.md for the storage-key half.
Configuration against runtime. The split is by where the setting lives
rather than by topic, so a search by topic misroutes. A02 owns what a
settings module or a DNS zone declares. references/deployment-and-runtime.md
owns what the proxy, the process, and the image do with a request. That
includes forwarded-header trust, and the client IP that every rate limit and
audit record depends on. A cached response splits on the same line. A01 owns
whether a cached representation may be reused across principals. The
deployment file owns the edge rule that decides what is cached at all. Mail
authentication is A02, whether your domain can be forged, while whether your
mailer can be driven is A06.
Human against machine identity. A07 owns the human principal and every
credential issued to one. That includes the API-key discipline a static
service key still has to meet. references/service-identity-and-secrets.md
owns the machine principal: mechanism choice, inbound machine-token
validation, JWKS caching and rotation, proxy-set certificate identity, and a
downstream credential obtained by exchange. The prohibition on a passthrough
of an inbound token belongs to neither. It belongs to
references/agent-and-llm-interfaces.md, beside the tool-call threat model.
A04 owns the primitives all three are built on.
Mode selection
Review-time. Trigger on three requests. The user asks to review, audit, scan, or "check" existing code. The user pastes code and asks whether it is safe. The user has just finished a feature and wants a look at it. Behavior:
- Load
references/01-audit-workflow.mdfirst, before any topic file. It owns the sweep, and the topic files answer the questions that sweep generates. If you open a topic file first, you review whatever the codebase made obvious. - Treat the codebase as read-only. Do not edit, refactor, or "fix in place" unless the user explicitly asks you to apply fixes afterward.
- Optionally run the bundled scripts for fast triage, then read the code yourself. Scripts surface indicators. They do not replace judgment.
- Investigate before you flag. Confirm the data flow and the reachability of a sink. Do not pattern-match a keyword into a finding.
- Produce a findings report in the exact format in
references/00-methodology-and-severity.md. Order it by severity. Each finding carries a location, a CWE, an OWASP mapping, the evidence it was confirmed on, and a concrete fix. End with what you did not review.
Write-time. Trigger when you generate or modify backend code. Behavior:
- Apply the secure defaults from the relevant reference as you write. Those
defaults are parameterized queries, scoped querysets, explicit serializer
fields, correct cookie flags, safe deserializers, and secrets from the
environment.
references/00-methodology-and-severity.mdholds the standing contract, and the index of which file carries each generation moment's rule. - Prefer built-in framework mechanisms over add-ons (see the library index).
- Where a secure default conflicts with the request, apply the default. Say so in one line that names the risk and the exact opt-out. Never downgrade silently, and never refuse silently.
- Close with a short Security decisions note: the defaults applied, anything the request forced with its residual risk, and anything left for the caller. Write-time does not produce a findings report.
If it is ambiguous, default to write-time guardrails while you code, and offer to run a review afterward.
Using the scripts
All three scripts are read-only, stdlib-only, and make no network calls. All
three take --json, which is JSON Lines in each: one object per line,
consumed a record at a time. Run them for triage. Always confirm what they
surface by a read of the code.
- Entry-point inventory, the instrument for the workflow's first phase:
python scripts/entrypoint_inventory.py path/to/project --settings path/to/settings --json - One or more entry-point families at a time on a large surface:
python scripts/entrypoint_inventory.py path/to/project --kind url,drf,action - Settings posture across a whole settings package (never imports the project):
python scripts/settings_scan.py path/to/settings/ --json - Risky-pattern indicators across a tree:
python scripts/dangerous_patterns.py path/to/project - The same tree as JSON Lines, filtered, for a large codebase:
python scripts/dangerous_patterns.py path/to/project --json --min-severity MEDIUM - Confirm the scanner itself before you trust a quiet result:
python scripts/dangerous_patterns.py --selftest
The inventory enumerates the declared entry points: routes at their resolved prefixes, routers and actions, Ninja, GraphQL, gRPC, Channels, Celery, commands, signals, admin, and middleware. It marks each HTTP-reachable row with one of three states. The row declares its authorization, inherits it from somewhere not visible there, or has none.
All three parse with the ast module rather than match lines, so a hit is a
structural match. Parameterized SQL, mark_safe on a constant, and anything
inside a docstring are not reported. Every row names the reference file that
owns it. A dangerous_patterns.py hit also carries a stable rule identifier.
A file that fails to parse is reported as unparsed rather than skipped in
silence. Their output is a starting point, not a final report. Map each real
issue to a reference, verify it, and report it per the methodology.
What proof is, and the commands that produce it
Proof in this domain is the evidence a finding carries, the coverage ledger, and the script runs. A claim without those three is not a result.
- A finding carries confirmed evidence. That evidence is the shortest
source-to-sink path the finding was confirmed on, and the protection that
failed.
references/00-methodology-and-severity.md, "Finding schema" owns its shape.references/01-audit-workflow.md, "Phase 5 — verification" owns the gate that produces it. A finding without that line is a hypothesis. Label it as one, and put it under "Worth checking" with the exact item to verify. - The not-examined list is part of the deliverable. The coverage ledger keeps examined-and-clean apart from not-examined. Its not-examined lines become the report's limitations section. A report that drops that section claims coverage the sweep did not have.
- The exact commands are the three scripts under
scripts/. Run them as "Using the scripts" above states. Their output is a lead to verify, and never a finding.python scripts/dangerous_patterns.py --selftestproves the scanner itself before you trust a quiet result.
Read docs/architecture/GROUND-TRUTH.md and
docs/architecture/DESIGN-RECORD.md in the target project before any
judgment that turns on scale, configuration, or topology. Treat an absent or
stale entry as unknown, and judge against the least forgiving case. Here that
case is a reachable path and an exposed surface.
Never lower a severity to shorten a report. Never mark a not-examined surface as examined. Never close a finding without the test that holds it closed.
Stop conditions
Two stops already stand, and they stay. Review-time treats the codebase as
read-only. references/00-methodology-and-severity.md, "When a secure
default conflicts with the request" holds the firmer stop on three write-time
changes. Those are disabled TLS verification, pickle on a broker or a cache
other software reaches, and a production credential written into the
repository. Three more apply to this skill's own actions.
- A live credential exposure found during a sweep. Stop the sweep at once and escalate with the five fields below. Do not continue the review while a live credential is exposed.
- A rotation, a revocation, a disable, or a delete. Never execute one, at
any level of confidence. Recommend it, write the exact command, and wait
for a person.
references/agent-operator-security.md, "The confirmation gate on a recommended action" owns the rule. - A read that would open credential material. Refuse it, and ask for the
value instead.
references/agent-operator-security.md, "What the agent must never read" owns the file set.
The handoff carries five fields:
- The goal and the exact blocked step. Name the sweep phase, and the file or the surface the stop happened on.
- What you attempted, with the observed evidence verbatim. Give the location and the shape of the exposure, and never the value.
- The candidate causes you eliminated, and how. Name each one, and the retrieved text that ruled it out.
- The single decision or action you need from the human. State one: the command to run, the value to supply, or the confirmation to proceed.
- The state you leave behind, and whether it is safe to leave. Give the coverage ledger as it stands, and name the surfaces still unexamined.
Severity, in one line each
- Critical — trivially exploitable; RCE, full auth bypass, mass data exposure, or financial/payment manipulation.
- High — directly exploitable under realistic conditions; account takeover, privilege escalation, significant data exposure.
- Medium — exploitable given specific conditions, or a meaningful defense-in-depth gap.
- Low — hardening / defense-in-depth with limited direct impact.
A race is rated on how reliably its window can be won, and on what the collision costs. It is not filed as Medium merely because it is a race. A failure that leaves personal data alive past a promised deletion is rated on that promise as well as on attacker value.
Report findings you are ≥80% confident are real and reachable.
references/00-methodology-and-severity.md holds the full rubric, the
baseline severity table, the ASVS 5.0 chapter mapping, and the report
template.
Freshness
The claims here were verified against Django 6.1, 6.0.8, and 5.2.17 LTS, with
DRF 3.18.0. The foundation is the OWASP Top 10:2025, the API Security Top
10:2023, and ASVS 5.0.0. The agent tokens come from the OWASP Top 10 for LLM
Applications 2026 and the Top 10 for Agentic Applications 2026.
references/security-hardening-libraries.md carries its own index date, and
that date governs every package version claim in it.
Review again at the next Django feature release, and no later than 9 Feb 2027. Re-run the A03 dependency gate against the project's actual Python and Django versions on every use. That gate dates faster than the rest of the skill.