Phase boundary
Phase 1 delivers the standard, inventory and source appendices. It does not implement retention, apply migrations, access production data, change processor settings or authorize phase 2. The integration owner reviews this packet and obtains the user’s go-ahead. Every migration, including D1 or the memory sidecar schema, requires explicit user approval through that owner before implementation or execution. The findings below are source-backed compliance and data-lifecycle risks. They are not claims of an exploited vulnerability, production data exposure or complete absence of other safeguards. Severity describes the consequence if the observed gap remains in the applicable processing flow. Owners and acceptance are proposed work allocations, not claims that those owners have accepted delivery.Top five risks
DP-03 source examples are abuse IP logging, email development logging, and log-injection sanitization. This distinction prevents treating a log-injection fix as PII redaction.
Principle-by-principle gap register
Small PR sequence
Use native GitHub stacks for actual dependencies. Keep independent documentation, log fixes and processor evidence on separate branches. Each row is a review boundary and can split further by product or store. No row authorizes a migration or a production cutover.Yes means explicit user approval is required for the proposed schema migration. No means the proposed scope avoids schema changes, not that deployment or processor writes are already authorized. If implementation discovers a schema change in a No row, stop that part and obtain approval through the integration owner.
The first useful enforcement stack is C → D → E1/E2 or F1/F2. Storage and Worker stacks depend on the same fence contract. Event TTLs and logging can advance independently once their approved scopes are clear. Integrate a verified contiguous stack prefix only through the integration owner. Do not merge a later layer as implied approval for an unapproved migration below it.
Verification and release evidence
Documentation-only changes require navigation/link/frontmatter checks, a source-count reconciliation, a focused secret scan of the diff andbun check:changed before push. Run heavy validation off local workstations per the resource policy. A refused resource gate requires an authorized remote run or a reported blocker, without bypassing admission. Documentation validation does not require builds, bun validate, database resets, production data queries or provider writes.
Later implementation uses focused non-build tests locally and admitted isolated environments for database/runtime tests. Offload builds and broad suites according to current host/resource policy. Each migration needs explicit approval, isolated reset/upgrade evidence, exact-SHA staging application and the gated production migration result after an authorized release. Documentation alone never authorizes migration execution.
Before rollout, the integration owner records exact source, CI, security review, deployed identity, approved migration receipts, processor evidence and a subject/workspace fixture whose purge is complete across every in-scope store. Maintain the hard release hold for open critical/high security findings under the repository security policy. The source-risk register does not replace independent security review of implementation changes.
Completion of a rights request requires all required store receipts, or a precise lawful retained subset and expiry communicated under the applicable rules. Any missing provider response, unconfirmed delete, inaccessible backup expiry or unresolved unknown write remains visible. Metrics report deadline misses and partial completion without customer content or raw identifiers.