AMLO Screening — Implementation Plan (4 Phases)

หน้านี้คือแผนลงมือทำ ไม่ใช่ design — เหตุผลเชิงสถาปัตยกรรมอยู่ที่ Architecture & Scenarios · Phase 1 มีเอกสารแยกสำหรับส่งต่อที่ Phase 1 Handoff

1. กติกาข้อเดียวที่อยู่เหนือทุกเฟส

สิ่งเดียวที่ Business ตั้งใจให้กระทบ คือ ผู้ใช้ที่บริษัทติด AMLO จะทำรายการไม่ได้ — นอกจากนี้ไม่มีอะไรควรเปลี่ยนสำหรับใครเลย

2. ภาพรวม 4 เฟส

flowchart LR
    P1["Phase 1 — Data tier<br/>ตารางใหม่ + จัดกลุ่มข้อมูล<br/>dev อีกคน ทำคู่ขนาน"]
    P2["Phase 2 — Backend<br/>อ่าน source of truth<br/>บล็อก ปลด audit หลักฐาน"]
    P3["Phase 3 — Frontend<br/>ShareLib HostApp AdminPortal"]
    P4["Phase 4 — Infrastructure<br/>APIM facade v7"]
    CONTRACT{{"contract ที่ freeze ไว้<br/>= schema ของตารางใหม่"}}

    P1 -.ผลิต.-> CONTRACT
    CONTRACT -.บริโภค.-> P2
    P2 --> P3
    P3 --> P4

3. ขั้นตอนที่ทุกเฟสต้องทำเหมือนกัน

เริ่มงานทุกครั้ง:

git checkout development
git pull                 # ต้อง pull จริง — checkout ในเครื่องตามหลัง origin อยู่หลาย commit
git checkout -b feature/amlo-<ชื่องาน>

🔴 checkout ในเครื่องของหลาย repo ตามหลัง origin อยู่จริง (เคยทำให้สรุปผิดมาแล้ว 3 ครั้งในรอบก่อน) — ก่อนสรุปว่าโค้ดเป็นยังไง ให้ดู git show origin/development:<path> เสมอ ไม่ใช่ดู working tree

ทุกงานที่แตะ schema (entity / EF config / migration / ModelSnapshot):

ต้องทำบน branch MIGRATION ไม่ใช่ feature branch ของตัวเอง ตามกติกาของทีม:

1. git checkout MIGRATION → port เฉพาะ source ของ data tier (entity / enum / EF config) จาก feature มา
2. dotnet ef migrations add <ชื่อ> บน MIGRATION — ห้าม cherry-pick migration + snapshot จาก feature มา (lineage เพี้ยน)
3. verify dotnet ef migrations has-pending-model-changes = none
4. merge MIGRATION กลับเข้า feature branch ด้วย — feature ต้องพา migration ติดไป
5. ห้าม merge development → MIGRATION (จะลาก business logic เข้ามา)

คอลัมน์ใหม่ทุกตัวต้อง NULL ได้ — ไม่มีข้อยกเว้น

ค่า NULL ต้องแปลว่า “ยังไม่ได้ตรวจ / พฤติกรรมเดิม” เสมอ ห้ามแปลว่า “ผ่าน”

4. Phase 2 — Backend

รายละเอียดกลไกอยู่ที่ Architecture §4–§8 หน้านี้บอกแค่ลำดับงานและเงื่อนไขรับงาน

4.1 ลำดับงาน

4.2 เงื่อนไขรับงาน Phase 2

• คอลัมน์ใหม่ทุกตัว NULL ได้ และรันแอปเวอร์ชันก่อนหน้าชี้ DB ใหม่แล้วไม่พัง
• CurrentSchemaVersion ของ UserInfoForRedis ไม่ถูก bump และ blob เก่า deserialize ได้
• endpoint เดิมทุกเส้นตอบเหมือนเดิม (มี test เทียบ response ก่อน/หลัง)
• enforcement ยังปิดอยู่ — เปิด flag = ปิด แล้วทุก flow เดิมผ่าน
• has-pending-model-changes = none หลัง merge MIGRATION เข้า feature
• มี test ของ Redis refresh ล้มเหลว — วันนี้ CacheRefreshBehavior กลืน exception แล้วตอบ 200 ซึ่งกลายเป็นช่องโหว่ทันทีที่ Redis กลายเป็นตัวบอกสถานะบล็อก

5. Phase 3 — Frontend

ทำแบบเดียวกับ Phase 2 (checkout development → pull → branch ใหม่) แต่ฝั่งหน้าจอ

เงื่อนไขรับงาน Phase 3

• FE ใหม่ + BE เก่า (ยังไม่มี field AMLO) = หน้าจอปกติ ไม่มี error ไม่มี modal ค้าง
• modal ปิดได้เมื่อ /users/me ยืนยันเท่านั้น ห้ามปิดจาก local state
• Admin Portal มี guard ต่อ child route แยกกัน — วันนี้ menuAccessGuard มีอยู่แต่ canActivateChild ยัง comment ไว้
• Production artifact ต้องไม่มี Test Simulation ทั้ง route/chunk/menu — และต้องเช็ค permission/menu dataset ฝั่ง backend แยกต่างหาก เพราะเมนูมาจาก dataset ไม่ได้มาจาก artifact
• อัปโหลดทีละไฟล์ผูกด้วย correlation id ไม่ใช่ยิง 10 ไฟล์ใน request เดียว (10 × 10 MB เกินเพดาน request กลาง 10 MB)

6. Phase 4 — Infrastructure

ทำหลังสุดเสมอ ตามที่ Owner สั่งไว้ใน D1 เพราะกระทบ UAT ที่กำลัง process อยู่

เงื่อนไขรับงาน Phase 4

• มีแผน rollback กลับ v6 ที่ ทดสอบแล้วจริง ไม่ใช่เขียนไว้เฉยๆ
• steady-state Unknown = 0 ก่อนเปิด enforcement
• ทดสอบ rolling upgrade ว่า envelope รุ่นเก่าไม่ถูกตีความเป็น Clear
• load test เส้น resolve-session ตอน cache miss ผ่านก่อน go-live

7. สิ่งที่ยังไม่มีคำตอบและกระทบแผน