SRS: UC_8.2.11 — Flow 15C: Pod Leader Termination Offboarding Cascade

---

1. UC Index

---

UC_8.2.11 — Flow 15C: Pod Leader Termination Offboarding Cascade

---

2. Trigger

Event: POD_LEADER_TERMINATED webhook received by Zapier, fired from BPS Admin endpoint POST /api/bps/mentor/terminate.

The BPS endpoint executes the following server-side actions before firing the Zapier webhook:

1. Revokes 'Pod Leader' Discord role from the leader's Global_User_ID.
2. Sets Pod_Leader_Registry.Status = 'Terminated'.
3. Zeros out Pending_Carry_Balance in DB ledger (unvested tranches forfeited).
4. Writes entry to BPS_Audit_Log (Admin ID, Action, Timestamp, Reason).
5. Fires POD_LEADER_TERMINATED webhook to Zapier to execute mentee dispersal and IT offboarding.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Terminate Pod Leadership lines 3004–3023)

---

3. Pre-conditions

---

4. Post-conditions

---

5. Basic Flow

Step 1. Discord Offboarding

• Archive Pod Channel — Call POST /archive-pod-channel:
  • Input: pod_leader_id
  • Discord Bot locates the channel tied to pod_leader_id, removes all user access permissions, renames channel to archived-pod-[leader_name], clears channel_url in SQL Registry.
  • Returns: 200 OK.
• Full Digital Eviction — Call POST /discord/revoke-all-roles:
  • Input: user_id = [terminated_leader_id]
  • Strips all Title Roles (Associate / Trader / Senior), Pod Roles, and Special Roles from the terminated leader's Discord account.
  • The leader's Discord account remains on the server as a general/unverified member — NOT kicked or banned automatically. Manual Admin action required for misconduct.
  • Returns: 200 OK.

(Source: Zapier Integration V7.pdf §Flow 15C Action 1 line 2057; RFQ_ Stack Trading Prop Tech V7.pdf §Archive Pod Channel lines 2280–2292; §Revoke All Roles lines 2308–2322; Client supplement 2026-10-05 — §3.8A Full Digital Eviction)

Step 2. Identify Active Mentees

• Query SQL database for all active mentees where pod_leader_id = [terminated_leader_id].

(Source: Zapier Integration V7.pdf §Flow 15C Action 2 line 2059)

Step 3. Re-assign Mentees

• Execute Flow 10 matching logic for each mentee:
  • Criteria Waterfall: 1. Asset Match (Strict) → 2. Style Match → 3. Fallback: Lowest Current_Count.
  • If match found: assign to new Pod Leader in DB; increment new leader's Current_Count.
  • If no match (all leaders at Max_Capacity = 7): place mentee on FIFO waitlist.
• Discord Re-Sync for each successfully re-assigned mentee:
  • Revoke Mentee's access to the old_pod_id Discord channel.
  • Grant access to the new_pod_id Discord channel.
  • Sync relevant Mentee roles for the new pod.

(Source: Zapier Integration V7.pdf §Flow 15C Action 3 lines 2061–2064; Client supplement 2026-10-05 — §3.8C Re-Sync for Dispersed Mentees)

Step 4. Notify Mentees + Generate Google Meet Links

• Send mentor welcome emails to successfully re-assigned mentees (introducing new Pod Leader).
• Generate new recurring Google Meet links using the Zapier Google Calendar Integration (native Zapier action):
  • Zapier natively creates the recurring calendar event.
  • Zapier dynamically injects the generated Google Meet link directly into the email payload.
  • Auto-invite notetaker@stacktrading.com via the Master Calendar.
• No custom Google Calendar API scripts in Middleware — this step is handled entirely by Zapier's native Google Calendar integration to avoid custom middleware code.

(Source: Zapier Integration V7.pdf §Flow 15C Action 4 lines 2065–2067; Client confirmation 2026-09-20 — "Handle this entirely via the Zapier Google Calendar Integration")

