QnA Init Docs — UC_8.1.2 (Flow 6 - Level 6 Transition: W-2 vs. International)
UC liên quan: UC_8.1.2 — Flow 6: Level 6 Transition (W-2 vs. International) — đại diện toàn bộ Flow 6 (Path A + Path B), tương tự cách UC_8.1.1 đã dùng cho Flow 4A.
Trigger: Flow 4 Stage 5 Path C (Standard Promotion) — "W-2 Check: If New Level >= 6, Trigger Flow 6."
Agent tạo: Agent 2 (Challenger), theo system_init_workflow.md — Init Flow
Ngày tạo: 2026-10-10 (theo ngày session hiện tại)
Nguồn chính: References/QnA from clients/07_STAGE6_CAREER_PATH/level promotion/QnA_Level_Promotion.md — Section 4 (business logic gốc + Round 1), Section 4.1 (Round 2), Section 4.2 (Round 3), Section 4.3 (Round 4), Section 7 (Payment Timing Confirmation).
⚠️ Lưu ý WBS: UC_8.1 tồn tại trong WBS (node script/parse_wbs.js --compact) với function = "Flow 6 - L6 Transition", status_document = "Todo" (chưa có BA document). Theo chỉ đạo đã áp dụng cho UC_8.1.1, BA dùng UC_8.1.2 làm định danh riêng cho SRS sắp viết (đại diện toàn bộ Flow 6), không đổi tên hay xóa row UC_8.1 gốc trong WBS.
Flow 6 đã qua 4 round Q&A với khách (Round 1 → Section 4, Round 2 → Section 4.1, Round 3 → Section 4.2, Round 4 → Section 4.3) cộng thêm Section 7 (Payment Timing Confirmation) xác nhận chéo. Theo bảng Open Questions ở cuối QnA_Level_Promotion.md, Flow 6 chỉ còn đúng 1 open item: LVLPROMO-R4-B5 (nội dung template email SES-13 — khách mới nói "sẽ review", chưa có nội dung). LVLPROMO-R3-A2 không liên quan Flow 6 (thuộc Flow 4A, per-platform PnL reset).
Vì vậy, công việc Challenger ở đây chủ yếu là tổ chức lại các câu trả lời đã có thành format QnA init docs chuẩn (pre-fill cột "BA chốt" + cite đúng Section), và chỉ phát sinh câu hỏi mới (⏳ Chờ BA) cho các gap thực sự còn thiếu: nội dung SES-13, tên field cụ thể cho S3 URI, và error-path chưa được QnA nào đề cập tới (Typeform webhook failure).
CR Index (References/CR/_CR_INDEX.md): đã scan toàn bộ CR Registry — không có CR nào ảnh hưởng trực tiếp Flow 6 / Level 6 Transition / Rippling / Checkr / Dots / W-2 onboarding. CR gần nhất liên quan tới cụm Stage 3 KYC & Live Onboarding (CR-20260812-xxx) chỉ áp dụng cho Flow 3A-3H (KYC trước Live, không phải Level 6 transition sau khi đã Live). CR-20260818-001 (Flow 7 — Pod Impact & Dispersal) có đụng tới pod_leader_id/mentee exit nhưng không đổi logic Flow 6 Path A/B — chỉ liên quan tới Flow 7 (Termination/Rebuy) phần ảnh hưởng Pod, không phải phần "clear comp_track/standard_hours" mà Flow 6 quan tâm. → Không có [CR_CONFLICT] nào cần raise cho UC_8.1.2.
Cross-UC (same category STAGE 6: CAREER PATH & PROFESSIONALIZATION): không phát hiện UC nào khác overlap trực tiếp nội dung Flow 6 — UC_8.1.1 là Flow 4A (Promotion pipeline, khác scope), UC_8.2.12 là Flow 17 (Pod Leader Vesting, chỉ cross-ref phần Payment Timing). Không có [CROSS_UC_CONFLICT].
Missing Dependency (Phase 2.2 item 3): phát hiện 3 cross-UC dependency chưa có SRS — xem bảng Cross-cutting ở cuối file, mục [MISSING_DEPENDENCY].
| 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 | Country Check dùng nguồn nào để route Path A (USA) vs Path B (International) — ActiveCampaign hay internal DB? | — | Đã có sẵn trongQnA_Level_Promotion.md Section 4, Round 1 (General Q/A): "There is no reason to query ActiveCampaign for this. The system must query the internal billing_country directly from the PostgreSQL Users table to route the W-2 vs. International paths." ⚠️ Override Customer supplies — business logic gốc ghi "Query ActiveCampaign Contact Country", bị override hoàn toàn, dùng billing_country (Users table). | ✅ Đã chốt (QnA Section 4, Round 1 General) |
| 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 | Bước "Address Verification: Call USPS API" trong business logic gốc có còn áp dụng không? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 2, Q1-Q3/A1-A3):descope hoàn toàn — "We are removing the custom USPS API address verification step completely. Rippling handles address verification and PO Box exclusions natively during the employee onboarding flow." Email "Address Correction Request" cũng not applicable (Rippling tự prompt user native). ⚠️ Override Customer supplies — toàn bộ Step 2 trong business logic gốc bị loại bỏ, không viết vào SRS. | ✅ Đã chốt (QnA Section 4, Round 1, Path A Step 2) — không còn gì để hỏi, Step này KHÔNG xuất hiện trong SRS. |
| 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-03 | Bước "Background & Compliance Gate (Checkr): POST /candidates + POST /invitations" có còn áp dụng không? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 3, Q1-Q2/A1-A2):descope hoàn toàn — "We are removing the custom Checkr API integration. Rippling handles the background check process natively during onboarding. We do not need to pause the Zap or build custom dashboard waiting states for this." ⚠️ Override Customer supplies — toàn bộ Step 3 (Checkr integration, "consider" result gate, Critical Ops Alert cho background check flag) bị loại bỏ, không viết vào SRS. | ✅ Đã chốt (QnA Section 4, Round 1, Path A Step 3) — không còn gì để hỏi, Step này KHÔNG xuất hiện trong SRS. |
| 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-04 | Level_6_Offer_Configurator được build dạng gì (embed email, dedicated page, hay redirect URL)? | — | Đã có sẵn trong QnA Section 4.1, Round 2 (Q1/A1):Option B — "The Level_6_Offer_Configurator form (and all other forms) should be built as a clean, embedded Typeform hosted on a dedicated page on the Stack Trading site. We want to keep them in our ecosystem." | ✅ Đã chốt (QnA Section 4.1, Round 2, Q1/A1) |
| A-05 | Ai build Typeform trước, và frontend truyền dynamic data (Base_Income/Base_Income_Flex) vào Typeform bằng cách nào? | — | Đã có sẵn trong QnA Section 4.1, Round 2 (Q2/A2): SotaTek build first-pass Typeform (Level 6 Configurator, Mentee Survey, Exit Survey...) trước để map webhook payload cho Zapier flows. Frontend pullBase_Income/Base_Income_Flex từ API, pass vào Typeform URL qua Hidden Fields — Typeform dùng param này để hiển thị đúng số lương cho trader. | ✅ Đã chốt (QnA Section 4.1, Round 2, Q2/A2) |
| A-06 | Validation Logic (Track A 30-35 giờ / Track B ≤29 / International ≤35) có nằm trong CÙNG 1 form hay 2 form riêng biệt? | — | Đã có sẵn trong QnA Section 4.1, Round 2 (Q7/A7):2 form hoàn toàn riêng biệt theo country. Path A Form (US W-2): hỏi Track (A/B) + Hours. Path B Form (International): CHỈ hỏi Hours (không hỏi Track vì international không eligible cho US health benefits), giới hạn ≤35. ⚠️ Correction Customer supplies — business logic gốc liệt kê 3 điều kiện validation (bao gồm Level_6_Offer_International) trong CÙNG 1 block "Validation Logic (Form Level)" như thể 1 form chung — đã bị correction, viết SRS theo đúng 2 form riêng biệt, KHÔNG lặp lại điều kiện <= 35 của Path B vào form Path A. | ✅ Đã chốt (QnA Section 4.1, Round 2, Q7/A7) — correction quan trọng, SRS phải viết 2 form riêng biệt. |
| A-07 | Benefits Selection (Track A — health & welfare enrollment) được build ở đâu? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 4, Q2/A2): KHÔNG build enrollment UI — "Once the trader is hired in Rippling, Rippling's native platform takes over and automatically emails them the portal link to complete their benefits enrollment." Double-confirm ở QnA Section 4.1, Round 2 (Q8/A8): không cần gọi API riêng để email benefits enrollment — tự động khiworker.hire được gọi. | ✅ Đã chốt (QnA Section 4, Round 1 Q2/A2 + Section 4.1, Round 2 Q8/A8) |
| A-08 | requested_hours — user nhập total aggregate hours hay chọn giờ cụ thể trong tuần? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 4, Q3/A3): "They simply enter the total aggregate hours they commit to working per week. There are upper limits specified." | ✅ Đã chốt (QnA Section 4, Round 1, Q3/A3) |
| A-09 | Hours Threshold 30-35 (Track A) và ≤29 (Track B) — có phải chỉ là max, user có thể nhập thấp hơn tùy ý không? Có đổi được sau khi submit không? | — | Đã có sẵn trong QnA Section 4.3, Round 4 (Q2.2/A2.2):Track A bắt buộc nhập trong khoảng 30-35 (30 là minimum pháp lý để đủ điều kiện health benefits, KHÔNG phải chỉ gợi ý — user KHÔNG được nhập thấp hơn 30). Track B: <= 29, không có minimum. LOCK sau khi ký: "Not dynamically through the dashboard. Once they submit that form and the Rippling W-2 contract is generated and signed, their default schedule is locked." Đổi sau khi lock phải mở internal HR support ticket — Day 2 item, không build UI cho case này. | ✅ Đã chốt (QnA Section 4.3, Round 4, Q2.2/A2.2) — Hours Threshold Lock là Business Rule chính thức, phải ghi vào SRS. |
| A-10 | SES-13 — nội dung template email cho bước nào trong Flow 6 Path A, đã có chưa? | Đề xuất: tạm loại khỏi SRS cho tới khi có nội dung xác nhận, đánh dấu[BLOCKED]. | BA xác nhận: nội dung template SES-13 sẽ được bổ sung sau (BA tự thêm khi có). Giữ nguyên đề xuất — loại khỏi SRS cho tới khi có nội dung chính thức. | ⏳ Chờ BA (vẫn open, chờ BA bổ sung sau) — 🔴 BLOCKED (refLVLPROMO-R4-B5), loại nội dung template SES-13 khỏi SRS cho tới khi có nội dung chính thức. |
| A-11 | comp_track lưu giá trị gì trong DB — "standard"/"flex" hay "Standard"/"Flex"? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 4, Q4/A4): "Yes, comp_track maps to 'Standard' or 'Flex'." | ✅ Đã chốt (QnA Section 4, Round 1, Q4/A4) |
| 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-12 | Middleware có tự checkEmployee_Exists trước để quyết định gọi Rehire hay Create New không? | — | Đã có sẵn trong QnA Section 4.1, Round 2 (Q9/A9) + Section 4, Round 1 (Path A Step 5, Q1/A1):KHÔNG — middleware chỉ gọi 1 endpoint duy nhất /events/hr/v1/worker.hire. Rippling tự detect existing profile qua email/SSN và tự xử lý "rehire" vs "create new" phía server của Rippling. ⚠️ Correction Customer supplies — business logic gốc viết tuần tự "Check: IF Employee_Exists in Rippling -> Rehire. ELSE -> Create New" như thể middleware tự check trước — đã bị correction, SRS phải viết đúng: middleware chỉ gọi 1 API call, không tự phân nhánh. | ✅ Đã chốt (QnA Section 4, Round 1 Q1/A1 + Section 4.1, Round 2 Q9/A9) — correction quan trọng. |
| A-13 | Signwell hay Rippling xử lý agreement cho Path A (US W-2)? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 5, Q1/A1): Signwell chỉ dùng cho Contractor agreements (Level 1-5 và International). Path A (US W-2) dùngRippling (HRIS/payroll engine chính thức cho W-2). | ✅ Đã chốt (QnA Section 4, Round 1, Q1/A1) |
| A-14 | Rippling yêu cầu daily hours breakdown (giờ/ngày) thay vì cumulative weekly total — middleware tự chia đềuRequested_Hours cho M-F có đúng không? | — | Đã có sẵn trong QnA Section 4.3, Round 4 (Q1/A1):Xác nhận đúng — "dividing the Requested_Hours evenly across those five days is the correct way to handle Rippling's programmatic requirement." Công thức: hours_per_day = Requested_Hours / 5, áp dụng cho M-F (theo giờ mở sàn). Ví dụ: 20 giờ/tuần → 4 giờ/ngày. | ✅ Đã chốt (QnA Section 4.3, Round 4, Q1/A1) — Business Rule mới cho payloadWork_Schedule gửi Rippling, phải ghi rõ công thức trong SRS. |
| 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-15 | W2_Offer_Template đã có sẵn chưa, ai build? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 6, Q1/A1): "The W2_offer_template will be built natively inside of Rippling." SotaTek không build template này. | ✅ Đã chốt (QnA Section 4, Round 1, Q1/A1) |
| A-16 | Hourly_Rate lấy từ đâu khiBase_Income_Type == 'Hourly'? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 6, Q2/A2): Hourly_Rate =Base_Income (nếu chọn Standard track) hoặc Base_Income_Flex (nếu chọn Flex track) — pull trực tiếp từ Table A/B theo track đã chọn. | ✅ Đã chốt (QnA Section 4, Round 1, Q2/A2) |
| A-17 | base_income_type có bao giờ = N/A khi base_income/base_income_flex > 0 không? Khi Annual thì có tính hourly rate không? | — | Đã có sẵn trong QnA Section 4.1, Round 2 (Q4/A4):KHÔNG — base_income_type = N/A chỉ xảy ra khi income = $0 (Level 1-5). Khi = 'Annual': KHÔNG tính hourly rate — gửi trực tiếp giá trị annualized đã lưu ở Base_Income/Base_Income_Flex sang Rippling, không qua công thức chuyển đổi nào. | ✅ Đã chốt (QnA Section 4.1, Round 2, Q4/A4) |
| A-18 | base_income_type có user-editable không (user có tự đổi Hourly ↔ Annual được không)? | — | Đã có sẵn trong QnA Section 4.3, Round 4 (Q2.1/A2.1):KHÔNG user-editable — hardcoded theo Level trong Zapier Table A/B: 'Hourly' cho Level 6-9, tự động đổi thành 'Annual' khi lên Level 10 (Senior Trader 1). Middleware chỉ đọc giá trị theo current_level, không cho ghi đè. | ✅ Đã chốt (QnA Section 4.3, Round 4, Q2.1/A2.1) — Business Rule mới, phải ghi vào SRS (Base_Income_Type Lock). |
| A-19 | Form "Send W2_Offer via Rippling with Identity Confirmation checkbox" — form này host và config hoàn toàn trên Rippling? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 6, Q3/A3): "Yes, this form and the identity confirmation are hosted and executed entirely within the Rippling ecosystem." | ✅ Đã chốt (QnA Section 4, Round 1, Q3/A3) |
| 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-20 | receipt_hash ở bước này (Rippling Envelope ID) có cùng cơ chế 2-step (internal ID → on-chain tx_hash qua Ethers.js/Polygon) như đã mô tả ở Flow 4A không? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 7, Q1/A1):Cùng cơ chế — receipt_hash truyền VÀO chỉ là internal reference ID (có thể là DB ID, Rippling Envelope ID, hoặc Dots transaction ID tùy flow); middleware tự khởi tạo wallet, ghi on-chain qua Ethers.js, trả về tx_hash thật. Mọi metric_category ở mọi flow đều được ghi on-chain — không có ngoại lệ. Cơ chế này giống hệt mechanism đã confirm ở UC_8.1.1 (xem UC_8.1.1 A-10) — không lặp lại giải thích chi tiết, chỉ cross-ref. | ✅ Đã chốt (QnA Section 4, Round 1, Q1/A1) — cross-refUC_8.1.1 cho chi tiết cơ chế receipt_hash/tx_hash, không viết lại 2 lầ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-21 | "Archive Dots Contractor Profile" nghĩa là xóa data hay có hành động cụ thể gì trên Dots? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 8, Q1/A1): KHÔNG xóa data, KHÔNG có archive function trên Dots side. "To 'archive,' the middleware must suspend the active recurring backend payout trigger for Dots in our database so we do not accidentally double-pay the trader as both a W-2 employee and a contractor." Khách tự nhận xét "Maybe archive is the wrong word" — SRS nên dùng tên chính xác hơn là "Suspend Dots Recurring Payout Trigger", không dùng từ "Archive" gây hiểu nhầm. | ✅ Đã chốt (QnA Section 4, Round 1, Q1/A1) — SRS nên đặt tên bước lại là "Suspend Dots Payout Trigger" thay vì "Archive", tránh gây nhầm lẫ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-22 | Workflow Automator là gì, hoạt động thế nào? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 9, Q1/A1): "Workflow Automator is a native feature inside Rippling that triggers internal tasks and emails based on HR events." | ✅ Đã chốt (QnA Section 4, Round 1, Q1/A1) |
| A-23 | "Trading Hours Declaration" form lấy từ đâu, SotaTek có build không? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 9, Q2/A2): "The 'Trading hours declaration' is a native Rippling compliance form built by our team. SotaTek does not build this." | ✅ Đã chốt (QnA Section 4, Round 1, Q2/A2) |
| 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-24 | I-9 Section 2 + E-Verify có tự động gửi bởi Rippling không? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 10, Q1/A1): "Yes, Rippling handles the I-9 Section 2 and E-verify process automatically." (Nếu E-Verify fail, Ops được Rippling tự alert — xemCommon_rule/slack_channel_usage.md mục #12 "E-Verify / Background Check Flag" → #ops-onboarding.) | ✅ Đã chốt (QnA Section 4, Round 1, Q1/A1) — Ref:Slack Alert #12 cho E-Verify failure routing. |
| A-25 | "Close 1099 Account -> Create W-2 Account" là middleware tự gọi API Rippling, hay tự động xảy ra? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path A Step 10, Q2/A2): KHÔNG phải 1 API action riêng — "This is handled by our middleware suspending the Dots profile trigger (closing the 1099) and relying entirely on the Rippling worker.hire payload (creating the W-2)." Tức là bước này làkết quả tổng hợp của Step 8 (suspend Dots) + Step 5 (worker.hire), không có action riêng nào ở Step 10 cho việc này. | ✅ Đã chốt (QnA Section 4, Round 1, Q2/A2) — SRS nên viết rõ đây là trạng thái tổng hợp (derived state), không phải 1 action/API call riêng ở Step 10. |
| 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-26 | Level_6_Offer_International form chỉ có field requested_hours, có cần build UI riêng không? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path B, Q1/A1): "Yes, the International form only requires the requested hours field. We will use a basic Typeform for this." (Đồng bộ với A-04/A-06 — Option B embed, 2 form riêng biệt, Path B giới hạn ≤35 giờ, không hỏi Track vì international không eligible cho US health benefits.) | ✅ Đã chốt (QnA Section 4, Round 1, Q1/A1 + Section 4.1, Round 2 Q7/A7) |
| A-27 | Email "Dots_Profile_Action_Needed" ai gửi — Dots native hay hệ thống tự build? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path B, Q2/A2): "Yes, Dots natively emails the user if action is needed on their payout profile." | ✅ Đã chốt (QnA Section 4, Round 1, Q2/A2) |
| A-28 | Email "Level_6_International_Contractor" gửi khi nào, qua kênh nào? | — | Đã có sẵn trong QnA Section 4, Round 1 (Path B, Q3/A3): Gửi SAU KHI Dots API trả "Active", quaAWS SES. "Once Dots returns 'Active,' the system fires the 'Level_6_International_Contractor' email via AWS SES to provide their operational instructions." | ✅ Đã chốt (QnA Section 4, Round 1, Q3/A3) |
| A-29 | "Upload: Store signed Independent Contractor Agreement" — lưu ở đâu, field DB nào? | Đề xuất tên field:contractor_agreement_s3_uri (String, Users table) — tạm đặt tên vì khách chưa chỉ định cụ thể. | BA chốt: dùng tên field đề xuất contractor_agreement_s3_uri (String, Users table) — lưu signed agreement vào AWS S3 bucket (secure), lưu S3 object URI vào field này trên PostgreSQL Users table. | ✅ Đã chốt (BA xác nhận field = contractor_agreement_s3_uri, String, Users table, lưu S3 object URI). |
| A-30 | Rippling Action cho Path B — "None. Update the recurring backend trigger for the new Dots monthly retainer" — có action cụ thể nào middleware cần làm không? | — | Business logic gốc (Section 4) đã ghi rõ: Path B KHÔNG có Rippling action (international vẫn là contractor).International Base = Base_Income_Flex. Middleware cần update trigger payout định kỳ cho Dots monthly retainer — cơ chế cụ thể của trigger này được làm rõ ở Section 5 (Flow 8), không lặp lại ở đây: thêm cột users.dots_monthly_retainer (Decimal) + cron job nội bộ ngày 1 hàng tháng gọi POST /v2/transfers (xem QnA Section 5, Round 3, Q4/A4). | ✅ Đã chốt (business logic gốc Section 4 + cross-ref Section 5 Round 3 Q4/A4 cho cơ chế payout cụ thể) |
| 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-31 | Nếu Level 6+ W-2 trader bị terminate (hard breach) rồi rebuy, có cần clear data lương (comp_track, standard_hours) và yêu cầu onboard lại không? | — | Đã có sẵn trong QnA Section 4.1, Round 2 (Q3/A3):Có — "if a Level 6+ W-2 trader is terminated and buys a Rebuy, you must clear comp_track and standard_hours." Trader quay về Associate Track (không salary/benefits). Nếu đạt lại Level 6 → chạy lại toàn bộ Flow 6, gọi lại /events/hr/v1/worker.hire — Rippling tự xử lý rehire vs create new qua email/SSN (không cần middleware tự phân biệt, giống A-12). ⚠️ Bổ sung Customer supplies (liên quan Flow 7 — Termination/Rebuy): step clear comp_track/standard_hours chưa có trong business logic gốc của Flow 7, cần thêm khi viết SRS cho UC Flow 7 (hiện là UC_4.15.5 — xem [MISSING_DEPENDENCY] bên dưới). | ✅ Đã chốt (QnA Section 4.1, Round 2, Q3/A3) — cần đồng bộ sang SRS Flow 7 khi UC đó được viết (xem Missing Dependency). |
| A-32 | Sau khi ký contract, user có switch được giữa Standard/Flex track không? | — | Đã có sẵn trong QnA Section 4.2, Round 3 (Q2/A2):KHÔNG — "Once the contract is signed, the user cannot switch between the Standard and Flex tracks via the dashboard. Any future employment changes will be handled manually by Operations directly within Rippling. Do not build a track-switching UI. Day 2!" | ✅ Đã chốt (QnA Section 4.2, Round 3, Q2/A2) — Track Switching Ban là Business Rule chính thức, Day 2 item, KHÔNG build UI switch track trong scope hiện tại. |
| A-33 | Flex Track (base_income_flex) có nhận trading bonus khác với Standard Track không? | — | Đã có sẵn trong QnA Section 4.2, Round 3 (Q2.1/A2.1):KHÔNG khác — "base_income_flex users receive the exact same trading bonuses as standard users when they hit their Profit Targets. The track choice only dictates their base pay structure and benefits eligibility, it does not reduce or alter their trading bonus payouts." | ✅ Đã chốt (QnA Section 4.2, Round 3, Q2.1/A2.1) — Flex Bonus Parity là Business Rule chính thức: track chỉ ảnh hưởng base pay + benefits eligibility, KHÔNG ảnh hưởng Level/Performance Bonus. |
| A-34 | Rippling account (login credentials cho trader) được gửi tự động hay Ops phải gửi tay? | — | Đã có sẵn trong QnA Section 4.2, Round 3 (Q3/A3):Fully automated — "Rippling should automatically email the onboarding invitation and login credentials when the middleware successfully triggers the right Rippling endpoint. Stack Operations does not need to send this manually." | ✅ Đã chốt (QnA Section 4.2, Round 3, Q3/A3) |
| A-35 | Pending_Carry_Balance / Level Bonus / Recurring Salary cho Flow 6 Path A & B — timing chi trả cụ thể là gì? | — | Đã có sẵn đầy đủ trong QnA Section 7 (Payment Timing Confirmation) — xem bảng 3 mechanism (Pending_Carry_Balance → Flow 17 monthly ngày 1; Level/Performance Bonus → Flow 5 ngay lập tức; Recurring Salary → Flow 34/Rippling payroll cycle cho US, Dots monthly retainer trả trước cho International). Chi tiết đầy đủ, không lặp lại ở đây — xem cross-reference ở QnA Section 4.1 ngay dưới Round 2 (đã dọn duplicate, chỉ còn link). | ✅ Đã chốt (QnA Section 7) — SRS chỉ cần cross-ref Section 7, không lặp lại nội dung. |
| A-36 | [GAP — chưa có QnA nào trả lời] Nếu Typeform webhook (Level_6_Offer_Configurator hoặc Level_6_Offer_International) gửi submission nhưng Zapier không nhận được (webhook fail/timeout), có retry hoặc alert nào không? | — | BA chốt: không cover case này — loại khỏi scope SRS. | ✅ Đã chốt (BA: không cover case này, loại khỏi SRS). |
| A-37 | worker.hire (Rippling) fail — có rollback/compensating action nào không? | — | BA chốt Business Rule chung cho Flow 6: không cover riêng rollback DB write ordering — bất kỳ API call ra bên thứ 3 nào trong Flow 6 (Rippling/Dots/...) fail → bắn Slack alert mức SEV-01 và HALT flow ngay tại bước đó. | ✅ Đã chốt (BA: Business Rule chung — mọi 3rd-party API call fail trong Flow 6 → Slack alert SEV-01 + HALT flow). |
| A-38 | Dots "Suspended" (Path B) — flow HALT vô thời hạn. Có cần timeout/escalate cho Ops không? | — | BA chốt: không cần cover case này — giữ nguyên HALT vô thời hạn theo business logic gốc, không thêm escalation/timeout logic. | ✅ Đã chốt (BA: không cần cover, giữ HALT vô thời hạn như spec gốc). |
Flow 6 tham chiếu tới các flow sau, kiểm tra qua node script/parse_wbs.js --compact:
| Flow tham chiếu | WBS UC_ID | Trạng thái WBS | Điểm chạm với Flow 6 |
|---|
| Flow 7 (Termination/Rebuy) | UC_4.15.5 (category STAGE 2.2: DASHBOARD LIVE, function "Scenario D: Senior Exit (Level 6+)") | Todo — chưa có BA document | Flow 6 Round 2 (A-31) xác nhận: terminate + rebuy phải clearcomp_track/standard_hours, quay Associate Track. Business logic này PHẢI được viết vào SRS của UC_4.15.5 khi UC đó được author — SRS của UC_8.1.2 chỉ nên cross-ref, không tự lặp lại full logic của Flow 7. |
| Flow 15A (Leader Exit — Pod Leader Carry forfeiture) | Không tìm thấy UC_ID riêng trong WBS | N/A — không có row | QnA Section 7 xác nhận Flow 15A xử lý forfeiture củaPending_Carry_Balance khi Pod Leader bị terminate trước kỳ Flow 17. Đây không trực tiếp thuộc Flow 6 (Flow 6 là về trader cá nhân lên Level 6, không phải riêng Pod Leader), nhưng nếu trader ở Flow 6 ĐỒNG THỜI là Pod Leader thì có điểm giao. Flag [MISSING_DEPENDENCY] nghiêm trọng hơn 2 dòng dưới — Flow 15A chưa có cả WBS row, không chỉ "Todo". |
| Flow 17 (Pod Leader Vesting Payout) | UC_8.2.12 (category STAGE 6: CAREER PATH & PROFESSIONALIZATION, function "Flow 17 - Pod Leader Vesting") | Todo — chưa có BA document | Chỉ cross-ref cho Payment Timing (Section 7) — Pending_Carry_Balance accrue ở Flow 4 Stage 2, chi thật ở Flow 17. KHÔNG liên quan trực tiếp routing Path A/B của Flow 6. |
| Flow 34 (Payroll Run — US W-2 Recurring Salary) | UC_9.11 (category BACKGROUND MECHANISMS & CRON JOBS, function "Rippling Payroll Ledger Sync") | Todo — chưa có BA document | Chỉ cross-ref cho Payment Timing (Section 7) — Recurring Salary cho US W-2 theo chu kỳ payroll Rippling. Flow 6 chỉ tạo W-2 record ban đầu (worker.hire), không tự xử lý payroll run định kỳ. |
Khuyến nghị cho Architect (Agent 3): khi viết SRS cho UC_8.1.2, mọi đoạn liên quan tới Flow 7/15A/17/34 chỉ nên là cross-reference ngắn (link tới UC_ID tương ứng + 1 câu mô tả điểm giao), KHÔNG viết lại full business logic của các flow đó — các UC đích đang Todo, cần tự viết riêng SRS khi tới lượt.
| ID | Nội dung |
|---|
| P-01 | receipt_hash/tx_hash 2-step mechanism (internal reference ID → on-chain Polygon hash qua Ethers.js) lặp lại ở MỌI flow có Immutable Ledger Logging (Flow 4A, Flow 6, Flow 25/26/37). Đã confirm giống nhau 100% ở UC_8.1.1 A-10 và Flow 6 A-20. Đề xuất tách thành 1 shared rule trong common_rules.md (ví dụ CR-18: Immutable Ledger Logging — receipt_hash/tx_hash Mechanism) để các UC chỉ cần cite, không lặp lại giải thích. Chưa tạo CR mới — chỉ ghi nhận candidate, cần BA xác nhận trước khi tách. |
| P-02 | "Fully automated by [3rd-party HRIS/vendor], SotaTek does not build" là pattern lặp lại nhiều lần trong Flow 6 (benefits enrollment, W2 offer template, I-9/E-Verify, Trading Hours Declaration form, account provisioning email) — tất cả đều do Rippling tự động xử lý native. Không cần tách CR riêng (đây là đặc thù vendor, không phải UI/validation rule), nhưng Architect nên liệt kê rõ ràng trong 1 bảng "Rippling-native actions (out of SotaTek build scope)" khi viết SRS, để tránh BE/FE hiểu nhầm cần build thêm. |
- Tổng số dòng câu hỏi: 38 (A-01 → A-38).
- Đã chốt (từ QnA có sẵn hoặc BA trả lời trực tiếp trong review gate): A-01 → A-28, A-29, A-30 → A-38 trừ A-10 (37/38 câu — ~97%). Bao gồm 4 câu BA vừa trả lời trong vòng review này: A-29 (field
contractor_agreement_s3_uri), A-37 (Business Rule chung — 3rd-party API fail → Slack SEV-01 + HALT), A-36 và A-38 (không cover, loại khỏi scope).
- Vẫn
⏳ Chờ BA (chưa trả lời): A-10 (nội dung template email SES-13 — BA xác nhận sẽ bổ sung sau). Đây là item duy nhất còn block.
- Open item kế thừa từ
QnA_Level_Promotion.md (chưa đổi trạng thái): LVLPROMO-R4-B5 (nội dung SES-13) — vẫn BLOCKED, map vào A-10.
- Missing Dependency: 3 flow (Flow 7 →
UC_4.15.5, Flow 17 → UC_8.2.12, Flow 34 → UC_9.11) đều Todo trong WBS; Flow 15A không có WBS row nào — nghiêm trọng nhất, cần BA xác nhận có cần thêm row mới vào WBS không.
- Override/Correction xác nhận (không phải open question, đã có answer): 5 điểm — (1) Country Check dùng
billing_country thay ActiveCampaign (A-01); (2) USPS descope hoàn toàn (A-02); (3) Checkr descope hoàn toàn (A-03); (4) Path A/B là 2 form riêng biệt, không dùng chung validation (A-06); (5) Zero-Entry Onboarding chỉ gọi 1 endpoint, không tự check Employee_Exists trước (A-12).
- Business Rule mới chốt trong review gate: 3rd-party API call fail (bất kỳ bước nào trong Flow 6 gọi Rippling/Dots/...) → Slack alert SEV-01 + HALT flow ngay tại bước đó (A-37) — áp dụng chung, không cần spec riêng từng bước.
- Pattern candidate (chưa tạo CR mới): P-01, P-02.
Đủ điều kiện chuyển sang Agent 3 (Architect) cho 37/38 câu đã chốt. Chỉ A-10 (SES-13 template) còn block — Architect loại nội dung template email cụ thể khỏi SRS, chỉ ghi tên bước + trigger, đánh dấu [Pending BA confirmation — SES-13] cho tới khi có nội dung.