Bản dịch: UC_8.2.9 → UC_8.2.13

Tổng hợp bản dịch tiếng Việt cho 5 use case thuộc nhóm UC_8.2.x. File gốc tiếng Anh không bị thay đổi. Mọi mã UC, field name, API endpoint, business rule ID, status value giữ nguyên tiếng Anh. Cập nhật 2026-11-05: đồng bộ theo bản tiếng Anh hiện tại và QnA khách trả lời mới nhất (POD-XF-15…18, BG-008) — UC_8.2.9 (v1.6), UC_8.2.10 (v1.9), UC_8.2.11 (v1.4), UC_8.2.12 (v1.7), UC_8.2.13 (v2.9); bỏ nhãn "Table E", dùng Pod_Leader_Registry.

---

UC_8.2.9 — Luồng 15: Phân công lại Pod & Quản lý

Các Trigger

Luồng 15 có ba đường trigger độc lập. Mỗi đường loại trừ nhau ở điểm vào; tất cả hội tụ ở các bước đồng bộ Discord và cập nhật registry.

Phạm vi release (Xác nhận client 2026-10-30) — xem BR_8.2.9.11:

Điều kiện tiên quyết

Hậu điều kiện

Luồng cơ bản

Trigger A — Thay đổi trạng thái lãnh đạo (Cascade tự động)

Bước A-1. Phát hiện thay đổi trạng thái

• Zapier bắt sự kiện thay đổi trạng thái trên Pod_Leader_Registry khi Pod_Status IN ('Suspended', 'Terminated').
• Sự kiện này kích hoạt từ ba nguồn:
  • BPS Admin thủ công — Admin đặt Pod_Status trực tiếp qua BPS.
  • Webhook POD_LEADER_TERMINATED từ Flow 7 — Flow 7 (UC_9.10 — Pod Impact & Dispersal) kích hoạt webhook này ở Condition B (leader bị terminated giữa chu kỳ). Khi nhận, Middleware tự động thực thi UPDATE Pod_Leader_Registry SET Pod_Status = 'Terminated' trước khi khởi động cascade phân công lại. (Source: CR-20260818-001)
  • Luồng Flow 4B Defense — Khi Flow 4B (Drawdown Defense Re-Activation) kích hoạt và phát hiện Users.is_pod_leader == True: (1) tài khoản vào 48h Defense freeze (bị khóa ngay lập tức); (2) sau freeze, Middleware đặt Pod_Leader_Registry.Status = 'Suspended'; (3) Users.stagnation_deadline = Today + 60 Days (bộ đếm Performance Improvement Plan — theo CR-64); (4) pod bị giải thể và cascade Trigger A này thực thi. Trader bị cấm tham gia mọi hoạt động pod trong suốt 60 ngày PIP. Đường tái kích hoạt sau khi vượt qua PIP: Flow 15B (UC_8.2.10). (Source: CR-64)
• Truy vấn: Tìm tất cả mentee đang hoạt động có Pod_Leader_ID = [Failed_Leader_ID].

Bước A-2. Phân công lại mentee

• Lặp qua danh sách mentee → chạy Flow 10 Matching Script (Python) đối chiếu với Pod_Leader_Registry cho từng mentee.
• Waterfall tiêu chí (theo Flow 10): 1. Asset Match (Nghiêm ngặt) → 2. Style Match → 3. Fallback: Lowest Current_Count.
• Nếu tìm được: gán trong DB, tăng Current_Count của leader mới.
• Nếu không có (tất cả leader đạt Max_Capacity = 7): đặt Pod_Status = 'Pod_Waitlist' cho mentee.

Bước A-3. Đặt trạng thái lãnh đạo

• Pod_Status = 'Acting_Cover' nếu lý do trigger = Suspended (tạm thời).
• Pod_Status = 'Reassigned' nếu lý do trigger = Terminated (vĩnh viễn).

Bước A-4. Thao tác Discord (Archive-First Pattern)

Để tránh race condition và tương tác "mồ côi" trong các kênh pod đang hoạt động, các lời gọi PHẢI tuân theo trình tự archive-first.

• Bước A-4.1 — Lưu trữ kênh (luôn thực hiện trước tiên):

  • Gọi POST /archive-pod-channel với pod_leader_id: [Failed_Leader_ID].
  • Bot lập tức thu hồi quyền đọc/ghi của tất cả thành viên pod (leader + tất cả mentee), đổi tên kênh từ pod-[leader_name] thành archived-pod-[leader_name], xóa channel_url trong Pod_Leader_Registry.
  • Lý do: kênh bị đóng băng đồng thời với mọi người trước khi có bất kỳ thay đổi role nào, loại bỏ khoảng thời gian kênh vẫn hoạt động nhưng không có leader.

• Bước A-4.2 — Thu hồi role Leader:

  • Gọi POST /manage-discord-role với action: "REMOVE", role_name: "Pod Leader", user_id: [Failed_Leader_ID].

• Bước A-4.3 — Full Digital Eviction (chỉ khi Termination — Trigger A qua Flow 7 hoặc Flow 15C):

  • Gọi POST /discord/revoke-all-roles để gỡ toàn bộ Title Roles (Associate / Trader / Senior), Pod Roles, và Special Roles khỏi tài khoản của leader bị terminated.
  • Tài khoản người dùng vẫn ở lại server với tư cách thành viên thông thường/chưa xác minh — KHÔNG bị kick hay ban trừ khi Admin thực hiện thêm thao tác thủ công.
  • Bước này bị bỏ qua khi Suspension; chỉ áp dụng A-4.1 + A-4.2.

• Bước A-4.4 — Đồng bộ lại cho Mentee (sau khi Flow 10 phân công lại ở Bước A-2):

  • Với mỗi mentee được phân công lại cho Pod Leader mới: thu hồi quyền truy cập kênh pod cũ (đã được lưu trữ), cấp quyền truy cập kênh pod mới, đồng bộ các role Mentee cho pod mới.
  • Gọi POST /manage-discord-role cho từng mentee để cấp quyền truy cập kênh pod mới.

Bước A-5. Thông báo

• Gửi email Pod_Reassigned_Notification đến từng mentee được phân công lại ("Gặp gỡ mentor mới của bạn").

Bước A-6. Thanh lý số dư Carry (chỉ khi Termination)

• NẾU lý do trigger = Terminated: Thanh lý Pending_Carry_Balance → Stack General Account (mất trắng). Đặt Pending_Carry_Balance = $0.00.

---

Trigger B — BPS Admin ghi đè thủ công

Bước B-1. Nhận Webhook

• Zapier bắt webhook từ Middleware POST /admin-pod-reassignment.
• Payload bắt buộc: user_id, new_pod_id (nullable — null = xóa khỏi pod mà không phân công lại), admin_id, reason, transcript_url, request_id (UUID — bắt buộc để đảm bảo idempotency).
• Trường payload tùy chọn: force_override (boolean, mặc định false) — khi true, bỏ qua kiểm tra cooldown 30 ngày.
• Nếu thiếu trường bắt buộc → Middleware trả 400 Bad Request trước khi webhook kích hoạt. Zapier không bao giờ nhận payload bị lỗi.

Bước B-1.5. Kiểm tra Idempotency (Cổng chống trùng lặp)

• Middleware kiểm tra request_id trong Redis Cache (key: pod-reassign:{request_id}, TTL: 24h).
• Lần gọi đầu tiên (chưa có key): Lưu key vào Redis → tiếp tục Bước B-2.
• Lần gọi trùng lặp (key đã tồn tại — ví dụ: Zapier retry): Trả ngay 200 OK đã cache. Không ghi DB, không gọi Discord API, không gửi email. Luồng kết thúc tại đây.
• Lý do: cooldown 30 ngày bảo vệ trước ý định admin lặp lại qua nhiều ngày/tháng; idempotency key bảo vệ trước các lần Zapier retry do network timeout trong cùng một khoảng thời gian thao tác.

(Nguồn: Bổ sung client 2026-10-06 — Q20(a) cơ chế chống trùng lặp Trigger B)

Bước B-2. Kiểm tra Cooldown

• Middleware truy vấn pod_reassignment_date cho user_id.
• NẾU force_override = true → bỏ qua cooldown; tiếp tục. Middleware phải ghi override vào BPS_Audit_Log và kích hoạt Slack alert tự động đến kênh Operations #ops-it, bao gồm admin_id, reason, transcript_url, và cờ override.
• NẾU force_override = false (hoặc vắng mặt) VÀ lần chuyển cuối < 30 ngày → trả 429 Too Many Requests (Cooldown Active). Luồng kết thúc.
• NẾU NULL hoặc ≥ 30 ngày → tiếp tục.

Bước B-3. Đồng bộ Discord

• Gọi Discord Bot API: Xóa role của old_pod_id. Gán role của new_pod_id (bỏ qua nếu new_pod_id là null).

Bước B-4. Cập nhật Registry

• Cập nhật pod_leader_id trong bảng Users. Đặt pod_reassignment_date = Today. Cập nhật Current_Count của cả Pod Leader cũ và mới trong Pod_Leader_Registry để duy trì theo dõi năng lực chính xác.

Bước B-5. Thông báo

• Gửi email Pod_Reassigned_Notification đến trader. Gửi Slack alert đến Pod Leader cũ và mới.

---

Trigger C — Leader mất điều kiện tham gia

Bước C-1. Nhận cờ

• BPS Admin gọi POST /api/bps/mentor/revoke để đánh dấu leader mất điều kiện tham gia vĩnh viễn.
• Middleware thực thi: UPDATE Pod_Leader_Registry SET Status = 'Permanently_Ineligible'.

Bước C-2. Kích hoạt Webhook Offboarding

• Middleware kích hoạt sự kiện webhook POD_LEADER_TERMINATED đến Zapier.
• Điều này kích hoạt cùng Mentee Dispersal Cascade như Trigger A (đường Termination).

Bước C-3. Mentee Dispersal Cascade (kế thừa hành vi Flow 15A/15C)

• Truy vấn tất cả mentee đang hoạt động có pod_leader_id = [Ineligible_Leader_ID].
• Chạy lại Flow 10 Matching Engine cho từng mentee → gán cho leader đang hoạt động mới hoặc vào FIFO Waitlist.
• Discord offboarding (archive-first pattern):
  • Gọi POST /archive-pod-channel — kênh bị khóa và đổi tên thành archived-pod-[leader_name].
  • Gọi POST /manage-discord-role với action: "REMOVE", role_name: "Pod Leader".
• Số dư carry: tịch thu Pending_Carry_Balance = $0.00 về Stack General Account (xử lý giống Termination).
• Gửi email Pod_Reassigned_Notification đến từng mentee bị ảnh hưởng.

Bước C-4. Loại trừ vĩnh viễn trong tương lai

• Matching Flow 10 lọc theo Status = 'Active' AND Current_Count < Max_Capacity. Bản ghi Permanently_Ineligible tự động bị loại khỏi tất cả các chu kỳ matching trong tương lai.

Luồng thay thế

Alt-1 — Không có Pod Leader nào có thể nhận mentee được phân công lại:

• Flow 10 không trả kết quả (tất cả leader đạt Max_Capacity = 7).
• Mentee vào hàng đợi FIFO Pod_Waitlist. Email Pod_Waitlist_Notification được gửi.
• Đóng băng SLA Plan_Due: Khi mentee vào Pod_Waitlist, mốc thời gian Plan_Due (thời hạn nộp kế hoạch giao dịch 72 giờ) bị tạm dừng. Đồng hồ 72 giờ reset và chỉ bắt đầu chạy lại sau khi hệ thống ghép thành công mentee với Pod Leader mới. Mentee không thể nộp kế hoạch giao dịch khi chưa có mentor được phân công.
• Mentee quay lại hàng đợi matching khi Current_Count giảm (trigger Flow 11).

Alt-2 — Pod Leader bị suspended (không phải terminated) — xử lý Pending_Carry_Balance:

• Pending_Carry_Balance bị đóng băng (tạm giữ) — KHÔNG bị tịch thu. Số dư được giữ nguyên trong database.
• Vesting tiếp tục khi trạng thái leader trở về Active.
• Tịch thu vào Stack General Account chỉ áp dụng khi Termination vĩnh viễn (Bước A-6).

Alt-3 — Suspension do Defense: tái kích hoạt sau PIP:

• Sau khi Flow 4B đặt Pod_Leader_Registry.Status = 'Suspended', trader vào giai đoạn PIP 60 ngày (stagnation_deadline = Today + 60 Days theo CR-64).
• Trong PIP: Pending_Carry_Balance bị đóng băng (BR_8.2.9.3), trader không đủ điều kiện tham gia mọi hoạt động pod (không thể đăng ký hoặc được ghép là Pod Leader).
• Nếu trader vượt qua PIP: tái kích hoạt theo Flow 15B (UC_8.2.10) — Pod Leader Opt-In & Provisioning. stagnation_deadline reset về Today + 90 Days khi tái kích hoạt.
• Nếu trader trượt PIP (bị terminated): Pending_Carry_Balance bị tịch thu theo BR_8.2.9.3.

Luồng ngoại lệ

Exc-1 — discord_user_id là NULL khi gọi POST /manage-discord-role:

• Middleware ghi log mã cảnh báo DISCORD_USER_NOT_LINKED, bỏ qua lời gọi Discord API và trả 200 OK cho Zapier.
• Tự động hóa Zapier KHÔNG bị crash. Cập nhật DB và registry diễn ra bình thường.

Exc-2 — POST /archive-pod-channel thất bại:

• Thử lại nội bộ: Middleware thử lại tối đa 3× với Exponential Backoff khi gặp HTTP 429, HTTP 404, hoặc Timeout.
• Sau 3 lần thất bại: Ghi log vào bps_audit_logs với severity = WARN. Đặt channel_url = NULL trong Pod_Leader_Registry — trạng thái pod được xóa bất kể kết quả Discord. Slack alert đến #dev_ops. Middleware trả HTTP 200 OK với thông tin cảnh báo.
• Hành vi Zapier: Nhận 200 OK → tiếp tục không chặn sang bước tiếp theo (phân công lại mentee).

Exc-3 — Payload Trigger B thiếu trường bắt buộc:

• Middleware validate trước khi kích hoạt webhook. Trả 400 Bad Request. Zapier flow không được kích hoạt. Bản ghi audit log được ghi bởi Middleware.

