S5 — Core Business Flow + Phase 2 Delta (Specification)¶

สถานะเอกสาร: ร่างพร้อมนำเสนอเชิง Specification
ระบบ: S5 — ระบบค่าตอบแทนทนายความ มาตรา 134/1 และ ม.75
วันที่สังเคราะห์: 12 กันยายน 2569
แหล่งความจริง: live application tree, SRS/FD, แผน Phase 2, ADR และชุดทดสอบใน Repo

แผนภาพประกอบ: เปิด Business Core Diagram แบบเต็มจอ
Source spec ของแผนภาพ: diagrams/src/s5_business_core.json (สร้างใหม่ด้วย ~/.claude/skills/archify)
หน้าระบบหลัก: S5 — ระบบค่าตอบแทนทนายความ 134/1
ที่มา: สังเคราะห์จาก repo lawyer-compensation-system (live application tree, SRS/FD, แผน Phase 2, ADR, ชุดทดสอบ) เมื่อ 12 กันยายน 2569

แผนภาพวงจรธุรกิจหลัก (Business Core Flow)¶

เปิดแบบเต็มจอ — Business Core + Phase 2

Problem Statement¶

ระบบมีแกนธุรกิจที่ชัดเจนอยู่แล้ว แต่ความรู้เกี่ยวกับแกนนี้กระจายอยู่ในหน้าจอทนายความ, คิวเจ้าหน้าที่, โมดูลอนุมัติ, การเบิกจ่าย และรายงานหลายชุด ทำให้การอธิบายภาพรวมเชิงธุรกิจต้องไล่จากโค้ดและเอกสารหลายแหล่ง

ความยากเพิ่มขึ้นเมื่อ Phase 2 ไม่ได้สร้างระบบใหม่แยกจากของเดิม แต่เพิ่ม control layer เข้าไปในจุดสำคัญของ flow ได้แก่ การกำหนดสิทธิ์จากบัญชีรายชื่อ, การขอสิทธิ์ชั่วคราว, การป้องกันคำขอซ้ำ, การตรวจสอบและส่งกลับแก้ไข, การจำกัดขอบเขตข้อมูล, การติดตามผล และ Audit Trail หากนำเสนอโดยไม่แยก baseline กับ Phase 2 จะมองไม่เห็นว่าอะไรคือ business core เดิม อะไรคือการควบคุมความเสี่ยงที่เพิ่มขึ้น และอะไรยังเป็นขอบเขตที่ไม่ควรสรุปว่าเสร็จครบ

Solution¶

จัดทำ canonical business flow หนึ่งภาพสำหรับการนำเสนอและการแตกงาน โดยมีเส้นทางหลักดังนี้:

ลงทะเบียน → ตรวจสิทธิ์ยื่น → กรอก/แนบ/ตรวจทาน/ยื่นคำขอ → นิติกรตรวจ → ผู้จัดการตัดสินใจ → เบิกจ่ายและติดตามผล

บนเส้นทางเดียวกันให้แสดง Phase 2 เป็นชั้นเน้นพิเศษ ไม่ใช่เป็นระบบคู่ขนาน:

Phase 2A: ราก RBAC, การจัดการผู้ใช้งาน และ Master Data ที่ flow อื่นใช้ร่วมกัน
Phase 2B: การนำเข้าบัญชีรายชื่อ, dry-run, upsert, auto-revoke, Active List และ Temporary Approval
Phase 2C: การค้นหา/ติดตามผล, เหตุผลการไม่อนุมัติ และการส่งออกข้อมูล
Phase 2D: การส่งกลับสองทาง, สถานะการแก้ไขสำนวน, การตรวจข้ามจังหวัดตามสิทธิ์, SLA และการแก้ข้อมูลโดย ADMIN ในช่วงที่กำหนด
Cross-cutting controls: การกันคำขอซ้ำ/เลขคำขอซ้ำ, การบันทึกผู้แก้ไข/การเปลี่ยนสถานะ และการคงความเข้ากันได้ของฐานข้อมูลแบบ append-only

