lcbp3/specs/200-fullstacks/204-rfa-approval-refactor/spec.md

Feature Specification: RFA Approval System Refactor (TeamBinder/InEight-Style)

Feature Branch: 204-rfa-approval-refactor Created: 2026-05-11 Status: Draft Input: User description: "refactor ระบบการอนุมัติเอกสาร, RFA ให้เหมือนกับ TeamBinder หรือ InEight"

---

Overview

ปรับปรุงระบบการอนุมัติเอกสาร RFA (Request for Approval) ให้มีความยืดหยุ่นและครบถ้วนตามมาตรฐานระดับสูงของอุตสาหกรรมก่อสร้าง (TeamBinder, InEight) รองรับการทำงานแบบ Multi-Disciplinary Review, Response Codes มาตรฐาน, และ Distribution Matrix อัตโนมัติ

---

User Scenarios & Testing

User Story 1 - Review Teams by Discipline (Priority: P1)

ผู้จัดการโครงการสามารถกำหนดกลุ่มผู้ตรวจสอบ (Review Teams) ตามสาขาวิชา (Disciplines) แทนการระบุรายบุคคล เพื่อให้การมอบหมายงานยืดหยุ่นและรวดเร็ว

Why this priority: ฟีเจอร์หลักที่แยกระบบปัจจุบันกับมาตรฐานอุตสาหกรรม - ช่วยลดเวลาในการกำหนดผู้ตรวจสอบและรองรับการเปลี่ยนแปลงบุคคลในโครงการ

Independent Test: สามารถทดสอบโดยสร้าง Review Team ที่มีหลาย Disciplines และส่ง RFA เข้า workflow - ระบบต้องสามารถมอบหมายให้ทุก Discipline พร้อมกันได้

Acceptance Scenarios:

1. Given ผู้ใช้มีสิทธิ์จัดการ Review Teams, When สร้าง Review Team ใหม่ชื่อ "Structural Review Team" พร้อมกำหนด Disciplines: Structural, Civil, Then ระบบบันทึกทีมและสามารถใช้กับ RFA ได้
2. Given RFA ถูกส่งเข้า workflow และใช้ Review Team ที่มี 3 Disciplines, When ระบบประมวลผล, Then สร้าง Review Tasks สำหรับแต่ละ Discipline พร้อมกัน
3. Given Reviewer ในทีมเปลี่ยนตำแหน่งหรือลาออก, When Admin อัปเดตสมาชิกใน Review Team, Then RFA ที่รออยู่ต้องอัปเดตผู้รับผิดชอบโดยอัตโนมัติ

---

User Story 2 - Response Codes & Sub-Status (Priority: P1)

วิศวกรสามารถเลือก Response Code มาตรฐาน (1A, 1B, 1C, 2, 3, 4) พร้อม Sub-Status ที่บ่งบอกความหมายเฉพาะทาง เพื่อสื่อสารสถานะงานได้ชัดเจนและสอดคล้องกับมาตรฐานอุตสาหกรรม

Why this priority: ปรับปรุงการสื่อสารระหว่างฝ่ายต่างๆ ลดความกำกวมในการอนุมัติ และสนับสนุนการทำ Final Acceptance Certificate (FAC)

Independent Test: สามารถทดสอบโดยเปิดหน้าอนุมัติ RFA และตรวจสอบว่า Response Codes แสดงตาม Category ของเอกสาร - เลือก Code 1C ต้องมีการแจ้งเตือนฝ่ายสัญญา

Acceptance Scenarios:

1. Given RFA ประเภท Shop Drawing, When Reviewer เปิดหน้าอนุมัติ, Then แสดงเฉพาะ Response Codes ที่เกี่ยวข้องกับ Engineering/Drawings (1A-1G, 2, 3, 4)
2. Given Reviewer เลือก Code 1C (Change Order) หรือ 1D (Alternative), When บันทึกการอนุมัติ, Then ระบบส่งแจ้งเตือนไปยังฝ่ายสัญญา/BOQ อัตโนมัติ
3. Given RFA ได้รับ Code 2 (Approved as Noted), When ดูรายงานสถานะ, Then แสดงสถานะ "Approved with Minor Comments" พร้องานที่ต้องแก้ไข

---

User Story 3 - Delegation & Proxy (Priority: P2)

ผู้ตรวจสอบสามารถมอบหมายอำนาจ (Delegate) ให้ผู้อื่นทำงานแทนเมื่อไม่อยู่หรือไม่สะดวก โดยกำหนดระยะเวลาและขอบเขตอำนาจได้

