QnA Init Docs — UC_8.5 (Milestone Gifts, Flow 25/26/37)
UC liên quan: UC_8.5 — Perks: Milestone Gifts (Flow 25/26/37)
Trigger: Flow 25 — Flow 1 Step 7 (Perk Check - Generic, Level 1) · Flow 26 — Flow 4A Stage 5 Step 3 (Perk Check, Level 10) · Flow 37 — Webhook từ BPS Admin endpoint Send Goodwill Merch
Agent tạo: Agent 2 (Challenger), theo system_init_workflow.md — Init Flow
Ngày tạo: 2026-10-12
Nguồn:
- Business logic gốc:
Zapier Integration V7.pdf §Flow 25/26/37 (extract: zapier_v7_full.txt dòng 2347-2403, 2562-2581) · Table H Perks_Registry §3.6 (dòng 811-828)
- BPS Admin endpoint:
RFQ_ Stack Trading Prop Tech V7.pdf §BPS Endpoints — "Send Goodwill Merch" (extract: v7_full.txt dòng 2825-2847)
- QnA confirmed:
References/QnA from clients/07_STAGE6_CAREER_PATH/level promotion/QnA_Level_Promotion.md §6 (Round 1, 2026-09-22) + §6.4 (Round 2 re-confirmation, 2026-10-12)
⚠️ Lưu ý cấu trúc (BA xác nhận): UC_8.5 là 1 UC DUY NHẤT, KHÔNG tách thành UC_8.5.1/8.5.2/8.5.3 riêng cho từng flow. Các heading "UC_8.5 — Flow 25/26/37" dưới đây chỉ là section con trong cùng 1 file SRS UC_8.5_v1.md. Pattern Database Update (atomic increment/limit check/Slack alert) lặp lại ở cả 3 flow PHẢI viết thành 1 Business Rule chung (BR local, ví dụ BR_8.5.1) rồi cả 3 flow reference tới BR đó — KHÔNG lặp lại chi tiết 3 lần, KHÔNG thêm Common Rule mới vào common_rules.md (BA đã chốt tại C-13: giữ ở mức BR trong UC, không nâng lên CR).
| Flow | Trigger thực tế | UC sở hữu trigger | Trạng thái UC đó |
|---|
| Flow 25 (Founding 500 Hoodie, Level 1) | Flow 1 (New Trader Onboarding)Step 7 — "Perk Check - Generic": query Table H cho Level = 1, nếu Active == Yes AND Claimed < Limit → trigger Flow 25 | UC_2.8.2 (Flow 1 - Provisioning Pipeline, STAGE 1: CHECKOUT & ONBOARDING) | ✅ Đã có — xem UC_2.7-2.8_v1.md §Step 7 (dòng 1396-1412). UC_8.5 chỉ cần reference, không lặp lại logic Perk Check |
| Flow 26 (Tom James Suit, Level 10) | Flow 4A (Promotion)Stage 5 Step 3 — "Perk Check": query Table H cho Next_Level, nếu đủ điều kiện → trigger Fulfillment_Zap | UC_8.1.1 (đã authored — xem UC_8.1.1_v1.md Stage 5, dòng 194-202) | ✅ Đã có — UC_8.5 chỉ cần reference, không lặp lại logic Perk Check |
| Flow 37 (Goodwill Shirt, Support) | Webhook từ Middleware Hub, do BPS Admin endpointSend Goodwill Merch (POST) fire — endpoint do support team trigger tay qua BPS Admin UI | Thuộc nhóm UC Admin/BPS (chưa xác định UC_ID cụ thể trong WBS — categoryADMIN BPS OPERATIONS hiện chưa có breakdown UC trong node script/parse_wbs.js --compact) | [Not yet authored] — cần BA xác nhận UC_ID cho nhóm BPS Admin Endpoints trước khi link chéo |
Quyết định phạm vi (✅ Đã chốt — BA xác nhận qua C-00/C-00b): UC_8.5 chỉ viết phần fulfillment logic bên trong Flow 25/26/37 (Apliiq order, SES email, Immutable Ledger, Database Update Perk Logic, notify) — đúng như WBS mô tả ("Perks | Milestone Gifts (Flow 25/26/37)"). Phần trigger của Flow 25/26 (Perk Check ở Flow 1 §Step 7 / Flow 4A §Stage 5 Step 3) được reference bằng link tới UC_2.8.2 và UC_8.1.1 (cả 2 đã authored), không viết lại chi tiết. Riêng Flow 37 là ngoại lệ: BPS Admin endpoint Send Goodwill Merch được viết chi tiết đầy đủ (input/output/RBAC/audit) ngay trong UC_8.5 — vì đây là entry point duy nhất của Flow 37 và chưa có UC Admin BPS riêng nào claim phần này.
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|
| C-00 | UC_2.8.2 (Flow 1 - Provisioning Pipeline) chưa được author — Flow 25 (Level 1) phụ thuộc Step 7 "Perk Check - Generic" của UC đó để biết chính xác thời điểm/điều kiện trigger. Có cần block UC_8.5 chờ UC_2.8.2 viết trước không? | Không block — UC_8.5 chỉ reference trigger bằng 1 câu mô tả ngắn (trích đúng business logic gốc: "Triggered by Flow 1 Step 7 if Table H Level=1 Active==Yes AND Claimed<Limit"), đánh dấu[Not yet authored] cho UC_2.8.2, và flag lại khi UC_2.8.2 được viết cần cross-check không có conflict. | UC2.8.2 viết rồi. | ✅ Đã chốt — verify lại: UC_2.8.2 đã author tại docs/BA/UC_2.1-2.8/UC_2.7-2.8_v1.md (dòng 1177-1416), Step 7 "Perk Check - Generic" (dòng 1396-1412) đã có đầy đủ logic trigger Flow 25, khớp hoàn toàn business logic gốc, không conflict. UC_8.5 reference qua link [UC_2.8.2 §Step 7](../../UC_2.1-2.8/UC_2.7-2.8_v1.md#UC_2.8.2), không viết lại chi tiết trigger. |
| C-00b | Flow 37 được trigger qua "Webhook from Middleware Hub (Triggered by the BPS Admin API)" — endpointSend Goodwill Merch thuộc nhóm BPS Admin Endpoints, nhưng WBS hiện không có UC_ID riêng cho nhóm Admin BPS Operations (category = ADMIN BPS OPERATIONS trong WBS không có hàng con nào được parse). UC_8.5 có nên viết luôn chi tiết endpoint Send Goodwill Merch (input/output/RBAC/audit) bên trong UC_8.5, hay chỉ reference và chờ 1 UC Admin riêng? | Đề xuất: viết chi tiết đầy đủ endpointSend Goodwill Merch ngay trong UC_8.5 (vì đây là entry point duy nhất kích hoạt Flow 37, và QnA đã xác nhận rõ "Your responsibility is simply to build the secure backend endpoint" — không có UC Admin khác đang claim phần này). Khi UC Admin BPS Operations được author sau, sẽ reference ngược lại UC_8.5 cho endpoint này. | viết luôn ở đây đi | ✅ Đã chốt — viết chi tiết đầy đủ endpoint Send Goodwill Merch (input/output/RBAC/audit) ngay trong UC_8.5, theo đúng giả định đề xuất. |
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|
| C-01 | Table H ghiLimit = 500 cho Hoodie theo mô tả WBS ("L1: Founding 500 Hoodie via Apliiq API (500 limit)"), nhưng bản extract text của Table H trong zapier_v7_full.txt (dòng 815-828) bị lỗi OCR/table-parsing (dòng Level 1 thiếu cột Limit, dòng "Yes 0 500 Hoodie" bị lệch sang dòng Level 10). Số liệu nào là chuẩn? | Dùng số liệu từ WBS mô tả (đã được BA xác nhận khi lập WBS, sạch hơn bản OCR): Level 1 = 500 (Hoodie), Level 10 = 200 (Suit), Support = 100 (Tee). | Đã có sẵn trong QnA_Level_Promotion.md §6 — khách không correct số liệu Limit nào, chỉ xác nhận luồng vận hành. Dùng số liệu WBS mô tả làm chuẩn (500/200/100), KHÔNG dùng bản OCR lỗi. | ✅ Đã chốt |
| C-02 | shirt_size được map từ Users table sang Apliiq size parameter — field shirt_size được xác nhận tồn tại tại đâu, giá trị enum gì? | Theov7_full.txt dòng 894 (Claim Account endpoint): shirt_size là 1 trong 3 field thu thập cùng new_password/phone_number, enum = Tops: Hoodie, Shirt (nguyên văn source, có vẻ bị cắt — khả năng còn size S/M/L/XL/... bên dưới "Tops:" nhưng extract bị mất). Giả định: shirt_size là 1 field riêng (kiểu Dropdown) lưu size áo (S/M/L/XL/XXL), độc lập với loại áo (Hoodie/Shirt là loại perk, không phải size). | map từ bảng users ấy, luồng checkout UC2.8.2 có nói là lưu shirt size | ✅ Đã chốt — shirt_size map từ Users table (field đã được UC_2.8.2 checkout flow thu thập và lưu), dùng trực tiếp giá trị lưu sẵn, không cần enum riêng cho UC_8.5 |
| C-03 | Flow 25 "Notify" ghi: "Send Email to Trader (Shipping Confirmation template if available from Apliiq, or generic 'Perk on the way')." — đây là 2 lựa chọn template tùy điều kiện (Apliiq có trả shipping confirmation hay không), nhưng QnA Round 1 lại xác nhận email này gửi quaKlaviyo với event Perk_Unlocked_General (payload: user_name, user_email, perk_name, new_level). Vậy 2 template "Shipping Confirmation"/"generic Perk on the way" trong business logic gốc có còn áp dụng không, hay đã bị thay thế hoàn toàn bởi Perk_Unlocked_General qua Klaviyo? | Đề xuất: QnA thắng — Flow 25 Notify step gửiduy nhất qua Klaviyo Perk_Unlocked_General, KHÔNG có nhánh "Shipping Confirmation template from Apliiq" riêng. Business logic gốc mô tả 2 template chỉ là mô tả sơ bộ ban đầu, đã được QnA làm rõ/thay thế bằng cơ chế Klaviyo cụ thể. | Đã có sẵn trong QnA_Level_Promotion.md §6.1: "Yes, this is sent via Klaviyo using the Perk_Unlocked_General event payload... Send the user_name, user_email, perk_name ('Founding 500 Heavyweight Hoodie'), and new_level (Level 1)." → Xác nhận dùng đúng 1 cơ chế Klaviyo, không có nhánh Apliiq Shipping Confirmation riêng. | ✅ Đã chốt (QnA §6.1) |
| C-04 | Flow 25 Database Update ghi "Agency Note: Use database transaction or atomic increment for Claimed count to prevent race conditions during high volume" — đây là yêu cầu kỹ thuật rõ, nhưng cần xác nhận: atomic increment áp dụng ở mức row-lock SQL (UPDATE ... SET Claimed = Claimed + 1 WHERE Level = 1 AND Claimed < Limit) có phải là cách hiểu đúng, và Limit Check (IF Claimed >= Limit: Set Active = No) có cần nằm trong CÙNG 1 transaction với increment để tránh 2 request đồng thời đều pass check Claimed < Limit trước khi increment (race condition kinh điển)? | Đề xuất: dùng single atomic SQL statement kết hợp cả increment + limit check trong 1 câu lệnh (conditional UPDATE:UPDATE Perks_Registry SET Claimed = Claimed + 1, Active = CASE WHEN Claimed + 1 >= Limit THEN 'No' ELSE Active END WHERE Level = 1 AND Active = 'Yes' AND Claimed < Limit), đảm bảo chỉ 1 trong N request đồng thời thành công nếu Limit vừa đạt — các request còn lại nhận rowCount = 0 và phải bypass perk (không retry, không lỗi). | — | ✅ Đã chốt — áp dụng conditional atomic UPDATE như giả định đề xuất (đúng theo Agency Note "Use database transaction or atomic increment... to prevent race conditions") |
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|
| C-05 | 🔴**[BLOCKED — theo yêu cầu BA]** Email "To: reps@tomjames.com (Placeholder)" — BA đã xác nhận trực tiếp: "Tom James credential: Not available yet". Đây là credential thật (email đích) chưa có, không phải lỗi spec. | Không áp dụng giả định — đây là input chưa sẵn sàng từ phía khách/vendor, không phải gap logic cần BA quyết định cách xử lý nghiệp vụ. | BA xác nhận: "Can do later. Not block main flow." → Giữ reps@tomjames.com là placeholder trong SRS, đánh dấu rõ [PENDING VENDOR CREDENTIAL], KHÔNG block việc viết UC_8.5. Khi có địa chỉ email thật từ Tom James, chỉ cần update 1 giá trị config, không đổi logic. | ✅ Đã chốt (theo chỉ đạo BA — xem yêu cầu Init Flow) |
| C-06 | Body email ghi "Budget Code: STACK-SUIT-L10-[ID]" — QnA Q1.1/A1.1 xác nhận[ID] = user_id. Format đầy đủ của Budget Code có phải literal string STACK-SUIT-L10- + user_id nối trực tiếp (vd STACK-SUIT-L10-48213), hay có format khác (zero-padding, prefix riêng cho user_id dạng UUID)? | Đề xuất: literal concatenationSTACK-SUIT-L10- + giá trị thô của user_id (không zero-pad, không transform) — vì QnA chỉ xác nhận mapping, không đề cập format biến đổi. | Đã có sẵn trong QnA_Level_Promotion.md §6.2 Q1.1/A1.1: "[ID] maps directly to the user_id so we can track the budget internally." — xác nhận mapping trực tiếp, không có yêu cầu transform. Dùng giả định concatenation thô. | ✅ Đã chốt (QnA §6.2, áp dụng giả định concatenation do QnA không nêu format biến đổi) |
| C-07 | Immutable Ledger Logging input: QnA §6.4 (Round 2) xác nhận lại rõreceipt_hash = SES message ID, tx_hash = Polygon hash (output, viết vào PostgreSQL). Nhưng field tx_hash có cần truyền vào input của POST /api/ledger/record không, hay tx_hash chỉ là output của chính endpoint đó (middleware tự generate sau khi gọi Ethers.js, không phải input client gửi lên)? | Đề xuất:tx_hash KHÔNG phải input — đây là output do middleware tự sinh ra SAU KHI gọi contract.recordMetric() qua Ethers.js/Alchemy RPC thành công, rồi mới viết tx_hash vào PostgreSQL. Input của /api/ledger/record chỉ gồm: trader_id, metric_category, metric_value, date, receipt_hash (= SES message ID). | Đã có sẵn trong QnA_Level_Promotion.md §6.2 Q2/A2 + §6.4: "the receipt_hash passed into the /api/ledger/record endpoint is that SES message ID, and the tx_hash is the actual Polygon hash returned after the middleware executes the transaction" — xác nhận tx_hash là OUTPUT, không phải input. | ✅ Đã chốt (QnA §6.2/§6.4) |
| C-08 | Flow 26 không có bước "Database Update" tăng Claimed count TRƯỚC khi gửi email — thứ tự thực thi là: gửi email SES → ghi Immutable Ledger → tăng Claimed count, hay tăng Claimed count TRƯỚC rồi mới gửi email (để tránh gửi email cho 201 người nếu Limit = 200 do race condition giữa bước increment và bước gửi email)? | Đề xuất: tăng Claimed count TRƯỚC (atomic conditional UPDATE như C-04), chỉ tiếp tục gửi email SES + ghi ledger nếu increment thành công (rowCount > 0). Nếu increment fail (đã đạt Limit) → bypass toàn bộ flow theo đúng Q4/A4 đã chốt (không gửi email, không ledger, chỉ Slack Ops). | — | ✅ Đã chốt — increment-first áp dụng, nhất quán với Agency Note (atomic pattern) và Q4/A4 (bypass hoàn toàn nếu Active=No) |
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|
| C-09 | EndpointSend Goodwill Merch (nguồn: v7_full.txt dòng 2825-2847, RFQ V7 §BPS Endpoints) có spec đầy đủ: POST, input user_id, admin_id, reason, transcript_url, output HTTP 200 OK, logic "Inventory Check: Queries Table H Perks_Registry for Level='Support'. IF Active==Yes AND Claimed<Limit, proceed. IF Limit Reached, return HTTP 403 Forbidden to the UI with message 'Merch Inventory Depleted'. Execution: Fires a webhook containing the user's shipping address and shirt_size to Zapier (Flow 37)... Audit: Logs to Audit Table and Slack." Đây có phải spec đầy đủ cuối cùng, hay cần thêm RBAC gate cụ thể (các endpoint BPS khác như "Admin Hard Reset"/"Force Session Kick" đều ghi rõ "Requires 'Level_2' or 'Admin' role in JWT. IF Level_1, return HTTP 403 Forbidden" — nhưng dòng spec của "Send Goodwill Merch" KHÔNG ghi RBAC role cụ thể)? | Đề xuất: áp RBAC tối thiểu "Admin JWT authorization layer" theo câu mở đầu chung của toàn bộ §BPS Endpoints ("Agency A must secure all endpoints in this section behind an Admin JWT authorization layer") — không yêu cầu riêng Level_2+ như Hard Reset/Force Session Kick (vì đây là hành động hỗ trợ thông thường, support agent cấp thấp hơn vẫn cần làm được, không phải hành động nguy hiểm như kill account). | Đã có sẵn trong QnA_Level_Promotion.md §6.3 A1: "ensure it is protected behind the Admin JWT authorization layer" — xác nhận chỉ cần Admin JWT layer chung, KHÔNG có yêu cầu RBAC role cụ thể (Level_2+) như các endpoint nguy hiểm khác. Dùng đúng giả định trên. | ✅ Đã chốt (QnA §6.3, dùng Admin JWT layer chung) |
| C-10 | QnA §6.3 A1 ghi: "Our support team will trigger this endpoint manually through our internal BPS Admin interface... Adam has a prototype for this screen that he has already built and needs to hook it up to your endpoints when ready." → BPS Admin UI (frontend) đã có prototype riêng (Adam Culver build), KHÔNG thuộc scope FE của UC_8.5. UC_8.5 chỉ cần mô tả backend endpoint, đúng không? | Đề xuất: đúng — UC_8.5 chỉ viết Backend spec cho endpointSend Goodwill Merch (input/output/logic/RBAC/audit), KHÔNG viết Screen Description cho BPS Admin UI (đã có prototype Figma/code riêng của Adam, ngoài scope Sotatek theo câu trả lời). | Đã có sẵn trong QnA_Level_Promotion.md §6.3 A1: "Adam has a prototype for this screen that he has already built and needs to hook it up to your endpoints when ready." → Xác nhận FE đã có sẵn, Sotatek chỉ cần build + expose endpoint cho Adam's screen gọi vào. | ✅ Đã chốt (QnA §6.3) |
| C-11 | Flow 37 trigger "Webhook from Middleware Hub" — khi endpointSend Goodwill Merch trả HTTP 403 Forbidden (Limit Reached), response này được trả đồng bộ ngay trong response của chính API call đó (user/admin thấy lỗi 403 ngay trên UI), hay middleware vẫn trả 200 OK rồi mới async fire Slack alert "Goodwill Merch Inventory Depleted..."? Business logic Flow 37 (Zapier) viết "Alert: IF Limit Reached -> Notify Ops via Slack" — nhưng spec endpoint lại viết thẳng "return HTTP 403 Forbidden to the UI with message 'Merch Inventory Depleted'" TRƯỚC khi webhook tới Zapier/Flow 37 kịp chạy. Hai cơ chế này có mâu thuẫn không? | Đề xuất: KHÔNG mâu thuẫn — đây là 2 lớp kiểm tra riêng: (1) endpointSend Goodwill Merch tự làm Inventory Check NGAY tại backend TRƯỚC khi fire webhook — nếu Limit đã đạt, trả 403 ngay, KHÔNG fire webhook, KHÔNG trigger Flow 37 (nên Flow 37's "Limit Check" trong Zapier gần như không bao giờ xảy ra vì đã bị chặn ở lớp endpoint); Flow 37's Limit Check trong Zapier chỉ là safety-net cho race condition giữa lúc endpoint check và lúc Zapier xử lý webhook (atomic increment vẫn cần ở layer Zapier/DB để tránh 2 webhook đồng thời đều pass qua endpoint check). | Đồng ý asumption | ✅ Đã chốt — 2-layer check (endpoint pre-check 403 + Zapier atomic increment làm safety net) |
| C-12 | reason field trong input endpoint — có giá trị enum cố định hay freetext? Các BPS endpoint khác cùng pattern (Admin Terminate Live Trader theo QnA Failure and Recovery FR-53) dùng enum reason_code (LAYOFF_NO_CAUSE|TERMINATION_FOR_CAUSE). Send Goodwill Merch có cần enum tương tự (vd lý do support gửi quà: COMPENSATION|GOODWILL|ESCALATION_RESOLUTION) hay chỉ là free-text ghi chú lý do? | Đề xuất: free-text — khác vớireason_code (enum) ở endpoint Terminate, QnA §6.3 chỉ nói "logs the action to the audit table" mà không đề cập enum nào cho Goodwill Merch, và theo RFQ V7 §BPS Endpoints, hầu hết các field tên là reason (không phải reason_code) đều là free-text ghi chú cho audit. | — | ✅ Đã chốt — free-text, max length theo CR-02 Textarea (500 chars) |
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|
| C-13 | [PATTERN] Cả 3 flow (25/26/37) đều lặp lại chính xác cùng 1 pattern: "atomic increment Claimed count → IF Claimed>=Limit: Set Active=No → IF Limit Reached: Notify Ops/Marketing via Slack". Đây là ứng viên tốt để chuẩn hóa thành 1 Common Rule (CR-18: Perk Claim Atomic Increment Pattern) trong common_rules.md, áp dụng chung cho Table H bất kỳ Level/Perk nào (bao gồm cả 4 perk chưa có Fulfillment_Zap: Level 14 Watch, Level 18 Productivity, Level 22 Car — các perk này hiện Active=No, chưa active, nhưng pattern DB sẽ giống khi được active trong tương lai). | Đề xuất thêmCR-18 vào common_rules.md mô tả chung: atomic conditional UPDATE + Limit Check + Slack alert template, để UC tương lai (nếu các perk Level 14/18/22 được active) chỉ cần reference CR-18 thay vì viết lại. | k cần, làm 1 BR chung cho cả 3 cái là dc | ✅ Đã chốt — KHÔNG thêm CR-18 vào common_rules.md. Thay vào đó, viết 1 Business Rule chung (BR local trong UC_8.5, vd BR_8.5.1) mô tả pattern "atomic conditional UPDATE Claimed + Limit Check + Slack alert", rồi reference BR đó từ cả 3 flow (Hoodie/Suit/Goodwill) thay vì lặp lại chi tiết 3 lần. |
| C-14 | Slack alert đích danh 2 cách viết khác nhau trong business logic gốc: Flow 25/26 → "Notify Ops & Marketing"; Flow 37 → "Notify Ops" (không có chữ Marketing). Có tồn tại 2 channel Slack vật lý khác nhau (1 channel Ops-only, 1 channel Ops+Marketing) hay chỉ là cách diễn đạt, thực chất route về cùng 1 channel? | Đề xuất ban đầu: có 2 channel khác nhau, Goodwill chỉ cần Ops biết. [ĐÃ TỰ SỬA — giả định ban đầu SAI]: docs/BA/Common_rule/slack_channel_usage.md (mục 6, 7, 8) đã map sẵn — cả 3 flow (Hoodie/Suit/Goodwill) đều route về CÙNG 1 channel thực tế: #ops-marketing (C0BQX3AV679). Không có channel "Ops-only" riêng nào được định nghĩa cho Goodwill. Chữ "Notify Ops" (không có "& Marketing") trong business logic gốc của Flow 37 chỉ là cách diễn đạt khác, không phản ánh route channel khác biệt. | Dùng #ops-marketing (C0BQX3AV679) cho cả 3 flow, theo đúng slack_channel_usage.md mục 6/7/8 — không tách riêng channel nào theo flow. Message text vẫn giữ nguyên văn khác nhau theo từng flow ("Founding 500 Hoodie Limit Reached!" / "Tom James Suit Limit Reached!" / "Goodwill Merch Inventory Depleted. Support can no longer issue free shirts."), chỉ có đích gửi (channel) là chung. | ✅ Đã chốt (theo slack_channel_usage.md đã có sẵn, không cần hỏi BA thêm) |
| Mức độ | Số lượng | ID |
|---|
| ✅ Đã chốt (QnA/BA xác nhận/common_rule có sẵn) | 16 | C-00, C-00b, C-01, C-02, C-03, C-04, C-05, C-06, C-07, C-08, C-09, C-10, C-11, C-12, C-13, C-14 |
Credential Tom James (C-05): theo chỉ đạo BA trong yêu cầu Init Flow — "Not available yet / Can do later / Not block main flow" — đã chốt KHÔNG block, dùng placeholder reps@tomjames.com, đánh dấu [PENDING VENDOR CREDENTIAL] trong SRS.
Khuyến nghị: C-00/C-00b là 2 điểm scope-boundary quan trọng nhất (ảnh hưởng cấu trúc UC_8.5 — viết gì, reference gì) — nên BA xác nhận TRƯỚC khi Agent 3 (Architect) bắt đầu viết SRS. Các câu còn lại có giả định an toàn, có thể proceed song song nếu BA muốn tiết kiệm thời gian, nhưng Architect sẽ áp dụng [ASSUMPTION] tag và BA cần review lại trước khi coi UC_8.5 là final.