เอกสารนี้เป็น specification สำหรับความเข้าใจและการนำเสนอ ไม่ใช่คำสั่งให้เปลี่ยน behavior ของระบบหรือรัน migration

User Stories¶

As a ทนายความหรือที่ปรึกษากฎหมาย, I want to ลงทะเบียนบัญชีของตนเอง, so that ฉันสามารถเข้าสู่กระบวนการยื่นคำขอได้อย่างถูกต้อง
As a เจ้าหน้าที่ผู้ดูแลสิทธิ์, I want to ตรวจและยืนยันคุณสมบัติของผู้สมัคร, so that เฉพาะผู้ที่ผ่านการยืนยันจึงมีสิทธิ์ยื่นคำขอใหม่
As a ผู้ดูแลระบบ, I want to กำหนดบทบาทการใช้งานของเจ้าหน้าที่, so that แต่ละคนเห็นและทำงานได้ตามหน้าที่รับผิดชอบ
As a ผู้ดูแลระบบ, I want to ระงับบัญชีเจ้าหน้าที่แยกจากการระงับสิทธิ์ยื่นของทนาย, so that การระงับการเข้าสู่ระบบไม่ถูกสับสนกับการระงับสิทธิ์ยื่นคำขอ
As a ผู้ดูแลบัญชีรายชื่อ, I want to เลือกประเภทบัญชีรายชื่อระหว่างทนายความกับที่ปรึกษากฎหมายเด็กหรือเยาวชน, so that สิทธิ์ของแต่ละประเภทไม่ปะปนกัน
As a ผู้ดูแลบัญชีรายชื่อ, I want to อัปโหลดบัญชีรายชื่อทั้งประเทศในไฟล์เดียวต่อประเภท, so that ระบบมีแหล่งความจริงของสมาชิกในรอบล่าสุด
As a ผู้ดูแลบัญชีรายชื่อ, I want to ตรวจรูปแบบไฟล์และความถูกต้องรายแถวก่อนเขียนข้อมูลจริง, so that ข้อมูลผิดรูปแบบไม่ทำให้บัญชีรายชื่อทั้งชุดเสียหาย
As a ผู้ดูแลบัญชีรายชื่อ, I want to เห็น dry-run ที่สรุปจำนวนเพิ่ม อัปเดต เพิกถอน และแถวผิดพลาด, so that ฉันประเมินผลกระทบก่อนยืนยันการนำเข้าได้
As a ผู้ดูแลบัญชีรายชื่อ, I want to เห็นรายชื่อผู้ที่จะถูกเพิกถอนก่อน apply, so that ฉันตรวจพบการอัปโหลดไฟล์ไม่ครบทั้งประเทศได้ก่อนเกิดผลกระทบ
As a ผู้ดูแลบัญชีรายชื่อ, I want to ยืนยันหรือยกเลิกการ apply แยกจากการ preview, so that การอัปโหลดไม่กลายเป็นการเปลี่ยนสิทธิ์โดยไม่ตั้งใจ
As a ผู้ดูแลบัญชีรายชื่อ, I want to ให้สมาชิกที่ยังอยู่ในบัญชีคงสิทธิ์ไว้ และเพิกถอนเฉพาะผู้ที่หายจากบัญชีรอบล่าสุด, so that สิทธิ์สะท้อน roster ล่าสุดโดยอัตโนมัติ
As a ผู้ดูแลบัญชีรายชื่อ, I want to ย้อนกลับผลการนำเข้าทั้ง batch ได้โดยอาศัย before-state, so that ความผิดพลาดของ batch สามารถกู้คืนได้อย่างตรวจสอบได้
As a เจ้าหน้าที่, I want to ดู Active List แยกเป็นทนายความและที่ปรึกษากฎหมายเด็กหรือเยาวชน, so that ฉันรู้ว่าใครมีสิทธิ์ปัจจุบันในแต่ละประเภท
As a ทนายความที่ไม่มีชื่อใน roster ล่าสุด, I want to ขออนุญาตยื่นคำขอชั่วคราวโดยระบุวันปฏิบัติหน้าที่, so that ฉันยังขอใช้สิทธิ์ย้อนหลังในวันที่มีสิทธิ์ตามเงื่อนไขได้
As an ADMIN, I want to อนุมัติหรือไม่อนุมัติ Temporary Approval พร้อมเหตุผล, so that การใช้สิทธิ์ชั่วคราวมีผู้ตัดสินและมีหลักฐาน
As a ทนายความที่ได้รับอนุมัติชั่วคราว, I want to ยื่นได้เฉพาะวันที่ได้รับอนุมัติ, so that สิทธิ์ชั่วคราวไม่ขยายเกินขอบเขตที่ตัดสิน
As a ทนายความ, I want to เริ่มคำขอ 134/1 โดยเลือกวันปฏิบัติหน้าที่และข้อมูลพื้นที่, so that คำขอถูกผูกกับงานและจังหวัดที่เกี่ยวข้อง
As a ที่ปรึกษากฎหมายเด็กหรือเยาวชน, I want to เริ่มคำขอ ม.75 ผ่าน wizard เดียวกันในเชิงโครงสร้าง, so that ฉันทำงานได้ด้วยประสบการณ์ที่สอดคล้องกัน
As a ทนายความหรือที่ปรึกษากฎหมาย, I want to บันทึกข้อมูลเป็นร่างระหว่างกรอก wizard, so that ฉันกลับมาทำต่อได้โดยไม่ต้องเริ่มใหม่
As a ทนายความหรือที่ปรึกษากฎหมาย, I want to ให้ระบบตรวจข้อมูลผู้ต้องหา ประเภทเอกสาร อายุ และข้อมูลค่าใช้จ่าย, so that ข้อมูลไม่ครบหรือผิดรูปแบบถูกแจ้งก่อนยื่น
As a ผู้ยื่นคำขอ, I want to แนบแบบรับรองตนในระดับคำขอ, so that เอกสารนี้เป็นหลักฐานของคำขอทั้งใบ ไม่ถูกเข้าใจว่าเป็นของผู้ต้องหารายใดรายหนึ่ง
As a ผู้ยื่นคำขอ, I want to แนบเอกสารประกอบค่าเดินทางแยกจากแบบรับรองตน, so that เจ้าหน้าที่แยกประเภทหลักฐานและความบังคับได้ถูกต้อง
As a ผู้ยื่นคำขอ, I want to เห็นไฟล์แนบเดิมและชื่อไฟล์เดิมเมื่อกลับเข้าคำขอ, so that การย้อนกลับหรือเพิ่มผู้ต้องหาไม่ทำให้หลักฐานหาย
As a ผู้ยื่นคำขอ, I want to ตรวจทานข้อมูลทั้งหมดบนหน้า preview ก่อนกด “ยื่นคำขอ”, so that ฉันยืนยันความครบถ้วนก่อนคำขอเข้าสู่กระบวนการเจ้าหน้าที่
As a ผู้ดูแลระบบ, I want to ให้เลขคำขอออกเมื่อยื่นจริงและออกเพียงครั้งเดียว, so that การเปิดร่างหรือการกดส่งซ้ำไม่สร้างเลขซ้ำ
As a ระบบ, I want to ป้องกันคำขอซ้ำตามทนาย วันปฏิบัติหน้าที่ และประเภทคำขอ, so that หนึ่งสิทธิ์การปฏิบัติงานไม่ถูกเบิกซ้ำด้วยคำขอหลายใบ
As a ฝ่ายรับคำขอหรือเจ้าหน้าที่ดำเนินการ, I want to เห็นคิวคำขอที่รอรับและมอบหมาย, so that คำขอมีเจ้าของงานชัดเจนก่อนเข้าสู่การให้ความเห็น
As a นิติกร, I want to รับคำขอและตรวจรายละเอียดคดี ผู้ต้องหา เอกสาร และจำนวนเงิน, so that ความเห็นตั้งอยู่บนข้อมูลที่ตรวจสอบได้
As a นิติกร, I want to ส่งความเห็นให้ผู้จัดการตรวจพร้อมสถานะที่ชัดเจน, so that คำขอเดินต่อไปยังจุดตัดสินใจที่ถูกต้อง
As a นิติกร, I want to ส่งคำขอกลับฝ่ายรับคำขอพร้อมเหตุผล, so that ข้อมูลที่ยังไม่พร้อมถูกแก้ในจุดรับผิดชอบเดิม
As a นิติกร, I want to ส่งคำขอกลับให้ทนายโดยตรงพร้อมเหตุผล, so that ผู้ยื่นแก้ข้อมูลที่ตนรับผิดชอบได้โดยไม่ต้องผ่านเส้นทางที่ไม่จำเป็น
As a ทนายความหรือที่ปรึกษากฎหมาย, I want to เห็นเหตุผลการไม่อนุมัติหรือเหตุผลที่ถูกส่งกลับ, so that ฉันรู้ว่าต้องแก้ไขหรือดำเนินการต่ออย่างไร
As a ผู้ยื่นคำขอที่ถูกส่งกลับ, I want to แก้ไขสำนวนแล้วส่งกลับเข้าคิวนิติกร, so that คำขอเดิมเดินหน้าต่อได้โดยไม่สร้างคำขอใหม่
As a นิติกร, I want to เห็นคำขอที่ผู้ยื่นแก้ไขแล้วกลับเข้าคิว, so that การตรวจรอบถัดไปต่อเนื่องกับประวัติเดิม
As a ผู้จัดการ, I want to อนุมัติหรือไม่อนุมัติผลการพิจารณา, so that คำขอมีผลตัดสินก่อนเข้าสู่การเบิกจ่าย
As a ผู้จัดการ, I want to เห็นข้อมูลและความเห็นก่อนตัดสินใจ, so that การอนุมัติไม่แยกขาดจากหลักฐานของคำขอ
As a ผู้ปฏิบัติงานการเงิน, I want to นำคำขอที่อนุมัติแล้วเข้าชุดเบิกจ่าย, so that การจ่ายเงินเกิดจากรายการที่ผ่านการอนุมัติแล้ว
As a ผู้ปฏิบัติงานการเงิน, I want to ตรวจยอดและบันทึกการเบิกจ่าย, so that ผลการจ่ายสอดคล้องกับคำขอและตรวจสอบย้อนหลังได้
As a ผู้ใช้งานที่เกี่ยวข้อง, I want to ติดตามสถานะคำขอและเหตุผลได้, so that ไม่ต้องสอบถามด้วยช่องทางนอกระบบ
As a ทนายความ, I want to เห็นเฉพาะคำขอของตนเองในประวัติและการติดตามผล, so that ข้อมูลของทนายคนอื่นไม่รั่วไหล
As a เจ้าหน้าที่ส่วนภูมิภาค, I want to เห็นข้อมูลตามจังหวัดที่ตนรับผิดชอบ, so that การประมวลผลไม่ข้ามขอบเขตพื้นที่
As a เจ้าหน้าที่ส่วนกลาง, I want to สลับมุมมองจังหวัดสำหรับหน้าดูข้อมูลแบบ read-only, so that ฉันตรวจภาพรวมรายจังหวัดได้โดยไม่เปลี่ยนสังกัดจริงหรือเปิดสิทธิ์ประมวลผลข้ามจังหวัด
As a ผู้บริหารหรือผู้ตรวจสอบ, I want to ค้นหาและ export ผลการติดตาม, so that ฉันใช้ข้อมูลประกอบการกำกับและรายงานได้
As an ADMIN, I want to แก้ไขข้อมูลที่อนุญาตเฉพาะช่วงที่นิติกรกำลังพิจารณา, so that ข้อมูลผิดเล็กน้อยถูกแก้ได้โดยไม่เปิดช่องแก้หลังอนุมัติ
As a ผู้ตรวจสอบ, I want to เห็นว่าใครเปลี่ยนฟิลด์ใด จากค่าใดเป็นค่าใด และเมื่อใด, so that การเปลี่ยนแปลงสำคัญตรวจสอบย้อนกลับได้
As a ผู้ตรวจสอบ, I want to เห็นการเปลี่ยนสถานะสำคัญแม้เกิดจากการส่งกลับหรืออนุมัติ, so that audit trail สะท้อนเหตุการณ์ทางธุรกิจ ไม่ใช่เฉพาะการแก้ข้อความ
As a ผู้ดูแลระบบ, I want to เก็บประวัติการนำเข้า roster และ before-state ของแต่ละรายการ, so that การเปลี่ยนสิทธิ์จำนวนมากมีหลักฐานระดับ batch
As a ทีมพัฒนาและผู้ดูแลระบบ, I want to เพิ่ม schema แบบ additive และคงคอลัมน์เดิมไว้, so that code รุ่นเก่าสามารถทำงานได้หากต้อง rollback deployment

