QnA Init Docs — UC_8.2.3 (Flow 10.1B - AI Plan Dispatch + Calendar Compliance)

UC liên quan: UC_8.2.3 — Flow 10.1B: AI Plan Dispatch + Calendar Compliance Trigger: (A) Webhook TRADING_PLAN_ANALYZED từ Middleware · (B) Cron Calendar Compliance Auditor — Daily @ 01:00 UTC Agent tạo: Agent 1 (Auditor) + Agent 2 (Challenger), theo system_init_workflow.md — Init Flow Ngày tạo: 2026-10-12 · Phiên bản: v1 BA phụ trách: Anh Hoang Ghi chú: Phân chia sở hữu nội dung giữa 8 UC Pod: UC_8.2.1 §4.1.

0. Compliance Checklist (Agent 1 — Auditor)

#	Hạng mục	Kết quả	Ghi chú
1	Source pre-flight	✅	Không có CR về Flow 10.1B / Calendar Auditor. QnA: `POD-DISP-*`, `POD-SLA-07`. Nguồn gốc: Zapier Integration V7.pdf §Flow 10.1B · RFQ_ Stack Trading Prop Tech V7.pdf §Log Calendar Strike, §Background Mechanisms — Calendar Compliance Auditor
2	CR-08 Timestamp	✅	Thời điểm event, thời điểm strike, cửa sổ Weekly Report (lịch chạy theo US/Central, dữ liệu lưu UTC)
3	CR-18	✅	Áp cho ca không gửi được DM strike — xem A-08
4	CR-15.2 Slack	✅	Báo cáo strike tuần → `#ops-risk` (P-01)
5	WBS	✅	`UC_8.2.3`, category STAGE 6. WBS ghi open question "strike lưu ở đâu, ngưỡng" — xem A-07
6	Folder	✅	`docs/BA/UC_8.1-8.5/UC_8.2.3/`
7	`[MISSING_DEPENDENCY]`	⚠️	Webhook payload do UC_8.2.2 định nghĩa; bảng `SLA_Deadlines` do UC_8.2.4 định nghĩa (viết cùng đợt)
8	Spec V7 bị QnA override	✅	Xem §2

1. Đã chốt từ QnA / nguồn — không hỏi lại

ID	Nội dung đã chốt	Nguồn
Q-01	Email leader (T-04) do Zapier gửi qua AWS SES; Sotatek map biến (PDF link, AI text, nhắc SLA, calendar link)	`POD-DISP-12`
Q-02	Mọi Pod Leader `Active` có Google Workspace `@stacktrading.com` từ khi lên leader. Email cho leader (dossier, SLA) chỉ gửi vào `@stacktrading.com`, không bao giờ vào email cá nhân. Discord của leader vẫn gắn email cá nhân	`POD-DISP-01`, `POD-SLA-05`
Q-03	PDF vừa đính kèm vừa có link (`pdf_url`); PDF luôn < 25MB	`POD-DISP-03`, `POD-PLAN-04`
Q-04	Mentee không bao giờ nhận AI analysis	`POD-DISP-04`
Q-05	Master Google Calendar link = link đặt lịch tĩnh (kiểu Appointment Schedule), cấu hình sẵn tham số tự thêm `notetaker@stacktrading.com`. Leader bấm → chọn giờ → event mới sinh trên calendar `@stacktrading.com` của leader, mời email đăng ký của mentee + notetaker. Leader tự chọn/đổi giờ. Không bắt buộc số mentee mỗi buổi	`POD-DISP-02`
Q-06	Notetaker = Fireflies; account `notetaker@` do Adam Culver tạo & cấu hình	`POD-DISP-02`
Q-07	Auditor là cron Node.js, chạy Daily @ 01:00 UTC, đọc calendar qua Google Workspace Calendar API bằng Service Account bật Domain-Wide Delegation (Adam cấp JSON key)	`POD-DISP-10/13`, V7 Background Mechanisms
Q-08	Auditor có 2 nhiệm vụ: (1) strike khi event multi-party thiếu notetaker; (2) đóng `Induction_Due` khi thấy event có email mentee + notetaker. Event chỉ cần được tạo, không cần diễn ra trong 5 ngày	`POD-DISP-13`, `POD-SLA-07`
Q-09	"Multi-party" = event trên calendar của leader có ≥ 2 người thật. Quét toàn bộ calendar của leader (không chỉ event từ Master link). Không kiểm tra domain/danh tính khách mời; có notetaker trong guest list → đạt	`POD-DISP-07`
Q-10	Leader không có mentee / đang nghỉ không có event multi-party → tự nhiên không bị strike (không filter tường minh)	`POD-DISP-08`
Q-11	Strike: log `Leader ID`, `Event Timestamp`, `Event Title`, email người tham dự; ghi im lặng vào audit log PostgreSQL; Discord DM leader (copy T-13)	`POD-DISP-06/11` (partial)
Q-12	Weekly Slack Report: tổng số buổi multi-party toàn firm, tổng số vi phạm, danh sách leader bị strike (`Leader_Name` + `Leader_ID`). Thứ Sáu 5:00 PM US/Central; cửa sổ 168 giờ liên tục từ Thứ Sáu 5:00:01 PM tới Thứ Sáu 5:00:00 PM tuần sau. Leader không nhận report	`POD-DISP-09`

