Challenge 3: Interpret a check --deploy Warning — Possible Solution
====================================================================

WARNING: security.W018: You should not have DEBUG set to True in deployment.

WHAT NEEDS TO CHANGE
------------------------
The DEBUG setting in settings.py (or, following Challenge 1's pattern,
whatever environment variable it's derived from — e.g. DJANGO_DEBUG) is
currently evaluating to True in the environment where check --deploy was
run. It needs to be set to False for any environment that's genuinely
serving real production traffic. Concretely, this usually means setting
the DJANGO_DEBUG environment variable to "False" (or simply not setting
it at all, if the settings.py default is already False, per Challenge 1's
fixed version) on the production server specifically — while leaving it
True only in local development environments.

WHY check --deploy IS A BETTER SAFETY NET THAN MANUAL DISCIPLINE
---------------------------------------------------------------------
Relying on "the developer remembers to change DEBUG before every deploy"
has a specific, well-documented failure mode: it's exactly the kind of
manual step that's easy to forget under time pressure, easy to overlook
when a deploy is routine and unremarkable, and has NO feedback loop —
nothing breaks or complains if it's forgotten; the site simply runs with
DEBUG=True in production until someone notices (often after an incident,
when an unhandled error has already exposed a full stack trace and
internal settings to a real visitor, exactly the risk described in
Course 1's Security Misconfiguration coverage).

check --deploy converts this from "a step someone has to remember" into
"a command that actively checks and reports the actual current state" —
running it as an explicit step in a deployment script (as in Challenge 2)
means a forgotten DEBUG=True doesn't silently ship; it produces a visible
warning that a deployment script can even be configured to treat as a
hard failure (checking the command's exit code) that blocks the deploy
entirely, the same "fail loud before it reaches production" principle
behind CI pipelines that run type-checks and tests before allowing a
merge.

WHY THIS WORKS
--------------
- check --deploy specifically runs a curated set of checks known to
  matter for PRODUCTION security (as opposed to the default `check`
  command, which only validates general configuration correctness,
  regardless of environment) — it's Django's own built-in encoding of
  "here's what commonly goes wrong when Django apps get deployed."
- Treating its output as a required, checked step in the deployment
  sequence (rather than something a developer might glance at
  informally) turns institutional knowledge about safe deployment into an
  automated, repeatable gate — removing the dependency on any one
  person's memory or diligence on any given day.