Implementation Decisions¶

เอกสารนี้เป็นเอกสารกำกับความเข้าใจและการนำเสนอเท่านั้น การสร้าง Flow และ Specification ไม่เปลี่ยน controller, model, view, database หรือ deployment configuration
ใช้ live back-office module และ live lawyer-facing module เป็นหลักฐานของ flow ส่วน backup tree และสำเนา dated modules ไม่ถือเป็น source of truth
ใช้คำศัพท์กลาง register, cases, approval, refund, roster_import, temporary_approval, audit_trail, request_right_status, case_status, session_locat และ session_view_locat ตาม domain glossary/ADR ของ Repo
รวมคำขอ 134/1 และ ม.75 ไว้ใน business flow เดียว แต่รักษาความแตกต่างของกฎอายุ ประเภทคำขอ เลขคำขอ และข้อมูลผู้ต้องหาตามชนิดคำขอ
จุดเริ่มของการยื่นคือหน้า preview; การกด “ยื่นคำขอ” เป็น business transition ที่ออกเลขคำขอเมื่อยื่นจริง ไม่ใช่เมื่อสร้างร่าง
สิทธิ์ยื่นคำขอเป็น precondition ของ flow: ผู้มีสิทธิ์จาก roster เดินเส้นทางปกติ ส่วนผู้ถูกเพิกถอน/ระงับต้องผ่าน Temporary Approval ที่ผูกกับทนาย ประเภท roster และวันปฏิบัติหน้าที่
Roster import เป็นหนึ่งไฟล์ต่อหนึ่งประเภทต่อรอบ, มี validation และ dry-run ก่อน apply, ใช้ upsert, เพิกถอนผู้ที่ไม่อยู่ในบัญชีรอบล่าสุดตามกติกาที่ตัดสินแล้ว และต้องมี rollback ระดับ batch
การแนบเอกสารเป็น ownership ระดับคำขอ ไม่ใช่ระดับผู้ต้องหาหรือรายการเดินทาง แบบรับรองตนเป็นไฟล์บังคับหนึ่งไฟล์ ส่วนเอกสารประกอบค่าเดินทางเป็นไฟล์ทางเลือกหนึ่งไฟล์
การส่งกลับให้ทนายเป็น two-way flow: เก็บเลขคำขอเดิม, แสดงเหตุผล, เปิดสถานะแก้ไขสำนวน และส่งกลับเข้านิติกรตามกติกาที่อนุมัติแล้ว
การแก้ไขโดย ADMIN เป็น constrained edit เฉพาะช่วงที่นิติกรให้ความเห็น และไม่ใช้เป็นสิทธิ์แก้ไขข้อมูลทางการเงินหรือสถานะหลังอนุมัติ
session_locat คือสังกัดจริงที่ใช้กับ processing scope; session_view_locat คือมุมมองจังหวัดแบบ read-only และห้ามนำมาปนกับคิวปฏิบัติงานหรือสิทธิ์อนุมัติ
ไม่เพิ่ม role slug ใหม่และไม่ฟื้น role ที่ถูก retire; การควบคุมสิทธิ์ใช้ role token ที่ระบบและข้อมูลกลางรองรับอยู่แล้ว
Audit Trail เป็นชั้นเพิ่มเติมจาก log: เก็บค่าก่อน/หลังและผู้กระทำสำหรับการเปลี่ยนแปลงที่มีความหมาย ขณะที่การเปลี่ยนสถานะสำคัญต้องมีร่องรอยเสมอ
การแสดงผลเอกสารนี้ทำด้วย Archify workflow schema v2, ตั้งคุณภาพเป็น showcase, ใช้ automatic routing เป็นค่าเริ่มต้น และเน้น Phase 2 ด้วย phase/group/tag/สี semantic
เนื่องจาก authored language เป็นภาษาไทย จึงไม่กำหนด meta.locale; fixed Viewer UI ของ Archify จะ fallback เป็นภาษาอังกฤษ แต่เนื้อหาใน diagram ยังคงเป็นภาษาไทยทั้งหมด
ไม่เปิด engineering_profile และไม่ใส่ brand identity เพราะ diagram นี้เป็น business workflow ไม่ใช่ production deployment topology