2. Spec V7 bị QnA override — đã áp, không cần BA quyết

ID	Spec V7	QnA (thắng)
O-01	Calendar link "auto-inviting notetaker" (hiểu là hệ thống tạo event)	Link đặt lịch tĩnh, leader tự đặt (`POD-DISP-02`)
O-02	Auditor chỉ ghi strike	Thêm nhiệm vụ đóng `Induction_Due` (`POD-DISP-13`)
O-03	`ai_analysis` do Gemini 1.5 Pro sinh	Gemini 3.1 Pro + Extended Thinking (thuộc UC_8.2.2)

3. Câu hỏi & giả định (Agent 2 — Challenger)

3.1 Phần A — Email gửi Pod Leader

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	Email `@stacktrading.com` của leader lưu ở đâu, ai nhập? Middleware cần tra từ `pod_leader_id` ra email này (khác email cá nhân trong `Users`).	Thêm cột email công việc trên `Pod_Leader_Registry`; Ops nhập khi cấp Google account cho leader (Flow 15B). Thiếu email → không gửi, Slack Ops.	Ngoài phạm vi UC này — nơi lưu email `@stacktrading.com` của leader thuộc UC quản lý Pod Leader. UC_8.2.3 chỉ dùng email đó để gửi.	✅ Đã chốt
A-02	Master Calendar link của từng leader lưu ở đâu, ai tạo? Mỗi leader có link đặt lịch riêng (gắn calendar của họ).	Cột `calendar_link` trên `Pod_Leader_Registry`; Ops/Adam tạo link và nhập khi provision leader.	BE gọi API để tạo và lấy link đặt lịch của leader khi gửi email. Không lưu link.	✅ Đã chốt
A-03	Email khi mentee nộp lại plan (`POD-PLAN-05` "email cập nhật cho mentor"). T-04 ghi "A new mentee… has been assigned" và yêu cầu induction 5 ngày — sai ngữ cảnh khi là bản nộp lại.	Không có mẫu "Updated Trading Plan" riêng. Form đã chặn nộp lần 2 nên chỉ có 1 email; nếu lần 2 vẫn xảy ra thì dùng lại đúng mẫu T-04. Khách trả lời 2026-10-22.	✅ Đã chốt