Đặc tả Quản lý Truy cập & Role Discord

Phần này tổng hợp toàn bộ đặc tả tích hợp Discord cho Flow 15A (phân công lại) và Flow 15C (offboarding). Đây là tham chiếu chính thức cho tất cả lời gọi Discord API được kích hoạt bởi thay đổi trạng thái Pod Leader.

A. Hành động Offboarding cho Leader bị Terminated / Suspended

Các bước chi tiết:

1. Thu hồi role Leader: Gọi POST /manage-discord-role với action: "REMOVE", role_name: "Pod Leader".
2. Lưu trữ kênh Pod: Gọi POST /archive-pod-channel:
   • Xóa quyền đọc/ghi của tất cả thành viên pod cũ.
   • Đổi tên kênh từ pod-[leader_name] thành archived-pod-[leader_name].
   • Xóa channel_url trong Pod_Leader_Registry.
3. Full Digital Eviction — chỉ khi Termination: Gọi POST /discord/revoke-all-roles để gỡ toàn bộ Title Roles (Associate / Trader / Senior), Pod Roles, và Special Roles. Tài khoản người dùng vẫn ở lại server với tư cách thành viên thông thường/chưa xác minh với quyền truy cập bị hạn chế. Việc kick/ban do vi phạm phải được Admin thực hiện thủ công — không tự động hóa.

B. Failsafe — discord_user_id là NULL

Nếu discord_user_id IS NULL trong bảng Users khi bất kỳ lời gọi Discord API nào được thực hiện, Middleware PHẢI:

• Ghi log mã cảnh báo DISCORD_USER_NOT_LINKED.
• Bỏ qua hoàn toàn lời gọi API.
• Trả HTTP 200 OK để bảo toàn tính toàn vẹn của luồng thực thi.

Luồng không được crash hay dừng lại do thiếu liên kết Discord.

C. Đồng bộ lại cho Mentee bị phân tán

Khi phân công lại thành công cho Pod Leader mới (qua Flow 10):

• Thu hồi quyền truy cập của Mentee vào kênh Discord old_pod_id.
• Cấp quyền truy cập kênh Discord new_pod_id.
• Đồng bộ các role Mentee liên quan cho pod mới.

(Nguồn: Bổ sung client 2026-10-05 — §3.8 Discord Access & Role Management Specification)

Quy tắc nghiệp vụ

BR_8.2.9.1: Waterfall Matching — Asset Match là bắt buộc (Strict) Khi phân công lại mentee qua logic matching Flow 10, Asset Class (Futures vs. Forex) là bộ lọc cứng — không phải ưu tiên. Trader Futures không thể được gán cho Pod Leader Forex bất kể năng lực.

BR_8.2.9.2: Cooldown — Giới hạn chuyển 30 ngày mỗi trader (Trigger B) + Break-glass Force Override Admin manual re-assignment qua POST /admin-pod-reassignment bị giới hạn cooldown 30 ngày mỗi user_id. Nếu pod_reassignment_date trong 30 ngày, Middleware trả 429 Too Many Requests. Break-glass override: Admin có thể truyền force_override = true để bỏ qua cooldown. Khi cờ này được đặt, Middleware phải: (1) bỏ qua kiểm tra cooldown; (2) ghi bản ghi BPS_Audit_Log bắt buộc đánh dấu override; (3) kích hoạt Slack alert tự động đến kênh Operations với admin_id, reason, transcript_url, và cờ override. Cooldown không áp dụng cho Trigger A (tự động theo hệ thống) hay Trigger C (cờ điều kiện tham gia).

BR_8.2.9.3: Số dư Carry — Đóng băng khi Suspension, Tịch thu khi Termination

• Suspension: Pending_Carry_Balance bị đóng băng (tạm giữ) — KHÔNG tịch thu. Vesting tiếp tục khi Pod_Leader_Status trở về Active.
• Termination: Pending_Carry_Balance lập tức bị thanh lý về Stack General Account và reset về $0.00. Không có thời gian ân hạn hay vesting từng phần.

BR_8.2.9.4: Loại bỏ Permanently_Ineligible khỏi Matching Bản ghi Pod_Leader_Registry với Status = 'Permanently_Ineligible' phải bị loại khỏi tất cả truy vấn matching Flow 10. Đây là cờ vĩnh viễn, không thể đảo ngược từ góc nhìn của thuật toán matching.

BR_8.2.9.5: BPS Audit Log bắt buộc cho thao tác Admin Tất cả thao tác Trigger B phải ghi admin_id, reason, và transcript_url vào bảng BPS_Audit_Log. Thao tác không có audit trail đầy đủ là không tuân thủ.

BR_8.2.9.6: Discord Resiliency — NULL user_id không được crash luồng POST /manage-discord-role phải trả 200 OK khi discord_user_id IS NULL trong database PostgreSQL. Middleware Node.js bỏ qua thao tác Discord im lặng. Điều này ngăn tự động hóa Zapier bị crash khi trader chưa liên kết tài khoản Discord.

BR_8.2.9.7: Plan_Due SLA bị đóng băng trong thời gian Pod_Waitlist Khi mentee được đặt vào Pod_Waitlist (không có Pod Leader nào có thể nhận tại thời điểm phân công lại), mốc thời gian Plan_Due (SLA nộp kế hoạch giao dịch 72 giờ) phải bị tạm dừng trong database. Đồng hồ 72 giờ không chạy khi mentee chưa có mentor được phân công. Đồng hồ reset và tiếp tục chỉ sau khi hệ thống ghép thành công mentee với Pod Leader mới.

BR_8.2.9.8: Full Digital Eviction — Chỉ khi Termination Khi Pod Leader bị terminated vĩnh viễn (qua Flow 7 / Flow 15C), Middleware PHẢI gọi POST /discord/revoke-all-roles để gỡ toàn bộ Discord role (Title Roles: Associate / Trader / Senior; Pod Roles; Special Roles), bên cạnh các lời gọi tiêu chuẩn POST /manage-discord-role REMOVE "Pod Leader" và POST /archive-pod-channel. Trình tự ba lời gọi này chỉ dành riêng cho Termination. Suspension chỉ kích hoạt hai lời gọi đầu (xóa role + lưu trữ kênh) — POST /discord/revoke-all-roles bị bỏ qua với leader bị suspended. Tài khoản Discord của người dùng bị terminated KHÔNG tự động bị kick hay ban khỏi server. Người dùng giữ tư cách thành viên thông thường/chưa xác minh. Việc kick hoặc ban yêu cầu Admin thao tác thủ công.

(Nguồn: Bổ sung client 2026-10-05 — §3.8A Full Digital Eviction)

BR_8.2.9.9: Đồng bộ lại Discord cho Mentee khi phân công lại Khi Mentee được phân công lại thành công cho Pod Leader mới qua Flow 10, việc đồng bộ Discord PHẢI: (1) thu hồi quyền truy cập của Mentee vào kênh Discord của pod cũ (old_pod_id); (2) cấp quyền truy cập kênh Discord của pod mới (new_pod_id); (3) đồng bộ các role Mentee liên quan cho pod mới. Việc đồng bộ lại này là một phần của trình tự chuyển giao Flow 15 → Flow 10, không phải bước thủ công riêng.

(Nguồn: Bổ sung client 2026-10-05 — §3.8C Re-Sync for Dispersed Mentees)

BR_8.2.9.10: Luồng Suspension Pod Leader do Defense

Khi Flow 4B (Drawdown Defense Re-Activation) kích hoạt và Users.is_pod_leader == True, trình tự sau là bắt buộc:

1. 48h Defense Freeze ngay lập tức: Tài khoản bị khóa. Không được phép thực hiện bất kỳ hoạt động giao dịch hay quản lý pod nào.
2. Ghi trạng thái Suspended: Sau 48h freeze, Middleware đặt Pod_Leader_Registry.Status = 'Suspended'.
3. Bộ đếm PIP: Users.stagnation_deadline = Today + 60 Days (vô điều kiện — theo CR-64). Trader không đủ điều kiện tham gia mọi hoạt động pod trong suốt 60 ngày PIP.
4. Giải thể Pod: Cascade Flow 15A Trigger A thực thi — pod bị giải thể, mentee được phân công lại qua Flow 10, Discord offboarding theo archive-first pattern.
5. Số dư Carry: Pending_Carry_Balance bị đóng băng (KHÔNG tịch thu) theo BR_8.2.9.3 — là Suspension, không phải Termination.
6. Tái kích hoạt: Nếu trader vượt qua PIP → Flow 15B (UC_8.2.10) tái cấp phép danh tính Pod Leader. Nếu trader trượt PIP (bị Terminated) → Pending_Carry_Balance bị tịch thu.

(Source: CR-64; user spec 2026-10-09 §3 — Drawdown Defense ↔ Pod Mentorship Engine closed-loop spec)

BR_8.2.9.11: Triển khai theo giai đoạn — Trigger A ở Phase 1; Trigger B & C ở Phase 2 (Release 2)

• Phase 1 (Go-Live): Chỉ Trigger A được triển khai — tự động giải thể Pod, ghép lại mentee qua Flow 10, và lưu trữ Discord role/channel.
• Phase 2 (Release 2): Trigger B (BPS Admin phân công lại mentee thủ công) và Trigger C (BPS Admin bật cờ Permanent Ineligibility thủ công) được hoãn sang Phase 2 cùng với đợt triển khai BPS Admin Portal. Nguồn (1) "BPS Admin thay đổi trạng thái thủ công" của Trigger A cũng chuyển từ backend script sang giao diện BPS Admin Portal ở Phase 2. Các AC của Trigger B/C (AC-8.2.9-04, -05, -06, -07, -09) thuộc phạm vi kiểm thử Phase 2.
• Ghi đè thủ công ở Phase 1: Các trường hợp ghi đè thủ công hiếm gặp được xử lý bằng backend script, không qua giao diện BPS Admin.
• Rào chắn carry đối với Trigger A: Pending_Carry_Balance chỉ bị tịch thu (đặt về $0.00) khi Pod Leader bị Terminated vĩnh viễn (Flow 7 Termination / Flow 15C). Khi Pod Leader bị Suspended tạm thời do Drawdown Defense (Flow 4B), Pod bị giải thể và mentee được phân công lại, nhưng Pending_Carry_Balance bị đóng băng — được giữ trong database cho đến khi leader vượt qua PIP và trở về Active — không bị tịch thu (BR_8.2.9.3).

(Nguồn: Xác nhận client 2026-10-30 — bao gồm rào chắn carry tại Stage 6 Pod Leader sheet Row 10)

Bảng trạng thái — Pod Leader qua chu kỳ Defense

(Source: user spec 2026-10-09 §5 — Defense ↔ Pod state machine)

Tiêu chí chấp nhận

---

UC_8.2.10 — Luồng 15B: Pod Leader Đăng ký & Cấp phép

Trigger

Sự kiện: Webhook nhận được từ nút nhấn đăng ký trong email Pod_Leader_Invite.

Email Pod_Leader_Invite được gửi phía trước bởi Flow 6 (L6 Transition / UC_8.1) khi New_Level của trader đạt Min_Pod_Leader_Level = 7 (lấy từ Table C: Global_Variables).

Ghi chú PostgreSQL-native: Pod_Leader_Registry ("Table E" trong tài liệu đặc tả Zapier gốc) được xây dựng native trên PostgreSQL làm nguồn dữ liệu chuẩn duy nhất — KHÔNG phải là Zapier Table live. Tên "Table E" chỉ được giữ lại trong các trích dẫn nguồn như một quy ước đặt tên/tham chiếu chéo đến mục RFQ gốc. (Nhắc lại POD-JOIN-02.)

Điều kiện tiên quyết

Hậu điều kiện

Luồng cơ bản

Bước 1. Nhận Webhook

• Zapier bắt webhook đăng ký từ nút trong email Pod_Leader_Invite.
• Đăng ký chỉ là một lần nhấn nút — không hiển thị form nào và không thu thập dữ liệu hồ sơ ở bước này. Trading_Style chỉ được thu thập bởi Typeform ở Bước 7.1; Asset_Class không bao giờ được chọn (kế thừa từ Users.asset_class ở Bước 2).
• Payload chứa: user_id, leader_name.

Bước 2. Chèn vào Pod_Leader_Registry

• Chèn bản ghi vào Pod_Leader_Registry (bảng PostgreSQL native) qua SQL SELECT-INSERT để kế thừa asset_class trực tiếp từ bảng Users:
  • Leader_ID = user_id
  • Leader_Name = leader_name
  • Asset_Class — kế thừa từ Users.asset_class (KHÔNG phải từ form nhập)
  • Trading_Style = NULL — chỉ được ghi ở Bước 7.1 (Typeform)
  • Is_Profile_Complete = FALSE
  • Status = 'Active'
  • Current_Count = 0
  • Pending_Carry_Balance = $0.00
  • Max_Capacity = 7 (từ Table C Pod_Max_Capacity)
  • google_workspace_email — được ghi tại đây sau khi Bước 3 hoàn tất (hoặc được cập nhật ở Bước 3)

Bước 3. Cấp phép tài khoản Google Workspace

• Gọi Google Workspace Admin Directory API:
  • Endpoint: POST /admin/directory/v1/users
  • Trường quan trọng: primaryEmail = [firstname].[lastname]@stacktrading.com, orgUnitPath: /Pod Leaders, changePasswordAtNextLogin: true
  • Định dạng handle: firstname.lastname@stacktrading.com (chữ thường, không dấu).
  • MFA cấp OU được áp dụng (Google Authenticator bắt buộc trước khi truy cập Workspace).
• Xử lý email collision (atomic loop): WHILE GET /users/{handle}@stacktrading.com → 200: thêm 1, 2, 3, ... cho đến khi tìm được địa chỉ duy nhất (ví dụ: john.doe1@stacktrading.com). Không dùng suffix user_id hay pattern khác.
• Khởi tạo Google Standard Invite Flow → link kích hoạt gửi đến user_email cá nhân; không có mật khẩu nào được tạo hoặc lưu trữ bởi Middleware.
• Ghi DB:
  • UPDATE Users SET google_workspace_email = '{handle}@stacktrading.com'
  • UPDATE Pod_Leader_Registry SET google_workspace_email = '{handle}@stacktrading.com'

Bước 4. Pod_Leader_Registry & Tự động cấp phép Discord — Tạo kênh Discord