Testing Decisions¶

Test seam หลักคือ business-flow E2E ผ่านหน้าจอจริงและ endpoint ที่ผู้ใช้กดใช้งานจริง โดยใช้ fixture/บัญชีทดสอบเฉพาะของ test และตรวจทั้งผลบนหน้าจอ ผล redirect และ state ที่เกิดขึ้นในฐานข้อมูล
Happy path ต้องครอบคลุมอย่างน้อย: สิทธิ์พร้อม → สร้างร่าง → กรอกข้อมูล → แนบเอกสาร → preview → ยื่น → รับ/มอบหมายนิติกร → ให้ความเห็น → ผู้จัดการอนุมัติ → ติดตามผล/เบิกจ่าย
Negative path ต้องครอบคลุมอย่างน้อย: ไม่ผ่านสิทธิ์, ไม่มีแบบรับรองตน, ไฟล์ผิดชนิด/เกินขนาด, คำขอซ้ำ, เหตุผลส่งกลับว่าง, ยิงข้ามเจ้าของ/ข้ามจังหวัด, ยิง endpoint โดยไม่มี role และ apply roster โดยไม่ผ่าน dry-run
สำหรับ Temporary Approval ต้องทดสอบทั้งรออนุมัติ, อนุมัติ, ไม่อนุมัติพร้อมเหตุผล, ยื่นได้ตรงวัน, ยื่นผิดวัน และทั้งคำขอ 134/1 กับ ม.75
สำหรับ rejection/rework ต้องตรวจว่าทนายเห็นเหตุผล, แก้ไขและส่งกลับได้, สถานะกลับเข้าคิวที่ถูกต้อง, เลขคำขอเดิมคงอยู่ และการตีกลับที่ไม่อยู่ในช่วงอนุญาตถูกปฏิเสธ
สำหรับ roster import ต้องตรวจ parser, BOM/encoding, รายงาน dry-run, set-based apply, auto-revoke, type scope, before-state, rollback และ audit ระดับ batch โดยไม่ apply บนฐานข้อมูลร่วมจริงระหว่างพัฒนา
สำหรับ RBAC และ province scope ต้องทดสอบ role ที่อนุญาต/ไม่อนุญาต, ผู้ใช้ส่วนกลาง, ผู้ใช้ภูมิภาค, super admin, การ forge ค่า session และการแยก read scope ออกจาก processing scope
สำหรับการค้นหา/แบ่งหน้า/เรียงลำดับ ต้องทดสอบทั้งหน้าแรกและหน้าที่สอง เนื่องจาก CI 2.1.2/sqlsrv มี SQL shape ต่างกันเมื่อมี offset
สำหรับเงินและ audit ต้องตรวจค่าที่อ่านกลับจากฐานหลังเขียนสำเร็จ, ไม่สร้าง audit เมื่อ write ล้ม, ไม่เขียน audit เมื่อค่าไม่เปลี่ยน และคง log เดิมไว้ตาม ADR
Prior art ที่ใช้เป็นหลักฐานคือชุดทดสอบ Phase 2A RBAC/master data, Phase 2B roster/temporary approval, Phase 2C search/reason, Phase 2D bounce/admin edit, และชุด SCRUM-484 attachment กับ Phase 5 audit hardening
สำหรับ artifact ต้องรัน Archify validate workflow --quality showcase --json ให้ครบ 9 checks, ตรวจ workflow v2 layout receipt และรัน deliver ก่อน handoff; หลัง deliver ต้องรัน visual-check ที่ 1440×900, 1600×1000, 1920×1080 และ 2048×1320
Test เน้น external behavior และความหมายของ flow ไม่ผูกกับชื่อเมธอด โครงสร้าง HTML ภายใน หรือรายละเอียด implementation ที่เปลี่ยนได้

