Private Docs

Meeting Resolution Checklist

ใบบันทึกข้อสรุปประจำห้องประชุม — ไล่ทีละวาระ 0-8 พร้อมช่องติ๊กสถานะและตาราง action items

อัปเดต: 2026-07-07

MEETING RESOLUTION CHECKLIST — ใบบันทึกข้อสรุปประจำห้องประชุม

วันที่ประชุม: ________ · ผู้จด: ________ · สถานะ: 🔲 ยังไม่ประชุม วิธีใช้: เอกสารนี้คือ “ใบงาน” ที่เปิดค้างไว้ระหว่างประชุม — ไล่ทีละวาระ ติ๊กสถานะ เขียนข้อสรุปในช่อง แล้วเก็บ action item ลงตารางท้ายเอกสาร · การเลือก option ให้จดที่ DECISION_REGISTER.md (อ้างเลข A1-F3) — เล่มนี้จดทุกอย่างที่เหลือ: ความเข้าใจร่วม, เงื่อนไข, ข้อโต้แย้งที่ยังค้าง

สัญลักษณ์สถานะ: ✅ ตกลงแล้ว · 🔁 หารือต่อ (นัดใหม่/ขอข้อมูลเพิ่ม) · ⏸ parked (จงใจเลื่อน — ระบุเงื่อนไข revisit) · ❌ ปฏิเสธ (ระบุเหตุผล)


ก่อนเริ่มประชุม (5 นาที)

  • ผู้เข้าประชุมมีอำนาจตัดสินใจครบ 4 ฝั่ง: dev lead · infra/ops · product owner · compliance/DPO — ถ้าขาดฝั่งไหน ให้ mark decision ของฝั่งนั้นเป็น 🔁 ตั้งแต่ต้น อย่าตัดสินแทน
  • ทุกคนได้ MEETING_BRIEF.md ก่อนเข้าห้อง
  • ตกลง timebox: วาระ 0 ต้องจบภายใน ___ นาที (สำคัญสุด — อย่าให้วาระอื่นเบียด)

วาระ 0 — Stop the Bleeding (PLAN 00) — ต้องจบวันนี้

สถานะประเด็นข้อสรุปที่ตกลงกัน
🔲รับทราบ: credential รั่วใน git ถือว่า compromised — ต้อง rotate ไม่ใช่แค่ลบ
🔲ใคร coordinate rotate กับ EXIM admin / DGA + เริ่มเมื่อไหร่ชื่อ: ________ วันเริ่ม: ________
🔲DiagnosticsController: ลบ endpoint ทิ้ง หรือย้าย KV + ติด auth (ข้อเสนอ: ลบ)
🔲Dev-bypass: ยืนยัน prerequisite — dev cluster มี token จริงใช้ (Entra test users พร้อมไหม)
🔲วัน cutover ปิด bypass ต่อ service (ทีละตัว ห้ามพร้อมกัน)
🔲FE Phase 0: F1 (report token ใน localStorage) + F5 (sanitize default) — approve แก้ทันที

วาระ 1 — ขอบเขต 3 requirement ใหม่ (หัวใจของ meeting นี้)

สถานะประเด็นข้อสรุปที่ตกลงกัน
🔲Body signature: scope = external/S2S เท่านั้น หรือรวม browser (→ register B1, B2)
🔲ถ้าผู้ตรวจต้องการครอบ browser: ใครเป็นคนไปเจรจา/ขอ requirement เป็นลายลักษณ์อักษรชื่อ: ________
🔲Encryption field: เข้าใจตรงกันว่า BE→FE ไม่เข้ารหัส ใช้ minimization+mask แทน (เหตุผล: security theater)
🔲field P0 ชุดแรกที่จะ encrypt (ระหว่างรอ inventory เต็ม) — เลขบัตร? KYC docs? (→ B4/E1)
🔲Subscription key: granularity + ยอมรับเห็นใน devtools (→ C2, C3)
🔲ลำดับ enforce: observe mode → monitor → บังคับ — ใครดู dashboard ช่วง observeชื่อ: ________

วาระ 2 — Client / Frontend (PLAN 10)

สถานะประเด็นข้อสรุปที่ตกลงกัน
🔲Runtime config (config.json) แทน build-per-env — approve แนวทาง
🔲Findings F2-F4, F7 (MSAL localStorage, console.log PII, README) — เข้า backlog Phase 1 พร้อม ownerชื่อ: ________
🔲Report client: รับหลักการ “backend คุม dataset — client render อย่างเดียว — ไม่ trust ค่าวนกลับ”
🔲Report ที่เป็นหลักฐานทางธุรกิจ → server-side PDF/hash — list ตัวไหนบ้าง (→ E4)
🔲MSAL → sessionStorage (T6): PO รับ trade-off เปิด tab ใหม่ต้อง silent re-auth