3.2 Phần B — Calendar Compliance Auditor

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	Strike lặp lại hằng ngày cho cùng 1 event. Event thiếu notetaker vẫn nằm trên calendar → mỗi lần cron chạy lại phát hiện → strike + DM mỗi ngày. Event lặp lại (recurring) thì tính mỗi lần hay cả chuỗi?	Mỗi event chỉ bị strike 1 lần (theo ID event của Google). Event lặp lại: mỗi lần diễn ra (instance) tính riêng. Leader thêm notetaker sau khi bị strike → không gỡ strike.	Không strike lại: Task 1 chỉ xét cuộc họp diễn ra trong 24 giờ trước lượt chạy, không xét sự kiện tương lai → mỗi cuộc họp xét đúng 1 lần. Sự kiện lặp lại: mỗi lần diễn ra xét riêng. Khách trả lời 2026-10-22.	✅ Đã chốt
A-05	Cron quét event nào? "Toàn bộ calendar" không nói khoảng thời gian: event mới tạo/sửa từ lần chạy trước, event sắp diễn ra, hay cả event cũ?	Quét event được tạo hoặc sửa từ lần chạy trước (kể cả event diễn ra trong tương lai). Lần chạy đầu: quét từ ngày go-live.	Luôn bỏ sự kiện đã huỷ. Task 1 (strike): cuộc họp nhiều người chưa huỷ, bắt đầu trong [lúc chạy − 24h, lúc chạy); không xét tương lai; lượt lỡ không đọc bù. Task 2 (đóng `Induction_Due`): sự kiện chưa huỷ từ lúc chạy − 24h (BA mở rộng để không sót cuộc họp đã diễn ra giữa 2 lượt) tới lúc chạy + 7 ngày, chỉ mentee còn `Induction_Due` mở; đóng rồi thì không quét lại. Khách trả lời 2026-10-22.	✅ Đã chốt
A-06	Đếm "người thật": tính cả leader (người tổ chức)? Khách mời đã từ chối? Phòng họp / tài nguyên?	Người thật = người tổ chức + khách mời, trừ notetaker và tài nguyên (phòng, thiết bị). Khách mời đã từ chối vẫn tính.	Người thật = người tổ chức (leader) + khách mời, không tính notetaker và tài nguyên (phòng, thiết bị). Khách mời đã từ chối vẫn tính. Cron vẫn kiểm tra `notetaker@stacktrading.com` có trong danh sách khách mời hay không; notetaker chỉ không được đếm là người thật.	✅ Đã chốt
A-07	Lưu strike, ngưỡng, reset, kháng nghị `[POD-DISP-06/11 partial]`: bảng nào; bao nhiêu strike thì có hậu quả; có reset theo kỳ; leader kháng nghị / Ops xoá strike thế nào?	Bảng nhật ký strike riêng trong PostgreSQL (tên bảng do BE chốt). Không có hậu quả tự động (nhất quán SLA, survey, engagement); không reset; không kênh kháng nghị trong hệ thống — Ops xoá tay trong DB.	Strike được ghi im lặng vào PostgreSQL audit log (`POD-DISP-06`). Không có hậu quả, không reset, không kháng nghị.	✅ Đã chốt
A-08	Không gửi được DM strike (leader chưa liên kết Discord, chặn DM, bot lỗi).	Strike vẫn được ghi và vẫn có trong Weekly Report. Discord lỗi tạm (5xx / 429) → giữ DM trong hàng đợi, thử lại tăng dần theo `FR-42`. Leader chưa liên kết Discord / chặn DM / không tìm thấy người nhận → bỏ DM, không thử lại, ghi log (CR-18).	Không retry, không gửi email thay thế. `discord_user_id` rỗng hoặc DM lỗi → ghi log cảnh báo; strike vẫn ghi và vẫn tính vào báo cáo tuần. Khách trả lời 2026-10-22.	✅ Đã chốt
A-09	Đóng `Induction_Due` trễ tới 24 giờ. Auditor chạy 1 lần/ngày, còn SLA cron chạy mỗi giờ (UC_8.2.4) → leader đặt lịch lúc còn 10 giờ vẫn nhận warning / breach sai.	Tách nhiệm vụ (2) chạy mỗi giờ, ngay trước SLA cron; nhiệm vụ (1) strike giữ Daily @ 01:00 UTC.	Day 1 chấp nhận edge case (leader có 5 ngày để đặt lịch). Không thêm cron, không dùng webhook lịch thời gian thực. Khách trả lời 2026-10-22.	✅ Đã chốt
A-10	Event đặt trước khi có `Induction_Due` (leader đặt lịch khi mentee chưa nộp plan) → lúc đó chưa có gì để đóng.	Khi xét `Induction_Due`, cron tìm event có email mentee + notetaker được tạo từ `pod_join_date` trở đi, kể cả event tạo trước khi mở `Induction_Due`.	Vẫn tính. Nhận mọi sự kiện có email mentee + notetaker được tạo từ `pod_join_date` trở đi.	✅ Đã chốt
A-11	Event bị huỷ / xoá sau khi đã đóng `Induction_Due`.	Không mở lại `Induction_Due`.	Không mở lại `Induction_Due`.	✅ Đã chốt
A-12	Phạm vi leader được quét. V7 quét OU "Pod Leaders" trên Google Workspace — ai giữ danh sách OU khi leader mới vào / bị terminate? Leader đã terminate mà vẫn trong OU có bị strike không?	Cron chỉ xử lý leader có `Status = Active` trong `Pod_Leader_Registry` (đối chiếu email công việc — A-01); loại leader đang nghỉ theo danh sách status tại UC_8.2.4 A-04. Ops giữ OU.	Chỉ quét leader có `Status = Active` trong `Pod_Leader_Registry`, đối chiếu qua email công việc. Ops giữ OU "Pod Leaders". Cron chỉ đọc lịch của OU "Pod Leaders", không đọc lịch của mentee.	✅ Đã chốt
A-13	Weekly Report khi tuần không có strike nào — vẫn gửi? Report do job nào gửi (V7 ghi endpoint strike "writes the weekly Slack report metrics")?	Vẫn gửi (0 vi phạm). Một job hằng tuần riêng tổng hợp từ bảng strike + số buổi multi-party mà Auditor đã đếm.	Vẫn gửi, ghi 0 vi phạm. Báo cáo do một job hằng tuần riêng gửi lúc Thứ Sáu 5:00 PM US/Central.	✅ Đã chốt
A-14	Lưu transcript notetaker `[POD-DISP-14]`: ở Fireflies, Sotatek kéo về S3/DB, hay Ops tự quản?	Nằm trong Fireflies workspace của Stack Trading; Sotatek không build.	Ngoài phạm vi — transcript nằm trong workspace Fireflies của Stack Trading, Sotatek không build.	✅ Đã chốt
A-15	Sự kiện đã huỷ (leader huỷ buổi họp nhưng sự kiện vẫn được Google trả về ở trạng thái đã huỷ) có bị xét strike hoặc dùng để đóng `Induction_Due` không?	Không xét — chỉ đọc sự kiện chưa huỷ. Sự kiện bị huỷ sau khi đã đóng `Induction_Due` theo A-11.	Không xét — chỉ đọc sự kiện chưa huỷ.	✅ Đã chốt
A-16	Đóng `Induction_Due` của mentee pod khác. Cron đóng `Induction_Due` khi thấy email mentee + notetaker trên lịch leader — nếu mentee đó thuộc pod của leader khác (VD đã đổi pod, hoặc được mời họp chung) thì có đóng không?	Chỉ đóng khi mentee đang thuộc pod của chính leader sở hữu lịch (`Users.pod_leader_id` = `Leader_ID`).	Không lọc theo pod. Cron chỉ kiểm tra sự kiện có mời email mentee + `notetaker@stacktrading.com`, không kiểm tra người sở hữu lịch có phải leader của mentee hay không.	✅ Đã chốt
A-17	Cron Auditor lỗi toàn bộ (JSON key sai / hết hạn, bị thu hồi Domain-Wide Delegation, không đọc được OU) → không ai biết hôm đó không có strike và không đóng `Induction_Due`. Có báo Slack không, kênh nào?	Gửi 1 cảnh báo vào `#ops-dev` (CR-15.2) mỗi lượt chạy lỗi; không gửi cho leader.		⏳ Chờ BA 🟡
A-18	Báo cáo tuần đếm theo mốc nào. Cron có thể thấy sự kiện của tuần sau (họp đặt trước) → đếm theo thời điểm diễn ra sự kiện hay thời điểm cron ghi nhận/ghi strike? Tuần đổi giờ mùa hè/mùa đông, Thứ Sáu 5:00 PM US/Central → Thứ Sáu tuần sau chỉ là 167 hoặc 169 giờ, không phải 168.	Đếm theo thời điểm cron ghi nhận (mỗi cuộc họp / strike chỉ thuộc 1 báo cáo). Cửa sổ = từ mốc cuối của báo cáo trước tới 5:00:00 PM US/Central Thứ Sáu này (tuần đổi giờ là 167/169 giờ — không bỏ sót, không đếm trùng).	Cửa sổ báo cáo luôn tính từ 5:00 PM Thứ Sáu đến 5:00 PM Thứ Sáu theo giờ US/Central, không tính cứng 168 giờ. Đếm theo thời điểm diễn ra cuộc họp (VD đặt ở Tuần 1, họp Thứ Tư Tuần 2 → báo cáo Tuần 2). Cuộc họp chưa kịp được Auditor xét lúc gửi báo cáo → tính vào báo cáo tuần kế tiếp. Khách trả lời 2026-10-22.	✅ Đã chốt
A-19	Nội dung tin báo cáo tuần trên Slack. Bảng RACI ghi template Weekly Strike Report "khách đã gửi", nhưng QnA khách (T-01…T-13) không có mẫu này.	Khách gửi copy; nếu chưa có, Sotatek dựng tin tiếng Anh gồm 3 mục (tổng cuộc họp nhiều người, tổng vi phạm, danh sách `Leader_Name` + `Leader_ID`) để khách duyệt.	Weekly Risk Ops Metrics Report 📊1. Meeting & Violation Metrics:• Total Multi-Party Meetings: [Insert Total Meetings]• Total Missing Notetaker Violations: [Insert Total Violations]2. Strike List (Pod Leaders):(Note: Pod Leaders listed below have received a strike for missing notetakers)• [Leader_Name_1] \| ID: [Leader_ID_1]• [Leader_Name_2] \| ID: [Leader_ID_2]• [Leader_Name_3] \| ID: [Leader_ID_3]	✅ Đã chốt
A-20	Xác định đúng mentee để đóng `Induction_Due` (`POD-SLA-07`, `POD-SLA-10`, `POD-DISP-02`). Cron đóng `Induction_Due` khi thấy cuộc họp mời email mentee + notetaker, nhưng chưa rõ: (1) Master Calendar link là link chung của leader hay link riêng cho từng mentee, có tự điền sẵn email đăng ký của mentee đó không? Nếu link chung, leader phải tự gõ email mentee. (2) Cron khớp bằng email nào? Leader mời email khác email đăng ký (VD Gmail cá nhân của mentee) thì có đóng không? (3) Leader có nhiều `Induction_Due` đang mở (VD 5 mentee mới) nhưng chỉ tạo 1 cuộc họp thì đóng hạn nào?	(1) Mỗi email gửi leader có link riêng cho mentee đó, tự điền sẵn email đăng ký của mentee + `notetaker@stacktrading.com`. (2) Chỉ khớp email đăng ký trong `Users`. Mời email khác → không đóng, leader vẫn nhận email nhắc hạn / breach. (3) Chỉ đóng hạn của mentee có email đăng ký trong cuộc họp; các hạn còn lại vẫn mở. Cuộc họp chỉ có leader + notetaker (không có email mentee) không đóng hạn nào.		⏳ Chờ khách 🔴
Impact analysis