Out of Scope¶

ไม่แก้ไข behavior หรือ refactor code ของ application ในงานเอกสารนี้
ไม่สร้างหรือแก้ migration, ไม่เขียนข้อมูลลงฐานข้อมูลร่วม, ไม่ deploy, ไม่ merge, ไม่ push และไม่ tag release
ไม่สรุปว่า REQ-LAW-018 Budget Management เสร็จแล้วเพียงเพราะมีภาพรวมของการเบิกจ่าย
ไม่รวมการทำ .xlsx จริงด้วย PhpSpreadsheet, รายงานที่ยังไม่มีนิยาม/ยังไม่ครบ, หน้าจอตั้งค่าปฏิทินวันหยุด และการเปิดใช้ email/Keycloak runtime configuration เป็นผลลัพธ์ของ Flow นี้
ไม่อนุญาตให้มุมมองจังหวัด read-only กลายเป็นสิทธิ์ประมวลผล อนุมัติ หรือแก้ไขข้ามจังหวัด
ไม่กำหนด policy ใหม่ในจุดที่ SRS/FD/ADR ยังเปิดเป็นคำถาม; ต้องเปิด decision/ADR แยกก่อนนำไป implement
ไม่ใช้ไฟล์ backup, dead module, หรือ root view ที่ยังไม่ได้พิสูจน์ route เป็นหลักฐานของ business behavior