Why this priority: ป้องกันการคั่งค้างของ workflow เมื่อผู้ตรวจสอบไม่ว่าง รองรับการทำงานแบบ Hybrid/Remote

Independent Test: สามารถทดสอบโดยผู้ใช้ A ตั้งค่า Delegate ให้ผู้ใช้ B แล้วส่ง RFA มา - ผู้ใช้ B ต้องเห็นงานใน Inbox และสามารถอนุมัติแทนได้

Acceptance Scenarios:

1. Given ผู้ใช้ต้องการลาพักร้อน 1 สัปดาห์, When ตั้งค่า Delegation ให้ colleague พร้อมระบุวันที่เริ่ม-สิ้นสุด, Then งานที่ส่งมาระหว่างนี้ไปที่ Delegatee โดยอัตโนมัติ
2. Given มีงาน RFA รออยู่ใน Inbox และผู้ใช้ตั้งค่า Delegation ไว้, When มีการส่งงานใหม่เข้ามา, Then ระบบมอบหมายให้ Delegatee พร้อมแสดงว่าเป็น "Delegated from [Original User]"
3. Given Delegation หมดอายุ, When มีงานใหม่ส่งมา, Then งานกลับมาที่ผู้ใช้เจ้าของงานเดิม และยกเลิกสิทธิ์ Delegatee

---

User Story 4 - Auto-Reminders & Escalation (Priority: P2)

ระบบส่งการแจ้งเตือนอัตโนมัติเมื่องานใกล้ครบกำหนด และส่งขึ้นระดับ (Escalate) เมื่อเกินกำหนด ตาม SLA ที่กำหนดไว้

Why this priority: ลดความล่าช้าใน workflow และปรับปรุง on-time delivery rate ของเอกสาร

Independent Test: สามารถทดสอบโดยสร้าง RFA ที่มี Due Date ในอีก 1 วัน และตรวจสอบว่าระบบส่ง Reminder ตามที่ตั้งค่าไว้

Acceptance Scenarios:

1. Given RFA มี Due Date ในอีก 2 วัน, When ถึงเวลา 9:00 ของวันที่ตั้งค่า Reminder, Then ส่งอีเมล/แจ้งเตือนไปยังผู้รับผิดชอบ
2. Given RFA เกินกำหนด 1 วัน, When ถึงเงื่อนไข Escalation, Then ส่งแจ้งเตือนไปยัง Manager ของผู้รับผิดชอบ พร้อมสถานะ Overdue
3. Given Admin ตั้งค่า Reminder Frequency เป็น "Daily" สำหรับงาน Overdue, When งานค้างเกินกำหนด, Then ส่ง Reminder ทุกวันจนกว่าจะดำเนินการ

---

User Story 5 - Distribution Matrix (Priority: P2)

ระบบกระจายเอกสารอัตโนมัติไปยังผู้ที่เกี่ยวข้องหลังจาก RFA ได้รับการอนุมัติ ตาม Distribution Matrix ที่กำหนดไว้ตามประเภทเอกสารและ Response Code

Why this priority: ลด manual work ในการส่งเอกสารต่อ ป้องกันการส่งตกหล่น และสนับสนุนการทำ Transmittal อัตโนมัติ

Independent Test: สามารถทดสอบโดยอนุมัติ RFA ที่มี Distribution Matrix แล้วตรวจสอบว่าเอกสารถูกส่งไปยังผู้รับที่กำหนดใน Matrix โดยอัตโนมัติ

Acceptance Scenarios:

1. Given RFA ประเภท Shop Drawing ได้รับ Code 1A (Full Approval), When อนุมัติสำเร็จ, Then ระบบส่งเอกสารไปยัง Site Team, QS, และ Document Control ตาม Distribution Matrix
2. Given Distribution Matrix มีเงื่อนไข "Send only if Code = 1A, 1B, or 2", When RFA ได้รับ Code 3 (Rejected), Then ไม่ส่งเอกสารตาม Matrix (แจ้งเฉพาะผู้ส่ง)
3. Given Admin อัปเดต Distribution Matrix เพิ่มผู้รับใหม่, When RFA ถัดไปได้รับการอนุมัติ, Then ส่งเอกสารไปยังผู้รับใหม่ด้วย

---

User Story 6 - Master Approval Matrix Management (Priority: P3)