Dữ liệu	Dùng bởi
`SLA_Deadlines` — đóng `Induction_Due`	SLA cron dừng nhắc leader (UC_8.2.4)
Bảng strike	Weekly Slack Report (UC này) · Ops review tay

4. [PATTERN] Rule candidate cho common_rules.md

ID	Câu hỏi	Giả định (BA/QC đề xuất)	BA chốt (ưu tiên cao nhất)	Trạng thái
P-03	`[PATTERN]` "Email cho leader chỉ gửi vào `@stacktrading.com`" áp cho Flow 10.1B, 10.2 (kể cả CC), 10.3.	Viết 1 lần thành BR trong UC_8.2.3; UC_8.2.4, UC_8.2.5 chỉ Ref. Không cần common rule (chỉ trong Pod System).	Viết 1 lần thành BR trong UC_8.2.3; UC_8.2.4, UC_8.2.5 chỉ Ref. Không đưa vào common_rules.	✅ Đã chốt

5. BLOCKED — chờ khách, loại khỏi SRS

QnA ID	Nội dung	Ảnh hưởng UC
—	Không còn mục BLOCKED. `POD-DISP-14` (lưu transcript) chốt ngoài phạm vi — A-14	—

6. Việc nội bộ phát sinh

#	Việc	Owner
1	Đưa T-04 vào SES email sheet	BA
2	Xin Adam: account `notetaker@`, Service Account DWD + JSON key	BA / Tech lead
3	Gửi khách: A-03, A-04, A-05, A-08, A-09, A-18	BA

Tổng kết trạng thái

Đã chốt: Q-01 → Q-12, O-01 → O-03, A-01, A-02, A-06, A-07, A-10 → A-16, A-19, P-03.
Chờ BA: A-17.
Chờ khách: A-20.
Đã chốt 2026-10-22 (khách): A-03, A-04, A-05, A-08, A-09, A-18.

QnA Init Docs — UC_8.2.3 (Flow 10.1B - AI Plan Dispatch + Calendar Compliance)

On this page