# Phase 0 – Architecture Audit ## Part 1 – Context, Current Status & Audit Foundation > **Project:** Training Management System (TMS) > > **Phase:** Phase 0 – Architecture Audit > > **Objective:** Validate Architecture Readiness Before Permission-first Migration --- # Background ระบบ Training Management System (TMS) กำลังอยู่ในช่วงเปลี่ยนผ่านจาก **Role-based Authorization** ไปสู่ **Permission-first Authorization Architecture** ในปัจจุบัน ระบบมี Foundation สำหรับ Permission-first แล้วบางส่วน แต่ยังอยู่ใน **Compatibility Mode** หมายความว่า Feature หลายส่วนของระบบยังคงใช้แนวคิดเดิม เช่น - `businessRole` - `membership.role` - `systemRole` - `isHRD()` - `isIT()` - `requireHRD()` - `requireIT()` ขณะที่ Foundation ใหม่เริ่มถูกสร้างแล้ว เช่น - Permission Catalog - Permission Helpers - Effective Permission Resolver - Session Permission Resolution - Permission Template Schema - Permission Assignment Schema - Permission Override Schema ดังนั้น เป้าหมายของ Phase นี้คือ > **ตรวจสอบความพร้อมของ Foundation ทั้งหมดก่อนเริ่ม Migration ของ Feature** --- # Current Project Status สถานะปัจจุบันของระบบโดยสรุป ## Completed Foundation ที่มีอยู่แล้ว - Central Permission Catalog - Authorization Helper - Session Permission Resolver - Effective Permission Resolution - Database Schema สำหรับ Permission Template - Permission Assignment - Permission Override - Permission Audit Log - Compatibility Layer สำหรับระบบเดิม ## In Progress อยู่ระหว่าง Migration - Navigation - Page Guard - Route Handlers - Feature Authorization - Permission Template Service - Assignment Service ## Not Started ยังไม่มีการพัฒนา - Permission Template Administration UI - User Permission Assignment UI - Permission Override UI - Effective Permission Viewer - Compatibility Cleanup - Legacy Removal --- # Purpose Of Phase 0 Phase นี้มีหน้าที่เพียงอย่างเดียวคือ > **Audit + Validate + Assess + Report** ไม่ใช่ > Refactor ไม่ใช่ > Rewrite ไม่ใช่ > Feature Development --- # Expected Outcome เมื่อจบ Phase นี้ ทีมพัฒนาต้องสามารถตอบคำถามต่อไปนี้ได้อย่างชัดเจน - Foundation พร้อมหรือไม่ - Permission Model สมบูรณ์หรือไม่ - Session สามารถใช้เป็น Source of Truth ได้หรือไม่ - Effective Permission ถูกต้องหรือไม่ - Multi-Organization พร้อมหรือไม่ - Compatibility Layer เพียงพอหรือไม่ - Feature ใดสามารถเริ่ม Migration ได้ก่อน - Feature ใดมีความเสี่ยงสูง - มี Technical Debt อะไรค้างอยู่ - มี Architecture Smell หรือไม่ --- # Architecture Direction Architecture ใหม่ของระบบต้องยึดตามโครงสร้างนี้ ```text Organization │ ▼ Permission Template │ ▼ Template Permissions │ ▼ User Template Assignment │ ▼ User Permission Override │ ▼ Effective Permissions │ ▼ Authorization Helpers │ ▼ API / Server │ ▼ Page Guard │ ▼ Navigation │ ▼ UI Visibility ``` ทุก Feature ใหม่ ต้องอ้างอิง Architecture นี้เท่านั้น --- # Source Of Truth ภายหลังการ Migration Source Of Truth ต้องมีเพียงชุดเดียว ```text Effective Permissions ``` ระบบทั้งหมด ห้ามตรวจสอบสิทธิ์จาก - businessRole - membership.role - systemRole - isHRD() - isIT() โดยตรงอีก Field เหล่านี้สามารถมีอยู่ได้ แต่มีไว้เพื่อ Compatibility เท่านั้น --- # Scope Of Audit Phase นี้ต้องตรวจสอบทุก Layer ของระบบ ประกอบด้วย ## Architecture Layer - Authorization Architecture - Permission Architecture - Session Architecture - Organization Architecture ## Database Layer - Schema - Migration - Foreign Keys - Indexes - Constraints ## Backend Layer - Auth - Session - Permission Helpers - Route Handlers - Services ## Frontend Layer - Navigation - Page Guards - Feature Visibility - Permission Context ## Security Layer - Authorization - Privilege Escalation - Cross Organization Access - Permission Leak ## Performance Layer - Permission Resolution - Database Query - Cache - Session Size --- # Audit Philosophy การตรวจสอบครั้งนี้ ห้ามเริ่มจาก > "จะเปลี่ยนอะไร" แต่ต้องเริ่มจาก > "ระบบปัจจุบันทำอะไรอยู่" ก่อน หลังจากนั้น จึงประเมินว่า - สิ่งใดใช้ต่อได้ - สิ่งใดต้อง Refactor - สิ่งใดควรลบ - สิ่งใดควรสร้างใหม่ ห้ามสร้าง Component Helper Service หรือ Model ใหม่ หากของเดิมสามารถ Reuse ได้ --- # Audit Principles การตรวจสอบทุกหัวข้อ ต้องยึดหลัก ## Reuse First ตรวจสอบของเดิมก่อน ห้ามสร้างใหม่ทันที --- ## Evidence Based ห้ามคาดเดา ทุกข้อสรุปต้องอ้างอิงจากโค้ดจริง --- ## Compatibility First ห้ามเสนอแนวทาง ที่ทำให้ระบบเดิมใช้งานไม่ได้ --- ## Incremental Migration ทุก Feature ต้องสามารถย้ายทีละส่วนได้ โดยไม่ต้อง Rewrite ทั้งระบบ --- ## Security First UI ไม่ใช่ Security Authorization ต้องตรวจที่ Server เสมอ --- ## Single Source Of Truth Effective Permissions คือแหล่งข้อมูลสิทธิ์เพียงชุดเดียว ทุก Layer ต้องอ้างอิงจากข้อมูลชุดเดียวกัน --- # Important Rules Phase นี้ ห้ามทำสิ่งต่อไปนี้ - ห้าม Refactor Feature - ห้ามแก้ Business Logic - ห้ามแก้ Workflow - ห้ามเพิ่ม Feature ใหม่ - ห้ามเปลี่ยน Database Schema - ห้ามลบ Legacy Code - ห้ามลบ businessRole - ห้ามลบ membership.role - ห้ามลบ isHRD() - ห้ามลบ isIT() - ห้ามลบ requireHRD() - ห้ามลบ requireIT() หากพบปัญหา ให้บันทึกไว้ในรายงาน ห้ามแก้ไขทันที --- # End Of Section A หลังจบ Section นี้ ให้รอ Section B ก่อนดำเนินการตรวจสอบเชิงลึกต่อ # Phase 0 – Architecture Audit ## Part 1 – Section B ### Audit Objectives, Repository Inspection Strategy & Readiness Assessment > **Objective** > > กำหนดมาตรฐานการตรวจสอบ (Audit Standard) เพื่อประเมินว่าโปรเจกต์มีความพร้อมสำหรับการ Migration ไปสู่ Permission-first Architecture หรือไม่ --- # Primary Objectives Phase 0 มีเป้าหมายหลักเพียงข้อเดียว > **ยืนยันว่า Foundation ของระบบมีความถูกต้อง แข็งแรง และพร้อมสำหรับการ Migration ใน Phase ถัดไป** Codex ต้องไม่เริ่มจากการแก้ไขโค้ด แต่ต้องตอบคำถามต่อไปนี้ให้ได้ก่อน - Foundation พร้อมหรือยัง - โครงสร้างปัจจุบันมีข้อขัดแย้งกับ Permission-first หรือไม่ - มีส่วนใดที่สามารถ Reuse ได้ - มีส่วนใดที่ควร Refactor - มีส่วนใดที่ควรเลิกใช้ (Deprecated) - มีส่วนใดที่ยังขาดอยู่ - หากเริ่ม Migration ตอนนี้ จะมีความเสี่ยงอะไรบ้าง --- # Audit Strategy การตรวจสอบต้องทำจาก "แกนกลาง" ออกไปยัง Feature ลำดับการตรวจต้องเป็นดังนี้ ```text Architecture ↓ Database ↓ Authentication ↓ Authorization ↓ Session ↓ Permission Resolution ↓ Navigation ↓ Page Guard ↓ API ↓ Feature Server ↓ Feature UI ↓ Reports ``` ห้ามเริ่มตรวจจากหน้า UI ก่อน เนื่องจาก UI ไม่ใช่ Source of Truth --- # Repository Inspection Rules ก่อนวิเคราะห์หรือเสนอแนวทางใด ๆ ต้องตรวจสอบ Repository จริงก่อนเสมอ ห้ามสมมติว่า - มี Service - มี Helper - มี Component - มี Hook - มี Model หากยังไม่ได้ตรวจสอบ --- ## Required Inspection ทุก Layer ต้องตรวจอย่างน้อย ### Database - Schema - Enum - Tables - Foreign Keys - Constraints - Migration Files - Seed Strategy --- ### Authentication - auth.ts - session callback - JWT callback - next-auth types - organization context --- ### Authorization - permissions.ts - authorization.ts - roles.ts - session.ts --- ### Navigation - nav-config.ts - use-nav.ts - sidebar - menu visibility --- ### Page Guard - dashboard guards - route guards - middleware --- ### API ทุก Route ต้องตรวจว่า ใช้ ```text requirePermission() หรือ requireHRD() หรือ isHRD() ``` --- ### Feature Layer ตรวจทุก Module เช่น - Announcements - Online Lessons - Training Records - Reports - Employee Directory - Courses - Users - Notifications --- # Architecture Validation Matrix ทุก Layer ต้องถูกประเมินด้วยเกณฑ์เดียวกัน | Category | ตรวจสอบ | | -------------- | --------------------------------- | | Responsibility | Layer นี้มีหน้าที่ชัดเจนหรือไม่ | | Coupling | พึ่งพา Layer อื่นมากเกินไปหรือไม่ | | Duplication | Logic ซ้ำหรือไม่ | | Compatibility | รองรับ Migration หรือไม่ | | Extensibility | เพิ่ม Feature ใหม่ได้ง่ายหรือไม่ | | Testability | ทดสอบได้ง่ายหรือไม่ | | Security | มีช่องโหว่หรือไม่ | | Performance | มี Bottleneck หรือไม่ | --- # Readiness Assessment ทุกหัวข้อ ต้องให้คะแนน ```text READY PARTIAL NOT READY ``` พร้อมเหตุผล ตัวอย่าง ```text Permission Catalog Status READY Reason Permission ถูก Centralized แล้ว ``` หรือ ```text Navigation Status PARTIAL Reason รองรับ Permission Metadata แล้ว แต่ยังใช้ businessRole เป็น fallback ``` --- # Audit Categories การตรวจสอบต้องแบ่งออกเป็น ## Foundation - Permission Catalog - Session - Schema - Effective Permission - Organization --- ## Compatibility - businessRole - membership.role - systemRole - Legacy Helpers --- ## Feature แต่ละ Feature ต้องประเมินแยก - Ready - Partial - Not Ready --- ## Security ตรวจสอบ - Privilege Escalation - Missing Permission Checks - Direct URL Access - Organization Isolation - Data Leakage --- ## Performance ตรวจสอบ - Permission Resolution - Duplicate Queries - Session Payload - N+1 Queries - Cache Opportunities --- ## Maintainability ตรวจสอบ - Code Duplication - Service Separation - Helper Reuse - Naming Consistency - Folder Structure --- # Discovery Strategy ห้ามเริ่มจากการค้นหาเฉพาะไฟล์ที่คิดว่าสำคัญ ให้สำรวจระบบทั้งหมดก่อน ตัวอย่าง ```text Auth ↓ Session ↓ Permissions ↓ Navigation ↓ Page Guard ↓ API ↓ Services ↓ UI ``` ทุกขั้นตอน ต้องบันทึก - สิ่งที่พบ - สิ่งที่ขาด - สิ่งที่ซ้ำ - สิ่งที่ควรปรับ --- # Required Evidence ทุกข้อสรุป ต้องมีหลักฐาน เช่น - File - Function - Helper - Component - Route - Service ห้ามเขียนว่า > "น่าจะ" > "คาดว่า" > "อาจจะ" หากไม่มีหลักฐาน ให้ระบุว่า ```text Not Verified ``` --- # Audit Deliverables (Section B) เมื่อจบการตรวจสอบใน Section นี้ Codex ต้องสามารถสร้างรายการต่อไปนี้ได้ - Architecture Validation Matrix - Readiness Matrix - Foundation Checklist - Compatibility Checklist - Repository Inspection Summary - Code Discovery Summary เอกสารเหล่านี้จะถูกนำไปใช้ต่อใน - Phase 0 Part 2 - Phase 0 Part 3 - Phase 0 Part 4 และเป็นพื้นฐานสำหรับ Phase 1 --- # End Of Section B ห้ามเริ่ม Refactor จนกว่าจะผ่านการตรวจสอบทั้งหมดใน Phase 0 # Phase 0 – Architecture Audit ## Part 1 – Section C ### Enterprise Architecture Principles, Validation Rules & Anti-Pattern Detection > **Objective** > > กำหนดหลักการ (Architecture Principles) และกฎการตรวจสอบ (Validation Rules) สำหรับการย้ายระบบไปสู่ Permission-first Architecture โดยไม่สร้าง Technical Debt เพิ่ม --- # Enterprise Architecture Principles ทุกการวิเคราะห์และข้อเสนอแนะในโปรเจกต์นี้ ต้องยึดหลักการต่อไปนี้ --- ## Principle 1 — Permission First Permission คือ Source of Truth เพียงหนึ่งเดียวของระบบ ทุกการตรวจสอบสิทธิ์ ไม่ว่าจะอยู่ที่ - API - Route Handler - Server Action - Feature Service - Page Guard - Navigation - UI Visibility ต้องอ้างอิงจาก Effective Permissions เท่านั้น ห้ามตรวจสอบสิทธิ์จาก - businessRole - membership.role - systemRole โดยตรง Role มีไว้เพื่อช่วย Migration เท่านั้น --- ## Principle 2 — Effective Permission Is The Truth Permission จริงของผู้ใช้งาน ต้องคำนวณจาก ```text Permission Template + Allow Override - Deny Override = Effective Permissions ``` ห้ามให้แต่ละ Feature คำนวณ Permission เอง ต้องใช้ Logic กลางเพียงชุดเดียว --- ## Principle 3 — Server Owns Authorization Server คือเจ้าของการตัดสินใจเรื่องสิทธิ์ UI มีหน้าที่เพียง - ซ่อน - แสดง เท่านั้น ห้ามเชื่อถือ UI ทุก API ต้องตรวจ Permission ซ้ำเสมอ --- ## Principle 4 — Single Permission Engine ระบบต้องมี Permission Engine เพียงหนึ่งเดียว ทุกส่วนของระบบ ต้องเรียกใช้ Engine นี้ ห้ามมี Permission Logic ซ้ำหลายที่ --- ## Principle 5 — Organization Isolation ทุก Permission ต้องอยู่ภายใต้ Organization Context เสมอ ห้ามเกิดกรณี ```text User A Organization A ↓ เข้าถึงข้อมูล Organization B ``` โดยไม่ได้รับอนุญาต --- ## Principle 6 — Incremental Migration ทุก Feature ต้องสามารถย้ายทีละ Module ได้ โดยไม่ทำให้ Module อื่นเสีย --- ## Principle 7 — Backward Compatibility Compatibility Layer สามารถมีได้ แต่ ห้ามเป็น Source of Truth --- # Permission-first Validation Rules Codex ต้องตรวจสอบว่า ทุก Layer ใช้ Effective Permission จริงหรือไม่ Checklist ```text Permission ↓ Session ↓ Permission Engine ↓ API ↓ Feature ↓ Navigation ↓ UI ``` หากพบ Role เข้ามาเป็นตัวตัดสิน ให้บันทึกเป็น Architecture Finding --- # Architecture Validation Rules ตรวจสอบทุก Layer ด้วยกฎเดียวกัน --- ## Rule 1 Business Logic ต้องอยู่ Server ไม่ใช่ UI --- ## Rule 2 Authorization ต้องอยู่ Server ไม่ใช่ Hook --- ## Rule 3 Permission ต้อง Resolve เพียงครั้งเดียว ไม่ใช่ทุก Feature --- ## Rule 4 ทุก Module ต้องใช้ Permission Helper ชุดเดียวกัน --- ## Rule 5 ทุก Query ต้องมี Organization Scope --- ## Rule 6 ทุก Feature ต้องรองรับ Permission Override โดยไม่ต้องเขียน Logic เพิ่ม --- # Anti-Pattern Detection Codex ต้องค้นหา Architecture Smell ต่อไปนี้ --- ## Role Leak เช่น ```ts if (businessRole === "HRD") ``` หรือ ```ts if (isHRD()) ``` --- ## Permission Leak เช่น Permission ถูกตรวจ เฉพาะ UI --- ## Organization Leak เช่น Query ไม่มี organization_id --- ## Duplicate Authorization เช่น Feature A เขียน Permission Logic เอง Feature B เขียนใหม่อีกชุด --- ## Duplicate Permission Mapping เช่น Announcement มี Mapping คนละชุด กับ Online Lesson --- ## Feature-specific Permission Resolver เช่น Announcement Resolve Permission เอง แทนที่จะใช้ Permission Engine --- ## Session Leak เช่น Session มีข้อมูล Permission ไม่ตรงกับ Database --- ## Direct Role Dependency เช่น Navigation ตรวจ businessRole โดยตรง --- ## UI Trust เช่น ซ่อนปุ่ม แต่ API ไม่ตรวจ Permission --- ## Cross Organization Access เช่น ไม่มี Organization Context ใน Query --- # Permission Dependency Validation Codex ต้องตรวจสอบว่า Permission สัมพันธ์กันถูกต้องหรือไม่ ตัวอย่าง ```text announcement:publish ``` ควรมี ```text announcement:read_all ``` ก่อน หรือ ```text training_record:approve ``` ควรมี ```text training_record:review ``` หากพบ Permission ที่ขาด Dependency ให้บันทึก เป็น Finding --- # Reuse Validation ก่อนเสนอ สร้าง Service Component Hook Repository Helper ใหม่ Codex ต้องตรวจสอบว่า ของเดิม สามารถ Reuse ได้หรือไม่ หากสร้างใหม่ ต้องอธิบายเหตุผล ทุกครั้ง --- # Naming Validation ตรวจสอบ Naming Convention ทั้งหมด เช่น Permission ต้องเป็น ```text module:action ``` ตัวอย่าง ```text announcement:create announcement:publish online_lesson:approve ``` ห้ามมี Pattern หลายแบบ ในระบบเดียวกัน --- # Layer Responsibility Validation แต่ละ Layer ต้องมีหน้าที่ชัดเจน | Layer | Responsibility | | -------------------- | ---------------------------- | | Database | Data Storage | | Permission Engine | Resolve Effective Permission | | Authorization Helper | Permission Validation | | API | Business Authorization | | Service | Business Logic | | Navigation | Menu Visibility | | UI | Presentation | ห้าม Business Logic หลุดไปอยู่ UI --- # Architecture Smell Severity ทุก Finding ต้องถูกจัดระดับ ```text Critical High Medium Low Information ``` พร้อมเหตุผล และ ผลกระทบ --- # Required Outputs หลังจบ Section นี้ Codex ต้องสามารถสร้าง - Architecture Principles Validation - Anti-Pattern Report - Architecture Smell Report - Layer Responsibility Report - Permission Dependency Report - Reuse Opportunity Report ทั้งหมดจะถูกใช้ต่อ ใน Phase 0 Part 2 --- # End Of Section C ห้ามเสนอการ Refactor จนกว่าจะตรวจครบทุก Rule ใน Section นี้ # Phase 0 – Architecture Audit ## Part 1 – Section D ### Deliverables, Reporting Standards, Readiness Assessment & Exit Criteria > **Objective** > > กำหนดผลลัพธ์ (Deliverables) ที่ Codex ต้องจัดทำหลังจากตรวจสอบระบบเสร็จ รวมถึงมาตรฐานการจัดทำรายงาน การประเมินความพร้อม (Readiness Assessment) และเกณฑ์การอนุมัติให้เข้าสู่ Phase 1 --- # Deliverables เมื่อจบ Phase 0 Codex ต้องสร้างเอกสารในโฟลเดอร์ ```text docs/architecture-audit/ ``` ประกอบด้วยเอกสารอย่างน้อยดังต่อไปนี้ ```text phase-0-architecture-audit.md phase-0-readiness-report.md phase-0-risk-register.md phase-0-migration-checklist.md phase-0-architecture-findings.md phase-0-technical-debt.md phase-0-next-phase-plan.md ``` ห้ามรวมทุกอย่างไว้ในไฟล์เดียว แต่ละเอกสารต้องมีวัตถุประสงค์ชัดเจน --- # Architecture Audit Report รายงานหลักของ Phase 0 ต้องประกอบด้วย ## Executive Summary สรุปภาพรวม - สถานะปัจจุบัน - จุดแข็ง - จุดอ่อน - ความพร้อม - ความเสี่ยง - คำแนะนำ --- ## Current Architecture อธิบาย Architecture ปัจจุบัน พร้อม Diagram เช่น ```text Authentication ↓ Session ↓ Permission Resolution ↓ API ↓ Feature ↓ Navigation ↓ UI ``` --- ## Findings สรุปสิ่งที่พบ แบ่งตาม - Critical - High - Medium - Low พร้อม - File - Module - Description - Impact - Recommendation --- ## Reuse Opportunities สรุป Service Helper Component ที่สามารถ Reuse ได้ --- ## Technical Debt สรุป Legacy Code Code Duplication Architecture Smell Dependency ที่ยังเหลือ --- # Readiness Report รายงานนี้ มีหน้าที่ตอบเพียงคำถามเดียว ```text ระบบพร้อมเข้าสู่ Phase 1 หรือไม่ ``` ต้องแบ่งเป็นหมวด ตัวอย่าง | Category | Status | Score | Notes | | ------------------ | --------- | ----: | ------------------- | | Permission Catalog | READY | 100 | ครบถ้วน | | Session | READY | 95 | เหลือ Compatibility | | Navigation | PARTIAL | 60 | ยังใช้ businessRole | | Route Handler | NOT READY | 20 | ยังใช้ requireHRD | | Admin UI | NOT READY | 0 | ยังไม่มี | --- # Readiness Levels ใช้ระดับดังนี้ ```text READY PARTIAL NOT READY ``` พร้อมคะแนน ```text 0 - 100 ``` เกณฑ์ ```text 90-100 Production Ready 70-89 Ready For Migration 40-69 Need Improvement 0-39 Not Ready ``` --- # Risk Register ทุก Risk ต้องมี | Field | Description | | -------------- | ------------------------------ | | Risk ID | รหัส | | Severity | Critical / High / Medium / Low | | Probability | High / Medium / Low | | Impact | Business Impact | | Recommendation | วิธีลดความเสี่ยง | | Owner | ผู้รับผิดชอบ | | Phase | ควรแก้ในเฟสใด | ตัวอย่าง ```text R-001 Legacy businessRole High ควรลบใน Phase 4 ``` --- # Migration Checklist สร้าง Checklist ที่สามารถใช้จริง ในทุก Phase ตัวอย่าง ```text Permission Engine ☑ Template Service ☑ Navigation ☐ Announcement ☐ Online Lesson ☐ Training Record ☐ Admin UI ☐ Cleanup ☐ ``` --- # Architecture Scorecard ประเมินแต่ละหัวข้อ | Category | Score | | ------------------ | ----: | | Architecture | | | Security | | | Authorization | | | Session | | | Performance | | | Maintainability | | | Scalability | | | Multi Organization | | | Compatibility | | | Testability | | พร้อม คะแนนรวม --- # Documentation Standards ทุกเอกสาร ต้องมี ## Summary ## Findings ## Evidence ## Recommendation ## Impact ## Next Step ห้ามมีเพียง ความคิดเห็น โดยไม่มีหลักฐาน --- # Evidence Requirements ทุก Finding ต้องอ้างอิง - File - Function - Component - Route - Helper - Service ตัวอย่าง ```text File src/lib/auth/session.ts Function requirePermission() Finding ยังมี fallback ไป businessRole ``` ห้ามเขียน ```text น่าจะ อาจจะ คาดว่า ``` --- # Recommendation Standards ทุก Recommendation ต้องจัดลำดับ ```text Immediate Short Term Medium Term Long Term ``` พร้อมเหตุผล --- # Phase Gate ก่อนเข้าสู่ Phase 1 ต้องตรวจสอบว่า ## Permission Catalog READY --- ## Effective Permission Resolver READY --- ## Session READY --- ## Schema READY --- ## Compatibility Layer PARTIAL หรือ READY --- ## Critical Issues ต้องไม่มี --- ## High Severity ต้องมีแผนแก้ --- ## Documentation ครบทุกไฟล์ --- # Exit Criteria Phase 0 ถือว่าเสร็จ เมื่อ - Audit ครบทุก Layer - ตรวจ Repository ครบทุก Module - Architecture Validation ผ่าน - Security Review ผ่าน - Compatibility Review ผ่าน - Readiness Report เสร็จ - Risk Register เสร็จ - Migration Checklist เสร็จ - Technical Debt Report เสร็จ - Next Phase Plan เสร็จ หากเงื่อนไขใดไม่ผ่าน ห้ามเริ่ม Phase 1 --- # Definition Of Done Phase 0 จะถือว่าเสร็จสมบูรณ์ เมื่อสามารถตอบคำถามต่อไปนี้ได้ทั้งหมด - Foundation พร้อมหรือไม่ - Permission-first Model ถูกต้องหรือไม่ - Effective Permission เป็น Source Of Truth จริงหรือไม่ - Organization Isolation เพียงพอหรือไม่ - Feature ใดพร้อม Migration ก่อน - Feature ใดมีความเสี่ยง - Legacy ส่วนใดยังจำเป็น - Legacy ส่วนใดสามารถลบได้ในอนาคต - Architecture มี Technical Debt อะไร - ระบบพร้อมเข้าสู่ Phase 1 หรือยัง --- # Next Phase Handover เมื่อจบ Phase 0 ให้สร้างเอกสาร ```text docs/architecture-audit/phase-0-next-phase-plan.md ``` โดยระบุ ## Recommended Phase Order ```text Phase 1 Permission Core Architecture ↓ Phase 2 Feature Authorization Migration ↓ Phase 3 Permission Administration ↓ Phase 4 Compatibility Cleanup ``` พร้อม - Dependencies - Risks - Estimated Complexity - Expected Deliverables เพื่อใช้เป็นเอกสารอ้างอิงของทุกเฟสถัดไป --- # End Of Part 1 เมื่อ Part 1 เสร็จ ห้ามเริ่ม Refactor ห้ามเริ่ม Feature Migration ห้ามแก้ไขโค้ด จนกว่าจะเข้าสู่ **Phase 0 – Part 2 (Codebase Architecture Audit)** ซึ่งจะเป็นการตรวจสอบ Repository จริงแบบ File-by-File และ Module-by-Module โดยอ้างอิงหลักการทั้งหมดจาก Part 1