• Gọi POST /create-pod-channel:
  • Input: user_id, leader_name
  • Middleware slug hóa tên kênh trước khi gọi Discord Bot:
    • Chuyển về chữ thường.
    • Thay khoảng trắng bằng dấu gạch ngang.
    • Bỏ toàn bộ dấu tiếng Việt và ký tự đặc biệt.
    • Để tránh trùng tên giữa các leader cùng tên: thêm 4 ký tự đầu của leader_id vào cuối slug. Ví dụ: pod-john-doe-a7b2.
  • Discord Bot tạo kênh text và voice riêng tư với tên đã slug hóa.
  • Đặt quyền cho các thành viên pod được phân công.
  • Quyền truy cập kênh của leader (quyền theo từng người dùng): NẾU discord_user_id IS NOT NULL của leader → Bot cấp cho leader quyền truy cập kênh ngay khi tạo. NẾU discord_user_id IS NULL → kênh vẫn được tạo; quyền truy cập của leader được cấp khi leader chạy /link (BR_8.2.10.11). Quyền truy cập không bao giờ được cấp qua role dùng chung Pod Leader.
  • Trả JSON: { "channel_id": "string", "channel_url": "URL_string" }
• Zapier chờ phản hồi JSON chứa channel_url.

Bước 5. Ghi channel_url vào hồ sơ người dùng

• Cập nhật bản ghi SQL của trader: ghi channel_url từ phản hồi Bước 4 vào hồ sơ trader.

Bước 6. Gán Discord Role

• Gọi POST /manage-discord-role: Input: user_id, add_role = 'Pod Leader'
• Nếu discord_user_id IS NULL → endpoint trả 200 OK và bỏ qua thao tác (BR_8.2.10.4). Role và quyền truy cập kênh được áp dụng khi leader chạy /link sau đó (BR_8.2.10.11).

Bước 7. Gửi email chào mừng

• Gửi email Pod_Leader_Welcome đến email cá nhân của trader (user_email — KHÔNG phải @stacktrading.com).
• Nội dung: bộ chào mừng bao gồm:
  • Handle tài khoản Google Workspace @stacktrading.com.
  • Link kích hoạt Google Workspace (từ Bước 3).
  • URL kênh Discord riêng tư (channel_url).
  • Link truy cập lịch.
  • Link Typeform bắt buộc để thiết lập hồ sơ Trading Style (xem Bước 7.1): https://form.stacktrading.com/mentor-profile-setup?leader_id={{user_id}}&email={{user_email}} (Hidden Fields được tự động chèn để nhận dạng người dùng tự động).

Bước 7.1. Đồng bộ hồ sơ Pod_Leader_Registry — Trading_Style (Typeform Webhook)

• Trigger: New Entry Submitted từ Typeform được liên kết ở Bước 7.
• Pod Leader khai báo:
  • Trading_Style — multi-select: Scalping, Day Trading, Swing Trading, Algorithmic Trading (bắt buộc)
  • Asset_Class — chỉ hiển thị để tham khảo (được điền sẵn từ Users.asset_class; read-only; Pod Leader không thể thay đổi)
• Webhook kích hoạt từ Typeform → Middleware (Zapier Flow 15B.1):

  UPDATE Pod_Leader_Registry
  SET
      Trading_Style       = '{{typeform.trading_style}}',
      Is_Profile_Complete = TRUE,
      Status              = 'Active',
      Updated_At          = NOW()
  WHERE Leader_ID = '{{typeform.leader_id}}';

• Lưu ý: Asset_Class KHÔNG được ghi từ Typeform — đã được kế thừa từ Users.asset_class khi chèn ở Bước 2.
• Ảnh hưởng đến Flow 10: Bản ghi Pod_Leader_Registry chỉ hiển thị với Mentee Matching Engine sau khi Is_Profile_Complete = TRUE được ghi. Cho đến khi Bước 7.1 hoàn tất, Pod Leader không được ghép với mentee.
• Trigger Flow 11 (Waitlist Processor): ngay sau khi Is_Profile_Complete = TRUE được ghi, Middleware kích hoạt Zap Flow 11: Waitlist Processor cho Leader_ID này để lấp các slot trống của pod mới từ Pod_Waitlist (FIFO, cùng Asset_Class). Chính sự kiện này — không phải thao tác chèn registry ở Bước 2 — là sự kiện "new leader" của UC_8.2.8 BR_8.2.8.1 #2.

Luồng ngoại lệ

Exc-1 — POST /create-pod-channel trả lỗi hoặc timeout:

• channel_url không được trả về. Bước 5 (ghi DB) và Bước 6 (Discord role) không thể tiến hành.
• Hành vi đã xác nhận (Option A — Retry + Alert): KHÔNG rollback bản ghi Pod_Leader_Registry đã chèn ở Bước 2. Middleware thử lại POST /create-pod-channel 3 lần với exponential backoff. Nếu tất cả retry thất bại → SEV-1 Slack alert đến #ops-it để Ops tạo kênh thủ công và cập nhật channel_url trong DB.
• Lý do: Flow 15B được trigger bởi nút nhấn trong email — không có UI dashboard đang hoạt động để hiển thị lỗi; rollback DB sẽ để trader trong trạng thái không thể phục hồi.
• (Nguồn: Xác nhận client 2026-10-07)

Exc-2 — Cấp phép Google Workspace thất bại (Bước 3):

• Hành vi đã xác nhận (Option A — Tiếp tục): Cho phép luồng tiếp tục các Bước 4–7 (tạo kênh Discord, gán Discord role, gửi email chào mừng đến email cá nhân). Ghi log WORKSPACE_PROVISIONING_FAILED + gửi SEV-2 alert đến #ops-it để Ops cấp phép Workspace thủ công sau.
• Sau khi Ops cấp phép Workspace thủ công, một log entry là đủ — Middleware không cần gửi email thứ hai. Ops kích hoạt email chào mừng Workspace gốc trực tiếp từ Google Admin console.
• (Nguồn: Xác nhận client 2026-10-07)

Exc-3 — discord_user_id là NULL khi gọi POST /manage-discord-role:

• Middleware bỏ qua thao tác Discord và trả 200 OK.
• Các thao tác ghi DB (Bước 2, 3, và 5) vẫn được commit. Email (Bước 7) vẫn được gửi.

Exc-4 — Đăng ký trùng lặp (trader nhấn nút hai lần):

• ⚠️ Hành vi idempotency chưa được chỉ định trong nguồn. Giả định BA: kiểm tra Pod_Leader_Registry xem đã có Leader_ID với Status = 'Active' chưa trước khi chèn; bỏ qua nếu đã tồn tại. Hành vi response (200 OK no-op vs 409 Conflict) chờ xác nhận dev.

Quy tắc nghiệp vụ

BR_8.2.10.1: Min_Pod_Leader_Level lấy từ Table C Ngưỡng đủ điều kiện đăng ký Pod Leader là Min_Pod_Leader_Level, đọc từ Table C: Global_Variables. Giá trị hiện tại = 7. Giá trị này không bao giờ được hardcode trong logic ứng dụng — luôn đọc từ Table C để cho phép cấu hình mà không cần deploy code.

BR_8.2.10.2: Đặt tên kênh Discord — Slug hóa + Phòng tránh trùng tên Tên kênh của mỗi Pod Leader phải được tạo bằng cách slug hóa leader_name:

1. Chuyển về chữ thường.
2. Thay khoảng trắng bằng dấu gạch ngang.
3. Bỏ toàn bộ dấu tiếng Việt và ký tự đặc biệt.
4. Thêm 4 ký tự đầu của leader_id để phòng tránh trùng tên khi hai leader có tên giống nhau (ví dụ: pod-john-doe-a7b2). Việc slug hóa phải được thực thi bởi Middleware trong POST /create-pod-channel trước khi gọi Discord Bot API.

BR_8.2.10.3: Current_Count phải phản ánh số lượng phân công thực tế Pod_Leader_Registry.Current_Count phải được tăng mỗi khi mentee được gán cho leader (qua Flow 10 Bước 4). Khi cấp phép (luồng này), Current_Count được khởi tạo là 0. Độ chính xác của trường này rất quan trọng cho logic fallback năng lực của waterfall matching Flow 10.

BR_8.2.10.4: Discord Resiliency — NULL discord_user_id POST /manage-discord-role phải trả 200 OK khi discord_user_id IS NULL. Luồng không được crash. Các thao tác ghi DB và gửi email diễn ra bất kể.

BR_8.2.10.5: Asset Class phải khớp 100% — Không cho phép Pod Leadership chéo loại tài sản Asset_Class của Pod Leader (Futures hoặc Forex) phải khớp chính xác với loại tài sản của tất cả mentee được gán vào pod. Trader Forex không thể là Pod Leader cho trader Futures, và ngược lại. Tiêu chí matching Flow 10 áp dụng "Asset Match (Strict)" như cổng lọc đầu tiên — năng lực và phong cách chỉ được xem xét sau khi asset class đã được xác nhận.

BR_8.2.10.6: Cấp phép Google Workspace — Regular Pod Leaders Mỗi Regular Pod Leader được cấp phép qua Flow 15B PHẢI nhận tài khoản Google Workspace @stacktrading.com. Tài khoản được tạo dưới orgUnitPath = /Pod Leaders. Chính sách cấp OU áp dụng MFA (Google Authenticator) trước khi bất kỳ truy cập Workspace nào được cấp — Middleware không triển khai logic MFA trực tiếp.

• Định dạng handle: firstname.lastname@stacktrading.com (chữ thường, không dấu).
• Xử lý collision: thêm chỉ số tuần tự (1, 2, ...) qua atomic loop (ví dụ: john.doe1@stacktrading.com).
• Link kích hoạt gửi đến user_email cá nhân qua Google Standard Invite Flow. Không có mật khẩu nào được tạo hoặc lưu trữ bởi Middleware.
• google_workspace_email được ghi vào cả bảng Users và Pod_Leader_Registry (bảng PostgreSQL native).

BR_8.2.10.7: Kế thừa Asset_Class — Regular Pod Leaders không được chọn lại Regular Pod Leaders (Level 7+) KHÔNG được nhắc chọn Asset_Class ở bất kỳ đâu trong luồng này. Asset_Class được tự động kế thừa từ Users.asset_class khi ghi vào DB (Bước 2) và được hiển thị read-only trên Typeform ở Bước 7.1. Điều này ngăn mismatch giữa loại tài sản giao dịch thực tế của trader và danh tính Pod của họ. Founding Mentors (Flow 1.5) được miễn trừ quy tắc này — họ có thể là nhân viên tuyển dụng bên ngoài không có bản ghi Users.asset_class và vì vậy PHẢI khai báo Asset_Class rõ ràng qua Typeform (UC_8.2.13 Bước 9).

BR_8.2.10.8: Đồng bộ Typeform Profile — Cần xác nhận Trading_Style trước khi Flow 10 Matching Mỗi Regular Pod Leader được cấp phép qua Flow 15B PHẢI hoàn thành thiết lập hồ sơ Typeform (Bước 7.1) trước khi hiển thị với Flow 10 Mentee Matching Engine. Is_Profile_Complete được khởi tạo là FALSE khi chèn ở Bước 2 và chỉ được đặt thành TRUE bởi webhook Typeform. Pod Leaders với Is_Profile_Complete = FALSE bị loại khỏi các truy vấn matching Flow 10. Asset_Class được hiển thị trong Typeform chỉ để tham khảo — read-only và được điền sẵn từ Users.asset_class. Pod Leader không thể thay đổi Asset_Class qua Typeform.

BR_8.2.10.9: Lỗi kênh Discord — Không rollback DB; Thử lại 3× rồi SEV-1 Nếu POST /create-pod-channel thất bại hoặc timeout, bản ghi Pod_Leader_Registry đã chèn ở Bước 2 KHÔNG ĐƯỢC rollback. Middleware thử lại với exponential backoff (3 lần). Nếu tất cả thất bại, kích hoạt SEV-1 alert đến #ops-it để Ops tạo kênh thủ công và cập nhật channel_url trong DB. Flow 15B được trigger bởi nút nhấn trong email — không có dashboard để hiển thị lỗi, rollback DB là ngõ cụt không phục hồi được. (Nguồn: Xác nhận client 2026-10-07)

BR_8.2.10.10: Lỗi Google Workspace — Không chặn; Cascade tiếp tục Nếu cấp phép Google Workspace thất bại ở Bước 3, luồng KHÔNG ĐƯỢC dừng lại. Các Bước 4–7 (kênh Discord, Discord role, email chào mừng) tiếp tục bình thường. Ops được thông báo qua SEV-2 alert đến #ops-it và cấp phép Workspace thủ công. Sau khi Ops cấp phép, Ops kích hoạt email chào mừng Workspace gốc từ Google Admin console — Middleware không gửi email thứ hai. (Nguồn: Xác nhận client 2026-10-07)

BR_8.2.10.11: Late-Linking — Role Pod Leader + Quyền truy cập kênh riêng khi /link Khi người dùng chạy /link và Pod_Leader_Registry có bản ghi với Leader_ID = user_id VÀ Status NOT IN ('Terminated', 'Permanently_Ineligible'), bot PHẢI (1) gán role Pod Leader và (2) cấp cho người dùng đó quyền truy cập theo từng người dùng vào kênh pod của chính họ (Users.channel_url). Quyền truy cập kênh pod không bao giờ được cấp qua role dùng chung Pod Leader, vì vậy leader không thể xem các pod khác. Cùng quy tắc với UC_8.2.13 BR_8.2.13.27 (Founding Mentors). Chạy cùng với đồng bộ level-title (UC_8.1.1) và đồng bộ Pod Member (UC_8.2.1 A-04). ⚠️ UC_8.1.1 (handler /link, BA owner Huyen Dinh) chưa được cập nhật nhánh này. (Nguồn: QnA_Level_Promotion §3.3 nguyên tắc late-linking, 2026-09-30; Quyết định BA 2026-10-30 — quyền truy cập kênh được cấp tại thời điểm link)

Tiêu chí chấp nhận

---

§7.1 Chính sách Nghỉ phép & Hiatus cho Regular Pod Leaders (Tích hợp Flow 13)

