Client Questions — Background Mechanisms & Cron Jobs (UC_9.x)
Client Questions — Background Mechanisms & Cron Jobs (UC_9.x)
| Field | Value |
|---|---|
| BA in Charge | linh.nguyen34 |
| Date Created | 2026-10-28 |
| Status | ⏳ Chưa gửi khách |
| Scope | Flow 13 (UC_9.2), Flow 18 (UC_9.3), Flow 32 (UC_9.14), Flow 33 (UC_9.15), Flow 34 (UC_9.11), Flow 35 (UC_9.12), Flow 36 (UC_9.13), Flow 38 (UC_9.16) |
Cột Question viết bằng tiếng Anh để gửi khách nguyên văn. Cột Bối cảnh và Giả định hiện tại chỉ dùng nội bộ. Khi khách trả lời: ghi vào cột Answer, đổi Status thành ✅, rồi cập nhật UC tương ứng.
Flow 13 — Time-Off Management (UC_9.2)
1. W-2 time-off via Rippling (Path A)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F13-01 | Does Rippling's time-off policy block W-2 requests above the DTO_Days allowance per level (Table A / Table B), or should our middleware re-check the balance when it receives the approval webhook? | UC_9.2 Q-1. Rippling sở hữu số dư PTO ([HR-DEF-01]); chưa rõ Ops có cấu hình DTO_Days vào Rippling không. | Rippling chặn; middleware không kiểm tra lại. | ⏳ | |
| F13-02 | If a W-2 trader cancels or shortens an approved time-off in Rippling, does Rippling send a webhook, and should we unlock the account early / reduce the stagnation_deadline extension? | UC_9.2 Q-2. Hiện chỉ xử lý webhook "Approved". | Không tự động; Ops xử lý tay. | Không build tự động. Trader huỷ/rút ngắn PTO trên Rippling → gửi Slack #ops-general (hoặc tạo Freshdesk ticket) để Ops tự kiểm tra, mở lại tài khoản và chỉnh stagnation_deadline nếu cần. Toàn bộ Flow 13 áp cho Level 6+ và thuộc Release 2. (Client sheet F13-01, 2026-11-04) | ✅ 2026-11-04 |
| F13-03 | If the Rippling approval webhook arrives after the leave start date, the trading lock will be late. Should we alert Ops in that case? | UC_9.2 Q-3 / Exc-2. Rủi ro của kênh Rippling (khách đã chọn Option B). | Khoá ngay khi nhận; không cảnh báo. | Xử lý theo thời điểm webhook đến: (1) Hôm nay trong khoảng leave_start_date–leave_end_date → lock ngay cho phần còn lại của kỳ nghỉ, cộng đủ Requested_Days vào stagnation_deadline, gửi Slack thông báo thường tới #ops-general (late approval). (2) Hôm nay đã qua leave_end_date → KHÔNG lock; vẫn ghi PTO lên ledger (Flow 35), vẫn cộng stagnation_deadline, gửi Slack #ops-general. (Client sheet F13-02, 2026-11-04) | ✅ 2026-11-04 |
| F13-04 | Rippling counts approved PTO in working days (or hours), while stagnation_deadline is a calendar date. When extending stagnation_deadline, should we use (a) the number of days Rippling approved, or (b) the calendar days between the leave start and end date in the Rippling payload? | Ví dụ: nghỉ từ thứ Hai đến thứ Sáu tuần sau = 10 ngày làm việc nhưng 12 ngày lịch → (a) thiếu 2 ngày. | (b) ngày lịch. | Ngày lịch: stagnation_deadline = stagnation_deadline + Requested_Days. Không build logic ngày làm việc / lịch nghỉ lễ (Rippling tự tính working days cho Used_DTO vs DTO_Days). (Client sheet F13-03, 2026-11-04) | ✅ 2026-11-04 |
2. International Contractor form (Path B)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F13-05 | "Request Time Off" form: (a) Is Reason mandatory, and is there a max length? (b) Is Requested Days counted as calendar days including both start and end date? (c) Can Start Date be in the past? (d) The design has no Cancel button — how does the trader close the modal (X icon, click outside, Esc)? | UC_9.2 Q-4 / BR_9.2.20. Design: References/Wireframe/Dashboard/Flow 13_Request Time Off modal (International).jpg. | (a) Không bắt buộc, ≤ 500 ký tự; (b) ngày lịch, tính cả 2 đầu; (c) Start Date ≥ hôm nay; (d) X / click ngoài / Esc. | ⏳ |
3. Account lock & return
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F13-06 | When we lock the trader's account for time-off (Rithmic Suspend / MT5 Read-Only / TE Lock), do we also rotate their platform credentials (new password), or only lock the account and keep the same credentials? | UC_9.2 A-4/B-4, BR_9.2.17 ghi credentials_last_rotated_at = NOW() với nguồn "Supplement §3.3" — không có trong References. V7 chỉ ghi "Disable Trading Account via Middleware (Lock)". | Chỉ khoá, không đổi credential → bỏ ghi credentials_last_rotated_at. | 🗑️ Không gửi — đã xoá credentials_last_rotated_at khỏi UC_9.2 (2026-10-28) | |
| F13-07 | The Return Protocol Safety Check halts re-enablement if Trader_Status == 'Banned_Chargeback'. Per Flow 14, Banned_Chargeback is only set for Challenge (SIM) traders (Scenario A); Live traders (Scenario B) are only paused, never auto-banned. Since Flow 13 only applies to Level 6+ Live traders, should the Safety Check also halt when a Live trader has an open, unresolved dispute? If yes, which field marks that state (e.g. dispute_status = 'Open')? | Theo V7, Safety Check gần như không bao giờ chặn được trader Live → trader Live mở dispute khi đang nghỉ vẫn bị tự mở lại tài khoản. Exc-5 của UC_9.2 (nguồn "Supplement §7") đang trái V7. | Chặn khi có dispute đang mở; field chưa xác định. | Có chặn — qua payout_status: dispute hold của Live trader (Flow 14) set payout_status ≠ Approved → Safety Check chặn re-enable (xem F13-08). Không cần field mới. (Client sheet F13-05, 2026-11-04) | ✅ 2026-11-04 |
| F13-08 | Compliance_Flagged is used in the Flow 13 Safety Check but no flow in the spec sets it. What sets this status (e.g. Dots compliance.flagged = true, Checkr "consider", a manual Ops action)? | Chỉ xuất hiện ở Zapier V7 §Flow 13 Safety Check. | Chưa có giả định. | Compliance_Flagged không phải field/flow riêng. Return Safety Check đọc bảng Users (PostgreSQL), chặn re-enable + cảnh báo Ops trên Slack nếu: (1) user nằm trong email_blacklist; (2) Users.status ∈ {Banned_Chargeback, Failed, Terminated}; (3) Users.payout_status ≠ Approved (VD Hold/Flagged do BPS Apply Payout Hold, Dots webhook, hoặc Flow 14 Live dispute hold). Không thêm cột mới. ⚠️ Cần kiểm tra Failed/Terminated có trong enum Users.status. (Client sheet F13-04 + F13-05, 2026-11-04) | ✅ 2026-11-04 |
| F13-09 | Is Trader_Status (used in the Safety Check) a PostgreSQL Users field or the ActiveCampaign CRM status? Flow 14 says "Set CRM Status to Banned_Chargeback". | Ảnh hưởng chỗ middleware đọc khi chạy Safety Check. | PostgreSQL Users. | Luôn đọc bảng Users PostgreSQL. Không bao giờ query ActiveCampaign cho trạng thái vận hành / risk / compliance gate. (Client sheet F13-06, 2026-11-04) | ✅ 2026-11-04 |
4. Pod Leader & Founding Mentor during leave
Các mục UC_9.2 §4.1, UC_8.2.10 §7.1, UC_8.2.13 §6.1 đang cite "RFQ V7 §Time-Off & Hiatus Management Engine" — mục này không tồn tại trong V7.
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F13-10 | When a Pod Leader (Level 7+) or a Founding Mentor is on approved time-off / hiatus, should we keep everything that belongs to their Pod Leader role: (a) Google Workspace @stacktrading.com stays active, (b) Discord channel pod-[leader_name] is not archived, (c) Discord "Pod Leader" role is not revoked, (d) mentees stay in their pod? And should we block the POD_LEADER_TERMINATED webhook and Flow 15C (offboarding) for the whole leave period? | UC_9.2 §4.1.1–4.1.2; UC_8.2.10 §7.1.1; UC_8.2.13 §6.1.1. | Giữ nguyên tất cả; chặn Flow 15C. | YES cả 5 ý (a–e). Nghỉ phép (Flow 13) là tạm thời, KHÔNG phải Drawdown Defense (Flow 4B) hay Termination (Flow 15C). Giữ Workspace @stacktrading.com (vẫn nhận Wednesday AI Brief), không archive kênh pod-[leader_name], không thu role "Pod Leader", không giải tán pod / điều chuyển mentee; chặn POD_LEADER_TERMINATED / Flow 15C trong kỳ nghỉ. Khách dẫn POD Joining Row 64; POD Leader Rows 5, 12, 23. (Client reply 2026-10-30) | ✅ 2026-10-30 |
| F13-11 | Should we add a new status On_Leave to Pod_Leader_Registry? Today we have Active / Suspended / Terminated / Permanently_Ineligible / Acting_Cover / Reassigned. If yes, can a leader in On_Leave be matched with new mentees (Flow 10) during the leave? | UC_8.2.10 §7.1.2; liên quan [POD-JOIN-19] (chưa trả lời). | Thêm On_Leave; không nhận mentee mới. | YES thêm 'On_Leave'; NO match mentee mới. Flow 10 chỉ match Status == 'Active' (POD Joining Row 17 = POD-JOIN-19) nên On_Leave tự bị loại, không kích hoạt logic giải tán pod Suspended của Flow 15A. Return Protocol (Flow 13) set lại 'Active'. (Client reply 2026-10-30) | ✅ 2026-10-30 |
| F13-12 | For a regular Pod Leader on leave, should Pending_Carry_Balance be frozen (no vesting, no reduction) and the monthly vest run (Flow 17) skip them, with vesting resuming on the 1st of the month after they return? | UC_9.2 §4.1.3; UC_8.2.10 §7.1.3. | Đóng băng. | ⚠️ KHÔNG đóng băng — trái giả định. Theo loại khoản chi trong kỳ nghỉ: (1) W-2 base salary (Path A) vẫn trả qua Rippling payroll; (2) International retainer (Path B) tạm dừng, resume khi quay lại; (3) Trading performance payout (Flow 5): đã đạt trước kỳ nghỉ vẫn xử lý bình thường (tài khoản bị lock nên không đạt target mới); (4) Pod Leader carry (Flow 17) tiếp tục accrue và vest bình thường ngày 1 hàng tháng cho mọi Pod Leader đang DTO/Hiatus — carry chỉ bị đóng băng/mất khi Drawdown Defense hoặc Terminated (Flow 15C). (Client sheet F13-07, 2026-11-04) | ✅ 2026-11-04 |
| F13-13 | For a Founding Mentor on leave, should Pending_Carry_Balance be (a) frozen, the same as regular Pod Leaders, or (b) left unchanged and still vesting normally (Defense Bypass exemption)? | UC_8.2.13 §6.1.1 tự mâu thuẫn (bảng ghi "Frozen", đoạn văn ghi "exempted entirely"); UC_9.2 §4.1.3 ghi "frozen". | Chưa thống nhất. | Không còn ý nghĩa — mọi Pod Leader (kể cả Founding Mentor) đều vest bình thường khi nghỉ phép (xem F13-12). (Client sheet F13-07, 2026-11-04) | ✅ 2026-11-04 |
| F13-14 | While a Pod Leader / Founding Mentor is on leave, how should pod SLAs be covered (e.g. reviewing a mentee's Trading Plan within 72h, or the leader's 5-Day Induction for a new mentee)? (a) BPS Admin assigns a temporary "Acting Cover" Pod Leader with read-only access to the mentee's reports — the mentee stays in the original pod, and the cover ends automatically on the leave end date; (b) mentees are re-matched to another pod (as in Flow 15A when a leader is Suspended); or (c) nothing — SLAs are paused during the leader's leave? | UC_9.2 §4.1.4 và UC_8.2.13 §6.1.2 đã bị xoá 2026-10-28 (không có nguồn) → hiện UC chưa có cơ chế cover. 72h Trading Plan là SLA của mentee; 5-Day Induction là SLA của leader. | Chưa có. | Pause SLA timers — không Acting Cover, không re-match. SLA cron loại user Inactive_Hold (Flow 12) hoặc Locked do DTO/Hiatus (Flow 13) — Row 59 = POD-SLA-08; Daily Engagement Audit pause cho leader Locked do DTO/Hiatus — Row 95 = POD-AUDIT-10; Calendar Auditor miễn cho leader DTO/Hiatus — Row 49 = POD-DISP-08. ⚠️ Khách ghi "Option A" nhưng nội dung = option (c) của câu hỏi; ghi theo nội dung. (Client reply 2026-10-30) | ✅ 2026-10-30 |
| F13-15 | In Flow 15A, "Acting_Cover (Temp)" is set when a leader is Suspended and their mentees are re-matched. Is that the same "Acting Cover" as in F13-14 (temporary, mentees not moved), or a different concept? | Zapier V7 §Flow 15A. Sau F13-14 (2026-10-30: pause SLA), "Acting Cover" không dùng cho kỳ nghỉ — câu hỏi chỉ còn để xác nhận nghĩa của Acting_Cover trong Flow 15A. | Khác nhau. | ⏳ | |
| F13-16 | We understand the Founding Mentor exception only protects their administrative roles (Pod Leader role, Discord channel, Workspace), not their trading account. So during leave their trading account is locked and open positions are closed, the same as any trader. Is that correct? | Có nguồn: RFQ V7 §Founding Mentor Defense Bypass; BR_9.2.19. Chỉ xác nhận lại. | Đúng. | ⏳ |
Flow 18 — Configuration Database Backup (UC_9.3)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F18-01 | When the config backup or its verification still fails after all retries, how should the team be alerted: (a) Slack only, (b) a Freshdesk ticket, or (c) both? The spec says "Slack alert to #dev_ops", and our Slack channel list maps Config DB Backup alerts to #ops-dev — please confirm the channel. Should a Slack message also be sent on every successful daily backup? | Zapier V7 §Flow 18: "Slack alert to #dev_ops confirming successful backup or failure". slack_channel_usage.md (CR-15.2): #ops-dev = "Config DB Backup success/failure notifications". Freshdesk không có trong nguồn Flow 18. Spec mới chỉ gửi khi lỗi sau 3 lần retry. | Slack #ops-dev, gửi cả thành công lẫn thất bại; không tạo Freshdesk ticket. | Chỉ Slack #ops-dev (✅ khi thành công, 🚨 sau lần retry thứ 3); không Freshdesk — quyết định 2026-10-28 | ✅ Đã chốt nội bộ — không gửi khách |
| F18-02 | The spec marks S3 Object Lock as optional for config snapshots. Should it be mandatory, in Compliance Mode? Note: in Compliance Mode nobody (including AWS root) can delete a backup before its retention date. | Zapier V7 §Flow 18: "Object Lock for config snapshots (optional)". Spec mới ghi "bắt buộc — Compliance Mode". | Bắt buộc, Compliance Mode, retention 61 tháng. | ⏳ | |
| F18-03 | Proposed storage tiers: 0–12 months S3 Glacier Instant Retrieval, 13–24 months S3 Glacier Flexible Retrieval, 25–61 months S3 Glacier Deep Archive, delete after 61 months. The compliance section requires the first 2 years to be "immediately accessible", but Flexible Retrieval takes minutes to hours. Should months 13–24 stay on Instant Retrieval? And is automatic deletion after 61 months (5 years + 1 month) correct for config backups? | RFQ V7 §5.0 Compliance: "only 2 years have to be immediately accessible… Moving objects > 25 months to the cold storage bucket"; NFA: "5 years and 1 month". Đoạn này viết cho order/execution log; áp cho config backup là suy luận. | Instant Retrieval 0–24 tháng; Deep Archive 25–61 tháng; xoá sau 61 tháng. | Adam: backup là restoration point, không phải audit log; hot storage giữ tối đa 1 quý, còn lại vào cold tới 5 năm 1 tháng. Adrian (implementation): không viết cron nén theo tuần/tháng; cron hằng ngày upload file JSON vào prefix S3 backup, cấu hình S3 Lifecycle Rule: S3 Standard → S3 Glacier sau 90 ngày, expire/xoá sau 1,856 ngày (5 năm 1 tháng). (Client sheet F18-01 + F18-03, 2026-11-04) | ✅ 2026-11-04 |
| F18-04 | The backup runs "Daily at 02:00 AM CST". Should it run at 02:00 Chicago local time all year (07:00 UTC during daylight saving), or at a fixed 08:00 UTC? | Spec mới ghi "08:00 AM UTC (02:00 AM CST)" — chỉ đúng khi không có DST. | Cố định 02:00 giờ Chicago. | ⚠️ Chạy 02:00 UTC cố định mỗi ngày (không DST) — không phải 02:00 CST. Khách chốt thêm: mọi backend cron trong toàn hệ thống chạy theo UTC cố định. (Client sheet F18-02, 2026-11-04) | ✅ 2026-11-04 |
| F18-05 | Cross-region replication is "recommended" in the spec. Should we enable it (e.g. replicate to a second US region)? | Zapier V7 §Flow 18: "cross-region replication for DR (recommended)". Spec mới không nhắc. | Bật. | ⏳ |
Flow 32 — Velocity Reward Engine (UC_9.14)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F32-01 | The Velocity reward milestones are described differently in two places: (a) Zapier spec Flow 32 and your earlier answer: a 100% Associate Track code at 3 or 6 referrals; (b) the #velocity-intel pinned message: a 100% Associate Track code for every 2 sales, a bundle (1 Free Associate Track + 1 Free Reset + 1 Free Time Extension) at 6 sales, and the structure resets every 4 referrals. Which one is correct? | Zapier V7 §Flow 32 + QnA STAGE1-064 = 3/6. Pinned copy trong Discord Server Details.md (không có trong manifest) = 2/6 + bundle + chu kỳ 4, và tự mâu thuẫn ("4-Referral Milestone: Reaching 6 sales"). Trader đọc được nội dung pinned này. | 3/6 (theo QnA). | Mốc 3/6 — mỗi mốc 1 code EVAL_L1 100% (Zapier V7 §Flow 32 "Milestone Reached: 3 or 6 Referrals"; QnA STAGE1-064). Pinned message #velocity-intel (2/6 + chu kỳ 4) không phải nguồn chính thức. (BA chốt 2026-11-05) | ✅ 2026-11-05 |
| F32-02 | If the bundle in F32-01(b) is correct: should the 6-referral milestone issue 3 separate single-use codes (Associate Track, Reset, Time Extension), or one code covering all three? | Chỉ hỏi nếu F32-01 = (b). POST /generate-promo-code hiện chỉ có type + origin_user_id. | — | 3 promo code dùng 1 lần riêng biệt: product_id = EVAL_L1 (Associate Track), RESET, EXTENSION; gửi cả 3 trong 1 email Velocity_Reward_Unlocked. Không build bundle wallet. Flow 32 thuộc Release 2. (Client sheet F32-01, 2026-11-04) ⚠️ Không áp dụng — câu trả lời dựa trên phương án (b); F32-01 chốt 3/6 (2026-11-05) nên mỗi mốc chỉ 1 code EVAL_L1. | ✅ 2026-11-04 |
Flow 33 — Amplify Bounty (UC_9.15)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F33-01 | Can a Discord member whose discord_user_id is not linked to a Stack Trading account submit /submit-bounty? If yes, who receives the code and the email? | UC_9.15 Q1. | Phải link trước; chưa link → bot từ chối và hướng dẫn /link ở #verify. | Không cần link — ai trong Discord server cũng chạy được /submit-bounty. (1) Rate limit 1/24h và strike anti-bot tính theo discord_user_id; (2) thành công → luôn gửi code qua Discord DM; (3) query Users theo discord_user_id: có user + email → gửi thêm email; không có → bỏ bước email. (Client sheet F33-01, 2026-11-04) | ✅ 2026-11-04 |
| F33-02 | Is there a cap on Amplify rewards per trader (e.g. max 1 reward per 30 days)? The spec only defines 1 submission per 24h and 1 reward per URL. | UC_9.15 Q2. | Không giới hạn ngoài quy định V7. | ⏳ | |
| F33-03 | Which product does the Amplify 100% code apply to — any Level 1 Associate Track (any account size / market), or a specific one? | UC_9.15 Q3. | Mọi Associate Track Level 1. | ⏳ | |
| F33-04 | The success DM says the code "has also been sent to your email". Which email is this — a Klaviyo event (like Velocity_Reward_Unlocked) or an AWS SES template? Please provide the name and copy. | UC_9.15 Q4. | Klaviyo event (tên tạm Amplify_Reward_Unlocked). | Gửi trực tiếp qua AWS SES (không Klaviyo), chỉ khi discord_user_id đã link tới email trong Users; chưa link → chỉ DM. (Client sheet F33-02, 2026-11-04) | ✅ 2026-11-04 |
| F33-05 | Please confirm the copy for these bot messages (not in the spec): invalid URL (not TikTok / YouTube Shorts), already submitted in the last 24h, and "could not verify — try again later" (social API error). | UC_9.15 Q5. | BA soạn nháp, khách duyệt. | ⏳ | |
| F33-06 | If verification fails because of a social API error (not the trader's fault), does the 24h submission limit still apply? | UC_9.15 Q6. | Vẫn áp dụng. | Retry social API 3 lần (exponential backoff trong 10 giây). Cả 3 lần fail (hoặc URL invalid/private) → vẫn tính vào giới hạn 24h của discord_user_id, DM báo xác minh thất bại và có thể nộp lại sau 24h. (Client sheet F33-03, 2026-11-04) | ✅ 2026-11-04 |
| F33-07 | The Flow 33 rejection DM says "Repeated bot-farming attempts will result in an Amplify Program ban", but the #amplify-intel pinned message says purchased views / bot-farmed comments result in an "immediate and permanent ban". Which rule applies, and is the ban done automatically or manually by Ops? | UC_9.15 Q7. | Vi phạm lặp lại mới ban; Ops ban thủ công. | ⏳ |
Flow 34 — Rippling Payroll Ledger Sync (UC_9.11)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F34-01 | You confirmed Flow 34 also covers severance. Does a Rippling off-cycle run (e.g. severance) fire the same "Payroll Run Cleared" webhook? If yes, should the ledger metric_value still read "$[Total_Amount] Base + Benefits Paid", or use a different wording for severance? | UC_9.11 Q2; QnA A-33 (2026-09-10). | Cùng webhook; câu chữ cho severance chờ chốt. | ⚠️ Flow 34 chỉ xử lý payroll run thường theo lịch — lọc bỏ off-cycle run. Off-cycle W-2 (Performance Bonus Flow 5, Severance Flow 9) tự gọi POST /api/ledger/record trong Flow 5 / Flow 9, xử lý ở Flow 34 sẽ ghi trùng. Payroll thường giữ format: metric_category = "W2 Payroll Executed", metric_value = "$[Total_Amount] Base + Benefits Paid" (2 chữ số thập phân, VD "$2,500.00 Base + Benefits Paid"). (Client sheet F34-01, 2026-11-04) | ✅ 2026-11-04 |
| F34-02 | For the ledger entry, is Total_Amount the gross or the net pay? Is it always in USD? | UC_9.11 Q5. | Gross, USD. | ⏳ |
Flow 35 — Rippling PTO Ledger Sync (UC_9.12)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F35-01 | If an approved PTO is later cancelled or shortened in Rippling, should we write a corrective ledger entry (e.g. "PTO Cancelled"), given the original on-chain entry cannot be changed? | UC_9.12 Q1. Liên quan F13-02. | Không ghi bút toán điều chỉnh. | Không ghi bút toán on-chain điều chỉnh khi PTO bị huỷ/rút ngắn. (Client sheet F35-01, 2026-11-04) | ✅ 2026-11-04 |
| F35-02 | Can approved PTO be a half day? If yes, should the ledger show it as e.g. "0.5 Days PTO Approved (Paid Time Off)"? | UC_9.12 Q3. | Ghi đúng giá trị Rippling trả về. | Chỉ ngày nguyên (không nửa ngày — giới hạn Rippling). metric_value = "[Days_Approved] Days PTO Approved (Paid Time Off)", Days_Approved là số nguyên. (Client sheet F35-02, 2026-11-04) | ✅ 2026-11-04 |
Flow 36 — Dots Retainer Ledger Sync (UC_9.13)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F36-01 | In the ledger text "$[Total_Amount] Retainer Paid ([billing_country])", should the country be the ISO code (e.g. GB) or a label (e.g. UK)? The spec example shows UK. | UC_9.13 Q1. | Mã ISO alpha-2 từ bảng Users. | ⏳ | |
| F36-02 | When a Level 7+ promotion triggers a prorated one-time retainer payment, does Dots send the same "Retainer Processed" event, and should it be logged as its own ledger entry? | UC_9.13 Q2. | Có, ghi thành entry riêng. | ⏳ |
Flow 38 — Support Interception (UC_9.16)
| # | Question | Bối cảnh | Giả định hiện tại | Answer | Status |
|---|---|---|---|---|---|
| F38-01 | In #live-broadcast-chat, when the bot deletes a complaint during a live stream, should it still post the public placeholder reply ("@[User], to protect your account details…")? | UC_9.16 Q1; [DCS-BIZ-21a] (chưa trả lời). | Có, giống các kênh khác. | ⏳ | |
| F38-02 | Should the Freshdesk ticket be tagged with the source channel (e.g. live-broadcast) so Ops can prioritise it during live hours? | UC_9.16 Q2; [DCS-BIZ-21c]. | Tag theo tên kênh. | Description ticket gồm channel_name (VD the-pit, verify, broadcast-chat), discord_username, discord_id, timestamp tin nhắn; payload tạo ticket gửi tags: ["discord-escalation", channel_name]. ⚠️ Khách gọi broadcast-chat, docs đang dùng live-broadcast-chat. (Client sheet F38-01, 2026-11-04) | ✅ 2026-11-04 |
| F38-03 | Flow 38 defines its own confirmation email ("Stack Trading Support Ticket Created - Discord Escalation"), while Freshdesk also sends its default "New Ticket Created" auto-reply. Should the trader receive only the Flow 38 email, only the Freshdesk default, or both? | UC_9.16 Q3; list_email FD-01. | Chỉ email Flow 38 cho ticket tag Discord_Escalation. | ⏳ | |
| F38-04 | If the complaining Discord user is not linked to any Stack Trading account, should we (a) still create a ticket with a placeholder requester and alert Ops in Slack, or (b) not create a ticket? | UC_9.16 Q4 / Exc-1. | (a). | Option (b) — trái giả định. discord_id không link với Users → KHÔNG tạo Freshdesk ticket (email placeholder bị bounce, Ops không reply được). Bot vẫn xoá tin nhắn, reply công khai hướng dẫn link tài khoản hoặc email support@stacktrading.com, và post Slack #ops-general với discord_username, channel_name, message_text. (Client sheet F38-02, 2026-11-04) | ✅ 2026-11-04 |
| F38-05 | A complaint posted in #live-broadcast-chat may already be shown on the dashboard Live Chat before the bot deletes it. Should the dashboard remove it as well? | UC_9.16 Q5; CR-20260818-002 Q4. | Ngoài phạm vi cho tới khi khách chốt. | Release 1/2: chỉ xoá trên Discord là đủ. Day 2: dùng WebSocket DISCORD_CHAT_STREAM — (1) pre-filter: tin #broadcast-chat có trigger word được giữ lại chờ Gemini Flash, nếu là complaint thì xoá và không push; hoặc (2) thêm message_id vào payload, bot xoá thì emit delete event để React component gỡ khỏi chat. (Client sheet F38-03, 2026-11-04) | ✅ 2026-11-04 |
| F38-06 | If Gemini is unavailable, should the bot leave the message as-is (fail-open) or treat it as a complaint and intercept it (fail-closed)? | UC_9.16 Q6. | Fail-open. | Fail-open: retry Gemini 1 lần; vẫn lỗi/timeout → giữ nguyên tin nhắn + log warning. Không bao giờ fail-closed. (Client sheet F38-04, 2026-11-04) | ✅ 2026-11-04 |
| F38-07 | Please confirm the full trigger-word list, and whether it differs per channel (#the-pit, #verify, #live-broadcast-chat). Our draft: slippage, lag, frozen, scam, missing payout, Rithmic down, MT5 down, TradingView down, connection dropped. | UC_9.16 Q7; [PIT-BIZ-03], [DCS-BIZ-21b]. | Dùng list nháp cho cả 3 kênh. | ⏳ | |
| F38-08 | If the same trader posts several complaints within a short time, should we create one ticket per message or group them into one ticket? | UC_9.16 Q8. | Mỗi tin nhắn một ticket. | 1 ticket / discord_id / ngày UTC — trái giả định. Complaint tiếp theo trong cùng ngày UTC: bot vẫn xoá tin nhắn, rồi append làm note vào ticket hôm đó HOẶC bỏ qua không tạo ticket mới tới 00:00 UTC hôm sau (team chọn cách đơn giản hơn). (Client sheet F38-05, 2026-11-04) | ✅ 2026-11-04 |
Nội bộ — không gửi khách (BA / Dev tự chốt)
| # | Câu hỏi | Nguồn |
|---|---|---|
| INT-01 | Rippling không nằm trong danh sách provider Option B → Flow 34/35 đi Option A (Rippling → Zapier trực tiếp) hay bổ sung Rippling vào Option B? | UC_9.11 Q1 |
| INT-02 | Số lần retry / backoff của Zapier và kênh Slack khi lỗi lần cuối (Flow 34/35/36). | UC_9.11 Q3 |
| INT-03 | Worker Rippling không map được user_id: chỉ ghi audit hay cảnh báo Ops? | UC_9.11 Q4 |
| INT-04 | Flow 36 có cập nhật bảng invoice (đánh dấu paid) không — V7 không có. | UC_9.13 Q3 |
| INT-05 | UC_9.14 đang mô tả endpoint riêng POST /api/referral/velocity-reward và "không qua Zapier", trái với V7 (Zapier Flow 32 gọi POST /generate-promo-code); một số citation "§Velocity Reward Engine" không có trong V7. | Rà soát UC_9.14 |
| INT-07 | Flow 18: retry tối đa 3 lần, exponential backoff khi backup/verify lỗi — không có trong nguồn (UC_9.3 Exc-1 đang OPEN). Chốt với Dev. | Spec Flow 18 mới |
| INT-06 | UC_4.16.2 BR_4.16.2.12 ("No Write Path… cannot request time off") mâu thuẫn với form Flow 13 Path B → owner UC_4.16.2 cần cập nhật. | CR-20261027-001 |
Changelog
| Date | Version | Change | Notes |
|---|---|---|---|
| 2026-11-05 | v1.6 | F32-01 → ✅ mốc 3/6 (BA chốt, theo Zapier V7 §Flow 32 + STAGE1-064); F32-02 ghi chú không áp dụng (bundle chỉ thuộc phương án (b)) | UC_9.14 v1.1: giữ 1 code EVAL_L1 mỗi mốc; thêm Release 2 |
| 2026-11-04 | v1.5 | Client sheet (Adam/Adrian): 22 câu → ✅ (F13-02/03/04/07/08/09/12/13, F18-03/04, F32-02, F33-01/04/06, F34-01, F35-01/02, F38-02/04/05/06/08); F32-01 note nghiêng (b). Sheet khách đánh số khác — mã gốc ghi trong mỗi Answer | ⚠️ Conflict: carry vẫn vest khi nghỉ (F13-12) vs UC_9.2 §4.1.2/4.1.3, UC_8.2.9/10/13; cron UTC cố định (F18-04) vs POD-BRIEF-01; Flow 34 bỏ off-cycle (F34-01) vs A-33 |
| 2026-10-30 | v1.4 | F13-10, F13-11, F13-14 → ✅ (client reply 2026-10-30, dẫn Stage 6 - POD system sheet); thêm note bối cảnh F13-15 | Đồng bộ QnA_STAGE6_POD_SYSTEM_FLOW10_11.md v1.11 (POD-XF-15/16/17) |
| 2026-10-28 | v1.3 | F18-01 đóng — chỉ Slack #ops-dev, không Freshdesk | Áp vào UC_9.3 v1.2 |
| 2026-10-28 | v1.2 | Thêm mục Flow 18 (F18-01 → F18-05) + INT-07 | Từ spec Flow 18 user cung cấp, đối chiếu Zapier V7 §Flow 18 |
| 2026-10-28 | v1.1 | F13-06 bỏ (đã xoá field khỏi UC_9.2); F13-14 sửa câu chữ + bối cảnh (Acting Cover đã xoá khỏi UC) | Theo quyết định xoá nội dung không có nguồn |
| 2026-10-28 | v1.0 | Tạo file — 39 câu hỏi gửi khách (Flow 13: 16, Flow 32: 2, Flow 33: 7, Flow 34: 2, Flow 35: 2, Flow 36: 2, Flow 38: 8) + 6 câu nội bộ | Tổng hợp từ Open Questions của UC_9.2, 9.11–9.16 và các phát hiện khi rà soát nguồn 2026-10-27/28 |