ผู้ดูแลระบบสามารถจัดการ Master Approval Matrix ที่เป็นมาตรฐานขององค์กร แยกตามหมวดงานและสถานะย่อย ให้ใช้งานทั่วทั้งโครงการ

Why this priority: มาตรฐานการอนุมัติให้สอดคล้องกับบริษัทและอุตสาหกรรม ลดความสับสนในการใช้ Response Codes

Independent Test: สามารถทดสอบโดยสร้าง Master Approval Matrix ใหม่ และตรวจสอบว่า RFA แสดง Response Codes ตาม Matrix ที่กำหนด

Acceptance Scenarios:

1. Given Admin ต้องการสร้างมาตรฐานใหม่สำหรับโครงการก่อสร้างสะพาน, When สร้าง Master Approval Matrix พร้อมกำหนดหมวดงานและ Sub-status, Then สามารถใช้กับโครงการที่เลือกได้
2. Given Master Approval Matrix ถูกใช้งานในโครงการหลายแห่ง, When Admin แก้ไข Matrix, Then ระบบแสดง Warning ว่าจะมีผลกับโครงการที่ใช้งานอยู่

---

Edge Cases

1. Race Condition: สอง Reviewer ในทีมเดียวกันกดอนุมัติพร้อมกัน - ระบบต้องจัดการด้วย Optimistic Locking หรือ Redlock
2. Circular Delegation: ผู้ใช้ A Delegate ให้ B, B Delegate ให้ C, C พยายาม Delegate ให้ A - ระบบต้องตรวจจับและป้องกัน
3. Expired Review Task: Review Task ค้างนานเกินกำหนดและถูก Reassign - ต้องบันทึกประวัติการเปลี่ยนแปลง
4. Invalid Response Code: Reviewer พยายามใช้ Response Code ที่ไม่สอดคล้องกับ Category ของเอกสาร - ระบบต้องแสดงข้อผิดพลาดและไม่บันทึก
5. Concurrent Review: หลาย Disciplines ต้อง Review พร้อมกัน แต่มี Discipline หนึ่งปฏิเสธ - ต้องหยุด workflow และแจ้งผู้ส่ง

---

Requirements

Functional Requirements

Review Teams & Disciplines

• FR-001: ระบบ MUST รองรับการสร้าง Review Teams ที่มีหลาย Disciplines
• FR-002: Review Teams MUST สามารถกำหนดเป็น Default ตามประเภท RFA ได้
• FR-002.1: เมื่อมีการส่ง Revision ใหม่ของ RFA เดิม, ระบบ MUST ดึงรายชื่อ Review Team และ Disciplines จาก Revision ล่าสุดมาเป็น Default เพื่อความต่อเนื่อง (Inherit Previous Team) แต่ผู้ส่งยังคงสามารถปรับเปลี่ยนได้หากจำเป็น
• FR-003: เมื่อ RFA เข้า workflow ที่ใช้ Review Team, ระบบ MUST สร้าง Review Tasks สำหรับแต่ละ Discipline พร้อมกัน (Parallel Review)
• FR-004: Review Tasks MUST แสดงสถานะรวม (Aggregate Status) เช่น "2 of 3 Disciplines Approved"
• FR-004.5: Parallel Review MUST ใช้กฎ Lead Consolidation - ระบบอนุญาตให้ทุก Disciplines ตรวจสอบจนครบ โดยที่ Lead Discipline จะเป็นผู้พิจารณาความเห็นจากทุกฝ่ายและเป็นผู้สรุปสถานะสุดท้าย (Final Response Code) ของ RFA นั้นๆ
• FR-004.6: ในระหว่าง Parallel Review, Reviewers ทุกคน MUST สามารถเห็นคอมเมนต์และสถานะเบื้องต้นของกันและกันได้ (Full Transparency) เพื่อช่วยในการประสานงานข้ามสายงาน (Cross-discipline coordination)

Response Codes & Master Approval Matrix