Tham chiếu chéo: UC_9.2 — Flow 13 (Time-Off Management) quản lý toàn bộ pipeline nghỉ phép. Phần này ghi lại các quy tắc đặc thù cho Pod Leader áp dụng khi Flow 13 xử lý yêu cầu nghỉ phép của Regular Pod Leader (Level 7+).

§7.1.1 Nghỉ phép không thu hồi role Pod Leader

Nghỉ phép hợp lệ được phê duyệt qua Flow 13 KHÔNG hủy role Pod Leader. BPS Admin KHÔNG ĐƯỢC kích hoạt thủ công POST /api/bps/mentor/terminate trong thời gian nghỉ phép đã phê duyệt.

Tất cả tài nguyên Pod được bảo toàn trong trạng thái On_Leave:

(Nguồn: QnA_STAGE6_POD_SYSTEM_FLOW10_11.md [POD-XF-15] client xác nhận 2026-10-30; [POD-XF-18] client sheet 2026-11-04)

§7.1.2 Ma trận trạng thái Pod_Leader_Registry

(Nguồn: QnA_STAGE6_POD_SYSTEM_FLOW10_11.md [POD-XF-16] client xác nhận 2026-10-30; [POD-XF-18] client sheet 2026-11-04)

§7.1.3 Hành vi số dư Carry trong thời gian nghỉ phép

Pending_Carry_Balance tiếp tục tích lũy và vesting bình thường trong thời gian nghỉ phép được phê duyệt. Lần chạy vest hàng tháng (Flow 17, ngày 1 hàng tháng) PHẢI bao gồm các bản ghi có Pod_Leader_Registry.Status = 'On_Leave' — không đóng băng, không bỏ qua. Carry chỉ bị đóng băng khi bị suspension do Drawdown Defense (UC_8.2.9 BR_8.2.9.3) hoặc bị tịch thu khi Termination (Flow 15C).

(Nguồn: QnA_STAGE6_POD_SYSTEM_FLOW10_11.md [POD-XF-18]; QnA_BACKGROUND_MECHANISMS_CRON.md [BG-008] — client sheet 2026-11-04)

---

UC_8.2.11 — Luồng 15C: Cascade Offboarding khi Pod Leader bị sa thải

Trigger

Sự kiện: Webhook POD_LEADER_TERMINATED được Zapier nhận, kích hoạt từ BPS Admin endpoint POST /api/bps/mentor/terminate.

BPS endpoint thực hiện các hành động phía server sau trước khi kích hoạt Zapier webhook:

1. Thu hồi Discord role 'Pod Leader' khỏi Global_User_ID của leader.
2. Đặt Pod_Leader_Registry.Status = 'Terminated'.
3. Xóa Pending_Carry_Balance trong DB ledger (các tranche chưa vested bị mất).
4. Ghi bản ghi vào BPS_Audit_Log (Admin ID, Action, Timestamp, Reason).
5. Kích hoạt webhook POD_LEADER_TERMINATED đến Zapier để thực hiện phân tán mentee và offboarding IT.

Điều kiện tiên quyết

Hậu điều kiện

Luồng cơ bản

Bước 1. Discord Offboarding

• Lưu trữ kênh Pod — Gọi POST /archive-pod-channel:
  • Input: pod_leader_id
  • Discord Bot định vị kênh gắn với pod_leader_id, xóa toàn bộ quyền truy cập của người dùng, đổi tên kênh thành archived-pod-[leader_name], xóa channel_url trong SQL Registry.
  • Trả: 200 OK.
• Full Digital Eviction — Gọi POST /discord/revoke-all-roles:
  • Input: user_id = [terminated_leader_id]
  • Gỡ toàn bộ Title Roles (Associate / Trader / Senior), Pod Roles, và Special Roles khỏi tài khoản Discord của leader bị sa thải.
  • Tài khoản Discord của leader vẫn ở lại server với tư cách thành viên thông thường/chưa xác minh — KHÔNG tự động bị kick hay ban. Trường hợp vi phạm cần Admin thao tác thủ công.
  • Trả: 200 OK.

Bước 2. Xác định Mentee đang hoạt động

• Truy vấn SQL database để tìm tất cả mentee đang hoạt động có pod_leader_id = [terminated_leader_id].

Bước 3. Phân công lại Mentee

• Thực hiện logic matching Flow 10 cho mỗi mentee:
  • Waterfall Tiêu chí: 1. Asset Match (Nghiêm ngặt) → 2. Style Match → 3. Fallback: Lowest Current_Count.
  • Nếu tìm được: gán cho Pod Leader mới trong DB; tăng Current_Count của leader mới.
  • Nếu không có (tất cả leader đạt Max_Capacity = 7): đặt mentee vào danh sách chờ FIFO.
• Đồng bộ lại Discord cho mỗi mentee được phân công lại thành công:
  • Thu hồi quyền truy cập của Mentee vào kênh Discord old_pod_id.
  • Cấp quyền truy cập kênh Discord new_pod_id.
  • Đồng bộ các role Mentee liên quan cho pod mới.

Bước 4. Thông báo Mentee + Tạo Google Meet Link

• Gửi email chào mừng mentor đến mentee được phân công lại thành công (giới thiệu Pod Leader mới).
• Tạo Google Meet link định kỳ mới sử dụng Zapier Google Calendar Integration (hành động Zapier gốc):
  • Zapier tạo sự kiện lịch định kỳ.
  • Zapier tự động chèn Google Meet link đã tạo vào payload email.
  • Tự động mời notetaker@stacktrading.com qua Master Calendar.
• Không có script Google Calendar API tùy chỉnh trong Middleware — bước này được xử lý hoàn toàn bởi tích hợp Zapier Google Calendar gốc để tránh code middleware tùy chỉnh.

Bước 5. Xóa / Tạm dừng tài khoản Google Workspace

• Thực hiện hành động trên tài khoản Google Workspace dựa trên Role_Flag:

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

  • Gọi DELETE /admin/directory/v1/users/{google_workspace_email} để xóa vĩnh viễn tài khoản @stacktrading.com.

  Founding Mentor (Role_Flag = 'Founding_Mentor'):

  • Chỉ Hard Breach tự động: Workspace được bảo toàn. Administrative Bypass bảo vệ Workspace và carry của Founding Mentor ngay cả khi tài khoản giao dịch cá nhân vi phạm.
  • BPS Admin terminate thủ công (POST /api/bps/mentor/terminate): Tài khoản Workspace bị tạm dừng (PUT với suspended: true) hoặc xóa, tùy theo hướng dẫn của admin.

• Nếu google_workspace_email IS NULL (leader chưa bao giờ được cấp phép Workspace): bỏ qua Bước 5 dưới dạng no-op.

Các hành động Middleware trước Webhook (Thực hiện bởi BPS, KHÔNG phải Zapier)

Luồng thay thế

Alt-1 — Không có Pod Leader nào có thể nhận mentee được phân công lại (Bước 3):

• Tất cả Pod Leader đạt Max_Capacity = 7.
• Mentee vào hàng đợi FIFO Pod_Waitlist; email Pod_Waitlist_Notification được gửi.
• Mentee quay lại hàng đợi matching khi Current_Count giảm (trigger Flow 11).

Luồng ngoại lệ

Exc-1 — discord_user_id là NULL khi thao tác Discord được gọi:

• Middleware ghi log mã cảnh báo DISCORD_USER_NOT_LINKED, bỏ qua lời gọi Discord API và trả 200 OK.
• Cascade tiếp tục. Luồng không bị crash.
• Áp dụng cho cả POST /archive-pod-channel và POST /discord/revoke-all-roles.

Exc-2 — POST /archive-pod-channel thất bại (Bước 1):

• Thử lại nội bộ: Middleware thử lại tối đa 3× với Exponential Backoff khi gặp HTTP 429, HTTP 404, hoặc Timeout.
• Sau 3 lần thất bại: Ghi log vào bps_audit_logs với severity = WARN. Đặt channel_url = NULL trong Pod_Leader_Registry. Slack alert đến #dev_ops. Middleware trả HTTP 200 OK không chặn.
• Hành vi Zapier: Nhận 200 OK → tiếp tục không chặn sang Bước 2 (xác định mentee).

Exc-3 — Thao tác trên tài khoản Google Workspace thất bại (Bước 5):

• Không chặn — lỗi xóa/tạm dừng Workspace KHÔNG ĐƯỢC dừng cascade.
• Khi thất bại: Ghi log mã lỗi WORKSPACE_DELETION_FAILED kèm đầy đủ stack trace → kích hoạt SEV-2 alert đến Slack #ops-it → đẩy job xóa vào hàng chờ retry async (hoặc Ops xóa thủ công qua Google Admin Console) → cascade tiếp tục.
• Rủi ro khoảng trống (Window Gap Hazard): Leader vẫn giữ quyền truy cập email @stacktrading.com cho đến khi Ops xử lý xong. Rủi ro thấp — tại thời điểm này leader đã bị gỡ Discord role, quyền truy cập BPS/Dashboard, và kênh pod. Workspace đã được cô lập khỏi toàn bộ dữ liệu Mentee và hoạt động giao dịch.

Exc-4 — Tạo Google Meet link thất bại (Bước 4):

• Không chặn — lỗi Meet link KHÔNG ĐƯỢC chặn email thông báo cho mentee.
• Khi thất bại: Gửi email Pod_Reassigned_Notification kèm thông tin Pod Leader mới và ghi chú "Your Google Meet link will be updated on your calendar shortly" → đưa job tạo Meet link vào hàng chờ retry exponential backoff → thông báo Ops nếu hết số lần retry.

Quy tắc nghiệp vụ

BR_8.2.11.1: BPS Endpoint thực hiện các bước Middleware trước Webhook Endpoint POST /api/bps/mentor/terminate không phải là trigger Zapier thuần túy. Nó thực hiện các hành động Middleware (thu hồi role, cập nhật registry, xóa carry, audit log) đồng bộ và chỉ kích hoạt Zapier webhook như bước cuối cùng. Trách nhiệm của Zapier bắt đầu từ Bước 1 của UC này — lưu trữ kênh Discord và phân tán mentee.

BR_8.2.11.2: Mất số dư Carry là ngay lập tức và không thể đảo ngược Khi POST /api/bps/mentor/terminate được gọi, Pending_Carry_Balance bị xóa ngay lập tức trong DB ledger. Các tranche carry chưa vested bị mất vào Stack General Account. Không có thời gian ân hạn hay vesting từng phần khi sa thải.

BR_8.2.11.3: Discord Resiliency — NULL discord_user_id Tất cả Middleware endpoint tương tác Discord phải trả 200 OK khi discord_user_id IS NULL, bỏ qua thao tác im lặng. Điều này ngăn tự động hóa Zapier bị crash khi leader chưa liên kết tài khoản Discord.

BR_8.2.11.4: notetaker@stacktrading.com được tự động mời vào Google Meet Các Google Meet link định kỳ mới được tạo ở Bước 4 phải tự động mời notetaker@stacktrading.com qua Master Calendar. Điều này nhất quán với pattern đã thiết lập trong Flow 10.1B (lên lịch Induction Sync).

BR_8.2.11.5: BPS Audit Log bắt buộc Tất cả thao tác sa thải phải tạo bản ghi BPS_Audit_Log với admin_id, reason, action, và timestamp. Ghi bởi Middleware ở cấp BPS endpoint, trước khi Zapier webhook kích hoạt.

BR_8.2.11.6: Full Digital Eviction — Bắt buộc cho mọi trường hợp sa thải qua Flow 15C Flow 15C chỉ là luồng Termination. Bước 1 PHẢI gọi cả POST /archive-pod-channel VÀ POST /discord/revoke-all-roles. Khác với Flow 15 (UC_8.2.9) có phân nhánh Suspension vs. Termination, Flow 15C không bao giờ xử lý Suspension — Full Digital Eviction (gỡ toàn bộ Title + Pod + Special roles) luôn bắt buộc tại đây. Tài khoản Discord của leader bị sa thải KHÔNG tự động bị xóa khỏi server. Việc kick/ban do vi phạm phải được Admin thực hiện thủ công.

BR_8.2.11.7: Đồng bộ lại Discord cho Mentee khi phân công lại Với mỗi mentee được phân công lại thành công ở Bước 3, quyền truy cập Discord phải được cập nhật: thu hồi quyền truy cập kênh pod cũ, cấp quyền truy cập kênh pod mới, đồng bộ các role Mentee cho pod mới. Việc đồng bộ lại này là một phần của quá trình thực thi Bước 3, không phải bước trì hoãn hay tùy chọn.

BR_8.2.11.8: Thực thi không chặn — Lỗi SaaS bên ngoài không được dừng offboarding cốt lõi Lỗi trong các lời gọi API SaaS bên ngoài (Google Workspace Admin Directory API, Google Calendar API) KHÔNG ĐƯỢC chặn việc thực thi các bước offboarding cốt lõi. Chỉ báo chính của việc sa thải là Pod_Leader_Registry.Pod_Status = 'Terminated' trong PostgreSQL, có hiệu lực ngay lập tức bất kể trạng thái hoàn tất của API bên thứ ba. Các tác vụ cốt lõi (cập nhật trạng thái DB, phân công lại Mentee qua Flow 10, Discord eviction) mang tính giao dịch và phải thành công. Các tác vụ phụ (xóa Workspace, tạo Meet link) chạy trong các khối Try-Catch cô lập — khi thất bại, chúng ghi log, gửi alert, và đưa vào hàng chờ retry async mà không throw lỗi hay hủy cascade.

Tiêu chí chấp nhận

---

UC_8.2.12 — Luồng 17: Chi trả Vesting cho Pod Leader

Trigger

Sự kiện: Lịch trình — hàng tháng, kích hoạt vào ngày 1 mỗi tháng (00:00:00 UTC).

Zapier chỉ là scheduler trong luồng này. Nó gọi một endpoint duy nhất và chờ phản hồi JSON. Toàn bộ logic batch thực thi bên trong Middleware.

Điều kiện tiên quyết

Hậu điều kiện

Luồng cơ bản

Bước 1. Lịch trình kích hoạt (Zapier)

• Trigger lịch trình hàng tháng kích hoạt lúc 00:00:00 UTC vào ngày 1 mỗi tháng. UTC là timezone duy nhất được sử dụng — không phụ thuộc timezone địa phương.
• Zapier gọi POST /process-pod-vesting với input: cycle_date = Today (Middleware xử lý thành ngày UTC ISO 8601).

