alla-tms/plans/phase-0-architecture-audit-part-1.md

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 ใหม่ของระบบต้องยึดตามโครงสร้างนี้

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 ต้องมีเพียงชุดเดียว

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

ลำดับการตรวจต้องเป็นดังนี้

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

ต้องตรวจว่า

ใช้

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

ทุกหัวข้อ

ต้องให้คะแนน

READY

PARTIAL

NOT READY

พร้อมเหตุผล

ตัวอย่าง

Permission Catalog

Status

READY

Reason

Permission ถูก Centralized แล้ว

หรือ

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

ห้ามเริ่มจากการค้นหาเฉพาะไฟล์ที่คิดว่าสำคัญ

ให้สำรวจระบบทั้งหมดก่อน

ตัวอย่าง

Auth

↓

Session

↓

Permissions

↓

Navigation

↓

Page Guard

↓

API

↓

Services

↓

UI

ทุกขั้นตอน

ต้องบันทึก

• สิ่งที่พบ
• สิ่งที่ขาด
• สิ่งที่ซ้ำ
• สิ่งที่ควรปรับ

---

Required Evidence

ทุกข้อสรุป

ต้องมีหลักฐาน

เช่น

• File
• Function
• Helper
• Component
• Route
• Service

ห้ามเขียนว่า

"น่าจะ"

"คาดว่า"

"อาจจะ"

หากไม่มีหลักฐาน

ให้ระบุว่า

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 จริงของผู้ใช้งาน

ต้องคำนวณจาก

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

เสมอ

ห้ามเกิดกรณี

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

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

เช่น

if (businessRole === "HRD")

หรือ

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

สัมพันธ์กันถูกต้องหรือไม่

ตัวอย่าง

announcement:publish

ควรมี

announcement:read_all

ก่อน

หรือ

training_record:approve

ควรมี

training_record:review

หากพบ

Permission

ที่ขาด Dependency

ให้บันทึก

เป็น

Finding

---

Reuse Validation

ก่อนเสนอ

สร้าง

Service

Component

Hook

Repository

Helper

ใหม่

Codex

ต้องตรวจสอบว่า

ของเดิม

สามารถ Reuse

ได้หรือไม่

หากสร้างใหม่

ต้องอธิบายเหตุผล

ทุกครั้ง

---

Naming Validation

ตรวจสอบ

Naming Convention

ทั้งหมด

เช่น

Permission

ต้องเป็น

module:action

ตัวอย่าง

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

ต้องถูกจัดระดับ

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 ต้องสร้างเอกสารในโฟลเดอร์

docs/architecture-audit/

ประกอบด้วยเอกสารอย่างน้อยดังต่อไปนี้

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

เช่น

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

รายงานนี้

มีหน้าที่ตอบเพียงคำถามเดียว

ระบบพร้อมเข้าสู่ 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

ใช้ระดับดังนี้

READY

PARTIAL

NOT READY

พร้อมคะแนน

0 - 100

เกณฑ์

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	ควรแก้ในเฟสใด

ตัวอย่าง

R-001

Legacy businessRole

High

ควรลบใน Phase 4

---

Migration Checklist

สร้าง Checklist

ที่สามารถใช้จริง

ในทุก Phase

ตัวอย่าง

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

ตัวอย่าง

File

src/lib/auth/session.ts

Function

requirePermission()

Finding

ยังมี fallback ไป businessRole

ห้ามเขียน

น่าจะ

อาจจะ

คาดว่า

---

Recommendation Standards

ทุก Recommendation

ต้องจัดลำดับ

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

ให้สร้างเอกสาร

docs/architecture-audit/phase-0-next-phase-plan.md

โดยระบุ

Recommended Phase Order

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