StackTrading Docs
BA — Business AnalysisUC 8.1–8.5UC 8.2.1

UC 8.2.1

Flow 10 - Pod Joining: mời trader LIVE tham gia Pod, nhận Trading Style qua Typeform, ghép với Pod Leader phù hợp hoặc đưa vào waitlist

FieldValue
BA in ChargeAnh Hoang
Date Created2026-10-12
Versionv1.13
Document ReferencesZapier Integration V7.pdf (§Flow 3 — Pod Invite, §Flow 10, §3.1 Table C, §3.3 Table E) · RFQ_ Stack Trading Prop Tech V7.pdf (§Match Pod Mentor, §Manage Discord Role, §4.4 #11) · Discord Server Details.md (§pod-[leader_name]) · QnA from clients — STAGE 6: Pod System Flow 10 → 11 (POD-JOIN-01…29, POD-PLAN-07/11, POD-WAIT-15/22, POD-XF-07) · QnA_init_docs.md (A-01…A-08) · CHR-127 (Typeform embedding standard) · Common Rules CR-08, CR-15.2, CR-18

UC_8.2.1 — Flow 10: Pod Joining

🇻🇳 Section này viết bằng tiếng Việt để BA review. Mọi ID, anchor, tên field/API và text hiển thị cho user giữ nguyên tiếng Anh.

1. Overview

FieldContent
IDUC_8.2.1
Use CaseFlow 10: Pod Joining
DescriptionUC này mô tả cách trader LIVE tham gia Pod. Pod là nhóm mentorship gồm 1 Pod Leader và tối đa 7 mentee. Trader nhận lời mời, chọn phong cách giao dịch (Trading Style), rồi được hệ thống ghép vào pod của một leader phù hợp. Nếu chưa có leader phù hợp còn chỗ thì trader được xếp vào hàng chờ (waitlist).
Phạm viUC này gồm: điều kiện làm mentee, thứ tự chọn Pod Leader và bước gán pod. Không gồm: xử lý waitlist sau khi trader đã vào hàng (UC_8.2.8), nhắc hạn nộp Trading Plan (UC_8.2.4), thẻ My POD trên Dashboard (UC_4.14.2).
Zapier FlowFlow 10: Mentorship Opt-In & Trading Plan Submission (Step 1 đến Step 5)
Zapier TableTable C — Global_Variables (Pod_Max_Capacity, Min_Pod_Leader_Level) · Table E — Pod_Leader_Registry (Trading_Style, Asset_Class, Max_Capacity, Current_Count, Status)
APIMatch Pod Mentor API · API Manage Discord Role (POST /manage-discord-role)
Cron Job taskKhông có
3rd PartyTypeform, AWS SES, Klaviyo, Discord, Slack

2. Trigger

  • Flow 3 (Live Onboarding) gửi xong email Live_Onboarding_Level_1 cho trader. Zapier chạy Flow 10 ngay sau đó để gửi email mời.
  • Trader gửi form Style trên Typeform. Hệ thống bắt đầu tìm pod cho trader.
  • Trader đã có pod nhưng lúc đó chưa liên kết Discord, nay mới liên kết. Middleware gán role Pod Member cho trader (§5.6).

3. Pre-conditions

  • Trader có tài khoản LIVE đang hoạt động và đang ở Level 1 đến Level 6 (BR_8.2.1.1).
  • Trader chưa thuộc pod nào và không đứng trong waitlist.

4. Post-conditions

Khi trader được ghép pod:

  • Trader thuộc pod của một Pod Leader. Status pod của trader là Assigned.
  • Số mentee hiện có của leader đó (Current_Count) tăng thêm 1.
  • Hạn nộp Trading Plan (Plan_Due) được mở cho trader.
  • Trader nhận email Pod_Assignment_Confirmation.
  • Bot Discord đã đăng tin chào trader trong kênh pod.
  • Từ đây mentee không tự đổi pod hay rời pod được, xem BR_8.2.1.3.

Khi không ghép được:

  • Status pod của trader là Waitlist.
  • Trader nhận email Pod_Waitlist_Notification.

5. Basic Flow

5.1 Gửi lời mời (Flow 10 — Step 1)

Stage 1 — Gửi email mời

  1. Zapier gửi email Pod_Mentorship_Invite cho trader qua AWS SES. Nội dung email xem BR_8.2.1.4. Email có nút [Complete Intake Profile →] để mở form Style.
  2. Lời mời không hết hạn. Nếu trader không gửi form thì trader vẫn giao dịch bình thường, chỉ là không có pod.

5.2 Trader gửi form Style (Flow 10 — Step 2)

Stage 2 — Mở form

  1. Trader mở form bằng một trong 2 cách:
    • Bấm nút [Complete Intake Profile →] trong email mời.
    • Bấm nút [Join a POD] trên thẻ My POD của Dashboard (Ref: UC_4.14.2 BR_4.14.2.4).
  2. Cả 2 cách đều mở trang wrapper trên stacktrading.com. Trang wrapper là trang của Stack Trading có nhúng form Typeform bên trong. Trader phải đăng nhập mới xem được trang này.
  3. Trang wrapper lấy user_id từ phiên đăng nhập và đưa vào hidden field của form. Hidden field là trường ẩn: trader không nhìn thấy, nhưng giá trị được gửi kèm kết quả form để hệ thống biết ai đã gửi.
  4. Nếu trader đã gửi form trước đó thì trang wrapper không hiện form, xem E_8.2.1.1.

Stage 3 — Gửi form

  1. Trader chọn đúng 1 Trading Style trong 4 lựa chọn Scalping, Day Trading, Swing Trading, Algorithmic Trading, rồi bấm gửi. Form không hỏi Asset_Class. Nội dung form xem BR_8.2.1.4.
  2. Typeform gửi kết quả form sang Zapier Flow 10.

5.3 Tìm pod cho trader (Flow 10 — Step 3)

Stage 4 — Middleware kiểm tra trader

  1. Zapier gọi Match Pod Mentor API để Middleware tìm pod cho trader:

    Input fieldValue
    user_idUUID của trader, lấy từ hidden field của form
    styleTrading Style trader đã chọn ở bước 7

    Zapier không gửi asset_class. Output của API xem BR_8.2.1.6.

  2. Middleware kiểm tra input. Nếu thiếu field hoặc style sai giá trị thì Middleware trả lỗi, xem E_8.2.1.2.

  3. Middleware khoá dòng của trader trong bảng Users. Trong lúc Middleware đang xử lý trader này, mọi lần xử lý khác cho cùng trader phải chờ. Nhờ vậy, nếu trader gửi form 2 lần cùng lúc thì chỉ có 1 kết quả. Dữ liệu dùng khi ghép pod xem BR_8.2.1.5.

  4. Middleware kiểm tra trader có được làm mentee không, theo BR_8.2.1.1. Nếu trader không đủ điều kiện thì Middleware bỏ qua lần gửi này, xem E_8.2.1.3.

  5. Middleware lưu Style trader đã chọn vào profile của trader trong bảng Users.

Stage 5 — Chọn Pod Leader

  1. Middleware đọc Asset_Class của trader trong bảng Users, rồi chọn Pod Leader theo thứ tự ở BR_8.2.1.2. VD: trader Forex chọn Style Scalping. Có 2 leader Forex còn suất nhận Scalping: leader A có 5 mentee, leader B có 6 mentee. Middleware chọn leader A.
  2. Có leader phù hợp thì Middleware chuyển sang §5.4 Gán pod. Không có leader phù hợp thì Middleware chuyển sang §5.5 Vào waitlist.

5.4 Gán pod (Flow 10 — Step 4)

Phần này được chạy từ 2 nơi:

  • Từ Flow 10: Stage 6 và Stage 7 chạy bên trong Match Pod Mentor API, trước khi API trả kết quả cho Zapier.
  • Từ UC_8.2.8: Middleware chạy phần này khi trader trong waitlist bấm xác nhận suất. Khi đó không có Zap nào gọi API. Middleware tự làm cả bước gán role Discord ở Stage 8.

Stage 6 — Ghi database

  1. Middleware khoá dòng của leader được chọn, để không có lần ghép nào khác lấy suất của leader này cùng lúc (Ref: BR_8.2.1.5).

  2. Middleware ghi cùng lúc các thay đổi sau:

    • Ghi Leader_ID của leader vào Users.pod_leader_id của trader.
    • Đổi status pod của trader thành Assigned.
    • Tăng Current_Count của leader thêm 1.
    • Ghi pod_join_date là thời điểm gán pod (Ref: CR-08). Ngày này dùng để tính chu kỳ gửi survey cho mentee (UC_8.2.6).
    • Mở Plan_Due, là hạn nộp Trading Plan của trader. Hạn này là 72 giờ liên tục tính từ lúc gán pod, kể cả thứ Bảy và Chủ nhật. VD: trader được gán pod lúc 10:00 thứ Sáu thì Plan_Due là 10:00 thứ Hai. Cách nhắc hạn xem UC_8.2.4.

    Nếu có lỗi giữa chừng thì Middleware huỷ toàn bộ các thay đổi trên. Vì vậy không bao giờ có trường hợp Current_Count đã tăng mà trader chưa có pod_leader_id.

  3. Nếu trader đã có PDF Trading Plan thì Middleware không mở Plan_Due và trader không phải nộp lại. Trader đã có PDF khi trader đã nộp lúc còn ở waitlist, hoặc đã nộp ở pod trước rồi đổi pod. Thay vào đó, Middleware làm 3 việc (Ref: UC_8.2.2 BR_8.2.2.4):

    • Tự phân tích bản PDF đã nộp.
    • Gửi webhook TRADING_PLAN_ANALYZED.
    • Mở Induction_Due cho leader mới. Đây là hạn để leader họp induction với mentee, bằng 5 ngày lịch tính từ lúc gán pod. VD: trader được gán pod lúc 10:00 ngày 1 thì Induction_Due là 10:00 ngày 6.

Stage 7 — Báo cho trader

  1. Middleware gửi sự kiện Pod_Assignment_Confirmation sang Klaviyo. Klaviyo dùng sự kiện này để gửi email cho trader (Ref: BR_8.2.1.5). Email bắt buộc có:

    • Thông tin Pod Leader và quyền vào Discord.
    • Link form Trading Plan. Email là đường chính thức để mentee nhận link này, kể cả khi mentee không mở Discord.
    • Lời nhắc liên kết Discord, nếu trader chưa liên kết.

    Danh sách biến của sự kiện xem BR_8.2.1.6. Klaviyo lỗi xem E_8.2.1.7.

  2. Nếu đi từ Flow 10, Match Pod Mentor API trả 200 OK cho Zapier với match_found là true, leader_id là mã leader được gán và status là Assigned.

Stage 8 — Discord

  1. Khi status trả về là Assigned, Zapier gọi API Manage Discord Role (POST /manage-discord-role) để gán role Pod Member cho trader. Chi tiết input, output xem BR_8.2.1.6.

    Input fieldValue
    user_idUUID của trader
    add_rolePod Member

  2. Middleware cho bot Discord gán role bằng discord_user_id của trader, rồi trả 200 OK. discord_user_id là mã tài khoản Discord, được lưu khi trader liên kết Discord. Nếu trader chưa liên kết Discord thì xem E_8.2.1.8. Nếu Discord lỗi thì xem E_8.2.1.9.

  3. Bot đăng tin chào trader (welcome ping) công khai trong kênh pod pod-[leader_name], không gửi tin nhắn riêng. Tin chào tag trader bằng <@discord_user_id>. Tin này cũng là cách báo cho Pod Leader biết có mentee mới. Nội dung tin xem BR_8.2.1.4. Nếu kênh pod không tồn tại thì xem E_8.2.1.10.

5.5 Vào waitlist (Flow 10 — Step 5)

Stage 9 — Đưa trader vào hàng chờ

  1. Middleware đổi status pod của trader thành Waitlist và ghi Join_Date là thời điểm trader vào hàng (CR-08). Trader đứng cuối hàng. Cách lưu waitlist xem BR_8.2.1.5.
  2. Middleware gửi sự kiện Pod_Waitlist_Notification sang Klaviyo để Klaviyo gửi email báo cho trader. Sự kiện chỉ gửi 1 lần lúc trader vào hàng, không gửi lặp lại trong lúc trader chờ. Danh sách biến xem BR_8.2.1.6. Klaviyo lỗi xem E_8.2.1.7.
  3. Match Pod Mentor API trả 200 OK cho Zapier với match_found là false, leader_id là null và status là Waitlist. Zap dừng, không gọi API Manage Discord Role.
  4. Từ đây, việc mời trader vào pod khi có suất trống thuộc UC_8.2.8.

5.6 Trader liên kết Discord sau khi đã vào pod

Bước này không có trong Flow 10 của khách, được bổ sung để trader chưa liên kết Discord lúc gán pod vẫn nhận được role Pod Member.

  1. Trader liên kết Discord thành công.
  2. Middleware kiểm tra trader đã có pod_leader_id chưa.
    • Đã có pod: Middleware tự gán role Pod Member, không đi qua Zapier, dùng cùng logic của API Manage Discord Role (BR_8.2.1.6).
    • Chưa có pod: Middleware không làm gì.
  3. Bot không đăng lại tin chào, vì tin chào đã được đăng lúc gán pod (bước 23).

6. Exceptional Flows

Exception IDExceptionConditionSystem Handling / Fallback
E_8.2.1.1Trader mở lại form đã gửiTrader đã có pod, hoặc đang ở status Waitlist, Pending_Pod_Confirmation hoặc Inactive_Hold, rồi mở lại link form.Trang wrapper không hiện form mà hiện dòng chữ You have already submitted this. Form chỉ nhận 1 lần gửi trong thời gian trader chưa có pod. VD: trader gửi form và vào waitlist. Hôm sau trader bấm lại link trong email thì thấy dòng chữ trên thay cho form. Nếu có lần gửi lọt qua trang wrapper thì Middleware vẫn bỏ qua ở bước 12 (E_8.2.1.3).
E_8.2.1.2Input không hợp lệGọi Match Pod Mentor API thiếu user_id hoặc style, hoặc style không thuộc 4 giá trị cho phép.Middleware trả 400 và không ghi gì vào database.
E_8.2.1.3Trader không đủ điều kiện ghép pod (Ref: BR_8.2.1.1, CR-18)Trader rơi vào một trong các trường hợp:- user_id không tồn tại.- Trader đã có pod (pod_leader_id đã có giá trị).- Trader đang ở status Waitlist, Pending_Pod_Confirmation hoặc Inactive_Hold.- Trader đã lên Level 7 trở lên.- Tài khoản LIVE không còn hoạt động, tức status là Terminated (trader LIVE bị Hard Breach hoặc Resign).Middleware bỏ qua lần gửi: không ghép pod, không ghi database, không gửi email. API vẫn trả 200 OK để Zap không bị báo lỗi. Zap dừng tại đây.
E_8.2.1.4Trader Waitlist_Ghost gửi lại formTrader từng bị loại khỏi waitlist vì không bấm xác nhận suất trong 48 giờ (status Waitlist_Ghost), nay gửi lại form.Middleware không bỏ qua mà ghép trader như người gửi form lần đầu. Nếu trader lại vào waitlist thì trader đứng cuối hàng, vì Join_Date được ghi theo lần gửi mới. VD: trader bị loại khỏi waitlist ngày 10, gửi lại form ngày 15 và không có leader phù hợp. Trader vào hàng với Join_Date là ngày 15, đứng sau mọi người đã vào hàng trước ngày 15.
E_8.2.1.5Nhiều trader tranh suất cuốiLeader chỉ còn 1 suất mà nhiều trader gửi form cùng lúc.Middleware khoá dòng của leader (BR_8.2.1.5) nên người được xử lý trước nhận suất. Những người sau được xét lại theo BR_8.2.1.2. Nếu không còn leader phù hợp thì họ vào waitlist và nhận email báo. VD: leader X còn 1 suất, trader A và B gửi form cùng lúc. A được xử lý trước nên vào pod của X. B được xét lại, không còn leader phù hợp nên vào waitlist và nhận email Pod_Waitlist_Notification.
E_8.2.1.6Lỗi hệ thống khi tìm podDatabase lỗi hoặc hết thời gian chờ trong lúc chạy Match Pod Mentor API.Middleware trả 500 và huỷ toàn bộ phần đang ghi dở, database giữ nguyên như trước khi gọi. Zapier coi bước này là lỗi và hiện "Zap Error".
E_8.2.1.7Gửi sự kiện sang Klaviyo bị lỗiMiddleware gửi Pod_Assignment_Confirmation (bước 19) hoặc Pod_Waitlist_Notification (bước 25) không thành công.Middleware gửi 1 Slack alert Pod Assignment Downstream Error… vào #ops-general (nội dung xem BR_8.2.1.4). Việc gán pod hoặc vào hàng chờ không bị huỷ. Middleware không tự gửi lại sự kiện; Ops xử lý tay khi nhận alert.
E_8.2.1.8Trader chưa liên kết Discord lúc gán poddiscord_user_id của trader rỗng.API Manage Discord Role trả 200 OK và bỏ qua việc gán role, Zapier không bị báo lỗi (BR_8.2.1.6). Việc gán pod vẫn giữ nguyên. Bot vẫn đăng tin chào, nhưng thay phần tag bằng first_name và last_name của trader dạng chữ thường. Role được gán sau khi trader liên kết Discord (§5.6).
E_8.2.1.9Discord lỗi khi gán roleDiscord sập, quá giới hạn số lần gọi, hoặc không tìm thấy role. Áp dụng cho bước 22 và §5.6.Middleware gửi 1 Slack alert Pod Assignment Downstream Error… vào #ops-general và vẫn trả 200 OK, để Zapier không báo thêm "Zap Error" cho cùng một lỗi (BR_8.2.1.6). Việc gán pod không bị huỷ. Middleware không tự gán lại role; Ops xử lý tay khi nhận alert.
E_8.2.1.10Kênh pod không tồn tại (Ref: CR-15.2)channel_url của leader rỗng, hoặc kênh đã bị archive.Bot không đăng tin chào và không thử đăng lại. Việc gán pod vẫn bình thường. Hệ thống gửi Slack alert 🚨 ACTION REQUIRED: Missing Pod Channel vào #ops-general (nội dung xem BR_8.2.1.4). Operations nhận alert thì tạo hoặc link kênh, rồi thêm trader vào kênh bằng tay.
E_8.2.1.11Zapier gọi trùng (Ref: BR_8.2.1.6)Match Pod Mentor API được gọi lại cho trader đã ở status Assigned hoặc Waitlist.Middleware trả 200 OK và bỏ qua. Current_Count không bị tăng lần hai. VD: trader đã vào pod của leader X, API được gọi lại cho trader này thì Current_Count của leader X giữ nguyên.

Kênh Slack #ops-general: Prod dùng kênh C0BR8LRC5MK, Test dùng kênh #test-ops-general (C0BR6UXRR8D).

7. Business Rules

BR_IDRule Description
BR_8.2.1.1Ai được làm mentee: Pod chỉ dành cho trader LIVE. Trader SIM hoặc Evaluation không được vào pod.Mentee là trader từ Level 1 đến Level 6. Khi trader lên Level 7 (giá trị Min_Pod_Leader_Level trong Table C) thì được coi là tốt nghiệp và tự động rời pod (Ref: UC_8.1.1 Stage 2 bước 3).Trader từ Level 7 trở lên không làm mentee nữa. Kể cả khi trader từ chối làm Pod Leader thì trader vẫn là trader độc lập, không quay lại làm mentee.
BR_8.2.1.2Thứ tự chọn Pod Leader: Middleware chỉ xét leader có Status là Active và còn suất. Còn suất nghĩa là số mentee hiện có (Current_Count) nhỏ hơn số mentee tối đa của leader đó (Max_Capacity trong Table E). VD: leader có Max_Capacity là 7 và đang có 6 mentee thì còn 1 suất. Leader Suspended, Terminated hoặc Permanently_Ineligible không được xét.Trong các leader đó, Middleware chọn theo thứ tự:1. Cùng Asset_Class (bắt buộc). Mỗi trader chỉ có 1 Asset_Class, lưu lúc checkout theo nền tảng trader chọn. Không bao giờ ghép trader Forex với leader Futures hoặc ngược lại, kể cả khi leader đó còn suất.2. Cùng Trading Style (ưu tiên, không bắt buộc). Style khớp khi Style của trader nằm trong danh sách Style của leader. Nếu không leader nào khớp Style thì Middleware bỏ tiêu chí này và xét mọi leader cùng Asset_Class.3. Ít mentee nhất, để chia đều mentee cho các pod. VD: Pod A có 5 mentee, Pod B có 6 mentee thì chọn Pod A.4. Nếu vẫn bằng nhau thì chọn leader có Leader_ID nhỏ hơn, tức là leader đăng ký sớm hơn.Middleware không dùng điểm survey (UC_8.2.6) hay kết quả audit (UC_8.2.7) để chọn leader.Flow 11 (UC_8.2.8) dùng lại tiêu chí 1 và 2. Tiêu chí 3 được thay bằng thời gian chờ: ai vào hàng sớm hơn (Join_Date cũ hơn) thì được mời trước.
BR_8.2.1.3Thay đổi sau khi đã vào pod: Dashboard không có nút để mentee tự đổi pod hoặc tự rời pod. Muốn đổi leader hoặc rời pod thì mentee liên hệ Support. Operations xử lý qua POST /admin-pod-reassignment (BPS). Nếu lần đổi pod gần nhất chưa đủ 30 ngày thì yêu cầu bị từ chối (Ref: UC_8.2.9). VD: mentee được đổi pod ngày 1, yêu cầu đổi tiếp vào ngày 20 bị từ chối vì mới được 19 ngày.Hệ thống không tự ghép lại pod khi mentee muốn đổi Style.Rời kênh Discord không có nghĩa là rời pod, vì database mới là nguồn chuẩn. Nếu mentee lỡ rời kênh thì gửi support ticket để admin cho bot thêm mentee lại vào kênh.
BR_8.2.1.4Nội dung tin nhắn: xem chi tiết tại §7.1.
BR_8.2.1.5Dữ liệu dùng khi ghép pod: Middleware (Node.js) ghép pod bằng câu lệnh SQL trên bảng Pod_Leader_Registry, không dùng Python Script.Pod_Leader_Registry nằm trực tiếp trong PostgreSQL của Middleware. "Table E" chỉ là tên gọi trong tài liệu, bảng này không cần đồng bộ với Zapier. Kết quả form không lưu vào Table E.Middleware khoá dòng của leader khi đọc và tăng Current_Count, để 2 lần ghép cùng lúc không làm số mentee vượt quá Max_Capacity. VD: leader còn 1 suất và 2 trader được ghép cùng lúc thì chỉ 1 trader lấy được suất.Chỉ Middleware được ghi cột Current_Count. Flow khác muốn đổi giá trị này phải gọi Middleware.Middleware so với Max_Capacity riêng của từng leader. Pod_Max_Capacity trong Table C (mặc định là 7) chỉ là giá trị gán sẵn khi tạo leader mới. VD: leader mới được tạo với Max_Capacity là 7, sau đó được đổi thành 5 thì Middleware so với 5.Bảng Users lưu pod_leader_id, pod_join_date, Trading Style, status pod (Assigned, Waitlist và các status khác) và Join_Date. Status hàng chờ là Waitlist, không có bộ đếm Pod_Waitlist_Count. Cách lưu waitlist do BE quyết định.Email Pod_Assignment_Confirmation và Pod_Waitlist_Notification do Klaviyo gửi. Middleware chỉ gửi sự kiện sang Klaviyo, Sotatek không dựng nội dung email trong Node.js hay Zapier.
BR_8.2.1.6Input, output của API và sự kiện Klaviyo: xem §7.2.

7.1 BR_8.2.1.4 — Nội dung tin nhắn

Giữ nguyên văn tiếng Anh do khách cung cấp.

Email Pod_Mentorship_Invite (Zapier gửi qua AWS SES)

Hello [First Name], Congratulations on reaching the live desk. To help you continue your progression, you are now eligible to join a Trading Pod. Pods are designed to group you with a mentor and a team of traders who focus on similar instruments and trading style as you. The mentorship program is built around the discipline of following a structured trading plan, which you will develop in the next step, to keep you accountable to your risk model. To begin, we need to match you with a relevant mentor. Please click the link below to complete your intake profile so our routing engine can assign your seat. [Complete Intake Profile →] Note: Seats are assigned based on availability. If your specific asset class and style are at capacity, you will be placed on the priority waitlist. Footer: Stack Trading | support@stacktrading.com

Nút [Complete Intake Profile →] mở trang wrapper của form Style. Link không chứa user_id; user_id lấy từ phiên đăng nhập.

Form Style trên Typeform — Form 6: Pod Mentorship Intake (Asset & Style Matching)

Thành phầnNội dung
Form TitlePod Mentorship Intake
Hidden fielduser_id
Welcome ScreenMentorship at Stack Trading is reserved for those committed to institutional growth. To pair you with the correct Pod Leader, we need to define your market and execution style. Submit your profile below to initiate the matching engine.
Question 1 (Multiple Choice, Required)Select your primary Trading Style:
Hint của Question 1This determines your mentor pairing. Choose the execution style that dominates your trading plan. Note Swing Trading Futures is not viable as a primary strategy until higher levels due to CME overnight margin restrictions.
OptionsScalping, Day Trading, Swing Trading, Algorithmic Trading
Ending ScreenProfile submitted. Our routing engine is scanning the Pod Leader Registry for an exact match. If a seat is available, you will receive your Discord channel assignment and Trading Plan blueprint shortly. If your targeted mentors are at full capacity, your position will be secured on the priority waitlist.

Form chỉ có 1 câu hỏi và không hỏi Asset_Class.

Trang wrapper khi trader đã gửi form

You have already submitted this

Welcome ping trong kênh pod. <@discord_user_id> là phần tag trader. Nếu trader chưa liên kết Discord thì phần này thay bằng first_name last_name dạng chữ thường.

Welcome to the Pod, <@discord_user_id>! You have 72 hours to complete and submit your mandatory Trading Plan. Your Pod Leader will review your submission and schedule your 1-on-1 induction sync. Submit your plan here: [Typeform_Link]

[Typeform_Link] là link trang wrapper của form Trading Plan. Link không chứa user_id, nên nếu người khác trong kênh bấm link thì trang mở theo phiên đăng nhập của chính họ và họ không nộp thay được.

Slack #ops-general khi kênh pod không tồn tại

🚨 ACTION REQUIRED: Missing Pod Channel Leader ID: [Insert Leader_ID] Leader Name: [Insert Leader_Name] Error: The Discord bot attempted to post a welcome ping for a newly assigned mentee, but the channel URL is NULL or the channel is archived. Status: The mentee's database assignment was successful, but they do not have Discord access. Please manually create or link the channel and assign the mentee.

Slack #ops-general khi gửi sự kiện Klaviyo hoặc gán role Discord bị lỗi. Mỗi lỗi chỉ gửi 1 alert.

Pod Assignment Downstream Error: Failed to dispatch Klaviyo/Discord event for User [user_id] in Pod [pod_leader_id].

Khi trader vào hàng chờ thì trader chưa có pod_leader_id, nên phần [pod_leader_id] để trống.

7.2 BR_8.2.1.6 — Input, output của API và sự kiện Klaviyo

Đường dẫn và định dạng chi tiết của API do Sotatek chốt trong OpenAPI spec của Middleware. Mọi thời điểm ghi database theo chuẩn CR-08.

Match Pod Mentor API — Zapier Flow 10 gọi mỗi lần trader gửi form Style (bước 9).

Input fieldKiểuBắt buộcGhi chú
user_idUUID✅Lấy từ hidden field của form Style
styleString✅Đúng 1 trong 4 giá trị Scalping, Day Trading, Swing Trading, Algorithmic Trading
Output field (200 OK)KiểuGhi chú
match_foundBooleantrue khi trader được gán pod
leader_idString hoặc nullLeader_ID của leader được gán. null khi trader không được gán pod
statusStringAssigned khi trader được gán pod. Waitlist khi trader vào hàng chờ. Khi Middleware bỏ qua lần gửi (E_8.2.1.3), status không phải 2 giá trị này; cách thể hiện cụ thể do BE chốt trong OpenAPI spec

Mã lỗi: xem E_8.2.1.2, E_8.2.1.3, E_8.2.1.6, E_8.2.1.11.

API Manage Discord Role (POST /manage-discord-role) — Zapier Flow 10 gọi khi Match Pod Mentor API trả status là Assigned (bước 21).

  • Endpoint dùng chung với Flow 4 (UC_8.1.1), nơi endpoint dùng để đổi title theo Level và gỡ role Pod Member khi trader tốt nghiệp.
  • Khi UC_8.2.8 dùng lại §5.4, và khi trader liên kết Discord muộn (§5.6), không có Zap gọi endpoint. Middleware tự gán role với cùng input và cùng cách xử lý như dưới đây.
Input fieldKiểuBắt buộcGhi chú
user_idUUID✅
add_roleString❌Tên role cần thêm. Trong UC này là Pod Member
remove_roleString❌Tên role cần gỡ. UC này không dùng

Mỗi lần gọi phải có ít nhất add_role hoặc remove_role. Output là 200 OK, không có nội dung trả về.

Tình huốngPhản hồiGhi dữ liệu
Thiếu user_id, hoặc thiếu cả add_role lẫn remove_role400Không
user_id không tồn tại200 OK, bỏ qua. Zapier không bị báo lỗiKhông
Trader chưa liên kết Discord (discord_user_id rỗng)200 OK, bỏ qua. Zapier không bị báo lỗiKhông
Discord lỗi200 OK, kèm 1 Slack alert vào #ops-generalKhông. Việc gán pod vẫn giữ nguyên
Thêm role trader đã có, hoặc gỡ role trader không có200 OK, không thay đổi gìKhông

Sự kiện gửi sang Klaviyo — Middleware gửi sự kiện, Klaviyo tự gửi email cho trader. Mỗi sự kiện chỉ gửi 1 lần cho mỗi lần trader được gán pod hoặc vào hàng chờ.

Sự kiệnGửi khiBiến tối thiểu
Pod_Assignment_ConfirmationStage 6 đã ghi database xong (bước 19)Mã trader, email trader, tên Pod Leader, link kênh pod, link trang wrapper của form Trading Plan (không chứa user_id), và trader đã liên kết Discord hay chưa. Biến cuối cùng giúp email chèn lời nhắc liên kết Discord
Pod_Waitlist_NotificationStage 9 đã ghi database xong (bước 25)Mã trader và email trader

8. Open Items

Không còn hạng mục mở. Chi tiết: QnA_init_docs.md.

9. Phân chia trách nhiệm

Hạng mụcSotatek buildStack Trading OpsBên thứ 3 tự chạy
Form Style trên Typeform và cấu hình gửi kết quả sang Zapier✅—Typeform
Zap Flow 10 gửi Pod_Mentorship_Invite (template và biến)✅✅ Cung cấp copy (đã gửi)AWS SES
Match Pod Mentor API: ghép pod, gán pod, mở Plan_Due, đưa vào waitlist✅——
Gửi sự kiện Pod_Assignment_Confirmation, Pod_Waitlist_Notification✅❓ Ai dựng template trong KlaviyoKlaviyo
Slack alert lỗi sau khi gán pod (Klaviyo, Discord)✅✅ Xử lý tay khi nhận alert—
Trang wrapper có đăng nhập cho form Style, form Trading Plan và chặn gửi lần 2✅——
API Manage Discord Role, bot Discord: gán role, welcome ping, Slack alert thiếu kênh✅✅ Copy (đã gửi), tạo hoặc link kênh khi nhận alert—
Đổi pod theo yêu cầu (BPS)✅ Endpoint và cooldown 30 ngày✅ Thao tác—

Changelog

DateVersionUpdated itemBeforeAfterNotes
2026-10-12v1Initial document——Bản tiếng Việt để BA re-check trước khi chuyển tiếng Anh. Viết lại từ đầu theo template UC_8.1.1 (bản 2026-10-09 đã xoá). Nguồn chính: QnA POD-JOIN-01…28, POD-PLAN-07, POD-FDBK-09, POD-WAIT-03/04/15, POD-XF-07/08. Spec V7 bị QnA thay thế: form bỏ câu Asset_Class và Match Pod Mentor bỏ input asset_class (POD-JOIN-03); Style chỉ là ưu tiên, không bắt buộc (POD-JOIN-06); bỏ "Python Script" (POD-JOIN-04); status Pod_Waitlist → Waitlist, bỏ bộ đếm Pod_Waitlist_Count (POD-WAIT-15); Pod_Assignment_Confirmation do Klaviyo gửi thay vì Zapier (POD-JOIN-20/22). Ghi nhận lệch nguồn ngoài phạm vi: Discord Server Details.md ghi audience kênh pod "Level 6 and above" — UC này theo QnA (mentee Level 1–6).
2026-10-12v1.1Thêm mục API & CronEndpoint chỉ được nhắc 1 dòng trong BR_8.2.1.5Mục API & Cron: spec đầy đủ Match Pod Mentor, POST /manage-discord-role, sự kiện Klaviyo (input, output, xử lý, lỗi, gọi trùng). Basic Flow trỏ tới từng API; BR_8.2.1.5 rút các dòng APIMã lỗi 400/401/500, status Skipped và biến tối thiểu sự kiện Klaviyo do BA định nghĩa theo RFQ_ Stack Trading Prop Tech V7.pdf §4.4 #11, #19
2026-10-12v1Stage 4 bước 6 · BR_8.2.1.4 — kênh Slack thiếu kênh pod"Operations" (khách ghi), chờ chốt P-01#ops-generalBA chốt: map kênh khách ghi sang kênh Slack hiện có trong CR-15.2 (khách ghi nhầm tên kênh).
2026-10-12v1.2Basic Flow — mô tả lời gọi APIBước gọi API chỉ gắn "(Ref: API_x)", không rõ bên gọi / bên nhận / kết quảMỗi bước gọi giữa các hệ thống ghi dạng [Bên gọi → Bên nhận] tên API + input chính → kết quả; rẽ nhánh Stage 3 theo status trả về (Assigned / Waitlist / Skipped); ghi rõ Stage 4–5 chạy bên trong Match Pod Mentor—
2026-10-13v1.3Dùng tên API gốc; bỏ tên tự đặtStatus Skipped của Match Pod Mentor; tên API viết Match Pod Mentor / POST /manage-discord-roleTrường hợp bỏ qua mô tả bằng lời ("trả 200 OK, bỏ qua, không ghi gì"); tên API theo nguồn: Match Pod Mentor API, API Manage Discord Role (POST /manage-discord-role) ở tiêu đề API, bảng tóm tắt, Basic FlowChỉ giữ tên có trong nguồn; tên cụ thể do BE chốt trong OpenAPI spec (RFQ_ Stack Trading Prop Tech V7.pdf §4.4 #11)
2026-10-13v1.4Basic Flow Stage 2 bước 2 — bên gọi Match Pod Mentor APIGhi chắc chắn [Typeform → Middleware]Kết quả form chuyển tới Middleware (qua Zapier hay thẳng: Hạng mục mở #1), Middleware chạy Match Pod Mentor APIĐối chiếu client sheet Flow 10: nguồn không nói bên gọi
2026-10-13v1.5Stage 4 bước 1 — status pod khi gánKhông ghi status podGhi status pod = Assigned cùng lúc với pod_leader_id và Current_CountKhách chốt 2026-10-13 (POD-WAIT-22): Assigned là status trong database, thay cho Active_Pod_Member
2026-10-15v1.6Stage 1, Stage 2 bước 2–3, Stage 4 bước 6, Stage 6 (mới), BR_8.2.1.1, BR_8.2.1.2, BR_8.2.1.4, API_8.2.1.1; Hạng mục mởKết quả form đi qua Zapier hay thẳng: mở · chỉ bỏ qua khi đã có pod / Waitlist · chưa liên kết Discord thì welcome ping chưa rõ · liên kết Discord sau khi vào pod thì không ai gán role · chưa có copy Pod_Mentorship_Invite · 9 hạng mục mởTypeform → Zapier → Zapier gọi Match Pod Mentor API (A-01) · bỏ qua thêm Pending_Pod_Confirmation, Inactive_Hold, Level ≥ 7, LIVE không còn hoạt động; Waitlist_Ghost ghép như người mới, cuối hàng (A-02) · vẫn đăng welcome ping, thay tag bằng first_name last_name (A-03) · Stage 6: liên kết Discord sau → Middleware gán role Pod Member (A-04) · mỗi trader 1 Asset_Class (A-06) · gửi mời ngay khi Flow 3 hoàn tất (A-08) · thêm copy email mời (POD-JOIN-24) · còn 2 hạng mục mởA-01, A-02, A-04, A-08: BA chốt 2026-10-15. A-03: khách trả lời (POD-JOIN-29). A-06: không áp dụng — Zapier Integration V7.pdf Flow 1 lưu 1 Asset_Class/trader. Copy email mời: khách cung cấp 2026-10-15
2026-10-15v1.7Toàn UC — viết lại theo khuôn UC_8.1.xCó bảng "Giải thích thuật ngữ" ở đầu; mục "API & Cron" riêng liệt kê API_8.2.1.1 Match Pod Mentor API, API_8.2.1.2 API Manage Discord Role, API_8.2.1.3 Sự kiện Klaviyo; BR_8.2.1.5 "Thông tin kỹ thuật cho dev"; mục "Hạng mục mở" đặt sau RACIBỏ bảng thuật ngữ (giải thích ngay câu dùng lần đầu). Overview thêm dòng API (2 API đúng nguồn: Match Pod Mentor API, API Manage Discord Role) và Cron Job task (Không có). Basic Flow 6 Stage gắn với Step của Flow 10; input API ghi bảng ngay tại Stage 2 bước 3 và Stage 4 bước 6; mã lỗi 401/400/500 và các nhánh [If …] → ngay trong bước. BR_8.2.1.5 đổi tên theo nội dung "Dữ liệu dùng khi ghép pod"; thêm BR_8.2.1.6 "Match Pod Mentor API, API Manage Discord Role và sự kiện Klaviyo" (input, output, bảng lỗi, gọi trùng, biến sự kiện); anchor API_8.2.1.1–API_8.2.1.3 giữ trong BR_8.2.1.6. Sự kiện Klaviyo không còn đánh số API. "Hạng mục mở" → "Open Items", đặt trước RACI; nội dung 2 mục giữ nguyênĐồng bộ khuôn với UC_8.2.2 → 8.2.8 (commit 2026-10-15). Nội dung nghiệp vụ, BR_8.2.1.1–BR_8.2.1.4 và các quyết định v1.6 giữ nguyên. Nguồn API: client sheet Flow 10 ("Match Pod Mentor API", "API Manage Discord Role")
2026-10-15v1.8Stage 4 bước 3 — trader đã có PDF Trading PlanLuôn mở Plan_Due khi gán podĐã nộp Trading Plan khi còn ở waitlist → không mở Plan_Due; Middleware tự phân tích PDF mới nhất, gửi webhook, mở Induction_Due cho leader mớiTheo UC_8.2.2 A-04 (BA chốt 2026-10-15)
2026-10-16v1.9BR_8.2.1.4 — nội dung form StyleChỉ có danh sách 4 Style ở Stage 2 bước 1Thêm nội dung form Style (Form 6: Pod Mentorship Intake): Form Title, hidden field user_id, Welcome Screen, Question 1 + hint, 4 options, Ending ScreenTheo bảng template Stage 6 — POD system khách gửi
2026-10-16v1.10BR_8.2.1.6 — biến sự kiện Pod_Assignment_ConfirmationLink form Trading Plan gắn sẵn user_idGắn sẵn user_id, mentor_emailTheo UC_8.2.2 v1.11 (hidden field Form 3)
2026-10-22v1.11Stage 1 bước 1 · Stage 2 bước 5 · Stage 4 bước 4, 6 · Stage 5 bước 2 · BR_8.2.1.1, BR_8.2.1.4, BR_8.2.1.5 · API_8.2.1.1–3 · Open Items · Phân chia trách nhiệmKlaviyo / Discord lỗi sau khi gán pod: Open Items #1 · link form Style và Trading Plan gắn sẵn user_id trên link; welcome ping công khai chứa link: Open Items #2 · không chặn gửi form Style lần 2 ở phía formKlaviyo / Discord lỗi → không huỷ việc gán, 1 Slack alert #ops-general "Pod Assignment Downstream Error…", Discord lỗi trả 200 OK để không báo thêm "Zap Error"; thử lại 3 lần để Day 2 · form nhúng trang wrapper có đăng nhập, user_id lấy từ phiên đăng nhập; welcome ping giữ link, không chặn thêm · trang wrapper chặn gửi form Style lần 2, hiện You have already submitted this · Open Items: không cònKhách trả lời 2026-10-22: A-05, A-07 (kèm chặn gửi lần 2 cho mọi form). Kênh #operations khách ghi → #ops-general theo P-01
2026-10-22v1.11Basic Flow · Business Rules · Document References — kiểm tra chữ ký webhookBước kiểm tra chữ ký (HMAC/JWS), sai → 401 (RFQ V7 §4.4 #19)Bỏ toàn bộ bước kiểm tra chữ ký và các dòng 401BA chốt 2026-10-22: yêu cầu bảo mật chung, khách không nói riêng cho flow này
2026-10-22v1.11Stage 4 bước 3 — trader đã có PDF Trading PlanChỉ áp cho trader nộp lúc còn ở waitlistÁp cho mọi trader đã có PDF (nộp ở waitlist hoặc ở pod trước): dùng lại bản đã nộp, không mở Plan_Due, gửi PDF cho leader mới, mở Induction_DueKhách: đổi pod thì "The Trading Plan should just be reused" (UC_8.2.2 A-03)
2026-10-22v1.11Post-conditions · Stage 1 bước 1 · Stage 2 bước 5 · Stage 4 bước 1, 3, 4, 6, 7 · Stage 5 bước 2 · BR_8.2.1.1 · API_8.2.1.2Một số câu gộp nhiều ý trong 1 dòngTách thành các ý riêng (sub-bullet)Viết lại cho dễ hiểu, không đổi nghiệp vụ
2026-10-22v1.11Trigger · Stage 2 bước 5 · Stage 3 bước 1 · Stage 4 bước 4, 6, 7 · Stage 5 bước 2 · Stage 6 bước 2 · BR_8.2.1.1, BR_8.2.1.2 · API_8.2.1.2, API_8.2.1.3Một số câu viết tắt / mơ hồDiễn giải rõ nghĩaViết lại cho dễ hiểu, không đổi nghiệp vụ
2026-10-22v1.11Toàn UC — Basic Flow, Business RulesVăn phong ký hiệu, rút gọn, khó đọcViết lại bằng câu đầy đủ, kèm VDTheo mẫu BA duyệt 2026-10-22, không đổi nghiệp vụ
2026-10-22v1.11Basic Flow · Business Rules — cấu trúc lại theo flow gốcBasic Flow tự sắp xếp, tách rời Business RulesMỗi bước trích nguyên văn flow khách + bổ sung, edge case; BR ngắn gộp vào flow (giữ anchor), BR dài được trỏ từ flowTheo mẫu UC_8.2.2, không đổi nghiệp vụ
2026-10-29v1.12Toàn UC — cấu trúc lại theo khuôn UC_1.8.7Mỗi bước trích nguyên văn flow gốc của khách; mã QnA (POD-JOIN-xx, A-xx, CHR-127) nằm trong thân doc; BR và edge case trộn trong flow; bước không đánh số liên tục; có đoạn "Các điểm khác tài liệu gốc"Mục đánh số 1 đến 9; §5 chia 5.1 đến 5.6 theo Step của Flow 10, Stage và bước đánh số liên tục 1 đến 30; edge case gom vào bảng §6 Exceptional Flows (E_8.2.1.1 đến E_8.2.1.11); BR gom vào bảng §7, nội dung tin nhắn ở §7.1, API ở §7.2; điểm khác tài liệu gốc ghi thành rule ở BR_8.2.1.5; mã QnA chỉ giữ ở Document References và Changelog. Mọi BR đều được refer từ bước hoặc exception liên quan (BR_8.2.1.3 từ Post-conditions; BR_8.2.1.5 từ bước 11, 16, 19, 24 và E_8.2.1.5; API_8.2.1.2 từ bước 21, §5.6, E_8.2.1.8, E_8.2.1.9). Giữ nguyên anchor BR_8.2.1.1–BR_8.2.1.6, API_8.2.1.1–API_8.2.1.3, UC_8.2.1-stage-4BA yêu cầu viết dễ hiểu như UC_1.8.7, không đổi nghiệp vụ
2026-10-29v1.12§1 Overview — DescriptionMô tả chi tiết các bước, tên API, field và nhánh xử lýChỉ ghi tổng quan: UC dùng để làm gì và nội dung chính, bằng câu thường; chi tiết xem §5BA yêu cầu Description chỉ ghi tổng quan, không đổi nghiệp vụ
2026-10-29v1.12Các chỗ ghi status tài khoản Terminated / FailedGhi status không kèm nguyên nhân, hoặc ghi "resign hoặc bị terminate", "Resigned hoặc Terminated"Ghi kèm nguyên nhân: Terminated là trader LIVE bị Hard Breach hoặc Resign; Failed là trader SIM bị Hard Breach hoặc Resign. Không có status Resigned riêngBA yêu cầu 2026-10-29, để biết status xuất hiện khi nào
2026-11-03v1.13E_8.2.1.7, E_8.2.1.9 — Klaviyo / Discord lỗi sau khi gán podGhi "cơ chế tự thử lại 3 lần để Day 2"; E_8.2.1.7 thêm "nếu đã có hàm thử lại dùng chung thì dùng hàm đó"Bỏ mọi nội dung thử lại: lỗi là gửi ngay 1 Slack alert, Middleware không tự gửi lại sự kiện / gán lại role, Ops xử lý tayRetry 3 lần không thuộc scope hiện tại (khách đẩy sang Day 2)

QnA Init Docs — UC_8.2.1 (Flow 10 - Pod Joining)

Previous Page

UC 8.2.2

On this page

UC_8.2.1 — Flow 10: Pod Joining1. Overview2. Trigger3. Pre-conditions4. Post-conditions5. Basic Flow5.1 Gửi lời mời (Flow 10 — Step 1)5.2 Trader gửi form Style (Flow 10 — Step 2)5.3 Tìm pod cho trader (Flow 10 — Step 3)5.4 Gán pod (Flow 10 — Step 4)5.5 Vào waitlist (Flow 10 — Step 5)5.6 Trader liên kết Discord sau khi đã vào pod6. Exceptional Flows7. Business Rules7.1 BR_8.2.1.4 — Nội dung tin nhắn7.2 BR_8.2.1.6 — Input, output của API và sự kiện Klaviyo8. Open Items9. Phân chia trách nhiệmChangelog