Bước 2. Truy vấn Leader đủ điều kiện (Middleware)

• Middleware truy vấn Pod_Leader_Registry để tìm tất cả bản ghi có Pending_Carry_Balance > 0.
• Cổng trạng thái:
  • Status = 'Active': đủ điều kiện — tiếp tục định tuyến thanh toán.
  • Status = 'Suspended' (tạm dừng tạm thời, ví dụ Flow 4B Drawdown Defense): bỏ qua — số dư carry bị đóng băng (giữ trong database), không bị tịch thu và không được vest. Flow 17 không được thực hiện bất kỳ khoản thanh toán nào cho leader này. Vesting tiếp tục khi leader vượt qua PIP và trở về Status = 'Active'. (Xác nhận client 2026-10-30; tham chiếu chéo UC_8.2.9 BR_8.2.9.3 / BR_8.2.9.11)
  • Status = 'On_Leave' (nghỉ phép đã được duyệt, Flow 13): đủ điều kiện — xử lý như Active; carry tiếp tục tích lũy và vest trong thời gian nghỉ, tiếp tục định tuyến thanh toán. (Tham chiếu chéo: UC_8.2.10 §7.1.3; QnA_STAGE6_POD_SYSTEM_FLOW10_11.md [POD-XF-18] — client sheet 2026-11-04)
  • Status = 'Terminated' (bị sa thải qua Flow 7 / Flow 15C): không đủ điều kiện — carry chưa vested lập tức bị tịch thu. Đặt Pending_Carry_Balance = $0.00 cho các leader này mà không thực hiện thanh toán nào. Không gọi Dots hay Rippling.
• Ngưỡng Min_Payout_Threshold: Chỉ áp dụng cho leader đủ điều kiện (không phải Terminated). Nếu Pending_Carry_Balance < $100 (lấy từ Table C: Min_Payout_Threshold), leader bị loại khỏi chu kỳ hiện tại. Số dư của họ không bị xóa — nó được chuyển sang và tích lũy đến lần chạy tiếp theo khi đạt ngưỡng.

Bước 3. Định tuyến thanh toán mỗi Leader (Middleware — vòng lặp)

• Với mỗi leader đủ điều kiện, đánh giá billing_country, current_level, và compensation_track:
  • Đường A — Dots API: billing_country != 'US' (tất cả level) HOẶC billing_country == 'US' AND current_level < 6. Gọi POST /v2/payouts với payee_id, amount = Pending_Carry_Balance, memo = "Monthly Pod Leader Carry Vesting - [Month/Year]".
  • Đường B — Rippling Off-Cycle Payroll: billing_country == 'US' AND current_level >= 6 AND compensation_track IN ('Standard', 'Flex'). Gọi POST /api/v1/payroll/off-cycle-payruns với employee_id, earning_type = "DISCRETIONARY_BONUS", amount = Pending_Carry_Balance.
    • Vì sao dùng Off-Cycle (không phải payroll thường kỳ): Thưởng carry là khoản thưởng hiệu suất biến đổi được quyết toán vào ngày 1 hàng tháng, độc lập với lịch payroll W-2 cố định. Off-Cycle API chi trả ngay mà không cần chờ kỳ payroll thường kỳ tiếp theo.
    • Vì sao dùng DISCRETIONARY_BONUS: Carry được phân loại là US Supplemental Wages theo quy định của IRS. Rippling tự động áp dụng đúng mức khấu trừ thuế bổ sung — tách biệt với lương thường kỳ giúp tránh xử lý thuế W-2 sai cho nhân viên.

Bước 4. Ghi blockchain (Middleware — trong vòng lặp)

• Sau khi mỗi lời gọi API thanh toán hoàn tất:
  • Khởi tạo ví Ethers.js.
  • Gọi contract.recordMetric() với:
    • metric_category = "Pod Leader Vesting"
    • metric_value = "[Amount] USD Cleared"
    • receipt_hash = [Dots hoặc Rippling Transaction ID]

Bước 4a. QuickBooks Online Journal Entry (Middleware — trong vòng lặp, chỉ Đường A) — CHR-139

• Chỉ kích hoạt sau khi Dots API trả transaction ID thành công cho leader.
• Bút toán riêng lẻ — không gộp: đẩy một QuickBooks Journal Entry riêng cho mỗi Pod Leader / Founding Mentor trong vòng lặp. Không bao giờ gộp nhiều leader vào một Journal Entry.
• Chỉ Dots: áp dụng cho các khoản thanh toán định tuyến qua Đường A (International Contractors, và US 1099 Contractors / Founding Mentors không thuộc payroll W-2). Với Đường B (US Level 6+ W-2 qua Rippling Off-Cycle Payroll API), bỏ qua việc đẩy QuickBooks — Rippling tự đồng bộ payroll W-2 sang QuickBooks.
• Ánh xạ tài khoản (số tiền thanh toán tuyệt đối ở cả hai dòng):

(Nguồn: CHR-139; QuickBooks Integration Specification §4.B "Pod Leader Carry/Commission - Flow 17 - Contractors"; Xác nhận client 2026-10-30)

Bước 5. Xóa số dư (Middleware — trong vòng lặp)

• Đặt Pod_Leader_Registry.Pending_Carry_Balance = $0.00 cho leader đã được xử lý.
• Đặt Pod_Leader_Registry.last_vesting_payout_at = NOW().
• Ngăn thanh toán trùng lặp ở chu kỳ tiếp theo.

Bước 6. Trả JSON (Middleware → Zapier)

• Middleware trả JSON cho Zapier:

  {
    "processed_count": <int>,
    "processed_users": ["email@example.com", ...]
  }

• Zapier chờ phản hồi này trước khi tiếp tục.

Bước 7. Thông báo Ops (Zapier)

• Kích hoạt Slack alert đến #finance-ops (Head of Ops):
  • "Monthly Pod Vesting Complete: Processed [X] leaders, Total Paid: $[Y], Polygon Tx: [Hash]"

Bước 8. Thông báo Leader (Zapier)

• Gửi email Pod_Leader_Vesting_Paid đến mảng email trong processed_users.
• Nội dung: thông báo xác nhận các khoản carry đã được thanh toán vào kênh ngân hàng.

Tham chiếu tích lũy Carry (Cách Pending_Carry_Balance được tích lũy)

Carry được tích lũy bởi Middleware trong Flow 6 (Level Transition) — được kích hoạt bởi việc thăng level của mentee, không phải level của chính Pod Leader. Khi một Mentee (trader trong Pod) thăng lên level đủ điều kiện, hệ thống ghi có cho Pod Leader trực tiếp quản lý mentee đó như sự ghi nhận cho công tác coaching:

Carry tích lũy qua tất cả các sự kiện thăng cấp từ tất cả mentee trong pod của leader. Lần chạy thanh toán Flow 17 hàng tháng chi trả toàn bộ Pending_Carry_Balance đã tích lũy và reset về $0.00 sau mỗi chu kỳ.

Ví dụ: Nếu Pod Leader có 3 mentee và trong một tháng Mentee A đạt L3 (+$250) và Mentee B đạt L5 (+$500), Pending_Carry_Balance của leader tăng thêm $750 trước chu kỳ thanh toán tiếp theo.

Luồng ngoại lệ

Exc-1 — Không có leader nào có Pending_Carry_Balance > 0:

• Middleware trả { "processed_count": 0, "processed_users": [] }.
• Zapier gửi Slack alert: "Pod Vesting Complete. Processed 0 leaders."
• Không gửi email (mảng processed_users rỗng).

Exc-2 — Lời gọi Dots hoặc Rippling API thất bại cho một leader cụ thể:

• Leader thất bại bị bỏ qua cho chu kỳ hiện tại. Vòng lặp tiếp tục sang leader tiếp theo — một lỗi không dừng toàn bộ batch.
• Pending_Carry_Balance của leader thất bại KHÔNG bị xóa — được bảo toàn và sẽ được đưa vào lần chạy chu kỳ tiếp theo.
• Một lỗi được kích hoạt đến Slack #ops-treasury: cảnh báo bao gồm leader_id, số tiền, và lỗi API.
• Tất cả leader khác trong batch được xử lý bình thường.

Exc-3 — Lời gọi blockchain contract.recordMetric() thất bại SAU KHI thanh toán đã được gửi:

• KHÔNG đảo ngược khoản thanh toán. Giao dịch tiền pháp định là off-chain và đã được quyết toán qua Dots/Rippling. Pending_Carry_Balance vẫn được reset về $0.00 — khôi phục lại sẽ có nguy cơ thanh toán trùng lặp ở chu kỳ tiếp theo.
• Lưu bản ghi audit cục bộ vào PostgreSQL với Dots/Rippling Transaction ID; đặt trạng thái polygon_tx_hash là PENDING_BLOCKCHAIN_SYNC hoặc FAILED.
• Đưa payload log blockchain vào hàng chờ retry async với exponential backoff.
• Gửi Slack alert đến #dev_ops với Leader ID và Payout Transaction ID để Ops/DevOps theo dõi.

Exc-4 — Middleware timeout trước khi trả phản hồi cho Zapier:

• Zapier tự động retry POST /process-pod-vesting với cùng cycle_date = Today (Zapier Company Tier exponential retry).
• Ba lớp idempotency phòng tránh thanh toán trùng lặp:
  • Lớp 1 — Bộ lọc trạng thái DB: Middleware truy vấn lại Pending_Carry_Balance > 0. Leader đã được thanh toán trong lần chạy trước có Pending_Carry_Balance = $0.00 và được bỏ qua tự động.
  • Lớp 2 — Khóa idempotency gateway thanh toán: Với mỗi lời gọi thanh toán, Middleware truyền Idempotency-Key: VESTING_{leader_id}_{cycle_date} (ví dụ: VESTING_USR_98765_2026-10-01) cho Dots/Rippling. Nếu khoản thanh toán đã hoàn tất, Dots/Rippling trả HTTP 409 — không có giao dịch mới được tạo.
  • Lớp 3 — Neo blockchain: contract.recordMetric() với receipt_hash = transaction ID gốc cung cấp audit trail on-chain; Ops có thể đối chiếu bất kỳ khoảng trống nào ngay lập tức.

Quy tắc nghiệp vụ

BR_8.2.12.1: Zapier chỉ là Scheduler — Không có logic Middleware trong Zapier Với Flow 17, công việc duy nhất của Zapier là kích hoạt trigger lịch trình và gọi endpoint POST /process-pod-vesting duy nhất. Toàn bộ xử lý batch — truy vấn leader, định tuyến thanh toán, ghi blockchain, xóa số dư — được thực thi bên trong Middleware. Không có vòng lặp Zapier theo từng leader.

BR_8.2.12.2: Định tuyến Chi trả Carry — Dots vs. Rippling Định tuyến thanh toán được xác định bằng cách đánh giá ba trường trong bảng Users: billing_country, current_level, và compensation_track.

Đường A — Dots API (thanh toán một lần):

• billing_country != 'US' — tất cả leader quốc tế (tất cả level 1–24)
• HOẶC billing_country == 'US' AND current_level < 6 — contractor junior Mỹ (trước W2)
• Payload: POST /v2/payouts — payee_id, amount, memo

Đường B — Rippling Off-Cycle Payroll API:

• billing_country == 'US' AND current_level >= 6 AND compensation_track IN ('Standard', 'Flex')
• compensation_track được đặt trong quá trình chuyển Level 6 (Flow 6)
• Payload: POST /api/v1/payroll/off-cycle-payruns — employee_id, earning_type = "DISCRETIONARY_BONUS", amount
• Lý do dùng Off-Cycle (không phải payroll thường kỳ): Carry là khoản thưởng hiệu suất biến đổi được quyết toán vào ngày 1 hàng tháng, độc lập với lịch payroll W-2 cố định. Off-Cycle API quyết toán ngay mà không cần chờ kỳ payroll thường kỳ tiếp theo.
• Lý do dùng earning type DISCRETIONARY_BONUS: Carry được xếp vào US Supplemental Wages theo quy định của IRS. Định tuyến qua Off-Cycle API với earning type này giúp Rippling tự động áp dụng đúng mức khấu trừ thuế bổ sung — tách biệt với lương thường kỳ để tránh xử lý thuế W-2 sai cho nhân viên.

Ngưỡng thanh toán tối thiểu: Nếu Pending_Carry_Balance < $100 (Min_Payout_Threshold trong Table C), chu kỳ bị bỏ qua cho leader đó và số dư chuyển sang tháng sau để tránh rò rỉ phí giao dịch.

Founding Mentors (Role_Flag = 'Founding_Mentor'): Tuân theo các quy tắc định tuyến giống hệt Pod Leader thông thường (US vs. quốc tế, theo level). Pending_Carry_Balance của họ tiếp tục vesting bình thường ngay cả khi tài khoản giao dịch cá nhân kích hoạt vi phạm drawdown — vesting carry không bị chặn bởi drawdown defense.

BR_8.2.12.3: Receipt Hash Blockchain = Payout Transaction ID Mỗi khoản thanh toán được xử lý trong chu kỳ vesting phải được ghi trên Polygon PoS blockchain qua contract.recordMetric(). Trường receipt_hash phải được đặt bằng transaction ID Dots hoặc Rippling từ phản hồi API thanh toán. Đây là bằng chứng thanh toán bất biến.

BR_8.2.12.4: Xóa số dư là bắt buộc sau mỗi khoản thanh toán Pending_Carry_Balance phải được đặt về $0.00 cho mỗi leader ngay sau khi khoản thanh toán của họ được xác nhận. Điều này ngăn thanh toán trùng lặp ở chu kỳ hàng tháng tiếp theo. Việc xóa phải xảy ra trong cùng vòng lặp xử lý Middleware với lời gọi thanh toán.

BR_8.2.12.5: Số tiền Carry cố định tại thời điểm tích lũy, không phải tại thời điểm thanh toán Số tiền carry được tích lũy tại thời điểm thăng level của mentee (Flow 6): L3 = $250, L5 = $500, L7 = $1,500. Khoản thanh toán vesting hàng tháng không tính lại các số tiền này — chỉ đơn giản là thanh toán bất kỳ Pending_Carry_Balance tích lũy nào tồn tại tại thời điểm thanh toán. Không có điều chỉnh hồi tố.