Step 5. Delete / Suspend Google Workspace Account

• Execute Google Workspace account termination via Google Admin Directory API based on Role_Flag:

  Regular Pod Leader (Role_Flag != 'Founding_Mentor'):

  • Call DELETE /admin/directory/v1/users/{google_workspace_email} to permanently delete the @stacktrading.com account.

  Founding Mentor (Role_Flag = 'Founding_Mentor'):

  • Hard Breach only (automated): Workspace account is preserved. Administrative Bypass protects the Founding Mentor's Workspace and carry even if their personal trading account breaches.
  • BPS Admin manual termination (POST /api/bps/mentor/terminate): Workspace account is suspended (PUT with suspended: true) or deleted, depending on admin instruction.

• If google_workspace_email IS NULL (leader never had Workspace provisioned): skip Step 5 as a no-op.

(Source: Client confirmation 2026-09-28 — Flow 15C Step 2; Flow 1.5 Administrative Bypass rule)

---

6. Middleware Pre-Webhook Actions (Executed by BPS, NOT by Zapier)

The following actions are executed by Middleware synchronously when POST /api/bps/mentor/terminate is called, before the Zapier webhook fires. Zapier does not re-execute these steps:

---

7. Alternative Flows

Alt-1 — No available Pod Leader for re-matched mentee (Step 3):

• All Pod Leaders at Max_Capacity = 7.
• Mentee placed on FIFO Pod_Waitlist; Pod_Waitlist_Notification email sent.
• Mentee re-enters matching queue when Current_Count decreases (Flow 11).

---

8. Exceptional Flows

Exc-1 — discord_user_id is NULL when Discord action called:

• Middleware logs warning code DISCORD_USER_NOT_LINKED, bypasses the Discord API call, and returns 200 OK.
• Cascade continues. Flow does not crash.
• Applies to both POST /archive-pod-channel and POST /discord/revoke-all-roles.
• (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Manage Discord Role / §Revoke All Roles lines 2308–2322; Client supplement 2026-10-05 — §3.8B Failsafe)

Exc-2 — POST /archive-pod-channel fails (Step 1):

• Internal Retry: Middleware retries max 3× with Exponential Backoff on HTTP 429, HTTP 404, or Timeout.
• After 3 failures:
  • Log entry written to bps_audit_logs with severity = WARN.
  • channel_url set to NULL in Pod_Leader_Registry (Table E) — pod state cleared regardless of Discord outcome.
  • Slack alert to #dev_ops: "⚠️ WARNING: Failed to archive Discord channel for Pod Leader [Leader_ID]. Manual cleanup required."
  • Middleware returns HTTP 200 OK: { "status": "success", "channel_archived": false, "warning": "Discord API timeout, logged for manual cleanup" }.
• Zapier behavior: Receives 200 OK → continues non-blocking to Step 2 (identify mentees).

(Source: Client confirmation 2026-09-18)

Exc-3 — Google Workspace account action fails (Step 5):

• Non-blocking — Workspace deletion/suspension failure MUST NOT halt the cascade.
• On failure: Log error code WORKSPACE_DELETION_FAILED with full stack trace → fire SEV-2 alert to Slack #ops-it → push deletion job to async retry queue (or Ops deletes manually via Google Admin Console) → cascade continues.
• Window Gap Hazard: Leader retains @stacktrading.com email access until Ops resolves. Risk is low — leader has already been stripped of Discord roles, BPS/Dashboard access, and pod channel. Workspace is isolated from all Mentee data and trading activity by this point.
• (Source: Client supplement 2026-10-06 — Q9 Fault Tolerance confirmation)

Exc-4 — Google Meet link generation fails (Step 4):

• Non-blocking — Meet link failure MUST NOT block mentee notification emails.
• On failure: Send Pod_Reassigned_Notification email with new Pod Leader details and note "Your Google Meet link will be updated on your calendar shortly" → place Meet link creation job in exponential backoff retry queue → Ops notified if retries exhausted.
• (Source: Client supplement 2026-10-06 — Q9 Fault Tolerance confirmation)

