QnA Init Docs — UC_8.1.1 (Flow 4A - Promotion)
UC liên quan: UC_8.1.1 — Flow 4A - Promotion
Trigger: Middleware Webhook Profit_Target_Hit
Agent tạo: Agent 2 (Challenger), theo system_init_workflow.md — Init Flow
Ngày tạo: 2026-09-30 (giả định — theo ngày session hiện tại)
Cập nhật lần 2: Đã bổ sung raw spec chi tiết hơn (client cung cấp thêm) — xem các mục đánh dấu 🆕 bên dưới.
⚠️ Lưu ý WBS (đã được user xác nhận bỏ qua):
UC_8.1.1KHÔNG tồn tại trong WBS hiện tại (node script/parse_wbs.js --compact). Chỉ cóUC_8.1(= Flow 6 - L6 Transition, KHÔNG phải Flow 4A). User đã chỉ đạo: "kệ đi có trong WBS đó chắc WBS hiện tại outdated" → tiếp tục dùngUC_8.1.1làm định danh cho Flow 4A - Promotion, không re-raise vấn đề này, không tự thêm dòng WBS mới trừ khi được yêu cầu.
⚠️ [CROSS_UC_CONFLICT] — Overlap với WBS rows đã tồn tại (Phase 2.2, MANDATORY)
Theo WBS hiện tại (category STAGE 6: CAREER PATH & PROFESSIONALIZATION), 2 UC sau đã có row riêng và overlap trực tiếp với nội dung Flow 4A vừa paste:
| WBS UC_ID | Function | Overlap với Flow 4A |
|---|---|---|
UC_8.4.3 | Level 24 Prestige Reset | Trùng hoàn toàn với Stage 1 — "Prestige Reset Check for Level 24" (Sweep Profit, Pay Bonus, Reset Account, Freshdesk ticket CEO/Exec review) |
UC_8.4.1 | Flow 4B - Drawdown Defense (L9+) | Liên quan tới Stage 2 — "Recharge Check for Defense Protocol (Levels 9-17)" — đây là điểm giao giữa Flow 4A (promotion trigger) và Flow 4B (defense/drawdown trigger) |
UC_8.4.2 | Defense Recharge (2 mechanisms) | Cùng vùng logic recharge-check nêu trên |
Không có UC_ID riêng cho core pipeline Stage 1-5 (Ledger Reset, Immutable Ledger Logging, Discord Promotion, Data Fee Refund, Klaviyo/Everflow) — đây đúng là phần mà UC_8.1.1 đang được dùng để đại diện.
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|---|---|---|---|
| A-00 | UC_8.1.1 (Flow 4A - Promotion) có nên chỉ giữ core pipeline (Stage 1 dedup/lock, Stage 2 ledger reset + param calc, Stage 3 ledger update/logging/Discord, Stage 4 data fee refund, Stage 5 Klaviyo/Everflow), vàtách riêng phần Level 24 Prestige Reset sang UC_8.4.3 để tránh duplicate content giữa 2 file? | Đề xuất: UC_8.1.1 viết Level 24 Prestige Reset như 1Basic Flow branch ngắn (trigger condition + link sang UC_8.4.3), KHÔNG viết lại full BR — full BR (Sweep Profit mechanics, Freshdesk ticket, CEO/Exec review) thuộc về UC_8.4.3 khi UC đó được viết. Recharge Check (Defense Protocol) tương tự — chỉ nêu trigger condition trong UC_8.1.1, cross-ref UC_8.4.1/8.4.2 cho chi tiết. | Không nha xóa cái UC dành cho level 24 đi. viết hết vào cùng UC 8.1.1 | ✅ Đã chốt — giữ nguyên UC_8.4.1/8.4.2/8.4.3, viết chi tiết Level 24 trong cùng UC_8.1.1, không tách sang UC khác. |
| A-00b 🆕 | Raw spec (bản bổ sung) cho thấyEverflow Partner/Affiliate onboarding + tracking + tiered commission là 1 khối logic rất lớn và độc lập (partner registration screen trên activation flow, JS SDK/cookie capture tại checkout, POST /everflow/register-partner, tier table 3 mức, S2S postback cho MỌI checkout thành công — không chỉ Level 6). Phần này có thực sự thuộc scope UC_8.1.1 (Career Path Promotion) hay thuộc 1 UC khác (Checkout / Partner-Affiliate Onboarding)? | Đề xuất: UC_8.1.1 (Flow 4A) chỉ nên giữđúng 1 điểm chạm — Level 6 bounty trigger point (verify everflow_transaction_id đã tồn tại trên user record → fire S2S postback với event_id + everflow_transaction_id, KHÔNG có bounty_amount, xem A-20). Toàn bộ phần còn lại (partner registration screen, JS SDK/cookie capture, st_affiliate_data, S2S fail-open, POST /everflow/register-partner, Velocity Group profile, tier table 15%/20%/25% + CAC, "Other Conversion Events" postback cho mọi checkout, Zapier Flow 32 milestone 3/6) thuộc về Checkout flow (Zapier Flow 1) hoặc 1 UC riêng cho Partner/Affiliate onboarding — KHÔNG lặp lại trong UC_8.1.1, chỉ cross-ref. | 1. đúng là t chỉ cần điểm chạm thôi nhé2. phải mô tả rõ cơ chế của dev cần lam gì nhé đoan mà S2S ấy | ✅ Đã chốt — chỉ giữ 1 điểm chạm Level 6 bounty trong UC_8.1.1; cần bổ sung mô tả rõ cơ chế dev S2S khi viết SRS (theo ý 2 BA nêu) |
⚠️ [CR_CONFLICT] — CR-20260720-003 (Everflow, Active) vs QnA Round 4 (mới hơn)
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|---|---|---|---|
| A-01 | CR-20260720-003 (🔴 Active, ★★★★, "Everflow replaces Impact.com", ảnh hưởng trực tiếp Flow 4) yêu cầu payload S2S Postback mang biến động Level_6_Affiliate_Bounty (từ Zapier Table C). Nhưng QnA_Level_Promotion.md Round 4 (2026-09-27, mới hơn CR, client-confirmed) lại nói bỏ hẳn field bounty_amount — chỉ gửi event_id, để dashboard Everflow tự xử lý payout tier. CR thường thắng tuyệt đối theo rule, nhưng ở đây QnA lại là bản cập nhật SAU và cụ thể hơn cho đúng payload này. Ưu tiên bên nào? | Đề xuất: Coi QnA Round 4 làbản làm rõ/thu hẹp phạm vi của CR-20260720-003 cho riêng field bounty_amount (không phải override toàn bộ CR — CR vẫn đúng ở phần "Everflow thay Impact.com"), áp dụng QnA cho payload cụ thể này. Đồng thời đề xuất cập nhật CR_summary.md của CR-20260720-003 để ghi chú lại phần thu hẹp này, tránh future BA đọc CR mà làm sai payload. | Đã có sẵn trong QnA (Level Promotion Round 4, Section E, 2026-09-27): "Xoábounty_amount=500 khỏi payload S2S Postback — chỉ giữ event_id; Everflow dashboard tự cấu hình payout $500 theo event_id đó." → BA chốt dùng QnA cho payload, giữ CR cho phần vendor migration. | ✅ Đã chốt (QnA Round 4, Section E) — cần BA xác nhận có updateCR_summary.md không |
UC_8.1.1 — Flow 4A: Stage 1 (Dedup, Lock & Liquidate, Prestige Reset trigger, Frontend sequence)
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|---|---|---|---|
| A-02 | Idempotency key choPOST /lock-and-liquidate — nếu Middleware gửi lại cùng Event_ID do retry (network timeout) trong lúc request đầu vẫn đang xử lý (chưa trả response), có race condition không? | Đề xuất: DB unique constraint trênEvent_ID + xử lý theo kiểu "claim-first" (insert Event_ID vào bảng dedup TRƯỚC khi gọi /lock-and-liquidate, nếu insert fail do duplicate key → return 200 idempotent-noop ngay, không gọi lock lần 2). | không cần viết technical như này, bỏ đoạn này k cần viết chi tiết đâu | ✅ Đã chốt — bỏ đoạn technical idempotency chi tiết, không viết vào SRS |
| A-03 | Khi trader đạt Profit Target nhưng KHÔNG phải Level 24 — flow có tạo tài khoản trading mới hay giữ tài khoản cũ? | Đã có sẵn trong QnA (Level Promotion Round 2/3, mục A2): "KHÔNG provision tài khoản mới mỗi lần lên level — giữ nguyên tài khoản hiện tại, thực hiện lock + flatten + cancel orders + balance adjustment. Toàn bộ lịch sử trade cũ vẫn tồn tại trên Rithmic/TE/MT5, nhưng dashboard widget chỉ đọc data sau mốc thời gian promotion (timestamp boundary)." | Đã chốt — dùng nguyên văn QnA trên, override raw spec nếu raw spec ngụ ý provision account mới. | ✅ Đã chốt (QnA Round 2/3, mục A2) |
| A-04 | LVLPROMO-R3-A2 (chưa trả lời trong QnA): Khi balance adjustment xảy ra lúc promotion, PnL history trên từng platform (Rithmic/TE/MT5) là cộng dồn (accumulate) hay reset về 0 cho kỳ mới? | ⚠️ No safe default — số liệu PnL hiển thị sai có thể ảnh hưởng trực tiếp tới bonus calculation và certificate. Cần BA/client xác nhận trước khi viết Business Rule cho phần này. | sau khi đã clear position thì pnl về = 0.🆕 Double-confirm bởi STAGE6-006 (QnA_STAGE6_CAREER_PATH.md, 2026-09-30): sequence đúng là flatten toàn bộ position → confirm account 100% flat → ghi final realized PnL vào historical_pnl → mới reset active virtual equity ledger cho level mới. → PnL reset về 0 sau khi flatten, không mất số liệu vì đã snapshot vào historical_pnl trước đó. | ✅ Đã chốt — hết BLOCKED, gỡ khỏi Open Items cuối file. |
| A-05 🆕 | Frontend LEVEL_PROMOTION sequence — với Level 6 modal (USA/International khác nhau) và các level khác hiện "Provisioning in Progress" — nếu API/lock-and-liquidate trả lỗi 5xx TRONG LÚC animation certificate đang chạy, frontend xử lý thế nào (rollback animation, hiện lỗi, hay tiếp tục animation rồi báo lỗi sau)? | Raw spec bổ sung làm rõ thêm thứ tự hiển thị: celebration modal + certificate animation + sharing luôn chạy đầy đủ, KHÔNG bị gián đoạn bởi backend; message "Next Level Provisioning in Progress" chỉ hiện SAU KHI trader tự đóng modal (không chạy song song/chặn modal). Case lỗi 5xx trong lúc animation vẫn CHƯA được trả lời trực tiếp — giữ đề xuất cũ: animation chỉ trigger sau response 200 thành công (không optimistic UI); nếu lỗi 5xx thì hiện toast error, không chạy animation. | kể cả k flatten dc hay gì vẫn hiện modal level certificate nhé, close đi cái thì hiện modal progress nếu như đang progress account. mà modal này close chặn full màn chứ k dc thực hiện action gì khác nha.🆕 Double-confirm bởi STAGE6-004 (QnA_STAGE6_CAREER_PATH.md, 2026-09-30): client xác nhận modal "Next Level Provisioning in Progress" phải đứng yên trên màn hình, không tự đóng, tới khi backend hoàn tất provisioning account cho level mới — khớp 100% với chốt trước đó. | ✅ Đã chốt — double-confirm bởi STAGE6-004. Case lỗi 5xx trong lúc animation vẫn chưa có câu trả lời trực tiếp, nhưng không còn ảnh hưởng vì modal certificate luôn hiện bất kể backend thành công hay fail. |
| A-05b 🆕 | [Business Rule mới] Raw spec bổ sung nêu rõ: nếu Stage 1 (Lock & Liquidate) KHÔNG hoàn tất được — vì market đóng hoặc flatten fail — thì Stage 2-5 (ledger reset, risk update, promotion announcement...) PHẢI bị block cho tới khi xác nhận account 100% flat (Open_Positions == 0). Đây có phải là BR chính thức cần ghi vào SRS, và cơ chế check "market đóng" dùng nguồn nào? | Đề xuất: xác nhận là BR bắt buộc (đặt tên BR chính thức khi viết SRS) — Verify loop (đã có trong raw spec gốc) là cơ chế thực thi: pollOpen_Positions tới khi = 0 mới cho Stage 2 tiếp tục; nếu market đóng, loop cần timeout + alert Ops (không loop vô hạn). Cần BA xác nhận có cần timeout/alert Ops khi loop kéo dài không. | t nghĩ lúc viết flow b cx ghi vào luôn áy k cần ref sang BR mới ghi. với lại open_positions == 0 sàn se bắn event nhaloop timeout thì bỏ qua đi | ✅ Đã chốt — viết trực tiếp vào Flow (không ref sang BR riêng); điều kiện flat dùng event từ sàn bắn về (Open_Positions==0); bỏ loop timeout/alert Ops |
| A-06 🆕 | Level 24 Prestige Reset — "Sweep Profit" có phải là điều chỉnh số dư nội bộ (internal balance adjustment, không di chuyển tiền thật) khác với "Pay Bonus" (payout thật, qua bảngpayouts + Flow 5)? Cần phân biệt rõ 2 khái niệm này trong BR. | Raw spec bổ sung xác nhận đúng và cho chi tiết chính xác hơn:Sweep Profit = bước tính toán thuần (profit vượt Max_Forex_Notional/Futures_Capital theo Table B cho Level 24), KHÔNG di chuyển tiền. Pay Bonus = middleware ghi 1 row mới vào CÙNG bảng payouts mà Stage 4 (Data Fee Refund) dùng, amount = swept profit, Flow 5 (Dots/Rippling, off-platform) pick up sau. Reset Account = Balance Adjustment trên execution platform (Rithmic/MT5/TE) về đúng Max_Forex_Notional/Futures_Capital, làm song song với update ledgers.virtual_equity và ledgers.allocated_capital trong DB nội bộ về cùng giá trị. Freshdesk ticket payload cũng đã rõ: Trader Full Name, Email, Global User ID, Subject = "Level 24 Prestige Reset", Body = final profit metrics + prompt liên hệ CEO. | OK | ✅ Đã chốt (OK, khớp giả định BA/QC đề xuất) — chỉ còn phụ thuộc quyết định scope A-00 (đã chốt: viết chung UC_8.1.1) |
UC_8.1.1 — Flow 4A: Stage 2 (Ledger Reset, Next Level Params, Pod Leader Carry, Defense Recharge Check)
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|---|---|---|---|
| A-07 | Next Level Parameter — lookup Table A/B: nếuEvent_ID xử lý ra level mới KHÔNG tồn tại trong Table A/B (vd: data thiếu dòng cho level đó), flow nên fail-safe thế nào (block promotion, dùng giá trị fallback, hay alert Ops)? | Đề xuất: block promotion + fire alert Slack#ops-general (theo CR-15.2, kênh catch-all cho "Pay raise logic confirmations") + giữ trader ở trạng thái pending, KHÔNG tự đoán giá trị fallback cho risk parameter. | không có case này, ops tự xử lý | ✅ Đã chốt — không xử lý case thiếu data Table A/B, Ops tự xử lý thủ công |
| A-07b 🆕 | Raw spec bổ sung xác nhận công thức tính chính xác:Next_Level = Current_Level + 1; Futures → Level_Starting_Capital = Futures_Capital (Table B); Forex → Level_Starting_Capital = Max_Forex_Notional / 50. Có cần confirm nguồn gốc số 50 (hằng số leverage/margin ratio) không, và nó có nằm trong Table A/B hay là hardcode riêng? | Đề xuất: ghi nhận công thức trên vào BR, hỏi thêm liệu/50 là hardcode cố định toàn hệ thống hay có thể thay đổi theo cấu hình (nếu đổi thì nên đọc từ config/Table A thay vì hardcode trong code). 🆕 Xem STAGE6-005 — câu trả lời "cố định" bên cột phải đã bị khách tự đảo ngược. | ⚠️ OVERRIDE bởi STAGE6-005 (2026-09-30) — KHÔNG dùng /50 nữa. Công thức mới: Level_Starting_Capital = (Max_Forex_Notional * Margin_Rate) + Market_Loss_When_Stopped, Margin_Rate đọc từ cột mới trong Zapier Table A | ✅ Đã chốt (approved) — công thức mới Level_Starting_Capital = (Max_Forex_Notional * Margin_Rate) + Market_Loss_When_Stopped, Margin_Rate đọc từ Table A, KHÔNG dùng /50 |
| A-07c 🆕 | Raw spec bổ sung mô tả Ledger Reset gồm 4 bước con: (1) Sync State qua Execution API lấy final closed P&L, (2) Update Virtual Ledger (ledgers.virtual_equity về target reset balance + log chênh lệch vào bảng historical_pnl), (3) Update Risk Limits (reset Daily_Loss_Limit, re-validate Max_Notional cho Forex), (4) Metadata Update (ledgers.level_id nếu có new_level_id, ledgers.is_active = FALSE nếu deactivate = TRUE). Thứ tự 4 bước này có bắt buộc tuần tự (sync xong mới update ledger) hay có thể parallel một phần? | Đề xuất: tuần tự — (1) phải xong trước (2) vì (2) cần final P&L từ (1) để tính chênh lệch log vàohistorical_pnl; (3) và (4) có thể chạy song song với nhau sau khi (2) xong vì không phụ thuộc lẫn nhau. | thôi giữ như specs ban đầu đi (1) Sync State qua Execution API lấy final closed P&L, (2) Update Virtual Ledger (ledgers.virtual_equity về target reset balance + log chênh lệch vào bảng historical_pnl) 🆕 ĐÃ BỊ ĐẢO NGƯỢC bởi STAGE6-007 (QnA_STAGE6_CAREER_PATH.md, 2026-09-30) — khách chốt lại: bước (3) Update Risk Limits và bước (4) Metadata Update BỊ LOẠI HẲN khỏi reset-ledger (Stage 2). Lý do: (3) redundant vì Stage 3 đã comprehensive update risk params (Target/Stop) rồi; (4) level update (Current_Level=Next_Level) đã dồn hết vào Flow 4 Stage 3, không shoehorn vào ledger reset endpoint. /financial/reset-ledger giờ CHỈ còn 2 việc: capture PnL vào historical_pnl + reset equity/balance. | ✅ Đã chốt (approved) — bỏ bước (3) Update Risk Limits + (4) Metadata Update khỏi Stage 2, dồn hết về Stage 3; /financial/reset-ledger chỉ còn capture PnL + reset equity/balance |
| A-08 🆕 | Pod Leader Carry Logic — carry cố định (L3=$250, L5=$500, L7=$1500) được ghi nhận ngay lúc promotion, hay accrue chờ tới kỳ vesting (Flow 17)? | Đề xuất giữ nguyên: ghi nhận (accrue) ngay lúc promotion, KHÔNG payout ngay — payout thật xử lý ở Flow 17 (Pod Leader Vesting, monthly). Raw spec bổ sung xác nhận tên field chính xác: pseudocodePending_Carry_Balance = Pending_Carry_Balance + Carry_Amount — field lưu accrued carry là Pending_Carry_Balance (không phải tên khác), khớp với đề xuất accrual-vs-vesting đã nêu. | Not paid at the moment it accrues. There is a separate flow - Flow 17: Pod Leader Vesting Payout - that runs on a monthly schedule, on the 1st of the month (Trigger: Scheduled Job, Monthly, 1st of Month). The Middleware loops through all eligible Pod Leaders, calls the Dots/Rippling Off-Cycle API to pay out, then zeroes out Pending_Carry_Balance to prevent double payment. So Flow 4 Stage 2 (Pending_Carry_Balance += Carry_Amount) is only an accrual step, NOT a payment step. The actual money only moves once a month, on the 1st, via Flow 17. Open question we have NOT yet asked you: if a Pod Leader's account is terminated (Flow 7) before Flow 17's next scheduled run, what happens to their outstanding Pending_Carry_Balance? if a Pod Leader is terminated before the 1st of the month, their Pending_Carry_Balance is forfeited. As specified in Flow 15A (Leader Exit), the middleware must zero out the balance and liquidate it back to the Stack General Account. | ✅ Đã chốt đủ (accrual Flow 4 Stage 2, payout qua Flow 17 ngày 1 hàng tháng, forfeit nếu terminate trước Flow 17 theo Flow 15A) — không còn blocker |
| A-09 🆕 | Defense Protocol recharge check (Level 9-17) tại Stage 2 — đây làcheck điều kiện (trader có đủ điều kiện re-enable Defense Protocol không) hay là thực thi luôn recharge logic? Nếu là thực thi, có trùng với UC_8.4.1/UC_8.4.2 không? | Raw spec bổ sung đặt tên chính thức cho bước này là**"Recharge Check (Standard Accrual)"** và cho biết Stage 2CÓ thực thi logic đếm dồn, không chỉ check điều kiện: Promotions_Since_Defense = Promotions_Since_Defense + 1; nếu >= 2 → Defense_Used = False + reset counter về 0 + gửi email Defense_Protocol_Recharged qua AWS SES. Điều này gợi ý Stage 2 (Flow 4A) tự sở hữu phần "Standard Accrual" (counter tăng dần theo mỗi promotion), còn UC_8.4.1/UC_8.4.2 có thể chỉ sở hữu phần "Emergency/manual recharge" (2 mechanisms) khác — cần BA xác nhận đúng ranh giới này để tránh trùng lặp. | Bỏ các UC UC_8.4.1, UC_8.4.2, UC_8.4.3 đi nha, viết chi tiết ở đây luôn. | ✅ Đã chốt — bỏ UC_8.4.1/8.4.2/8.4.3, viết chi tiết Recharge Check (Standard Accrual) ngay trong UC_8.1.1 |
UC_8.1.1 — Flow 4A: Stage 3 (Ledger Update, Immutable Ledger Logging, Account/Risk Update, Dashboard Day-0, S3 Certificate, Discord)
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|---|---|---|---|
| A-10 🆕 | receipt_hash (internal DB reference) và tx_hash (Polygon blockchain hash thật qua Ethers.js) — 2 giá trị này có luôn đi cùng nhau (1-1) hay có trường hợp receipt_hash được tạo trước khi tx_hash confirm (do Polygon network delay)? | Raw spec bổ sung xác nhận đúng cơ chế 2-step như đề xuất (receipt_hash đồng bộ, tx_hash bất đồng bộ sau Polygon confirm), và bổ sung thêm endpointGET /public/ledger (50 record gần nhất, cache 5 phút) dùng cho public ledger page. Quan trọng — correction cho raw spec gốc: điều kiện "Immutable Ledger Logging chỉ áp dụng IF Next_Level >= 4" đã bị raw spec bổ sung ghi rõ "(exclude this condition)" → nghĩa là bỏ hẳn điều kiện gate theo level, Immutable Ledger Logging áp dụng cho MỌI lần promotion không phân biệt level. Cần BA xác nhận chính thức việc bỏ gate này (khác với giả định ban đầu chỉ log từ Level 4). | đông ý với giả định | ✅ Đã chốt — xác nhận chính thức bỏ gate Level>=4, Immutable Ledger Logging áp dụng cho MỌI lần promotion |
| A-11 | Certificate format lưu trên S3 — PDF hay PNG? | Đã có sẵn trong QnA (Level Promotion Round 4, Q2/A2): "PNG (không phải PDF) — frontend generate PNG qua GET /certificate rồi push lên S3." ⚠️ Override lại Round 3 (từng nói PDF) — QnA Round 4 mới hơn thắng. | Đã chốt — dùng PNG, không dùng PDF. | ✅ Đã chốt (QnA Round 4, Q2/A2) |
| A-12 🆕 | Dashboard Day-0 timestamp boundary — timestamp field này có tuân theo chuẩn UTC/ISO 8601 millisecond precision (CR-08) không, và field tên là gì? | Đề xuất: tuân theo CR-08 — fieldpromotion_timestamp_utc (ISO 8601, .sss precision), lưu tại thời điểm /lock-and-liquidate hoàn tất. Dashboard widget filter data theo >= promotion_timestamp_utc cho account đó, KHÔNG xoá/ẩn data cũ. Raw spec bổ sung xác nhận đúng cách hiểu này (timestamp boundary, ignore trade history trước mốc đó khi tính toán widget) — khớp với QnA Round 2/3 mục A2. | bỏ qua cái này, technical quá | ✅ Đã chốt — bỏ qua, không cần ghi chi tiết tên field timestamp vào SRS |
| A-13 | Discord Announcement routing — Level 1 có được announce không, và "Silent vs Viral" concept còn áp dụng không? | Đã có sẵn trong QnA (Level Promotion Round 1, mục C1): "Theo Discord doc riêng (Google Doc), Level 1 CŨNG được announce (không chỉ 6/10/14). 'Silent vs Viral' đã obsolete. Chỉ khác channel đích: Level 14+ →#viral-wins, còn lại → #trading-floor-announcements." ⚠️ KHÔNG dùng CR-20260827-001 (#the-pit routing) — CR này đã bị đánh dấu unofficial/withdrawn (2026-09-06), xác nhận lại tại _CR_INDEX.md dòng CR-20260827-001. Raw spec bổ sung (bản mới) vẫn còn paste lại bảng routing CŨ có nhắc #the-pit, nhưng ngay sau đó tự đính chính lại đúng logic Level 14+ → #viral-wins / còn lại → #trading-floor-announcements — tự thân raw spec đã tái xác nhận, không phải nguồn mới mâu thuẫn. | Đã chốt — dùng QnA Round 1 mục C1, bỏ hoàn toàn logic#the-pit dù raw spec paste vào còn nhắc tới (raw spec tự đính chính lại ngay sau đó). 🆕 Double-confirmed bởi Discord Server Details.md (nguồn mới, xem _SOURCE_MANIFEST.yaml id DISCORD_SERVER_DETAILS) — mục Announcements của doc này liệt kê đúng 7 announcement templates cho MỌI level (1, 2-5/7-8/11-13, 6, 9, 10, 14, 15-24), route Level 14+ → #viral-wins, tất cả còn lại (kể cả Level 1 và Level 9) → #trading-floor-announcements. Không có channel nào tên #the-pit trong routing này — khớp 100% với QnA Round 1 C1, không phát sinh conflict mới. | ✅ Đã chốt (QnA Round 1, mục C1; double-confirmed bởi Discord Server Details.md) |
| A-13b 🆕 | Raw spec bổ sung cho Table G (Discord Title theo Level) đầy đủ: Level 1 = "The First Allocation"; Level 2-5, 7-8, 11-13 = "The Standard Progression"; Level 6 = "The Career Milestone"; Level 9 = "Drawdown Defense"; Level 10 = "Senior Trader 1"; Level 14 = "Senior Trader 2"; Level 15-24 = "Heavy Hitters". Đây là reference detail cho SRS, không phải câu hỏi mở — có cần xác nhận danh sách này là bản cuối cùng (final) không? | Đề xuất: ghi nhận Table G này làm reference table trong SRS (Business Rule liên quan Discord announcement), giả định đây là bản final trừ khi BA nói khác. | 🆕 Tự chốt được, không cần hỏi BA — Discord Server Details.md (nguồn gốc "Google Doc" được QnA Round 1 C1 nhắc tới) section Announcements confirm nguyên văn 7 bảng, khớp 100% với Table G: 1) "The First Allocation" (Lv1) → #trading-floor-announcements; 2) "The Standard Progression" (Lv 2-5,7-8,11-13) → #trading-floor-announcements; 3) "The Career Milestone" (Lv6) → #trading-floor-announcements; 4) "Drawdown Defense" (Lv9) → #trading-floor-announcements; 5) "Senior Trader 1" (Lv10) → #trading-floor-announcements; 6) "Senior Trader 2" (Lv14) → #viral-wins; 7) "Heavy Hitters" (Lv15-24) → #viral-wins. Table G trong raw spec = final, dùng trực tiếp cho SRS kèm text template đầy đủ (emoji + copy) từ Discord doc. | ✅ Đã chốt (Discord Server Details.md, mục Announcements — tự giải quyết, không phải hỏi BA) |
| A-14 | Discord bot failure handling — retry 5xx/429 và drop 404 — chính xác cơ chế và message là gì? | Đã có sẵn trong QnA (Level Promotion Round 4, Stage 3, Q1/A1): "5xx/429 → chấp nhận retry qua cron 30 phút (Redis queue). 404 → drop + không retry, cảnh báo Ops Slack với message chính xác: '⚠️ Discord Notification Failed: User ID [ID] not found or channel missing. Skipping retry.'" | Đã chốt — dùng nguyên văn message trên, không paraphrase. | ✅ Đã chốt (QnA Round 4, Stage 3, Q1/A1) |
UC_8.1.1 — Flow 4A: Stage 4 (Data Fee Refund Calculation)
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|---|---|---|---|
| A-17 | Data Fee Refund có áp dụng nếu trader bị terminate TRƯỚC khi đạt Level 3 không? | Đã có sẵn trong QnA (Level Promotion Round 4, Stage 4, Q1/A1): "KHÔNG áp dụng — nếu terminate trước Level 3, hệ thống chỉ query fee records nhưng KHÔNG setrefunded_at. Xác nhận đúng logic Option 2." | Đã chốt — Option 2 đúng, không refund khi terminate trước Level 3. | ✅ Đã chốt (QnA Round 4, Stage 4, Q1/A1) |
| A-18 | Refund có bao gồm add-on fees hoặc platform fees không, hay chỉ CME base fee? | Đã có sẵn trong raw spec + xác nhận không bị QnA nào override: chỉ tính CME base fee (MARKET_DATA_BASE), loại trừ add-ons và platform fees. | Đã chốt — chỉ CME base fee. | ✅ Đã chốt (Customer supplies + không có QnA override) |
UC_8.1.1 — Flow 4A: Stage 5 (Klaviyo Emission, Everflow, Perk Check)
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|---|---|---|---|
| A-19 🆕 | Klaviyo 3-way branch (Level 3 Refund / Level 6 W-2+Everflow / Standard) — nếu 1 trader thỏa ĐỒNG THỜI 2 điều kiện (vd: về lý thuyết Level 3 và Level 6 không thể trùng, nhưng cần xác nhận đây là mutually exclusive theo đúng level number, không phải theo range)? | Đề xuất giữ nguyên: mutually exclusive theo đúngcurrent_level value. Raw spec bổ sung cho payload field cụ thể từng path: Path A (Level 3) = user_name, refund_amount, total_bonus, Level-Up URL (kèm nút push-start activation); Path B (Level 6) = user_name, new_level, next_target, cùng Level-Up URL mechanism, thêm dashboard "share toggle" copy URL trực tiếp; Path C (Standard) = user_name, new_level, next_target, Level-Up URL. | 🆕 Đã chốt bởi STAGE6-008 (QnA_STAGE6_CAREER_PATH.md, 2026-09-30): Mutually-exclusive theo current_level value — confirmed đúng. Đồng thời bổ sung flow-trigger routing MỚI (chưa có trong raw spec gốc): Path B (New_Level==6) -> MUST trigger Flow 6 (Level 6 Transition). Path C, với New_Level > 6 (vd Level 7,8,9) -> MUST trigger Flow 8 (Pay Raise Engine) de recalculate compensation, KHÔNG chỉ emit Klaviyo Promotion_Standard payload suông. Nhắc lại KHÔNG pass bounty_amount trong Everflow conversion payload (khớp A-01/A-20). | ✅ Đã chốt (STAGE6-008) — mutually-exclusive OK + Path B->Flow 6, Path C(>6)->Flow 8 là BR mới cần thêm vào SRS |
| A-20 | Everflow S2S Postback — payload cuối cùng chỉ cóevent_id, không có bounty_amount. Có cần thêm field nào khác (vd: transaction_id, user_id) để Everflow match đúng affiliate click gốc không? | Đã có sẵn trong QnA (Level Promotion Round 4, Section E, Q1-Q3/A1-A3): dùngeverflow_transaction_id (lưu từ lúc JS SDK capture st_affiliate_data cookie ở S2S Click API) làm khoá match, cùng event_id. | Đã chốt — payload gồmevent_id + everflow_transaction_id, KHÔNG có bounty_amount. Xem thêm A-01 (CR conflict) về việc bounty do Everflow dashboard tự cấu hình. | ✅ Đã chốt (QnA Round 4, Section E) |
| A-20b 🆕 | Raw spec bổ sung cho biết S2S postback Everflow thực ra fire choMỌI checkout thành công (không riêng Level 6), qua mọi gateway; user thuộc "Velocity Group" (internal) được hardcode $0.00 commission (tránh SaaS billing bị inflate) nhưng vẫn fire webhook riêng để đếm milestone 3/6 referral → trigger Zapier Flow 32 (promo code free challenge); external enterprise affiliate dùng cùng postback nhưng nhận payout thật qua Everflow. Việc này liên quan A-00b — Level 6 bounty trong UC_8.1.1 có phải chỉ là 1 trong nhiều điểm chạm mà postback checkout-wide này gọi tới không? | Đề xuất: xác nhận Level 6 bounty (A-20) là 1 use-case CON của hệ thống postback checkout-wide lớn hơn — UC_8.1.1 chỉ mô tả đúng điểm chạm Level 6 bounty, phần postback checkout-wide (mọi gateway, Velocity Group $0, Flow 32 milestone) thuộc Checkout UC (Flow 1) — xem A-00b. | Đúng — xác nhận Level 6 bounty (A-20) chỉ là 1 use-case con của postback checkout-wide lớn hơn. UC_8.1.1 chỉ mô tả điểm chạm Level 6 bounty, phần còn lại (mọi gateway, Velocity Group $0, Flow 32 milestone) thuộc Checkout UC (Flow 1), chỉ cross-ref. | ✅ Đã chốt — dùng đề xuất BA/QC làm chính thức |
| A-21 | Perk Check via Table H (Perks Registry) — nếu Table H thiếu entry cho level vừa promote lên, flow có block promotion hay chỉ skip phần perk (promotion vẫn thành công, không có perk)? | Đề xuất: KHÔNG block promotion — Perk Check là bước bổ sung/optional, nếu Table H thiếu entry thì skip cấp perk (log warning nội bộ), không ảnh hưởng core promotion pipeline (ledger, ranking, certificate). Raw spec bổ sung xác nhận cấu trúc Perk Check (Path C): lookup Table H → triggerFulfillment_Zap → gửi email Perk_Unlocked_General — khớp với hiểu hiện tại, không đổi. | k block, skip — xác nhận KHÔNG block promotion, chỉ skip cấp perk khi Table H thiếu entry. | ✅ Đã chốt (BA xác nhận: không block, skip) |
| A-22 🆕 | [Sub-flow hoàn toàn mới] Feedback Survey Gate — raw spec bổ sung mô tả 1 pre-condition TRƯỚC khi vào Stage 5's 3-way Klaviyo branch: query Users.last_survey_date; nếu NULL hoặc > 30 ngày trước → emit Template_Mentee_Survey webhook tới Klaviyo (gửi email chứa Typeform link) + update last_survey_date = hôm nay (lưu ý: đây là ngày GỬI, không phải ngày SUBMIT). Flow 10.4 (= UC_8.2.6 "Mentee Feedback") đóng vai trò webhook receiver bất đồng bộ cho Typeform submission, route điểm số về Pod_Leader_Registry để tính mentor compliance. Sub-flow này có thuộc scope UC_8.1.1 hay nên tách hoàn toàn sang UC_8.2.6? | Đề xuất: Gate check (last_survey_date + emit webhook + update ngày gửi) là 1 precondition step trong Flow 4A/UC_8.1.1 (nó chạy TRƯỚC 3-way branch, thuộc trigger chain của promotion), nhưng phần xử lý submission + Pod_Leader_Registry compliance scoring thuộc UC_8.2.6 (Flow 10.4) — UC_8.1.1 chỉ mô tả việc emit + update timestamp, cross-ref UC_8.2.6 cho phần còn lại. | OK | ✅ Đã chốt (OK, khớp đề xuất BA/QC) — Gate check thuộc UC_8.1.1, phần xử lý submission/compliance scoring thuộc UC_8.2.6 |
| A-22-override 🆕 | CHR-141 (override A-22): threshold 30→60 ngày, thêm điều kiện pod_leader_id IS NOT NULL vào gate. | — | ✅ Đã chốt (CHR-141) — gate mới: pod_leader_id IS NOT NULL AND (last_survey_date IS NULL OR last_survey_date < NOW() - INTERVAL '60 days') | ✅ Đã chốt (CHR-141) |
| A-23 🆕 | [Business Rule mới] Nếu trader chưa link Discord account (discord_user_id IS NULL) khi promotion xảy ra, Discord role-assignment flow nên fail hay skip? Và nếu trader promote nhiều level liên tiếp mà không login dashboard (vd Level 2 -> Level 6), lần login kế tiếp hiện bao nhiêu certificate? | Chưa có trong raw spec gốc — phát sinh từ QnA mới (STAGE6-009). | Đã chốt bởi STAGE6-009 (QnA_STAGE6_CAREER_PATH.md, 2026-09-30): (1) Nếu discord_user_id NULL -> middleware SKIP toàn bộ Discord API role-assignment call, return 200 OK, KHÔNG để promotion flow crash. (2) Late-linking: khi trader link Discord sau (/link slash command), middleware PHẢI query current_level hiện tại từ PostgreSQL, map đúng title cho level đó, apply đúng role đó — KHÔNG được default về "Associate Trader". (3) Multi-level-up không login dashboard: frontend CHỈ render celebration + certificate + modal bắt buộc (vd Level 6 W-2 transition) cho level cao nhất đã đạt được tại lần login kế tiếp — KHÔNG bắt trader click qua backlog animation của các level đã bỏ qua. | ✅ Đã chốt (STAGE6-009) — 3 Business Rule mới cần thêm vào SRS: Discord skip-if-unlinked, Discord late-link role sync, Frontend single-latest-level animation. |
[PATTERN] Rule candidates cho common_rules.md
| ID | Nội dung |
|---|---|
| P-01 | CR-08 áp dụng cho toàn bộ timestamp trong Flow 4A (Event_ID log time, promotion_timestamp_utc, refunded_at, ledger record time) — đã có sẵn CR-08, không cần thêm rule mới, chỉ cần cite khi viết SRS. |
| P-02 | Discord bot failure retry pattern (5xx/429 → cron 30 phút; 404 → drop + Slack message cố định) — nếu pattern này lặp lại ở flow khác có gọi Discord bot (ngoài Flow 4A), đề xuất tách thành CR riêng (CR-18: Discord Bot Failure Handling) để tránh lặp lại. Chưa đủ dữ liệu để confirm lặp lại ở UC khác — chỉ ghi nhận candidate, chưa tạo CR. |
Open Items tồn đọng từ QnA_Level_Promotion.md (chưa được client trả lời — giữ nguyên trạng thái BLOCKED)
| QnA ID | Nội dung | Trạng thái |
|---|---|---|
LVLPROMO-R4-B5 | Nội dung template SES-13 (email) — client chỉ nói "sẽ review", chưa có nội dung xác nhận | 🔴 BLOCKED — chưa có nội dung, loại khỏi SRS cho tới khi có |
Theo Init Flow rule: "Nếu BA chỉ trả lời một phần → chỉ tiếp tục với phần đã confirm. Đánh dấu phần chưa confirm là
[BLOCKED]và loại khỏi docs." → phần nội dung phụ thuộcLVLPROMO-R4-B5vẫn bị loại khỏi SRS UC_8.1.1 cho tới khi có nội dung. 🆕LVLPROMO-R3-A2đã đóng — xem A-04 ở trên, double-confirm bởi STAGE6-006, gỡ khỏi bảng Open Items.
Tổng kết trạng thái
- Đã chốt (từ QnA/CR/BA có sẵn, không cần hỏi lại BA): A-00, A-00b, A-01, A-02, A-03, A-04, A-05, A-05b, A-06, A-07, A-07b, A-07c, A-08, A-09, A-10, A-11, A-12, A-13, A-13b, A-14, A-17, A-18, A-19, A-20, A-20b, A-21, A-22, A-23 (27/27 câu — 100%)
- Đang chờ BA xác nhận: không còn câu nào — TOÀN BỘ QnA đã confirmed. ✅ ĐỦ ĐIỀU KIỆN qua Step 3 (Architect) theo PAUSE Gate của
system_init_workflow.md. - BLOCKED (chưa có safe default, chờ client): phần liên quan
LVLPROMO-R4-B5(template SES-13) —LVLPROMO-R3-A2đã đóng, xem A-04 - Pattern candidate (chưa tạo CR mới): P-01, P-02
- 🆕 Cập nhật lần 2 (raw spec bổ sung): đã sharpen A-05/A-06/A-08/A-09/A-10/A-12/A-13/A-19/A-21 với chi tiết kỹ thuật chính xác hơn (field names, API steps, payload fields); thêm BR mới A-05b (Stage 1 blocking gate); thêm câu hỏi mới A-07b/A-07c (ledger reset/next-level calc), A-13b (Table G title mapping), A-20b (Everflow checkout-wide postback vs Level 6 bounty scope), A-22 (sub-flow MỚI: Feedback Survey Gate); thêm scope-boundary question A-00b (Everflow Partner/Affiliate onboarding — có thể không thuộc UC_8.1.1).
- 🆕 Cập nhật lần 3 (nguồn mới
References/Customer supplies/Discord/Discord Server Details.md, đã add vào_SOURCE_MANIFEST.yamlidDISCORD_SERVER_DETAILS, ★★★): doc này chính là "Discord doc riêng (Google Doc)" được QnA Round 1 mục C1 tham chiếu — double-confirm A-13 (routing Level 14+ →#viral-wins, còn lại →#trading-floor-announcements, không có#the-pit) và tự chốt A-13b (Table G khớp 100% với 7 announcement template của doc, kèm text copy đầy đủ dùng được luôn cho SRS, không cần hỏi lại BA). Doc cũng cho thêm input hữu ích cho các phần sau của UC_8.1.1 chưa được dùng tới ở init round này: Discord Role Configuration đầy đủ (bảng "Compiled Discord Roles and Badges" — map Level range ↔ Role Title ↔ Permission, dùng cho/manage-discord-roleở A-03); Pod channel naming convention (pod-[leader_name]khi active,archived-pod-[leader_name]khi leader bị terminate/suspend — liên quan Flow 15A/15B, UC_8.2.10). - 🆕 Cập nhật lần 4 (QnA mới
QnA_STAGE6_CAREER_PATH.md, STAGE6-004 → STAGE6-010, 2026-09-30): đóng hẳn A-04 (BLOCKED → đã chốt, PnL reset về 0 sau flatten, snapshot vàohistorical_pnltrước khi reset); double-confirm A-05 (modal processing block full màn, không đổi); ⚠️ OVERRIDE A-07b — bỏ hardcode/50, công thức mớiLevel_Starting_Capital = (Max_Forex_Notional * Margin_Rate) + Market_Loss_When_Stopped(Margin_Rate đọc từ cột mới Table A); ⚠️ OVERRIDE A-07c — bỏ bước (3) Update Risk Limits và (4) Metadata Update khỏireset-ledgerStage 2 (dồn hết về Stage 3); chốt A-19 — Path B (Level 6) trigger Flow 6, Path C với Level > 6 trigger Flow 8 (không chỉ emit Klaviyo). STAGE6-010 (comment Figma/Discord doc) chờ theo dõi riêng, chưa có nội dung trả lời trực tiếp. - 🆕 Cập nhật lần 5 (BA trả lời trực tiếp trong bảng + dọn file): BA chốt A-16 (xem Stage 4) đã bị gỡ khỏi bảng ở version trước — cần BA xác nhận lại A-16 có bị xóa nhầm không (Stage 4 hiện chỉ còn A-17, A-18); A-20b chốt "Đúng" (Level 6 bounty là use-case con của postback checkout-wide, phần còn lại thuộc Checkout UC Flow 1); A-21 chốt "không block, skip cấp perk nếu Table H thiếu entry". Đã gỡ 1 dòng A-23 bị duplicate/hỏng do lỗi encode ở lần sửa trước (nội dung gốc giữ nguyên ở dòng A-23 còn lại, không mất thông tin). ⚠️ Phát hiện cần BA xác nhận:
A-14b,A-15,A-15b,A-16được nhắc tới ở các bản cập nhật trước nhưng không còn tồn tại trong bảng hiện tại (Stage 3 chỉ còn A-10 → A-14, Stage 4 chỉ còn A-17 → A-18) — đặc biệt A-15b có nội dung ⚠️ nguy cơ mâu thuẫn "Wipe UI History" vs A-03/A-12 được đánh dấu ưu tiên cao, nếu bị mất ngoài ý muốn cần khôi phục. - ✅ Cập nhật lần 7 (BA approve chính thức A-07b + A-07c): cả 2 câu chuyển từ "⚠️ Đã chốt lại (OVERRIDE)" sang ✅ Đã chốt, không còn gắn mác cần confirm thêm. A-07b: dùng chính thức công thức
Level_Starting_Capital = (Max_Forex_Notional * Margin_Rate) + Market_Loss_When_Stoppedcho Forex, bỏ hẳn/50hardcode. A-07c:/financial/reset-ledger(Stage 2) chính thức chỉ còn 2 việc — capture PnL vàohistorical_pnl+ reset equity/balance; bước Update Risk Limits và Metadata Update dồn hẳn về Stage 3. Có thể dùng trực tiếp cho SRS, không cần chờ gì thêm. - ⚠️ Cập nhật lần 6 (sửa lại Trạng thái sai — BA đã trả lời rõ nhưng cột Trạng thái vẫn để "⏳ Chờ BA"): rà lại toàn bộ cột "BA chốt" và chuyển sang ✅ Đã chốt cho A-00, A-00b, A-02, A-05b, A-06, A-07, A-09, A-10, A-12, A-22 — BA đã trả lời dứt khoát ở cột "BA chốt" (vd A-00: "không xoá UC, viết hết vào UC_8.1.1"; A-09: "bỏ UC_8.4.1/8.4.2/8.4.3"; A-12: "bỏ qua, technical quá") nhưng Trạng thái bị bỏ sót chưa update theo. A-08 chuyển sang đã chốt phần chính (timing accrual-vs-vesting đã được double-confirm ở Section 7 của QnA_Level_Promotion.md). Chỉ còn thật sự "Chờ BA" đang ở A-07b/A-07c (override công thức, cần confirm chính thức) và scope A-00/A-00b (đã có hướng nhưng cần viết rõ hơn khi làm SRS).