• FR-005: ระบบ MUST ใช้ Master Approval Matrix ตามมาตรฐานที่กำหนด
• FR-006: Response Codes MUST แสดงตาม Category ของเอกสาร (Engineering, Material, Contract, Testing, ESG) และระบบ MUST จำกัดตัวเลือก (Filter) ให้ทั้ง Reviewer และ Lead เห็นเฉพาะโค้ดที่อยู่ในหมวดหมู่นั้นๆ เท่านั้น
• FR-006.1: หาก Final Response Code มีผลกระทบต่อ Cost หรือ Schedule (ตาม Matrix), ระบบ MUST ทำการ Flag และแจ้งเตือนบน Management Dashboard ทันที เพื่อให้ฝ่ายบริหารดำเนินการต่อภายนอกระบบได้ทันท่วงที
• FR-007: Code 1C (Change Order), 1D (Alternative), 3 (Rejected) MUST trigger การแจ้งเตือนไปยังฝ่ายที่เกี่ยวข้องโดยอัตโนมัติ
• FR-008: ระบบ MUST บันทึกประวัติการเปลี่ยน Response Code (Audit Trail)
• FR-009: Reviewer MUST สามารถเพิ่ม Comments พร้อม Response Code ได้

Delegation & Proxy

• FR-010: ผู้ใช้ MUST สามารถตั้งค่า Delegation ได้ พร้อมกำหนดระยะเวลาเริ่มต้น-สิ้นสุด
• FR-011: Delegation MUST รองรับการกำหนด Scope (เฉพาะบางประเภทเอกสาร หรือทั้งหมด)
• FR-012: ระบบ MUST ตรวจจับและป้องกัน Circular Delegation และไม่อนุญาตให้มีการมอบหมายงานต่อ (Sub-delegation) ในระดับผู้ใช้งานปกติ (Single Level Only) ยกเว้น Admin ที่มีสิทธิ์ในการ Reassign หรืองานจัดการมอบหมายงานใหม่ได้เสมอ
• FR-013: เมื่อ Delegation หมดอายุ, งานใหม่ MUST กลับไปยังผู้ใช้เดิมโดยอัตโนมัติ
• FR-014: Delegatee MUST เห็นงานที่ได้รับมอบหมายแยกจากงานของตนเอง (Badge "Delegated")

Auto-Reminders & Escalation

• FR-015: ระบบ MUST ส่ง Reminder ตาม Schedule ที่กำหนด (1 วันก่อน Due, วัน Due, ทุกวันหลัง Due)
• FR-016: Escalation MUST ดำเนินการแบบลำดับชั้น (L1 -> L2) โดยที่แต่ละระดับจะมีการแจ้งเตือน 3 ครั้งก่อนจะยกระดับขึ้นไปตามเกณฑ์ที่ตั้งไว้ และเมื่อถึงระดับสูงสุด (L2) ระบบ MUST ส่งแจ้งเตือนรายวัน (Daily) จนกว่าจะมีการดำเนินการ
• FR-016.1: ระบบ MUST บันทึกประวัติการ Escalation และการตอบสนองของผู้บริหารใน Audit Trail
• FR-017: Admin MUST สามารถตั้งค่า Reminder Rules ต่อโครงการ/ประเภทเอกสารได้
• FR-018: ระบบ MUST บันทึกประวัติการส่ง Reminder (ส่งเมื่อไหร่, ใครได้รับ)

Frontend Workflow Visualization

• FR-019.1: Parallel Review MUST แสดงผลด้วย Horizontal Stepper - แถบความคืบหนันแนวนอนแสดงสถานะแต่ละ Discipline [Structural ▓▓▓░] [Civil ▓▓▓▓] [MEP ▓░░░]
• FR-019.2: เมื่อมี Code 3 (Rejected) จาก Discipline ใด MUST แสดง Modal Dialog แจ้งการ Veto พร้อมรายละเอียด Discipline ที่ reject
• FR-019.3: Navigation ระหว่าง Discipline details MUST ใช้ Side Panel layout - ซ้ายรายการ Disciplines, ขวาแสดงรายละเอียด Comments + Attachments ของ Discipline ที่เลือก
• FR-019.4: Project Manager MUST สามารถ Override Veto ได้ - บังคับผ่าน RFA แม้มี Code 3 จาก Discipline พร้อมบันทึกเหตุผล, Audit trail ว่าเป็น forced approval, และแจ้งเตือนทุก stakeholder ที่เกี่ยวข้อง

Distribution Matrix