---

9. Business Rules

BR_8.2.11.1: BPS Endpoint Executes Middleware Steps Before Webhook

The POST /api/bps/mentor/terminate endpoint is not a pure Zapier trigger. It executes Middleware-level actions (role revocation, registry update, carry zeroing, audit log) synchronously and only fires the Zapier webhook as the final step. Zapier's responsibility begins at Step 1 of this UC — Discord channel archiving and mentee dispersal.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Terminate Pod Leadership lines 3004–3023)

BR_8.2.11.2: Carry Balance Forfeiture is Immediate and Irreversible

When POST /api/bps/mentor/terminate is called, Pending_Carry_Balance is immediately zeroed in the DB ledger. Unvested carry tranches are forfeited to Stack General Account. There is no grace period or partial vesting on termination.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Terminate Pod Leadership lines 3009–3012)

BR_8.2.11.3: Discord Resiliency — NULL discord_user_id

All Discord-facing Middleware endpoints must return 200 OK when discord_user_id IS NULL, dropping the action silently. This prevents Zapier automation from crashing when the leader has not linked their Discord account.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Revoke All Roles lines 2316–2322)

BR_8.2.11.4: notetaker@stacktrading.com Auto-Invited to Google Meet

New recurring Google Meet links generated in Step 4 must auto-invite notetaker@stacktrading.com via the Master Calendar. This is consistent with the pattern established in Flow 10.1B (Induction Sync scheduling).

(Source: Zapier Integration V7.pdf §Flow 10.1B line 1861; §Flow 15C Action 4 line 2067)

BR_8.2.11.5: BPS Audit Log Mandatory

All termination actions must generate a BPS_Audit_Log entry with admin_id, reason, action, and timestamp. Written by Middleware at the BPS endpoint level, before Zapier webhook fires.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Terminate Pod Leadership line 3015; §BPS Audit Log lines 2724–2761)

BR_8.2.11.6: Full Digital Eviction — Mandatory for All Flow 15C Terminations

Flow 15C is exclusively a Termination flow. Step 1 MUST call both POST /archive-pod-channel AND POST /discord/revoke-all-roles. Unlike Flow 15 (UC_8.2.9) which branches on Suspension vs. Termination, Flow 15C never handles Suspension — the Full Digital Eviction (all Title + Pod + Special roles stripped) is always required here.

The terminated leader's Discord account is NOT automatically removed from the server. Manual kick/ban by Admin is required for misconduct cases.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Revoke All Roles lines 2308–2322; Client supplement 2026-10-05 — §3.8A)

BR_8.2.11.7: Mentee Discord Re-Sync on Reassignment

For each mentee successfully re-assigned in Step 3, Discord access must be updated: old pod channel access revoked, new pod channel access granted, Mentee roles synced for the new pod. This re-sync is part of the Step 3 execution, not a deferred or optional step.

(Source: Client supplement 2026-10-05 — §3.8C Re-Sync for Dispersed Mentees)

BR_8.2.11.8: Non-Blocking Execution — External SaaS Failures Must Not Halt Core Offboarding

Failures in external SaaS API calls (Google Workspace Admin Directory API, Google Calendar API) MUST NOT block execution of core offboarding steps. The primary indicator of termination is Pod_Leader_Registry.Pod_Status = 'Terminated' in PostgreSQL, which takes immediate effect regardless of third-party API completion states.

Core tasks (DB state update, Flow 10 Mentee re-assignment, Discord eviction) are transactional and must succeed. Secondary tasks (Workspace deletion, Meet link generation) run in isolated Try-Catch blocks — on failure, they log, alert, and enqueue for async retry without throwing or aborting the cascade.

(Source: Client supplement 2026-10-06 — Q9 Fault Tolerance — "Resilient Offboarding & Core First" principle)

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §BPS Endpoints; §Archive Pod Channel; §Manage Discord Role)

---

11. Acceptance Criteria

---

12. Changelog