BR_8.2.12.6: Thông báo Ops là bắt buộc Slack alert đến Head of Ops phải được kích hoạt sau mỗi lần chạy vesting (dù có hay không có leader được xử lý). Alert phải bao gồm processed_count từ phản hồi Middleware. Đây là cơ chế giám sát Ops cho chu kỳ thanh toán hàng tháng.

BR_8.2.12.7: Min_Payout_Threshold lấy từ Table C — Không được hardcode Số dư carry tối thiểu cần thiết để đủ điều kiện cho chu kỳ thanh toán là Min_Payout_Threshold, đọc từ Table C: Global_Variables. Giá trị hiện tại = $100. Nếu Pending_Carry_Balance < $100 của leader vào ngày 1 của tháng, họ bị bỏ qua — số dư không bị xóa, nó chuyển sang chu kỳ tiếp theo. Giá trị này không bao giờ được hardcode trong Middleware; luôn đọc từ Table C.

BR_8.2.12.8: Lỗi thanh toán — Cách ly vòng lặp, Bảo toàn số dư, Alert đến #ops-treasury Nếu lời gọi Dots hoặc Rippling thất bại cho một leader cụ thể:

1. Leader thất bại bị bỏ qua; vòng lặp batch tiếp tục sang leader tiếp theo.
2. Pending_Carry_Balance của leader thất bại KHÔNG bị xóa — tích lũy và được retry ở chu kỳ hàng tháng tiếp theo.
3. Slack error alert kích hoạt đến #ops-treasury (không phải #ops-it) với leader_id, số tiền, và chi tiết lỗi API.
4. Các leader còn lại trong batch không bị ảnh hưởng.

BR_8.2.12.9: Leader bị Terminated — Carry bị tịch thu khi kiểm tra chu kỳ, không thực hiện thanh toán Khi bước kiểm tra điều kiện ở Bước 2 gặp leader có Status = 'Terminated' và Pending_Carry_Balance > 0, carry chưa vested lập tức bị tịch thu: Pending_Carry_Balance được đặt về $0.00 mà không gọi Dots hay Rippling. Điều này tương ứng với việc xóa carry ngay lập tức do BPS termination endpoint thực hiện (Flow 15C / UC_8.2.11 M-3), và xử lý bất kỳ số dư còn sót nào có thể đã tích lũy giữa sự kiện sa thải và chu kỳ thanh toán tiếp theo.

BR_8.2.12.10: QuickBooks Journal Entry — Một bút toán cho mỗi khoản thanh toán Dots, bỏ qua Rippling W-2 (CHR-139) POST /process-pod-vesting phải tuân theo ba quy tắc đối với QuickBooks Online:

1. Bút toán riêng lẻ (không gộp): một Journal Entry riêng cho mỗi Pod Leader / Founding Mentor, được đẩy khi Dots API trả transaction ID thành công. Không bao giờ gộp nhiều leader vào một Journal Entry.
2. Chỉ Dots (bỏ qua Rippling W-2): Journal Entry chỉ được đẩy cho các khoản thanh toán định tuyến qua Dots API (Đường A). Các khoản thanh toán qua Rippling Off-Cycle Payroll API (Đường B — US Level 6+ W-2) bị bỏ qua, vì Rippling tự đồng bộ payroll W-2 sang QuickBooks.
3. Ánh xạ tài khoản: Debit 5016 POD Leader Bonus Contractor / Credit 1102 DOTS, cả hai đều bằng số tiền thanh toán tuyệt đối.

(Nguồn: CHR-139; QuickBooks Integration Specification §4.B "Pod Leader Carry/Commission - Flow 17 - Contractors"; Xác nhận client 2026-10-30)

Tiêu chí chấp nhận

---

UC_8.2.13 — Luồng 1.5: Khởi tạo Founding Mentor

Trigger

Sự kiện: Webhook nhận từ Signwell — loại sự kiện: Document Signed (Founding Pod Leader Agreement).

Rippling không được sử dụng là nền tảng thực thi hợp đồng cho luồng này. Signwell thay thế Rippling cho mục đích ký hợp đồng và trigger webhook. Founding Mentors có thể đến từ bất kỳ quốc gia nào — quốc tịch không phải ràng buộc điều kiện tham gia.

Điều kiện tiên quyết

Hậu điều kiện

Luồng cơ bản

Bước 1. Nhận Signwell Webhook [CHR-78]

• Zapier bắt Signwell webhook: document_completed — Founding Pod Leader Agreement.
• Payload chứa: user_email của người ký.
• Middleware validate chữ ký HMAC-SHA256 trước khi xử lý (BR_8.2.13.10).

Bước 2. Upsert Global_User_ID [CHR-78]

• Truy vấn PostgreSQL để tìm bản ghi hiện có theo user_email.
• Nếu không có bản ghi: tạo Global_User_ID mới.
• Upsert bản ghi với:
  • Role_Flag = 'Founding_Mentor'
  • is_pod_leader = TRUE
  • contract_pod_leader = 'Signed'
• Tất cả trường hiện có (lịch sử giao dịch, trạng thái challenge, v.v.) được bảo toàn — không bao giờ tạo hàng trùng lặp.

Bước 3. Smart Gating — Gửi KYC [CHR-78]

• Kiểm tra identity_status trên bản ghi đã upsert:
  • Người dùng hoàn toàn mới HOẶC identity_status != 'Approved': Gọi Veriff API POST /v1/sessions → nhận { "sessionId": "string", "verification_url": "URL" }. Gửi email khởi tạo KYC với verification_url. Đặt identity_status = 'Pending'.
  • Trader hiện có với identity_status = 'Approved': Bỏ qua Veriff hoàn toàn — KYC đã được xác minh (smart gate bypass).

Bước 4. Smart Gating — Gửi Payout Dots [CHR-78]

• Kiểm tra payout_status trên bản ghi đã upsert:
  • payout_status != 'Approved' VÀ dots_payee_id IS NULL: Gửi link setup payout Dots đến user_email để đăng ký ngân hàng + W-9/W-8BEN.
  • payout_status = 'Approved' HOẶC dots_payee_id IS NOT NULL: Bỏ qua Dots — hồ sơ payout đã được cấu hình (smart gate bypass).
• Bước 3 và 4 độc lập — bypass một phần là hợp lệ (ví dụ: chỉ bypass KYC, hoặc chỉ bypass Dots).

Bước 5. Provisioning Gate [CHR-78]

• Middleware kiểm tra: identity_status = 'Approved' VÀ payout_status = 'Approved'.
• Case A — Một hoặc cả hai trạng thái vẫn đang Pending (async): Middleware đăng ký là async webhook listener. Gate mở khi CẢ HAI callback Veriff (identity_status = 'Approved') VÀ callback Dots (payout_status = 'Approved') được nhận. Bước 6–8 không thực thi cho đến khi cả hai được nhận.
• Case B — Cả hai trạng thái đã Approved (đồng bộ): Gate đánh giá là TRUE ngay lập tức sau khi Bước 3 và 4 hoàn tất (cả hai smart gate bypass đều kích hoạt). Middleware KHÔNG chờ bất kỳ webhook nào — kích hoạt Bước 6–8 ngay lập tức.
• Chỉ một điều kiện không đủ để trigger provisioning.

Bước 6. Cấp phép tài khoản Google Workspace [CHR-78]

• Gọi Google Workspace Admin Directory API:
  • Endpoint: POST /admin/directory/v1/users
  • Trường quan trọng: primaryEmail = [firstname].[lastname]@stacktrading.com, orgUnitPath: /Founding Mentors, changePasswordAtNextLogin: true
  • MFA cấp OU được áp dụng (Google Authenticator bắt buộc trước khi truy cập Workspace)
• Xử lý email collision (atomic loop): WHILE GET /users/{handle}@stacktrading.com → 200: thêm .1, .2, .3, ... cho đến khi tìm được địa chỉ duy nhất.
• Khởi tạo Google Standard Invite Flow → link kích hoạt gửi đến email cá nhân; không có mật khẩu nào được tạo hoặc lưu trữ bởi Middleware.
• UPDATE Users SET google_workspace_email = '{handle}@stacktrading.com'

Bước 6.5. Tạo kênh Discord Pod [CHR-78]

• Gọi Middleware endpoint POST /create-pod-channel với:
  • user_id: Global_User_ID của Founding Mentor
  • leader_name: trích từ google_workspace_email — bỏ hậu tố @stacktrading.com (ví dụ: john.doe@stacktrading.com → john.doe). Ghi leader_name = 'john.doe' vào Pod_Leader_Registry.Leader_Name.
• Middleware slug hóa tên kênh trước khi gọi Discord Bot — cùng quy tắc với Flow 15B (BR_8.2.10.2):
  • Chuyển về chữ thường; thay khoảng trắng và dấu . bằng dấu gạch ngang; bỏ toàn bộ dấu và ký tự đặc biệt.
  • Thêm 4 ký tự đầu của leader_id vào cuối (ví dụ: john.doe → pod-john-doe-a7b2).
• Discord Bot tạo kênh text và voice riêng tư với tên đã slug hóa và đặt quyền cho các thành viên pod được phân công.
• Quyền truy cập kênh của leader (quyền theo từng người dùng): NẾU discord_user_id IS NOT NULL → Bot cấp cho Founding Mentor quyền truy cập kênh ngay khi tạo. NẾU discord_user_id IS NULL → kênh vẫn được tạo; quyền truy cập của leader được cấp khi mentor chạy /link (BR_8.2.13.27). Quyền truy cập không bao giờ được cấp qua role dùng chung Pod Leader.
• Trả JSON: { "channel_id": "string", "channel_url": "URL_string" }. Zapier chờ phản hồi chứa channel_url.
• leader_name PHẢI được dẫn xuất từ handle Workspace, KHÔNG phải từ legal_name của Veriff (xem BR_8.2.13.17).
• Bước này thực thi ngay sau Bước 6 (cấp phép Workspace) và trước Bước 7 (tạo coupon Amplify).
• Khi thất bại: Thử lại 3× với exponential backoff; không rollback Pod_Leader_Registry; SEV-1 alert nếu tất cả retry thất bại. Bước 7 và 8 vẫn tiếp tục. Xem Exc-5.

Bước 6.6. Ghi channel_url vào hồ sơ người dùng

• Cập nhật bản ghi SQL người dùng: ghi channel_url từ phản hồi Bước 6.5 vào hồ sơ Founding Mentor.

Bước 6.7. Gán Discord Role

• Gọi POST /manage-discord-role với user_id, add_role = 'Pod Leader'.
• Nếu discord_user_id IS NULL → endpoint trả 200 OK và bỏ qua thao tác (BR_8.2.10.4). Luồng tiếp tục.
• Role và quyền truy cập kênh bị bỏ qua sẽ được áp dụng khi mentor chạy /link sau đó (BR_8.2.13.27).

Bước 7. Tạo coupon Amplify 100% (chỉ EVAL_L1) [CHR-78]

• Tạo coupon giảm giá 100% Amplify giới hạn cho EVAL_L1 (Associate Track, $650 — không thể áp dụng cho Reset, Accelerated, Advanced, hoặc phí Live).

Bước 7.5. Discord Link Token

• NẾU discord_user_id IS NOT NULL → bỏ qua; không cần token (đã liên kết).
• NGƯỢC LẠI NẾU discord_link_token IS NOT NULL (trader hiện có, chưa liên kết) → tái sử dụng token hiện có. KHÔNG tạo lại.
• NGƯỢC LẠI → tạo UUID, UPDATE Users SET discord_link_token = '{uuid}'.
• Chạy sau provisioning gate, trước Bước 8. Không bị chặn bởi lỗi ở Bước 6.5.
• Token không bao giờ bị ghi đè bởi các bước sau, bao gồm checkout [CHR-91] khi mentor sử dụng coupon (BR_8.2.13.28).

Bước 8. Gửi email Pod_Founding_Leader_Welcome [CHR-78]

• Đến: user_email (email cá nhân — KHÔNG phải @stacktrading.com)
• Nội dung:
  • Mã coupon Amplify 100%.
  • Link kích hoạt Google Workspace (từ Bước 6).
  • Hướng dẫn onboarding.
  • Link Typeform để thiết lập hồ sơ (xem Bước 9): https://form.stacktrading.com/mentor-profile-setup?leader_id={{user_id}}&email={{user_email}} (Hidden Fields được tự động chèn).
  • Khối Discord (chỉ khi discord_user_id IS NULL): Discord invite URL + hướng dẫn "Join the server and type /link [discord_link_token] in #verify" kèm token từ Bước 7.5.
  • Không bao gồm: Link Veriff KYC (gửi riêng ở Bước 3), bất kỳ mật khẩu Workspace nào.
• Mentor dùng coupon tại public checkout ($0.00) → Level 0 SIM, vốn khởi điểm tiêu chuẩn. Không cần BPS Admin cấp phép thủ công.

Bước 9. Đồng bộ hồ sơ Pod_Leader_Registry — Asset_Class & Trading_Style (Typeform Webhook) [CHR-145]

• Trigger: webhook New Entry Submitted từ Typeform được liên kết ở Bước 8 — bất đồng bộ, kích hoạt độc lập sau khi mentor hoàn thành form hồ sơ.
• Founding Mentor khai báo:
  • Asset_Class — Futures hoặc Forex (bắt buộc; Founding Mentors có thể là nhân viên tuyển dụng bên ngoài không có bản ghi Users.asset_class)
  • Trading_Style — multi-select: Scalping, Day Trading, Swing Trading, Algorithmic Trading
• Webhook kích hoạt từ Typeform → Middleware (Zapier Flow 1.5.1):

  UPDATE Pod_Leader_Registry
  SET
      Asset_Class         = '{{typeform.asset_class}}',
      Trading_Style       = '{{typeform.trading_style}}',
      Is_Profile_Complete = TRUE,
      Status              = 'Active',
      Updated_At          = NOW()
  WHERE Leader_ID = '{{typeform.leader_id}}';