• FR-019: Distribution Matrix MUST กำหนดผู้รับตาม: ประเภทเอกสาร + Response Code + สถานะเอกสาร และระบบ MUST อนุญาตให้ผู้สรุปผล (Lead/PM) เพิ่มผู้รับเพิ่มเติมแบบ Manual ได้ก่อนการส่งออกเฉพาะครั้งนั้นๆ
• FR-020: ระบบ MUST สร้าง Transmittal Records อัตโนมัติหลังการอนุมัติตาม Distribution Matrix ผ่าน BullMQ Queue (Async, ภายใน 5 นาที)
• FR-021: Distribution Matrix MUST รองรับเงื่อนไข "Send Only If" (เช่น Code 1A, 1B เท่านั้น)
• FR-022: ระบบ MUST แสดงรายงาน Distribution Status (ส่งแล้วกี่ราย, ค้างกี่ราย)

Integration with Existing Systems

• FR-023: ต้องใช้ Unified Workflow Engine (ADR-001) ที่มีอยู่แล้ว
• FR-024: ต้องใช้ BullMQ (ADR-008) สำหรับ Reminders และ Distribution Jobs
• FR-025: ต้องใช้ CASL (ADR-016) สำหรับสิทธิ์ Reviewer และ Delegation

---

Key Entities

ReviewTeam

• ตัวแทนกลุ่มผู้ตรวจสอบที่จัดการตามสาขาวิชา
• Attributes: name, description, projectId, defaultForRfaTypes, isActive
• Relationships: has many ReviewTeamMember, has many ReviewTask

ReviewTeamMember

• สมาชิกใน Review Team พร้อม Discipline ที่รับผิดชอบ
• Attributes: teamId, userId, disciplineId, role, priorityOrder
• Relationships: belongs to ReviewTeam, belongs to User, belongs to Discipline

ReviewTask

• งานตรวจสอบที่สร้างเมื่อ RFA เข้า workflow
• Attributes: rfaRevisionId, teamId, disciplineId, assignedToUserId, status, dueDate, responseCode, comments
• Relationships: belongs to RfaRevision, belongs to ReviewTeam

ResponseCodeMatrix

• Master Approval Matrix ที่กำหนด Response Codes ตาม Category
• Attributes: code, subStatus, category, descriptionTh, descriptionEn, implications, requiresNotificationTo
• Relationships: has many ResponseCodeRule

ResponseCodeRule

• กฎการใช้ Response Code ตามประเภทเอกสาร
• Attributes: matrixId, documentTypeId, isEnabled, requiresComments, triggersNotification

Delegation

• การมอบหมายอำนาจจากผู้ใช้หนึ่งไปอีกผู้ใช้
• Attributes: delegatorId, delegateeId, startDate, endDate, scope, documentTypes, isActive
• Relationships: belongs to User (delegator), belongs to User (delegatee)

ReminderRule

• กฎการส่ง Reminder ตาม SLA
• Attributes: name, projectId, documentTypeId, triggerDays, reminderType, recipients, messageTemplate
• Relationships: has many ReminderSchedule

DistributionMatrix

• กำหนดการกระจายเอกสารหลังอนุมัติ
• Attributes: name, documentTypeId, responseCode, status, recipients, conditions, isActive
• Relationships: has many DistributionRecipient

DistributionRecipient

• ผู้รับเอกสารใน Distribution Matrix
• Attributes: matrixId, recipientType (USER/ORGANIZATION/TEAM), recipientId, deliveryMethod

---

Success Criteria

Measurable Outcomes

• SC-001: ผู้ใช้สามารถกำหนด Review Team ได้ในเวลาน้อยกว่า 2 นาที (เทียบกับระบบเดิมที่ต้องเลือกรายบุคคล)
• SC-002: Response Code ถูกใช้งานได้ถูกต้อง 95%+ ของเวลาทั้งหมด (ลดการใช้ผิดประเภท)
• SC-003: ลดเวลาในการอนุมัติ RFA โดยเฉลี่ย 30% จากการใช้ Parallel Review และ Response Codes ที่ชัดเจน
• SC-004: 0% ของเอกสารที่ค้างงานเนื่องจากผู้ตรวจสอบไม่อยู่ (ใช้ Delegation)
• SC-005: 100% ของเอกสารที่อนุมัติถูกกระจายตาม Distribution Matrix โดยไม่ต้อง manual intervention
• SC-006: On-time delivery rate ของ RFA ปรับปรุงจาก baseline เป็นอย่างน้อย 85%
• SC-007: ผู้ใช้พึงพอใจกับระบบอนุมัติใหม่ (NPS > 40)

---

Clarifications

Session 2026-05-13