Further Notes¶

ภาพนี้ตั้งใจตอบคำถามว่า “ระบบทำคุณค่าทางธุรกิจตั้งแต่รับรองผู้มีสิทธิ์จนถึงผลการเบิกจ่ายอย่างไร และ Phase 2 เพิ่ม control ตรงไหน” ไม่ใช่แผนผัง deployment หรือ data model เต็มรูปแบบ
Phase 2 เป็น delta ที่ซ้อนอยู่บน core process: 2A เป็น foundation, 2B คุม eligibility, 2C เพิ่ม visibility/feedback, 2D ทำให้ approval workflow มีทางกลับและกติกาชัดขึ้น
HEAD ปัจจุบันมีงานต่อยอดหลัง Phase 2 เช่น disbursement/refund, notification, server-side performance, province view switcher และ audit hardening อยู่แล้ว เอกสารนี้จึงระบุไว้เป็นหลักฐานประกอบ แต่ไม่ยกให้เป็น Phase 2 business capability ใหม่ทั้งหมด
จุดทดสอบที่เสนอเป็น seam เดียวในระดับ business journey โดยมี contract/static tests เป็นหลักฐานสนับสนุน ไม่แตกเป็น integration seam ใหม่สำหรับทุก controller
สถานะ requirement บางข้อยังเป็น partial หรือมี dependency ตาม coverage ledger และ open questions ของ Repo; การแสดงเส้นทางบนภาพไม่ได้แปลว่าทุก acceptance criterion ของทุก REQ ปิดครบ
การเปลี่ยนแปลงใด ๆ ที่ทำให้สถานะ, role, ownership, province scope, payment invariant หรือ schema compatibility เปลี่ยน ต้อง update ทั้งเอกสารนี้และ source diagram ในงานเดียวกัน