• Ảnh hưởng đến Flow 10: Bản ghi Pod_Leader_Registry chỉ hiển thị với Mentee Matching Engine sau khi bước này ghi Asset_Class không null. Cho đến khi Bước 9 hoàn tất, Founding Mentor chưa sẵn sàng nhận phân công mentee.
• Trigger Flow 11 (Waitlist Processor): ngay sau khi ghi hồ sơ thành công (Status = 'Active' VÀ Is_Profile_Complete = TRUE), Middleware kích hoạt Zap Flow 11: Waitlist Processor cho Leader_ID này để lấp các slot trống (Current_Count < Max_Capacity) từ Pod_Waitlist (FIFO, cùng Asset_Class). Kích hoạt một lần cho mỗi lần nộp Typeform; lần nộp lại không làm Is_Profile_Complete chuyển từ FALSE sang TRUE sẽ không kích hoạt lại. Đây là sự kiện "new leader" của UC_8.2.8 BR_8.2.8.1 #2 đối với Founding Mentors.
• Ảnh hưởng đến Checkout [CHR-145]: Pod_Leader_Registry.Asset_Class trở thành loại tài sản bắt buộc khi Founding Mentor checkout bằng coupon 100%. Tại checkout Bước 5 (email onBlur), asset_class trong giỏ hàng phải khớp với Pod_Leader_Registry.Asset_Class và product_id trong giỏ hàng phải là EVAL_L1; nếu không, checkout bị chặn và mentor phải chọn lại. Nếu Bước 9 chưa hoàn tất (Asset_Class IS NULL), checkout bị chặn cho đến khi Typeform được nộp. Xem BR_8.2.13.25 / BR_8.2.13.26 (banner BN-18/19/20).

Cấp hệ thống: Founding Mentor Defense Bypass (Liên tục)

Đây không phải là bước Zapier flow — đây là quy tắc bảo vệ phía server liên tục được kích hoạt bởi Role_Flag = 'Founding_Mentor'.

Logic: Bất kỳ Global_User_ID nào có Role_Flag = 'Founding_Mentor' đều được bảo vệ qua biến hệ thống khỏi các trigger tạm dừng tự động (ví dụ: Drawdown Defense) mà nếu không sẽ ảnh hưởng đến trạng thái mentorship của họ.

Sự bảo vệ này tồn tại miễn là Role_Flag = 'Founding_Mentor' được đặt trên bản ghi.

Carry balance trong thời gian tạm dừng: Kịch bản này không áp dụng cho Founding Mentors. Do quy tắc Defense Bypass miễn trừ Founding Mentors khỏi các trigger tạm dừng tự động, Pending_Carry_Balance của họ không bao giờ bị tự động đóng băng bởi Drawdown Defense hay sự kiện DTO/Hiatus. (Lưu ý: Đối với Pod Leaders tiêu chuẩn, Pending_Carry_Balance bị tạm thời đóng băng cho đến khi họ trở lại từ tạm dừng.)

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Task: Founding Mentor Defense Bypass lines 3141–3145; Xác nhận client 2026-09-30 — carry balance freeze N/A cho Founding Mentors)

§6.1 Quản trị Hiatus & Nghỉ phép (Tích hợp Flow 13)

Tham chiếu chéo: UC_9.2 — Flow 13 (Time-Off Management) quản lý toàn bộ pipeline xử lý nghỉ phép. Phần này ghi lại các quy tắc đặc thù cho Founding Mentor áp dụng khi Flow 13 được kích hoạt cho Founding Mentor.

Nguyên tắc bảo toàn vai trò tuyệt đối

Nghỉ phép tạm thời (DTO hoặc Hiatus qua Flow 13) KHÔNG ĐƯỢC coi là từ bỏ vai trò đối với Founding Mentor. Tất cả đặc quyền quản trị và tài nguyên dưới đây được bảo toàn 100% trong suốt trạng thái On_Leave:

Carry trong thời gian nghỉ phép là như nhau đối với Founding Mentor và Pod Leader tiêu chuẩn: không có Pod Leader nào bị đóng băng Pending_Carry_Balance trong thời gian nghỉ phép được phê duyệt — số dư tiếp tục vesting qua Flow 17. (Thay thế cách diễn đạt trước đây, khi bảng ghi "Frozen" còn đoạn văn ghi "exempted entirely".)

(Source: QnA_STAGE6_POD_SYSTEM_FLOW10_11.md [POD-XF-15] client xác nhận 2026-10-30; [POD-XF-18] client sheet 2026-11-04; RFQ_ Stack Trading Prop Tech V7.pdf §Founding Mentor Defense Bypass)

Luồng ngoại lệ

Exc-0 — Nhận webhook document_id trùng lặp (Bước 1):

• Kiểm tra idempotency: nếu contract_pod_leader = 'Signed' đã tồn tại cho user_email này → HTTP 200 No-Op; cảnh báo được ghi log. Không upsert trùng, không gửi KYC, không provisioning.

Exc-1 — Tạo Veriff session thất bại (Bước 3):

• POST /v1/sessions trả non-200.
• 3 lần retry với exponential backoff (30s → 5min → 15min); sau tất cả đều thất bại: HALT — provisioning bị hoãn. SEV-2 → #dev_ops.

Exc-2 — Global_User_ID đã tồn tại với Role_Flag khác (Bước 3):

• Middleware khớp theo email và áp dụng upsert: Role_Flag = 'Founding_Mentor', is_pod_leader = TRUE, contract_pod_leader = 'Signed'. Tất cả trường khác được bảo toàn trên cùng Global_User_ID — không tạo hàng mới.
• Sub-case A — tài khoản hiện có là Active_Challenge hoặc Active_DMA: Role_Flag = 'Founding_Mentor' được áp dụng ngay lập tức; tài khoản giao dịch hiện có tiếp tục bình thường. Nếu mentor cố gắng sử dụng coupon 100% Amplify để mua thêm tài khoản tại checkout, hệ thống chặn giao dịch và trả: "You already have an active account."
• Sub-case B — tài khoản hiện có là Failed hoặc Terminated: Role_Flag = 'Founding_Mentor' được áp dụng. Khi mentor sử dụng coupon 100% tại public checkout với email đã đăng ký, hệ thống lưu trữ lịch sử tài khoản thất bại/terminated trước vào user_account_history, reset số liệu, và cấp phép SIM challenge mới dưới cùng Global_User_ID.

Exc-3 — Cấp phép Google Workspace thất bại (Bước 6):

• Hành vi đã xác nhận (Option A — Tiếp tục): Cho phép luồng tiếp tục tạo coupon (Bước 7) và gửi email Pod_Founding_Leader_Welcome (Bước 8) đến email cá nhân.
• Ghi log lỗi; gửi SEV-2 Slack alert đến #ops-it. Ops cấp phép Workspace thủ công sau thông qua Google Admin console — Middleware KHÔNG gửi email chào mừng Workspace thứ hai; Ops kích hoạt email chào mừng gốc từ Google Admin.
• (Nguồn: Xác nhận client 2026-10-07)

Exc-4 — Tạo coupon Amplify thất bại (Bước 7):

• Hành vi đã xác nhận (Option A — Giữ email): GIỮ email Pod_Founding_Leader_Welcome — KHÔNG gửi mà thiếu coupon. Gửi coupon mà không có coupon làm phát sinh ticket hỗ trợ.
• Gửi alert Ops để tạo coupon thủ công; gửi lại email khi coupon sẵn sàng.
• Coupon Founding Mentor KHÔNG có TTL cứng hoặc ngày hết hạn (khác với coupon retention Flow 7B có thời hạn 10 ngày).
• (Nguồn: Xác nhận client 2026-10-07)

Exc-5 — Tạo kênh Discord pod thất bại (Bước 6.5):

• POST /create-pod-channel trả non-200 hoặc connection timeout.
• channel_url không được trả về → Bước 6.6 (ghi DB) và Bước 6.7 (Discord role) không thể tiến hành.
• Hành vi (giống UC_8.2.10 Exc-1): KHÔNG rollback bản ghi Pod_Leader_Registry. Middleware thử lại POST /create-pod-channel 3 lần với exponential backoff. Nếu tất cả retry thất bại → ghi log DISCORD_CHANNEL_CREATION_FAILED kèm user_id và leader_name + SEV-1 Slack alert đến #ops-it; Ops tạo kênh thủ công và cập nhật channel_url trong DB (BR_8.2.13.29).
• Bước 7, 7.5 và 8 vẫn tiếp tục. KHÔNG giữ lại email chào mừng.

Quy tắc nghiệp vụ

BR_8.2.13.1: Veriff sử dụng link dựa trên Session, không phải URL tĩnh Flow 1.5 tạo Veriff session mới qua POST /v1/sessions cho mỗi Founding Mentor. verification_url là duy nhất cho mỗi session và được giới hạn trong sessionId đó. Tuyệt đối không gửi link tĩnh hoặc tái sử dụng — đây là ràng buộc cấp hệ thống của Veriff, nhất quán với Flow 3A (Live Onboarding).

BR_8.2.13.2: Mật khẩu Workspace không bao giờ được gửi qua email Khi cấp phép tài khoản Google Workspace (Bước 6), changePasswordAtNextLogin: true phải được đặt. Middleware không được tạo, lưu trữ, hoặc truyền mật khẩu. Người dùng tự đặt mật khẩu qua Google's Standard Invite Flow khi đăng nhập lần đầu. Quy tắc này áp dụng cho email Pod_Founding_Leader_Welcome và mọi liên lạc trong tương lai.

BR_8.2.13.3: MFA được áp dụng bởi chính sách OU, không phải code ứng dụng SSO/MFA enforcement không được triển khai trong logic ứng dụng Middleware. Nó được áp dụng bởi chính sách Organizational Unit (OU) Google Workspace @stacktrading.com, yêu cầu kích hoạt Google Authenticator / MFA trước khi bất kỳ truy cập Workspace nào được cấp phép. Code ứng dụng chỉ đảm bảo người dùng được tạo trong OU đúng.

BR_8.2.13.4: Role_Flag = 'Founding_Mentor' kích hoạt Defense Bypass vĩnh viễn Đặt Role_Flag = 'Founding_Mentor' trên bản ghi Global_User_ID (Bước 3) không phải là thẩm mỹ — nó kích hoạt sự bảo vệ liên tục, phía server, miễn trừ người dùng khỏi tất cả trigger tạm dừng tự động ảnh hưởng đến trạng thái mentorship (ví dụ: Drawdown Defense). Sự bảo vệ này là cấp hệ thống và tồn tại suốt vòng đời bản ghi.

BR_8.2.13.5: Email chào mừng chỉ chứa Coupon + Link kích hoạt Email Pod_Founding_Leader_Welcome phải chứa chính xác: mã coupon Amplify 100% cho Associate Track, link kích hoạt Google Workspace, hướng dẫn onboarding, link Typeform hồ sơ, và — khi discord_user_id IS NULL — Discord invite URL kèm hướng dẫn /link [discord_link_token]. Không được chứa: bất kỳ mật khẩu Workspace nào, bất kỳ link Veriff KYC nào (link KYC được gửi trong email riêng từ bước Veriff session).

BR_8.2.13.6: Email Workspace Collision — Chỉ số tuần tự Nếu địa chỉ Workspace dẫn xuất [firstname].[lastname]@stacktrading.com đã tồn tại, Middleware phải thêm chỉ số số học tuần tự (ví dụ: john.doe1, john.doe2) cho đến khi tìm được địa chỉ duy nhất. KHÔNG sử dụng suffix user_id hoặc pattern khác.

BR_8.2.13.7: Dots Payout Setup được gửi bởi Middleware — Cùng sequence với Stage 3 Flow 1.5 sử dụng cùng sequence KYC → Payouts như Stage 3 Live Onboarding. Sau khi nhận Signwell webhook, Middleware gửi link setup payout Dots đến Founding Mentor (Bước 4 — smart-gated: bỏ qua nếu payout_status = 'Approved'). Mentor không cần tự onboard Dots độc lập — việc gửi được khởi tạo bởi hệ thống. Rippling không được sử dụng ở bất kỳ điểm nào trong luồng này.

BR_8.2.13.8: Cấp phép tài khoản Trading qua Public Checkout, không phải BPS Admin Founding Mentors không được cấp phép tài khoản giao dịch thủ công qua BPS Admin. Họ phải sử dụng coupon Amplify giảm giá 100% được tạo ở Bước 7 để mua Associate Track qua website public. Họ bắt đầu ở Level 0 trong môi trường SIM với vốn khởi điểm tiêu chuẩn cho tier đã chọn. Không có đường cấp phép đặc biệt nào cho tài khoản giao dịch của Founding Mentors.

BR_8.2.13.9: contract_pod_leader ≠ contract_status — Hai State Machine riêng biệt contract_pod_leader theo dõi Founding Pod Leader Agreement (luồng này) và hợp đồng đăng ký Standard Pod Leader (Flow 15B). contract_status được dành riêng cho Trader ICA được ký trong Flow 3E (Live Onboarding). Đây là các trường độc lập trên bảng Users và không bao giờ được hợp nhất hay tạo alias.

BR_8.2.13.10: Signwell Webhook phải được validate HMAC-SHA256 Middleware phải validate chữ ký HMAC-SHA256 trên mỗi Signwell webhook inbound trước khi bất kỳ xử lý nào bắt đầu (Bước 1). Các yêu cầu không qua validate chữ ký phải bị từ chối với HTTP 400 và không được trigger bất kỳ upsert, gửi KYC, hoặc provisioning nào.

BR_8.2.13.11: Provisioning Gate — Cả KYC và Payout phải được Approved trước Workspace + Coupon Cấp phép Google Workspace (Bước 6) và tạo coupon Amplify + email chào mừng (Bước 7 và 8) không được thực thi cho đến khi CẢ HAI điều kiện sau được đáp ứng trên bản ghi người dùng:

• identity_status = 'Approved'
• payout_status = 'Approved'

Case A (async): Nếu một trong hai trạng thái vẫn đang Pending sau Bước 3 và 4, Middleware đăng ký là async webhook listener và kích hoạt provisioning chỉ khi cả hai callback được nhận. Một trạng thái một mình không trigger provisioning.

Case B (đồng bộ): Nếu cả hai trạng thái đã là 'Approved' khi Bước 3 và 4 thực thi (cả hai smart gate bypass đều kích hoạt), gate đánh giá là TRUE ngay lập tức — Middleware không chờ bất kỳ webhook nào và kích hoạt provisioning đồng bộ.

