coulomb-social/docs/release/client-offboarding-scope-review-2026-10-31.md
tegwick f34d46d9f6
Some checks failed
Use-case regression gate / usecase-regressions (push) Failing after 2m27s
Define concrete client offboarding scope and retained data boundaries
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a18e2d-f513-7742-b8e7-12af0b744ff3
2026-10-31 15:56:54 +01:00

8.5 KiB
Raw Blame History

Client offboarding scope review — 2026-10-31

CSOC-WP-0012-T12 now has a concrete, non-destructive scope review. It remains progress, not accepted or executable. This review neither closes the active service nor authorizes deletion, session revocation, expiry or credential changes.

The governing service contract §6.2 requires support for complete client export and deletion: export, instance teardown and backup expiry. Demonstrating that capability does not require tearing down this active client now. T12 still needs its agreed scope, private export delivery/acceptance and independently verified teardown/expiry procedure.

Verified scope and unresolved attribution

The packaged revision19 export proof covers the accepted tenant:platform: one User, Member, Space and SpaceMembership and85local files. Its coherent 07:13recovery point had no external bindings in that selected tenant. The temporary export was removed after validation; this is not a delivered client archive.

A fresh read-only application transaction at14:51Z repeats the ownership checks and finds the same four record counts and85selected local files, with no selected external binding. It also finds two spaces in the instance, one outside the selected tenant. A separate bounded read confirms that unselected space has an external binding and belongs to the configured default tenant (tenant:coulomb), with no creator link. These facts do not establish its legal client, whether it is dispensable, or whether its remote content has been preserved. T11's canonical client/app/instance mapping and the disposition of this unselected binding must precede any proposal to tear down the whole database or instance.

The live read observed43session rows. Those rows were counted, not decoded or attributed to the selected client. The read used a read-only transaction; app writers were not fenced and no new coherent export was created. Do not combine its counts with the older export hash to claim a newly verified deliverable.

Stores and owner returns

Store or boundary Established evidence Required offboarding return
App SQL data, local principals, grants and admin history Database coulomb_social_db; schema-derived inventory and selected-tenant export guards; one unselected externally bound space Resolve client/tenant scope, produce and privately deliver a final coherent export, obtain acceptance, then review the database/role action through the deployment/database owners. Preserve the shared apps-pg cluster and other databases.
Local pages, assets, aliases and all revisions 85selected local files; deployed content PVC coulomb-social-content, UID9888abeb-9d52-4c70-a23d-b5494780d9c3, Bound2Gi/local-path Export all assigned content, including deleted-page revisions. A future teardown must separately identify the claim/PV and verify its storage outcome. The PVC has helm.sh/resource-policy: keep; uninstalling the release alone is not content deletion.
App sessions and transient OIDC state 43current session rows; intentionally excluded from the client ZIP Establish the approved app/tenant scope and revoke its sessions through a reviewed action. A count does not attribute anonymous/transient sessions; do not infer authority to revoke shared identity-provider sessions.
External content and identity links One unselected externally bound space; OIDC/NetKingdom and user-engine are shared owners Resolve the remote content and client assignment. Review only application-specific links/grants with their owners; do not delete shared human identities, provider clients or services based on local Member removal.
Node backup and release state Existing paired archives, release capsules and date-operation journals; date journals can retain original index bytes outside CONTENT_ROOT Include all assigned private bytes and journal/preimage copies in the exact retained/deleted set. T04's custody repair changes ownership/modes only and is not a disposition or expiry approval.
Local retained restores Five running PostgreSQL recovery containers, five volume-backed stores; internal networks, one container each, no published ports Preserve them pending disposition. The private inventory records container IDs, volume/mount identities, networks and links to existing restore receipts. Future cleanup must bind exact identities and verify both database volumes and corresponding plaintext content directories; stopping a container is not deletion.
Private source captures, review bundles and local archives Source inventory spans71spaces and several source principals; private review/export copies are outside the live app Classify ownership before deleting any directory. The whole source capture is not automatically the selected tenant's dataset. Preserve originals, accepted evidence and unresolved source records until explicit disposition.
Primary provider copies Dedicated Coulomb application-archive prefix in shared railiance-platform-pg-backup Provider owner must inventory exact versions, retain the final accepted export/recovery point as agreed, then execute admitted expiry. Do not delete the shared bucket or other applications' prefixes.
Mirrored generations and public receipts Existing dated generation selection and exact-version readback; expiry remains separately admitted Recompute the current exact keep/expiry set at execution. Rolling retention is not full client offboarding; deleting one mirror does not remove primary or protected copies.
Protected kits, proofs and separate recovery-key custody Latest provider kit4166eb8b/version1793432303941465 is explicitly outside automatic expiry Obtain explicit owner disposition for all client-bearing kit versions, proofs and associated recovery custody. Existing no-expiry protection remains in force; destroying a key alone is not a demonstrated complete offboarding procedure.
Logs, telemetry and notification ledgers App/process logs and operator state are outside the ZIP; email-connect is a shared owner Establish attribution and the permitted retention/expiry outcome with each owner. No log, mail-ledger or telemetry payload inventory or removal is claimed here. Preserve unrelated applications and required retained records.
Deployment, endpoint and credential projections Revision19 and its declared resource/identity boundaries remain active After accepted export and explicit teardown admission, remove only the bound instance resources/projections and verify routing, workloads, data stores and owner returns. Keep shared cluster, forge, identity, mail, telemetry and provider services.

The PVC's native PV reclaim policy is Delete, and its claim UID matches the bound PVC. That policy is a configuration fact, not proof of deletion: the claim has not been removed, and no storage teardown has been exercised.

Evidence and closure sequence

The public aggregate proof is client-offboarding-scope-2026-10-31.json. Exact local restore volume/path metadata stays in the private ~/.config/coulomb-social/auth/exports/offboarding-review-20261031/ inventory. Four restore containers link directly to public recovery receipts; the fifth links through the private receipt whose SHA matches the published revision19 client-export proof. All five remain running and untouched.

  1. Bind the canonical client to the actual tenant/instance scope and resolve the unselected external binding; do not substitute the deployment default tenant.
  2. Agree the complete store list and retention/expiry outcomes, including the protected-kit hold, shared-owner stores and retained private copies.
  3. Prepare the exact teardown/expiry procedure and demonstrate it on a disposable scoped instance and provider-owner test resources. Keep production identities, data and held backups out of that destructive rehearsal.
  4. Produce a fresh coherent export for private delivery and obtain the required client acceptance. The existing rehearsal archive no longer exists.
  5. If actual offboarding is later requested, bind the then-current identities, object versions, writer fence, accepted export and approvals before execution; retain independent completion/exception receipts for every included store.

This review does not choose retention durations, release holds, infer a client ID or claim that steps3–5 have been performed. It supplies the missing concrete scope for T12 while preserving T04 retention, T11 attribution, WP-0013 portability and WP-0014 source/grant obligations.