docs: land the boundary scrub across the corpus

The repository is public. Three passages named a repository that is not,
and the name alone discloses that the project exists. The boundary each
one drew is the content that matters; the name was only the mechanism
for drawing it.

Each of the three is rewritten by capability rather than deleted. a03
hands batch design, transaction behavior, and the atomic setting to
migration operations and lock behavior; a08 and a10 hand the lease, the
retry, the dead-letter design, and the outbox dispatcher to queue
delivery and retry mechanics. The seam and its direction survive intact
-- what the file owns, and where the reader's question goes instead --
so a reader who never sees the name loses nothing but the pointer.

No substitute label replaces a removed name. "A sibling skill" or
"another skill in this suite" would disclose the same set membership the
name did, so each rewrite names a capability and stops.

The README changelog rows for v1.48.0 and v1.49.0 carried two more.
Those rows are historical and are otherwise untouched: the edit removes
the two names and the one word that stopped making sense without one, so
"a named handoff" becomes "a handoff". No date, number, claim, or
verdict in either row moves.

Two seams the final checkpoint reported as unmarked now carry a sentence
each. The process-model material in deployment-and-runtime.md sat
against deploy sequencing, process supervision, and rollback behavior
with no boundary stated at all, and the N+1 material in
graphql-and-alternative-api-surfaces.md sat against query count,
batching, and plan work the same way. Each gets one sentence in the
section that owns the subject, naming what the file owns and what is
outside its scope. Neither becomes a section, and neither enters the
router.

No version bump, no changelog row, and no tag. This is a scrub rather
than a release, and a later session releases it together with its own
work by reading the real diff from the last tag.

Author: n-shadloo

README.md

@@ -667,10 +667,9 @@ access for one deployment window is still an access-control vulnerability.
 A large backfill runs in batches. The batch boundary is where the invariant
 breaks. Never sacrifice the invariant to make the operation resumable. A batch
 that leaves rows at a permissive default widens access for that window. Batch
-design, transaction behavior, and the `atomic` setting belong to the
-`django-migration-safety` skill, which is authoritative on migration
-operations. This file owns one thing only: the access rule holds at every
-batch boundary.
+design, transaction behavior, and the `atomic` setting belong to migration
+operations and lock behavior, which this file does not cover. This file owns
+one thing only: the access rule holds at every batch boundary.
 
 Use `schema_editor.connection.alias` with `.using(alias)` for every query. A
 query that ignores the router writes to the wrong database, which defeats

references/a03-software-supply-chain.md

@@ -627,9 +627,9 @@ between the commit and the enqueue, or a broker outage at `.delay`, leaves a
 `RECEIVED` row that no worker claimed. A periodic sweep re-enqueues the
 `RECEIVED` records older than a small threshold, so a lost wake-up delays the
 work instead of dropping it. The lease, the retry, and the dead-letter design
-of that worker belong to the `django-async-jobs` skill, which is authoritative
-on delivery mechanics. This file owns one thing only: the verified event
-survives the acknowledgment.
+of that worker belong to queue delivery and retry mechanics, which this file
+does not cover. This file owns one thing only: the verified event survives the
+acknowledgment.
 
 `csrf_exempt` belongs on this route and nowhere else, and it is only safe
 because the MAC replaces what CSRF was protecting. A CSRF-exempt webhook route

references/a08-integrity-and-deserialization.md

@@ -340,12 +340,13 @@ with transaction.atomic():
   enqueue itself is lost when the process dies between the commit and the
   callback, so `on_commit` orders the work without making it durable. Where
   the record must not be lost, use the transactional outbox in
-  `a09-logging-and-alerting.md`, "Lifecycle hooks and audit guarantees". Let
-  `django-async-jobs` own the dispatcher that drains it. Past the broker, a
-  worker that finishes the work and dies before acknowledging causes a
-  redelivery. Every task must therefore be safe to run twice. Re-check the
-  state before you act, rather than assuming the first run did not happen.
-  That is the same design as the next section, applied to a worker.
+  `a09-logging-and-alerting.md`, "Lifecycle hooks and audit guarantees". The
+  dispatcher that drains it belongs to queue delivery and retry mechanics,
+  which this file does not cover. Past the broker, a worker that finishes the
+  work and dies before acknowledging causes a redelivery. Every task must
+  therefore be safe to run twice. Re-check the state before you act, rather
+  than assuming the first run did not happen. That is the same design as the
+  next section, applied to a worker.
 - Two tasks enqueued in order are not guaranteed to execute in order or on the
   same worker. Never let task B assume it can see task A's effect; have it
   check.

references/a10-exceptional-conditions.md

@@ -409,6 +409,10 @@ console or Debug Toolbar, medium for metrics and health disclosure.
   (default 100), and `--limit-request-field-size` (default 8190) bound the
   request line and headers before any Django code runs.
 
+This file owns the finding on whether a setting or a runtime posture is unsafe.
+Deploy sequencing, process supervision, and rollback behavior are outside its
+scope.
+
 ## systemd hardening
 
 Restrict the service unit:

references/deployment-and-runtime.md

@@ -479,6 +479,10 @@ against query counts under a realistic nested document rather than trusting
 that the optimizer engaged. The pool-side consequence and its limits are in
 `data-layer-and-database.md`, "Connection exhaustion and query timeouts".
 
+This file owns the finding when an unbounded query becomes a
+denial-of-service surface or a scope bypass. Query count, batching, and plan
+work are outside its scope.
+
 ## Persisted queries and operation allowlists
 
 Where the API serves only first-party clients — which is most Django GraphQL