วาระ 3 — Backend Hardening (PLAN 05 — จุดคานงัด)

สถานะประเด็นข้อสรุปที่ตกลงกัน
🔲Owner ของ Backend_Package (คนเดียว ชัดเจน — ทุกอย่างพึ่งตัวนี้)ชื่อ: ________
🔲Approve ลำดับ rollout: UserService → Template → Sentinel → ที่เหลือ + timeline ต่อ service
🔲ThirdPartyFX + Workflow ต้อง port auth ก่อน (Step 0) — ใครทำชื่อ: ________
🔲รับทราบความเสี่ยง FallbackPolicy rollout (probe 401) + ลำดับ 5 step ที่ห้ามสลับ

วาระ 4 — Session / Token (PLAN 04)

สถานะประเด็นข้อสรุปที่ตกลงกัน
🔲Session TTL (→ C1) — PO ต้องอยู่ในห้องตอนตัดสิน + วิธีสื่อสาร useridle: ___ / absolute: ___ / RememberMe: ___
🔲H2 token encryption: เลือก invalidate ทุก session (T2) — นัด maintenance windowวันที่: ________
🔲H3 InternalOnly gate: ใคร verify ค่า env จริง + เพิ่ม fail-fastชื่อ: ________

วาระ 5 — CI Security (PLAN 01)

สถานะประเด็นข้อสรุปที่ตกลงกัน
🔲Gitleaks + regression gates เริ่มทันที (ฟรี ไม่รอ infra) — approve
🔲งบ + คนดูแล SonarQube/DT (→ D2) — approve / เลื่อนถึงวันที่
🔲Gate policy ต่อ phase (→ D1) + exception process มี expiry
🔲BOT tool-acceptability (→ D3): บันทึกความเสี่ยง + ใครไปขอ confirmชื่อ: ________

วาระ 6 — Secrets / Redis / PDPA / Infra (PLAN 06/07/08/09)

สถานะประเด็นข้อสรุปที่ตกลงกัน
🔲Purge git history: approve force-push repo ไหนบ้าง + นัด window (→ F3, T5)repos: ________ วันที่: ________
🔲Rotation cadence ตามตาราง 6.3 + ตั้ง expiry ทุก secret ทันที
🔲Redis: แยก instance หรือ DB index+ACL ก่อน (ข้อเสนอ: อย่างหลัง)
🔲PII inventory: เริ่ม UserService — ใครทำ + deadlineชื่อ: ________ due: ________
🔲ShowPII fix (SIT/UAT เสี่ยงอยู่ตอนนี้) — จัดเป็น quick win ใน Phase 1
🔲Log retention 90 วัน + WORM: รับค่าใช้จ่าย (→ COST §2)
🔲ForwardedHeaders ต้องทำคู่ rate limiter ใน Phase 1 (ไม่ใช่ Phase 3) — รับทราบ

วาระ 7 — Trade-offs Sign-off (COST §4)

สถานะTrade-offผู้ accept (ชื่อ)
🔲T1 idle timeout 30 นาที
🔲T2 invalidate ทุก session 1 ครั้ง
🔲T3 dev ใช้ token จริงบน dev
🔲T4 CI gate blocking
🔲T5 force-push หลัง purge
🔲T6-T10 (รับทราบรวม — รายละเอียดใน COST §4)

วาระ 8 — ของที่จงใจไม่ทำ (COST §5)

สถานะประเด็นข้อสรุปที่ตกลงกัน
🔲รับทราบ list “แพงเกินคุ้มตอนนี้” (mTLS, JWE, session-bound key, Worker, Roslyn) + เงื่อนไข revisit
🔲นัด review รอบ 6 เดือน — ใส่ calendar เลยวันที่: ________

ปิดประชุม (10 นาทีสุดท้าย — ห้ามข้าม)

  • ทวนมติ: ไล่ DECISION_REGISTER เฉพาะแถว ❗ ทั้ง 8 — ทุกตัวมีคำตอบหรือมีวันนัดตอบ
  • ไล่ตาราง action items ด้านล่าง — ทุกแถวมี owner + due date
  • ประเด็น 🔁 ทั้งหมด: นัดวันหารือต่อ + ระบุข้อมูลที่ต้องหามาเพิ่ม
  • ใครส่ง minutes + ภายในเมื่อไหร่: ชื่อ ________ ภายใน ________
  • นัด checkpoint ถัดไป (เสนอ: 2 สัปดาห์ — review Phase 0 เสร็จ): วันที่ ________

📋 Action Items (เติมระหว่างประชุม)

#ActionOwnerDueอ้างอิงวาระ/Decision
1
2
3
4
5
6
7
8

🔁 ประเด็นค้าง (หารือต่อ)

#ประเด็นข้อมูลที่ต้องหาเพิ่มใครหานัดหารือต่อ
1
2
3