UC 8.2.7

---

UC_8.2.7 — Flow 10.5: Daily Pod Engagement AI Audit

🇻🇳 Section này viết bằng tiếng Việt để BA review. Mọi ID, anchor, tên field/API và text hiển thị cho user giữ nguyên tiếng Anh.

1. Overview

2. Trigger

• Cron Job task Process Daily Pod Metrics chạy lúc 11:59 PM giờ US/Central, từ Thứ Hai đến Thứ Sáu. Đây là tác vụ nội bộ của Middleware, tự chạy theo lịch, không do ai gọi.
• Giờ chạy tự đổi theo giờ mùa đông (CST) và giờ mùa hè (CDT). VD: mùa đông và mùa hè cron đều chạy lúc 11:59 PM theo đồng hồ ở Chicago.
• Cron không chạy Thứ Bảy và Chủ Nhật. Ngày lễ giữa tuần có chạy hay không chưa chốt (§8 #3).

3. Pre-conditions

• Pod Leader có ít nhất 1 mentee.
• Kênh pod của leader đang hoạt động.

4. Post-conditions

• Mỗi pod được audit có thêm 1 kết quả (PASS hoặc FAIL) trong engagement_metrics của leader, kèm tổng số tin nhắn trong kênh và số tin nhắn của leader.
• Pod bị bỏ qua thì không có kết quả cho ngày đó: pod không đủ điều kiện audit, bot không đọc được kênh, gửi webhook lỗi, Zap lỗi, hoặc AI trả kết quả sai định dạng (§6).
• Hệ thống không bật cảnh báo, không áp ngưỡng và không phạt leader dựa trên kết quả.

5. Basic Flow

5.1 Chọn pod cần audit (RFQ V7 — Cron bước 1)

Stage 1 — Lọc leader

1. Cron Job task Process Daily Pod Metrics chạy trên Middleware (bot Node.js). RFQ V7 liệt kê tác vụ này trong bảng endpoint với input pod_id, leader_id, nhưng đó thực chất là các trường cron gửi đi trong webhook ở bước 14, không phải dữ liệu bên ngoài gửi vào.

2. Lúc bắt đầu chạy, Middleware ghi ngày hôm nay theo giờ US/Central vào audit_date. Đây là ngày của khung chat được audit, và mọi kết quả của lượt chạy dùng chung ngày này. VD: cron chạy lúc 11:59 PM Thứ Ba thì audit_date là Thứ Ba.

3. Cron đọc 2 bảng rồi xét lần lượt từng leader:

   • Pod_Leader_Registry: Leader_ID, Current_Count (số mentee hiện có) và kênh pod.
   • Users: discord_user_id của leader và trạng thái DTO hoặc Hiatus.

4. Leader chỉ được audit khi thoả cả 3 điều kiện:

   • Pod có ít nhất 1 mentee (Current_Count lớn hơn 0).
   • Kênh pod còn tồn tại và chưa bị archive (lưu trữ, không dùng nữa).
   • Leader không bị khoá do đang nghỉ DTO hoặc Hiatus đã duyệt qua Flow 13. DTO là nghỉ phép có lương cho leader W-2; Hiatus là tạm nghỉ cho leader International. Trạng thái này nằm ở cột nào chưa chốt (§8 #4).

   Founding Mentor vẫn bị audit như mọi leader khác, khác với Drawdown Defense là nơi Founding Mentor được miễn. Leader không đủ điều kiện hoặc bị lỗi thì xem E_8.2.7.1, E_8.2.7.2.

5.2 Gom chat và đếm tin nhắn (RFQ V7 — Cron bước 2)

Stage 2 — Đọc kênh pod

5. Bot Discord của Middleware đọc tin nhắn trong kênh chữ của pod. Mỗi pod có kênh pod-[leader_name] do Create Pod Channel tạo, gồm 1 kênh chữ và 1 kênh thoại, cả hai đều riêng tư. Kênh thoại không được audit: leader trao đổi bằng giọng nói thì vẫn phải để lại tóm tắt hoặc tương tác bằng chữ trong kênh chữ thì mới có thể được PASS.
6. Bot chỉ lấy tin trong đúng 24 giờ, từ 23:59:00 hôm trước đến 23:59:00 hôm nay, giờ US/Central:
   • VD: lượt chạy Thứ Ba lấy tin từ 23:59:00 Thứ Hai đến 23:59:00 Thứ Ba. Tin gửi lúc 23:59:30 Thứ Ba thuộc khung của Thứ Tư.
   • Bot không lấy bù tin cũ cho đủ 50,000 ký tự. VD: chat Thứ Ba chỉ có 3,000 ký tự thì log gửi đi chỉ có 3,000 ký tự đó.
   • Thứ Bảy và Chủ Nhật không có lượt chạy, nên tin gửi trong cuối tuần bị bỏ hẳn. Lượt Thứ Hai chỉ xét tin từ 23:59:00 Chủ Nhật đến 23:59:00 Thứ Hai. VD: tin gửi lúc 10:00 Thứ Bảy không thuộc lượt nào.
7. Bot bỏ tin do bot gửi (author.bot == true, VD tin chào mừng welcome ping), không tính vào 2 bộ đếm và không đưa vào raw_chat_log.
8. Trader đã đồng ý cho hệ thống đọc chat khi ký Master Terms of Service lúc onboarding (Flow 3), nên hệ thống không gửi thông báo trong kênh và không có màn hình giải thích việc này. Bot không đọc được kênh thì xem E_8.2.7.3.

Stage 3 — Đếm tin nhắn

9. Cron đếm trên toàn bộ tin trong khung thời gian, trước khi cắt log ở bước 13, nên số đếm không bị ảnh hưởng khi log bị cắt:
   • total_channel_messages: tổng số tin nhắn trong kênh.
   • total_leader_messages: số tin do leader gửi, tức tin có tác giả là discord_user_id của leader. Leader chưa liên kết Discord thì xem E_8.2.7.4.

5.3 Kết luận ngay hoặc gửi sang Zapier (RFQ V7 — Cron bước 3)

Stage 4 — Kết luận theo số đếm

10. Cron dựa vào 2 số đếm để quyết định:
    • total_channel_messages bằng 0, tức là không ai nhắn gì: kết luận PASS. Leader không bị phạt khi mentee im lặng.
    • total_channel_messages lớn hơn 0 và total_leader_messages bằng 0, tức là có người nhắn nhưng leader không nhắn: kết luận FAIL. VD: mentee gửi 12 tin, leader gửi 0 tin thì FAIL.
    • Còn lại, tức là có người nhắn và leader cũng có nhắn: gửi sang Zapier để AI đánh giá. VD: kênh có 20 tin, leader gửi 3 tin thì gửi sang Zapier.
11. Với 2 trường hợp kết luận ngay, cron không gọi AI và không gửi gì sang Zapier, mà tự ghi 1 phần tử vào engagement_metrics của leader, cùng cách ghi như bước 21 (BR_8.2.7.2). Theo RFQ V7, mọi pod đều được gửi sang Zapier; việc Middleware tự ghi cho 2 trường hợp này là giả định chưa chốt (§8 #1). Ghi lỗi thì xem E_8.2.7.5.

Stage 5 — Ghép log và gửi webhook

12. Cron ghép các tin thành raw_chat_log, là đoạn chat dạng chữ cho AI đọc:
    • Dòng đầu luôn là Pod Leader: <tên hiển thị của leader>, để Gemini phân biệt tin của leader với tin của mentee.
    • Các dòng sau xếp theo thời gian, tin cũ ở trên. Mỗi tin là 1 dòng dạng [Time] [User]: Message, Time theo giờ US/Central.
    • [User] là tên hiển thị trên Discord của người gửi; không đặt tên hiển thị thì dùng username; không dùng discord_user_id. VD: [09:15] [Minh Tran]: Hôm nay em vào lệnh EURUSD.
13. raw_chat_log dài hơn 50,000 ký tự thì cron bỏ phần chat cũ ở đầu, chỉ giữ 50,000 ký tự mới nhất:
    • Chỗ cắt rơi vào giữa một dòng thì bỏ luôn dòng đó, nên log có thể ngắn hơn 50,000 ký tự một chút. VD: log dài 62,000 ký tự thì cron bỏ khoảng 12,000 ký tự đầu, cộng thêm phần còn lại của dòng bị cắt dở.
    • Dòng Pod Leader: … luôn được giữ ở đầu.
    • Cron không chia log thành nhiều phần để gửi nhiều lần.
14. Cron gửi webhook tới Catch Hook của Zap Flow 10.5, mỗi pod mỗi ngày 1 webhook. Payload gồm 6 trường: 5 trường theo RFQ V7 và trường audit_date. Chi tiết xem BR_8.2.7.3. Gửi xong, cron chuyển sang pod kế tiếp, không chờ kết quả AI. Gửi lỗi hoặc chạy lại trong ngày thì xem E_8.2.7.6, E_8.2.7.7.

5.4 AI đánh giá (Flow 10.5 — Trigger, Action 1, Action 2)

Stage 6 — Zapier gọi Gemini

15. Trigger: Zap Flow 10.5 chạy khi Catch Hook nhận webhook do cron gửi ở bước 14. Catch Hook là địa chỉ nhận webhook do Zapier cấp. Chỉ pod có người nhắn và leader cũng có nhắn mới tới bước này.
16. Action 1 (Parse): Zapier tách các trường trong webhook, gồm 5 trường RFQ V7 và audit_date (BR_8.2.7.3).
17. Action 2 (AI Audit): Zapier gửi raw_chat_log cho Gemini 1.5 Flash kèm câu lệnh nguyên văn của khách (BR_8.2.7.1). Câu lệnh yêu cầu Gemini trả đúng 1 từ PASS hoặc FAIL. Sotatek không làm thêm bước thử lại riêng khi AI trả kết quả sai định dạng. Gemini không phản hồi thì xem E_8.2.7.8.

5.5 Ghi kết quả (Flow 10.5 — Action 3)

Stage 7 — Middleware ghi engagement_metrics

18. Action 3: Zapier chuyển kết quả cho Middleware để Middleware ghi database. Zapier không ghi thẳng vào PostgreSQL, vì Pod_Leader_Registry là bảng do Middleware quản lý. Việc Middleware mở endpoint nhận kết quả là giả định, vì chưa chốt bên nào ghi database (§8 #1). Nguồn không đặt tên endpoint này; đường dẫn do Sotatek chốt trong OpenAPI spec.

    Input field	Value
    leader_id	Lấy từ webhook. Bắt buộc
    pod_id	Lấy từ webhook. Bắt buộc. Dùng để đối chiếu và ghi log
    audit_date	Lấy từ webhook. Bắt buộc
    Kết quả AI	Kết quả Gemini trả ở bước 17, chuyển nguyên văn. Bắt buộc
    total_channel_messages	Lấy từ webhook. Bắt buộc. Số nguyên lớn hơn hoặc bằng 0
    total_leader_messages	Lấy từ webhook. Bắt buộc. Số nguyên lớn hơn hoặc bằng 0

    Input sai thì xem E_8.2.7.9.

19. Middleware tìm leader theo leader_id. Không tìm thấy thì xem E_8.2.7.10.

20. Middleware đọc kết quả AI: đổi toàn bộ sang chữ hoa rồi tìm nguyên từ PASS hoặc FAIL. Từ dính thêm chữ khác không được tính, VD "PASSED" hay "FAILURE".

    • Chỉ có từ PASS thì result là PASS. VD: AI trả The leader engaged moderately, so PASS thì kết quả là PASS.
    • Chỉ có từ FAIL thì result là FAIL.
    • Không có từ nào, hoặc có cả hai, thì xem E_8.2.7.11.

21. Middleware khoá dòng của leader trong Pod_Leader_Registry, để 2 lần ghi cùng lúc không làm mất phần tử của nhau. Middleware lấy audit_date làm date của phần tử, nên kết quả về sau 00:00 vẫn ghi đúng ngày của khung chat. VD: lượt chạy lúc 23:59 Thứ Ba, kết quả về lúc 00:05 Thứ Tư thì date vẫn là Thứ Ba. Sau đó:

    • Đã có phần tử cùng date (cron chạy lại trong ngày, hoặc cùng kết quả được gửi 2 lần) thì ghi đè, không thêm phần tử trùng.
    • Chưa có thì thêm phần tử mới { date, result, total_messages, leader_messages }, với total_messages lấy từ total_channel_messages và leader_messages lấy từ total_leader_messages. Cách lưu xem BR_8.2.7.2.

22. Ghi xong, Middleware trả 200 OK. Lỗi hệ thống thì xem E_8.2.7.12.

23. Sau khi ghi kết quả, hệ thống không làm gì thêm: không áp ngưỡng, không gửi cảnh báo, không phạt leader. Operations tự xem xét kết quả bên ngoài hệ thống. Kết quả FAIL không ảnh hưởng tiền carry của leader (Flow 17, UC_8.2.12).

6. Exceptional Flows

7. Business Rules

7.1 BR_8.2.7.1 — AI đánh giá

Câu lệnh cho AI (nguyên văn):

Review this daily chat log from a trading desk. Did the mentor (Leader) engage with the team, ask probing questions regarding execution, or answer technical inquiries? Return exactly one word: 'PASS' or 'FAIL'.

7.2 BR_8.2.7.3 — Payload webhook gửi Zapier

Cron gửi webhook ở bước 14 tới Catch Hook của Zap Flow 10.5, mỗi pod mỗi ngày 1 webhook (Ref: RFQ_ Stack Trading Prop Tech V7.pdf §Process Daily Pod Metrics; Zapier Integration V7.pdf §Flow 10.5 Action 1).

8. Open Items

Chi tiết: QnA_init_docs.md.

9. Phân chia trách nhiệm

---

Changelog