• Q1: Parallel Review consensus model for conflicting decisions? → A: Lead Consolidation - Allow all disciplines to complete their review, then the Lead Discipline consolidates all comments and makes the final decision.
• Q2: Delegation Depth and sub-delegation rules? → A: Single Level Only (No sub-delegation) for regular users, but Admin retains full override power to reassign or manage delegations as needed.
• Q3: Manual overrides in Distribution Matrix? → A: Flexible Recipients - Allow Lead/PM to manually add additional recipients during the final approval step for a specific RFA.
• Q4: Escalation Cycle and notification frequency? → A: 3-Strike Escalation - Notify current escalation level 3 times before moving up to the next level (Progressive). Once the highest level (L2) is reached, send daily reminders until resolved.
• Q5: Transparency between Disciplines during Parallel Review? → A: Full Transparency - All reviewers can see each other's comments and partial results in real-time.
• Q6: Handling Cost/Schedule Implications from Response Codes? → A: Dashboard Flagging - Record the impact and notify management via dashboard/reporting without blocking the RFA flow.
• Q7: Review Team persistence on resubmissions? → A: Inherit Previous Team - Automatically default to the same team and disciplines from the previous version for continuity.
• Q8: Response Code visibility constraints for Reviewers? → A: Category Scoped - Filter the available codes based on the RFA category for both Reviewers and Leads to ensure consistency.

Session 2026-05-11

• Q1: Master Approval Matrix scope and inheritance model? → A: Global base + Project overrides - Default Matrix inherited organization-wide, projects can override specific codes/rules as needed (Option B)
• Q2: Parallel Review consensus model when Disciplines have conflicting decisions? → A: Lead Consolidation (Updated 2026-05-13) - Formerly Majority with Veto.
• Q3: Escalation chain depth for overdue RFA reviews? → A: 2 levels - Direct manager first, then Project Manager/Director if still unresolved after additional delay (Option B)
• Q4: Distribution Matrix execution timing relative to approval? → A: Async after approval - Approval returns immediately, distribution queued via BullMQ and processed automatically within 5 minutes (Option C)
• Q5: Frontend pattern for displaying Parallel Review progress? → A: Horizontal Stepper - แถบความคืบหนันแนวนอนแสดงสถานะแต่ละ Discipline (Option A)
• Q6: How to display Veto/Consensus status เมื่อมีการ Reject? → A: Modal Dialog - Popup แจ้งเมื่อมีการ Reject พร้อมรายละเอียด Discipline ที่ระบุ (Option B)
• Q7: Navigation pattern between Discipline details for Reviewer? → A: Side Panel - ซ้ายรายการ Disciplines, ขวาแสดงรายละเอียดที่เลือก (Option D)
• Q8: Can a decision be overridden and by whom? → A: Project Manager Override - PM สามารถบังคับผ่านการตัดสินใจของ Lead ได้ พร้อมบันทึกเหตุผล และแจ้งเตือนทุก stakeholder (Option B)

---

Assumptions

1. ผู้ใช้มีความคุ้นเคยกับ Response Codes มาตรฐานอุตสาหกรรม - จำเป็นต้องมี Training Material ประกอบ
2. โครงสร้าง Discipline Master Data มีอยู่แล้ว - ใช้จากระบบ User Management ที่มีอยู่
3. Unified Workflow Engine (ADR-001) มีความสามารถรองรับ Parallel Tasks - อาจต้องปรับปรุง DSL
4. BullMQ Infrastructure พร้อมใช้งาน - สำหรับ Reminders และ Background Jobs

---

Dependencies

• ADR-001: Unified Workflow Engine (ต้องรองรับ Parallel Review Tasks)
• ADR-008: BullMQ Notification Strategy
• ADR-016: CASL Authorization (สำหรับ Reviewer สิทธิ์)
• ADR-019: UUID Strategy (สำหรับ Entities ใหม่)
• ADR-021: Workflow Context (สำหรับ Step Attachments)
• Existing: Discipline, User, Organization Master Data

---

Risks & Mitigations

Risk	Impact	Mitigation
ผู้ใช้ไม่คุ้นเคยกับ Response Codes ใหม่	High	ทำ Training Workshop พร้อม Quick Reference Guide
Workflow Engine ไม่รองรับ Parallel Review	High	ประเมิน DSL ก่อนเริ่ม, อาจต้อง Refactor Engine
Performance ช้าจาก Complex Matrix Lookup	Medium	ทำ Caching สำหรับ Matrix และ Rules
Circular Delegation ซับซ้อน	Low	Validation ตั้งแต่ต้น, Limit depth ของ chain