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

```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