BR_8.2.13.12: Đường downstream sau SIM — Flow 3A Branch C (UC_5.1) Sau khi Founding Mentor hoàn thành provisioning Flow 1.5 và sử dụng coupon 100% để vào môi trường SIM, đường tiếp theo khi qua đánh giá SIM là Flow 3A (UC_5.1) Branch C — Returning Trader. Tại điểm đó cả identity_status = 'Approved' và payout_status = 'Approved' đã được đặt trên bản ghi người dùng (thiết lập trong luồng này). Flow 3A tự nhiên định tuyến Branch C và bỏ qua các bước KYC và gửi Dots — không cần xác minh hoặc bước payout thừa. Middleware không được thêm kiểm tra KYC hoặc Dots bổ sung khi xử lý sự kiện SIM pass của Founding Mentor.

BR_8.2.13.13: Coupon Founding Mentor — Không chuyển nhượng, Không hết hạn, Chỉ EVAL_L1 Coupon Amplify 100% được tạo cho Founding Mentors bị ràng buộc bởi user_email của người nhận (không chuyển nhượng). Coupon chỉ áp dụng cho EVAL_L1 (Associate Track $650) — không áp dụng cho các track khác. Coupon KHÔNG có TTL cứng hoặc ngày hết hạn (khác với coupon retention Flow 7B có thời hạn 10 ngày). Coupon từ Everflow "Viral Reward" có thể chuyển nhượng và hoạt động như gift card — khác biệt với coupon Founding Mentor. (Nguồn: Xác nhận client 2026-10-07)

BR_8.2.13.14: Coupon chỉ giao qua Email — Không có Dashboard UI Coupon Founding Mentor được giao qua email Pod_Founding_Leader_Welcome. Không có dashboard UI hoặc module quản lý coupon trong giai đoạn ra mắt Day 1. Founding Mentor phải truy cập email để lấy mã coupon. (Nguồn: Xác nhận client 2026-10-07)

BR_8.2.13.15: Lỗi Google Workspace — Không chặn; Cascade tiếp tục đến Bước 7 và 8 Nếu cấp phép Google Workspace thất bại ở Bước 6, luồng KHÔNG ĐƯỢC dừng lại. Bước 7 (tạo coupon Amplify) và Bước 8 (gửi email chào mừng) tiếp tục bình thường. Ops được thông báo qua SEV-2 alert đến #ops-it và cấp phép Workspace thủ công sau. Sau khi Ops cấp phép, Ops kích hoạt email chào mừng Workspace gốc từ Google Admin console — Middleware không gửi email thứ hai. (Nguồn: Xác nhận client 2026-10-07)

BR_8.2.13.16: Coupon Amplify thất bại — Giữ email; Không gửi thiếu coupon Nếu POST /amplify/create-coupon thất bại ở Bước 7, email Pod_Founding_Leader_Welcome PHẢI ĐƯỢC GIỮ LẠI — KHÔNG gửi mà thiếu coupon. Lý do: gửi email chào mừng mà không có coupon tạo ra kỳ vọng không thể đáp ứng và phát sinh ticket hỗ trợ. Ops được alert để tạo coupon thủ công; email được gửi lại khi coupon sẵn sàng. (Nguồn: Xác nhận client 2026-10-07)

BR_8.2.13.17: leader_name PHẢI được dẫn xuất từ handle Workspace — KHÔNG phải từ legal_name của Veriff Trích leader_name từ google_workspace_email bằng cách bỏ @stacktrading.com (ví dụ: john.doe@stacktrading.com → john.doe). KHÔNG dùng legal_name của Veriff. Lý do: (1) Discord API chỉ chấp nhận chữ thường ASCII/chữ số/dấu gạch ngang — tên từ Veriff thường chứa dấu/khoảng trắng gây lỗi HTTP 400; (2) vòng lặp xử lý collision của Workspace đảm bảo handle là duy nhất, và tính duy nhất này tự động được leader_name trong Pod_Leader_Registry và Discord kế thừa; (3) danh tính pháp lý (KYC/thuế) được tách biệt khỏi danh tính nghiệp vụ (Discord/Workspace). Slug kênh Discord tuân theo BR_8.2.10.2 (chữ thường, ./khoảng trắng → -, bỏ dấu/ký tự đặc biệt, thêm 4 ký tự đầu của leader_id — ví dụ: pod-john-doe-a7b2). (Nguồn: Bổ sung client 2026-10-19; Quyết định BA 2026-10-29 — slug thống nhất với Flow 15B)

BR_8.2.13.18: Cron dọn dẹp Guest PHẢI loại trừ Founding Mentors [CHR-145] Cron job tự động xóa Guest sau 30 ngày phải bao gồm AND role_flag != 'Founding_Mentor' (hoặc tương đương AND role_flag IS NULL) trong mệnh đề WHERE. Bản ghi Founding Mentor không bao giờ được tự động xóa bởi cron dọn dẹp Guest bất kể thời gian không hoạt động. Lý do: Founding Mentors sử dụng coupon Amplify tại public checkout với tư cách Guest/người dùng ẩn danh trước khi Role_Flag được lan truyền đầy đủ — nếu không có điều kiện loại trừ này, cron có thể xóa các bản ghi Founding Mentor hợp lệ trong khoảng thời gian giữa Signwell trigger và khi hoàn tất checkout. (Nguồn: Xác nhận client 2026-10-22)

BR_8.2.13.19: Promo Code — Phase 1: Chỉ EVAL_L1, không có logic đặc biệt Trong Phase 1, cơ chế validate promo code 1-1 EVAL_L1 hiện có được giữ nguyên cho tất cả Founding Mentors — bao gồm cả Founding Mentor quay lại (Exc-2 Sub-case B). Không viết logic promo code đặc biệt hay tùy chỉnh nào cho luồng này. Áp dụng cho nhiều sản phẩm, coupon dùng được cho reset, và mọi tính linh hoạt khác về promo được hoãn sang Phase 2 (Day 2) để bảo vệ tiến độ ra mắt. Điều này xác nhận phạm vi hiện có của BR_8.2.13.13 — chỉ EVAL_L1, không chuyển nhượng, không hết hạn — mà không bổ sung logic xử lý promo đặc biệt. (Nguồn: Xác nhận client 2026-10-22)

BR_8.2.13.20: Quy tắc thuế $0.00 — Bỏ qua Quaderno API khi số tiền cuối cùng bằng 0 Thuế luôn được tính trên số tiền ròng sau chiết khấu. Khi Final_Amount == 0 (tức là coupon 100% chi trả toàn bộ giá checkout): (1) Tự động đặt Tax = $0.00; (2) KHÔNG gọi API tính thuế Quaderno — bỏ qua hoàn toàn lời gọi API. Không có request Quaderno nào được thực hiện cho đơn hàng $0.00. (Nguồn: Xác nhận client 2026-10-22)

BR_8.2.13.21: Checkout $0.00 — Bỏ qua mọi cổng thanh toán; Ghi nhận nội bộ; Tạo biên nhận PDF trên S3 Khi Final_Amount == 0 sau khi áp dụng coupon Founding Mentor 100%: (1) KHÔNG gửi giao dịch đến bất kỳ bộ xử lý thanh toán nào (NMI, ForumPay, T365, Dusupay, PayRetailers, hoặc bất kỳ cổng nào khác); (2) Ghi nhận giao dịch $0.00 nội bộ trong database hệ thống; (3) Tạo biên nhận PDF $0.00 trên S3 và gửi cho Founding Mentor; (4) Định tuyến trực tiếp đến Flow 1 Account Activation mà không qua bước xác nhận của bộ xử lý thanh toán. Checkout $0.00 không phải là trạng thái lỗi — đây là kết quả hợp lệ, được dự kiến đối với Founding Mentor sử dụng coupon Amplify 100%. (Nguồn: Xác nhận client 2026-10-22)

BR_8.2.13.22: QuickBooks — Loại trừ đơn hàng $0.00 khỏi Journal Entry KHÔNG gửi đơn hàng $0.00 sang QuickBooks. API journal entry của QuickBooks chỉ được kích hoạt khi total_amount > 0. Khi total_amount == 0 (tức là checkout $0.00 của Founding Mentor), bỏ qua hoàn toàn tích hợp QuickBooks — không tạo journal entry, không gọi QBO API. (Nguồn: Xác nhận client 2026-10-22; CHR-139 — QuickBooks logging)

BR_8.2.13.23: Không hard-lock Dashboard trong thời gian SIM Overlay onboarding hard-lock (UC_5.1 BR_5.1.3 / BR_5.1.8) chỉ áp dụng cho Flow 3 (chuyển SIM sang Live sau Passed_Challenge) và Flow 6 (chuyển Level 6). Khi một trader SIM hiện có ở Level 0 được đưa vào Flow 1.5 và identity_status = 'Pending' / payout_status = 'Pending' được đặt, dashboard KHÔNG ĐƯỢC hiển thị overlay chặn cứng. Trader tiếp tục giao dịch tài khoản SIM mà không bị gián đoạn. Cổng: overlay bị ẩn khi Role_Flag = 'Founding_Mentor' và trader vẫn đang ở SIM (bước KYC + Dots ban đầu này). Sau khi Founding Mentor vượt qua SIM (Passed_Challenge → Flow 3A Branch C, BR_8.2.13.12), overlay được hiển thị như bình thường. (Nguồn: Xác nhận client 2026-10-30; UC_5.1 BR_5.1-F1.5.8)

BR_8.2.13.24: Link Veriff KYC và link setup Dots — Chỉ qua Email, không có Banner Dashboard Link Veriff KYC (Bước 2) và link setup payout Dots (Bước 4) chỉ được gửi qua các email onboarding của Flow 1.5. Không xây dựng banner dashboard hay lời nhắc trong ứng dụng mới nào cho Flow 1.5. (Nguồn: Xác nhận client 2026-10-30)

BR_8.2.13.25: Checkout — Kiểm tra hồ sơ & Asset Class của Founding Mentor [CHR-145] Tại checkout Bước 5 (email onBlur, Duplicate Account Check — UC_2.6.2), khi bản ghi Users khớp theo email có Role_Flag = 'Founding_Mentor', kiểm tra này chạy trước các nhánh status tiêu chuẩn: (1) Nếu Pod_Leader_Registry.Asset_Class IS NULL (Typeform Bước 9 chưa được nộp) → HTTP 409 từ POST /capture-lead; không ghi bản ghi Users; nút [Next] bị vô hiệu hóa; banner BN-20. (2) Nếu asset_class trong giỏ hàng (Bước 1) ≠ Pod_Leader_Registry.Asset_Class đã khai báo trong Typeform Bước 9 → HTTP 409; không ghi bản ghi Users; nút [Next] bị vô hiệu hóa; banner BN-18. Mentor phải chọn lại loại tài sản khớp. (3) Khớp → tiếp tục BR_8.2.13.26. Mô phỏng theo UC_2.6.2 BR_2.6.2.11 (BN-16). (Nguồn: CHR-145)

BR_8.2.13.26: Checkout — Gói của Founding Mentor phải là EVAL_L1 [CHR-145] Được đánh giá ngay sau khi BR_8.2.13.25 thông qua. product_id trong giỏ hàng (Bước 2) phải là EVAL_L1 (Associate Track — sản phẩm duy nhất mà coupon Founding Mentor áp dụng, BR_8.2.13.13). Nếu không → HTTP 409 từ POST /capture-lead; không ghi bản ghi Users; nút [Next] bị vô hiệu hóa; banner BN-19. Mentor phải chọn lại Associate Track. Khớp → tiếp tục các nhánh status tiêu chuẩn của Duplicate Account Check. Mô phỏng theo UC_2.6.2 BR_2.6.2.12 (BN-17). ⚠️ UC_2.6.2 (tài liệu checkout, BA owner Huyen Dinh) chưa được cập nhật nhánh này. (Nguồn: CHR-145)

BR_8.2.13.27: Late-Linking — Role Pod Leader + Quyền truy cập kênh riêng khi /link Khi người dùng chạy /link và Pod_Leader_Registry có bản ghi với Leader_ID = user_id VÀ Status NOT IN ('Terminated', 'Permanently_Ineligible'), bot PHẢI (1) gán role Pod Leader và (2) cấp cho người dùng đó quyền truy cập theo từng người dùng vào kênh pod của chính họ (Users.channel_url). Áp dụng cho cả Founding Mentors (Flow 1.5) và Pod Leader thông thường (Flow 15B — BR_8.2.10.11). Chạy cùng với đồng bộ level-title (UC_8.1.1) và đồng bộ Pod Member (UC_8.2.1 A-04). ⚠️ UC_8.1.1 (handler /link, BA owner Huyen Dinh) chưa được cập nhật nhánh này. (Nguồn: QnA_Level_Promotion §3.3 nguyên tắc late-linking, 2026-09-30; Quyết định BA 2026-10-30 — quyền truy cập kênh được cấp tại thời điểm link)

BR_8.2.13.28: Discord Token của Founding Mentor — Được tạo trong Flow 1.5, không bao giờ bị ghi đè Token từ Bước 7.5 là token mà mentor nhận được trong email chào mừng. Bất kỳ bước tạo token nào sau đó (ví dụ: checkout [CHR-91] khi mentor sử dụng coupon) KHÔNG ĐƯỢC ghi đè discord_link_token đã tồn tại. Nếu không, token đã gửi qua email sẽ mất hiệu lực. ⚠️ UC_2.7-2.8 (checkout [CHR-91], BA owner Huyen Dinh) chưa được cập nhật điều kiện bảo vệ này. (Nguồn: Quyết định BA 2026-10-30; QnA [DL-EP-02])

BR_8.2.13.29: Lỗi kênh Discord — Không rollback DB; Thử lại 3× rồi SEV-1 Cùng quy tắc với BR_8.2.10.9. Nếu POST /create-pod-channel thất bại hoặc timeout, bản ghi Pod_Leader_Registry KHÔNG ĐƯỢC rollback. Middleware thử lại với exponential backoff (3 lần); nếu tất cả thất bại, kích hoạt SEV-1 alert đến #ops-it để Ops tạo kênh thủ công và cập nhật channel_url trong DB. Bước 7, 7.5 và 8 không bị chặn. (Nguồn: Quyết định BA 2026-10-29 — thống nhất với Flow 15B)

Mô hình dữ liệu

Bảng Users (các trường liên quan được thêm/cập nhật bởi luồng này)

Bảng Pod_Leader_Registry — các trường được ghi bởi luồng này

Tham chiếu API

Template Email

Tiêu chí chấp nhận