UC 8.2.2
Flow 10.1A - Trading Plan Ingestion: mentee nộp Trading Plan trên Typeform → Middleware ghi SLA, tạo PDF lưu S3 và cho AI phân tích plan
| Field | Value |
|---|---|
| BA in Charge | Anh Hoang |
| Date Created | 2026-10-12 |
| Version | v1.14 |
| Document References | Zapier Integration V7.pdf (§Flow 10.1A, §Flow 10.1B Trigger) · RFQ_ Stack Trading Prop Tech V7.pdf (§Analyze Trading Plan, §4.4 #11) · QnA from clients — STAGE 6: Pod System Flow 10 → 11 (POD-PLAN-03/05/06/08/09/10/12/15/16, POD-DISP-01/04/05/12) · QnA_init_docs.md (A-01, A-03…A-06, A-13, A-14) · CHR-127 (Typeform embedding standard) · Common Rules CR-08, CR-15.2, CR-18 |
UC_8.2.2 — Flow 10.1A: Trading Plan Ingestion
🇻🇳 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
| Field | Content |
|---|---|
| ID | UC_8.2.2 |
| Use Case | Flow 10.1A: Trading Plan Ingestion |
| Description | UC này mô tả việc mentee mới vào pod nộp Trading Plan, là bản kế hoạch giao dịch bắt buộc. Hệ thống ghi nhận mentee đã nộp, lưu bản kế hoạch thành file PDF và cho AI phân tích, để chuẩn bị gửi cho Pod Leader. |
| Phạm vi | UC này đi từ lúc mentee nộp Trading Plan tới lúc Middleware gửi webhook TRADING_PLAN_ANALYZED. Không gồm: email gửi Pod Leader (UC_8.2.3), cách lưu và nhắc hạn SLA (UC_8.2.4). |
| Zapier Flow | Flow 10.1A trong Zapier Integration V7.pdf (Trigger, Action 1 đến Action 5) do Middleware làm thay, không có Zap. Zapier chỉ nhận webhook ở Flow 10.1B (UC_8.2.3). |
| Zapier Table | — |
| API | API Analyze Trading Plan (POST /analyze-trading-plan) · Webhook TRADING_PLAN_ANALYZED (Middleware gửi sang Zapier) |
| Cron Job task | Không có |
| 3rd Party | Typeform, Google Workspace (mẫu Google Doc, xuất PDF), AWS S3, Google Gemini 3.1 Pro, Slack |
2. Trigger
- Mentee nộp form Trading Plan trên Typeform.
3. Pre-conditions
- Mentee đã đăng nhập và mở form qua trang wrapper trên
stacktrading.com. Trang wrapper là trang của Stack Trading có nhúng form Typeform bên trong, phải đăng nhập mới xem được. - Mentee nhận link trang wrapper trong email
Pod_Assignment_Confirmation, trong tin chào ở kênh pod, hoặc trong email nhắc hạn SLA (Ref: UC_8.2.1). Link không chứauser_id.
4. Post-conditions
Khi mentee đã có Pod Leader:
- Bảng
SLA_Deadlinesđã được cập nhật: hạn nộpPlan_Duecủa mentee đã đóng, hạn inductionInduction_Duecủa leader đã mở. - File PDF Trading Plan đã nằm trên S3 và link file đã được lưu trong database.
- Middleware đã gửi webhook
TRADING_PLAN_ANALYZEDsang Zapier.
Khi mentee chưa có Pod Leader (đang ở waitlist):
- File PDF và link file vẫn được lưu.
- Middleware không ghi SLA, không cho AI phân tích và không gửi webhook (E_8.2.2.5).
5. Basic Flow
5.1 Mentee nộp form (Flow 10.1A — Trigger)
Stage 1 — Nộp form
- Mentee mở trang wrapper. Trang wrapper lấy
user_idtừ phiên đăng nhập và đưa vào form cùngmentor_email, dưới dạng hidden field. Hidden field là trường ẩn: mentee không nhìn thấy, nhưng giá trị được gửi kèm kết quả form để hệ thống biết ai đã nộp. Chi tiết 2 hidden field xem BR_8.2.2.1. - Mentee trả lời các câu hỏi, tải lên tối đa 3 ảnh chart, tick câu đồng ý ở cuối form, rồi bấm nộp. Nội dung form xem BR_8.2.2.1.
- Nộp xong thì câu trả lời bị khoá, mentee không sửa được.
- Typeform gửi kết quả form sang Middleware. Mỗi mentee chỉ nộp Trading Plan 1 lần, xem BR_8.2.2.4.
5.2 Ghi hạn SLA (Flow 10.1A — Action 5)
Stage 2 — Ghi nhận mentee đã nộp
- Middleware ghi SLA ngay khi nhận bài, trước khi tạo PDF. Nhờ vậy, nếu bước tạo PDF hoặc AI ở phía sau bị lỗi thì mentee vẫn được tính là đã nộp.
- Middleware đóng
Plan_Duecủa mentee, tức là đánh dấu mentee đã nộp. Từ đây cron SLA (UC_8.2.4) không nhắc mentee nữa. Mentee nộp muộn thì xem E_8.2.2.4. - Middleware mở
Induction_Duecho Pod Leader. Đây là hạn để leader họp induction với mentee, bằng 5 ngày lịch tính từ lúc mentee nộp. VD: mentee nộp lúc 09:00 ngày 10 thì hạn là 09:00 ngày 15. Nếu lần gán pod hiện tại đã cóInduction_Duethì xem E_8.2.2.6.
5.3 Tạo file PDF (Flow 10.1A — Action 1 đến Action 3)
Stage 3 — Tạo và lưu PDF
- Formatter (Action 1): Middleware lấy các câu trả lời dạng chữ và link ảnh chart của Typeform. Middleware tải ảnh về ngay, vì link ảnh của Typeform chỉ dùng được trong thời gian ngắn.
- Docs (Action 2): Middleware điền các câu trả lời vào mẫu Google Doc. Ảnh chart hiện ngay trong tài liệu. Mẫu Google Doc do Stack Trading tạo và giữ trên Drive công ty (§9).
- Export (Action 3): Middleware xuất tài liệu ra file PDF, lưu lên S3, rồi lưu link file (
document_s3_url) vào database để UC_8.2.3 và UC_8.2.5 dùng lại. Cách lưu PDF xem BR_8.2.2.2. - Nếu bất kỳ bước nào từ bước 8 đến bước 10 bị lỗi thì xem E_8.2.2.7.
5.4 AI phân tích và gửi webhook (Flow 10.1A — Action 4)
Stage 4 — Gọi API phân tích
-
Middleware gọi
API Analyze Trading Plan(POST /analyze-trading-plan):Input field Value user_idUUID của mentee document_s3_urlLink file PDF vừa lưu ở bước 10 Chi tiết API xem BR_8.2.2.6. Input sai hoặc gọi trùng xem E_8.2.2.8, E_8.2.2.9.
-
API tra email của Pod Leader hiện tại trong database theo
user_id. Nếu mentee chưa có Pod Leader thì xem E_8.2.2.5. -
API trả
200 OKngay, rồi chạy nền bước 15 và bước 16.
Stage 5 — Chạy nền
- Middleware tải file PDF và ảnh từ S3, gửi cho Gemini 3.1 Pro (bật Extended Thinking) cùng câu lệnh phân tích. Mỗi lần gọi chờ tối đa 120 giây. Cấu hình AI và câu lệnh xem BR_8.2.2.3. Gemini lỗi hoặc trả kết quả không dùng được thì xem E_8.2.2.10, E_8.2.2.11.
- Middleware gửi webhook
TRADING_PLAN_ANALYZEDtới Zapier Catch URL của Flow 10.1B. Webhook có email leader, link PDF, kết quả phân tích của AI, tên leader, tên mentee và Master Calendar link của leader. Payload xem BR_8.2.2.6. Zapier dùng webhook này để email cho Pod Leader (UC_8.2.3). Gửi webhook lỗi thì xem E_8.2.2.12. - Không ai duyệt kết quả AI trước khi gửi. Mentee không bao giờ nhận phần phân tích của AI (BR_8.2.2.3).
6. Exceptional Flows
| Exception ID | Exception | Condition | System Handling / Fallback |
|---|---|---|---|
| E_8.2.2.1 | Mentee mở lại form đã nộp (Ref: BR_8.2.2.4) | Mentee đã nộp Trading Plan rồi mở lại link form. | Trang wrapper không hiện form mà hiện dòng chữ You have already submitted this. |
| E_8.2.2.2 | Lần nộp thứ 2 lọt qua trang wrapper (Ref: BR_8.2.2.4, CR-18) | Middleware nhận kết quả form của mentee đã nộp trước đó. | Middleware trả 200 OK và bỏ qua, không lưu gì. |
| E_8.2.2.3 | Người khác bấm link form | Một người khác trong kênh pod bấm link form Trading Plan. | Form mở theo phiên đăng nhập của chính người đó, nên họ không nộp thay mentee được. |
| E_8.2.2.4 | Nộp muộn sau 72 giờ | Mentee nộp sau khi hạn Plan_Due đã qua. | Bài vẫn được nhận và xử lý như bình thường. Plan_Due vẫn được đóng. VD: hạn đã qua 2 ngày mà mentee mới nộp thì bài vẫn được nhận, và leader vẫn nhận PDF. |
| E_8.2.2.5 | Mentee chưa có Pod Leader | Mentee nộp lúc đang ở waitlist (pod_leader_id rỗng). | Middleware không ghi SLA. Middleware vẫn tạo PDF và lưu lên S3. API Analyze Trading Plan trả 200 OK nhưng không gọi AI và không gửi webhook. Khi mentee được gán pod, Middleware dùng lại PDF này để chạy AI và gửi webhook cho leader mới, không mở Plan_Due, và mở Induction_Due bằng 5 ngày lịch tính từ lúc gán pod (Ref: UC_8.2.1). VD: mentee được gán pod lúc 14:00 ngày 20 thì Induction_Due là 14:00 ngày 25. |
| E_8.2.2.6 | Đã có Induction_Due | Lần gán pod hiện tại đã có Induction_Due, dù hạn đang mở hay đã đóng. | Middleware không ghi đè và không mở lại Induction_Due. |
| E_8.2.2.7 | Lỗi khi tạo PDF (Ref: BR_8.2.2.5) | Lỗi ở bước 8, 9 hoặc 10: tải ảnh, tạo tài liệu, xuất PDF, lưu S3 hoặc lưu link. | Middleware ghi log, gửi 1 Slack alert vào #ops-general và không thử lại. Middleware dừng xử lý lần nộp này: không gọi AI, không gửi webhook. Hạn SLA đã ghi ở bước 6 và 7 vẫn giữ nguyên, mentee vẫn được tính là đã nộp. Operations nhận alert và tự gửi plan cho leader. |
| E_8.2.2.8 | Input không hợp lệ | Gọi API Analyze Trading Plan thiếu user_id hoặc document_s3_url. | API trả 400 và không xử lý. |
| E_8.2.2.9 | Gọi trùng (Ref: CR-18) | Gọi API Analyze Trading Plan với document_s3_url đã nhận trước đó. | API trả 200 OK và bỏ qua, không gọi AI và không gửi webhook lần nữa. |
| E_8.2.2.10 | Gemini lỗi hoặc quá thời gian (Ref: BR_8.2.2.3) | Gemini báo lỗi, hoặc quá 120 giây chưa trả kết quả. | Middleware gọi lại tối đa 3 lần, chờ lần lượt 2 giây, 4 giây và 8 giây trước mỗi lần. Vẫn lỗi thì ai_analysis là câu AI analysis temporarily unavailable. và Middleware vẫn gửi webhook, để leader vẫn nhận PDF. |
| E_8.2.2.11 | AI trả rỗng hoặc lạc đề (Ref: BR_8.2.2.3) | Gemini trả về nội dung rỗng hoặc không liên quan tới plan. | Middleware vẫn gửi nguyên kết quả. Khi gửi email, Zapier thay kết quả này bằng câu AI analysis unavailable. Please review the attached plan directly. (UC_8.2.3). |
| E_8.2.2.12 | Gửi webhook lỗi (Ref: BR_8.2.2.5) | Zapier Catch URL không nhận được webhook TRADING_PLAN_ANALYZED. | Middleware ghi log, gửi 1 Slack alert vào #ops-general và không gửi lại. Việc lưu PDF và hạn SLA không bị huỷ; Induction_Due vẫn tính bình thường. Operations tự gửi plan cho leader. |
7. Business Rules
| BR_ID | Rule Description |
|---|---|
| BR_8.2.2.1 | Form Trading Plan: xem chi tiết tại §7.1. |
| BR_8.2.2.2 | Lưu file PDF: File PDF được lưu vĩnh viễn trên S3, không sửa, không xoá. Mở link không cần đăng nhập và link không hết hạn. Tên file là chuỗi ngẫu nhiên dài (VD .../3f2b9c1e-7a4d-4e8b-9c2f-1d6a5b8e0f47.pdf), nên người không được gửi link không dò ra được link của mentee khác.Mentee không có chỗ xem lại PDF trên Dashboard. Khi mentee đổi pod, leader cũ vẫn giữ email đã nhận, không thu hồi. |
| BR_8.2.2.3 | AI phân tích Trading Plan: xem chi tiết tại §7.2. |
| BR_8.2.2.4 | Nộp 1 lần, dùng lại khi đổi pod: Mỗi mentee chỉ nộp Trading Plan 1 lần duy nhất (E_8.2.2.1, E_8.2.2.2).Khi mentee sang pod mới, mentee không nộp lại mà hệ thống dùng lại Trading Plan đã nộp. Áp dụng khi mentee đổi pod qua POST /admin-pod-reassignment, khi pod cũ bị rã rồi mentee được ghép lại, và khi mentee đi qua waitlist. Leader mới nhận PDF và có hạn Induction_Due khi mentee được gán pod (Ref: UC_8.2.1 §5.4). |
| BR_8.2.2.5 | Slack alert khi lỗi: Gửi vào #ops-general. Prod dùng kênh C0BR8LRC5MK, Test dùng kênh #test-ops-general (C0BR6UXRR8D) (Ref: CR-15.2). Mỗi lỗi gửi 1 alert, không thử lại.Lỗi khi tạo PDF (E_8.2.2.7): Trading Plan Ingestion Failed for User [user_id] at Step [step_name]: [error_message]. Trong đó [step_name] là tên Action bị lỗi: Formatter, Docs, Export hoặc Database. VD lưu S3 lỗi thì [step_name] là Export.Lỗi khi gửi webhook (E_8.2.2.12): Failed to dispatch TRADING_PLAN_ANALYZED for User [user_id] |
| BR_8.2.2.6 | API Analyze Trading Plan và webhook TRADING_PLAN_ANALYZED: xem chi tiết tại §7.3. |
7.1 BR_8.2.2.1 — Form Trading Plan
| Thành phần | Quy tắc |
|---|---|
| Nơi đặt form | Form nằm trên Typeform và là form riêng, tách khỏi form Style (UC_8.2.1). Trên Dashboard không có màn hình nào cho form này. Kết quả form được gửi thẳng tới Middleware, không đi qua Zapier. |
| Câu hỏi | Stack Trading cung cấp nội dung câu hỏi (xem bên dưới). Sotatek dựng các câu hỏi này trong Typeform. |
| Hidden field | Trang wrapper đưa 2 trường ẩn vào form:- user_id: bắt buộc, lấy từ phiên đăng nhập, để hệ thống biết ai là người nộp.- mentor_email: email @stacktrading.com của Pod Leader tại lúc mentee mở form.Middleware luôn tra email của leader hiện tại trong database theo user_id. Vì vậy, nếu mentee đã đổi pod mà mentor_email vẫn là email của leader cũ thì người nhận email vẫn đúng. |
| Ảnh chart | Ảnh chụp chart hoặc ảnh setup phân tích kỹ thuật của mentee, không phải ảnh đại diện. Chỉ nhận file .png, .jpg, .jpeg. Tối đa 3 ảnh, mỗi ảnh không quá 5MB. Giới hạn này được cài trong Typeform, để file PDF luôn nhỏ hơn 25MB và đính kèm được vào email. VD: 3 ảnh, mỗi ảnh 5MB, tổng cộng 15MB, vẫn dưới mức 25MB. |
| Câu đồng ý (bắt buộc) | Câu hỏi loại "Legal / Consent", đặt ở cuối form, ngay trước nút Submit. Mentee chưa tick thì không nộp được form. |
| Hạn nộp | Link vẫn nhận bài sau 72 giờ. Mentee nộp muộn không bị khoá role, không bị huỷ pod và không bị đẩy khỏi kênh, chỉ nhận email nhắc hạn và email breach theo UC_8.2.4 (E_8.2.2.4). |
Nội dung form (Form 3: The Trading Plan). Giữ nguyên văn tiếng Anh do khách cung cấp.
| Thành phần | Nội dung |
|---|---|
| Form Title | Your Trading Blueprint |
| Welcome Screen | Welcome to the Pod. Institutional capital demands institutional discipline. Amateurs trade on intuition, professionals trade on executable frameworks. Detail your comprehensive strategy, risk models, and daily protocols below. Your Pod Leader will use this blueprint to audit your trades and hold you accountable. Vague plans will be rejected. |
| Ending Screen | Blueprint submitted and logged to the compliance ledger. Institutional discipline begins now. Your mentor will review this risk model prior to your induction sync. Stick to the plan. |
Mỗi Section mở đầu bằng 1 Statement Screen mang tên của Section đó. Statement Screen là màn hình giới thiệu, không có câu hỏi.
| # | Section | Loại | Câu hỏi | Validation |
|---|---|---|---|---|
| Q1 | 1. Market Context & Pre-Session Planning | Multiple Choice | What is your primary execution timeframe?Options: Intraday Scalp (Seconds to Minutes), Intraday Trend Following (Minutes to Hours), Swing Trading (Multi-day), Macro / Position (Weeks) | — |
| Q2 | 1 | Long Text | Detail your daily pre-market preparation routine. How do you track macroeconomic catalysts (red folder events), map your daily liquidity levels (such as overnight range, prior day high/low), and establish your directional bias before the bell? | Required |
| Q3 | 1 | Short Text | What specific conditions dictate that you sit on your hands and DO NOT trade? (such as FOMC days, choppy VIX, poor sleep). | Required |
| Q4 | 2. The Statistical Edge | Multiple Choice | What is the core classification of your strategy?Options: Trend Following (Momentum/Breakouts), Mean Reversion (Fading/Contrarian), Volatility Expansion (News/Event Driven), Liquidity / Order Flow / DOM | — |
| Q5 | 2 | Long Text | Define your core statistical edge in a few sentences. Why does your setup make money over a 100-trade sample size? What gives you confidence in this edge (backtesting vs. forward testing), and who is the counterparty losing to you on the other side of this trade? Please write at least 150 characters | Required, tối thiểu 150 ký tự |
| Q6 | 2 | Long Text | Detail the mechanical criteria required to enter your absolute 'A+ Setup'. What specific confluence of price action, indicators, or volume MUST be present before you click buy/sell? Take the guesswork out of it. | Required |
| Q7 | 3. Trade Management & Risk Modeling | Multiple Choice | How do you manage position sizing on entry?Options: Fixed Fractional (such as, 1% risk per trade), Volatility-Adjusted (ATR based), Kelly Criterion, Tiered / Scaling In (example 50% at level, 50% on confirmation) | — |
| Q8 | 3 | Long Text | Invalidation: Where is your stop-loss placed upon entry? Is it a structural stop based on support/resistance, a volatility stop, or a time-based stop? Where is the trade proven technically wrong? | Required |
| Q9 | 3 | Long Text | Take-Profit & Trailing: How do you manage winning trades? Do you use fixed R:R targets, scale out at partials (e.g. take 50% off at 2R), or mechanically trail your stop? If you are a trend follower, do you pyramid (add size) to your winners when a breakout is confirmed? | Required |
| Q10 | 4. Psychology & Post-Session Evaluation | Long Text | Circuit Breaker: Drawdowns are inevitable. What is your personal hard daily loss limit trigger (which should be tighter than the firm's limit)? What is your physical, mechanical routine to step away from the screens when you experience emotional 'tilt' or hit 3 consecutive losses? Please write at least a few sentences. | Required, tối thiểu 100 ký tự |
| Q11 | 4 | Long Text | Detail your post-session evaluation routine. How do you journal your trades, and what specific metrics (e.g. MFE, MAE, Win Rate) do you track to grade your adherence to this plan regardless of your daily P&L? | Required |
| Q12 | 5. The Visual Playbook | File Upload | Upload your Visual Playbook. Provide an annotated chart markup of your 'A+ Setup' clearly highlighting the Entry criteria, Invalidation level (Stop Loss), and Take-Profit logic. (Please upload image files only: .png, .jpg, or .jpeg) | Theo dòng "Ảnh chart" ở bảng trên |
| Q13 | 6. Legal & Data Consent | Legal / Consent | Câu đồng ý (bên dưới) | Required |
Nội dung câu đồng ý (Q13):
By submitting this Trading Plan, you acknowledge and consent to Stack Trading processing your submitted data, including text and chart images, using automated artificial intelligence (AI) systems. This data is analyzed to provide coaching feedback, will be shared with your assigned Pod Leader, and is stored securely for compliance and quality assurance purposes.
Checkbox: I consent to the data processing terms.
Trang wrapper khi mentee đã nộp
You have already submitted this
7.2 BR_8.2.2.3 — AI phân tích Trading Plan
| Thành phần | Quy tắc |
|---|---|
| Model | Gemini 3.1 Pro, bật chế độ Extended Thinking. |
| Dữ liệu gửi AI | File PDF Trading Plan (có kèm ảnh chart) tạo ở bước 10, và câu lệnh nguyên văn bên dưới. |
| Thời gian chờ | Mỗi lần gọi, Middleware chờ kết quả tối đa 120 giây. |
| Thử lại | Gemini báo lỗi hoặc quá 120 giây chưa trả kết quả thì Middleware gọi lại tối đa 3 lần, chờ lần lượt 2 giây, 4 giây và 8 giây trước mỗi lần. VD: lần gọi đầu lỗi thì chờ 2 giây rồi gọi lại lần 1; vẫn lỗi thì chờ 4 giây rồi gọi lại lần 2; vẫn lỗi thì chờ 8 giây rồi gọi lại lần 3. |
| Kết quả | AI trả về văn bản thường. Middleware dùng nguyên văn bản này làm ai_analysis trong webhook TRADING_PLAN_ANALYZED. |
| Hết lượt thử | ai_analysis là câu AI analysis temporarily unavailable. và Middleware vẫn gửi webhook, để leader vẫn nhận PDF và hạn SLA vẫn chạy đúng (E_8.2.2.10). |
| AI trả rỗng hoặc lạc đề | Middleware vẫn gửi nguyên kết quả, Zapier thay bằng câu thay thế khi gửi email (E_8.2.2.11). |
| Số lượt gọi | Mỗi lần nộp chỉ gọi Gemini đúng 1 lượt, đã tính cả các lần thử lại. Typeform gửi lại cùng một lần nộp thì Middleware bỏ qua, không gọi Gemini lần nữa (E_8.2.2.9). |
| Người duyệt | Không ai duyệt kết quả của AI trước khi gửi đi. |
| Người nhận | Chỉ Pod Leader nhận kết quả phân tích. Mentee không bao giờ nhận phần phân tích của AI. |
Câu lệnh cho AI (nguyên văn):
Analyze this trading plan. Identify structural strengths and potential risk management weaknesses. Do not dictate strategy; provide supportive, objective feedback a mentor can use to guide the trader. Conclude by explicitly reminding the mentor to encourage the trader to use the daily journaling dashboard.
7.3 BR_8.2.2.6 — API Analyze Trading Plan và webhook TRADING_PLAN_ANALYZED
API Analyze Trading Plan (POST /analyze-trading-plan) — Middleware gọi sau khi đã lưu PDF lên S3 (bước 12). Đường dẫn và định dạng chi tiết do Sotatek chốt trong OpenAPI spec của Middleware.
- Input:
user_id,document_s3_url. - Output: trả
200 OKngay, sau đó chạy nền: cho Gemini phân tích PDF và gửi webhookTRADING_PLAN_ANALYZED.
| Tình huống | Phản hồi | Xử lý |
|---|---|---|
Thiếu user_id hoặc document_s3_url | 400 | Không xử lý (E_8.2.2.8) |
document_s3_url đã nhận trước đó | 200 OK | Bỏ qua, không xử lý lại (E_8.2.2.9) |
Mentee chưa có Pod Leader (pod_leader_id rỗng) | 200 OK | Không gọi AI, không gửi webhook. PDF vẫn giữ trên S3 để dùng khi mentee được gán pod (E_8.2.2.5) |
| Hợp lệ | 200 OK | Chạy nền: Gemini phân tích, gửi webhook |
Webhook TRADING_PLAN_ANALYZED — API Analyze Trading Plan gửi ở phần chạy nền (bước 16), tới Zapier Catch URL của Flow 10.1B (UC_8.2.3). Catch URL là địa chỉ Zapier cấp để nhận dữ liệu.
- Gửi khi Gemini đã trả kết quả, hoặc Middleware đã thử lại hết lượt.
- Không gửi khi mentee chưa có Pod Leader.
- Mỗi lần nộp chỉ gửi đúng 1 webhook. Lần nộp thứ 2 của mentee, hoặc Typeform gửi lại cùng một lần nộp, thì Middleware không gửi webhook.
| Payload field | Kiểu | Ghi chú |
|---|---|---|
mentor_email | String | Email @stacktrading.com của Pod Leader, tra trong database theo user_id. Không bao giờ dùng email cá nhân của leader. |
pdf_url | String (URL) | Bằng document_s3_url, là link PDF lưu ở bước 10. |
ai_analysis | String | Kết quả của Gemini. Hết lượt thử thì là câu AI analysis temporarily unavailable. |
| Tên Pod Leader | String | Điền vào [Leader_Name] trong email gửi leader (UC_8.2.3). Tên trường do BE chốt trong OpenAPI spec. |
| Tên mentee | String | Điền vào [Mentee_Name] trong email gửi leader. Tên trường do BE chốt. |
| Master Calendar link của leader | String (URL) | Điền vào [calendar_link] trong email gửi leader. Khi gửi webhook, BE gọi API để tạo hoặc lấy link đặt lịch của leader, không lưu link này. Tên trường do BE chốt. |
3 trường đầu lấy theo RFQ_ Stack Trading Prop Tech V7.pdf §Analyze Trading Plan. 3 nội dung sau do Middleware tra sẵn, để Zapier có đủ thông tin soạn email cho leader mà không phải tự tra database.
8. Open Items
Không còn hạng mục mở. Chi tiết: QnA_init_docs.md.
9. Phân chia trách nhiệm
| Hạng mục | Sotatek build | Stack Trading Ops | Bên thứ 3 tự chạy |
|---|---|---|---|
| Bộ câu hỏi Trading Plan | — | ✅ Cung cấp | — |
| Dựng form Typeform (hidden field, giới hạn ảnh, câu đồng ý) và cấu hình gửi kết quả thẳng tới Middleware | ✅ | — | Typeform |
| Trang wrapper có đăng nhập cho form Trading Plan và chặn nộp lần 2 | ✅ | — | — |
| Slack alert lỗi phần chạy nền (tạo PDF, gửi webhook) | ✅ | ✅ Xử lý tay khi nhận alert (gửi plan cho leader) | — |
| Mẫu Google Doc trên Drive công ty | — | ✅ Tạo và giữ · ❓ cấp quyền cho Middleware đọc mẫu và tạo tài liệu | Google Workspace |
Middleware nhận kết quả form, ghi SLA, tạo PDF, lưu S3; API Analyze Trading Plan gọi Gemini, gửi webhook | ✅ | — | Google Workspace, AWS S3, Gemini |
| Câu lệnh cho AI | — | ✅ Cung cấp (V7) | — |
Changelog
| Date | Version | Updated item | Before | After | Notes |
|---|---|---|---|---|---|
| 2026-10-12 | v1 | Initial document | — | — | Bản tiếng Việt để BA re-check trước khi chuyển tiếng Anh. Viết lại từ đầu theo template UC_8.1.1 (bản 2026-10-10 đã xoá). Nguồn chính: QnA POD-PLAN-01…16, POD-JOIN-02/03, POD-DISP-04/05/12, POD-BRIEF-13, POD-SLA-03. Spec V7 bị QnA thay thế: Action 4 truyền user_id thay mentor_email (POD-PLAN-16); Gemini 1.5 Pro → 3.1 Pro Extended Thinking, timeout 120s, 3 lần thử lại (POD-DISP-05); SLA_Deadlines là bảng PostgreSQL (POD-SLA-03). |
| 2026-10-12 | v1 | BR_8.2.2.5 — kênh nhận "Zap Error" | "Operations Slack channel" (khách ghi), chờ chốt P-01 | #ops-general | BA chốt: map kênh khách ghi sang kênh Slack hiện có trong CR-15.2 (khách ghi nhầm tên kênh). |
| 2026-10-12 | v1.1 | Thêm mục API & Cron | Endpoint, webhook và các bước Zap chỉ được nhắc 1 dòng trong BR_8.2.2.6 và Basic Flow | Mục API & Cron: spec Zap Flow 10.1A (trigger Typeform + Action 1–5), POST /analyze-trading-plan (input, output, xử lý, lỗi, gọi trùng), gọi Gemini, webhook TRADING_PLAN_ANALYZED (payload, lỗi khi gửi, gửi trùng). Basic Flow trỏ tới từng API; BR_8.2.2.6 rút các dòng API; thêm Hạng mục mở #10–12 | Mã lỗi 400/401/500, xử lý user_id không tồn tại (200 OK, bỏ qua), tách phần trả lời ngay / phần chạy nền, kiểu dữ liệu UUID / String (URL) và output rỗng của endpoint do BA định nghĩa theo RFQ_ Stack Trading Prop Tech V7.pdf §4.4 #11, #19 |
| 2026-10-12 | v1.2 | Basic Flow — mô tả lời gọi API | Bước gọi API chỉ gắn "(Ref: API_x)", không rõ bên gọi / bên nhận / kết quả; không rõ ranh giới trả 200 OK và chạy nền | Mỗi bước gọi giữa các hệ thống ghi dạng [Bên gọi → Bên nhận] tên API + input chính → kết quả ([Typeform → Zapier], [Zapier → Google Docs], [Zapier → S3], [Zapier → Middleware], [Middleware → S3], [Middleware → Gemini], [Middleware → Zapier]); ghi rõ Stage 3 bước 1–3 chạy trước khi trả 200 OK, Stage 3 bước 4 → Stage 5 chạy nền; thêm nhánh theo kết quả (sai chữ ký/input, user_id không tồn tại, có/không có Pod Leader, Gemini trả kết quả / thử lại / hết lượt, Zap lỗi, webhook lỗi). Mục API & Cron cập nhật số bước tham chiếu | — |
| 2026-10-13 | v1.3 | Dùng tên API gốc; bỏ tên tự đặt | Tiêu đề / bảng tóm tắt API & Cron và Basic Flow gọi endpoint bằng đường dẫn POST /analyze-trading-plan; "Zap Flow 10.1A"; "Gọi Gemini"; bước Zap đánh số "bước 1–5" / "Action 1–4" | API Analyze Trading Plan (POST /analyze-trading-plan); "Flow 10.1A: Trading Plan Ingestion"; "Gemini 3.1 Pro with Extended Thinking (thuộc API Analyze Trading Plan)"; webhook TRADING_PLAN_ANALYZED ghi rõ do API Analyze Trading Plan gửi; bước Zap gọi đúng tên nguồn Action 1 (Formatter), Action 2 (Docs), Action 3 (Export), Action 4 (API Push), Action 5 (Database). Mọi tên trường trong UC (user_id, document_s3_url, mentor_email, pdf_url, ai_analysis, pod_leader_id, Plan_Due, Induction_Due) đều có trong nguồn nên giữ nguyên. Giả định A-05, A-09 trong QnA_init_docs bỏ tên trường tự đặt mentee_name, leader_name, calendar_link, submitted_at, thay bằng mô tả nội dung | Chỉ giữ tên có trong nguồn; tên trường mới do BE chốt trong OpenAPI spec (RFQ_ Stack Trading Prop Tech V7.pdf §4.4 #11). Không đổi nghiệp vụ |
| 2026-10-13 | v1.4 | Basic Flow Stage 3–5 — Action 5 (Database) | Đóng Plan_Due / mở Induction_Due đặt trong phần chạy nền của Middleware, chỉ chạy khi mentee có leader | Action 5 (Database) là bước của Zap, chạy sau Action 4 khi nhận 200 OK (Stage 4); phần Middleware chạy nền (AI, webhook) tách thành Stage 5 | Theo Zapier Integration V7.pdf Flow 10.1A Action 4 → Action 5, POD-PLAN-08/11 |
| 2026-10-14 | v1.5 | Toàn UC — viết lại theo khuôn UC_8.1.x | Có bảng "Giải thích thuật ngữ" ở đầu; Basic Flow 5 Stage nhưng tham chiếu sang mục riêng; mục "API & Cron" liệt kê 4 API: API_8.2.2.1 Flow 10.1A: Trading Plan Ingestion (Zap), API_8.2.2.2 API Analyze Trading Plan (POST /analyze-trading-plan), API_8.2.2.3 Gemini 3.1 Pro with Extended Thinking, API_8.2.2.4 Webhook TRADING_PLAN_ANALYZED; BR_8.2.2.6 "Thông tin kỹ thuật cho dev"; mục "Hạng mục mở" đặt sau RACI | Bỏ bảng thuật ngữ (giải thích ngay câu dùng lần đầu). Basic Flow 5 Stage, bước đánh số, rẽ nhánh [If …] → ngay trong bước; input API Analyze Trading Plan ghi bảng tại Stage 3 bước 1; mã lỗi 401/400/500 tại Stage 3 bước 2; các bước Zap (Trigger, Action 1–5) viết thẳng trong Stage 1–4; gọi Gemini là một hành động ở Stage 5 bước 6, thông số gộp vào BR_8.2.2.3. Bỏ mục "API & Cron" (UC không có cron — ghi ở Trigger). Chỉ còn 2 API đúng như nguồn: API Analyze Trading Plan (POST /analyze-trading-plan) và webhook TRADING_PLAN_ANALYZED. BR_8.2.2.6 đổi tên theo nội dung: "API Analyze Trading Plan và webhook TRADING_PLAN_ANALYZED" (input, bảng lỗi, gọi trùng, payload webhook); anchor API_8.2.2.4 giữ tại phần webhook trong BR_8.2.2.6. "Hạng mục mở" → "Open Items", đặt trước RACI; nội dung 12 mục giữ nguyên | Theo yêu cầu BA: mô tả và thứ tự như UC_8.1.1 / UC_8.1.2. Nội dung nghiệp vụ và BR ID giữ nguyên. Sửa số API cho khớp nguồn: Zapier Integration V7.pdf §Flow 10.1A Action 4 gọi "Middleware Hub Endpoint (POST /analyze-trading-plan)", §Flow 10.1B Trigger "Webhook TRADING_PLAN_ANALYZED received from Middleware Hub"; RFQ_ Stack Trading Prop Tech V7.pdf §Analyze Trading Plan ("Node.js POSTs the Async Webhook Payload to the Zapier Catch URL"). Zap Flow 10.1A là chuỗi bước Zapier, gọi Gemini là bước xử lý nền của endpoint ("passes payload to Gemini") — không đánh số API. |
| 2026-10-14 | v1.6 | Cron Job task tách khỏi API | Overview chỉ có 3rd Party | Thêm dòng API (2 API) và Cron Job task (Không có) | Theo yêu cầu BA: Cron Job task là tác vụ nền chạy theo lịch, khác API; phải ghi rõ "Cron Job task" như API ghi rõ "API". Nguồn: RFQ_ Stack Trading Prop Tech V7.pdf §3.3 Background Workers (Cron Jobs). |
| 2026-10-15 | v1.7 | Stage 5 bước 4, 7 · BR_8.2.2.6 (webhook TRADING_PLAN_ANALYZED) · Open Items | Webhook chỉ có mentor_email, pdf_url, ai_analysis; thiếu tên leader, tên mentee, calendar link cho email leader → Open Items #5 (A-05) | Middleware tra và gửi kèm tên Pod Leader, tên mentee, Master Calendar link của leader trong webhook; bỏ Open Items #5, đánh số lại #6–#12 → #5–#11 | BA chốt 2026-10-15: dữ liệu tra được trong hệ thống (leader từ mentor_email, mentee từ link PDF đã lưu); Middleware gửi kèm thay vì để Zapier tra database |
| 2026-10-15 | v1.8 | Stage 2, Stage 3 bước 1, Stage 5 bước 2–3, BR_8.2.2.3, BR_8.2.2.4, BR_8.2.2.6 · Open Items | 11 hạng mục mở | Đóng 7 hạng mục: A-02 (lỗi sau Action 5 không flag mentee — POD-PLAN-11), A-04 (nộp khi ở waitlist rồi được gán pod: không mở Plan_Due, Middleware tự phân tích PDF mới nhất + mở Induction_Due cho leader mới), A-06 (gọi trùng cùng document_s3_url → bỏ qua, CR-18), A-09 (mốc nộp = lúc Submit Typeform — POD-PLAN-08), A-10 và A-12 (bỏ — ngoài phạm vi BA), POD-PLAN-01/02 (khách đã gửi, BA bổ sung sau). Còn 4 hạng mục: A-01, A-03, A-13, A-14 | BA chốt 2026-10-15. A-02, A-09 theo câu trả lời khách đã có trong QnA |
| 2026-10-15 | v1.9 | Toàn UC — Flow 10.1A chuyển về BE (A-01) | Zap Flow 10.1A: Typeform → Zapier → Action 1 (Formatter), Action 2 (Docs), Action 3 (Export) tạo PDF lưu S3 → Action 4 (API Push) gọi API Analyze Trading Plan với user_id, document_s3_url → Action 5 (Database) ghi SLA; Middleware chạy nền tải PDF từ S3, Gemini, webhook. Lỗi Zap → "Zap Error" (BR_8.2.2.5). 4 hạng mục mở | Không còn Zap cho Flow 10.1A. Typeform gửi kết quả thẳng tới API Analyze Trading Plan (input: user_id, câu trả lời, link ảnh, thời điểm submit, mã lần nộp). Middleware ghi SLA ngay khi nhận bài (trước khi trả 200 OK), rồi chạy nền: map dữ liệu, tạo Google Doc từ mẫu, xuất PDF, lưu S3, Gemini, webhook TRADING_PLAN_ANALYZED. Gọi trùng nhận theo mã lần nộp của Typeform (thay cho document_s3_url). BR_8.2.2.5 đổi thành "Lỗi khi xử lý nền". RACI: thêm ❓ Stack Trading cấp quyền cho Middleware dùng mẫu Google Doc. Open Items: đóng A-01; A-13 mở rộng cho lỗi tạo PDF / S3; còn 3 hạng mục | Dev đề xuất BE xử lý Flow 10.1A thay Zapier; BA chốt 2026-10-15. Giữ tên API Analyze Trading Plan và webhook TRADING_PLAN_ANALYZED theo nguồn, chỉ đổi bên gọi. Cần báo khách vì lệch Zapier Integration V7.pdf Flow 10.1A |
| 2026-10-16 | v1.10 | BR_8.2.2.1 — nội dung form Trading Plan | Chỉ có câu đồng ý; bộ câu hỏi ghi "do Stack Trading cung cấp" | Thêm nội dung Form 3: The Trading Plan — Form Title, Welcome Screen, Ending Screen, 13 câu hỏi theo 6 Section (loại câu, options, validation: Q5 tối thiểu 150 ký tự, Q10 tối thiểu 100 ký tự). Ảnh chart chỉ nhận .png, .jpg, .jpeg | Theo bảng template Stage 6 — POD system khách gửi. Hidden field giữ user_id (POD-PLAN-16 thay mentor_email) |
| 2026-10-16 | v1.11 | Pre-conditions · Stage 1 bước 3 · BR_8.2.2.1 — hidden field | Chỉ có user_id | Thêm hidden field mentor_email theo Form 3. Middleware vẫn tra email leader từ database theo user_id, không dùng mentor_email trên link | BA chốt 2026-10-16 theo bảng template Stage 6 — POD system khách gửi (Hidden Variables: user_id, mentor_email) |
| 2026-10-22 | v1.12 | Pre-conditions · Stage 1 bước 1–3 · Stage 2 bước 3, 5 · BR_8.2.2.1, BR_8.2.2.4, BR_8.2.2.6 · Open Items · Phân chia trách nhiệm | Nộp lại = lần nộp mới, không chặn (POD-PLAN-05); nộp lại có mở Induction_Due mới: Open Items #1 · hidden field user_id, mentor_email gắn sẵn trên link | Mỗi lần gán pod chỉ nhận 1 lần nộp; trang wrapper hiện You have already submitted this, Middleware bỏ qua lần 2 lọt qua; lần nộp lúc ở waitlist tính cho lần gán pod kế tiếp; Induction_Due chỉ mở 1 lần cho mỗi lần gán · form nhúng trang wrapper có đăng nhập, user_id lấy từ phiên đăng nhập; người khác bấm link không nộp thay được · Open Items còn 2 (đánh số lại) | Khách trả lời 2026-10-22: A-03 (thay POD-PLAN-05), UC_8.2.1 A-07 (CHR-127) |
| 2026-10-22 | v1.13 | Stage 2 bước 5 · Stage 3 bước 4 · Stage 4 bước 4 · BR_8.2.2.4, BR_8.2.2.5, BR_8.2.2.6 · Open Items · Phân chia trách nhiệm | Mở Induction_Due mỗi khi lần nộp có Pod Leader · lỗi tạo PDF: Open Items #1 · gửi webhook TRADING_PLAN_ANALYZED lỗi: Open Items #2 | Chỉ mở Induction_Due khi lần gán pod hiện tại chưa có (IS NULL), không ghi đè / mở lại · lỗi tạo PDF → log + Slack #ops-general "Trading Plan Ingestion Failed…", dừng xử lý lần nộp, không thử lại · webhook lỗi → log + Slack "Failed to dispatch TRADING_PLAN_ANALYZED…", không gửi lại · Open Items: không còn | Khách trả lời 2026-10-22: A-03, A-13, A-14. Kênh #operations khách ghi → #ops-general theo P-01. Kèm: BR_8.2.2.6 — Master Calendar link do BE gọi API tạo / lấy, không lưu (theo UC_8.2.3 A-02) |
| 2026-10-22 | v1.13 | Stage 2 bước 1 · BR_8.2.2.6 · Document References | Middleware kiểm tra chữ ký webhook (HMAC) từ Typeform, sai → 401 (RFQ V7 §4.4 #19) | Bỏ bước kiểm tra chữ ký và dòng 401; Stage 2 bước 1 chỉ kiểm tra input | BA chốt 2026-10-22: khách không yêu cầu riêng cho flow này |
| 2026-10-22 | v1.13 | Stage 1 bước 1 · Stage 2 bước 3 · BR_8.2.2.4 (đổi tên "Nộp 1 lần, dùng lại khi đổi pod"), BR_8.2.2.6 | Mỗi lần gán pod nộp 1 lần; đổi pod được nộp thêm 1 lần; lần nộp ở waitlist tính cho lần gán kế tiếp | Mỗi trader nộp 1 lần duy nhất; đổi pod / ghép lại / qua waitlist → dùng lại PDF đã nộp, không mở Plan_Due; leader mới nhận PDF và Induction_Due lúc gán pod (UC_8.2.1 Stage 4 bước 3) | Khách: "1 submission per Pod assignment" = trong 1 lần gán không nộp lần 2; đổi pod → "The Trading Plan should just be reused" (A-03) |
| 2026-10-22 | v1.13 | Stage 2 bước 5 — diễn giải đóng Plan_Due / mở Induction_Due | 1 câu dài: "đóng Plan_Due … kể cả khi nộp sau 72 giờ; mở Induction_Due …" | Tách 3 ý: đóng Plan_Due = đánh dấu đã nộp, đúng hạn hay muộn đều đóng; mở Induction_Due = lúc nộp + 5 ngày lịch, kèm ví dụ; điều kiện IS NULL | Viết lại cho dễ hiểu, không đổi nghiệp vụ |
| 2026-10-22 | v1.13 | Pre-conditions · Stage 3 bước 4 · Stage 4 bước 1, 4 · BR_8.2.2.4 | Một số câu gộp nhiều ý trong 1 dòng | Tách thành các ý riêng (sub-bullet) | Viết lại cho dễ hiểu, không đổi nghiệp vụ |
| 2026-10-22 | v1.13 | Stage 4 bước 4 · BR_8.2.2.2 | "Link PDF ai có cũng mở được nhưng không đoán được (UUID)"; nội dung webhook liệt kê 1 dòng; "gửi kể cả khi AI lỗi (lúc đó ai_analysis là câu thay thế)" | Giải thích link không cần đăng nhập, tên file ngẫu nhiên nên không dò ra link người khác, không hết hạn; webhook liệt kê từng thông tin kèm ý nghĩa; AI lỗi thì ai_analysis = AI analysis temporarily unavailable. và webhook vẫn gửi để leader nhận PDF | Viết lại cho dễ hiểu, không đổi nghiệp vụ |
| 2026-10-22 | v1.13 | Stage 1 bước 3 · Stage 2 bước 3, 5 · Stage 3 (tiêu đề) · Stage 4 bước 1, 4 · BR_8.2.2.4, BR_8.2.2.5, BR_8.2.2.6 | Một số câu viết tắt / mơ hồ | Diễn giải rõ nghĩa | Viết lại cho dễ hiểu, không đổi nghiệp vụ |
| 2026-10-22 | v1.13 | Toàn UC — Basic Flow, Business Rules | Văn phong ký hiệu, rút gọn, khó đọc | Viết lại bằng câu đầy đủ, kèm VD | Theo mẫu BA duyệt 2026-10-22, không đổi nghiệp vụ |
| 2026-10-22 | v1.13 | Basic Flow — toàn bộ · BR_8.2.2.2, BR_8.2.2.3, BR_8.2.2.5, BR_8.2.2.6 (tham chiếu bước) | Basic Flow 4 Stage tự sắp xếp (nhận bài, tạo PDF, phân tích), nhánh lỗi chen giữa từng bước | Basic Flow đi theo đúng khung Flow 10.1A của khách: Trigger, Action 1 (Formatter), Action 2 (Docs), Action 3 (Export), Action 4 (API Push — AI phân tích và gửi webhook), Action 5 (Database — ghi SLA ngay lúc nhận bài); edge case ghi ngay dưới từng Action; tham chiếu "Stage n" trong BR đổi sang "Action n" | Không đổi nghiệp vụ. Điểm khác tài liệu gốc ghi 1 lần ở đầu Basic Flow: Middleware làm Action 1–5 thay Zapier (A-01) |
| 2026-10-22 | v1.13 | Overview · Trigger bước 3, 5 · Action 4 · BR_8.2.2.6 | Typeform gọi thẳng API Analyze Trading Plan ở Trigger, bảng input 6 trường (user_id, mentor_email, câu trả lời, link ảnh, thời điểm nộp, mã lần nộp) | Trigger: Typeform gửi kết quả form sang Middleware (1 câu). Action 4: Middleware gọi API Analyze Trading Plan với đúng 2 input của V7 (user_id, document_s3_url), API trả 200 OK rồi chạy nền Gemini và webhook. BR_8.2.2.6 tách 2 phần: nhận kết quả form từ Typeform và API Analyze Trading Plan | Bám đúng Flow 10.1A Action 4 và §Analyze Trading Plan của khách, không đổi nghiệp vụ |
| 2026-10-22 | v1.13 | Basic Flow — toàn bộ · BR_8.2.2.6 | Có các bước và nhánh không có trong nguồn: Middleware kiểm tra bài nộp (thiếu thông tin 400, không tìm thấy mentee, trùng mã lần nộp, lỗi 500), đường dẫn nhận kết quả form, trang wrapper giải thích dài | Viết lại sát Flow 10.1A và §Analyze Trading Plan của khách: mỗi Action 1–3 câu theo nguồn; chỉ giữ nhánh có nguồn (POD-*, A-xx đã chốt). Bỏ bảng "nhận kết quả form từ Typeform" ở BR_8.2.2.6; thêm dòng A-06 vào bảng API | Bám nguồn khách, không thêm thông tin tự đặt |
| 2026-10-22 | v1.13 | Basic Flow — trình bày | Mỗi Action viết lại bằng lời của Sotatek | Mỗi bước: trích nguyên văn dòng Trigger / Action của khách, bên dưới là phần bổ sung chi tiết và edge case kèm nguồn | Chỉ đổi cách trình bày, không đổi nghiệp vụ |
| 2026-10-22 | v1.13 | Basic Flow · BR_8.2.2.2, BR_8.2.2.4, BR_8.2.2.5 | Basic Flow và Business Rules tách rời: BR_8.2.2.2 (lưu PDF), BR_8.2.2.4 (nộp 1 lần), BR_8.2.2.5 (lỗi & Slack alert) không được nhắc trong flow | Đưa thẳng nội dung 3 BR ngắn này vào đúng bước: nộp 1 lần ở Trigger, lưu PDF và lỗi Action 1–3 ở Action 3, lỗi webhook ở Action 4 (anchor giữ nguyên tại vị trí mới để link từ UC khác vẫn đúng). Còn lại 3 BR dài, đều được trỏ từ flow: BR_8.2.2.1 (form), BR_8.2.2.3 (AI), BR_8.2.2.6 (API, webhook) | Không đổi nghiệp vụ |
| 2026-10-29 | v1.14 | Toàn UC — cấu trúc lại theo khuôn UC_1.8.7 (giống UC_8.2.1 v1.12) | Mỗi bước trích nguyên văn dòng Trigger / Action của khách; Basic Flow đi theo thứ tự Action 1 đến Action 5 dù Action 5 (ghi SLA) chạy đầu tiên; edge case ghi ngay dưới từng Action; BR_8.2.2.2, BR_8.2.2.4, BR_8.2.2.5 nằm trong flow; mã QnA trong thân doc | Bỏ dòng trích nguyên văn. Mục đánh số 1 đến 9; §5 đi theo thứ tự chạy thật: 5.1 nộp form, 5.2 ghi SLA (Action 5), 5.3 tạo PDF (Action 1 đến 3), 5.4 AI và webhook (Action 4), bước đánh số 1 đến 17. Edge case gom vào bảng §6 (E_8.2.2.1 đến E_8.2.2.12). BR gom vào bảng §7; BR_8.2.2.1 ở §7.1, BR_8.2.2.3 ở §7.2, BR_8.2.2.6 ở §7.3; BR_8.2.2.5 gom 2 nội dung Slack alert. Mọi BR đều được refer từ bước hoặc exception liên quan. Mã QnA chỉ giữ ở Document References và Changelog. Giữ nguyên anchor BR_8.2.2.1 đến BR_8.2.2.6, API_8.2.2.4, open-items, phan-chia-trach-nhiem | BA yêu cầu viết dễ hiểu như UC_1.8.7, không đổi nghiệp vụ |
| 2026-10-29 | v1.14 | §1 Overview — Description | Mô tả chi tiết các bước, tên API, field và nhánh xử lý | Chỉ ghi tổng quan: UC dùng để làm gì và nội dung chính, bằng câu thường; chi tiết xem §5 | BA yêu cầu Description chỉ ghi tổng quan, không đổi nghiệp vụ |