# apac_sub_unit_standing — retired standing APAC Sub-unit reference

This directory is a historical migration reference. Current Staging D3 defaults
to no Patch Bundle and does not replay this directory on every deployment. The
supported independent operator accepts only exact reviewed bundles under
`docs/migration/patch-bundles`; any future replay must first move or regenerate
the required migration there through review.

The original standing bundle covered three non-pack pieces of the Sub-unit
feature after a branch reset:

| SQL | What it does | Why it's here (not pack/seed) |
|---|---|---|
| `001_fls.sql` | Grants `Account.Sub_Unit__c` read+edit to every profile-owned permset | FLS needs a JOIN over all permsets — can't be a pack permission component or a declarative seed row |
| `002_tags.sql` | Single-column `UPDATE Account SET Sub_Unit__c` keyed by `Account_ID__c` (the reviewed 270-row mapping) | Raw SQL bypasses the app-layer required-field (`Industry`) validation that blocks a REST PATCH on some accounts; idempotent |
| `003_sharing.sql` | Per PoD: a Public Group (member = the virtual-lead User) + a criteria SharingRule `Sub_Unit__c == "<PoD>"` → group (Read) | Runtime records; needs deterministic-Id idempotency + a name-based User lookup |

The field + layout themselves are already pack-owned, so they self-heal via the
normal pack apply — this bundle covers only the FLS + data + sharing.

## Historical ordering

The Classic staging deploy ran stages
`reset-branch → apply-patch → apply → switch-nginx`. This bundle ran in
**apply-patch**, before the main `setup apply`. That mattered for `003`: the raw
`GroupMember` inserts did not fire the runtime membership-closure hooks, but the
subsequent `setup apply` rebuilt `_System_GroupMembershipClosure`, so the leads
actually gained visibility.

## Idempotency

All three are safe to re-run: `002` is `UPDATE … WHERE Account_ID__c IN (…)`;
`001`/`003` are `INSERT … ON DUPLICATE KEY UPDATE` with deterministic Ids
(`MD5` of a stable key). Group members are `INSERT … SELECT FROM User … WHERE
Name = '<lead>' AND IsActive = 1` — env-agnostic (works on staging and prod
without hardcoded per-env User Ids), and a missing/renamed lead inserts nothing
rather than a NULL member.

## Historical validation warning — high blast radius

This bundle has NOT been run against a live DB yet (the last
`reset:true` invalidated the operator creds and the staging read path was timing
out). Before authorizing any future migration, an operator with DB access must
confirm against a non-production target:

1. **`001`** applies (FieldPermissions rows land; a non-admin can then query the field).
2. **`002`** tags ≈266 real accounts (the 4 junk / missing-`Industry` accounts are
   intentionally not real — a raw UPDATE will still set them; drop them from the
   `IN (…)` list if you want them left blank).
3. **`003`** — confirm the schema assumptions hold here: `User.Name` is a
   filterable stored column; `Group` / `GroupMember` / `SharingRule` accept these
   string Ids with no additional required columns; and after the deploy's
   `setup apply`, a lead (e.g. Lux Li) can see all `Sub_Unit__c == "AI"` accounts.
4. Re-run the whole bundle once more and confirm it's a clean no-op (idempotent).

Do not trial it against Prod. The presence of these retained files is not
migration authority.