Deletion propagation

Verifies

Account deletion reaches every secondary store in use (caches, search indexes, object storage, third-party processors holding user records) through its own call graph, its events and its jobs, and a propagation window is declared; backups are inventoried, not judged. No AI engine is involved: the verdict is reproducible from the source alone.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP) analysed statically (tokens, function units, calls, imports, route registrations, decorators) plus Prisma, SQL, Markdown, text, YAML, TOML, Terraform and JSON files. The gate is a schema store named like users, accounts, customers, profiles or members with personal-data fields. Entry units of the deletion flow: functions named deleteAccount, deleteUser, closeAccount, removeAccount, eraseUser, gdprDelete, forgetUser, purgeUser, deleteProfile and equivalents; DELETE route handlers of /users, /accounts, /me, /profile, /customers (Next, Express/Fastify/Koa/Hono, Nest, Django, Flask, FastAPI, Laravel); destroy/delete actions of user, account or profile controllers; and listeners of user-deletion events (on('user.deleted'), @OnEvent, queue processors of a delete-user job, Django post_delete/pre_delete receivers with a user sender, Laravel observers, $listen maps and listener classes). The flow is followed through local functions and imported modules (at most 3 module hops), through the listeners of the events it emits (by event name) and through the handle/perform/run methods of the job classes it dispatches. Secondary store classes are detected by their SDKs anywhere in the checkout; a propagation is a deletion or suppression call of that class (redis del/unlink, cache.delete/forget, deleteObject/deleteByQuery/unsearchable, DeleteObjectCommand/Storage::delete/blob.delete, stripe customers.del, contacts.delete, suppress, GDPR/erasure endpoints…) inside a unit of the flow. The window is a number of days, weeks or months next to deletion, erasure, closure or backup wording in a document. Paths listed in excludes are never analysed. Nothing of the checkout is executed.

Decision rule

Not applicable when no user or account store with personal-data fields is declared. FAIL (HIGH, on the user store line) when there is no account-deletion entry unit at all. For each secondary store class in use, the flow must contain a propagation call of that class: a search index or a third-party processor without one is HIGH; a cache or object storage without one is MEDIUM (blocks in Extended suites). No declared window is MEDIUM (window-undeclared). Backups documented in the checkout yield an informative LOW (backups-declared) stating whether rotation or encryption wording accompanies them. PASS when every class in use is reached and a window is declared; the summary names the propagation per class (call, function, file, line, chain) and the window. Not judged by this check (declared): backup expiry and rotation (they run outside the checkout), third parties reached only with opaque identifiers, whether every entry unit propagates on its own (one propagating flow satisfies the class), whether the propagation call is conditional, and whether the processor actually erases on its side.

Type

deterministic

1.1.1: a callee whose root is a name that `Object.prototype` also carries (`build().toString()` tokenizes to the bare callee `toString`; also `constructor`, `valueOf`, `hasOwnProperty`) was looked up in the plain object that holds the imported names, so it resolved to the INHERITED FUNCTION instead of to nothing and the whole check died with "name.includes is not a function". Only a real binding counts now, and the name of a unit is always read as a string. Found on a 1 319-file checkout (2fa-available and session-expiry-rotation, 2026-09-24); the same line was in the 15 scripts that walk the call graph, so all fifteen ship the fix. (1.1.0: deterministic: the rule runs over the static analysis kit (tokens, function units, calls, imports, routes) with no AI engine; exact decisionRule and languages published; not-applicable with the reason when the checkout gives nothing to evaluate. The deletion flow is a call graph from the named entry units (DELETE /users, /accounts, /me handlers, user-controller destroy actions, user-deletion listeners) followed 3 module hops plus emitted events resolved to listeners by name and dispatched job classes resolved to handle/perform; each store class in use (cache, search index, object storage, third-party processor) must be reached by a propagation call in that graph. Not judged: backup expiry and rotation (informative LOW when documented), opaque-identifier third parties, per-entry-point propagation, conditional calls. (1.0.2: never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).)))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.