260322:1648 Correct Coresspondence / Doing RFA / Correct CI

2026-03-22 16:48:12 +07:00
parent e5deedb42e
commit 11984bfa29
683 changed files with 105251 additions and 29068 deletions
@@ -126,15 +126,15 @@ graph TB

 ### Phase 1: Foundation (2-3 weeks)

-| ID                                             | Task                        | Priority | Effort   | Status        | Dependencies |
-| ---------------------------------------------- | --------------------------- | -------- | -------- | ------------- | ------------ |
+| ID                                             | Task                        | Priority | Effort   | Status         | Dependencies |
+| ---------------------------------------------- | --------------------------- | -------- | -------- | -------------- | ------------ |
 | [BE-001](TASK-BE-015-schema-v160-migration.md) | Database Setup & Migrations | P0       | 2-3 days | 🔴 Not Started | None         |
 | [BE-002](./TASK-BE-002-auth-rbac.md)           | Auth & RBAC Module          | P0       | 5-7 days | 🔴 Not Started | BE-001       |

 ### Phase 2: Core Infrastructure (3-4 weeks)

-| ID                                                | Task                       | Priority | Effort     | Status        | Dependencies   |
-| ------------------------------------------------- | -------------------------- | -------- | ---------- | ------------- | -------------- |
+| ID                                                | Task                       | Priority | Effort     | Status         | Dependencies   |
+| ------------------------------------------------- | -------------------------- | -------- | ---------- | -------------- | -------------- |
 | [BE-013](./TASK-BE-013-user-management.md)        | User Management            | P1       | 5-7 days   | 🔴 Not Started | BE-001, BE-002 |
 | [BE-012](./TASK-BE-012-master-data-management.md) | Master Data Management     | P1       | 6-8 days   | 🔴 Not Started | BE-001, BE-002 |
 | [BE-003](./TASK-BE-003-file-storage.md)           | File Storage (Two-Phase)   | P1       | 4-5 days   | 🔴 Not Started | BE-001, BE-002 |
@@ -143,23 +143,23 @@ graph TB

 ### Phase 3: Business Modules (4-5 weeks)

-| ID                                               | Task                  | Priority | Effort    | Status        | Dependencies                       |
-| ------------------------------------------------ | --------------------- | -------- | --------- | ------------- | ---------------------------------- |
+| ID                                               | Task                  | Priority | Effort    | Status         | Dependencies                       |
+| ------------------------------------------------ | --------------------- | -------- | --------- | -------------- | ---------------------------------- |
 | [BE-005](./TASK-BE-005-correspondence-module.md) | Correspondence Module | P1       | 7-10 days | 🔴 Not Started | BE-001~004, BE-006, BE-012, BE-013 |
 | [BE-007](./TASK-BE-007-rfa-module.md)            | RFA Module            | P1       | 8-12 days | 🔴 Not Started | BE-001~004, BE-006, BE-012, BE-013 |

 ### Phase 4: Supporting Modules (2-3 weeks)

-| ID                                                 | Task                      | Priority | Effort   | Status        | Dependencies               |
-| -------------------------------------------------- | ------------------------- | -------- | -------- | ------------- | -------------------------- |
+| ID                                                 | Task                      | Priority | Effort   | Status         | Dependencies               |
+| -------------------------------------------------- | ------------------------- | -------- | -------- | -------------- | -------------------------- |
 | [BE-008](./TASK-BE-008-drawing-module.md)          | Drawing Module            | P2       | 6-8 days | 🔴 Not Started | BE-001~004, BE-012         |
 | [BE-009](./TASK-BE-009-circulation-transmittal.md) | Circulation & Transmittal | P2       | 5-7 days | 🔴 Not Started | BE-001~003, BE-006, BE-012 |
 | [BE-010](./TASK-BE-010-search-elasticsearch.md)    | Search & Elasticsearch    | P2       | 4-6 days | 🔴 Not Started | BE-001, BE-005, BE-007     |

 ### Phase 5: Supporting Services (1 week)

-| ID                                            | Task                     | Priority | Effort   | Status        | Dependencies   |
-| --------------------------------------------- | ------------------------ | -------- | -------- | ------------- | -------------- |
+| ID                  | Task                     | Priority | Effort   | Status         | Dependencies   |
+| ------------------- | ------------------------ | -------- | -------- | -------------- | -------------- |
 | [BE-011](README.md) | Notification & Audit Log | P3       | 3-5 days | 🔴 Not Started | BE-001, BE-002 |

 ---
@@ -1,53 +1,60 @@
 # Refactoring Document Numbering เพิ่ม features ให้กับ Document Numbering เพื่อรองรับหลักการ Immutability, Audit Trail และ Advanced Operations
+
 Template Management ต้องคงหน้านี้ไว้ (ไม่มีการปรับปรุง)
+
 ## รายละเอียด
+
 ### 1. ปรับปรุง Logic การออกเลขให้เป็นแบบ Assign Once
-  * 1.1 ตรวจสอบให้แน่ใจว่า `generateNextNumber` จะถูกเรียกเฉพาะตอน Create (POST) เท่านั้น
-  * 1.2 ห้ามเรียกตอน Update (PATCH/PUT) ยกเว้นกรณีมีการเปลี่ยนค่าสำคัญ (Project, Type, Discipline, Recipient) ในสถานะ Draft เท่านั้น หากค่าเหล่านี้ไม่เปลี่ยน **ต้อง** ใช้เลขเดิมเสมอ
-  * 1.3 ในกรณีที่มีการเปลี่ยนค่าสำคัญ (Project, Type, Discipline, Recipient) ถ้ายังไม่ได้ออกเลขถัดไป ต้องคืนเลขเดิม (-1 counter) ถ้าออกเลขถัดไปแล้ว ให้บันทึกเลขนี้ เป็น void_replace
-  * 1.4 ใช้ **Redlock** (Redis Distributed Lock) คลุม Logic การดึงและอัปเดต Counter ร่วมกับ **Optimistic Locking** (Version column) ใน Database
-  * 1.5 **Audit Logging:** แก้ไขฟังก์ชัน `logAudit` ให้บันทึก `operation` type (reserve, confirm, manual_override, void_replace) ให้ครบถ้วน
-  * 1.6 **Implement New Methods:**
-    * `manualOverride()`: บันทึกเลขและขยับ Counter ถ้าเลขมากกว่าปัจจุบัน
-    * `NumberingMetrics`: Interface สำหรับ Monitoring Dashboard
-    * `cancelNumber()`: บันทึก Audit ว่ายกเลิก (Skip) โดยไม่นำกลับมาใช้ใหม่
-    * `voidAndReplace()`: ออกเลขใหม่ให้เอกสารเดิม และบันทึกความเชื่อมโยง
-    * `bulkImport()`: สำหรับนำเข้าข้อมูลและตั้งค่า Counter เริ่มต้น
-    * `confirmNumber()`: บันทึกเลขและขยับ Counter ถ้าเลขมากกว่าปัจจุบัน
-    * `audit()`: บันทึก Audit ว่ายกเลิก (Skip) โดยไม่นำกลับมาใช้ใหม่
+
+- 1.1 ตรวจสอบให้แน่ใจว่า `generateNextNumber` จะถูกเรียกเฉพาะตอน Create (POST) เท่านั้น
+- 1.2 ห้ามเรียกตอน Update (PATCH/PUT) ยกเว้นกรณีมีการเปลี่ยนค่าสำคัญ (Project, Type, Discipline, Recipient) ในสถานะ Draft เท่านั้น หากค่าเหล่านี้ไม่เปลี่ยน **ต้อง** ใช้เลขเดิมเสมอ
+- 1.3 ในกรณีที่มีการเปลี่ยนค่าสำคัญ (Project, Type, Discipline, Recipient) ถ้ายังไม่ได้ออกเลขถัดไป ต้องคืนเลขเดิม (-1 counter) ถ้าออกเลขถัดไปแล้ว ให้บันทึกเลขนี้ เป็น void_replace
+- 1.4 ใช้ **Redlock** (Redis Distributed Lock) คลุม Logic การดึงและอัปเดต Counter ร่วมกับ **Optimistic Locking** (Version column) ใน Database
+- 1.5 **Audit Logging:** แก้ไขฟังก์ชัน `logAudit` ให้บันทึก `operation` type (reserve, confirm, manual_override, void_replace) ให้ครบถ้วน
+- 1.6 **Implement New Methods:**
+  - `manualOverride()`: บันทึกเลขและขยับ Counter ถ้าเลขมากกว่าปัจจุบัน
+  - `NumberingMetrics`: Interface สำหรับ Monitoring Dashboard
+  - `cancelNumber()`: บันทึก Audit ว่ายกเลิก (Skip) โดยไม่นำกลับมาใช้ใหม่
+  - `voidAndReplace()`: ออกเลขใหม่ให้เอกสารเดิม และบันทึกความเชื่อมโยง
+  - `bulkImport()`: สำหรับนำเข้าข้อมูลและตั้งค่า Counter เริ่มต้น
+  - `confirmNumber()`: บันทึกเลขและขยับ Counter ถ้าเลขมากกว่าปัจจุบัน
+  - `audit()`: บันทึก Audit ว่ายกเลิก (Skip) โดยไม่นำกลับมาใช้ใหม่

 ### 2. เพิ่มฟีเจอร์สำหรับ Admin
-  * 2.1 เพิ่ม Endpoints สำหรับ Admin (ควรติด Guard `RequirePermission`)
-  * 2.2 `GET /admin/document-numbering/metrics`
-  * 2.3 `POST /admin/document-numbering/manual-override`
-  * 2.4 `POST /admin/document-numbering/bulk-import`
-  * 2.5 `POST /admin/document-numbering/void-and-replace`
-  * 2.6 `POST /admin/document-numbering/cancel-number`
-  * 2.7 `POST /admin/document-numbering/confirm-number`
-  * 2.8 `POST /admin/document-numbering/audit`
-  * 2.9 `POST /admin/document-numbering/audit`
+
+- 2.1 เพิ่ม Endpoints สำหรับ Admin (ควรติด Guard `RequirePermission`)
+- 2.2 `GET /admin/document-numbering/metrics`
+- 2.3 `POST /admin/document-numbering/manual-override`
+- 2.4 `POST /admin/document-numbering/bulk-import`
+- 2.5 `POST /admin/document-numbering/void-and-replace`
+- 2.6 `POST /admin/document-numbering/cancel-number`
+- 2.7 `POST /admin/document-numbering/confirm-number`
+- 2.8 `POST /admin/document-numbering/audit`
+- 2.9 `POST /admin/document-numbering/audit`

 ### 3. ปรับปรุง UI เพื่อป้องกัน User แก้ไขเลขที่เอกสาร
-  * 3.1 แสดง "Auto Generated" หรือ Preview เลขที่เอกสาร (ถ้ามี)
-  * 3.2 ช่อง `Document No` ต้องเป็น **Read-Only** หรือ **Disabled** เสมอ User เห็นแต่แก้ไม่ได้
-  * 3.3 **API Integration:** ตัดการส่ง field `documentNumber` กลับไปหา Backend ในหน้า Edit เพื่อป้องกันการเขียนทับโดยบังเอิญ
+
+- 3.1 แสดง "Auto Generated" หรือ Preview เลขที่เอกสาร (ถ้ามี)
+- 3.2 ช่อง `Document No` ต้องเป็น **Read-Only** หรือ **Disabled** เสมอ User เห็นแต่แก้ไม่ได้
+- 3.3 **API Integration:** ตัดการส่ง field `documentNumber` กลับไปหา Backend ในหน้า Edit เพื่อป้องกันการเขียนทับโดยบังเอิญ

 ### 4. ปรับปรุง Database เพื่อรองรับฟีเจอร์ใหม่
-  * 4.1 Schema Update* ตรวจสอบตาราง `document_number_audit` ว่ามีคอลัมน์รองรับ `operation` (Enum) และ `metadata` (JSON) หรือไม่ หากไม่มีให้สร้าง Migration file
-  * 4.2 Data Seeding / Migration* ใช้ `BulkImportDto` ในการเขียน Script ดึงข้อมูลเลขที่เอกสารล่าสุดจากระบบเก่า
-    * 4.2.1 รัน Script ผ่าน Endpoint `bulk-import` เพื่อให้ระบบคำนวณและตั้งค่า `Last Number` ของแต่ละ Series ให้ถูกต้องทันทีที่ขึ้นระบบใหม่
+
+- 4.1 Schema Update\* ตรวจสอบตาราง `document_number_audit` ว่ามีคอลัมน์รองรับ `operation` (Enum) และ `metadata` (JSON) หรือไม่ หากไม่มีให้สร้าง Migration file
+- 4.2 Data Seeding / Migration\* ใช้ `BulkImportDto` ในการเขียน Script ดึงข้อมูลเลขที่เอกสารล่าสุดจากระบบเก่า
+  - 4.2.1 รัน Script ผ่าน Endpoint `bulk-import` เพื่อให้ระบบคำนวณและตั้งค่า `Last Number` ของแต่ละ Series ให้ถูกต้องทันทีที่ขึ้นระบบใหม่

 ### 5. Frontend Implementation (UI/UX)เป้าหมาย: ป้องกัน User แก้ไขเลขที่เอกสาร และสร้างเครื่องมือให้ Admin

-### 5.1 User Mode (Create/Edit Forms)* **Create Mode:** แสดง "Auto Generated" หรือ Preview เลขที่เอกสาร (ถ้ามี)
-* **Edit Mode (Strict Rule):** ช่อง `Document No` ต้องเป็น **Read-Only** หรือ **Disabled** เสมอ User เห็นแต่แก้ไม่ได้
-* **API Integration:** ตัดการส่ง field `documentNumber` กลับไปหา Backend ในหน้า Edit เพื่อป้องกันการเขียนทับโดยบังเอิญ
+### 5.1 User Mode (Create/Edit Forms)\* **Create Mode:** แสดง "Auto Generated" หรือ Preview เลขที่เอกสาร (ถ้ามี)

-### 5.2 Admin Dashboard (Monitoring & Tools)* **Numbering Dashboard:**
-  * Template Management: ต้องคงหน้านี้ไว้ ทำให้เป็นหน้าแรก ของ Numbering Dashboard
-  * สร้างหน้ากราฟแสดง `sequence_utilization` และ `failed_lock_attempts` จาก API Metrics ทำให้เป็น เมนูย่อย ของ Numbering Dashboard
-  * Management Tools: สร้าง Modal หรือ Form สำหรับ:
-    * Manual Override: กรณีต้องออกเลขย้อนหลังหรือเลขพิเศษ: ทำให้เป็น เมนูย่อย ของ Numbering Dashboard
-    * Void/Replace: ปุ่มกดเพื่อ Void เอกสารและออกเลขใหม่: ทำให้เป็น เมนูย่อย ของ Numbering Dashboard
+- **Edit Mode (Strict Rule):** ช่อง `Document No` ต้องเป็น **Read-Only** หรือ **Disabled** เสมอ User เห็นแต่แก้ไม่ได้
+- **API Integration:** ตัดการส่ง field `documentNumber` กลับไปหา Backend ในหน้า Edit เพื่อป้องกันการเขียนทับโดยบังเอิญ

+### 5.2 Admin Dashboard (Monitoring & Tools)\* **Numbering Dashboard:**

+- Template Management: ต้องคงหน้านี้ไว้ ทำให้เป็นหน้าแรก ของ Numbering Dashboard
+- สร้างหน้ากราฟแสดง `sequence_utilization` และ `failed_lock_attempts` จาก API Metrics ทำให้เป็น เมนูย่อย ของ Numbering Dashboard
+- Management Tools: สร้าง Modal หรือ Form สำหรับ:
+  - Manual Override: กรณีต้องออกเลขย้อนหลังหรือเลขพิเศษ: ทำให้เป็น เมนูย่อย ของ Numbering Dashboard
+  - Void/Replace: ปุ่มกดเพื่อ Void เอกสารและออกเลขใหม่: ทำให้เป็น เมนูย่อย ของ Numbering Dashboard
@@ -27,14 +27,12 @@
 ## 📝 Acceptance Criteria

 1. **Search Capabilities:**
-
   - [x] Search across multiple document types
   - [x] Full-text search in title, description
   - [x] Filter by project, status, date range
   - [x] Sort results by relevance/date

 2. **Indexing:**
-
   - [x] Auto-index on document create/update (Direct Call implemented)
   - [ ] Async indexing (via queue) - **Pending**
   - [ ] Bulk re-indexing command - **Pending**
@@ -227,11 +225,7 @@ export class SearchService {
    };
  }

-  async indexDocument(
-    documentType: string,
-    documentId: number,
-    data: any
-  ): Promise<void> {
+  async indexDocument(documentType: string, documentId: number, data: any): Promise<void> {
    await this.elasticsearch.index({
      index: this.INDEX_NAME,
      id: `${documentType}-${documentId}`,
@@ -242,11 +236,7 @@ export class SearchService {
    });
  }

-  async updateDocument(
-    documentType: string,
-    documentId: number,
-    data: any
-  ): Promise<void> {
+  async updateDocument(documentType: string, documentId: number, data: any): Promise<void> {
    await this.elasticsearch.update({
      index: this.INDEX_NAME,
      id: `${documentType}-${documentId}`,
@@ -256,10 +246,7 @@ export class SearchService {
    });
  }

-  async deleteDocument(
-    documentType: string,
-    documentId: number
-  ): Promise<void> {
+  async deleteDocument(documentType: string, documentId: number): Promise<void> {
    await this.elasticsearch.delete({
      index: this.INDEX_NAME,
      id: `${documentType}-${documentId}`,
@@ -298,22 +285,17 @@ export class SearchIndexer {

    const latestRevision = correspondence.revisions[0];

-    await this.searchService.indexDocument(
-      'correspondence',
-      correspondence.id,
-      {
-        id: correspondence.id,
-        correspondenceNumber: correspondence.correspondence_number,
-        title: correspondence.title,
-        description: latestRevision?.description,
-        projectId: correspondence.project_id,
-        projectName: correspondence.project.project_name,
-        status: correspondence.status,
-        createdAt: correspondence.createdAt,
-        organizationName:
-          correspondence.originatorOrganization.organization_name,
-      }
-    );
+    await this.searchService.indexDocument('correspondence', correspondence.id, {
+      id: correspondence.id,
+      correspondenceNumber: correspondence.correspondence_number,
+      title: correspondence.title,
+      description: latestRevision?.description,
+      projectId: correspondence.project_id,
+      projectName: correspondence.project.project_name,
+      status: correspondence.status,
+      createdAt: correspondence.createdAt,
+      organizationName: correspondence.originatorOrganization.organization_name,
+    });
  }

  @Process('index-rfa')
@@ -375,10 +357,7 @@ export class CorrespondenceService {
    private searchQueue: Queue
  ) {}

-  async create(
-    dto: CreateCorrespondenceDto,
-    userId: number
-  ): Promise<Correspondence> {
+  async create(dto: CreateCorrespondenceDto, userId: number): Promise<Correspondence> {
    const correspondence = await this.dataSource.transaction(/* ... */);

    // Queue for indexing (async)
@@ -158,14 +158,14 @@ rfaRevision: RfaRevision;
 ```typescript
 // correspondence/dto/create-correspondence-revision.dto.ts
 export class CreateCorrespondenceRevisionDto {
-  subject: string;  // was: title
+  subject: string; // was: title
  body?: string;
  remarks?: string;
 }

 // rfa/dto/create-rfa-revision.dto.ts
 export class CreateRfaRevisionDto {
-  subject: string;  // was: title
+  subject: string; // was: title
  body?: string;
  remarks?: string;
  dueDate?: Date;
@@ -180,29 +180,29 @@ export class CreateRfaRevisionDto {

 | File                                 | Status | Changes                                   |
 | ------------------------------------ | ------ | ----------------------------------------- |
-| `correspondence.entity.ts`           | ✅      | Minor: add recipients relation            |
-| `correspondence-revision.entity.ts`  | ✅      | Rename title→subject, add body/remarks    |
-| `correspondence-recipient.entity.ts` | ✅      | FK change to correspondence               |
-| `rfa.entity.ts`                      | ✅      | Shared PK pattern                         |
-| `rfa-revision.entity.ts`             | ✅      | Remove correspondenceId, add body/remarks |
-| `rfa-item.entity.ts`                 | ✅      | Rename column                             |
+| `correspondence.entity.ts`           | ✅     | Minor: add recipients relation            |
+| `correspondence-revision.entity.ts`  | ✅     | Rename title→subject, add body/remarks    |
+| `correspondence-recipient.entity.ts` | ✅     | FK change to correspondence               |
+| `rfa.entity.ts`                      | ✅     | Shared PK pattern                         |
+| `rfa-revision.entity.ts`             | ✅     | Remove correspondenceId, add body/remarks |
+| `rfa-item.entity.ts`                 | ✅     | Rename column                             |

 ### DTOs

 | File                                    | Status | Changes                         |
 | --------------------------------------- | ------ | ------------------------------- |
-| `create-correspondence-revision.dto.ts` | ✅      | title→subject, add body/remarks |
-| `update-correspondence-revision.dto.ts` | ✅      | Same                            |
-| `create-rfa-revision.dto.ts`            | ✅      | title→subject, add fields       |
-| `update-rfa-revision.dto.ts`            | ✅      | Same                            |
-| `create-rfa-item.dto.ts`                | ✅      | Column rename                   |
+| `create-correspondence-revision.dto.ts` | ✅     | title→subject, add body/remarks |
+| `update-correspondence-revision.dto.ts` | ✅     | Same                            |
+| `create-rfa-revision.dto.ts`            | ✅     | title→subject, add fields       |
+| `update-rfa-revision.dto.ts`            | ✅     | Same                            |
+| `create-rfa-item.dto.ts`                | ✅     | Column rename                   |

 ### Services

 | File                        | Status | Changes                          |
 | --------------------------- | ------ | -------------------------------- |
-| `correspondence.service.ts` | ✅      | Update queries for new relations |
-| `rfa.service.ts`            | ✅      | Handle Shared PK creation        |
+| `correspondence.service.ts` | ✅     | Update queries for new relations |
+| `rfa.service.ts`            | ✅     | Handle Shared PK creation        |

 ---

@@ -1,18 +1,22 @@
 # TASK-BE-017: Document Numbering Backend Refactor

 ---
+
 status: TODO
 priority: HIGH
 estimated_effort: 3-5 days
 dependencies:
-  - specs/01-requirements/01-03.11-document-numbering.md (v1.6.2)
-  - specs/03-implementation/03-04-document-numbering.md (v1.6.2)
-related_task: TASK-FE-017-document-numbering-refactor.md
+
+- specs/01-requirements/01-03.11-document-numbering.md (v1.6.2)
+- specs/03-implementation/03-04-document-numbering.md (v1.6.2)
+  related_task: TASK-FE-017-document-numbering-refactor.md
+
 ---

 ## Objective

 Refactor Document Numbering module ตาม specification v1.6.2 และ Implementation Guide โดยเน้น:
+
 - Single Numbering System (Option A)
 - Number State Machine (RESERVED → CONFIRMED → VOID → CANCELLED)
 - Two-Phase Commit implementation
@@ -27,6 +31,7 @@ Refactor Document Numbering module ตาม specification v1.6.2 และ Impl
 ### 1. Entity Updates

 #### 1.1 DocumentNumberCounter Entity
+
 - [ ] Rename `current_year` → ใช้ `reset_scope` pattern (`YEAR_2025`, `NONE`)
 - [ ] Ensure FK columns match: `correspondence_type_id`, `originator_organization_id`, `recipient_organization_id`
 - [ ] Add `rfa_type_id`, `sub_type_id`, `discipline_id` columns
@@ -34,6 +39,7 @@ Refactor Document Numbering module ตาม specification v1.6.2 และ Impl
 - [ ] Add `version` column for optimistic locking

 #### 1.2 New Entities (Create)
+
 - [ ] **DocumentNumberFormat**: Store templates per project/type (`document_number_formats` table)
 - [ ] **DocumentNumberReservation**: Store active reservations (`document_number_reservations` table)
 - [ ] **DocumentNumberAudit**: Store complete audit trail (`document_number_audit` table)
@@ -44,18 +50,21 @@ Refactor Document Numbering module ตาม specification v1.6.2 และ Impl
 ### 2. Service Updates

 #### 2.1 Core Services
+
 - [ ] **DocumentNumberingService**: Main orchestration (Reserve, Confirm, Cancel, Preview)
 - [ ] **CounterService**: Handle `incrementCounter` with DB optimistic lock & retry logic
 - [ ] **DocumentNumberingLockService**: Implement Redis Redlock (`acquireLock`, `releaseLock`)
 - [ ] **ReservationService**: Handle Two-Phase Commit logic (TTL, cleanup)

 #### 2.2 Helper Services
+
 - [ ] **FormatService**: Format number string based on template & tokens
 - [ ] **TemplateService**: CRUD operations for `DocumentNumberFormat` and validation
 - [ ] **AuditService**: Async logging to `DocumentNumberAudit`
 - [ ] **MetricsService**: Prometheus counters/gauges (utilization, lock wait time)

 #### 2.3 Feature Services
+
 - [ ] **ManualOverrideService**: Handle manual number assignment & sequence adjustment
 - [ ] **MigrationService**: Handle bulk import / legacy data migration

@@ -64,6 +73,7 @@ Refactor Document Numbering module ตาม specification v1.6.2 และ Impl
 ### 3. Controller Updates

 #### 3.1 DocumentNumberingController
+
 - [ ] `POST /reserve`: Reserve number (Phase 1)
 - [ ] `POST /confirm`: Confirm number (Phase 2)
 - [ ] `POST /cancel`: Cancel reservation
@@ -72,12 +82,14 @@ Refactor Document Numbering module ตาม specification v1.6.2 และ Impl
 - [ ] Add `Idempotency-Key` header validation

 #### 3.2 DocumentNumberingAdminController
+
 - [ ] `POST /manual-override`
 - [ ] `POST /void-and-replace`
 - [ ] `POST /bulk-import`
 - [ ] `POST /templates`: Manage templates

 #### 3.3 NumberingMetricsController
+
 - [ ] `GET /metrics`: Expose utilization & health metrics for dashboard

 ---
@@ -85,6 +97,7 @@ Refactor Document Numbering module ตาม specification v1.6.2 และ Impl
 ### 4. Logic & Algorithms

 #### 4.1 Counter Key Builder
+
 - Implement logic to build unique key tuple:
  - Global: `(proj, orig, recip, type, 0, 0, 0, YEAR_XXXX)`
  - Transmittal: `(proj, orig, recip, type, subType, 0, 0, YEAR_XXXX)`
@@ -92,11 +105,13 @@ Refactor Document Numbering module ตาม specification v1.6.2 และ Impl
  - Drawing: `(proj, TYPE, main, sub)` (separate namespace)

 #### 4.2 State Machine
+
 - [ ] Validate transitions: RESERVED -> CONFIRMED
 - [ ] Auto-expire RESERVED -> CANCELLED (via Cron/TTL)
 - [ ] CONFIRMED -> VOID

 #### 4.3 Lock Strategy
+
 - [ ] Try Redis Lock -> if valid -> Increment -> Release
 - [ ] Fallback to DB Lock if Redis unavailable (optional/advanced)

@@ -105,11 +120,13 @@ Refactor Document Numbering module ตาม specification v1.6.2 และ Impl
 ### 5. Testing

 #### 5.1 Unit Tests
+
 - [ ] `CounterService` optimistic locking
 - [ ] `TemplateValidator` grammar check
 - [ ] `ReservationService` expiry logic

 #### 5.2 Integration Tests
+
 - [ ] Full Two-Phase Commit flow
 - [ ] Concurrent requests (check for duplicates)
 - [ ] Idempotency-Key behavior
@@ -10,11 +10,13 @@ related:
 ---

 ## Objective
+
 Update backend entities and logic to align with schema v1.7.0 and revised document numbering specifications.

 ## Scope of Work

 ### 1. Drawing Module
+
 - **Contract Drawings:**
  - Update `ContractDrawing` entity (map_cat_id, volume_page)
  - Create `ContractDrawingSubcatCatMap` entity
@@ -27,11 +29,13 @@ Update backend entities and logic to align with schema v1.7.0 and revised docume
  - Create entities for `asbuilt_drawings` and related tables.

 ### 2. Document Numbering Module
+
 - **Counters:**
  - Update `DocumentNumberCounter` entity to match 8-part Composite Key.
  - Ensure strict typing for `reset_scope`.

 ## Definition of Done
+
 - [x] All entities match v1.7.0 schema
 - [x] Application compiles without type errors
 - [x] Document Numbering service supports new key structure
@@ -10,6 +10,7 @@
 ## 🎯 Objective

 Refactor the DMS system (Backend & Frontend) to support **High Scalability (100k+ Documents)**, **Enhanced Security (RBAC/Audit)**, and **Enterprise-Grade UX**. This task consolidates three key initiatives:
+
 1.  **Advanced Storage Management:** Optimize file storage for large datasets (Data Integrity).
 2.  **Admin Panel Refactor:** Secure and reorganize the administrative interface.
 3.  **Document Management Interface:** Improve frontend performance and usability for large document lists.
@@ -34,26 +35,30 @@ Refactor the DMS system (Backend & Frontend) to support **High Scalability (100k
 **Goal:** Shift from "Upload Date" to "Issue Date" storage logic and implement deep directory structures for performance.

 #### 1.1 Database Schema (Data Integrity)
+
 - [ ] **Verify Date Columns:** Ensure `rfa`, `correspondence`, `drawing_revisions` have a reliable `issue_date` or `document_date`.
 - [ ] **Update Attachments Table:** Add `reference_date` column to `attachments` to freeze the storage path date (prevents broken paths if document date changes).

 #### 1.2 FileStorageService Refactor
+
 - [ ] **Update `commit()` Logic:** Change storage path generation logic.
-    - *Old:* `/permanent/YYYY/MM/uuid.pdf` (based on execution time)
-    - *New:* `/permanent/{DocumentType}/{YYYY}/{MM}/{uuid}.pdf` (based on `issue_date`)
+  - _Old:_ `/permanent/YYYY/MM/uuid.pdf` (based on execution time)
+  - _New:_ `/permanent/{DocumentType}/{YYYY}/{MM}/{uuid}.pdf` (based on `issue_date`)
 - [ ] **Fail-safe Logic:** Implement fallback to `created_at` if `issue_date` is missing.

 #### 1.3 Infrastructure & Security
+
 - [ ] **Deep Directory Structure:** Implement logic to handle nested folders to verify Inode limits.
 - [ ] **Path Isolation:** Ensure Web Server (NestJS) has `ReadOnly` access to `permanent` storage, `Write` only for specific services.
 - [ ] **Streaming Proxy:** Enforce file access via API Stream only (Check RBAC -> Stream File), never expose direct static paths.

 #### 1.4 Data Migration (Legacy Support)
+
 - [ ] **Develop Migration Script:**
-    1. Scan `attachments` where `is_temporary = false`.
-    2. Retrieve `issue_date` from parent entity.
-    3. Move file to new structure.
-    4. Update `stored_path` in DB.
+  1. Scan `attachments` where `is_temporary = false`.
+  2. Retrieve `issue_date` from parent entity.
+  3. Move file to new structure.
+  4. Update `stored_path` in DB.

 ---

@@ -62,20 +67,23 @@ Refactor the DMS system (Backend & Frontend) to support **High Scalability (100k
 **Goal:** Secure the Admin Panel and reorganize the UI for better usability.

 #### 2.1 Critical Security Fixes (Immediate)
+
 - [ ] **Remove Hardcoded Bypass:** Delete `const isAdmin = true;` in `frontend/app/(admin)/layout.tsx`. Validate `session.user.role` from JWT.
 - [ ] **Middleware Enforcement:** Update `frontend/middleware.ts` to strictly require `ADMIN` or `DC` roles for `/admin/**` routes.
 - [ ] **Session Kill Switch:** Implement Backend endpoint and Frontend UI to revoke active user sessions.

 #### 2.2 Backend Optimization
+
 - [ ] **Bulk RBAC Update:** Create `PUT /roles/permissions/bulk` endpoint to handle multiple permission changes in a single transaction (Fixes Loop API issue).
 - [ ] **Audit Log Pagination:** Update `AuditLogService` to support Server-side Pagination (`page`, `limit`, `filters`).

 #### 2.3 Frontend Reorganization (UI/UX)
+
 - [ ] **Refactor Folder Structure:** Group admin pages logically:
-    - `/admin/access-control/` (Users, Roles, Sessions)
-    - `/admin/doc-control/` (Numbering, Workflows, Master Data)
-    - `/admin/monitoring/` (Audit Logs, Health)
-    - `/admin/settings/`
+  - `/admin/access-control/` (Users, Roles, Sessions)
+  - `/admin/doc-control/` (Numbering, Workflows, Master Data)
+  - `/admin/monitoring/` (Audit Logs, Health)
+  - `/admin/settings/`
 - [ ] **Shared Components:** Implement `AdminPageHeader` and `AdminDataTable` for consistency.

 ---
@@ -85,14 +93,17 @@ Refactor the DMS system (Backend & Frontend) to support **High Scalability (100k
 **Goal:** Support browsing 100k+ documents with high performance and better UX.

 #### 3.1 Performance (Server-Side Logic)
+
 - [ ] **Update Hooks:** Refactor `useDrawings` (and others) to accept `page`, `limit`, `sort`, `filter` params.
 - [ ] **ServerDataTable Component:** Create a reusable Table component that handles Server-side pagination and sorting events efficiently.

 #### 3.2 UI Structure & Navigation
+
 - [ ] **Tabbed Interface:** Split documents by category (e.g., Contract / Shop / As-Built) using Tabs to load data lazily.
 - [ ] **Visual Cues:** Add distinct Badges for Revision Status (e.g., "Current" vs "Superseded").

 #### 3.3 Data Integrity Features
+
 - [ ] **Pre-upload Validation:** Implement `NumberPreviewCard` to check Document Number availability in real-time before submission.
 - [ ] **Revision Guard:** Validate `nextPossibleRevision` to prevent skipping revisions (e.g., A -> C).

@@ -101,6 +112,7 @@ Refactor the DMS system (Backend & Frontend) to support **High Scalability (100k
 ## 📂 Technical Guidelines

 ### Backend: Bulk Permission DTO
+
 ```typescript
 export class BulkRolePermissionDto {
  @IsNumber()
@@ -114,13 +126,16 @@ export class BulkRolePermissionDto {
 ```

 ### Frontend: Sidebar Navigation Structure
+
 ```typescript
 const adminMenu = [
-  { title: "Overview", items: [{ title: "Dashboard", href: "/admin/dashboard" }] },
-  { title: "Access Control", items: [
-      { title: "Users", href: "/admin/access-control/users" },
-      { title: "Roles & Matrix", href: "/admin/access-control/roles" }
-    ]
+  { title: 'Overview', items: [{ title: 'Dashboard', href: '/admin/dashboard' }] },
+  {
+    title: 'Access Control',
+    items: [
+      { title: 'Users', href: '/admin/access-control/users' },
+      { title: 'Roles & Matrix', href: '/admin/access-control/roles' },
+    ],
  },
  // ...
 ];
@@ -133,4 +148,4 @@ const adminMenu = [
 1.  **Security:** Non-admin users MUST NOT access any `/admin` route.
 2.  **Performance:** Document lists with 100k records must load first page in < 200ms.
 3.  **Data Integrity:** Files are stored in structure `/permanent/{Type}/{Year}/{Month}/`.
-4.  **Reliability:** Bulk Permission updates are atomic (all or nothing).
+4.  **Reliability:** Bulk Permission updates are atomic (all or nothing).
@@ -28,46 +28,49 @@

 ### 1. Correspondence Revisions ⚠️ UI IMPACT

-| Change     | Old Field | New Field | Business Rule                           |
-| ---------- | --------- | --------- | --------------------------------------- |
+| Change     | Old Field | New Field | Business Rule                                   |
+| ---------- | --------- | --------- | ----------------------------------------------- |
 | **Rename** | `title`   | `subject` | Form label เปลี่ยนจาก "หัวเรื่อง" เป็น "เรื่อง" |
-| **Add**    | -         | `body`    | เพิ่ม Rich Text Editor สำหรับเนื้อความ        |
-| **Add**    | -         | `remarks` | เพิ่ม Textarea สำหรับหมายเหตุ                |
-| **Add**    | -         | `dueDate` | เพิ่ม Date Picker สำหรับกำหนดส่ง              |
+| **Add**    | -         | `body`    | เพิ่ม Rich Text Editor สำหรับเนื้อความ          |
+| **Add**    | -         | `remarks` | เพิ่ม Textarea สำหรับหมายเหตุ                   |
+| **Add**    | -         | `dueDate` | เพิ่ม Date Picker สำหรับกำหนดส่ง                |

 **UI Impact:**
+
 - Correspondence Form: เพิ่ม 3 fields ใหม่
 - Correspondence List: เปลี่ยน column header
 - Correspondence Detail: แสดง body และ remarks

 ### 2. Correspondence Recipients ⚠️ RELATION CHANGE

-| Before                   | After                  | Business Rule              |
-| ------------------------ | ---------------------- | -------------------------- |
+| Before                     | After                    | Business Rule                     |
+| -------------------------- | ------------------------ | --------------------------------- |
 | Recipients ผูกกับ Revision | Recipients ผูกกับ Master | ผู้รับคงที่ตลอด Revisions ทั้งหมด |

 **UI Impact:**
+
 - ย้าย Recipients Selection ออกจาก Revision Form
 - ไปอยู่ใน Master Correspondence Form แทน
 - Recipients จะไม่เปลี่ยนเมื่อสร้าง New Revision

 ### 3. RFA System 🔄 ARCHITECTURE CHANGE

-| Change           | Description                | Business Rule                                |
-| ---------------- | -------------------------- | -------------------------------------------- |
+| Change           | Description                | Business Rule                                      |
+| ---------------- | -------------------------- | -------------------------------------------------- |
 | **Shared ID**    | RFA.id = Correspondence.id | สร้าง Correspondence ก่อน แล้ว RFA ใช้ ID เดียวกัน |
-| **Subject**      | `title` → `subject`        | เหมือนกับ Correspondence                       |
-| **Body/Remarks** | เพิ่ม fields ใหม่             | เหมือนกับ Correspondence                       |
-| **Due Date**     | เพิ่ม field                  | กำหนดวันที่ต้องตอบกลับ                             |
+| **Subject**      | `title` → `subject`        | เหมือนกับ Correspondence                           |
+| **Body/Remarks** | เพิ่ม fields ใหม่          | เหมือนกับ Correspondence                           |
+| **Due Date**     | เพิ่ม field                | กำหนดวันที่ต้องตอบกลับ                             |

 **UI Impact:**
+
 - RFA Form: เพิ่ม body, remarks, dueDate
 - RFA Creation Flow: อาจต้อง adjust การ submit

 ### 4. RFA Items ⚠️ API CHANGE

-| Before                   | After           | Impact                                      |
-| ------------------------ | --------------- | ------------------------------------------- |
+| Before                   | After           | Impact                                        |
+| ------------------------ | --------------- | --------------------------------------------- |
 | `rfaRevCorrespondenceId` | `rfaRevisionId` | เปลี่ยน property name ใน API request/response |

 ---
@@ -87,18 +90,18 @@ interface CorrespondenceRevision {

 // AFTER
 interface CorrespondenceRevision {
-  subject: string;           // renamed from title
-  body?: string;             // NEW
-  remarks?: string;          // NEW
-  dueDate?: string;          // NEW
-  schemaVersion?: number;    // NEW
+  subject: string; // renamed from title
+  body?: string; // NEW
+  remarks?: string; // NEW
+  dueDate?: string; // NEW
+  schemaVersion?: number; // NEW
  // ...
 }

 // Move recipients to master level
 interface Correspondence {
  // ...existing fields
-  recipients: CorrespondenceRecipient[];  // MOVED from revision
+  recipients: CorrespondenceRecipient[]; // MOVED from revision
 }
 ```

@@ -115,10 +118,10 @@ interface RfaRevision {
 // AFTER
 interface RfaRevision {
  // correspondenceId: REMOVED
-  subject: string;           // renamed from title
-  body?: string;             // NEW
-  remarks?: string;          // NEW
-  dueDate?: string;          // NEW
+  subject: string; // renamed from title
+  body?: string; // NEW
+  remarks?: string; // NEW
+  dueDate?: string; // NEW
  // ...
 }

@@ -130,7 +133,7 @@ interface RfaItem {

 // AFTER
 interface RfaItem {
-  rfaRevisionId: number;     // renamed
+  rfaRevisionId: number; // renamed
  // ...
 }
 ```
@@ -161,7 +164,7 @@ const columns = [
  // BEFORE: { header: 'หัวเรื่อง', accessorKey: 'title' }
  // AFTER:
  { header: 'เรื่อง', accessorKey: 'subject' },
-  { header: 'กำหนดส่ง', accessorKey: 'dueDate' },  // NEW column
+  { header: 'กำหนดส่ง', accessorKey: 'dueDate' }, // NEW column
 ];
 ```

@@ -183,31 +186,31 @@ const columns = [

 | File                          | Status | Changes                                 |
 | ----------------------------- | ------ | --------------------------------------- |
-| `lib/types/correspondence.ts` | ✅      | title→subject, add body/remarks/dueDate |
-| `lib/types/rfa.ts`            | ✅      | Same + remove correspondenceId          |
+| `lib/types/correspondence.ts` | ✅     | title→subject, add body/remarks/dueDate |
+| `lib/types/rfa.ts`            | ✅     | Same + remove correspondenceId          |

 ### Forms

 | File                                                 | Status | Changes                |
 | ---------------------------------------------------- | ------ | ---------------------- |
-| `app/(dashboard)/correspondences/new/page.tsx`       | ✅      | Add new fields, rename |
-| `app/(dashboard)/correspondences/[id]/edit/page.tsx` | ✅      | Same                   |
-| `app/(dashboard)/rfas/new/page.tsx`                  | ✅      | Add new fields, rename |
-| `app/(dashboard)/rfas/[id]/edit/page.tsx`            | ✅      | Same                   |
+| `app/(dashboard)/correspondences/new/page.tsx`       | ✅     | Add new fields, rename |
+| `app/(dashboard)/correspondences/[id]/edit/page.tsx` | ✅     | Same                   |
+| `app/(dashboard)/rfas/new/page.tsx`                  | ✅     | Add new fields, rename |
+| `app/(dashboard)/rfas/[id]/edit/page.tsx`            | ✅     | Same                   |

 ### Lists/Tables

 | File                                                | Status | Changes       |
 | --------------------------------------------------- | ------ | ------------- |
-| `components/correspondence/correspondence-list.tsx` | ✅      | Column rename |
-| `components/rfa/rfa-list.tsx`                       | ✅      | Column rename |
+| `components/correspondence/correspondence-list.tsx` | ✅     | Column rename |
+| `components/rfa/rfa-list.tsx`                       | ✅     | Column rename |

 ### Services

 | File                                     | Status | Changes     |
 | ---------------------------------------- | ------ | ----------- |
-| `lib/services/correspondence.service.ts` | ✅      | DTO mapping |
-| `lib/services/rfa.service.ts`            | ✅      | DTO mapping |
+| `lib/services/correspondence.service.ts` | ✅     | DTO mapping |
+| `lib/services/rfa.service.ts`            | ✅     | DTO mapping |

 ---

@@ -1,18 +1,22 @@
 # TASK-FE-017: Document Numbering Frontend Refactor

 ---
+
 status: TODO
 priority: HIGH
 estimated_effort: 2-3 days
 dependencies:
-  - specs/06-tasks/TASK-BE-017-document-numbering-refactor.md
-  - specs/01-requirements/01-03.11-document-numbering.md (v1.6.2)
-  - specs/03-implementation/03-04-document-numbering.md (v1.6.2)
+
+- specs/06-tasks/TASK-BE-017-document-numbering-refactor.md
+- specs/01-requirements/01-03.11-document-numbering.md (v1.6.2)
+- specs/03-implementation/03-04-document-numbering.md (v1.6.2)
+
 ---

 ## Objective

 Refactor Frontend Document Numbering ตาม specification v1.6.2:
+
 - ป้องกัน User แก้ไขเลขที่เอกสาร
 - สร้าง Admin Dashboard ด้วย Metrics
 - Implement Admin Tools (Manual Override, Void/Replace)
@@ -24,17 +28,21 @@ Refactor Frontend Document Numbering ตาม specification v1.6.2:
 ### 1. User Mode Forms (Create/Edit)

 #### 1.1 Correspondence Form
+
 - [ ] **Create Mode**: แสดง "Auto Generated" หรือ Preview เลขที่เอกสาร
 - [ ] **Edit Mode**: ช่อง Document No เป็น **Read-Only** เสมอ
 - [ ] **API Integration**: ตัดการส่ง field `documentNumber` ไป Backend ใน Edit mode

 #### 1.2 RFA Form
+
 - [ ] Same as above - Read-Only document number

 #### 1.3 Transmittal Form
+
 - [ ] Same as above - Read-Only document number

 **Files:**
+
 - `frontend/components/correspondences/form.tsx`
 - `frontend/components/rfas/form.tsx`
 - `frontend/components/transmittals/form.tsx`
@@ -44,6 +52,7 @@ Refactor Frontend Document Numbering ตาม specification v1.6.2:
 ### 2. Admin Dashboard (`/admin/numbering`)

 #### 2.1 Tab Structure
+
 ```
 /admin/numbering
 ├── Templates (existing - keep as is)
@@ -52,10 +61,12 @@ Refactor Frontend Document Numbering ตาม specification v1.6.2:
 ```

 #### 2.2 Templates Tab (Existing)
+
 - [ ] Keep current functionality
 - [ ] เป็น Tab แรก (default)

 #### 2.3 Metrics & Audit Tab (NEW)
+
 - [ ] Fetch metrics from `GET /admin/document-numbering/metrics`
 - [ ] Display:
  - Sequence utilization gauge
@@ -65,6 +76,7 @@ Refactor Frontend Document Numbering ตาม specification v1.6.2:
  - Audit logs table with filters

 #### 2.4 Admin Tools Tab (NEW)
+
 - [ ] **Manual Override Form**:
  - Input: document_type, document_number, reason
  - Calls `POST /admin/document-numbering/manual-override`
@@ -83,6 +95,7 @@ Refactor Frontend Document Numbering ตาม specification v1.6.2:
 ### 3. API Integration

 #### 3.1 New API Endpoints
+
 ```typescript
 // services/document-numbering.service.ts (frontend)

@@ -110,6 +123,7 @@ getAuditLogs(params: AuditQueryParams): Promise<PaginatedAuditLogs>
 ```

 #### 3.2 DTOs
+
 ```typescript
 interface ManualOverrideDto {
  documentType: string;
@@ -149,12 +163,14 @@ interface AuditQueryParams {
 ### 5. UI/UX Requirements

 #### 5.1 Document Number Display
+
 - ใช้ Badge หรือ Chip style สำหรับ Document Number
 - สี: Info (blue) สำหรับ Auto-generated
 - สี: Warning (amber) สำหรับ Manual Override
 - สี: Destructive (red) สำหรับ Voided

 #### 5.2 Admin Tools Access Control
+
 - ซ่อน Admin Tools tab สำหรับ users ที่ไม่มี permission `system.manage_settings`
 - แสดง confirmation dialog ก่อน Manual Override / Void

@@ -9,15 +9,18 @@ related:
 ---

 ## Objective
+
 Update frontend application to align with the refactored backend (v1.7.0 schema). This includes supporting new field mappings, new As Built drawing type, and updated document numbering logic.

 ## Scope of Work

 ### 1. Type Definitions & API Client
+
 - **Types**: Update `Drawing`, `ContractDrawing`, `ShopDrawing` interfaces to match new backend entities (e.g. `mapCatId`, `projectId` in categories).
 - **API**: Update `drawing.service.ts` to support new filter parameters (`mapCatId`) and new endpoints for As Built drawings.

 ### 2. Drawing Upload Form (`DrawingUploadForm`)
+
 - **General**: Refactor to support dynamic fields based on Drawing Type.
 - **Contract Drawings**:
  - Replace `subCategoryId` with `mapCatId` (fetch from `contract-drawing-categories`?).
@@ -32,20 +35,23 @@ Update frontend application to align with the refactored backend (v1.7.0 schema)
  - Implement form fields similar to Shop Drawings (or Contract depending on spec).

 ### 3. Drawing List & Views (`DrawingList`)
+
 - **Contract Drawings**: Show `volumePage`.
 - **Shop Drawings**:
  - Display `legacyDrawingNumber`.
-  - Display Title from *Current Revision*.
+  - Display Title from _Current Revision_.
  - Remove direct title column from sort/filter if backend doesn't support it anymore on master.
 - **As Built Drawings**:
  - Add new Tab/Page for As Built.
  - Implement List View.

 ### 4. Logic & Hooks
+
 - Update `useDrawings`, `useCreateDrawing` hooks to handle new types.
 - Ensure validation schemas (`zod`) match backend constraints.

 ## Definition of Done
+
 - [x] Contract Drawing Upload works with `mapCatId` and `volumePage`
 - [x] Shop Drawing Upload works with `legacyDrawingNumber` and Revision Title
 - [x] As Built Drawing Upload and List implemented
@@ -10,8 +10,8 @@ Verify if the current Backend Implementation aligns with the `specs/06-tasks/TAS

 ## 📊 Summary

-| Module             | Spec ID | Status     | Gaps / Notes                                                                           |
-| :----------------- | :------ | :--------- | :------------------------------------------------------------------------------------- |
+| Module             | Spec ID | Status      | Gaps / Notes                                                                           |
+| :----------------- | :------ | :---------- | :------------------------------------------------------------------------------------- |
 | **Auth & RBAC**    | BE-002  | 🟡 Auditing | Checking Role/UserAssignment entities                                                  |
 | **User Mgmt**      | BE-013  | 🟡 Auditing | Checking `UserPreference` and Service                                                  |
 | **Master Data**    | BE-012  | 🟢 Verified | Consolidated `MasterService` used instead of granular services. Functionally complete. |
@@ -39,4 +39,5 @@ Verify if the current Backend Implementation aligns with the `specs/06-tasks/TAS
 - **Implementation Check:** `UserPreference` entity exists and linked 1:1.

 ---
-*Generated by Antigravity*
+
+_Generated by Antigravity_
@@ -5,8 +5,8 @@

 ## 📊 Overview

-| Task ID         | Title                     | Status            | Completion % | Notes                                                                       |
-| --------------- | ------------------------- | ----------------- | ------------ | --------------------------------------------------------------------------- |
+| Task ID         | Title                     | Status             | Completion % | Notes                                                                       |
+| --------------- | ------------------------- | ------------------ | ------------ | --------------------------------------------------------------------------- |
 | **TASK-BE-001** | Database Migrations       | ✅ **Done**        | 100%         | Schema v1.5.1 active. TypeORM configured.                                   |
 | **TASK-BE-002** | Auth & RBAC               | ✅ **Done**        | 100%         | JWT, Refresh Token, RBAC Guard, Permissions complete.                       |
 | **TASK-BE-003** | File Storage              | ✅ **Done**        | 100%         | MinIO/S3 strategies implemented (in `common`).                              |
@@ -25,29 +25,34 @@
 ## 🛠 Detailed Findings by Component

 ### 1. Core Architecture (✅ Excellent)
+
 - **Modular Design:** Strict separation of concerns (Modules, Controllers, Services, Entities).
 - **Security:** Global Throttling, Maintenance Mode Guard, RBAC Guards (`@RequirePermission`) everywhere.
 - **Resilience:** Redis-based Idempotency & Distributed Locking (`Redlock`) implemented in critical services like Document Numbering.
 - **Observability:** Winston Logger & Global Audit Interceptor integrated.

 ### 2. Workflow Engine (✅ Standout Feature)
+
 - Implements a **DSL-based** engine supporting complex transitions.
 - Supports **Versioning** of workflow definitions (saving old versions automatically).
 - **Hybrid Approach:** Supports both new DSL logic and legacy rigid logic for backward compatibility.
 - **Transactional:** Uses `QueryRunner` for atomic status updates & history logging.

 ### 3. Business Logic
+
 - **Document Numbering:** Very robust. Handles concurrency with Redlock + Optimistic Loop. Solves the "Duplicate Number" problem effectively.
 - **Correspondence & RFA:** Standardized controllers with Swagger documentation (`@ApiTags`, `@ApiOperation`).
 - **Drawing:** Correctly separated into `Shop` vs `Contract` drawings distinct logic.

 ### 4. Integration Points
+
 - **Frontend-Backend:**
  - Token payload now maps `username` correctly (Frontend task just fixed this).
  - Backend returns standard DTOs.
  - Swagger UI is likely available at `/api/docs` (standard NestJS setup).

 ## 🚀 Recommendations
+
 1.  **Integration Testing:** Since individual modules are complete, focus on **E2E Tests** simulating full flows (e.g., Create RFA -> Submit -> Approve -> Check Notification).
 2.  **Search Indexing:** Verify that created documents are actually being pushed to Elasticsearch (check `SearchService` consumers).
 3.  **Real-world Load:** Test the Document Numbering `Redlock` with concurrent requests to ensure it holds up under load.
@@ -5,8 +5,8 @@

 ## 📊 Overview

-| Task ID         | Title                     | Status     | Completion % | Notes                                                               |
-| --------------- | ------------------------- | ---------- | ------------ | ------------------------------------------------------------------- |
+| Task ID         | Title                     | Status      | Completion % | Notes                                                               |
+| --------------- | ------------------------- | ----------- | ------------ | ------------------------------------------------------------------- |
 | **TASK-FE-001** | Frontend Setup            | ✅ **Done** | 100%         | Project structure, Tailwind, Shadcn/UI initialized.                 |
 | **TASK-FE-002** | Auth UI                   | ✅ **Done** | 100%         | Store, RBAC, Login UI, Refresh Token, Session Sync implemented.     |
 | **TASK-FE-003** | Layout & Navigation       | ✅ **Done** | 100%         | Sidebar, Header, Layouts are implemented.                           |
@@ -9,6 +9,7 @@
 ## 1. Executive Summary

 This report summarizes the current implementation state of the **LCBP3-DMS** project.
+
 - **Backend:** All 18 core modules are implemented and operational. System is production-ready with ~95% completion.
 - **Frontend:** All 15 UI tasks are complete (100%). All end-user and admin modules are fully implemented and integrated.

@@ -20,6 +21,7 @@ This report summarizes the current implementation state of the **LCBP3-DMS** pro
 **Overall Backend Status:** ✅ **Completed** (Core Functional Requirements Met)

 ### ✅ Implemented Features (Verified)
+
 | Module                 | ID     | Key Features Implemented                                                            | Note                                     |
 | :--------------------- | :----- | :---------------------------------------------------------------------------------- | :--------------------------------------- |
 | **Auth & RBAC**        | BE-002 | JWT, Session, Role Scopes (Global/Project), Permission Guards.                      | `UserAssignment` linking used correctly. |
@@ -33,6 +35,7 @@ This report summarizes the current implementation state of the **LCBP3-DMS** pro
 | **Master Data**        | BE-012 | Consolidated Master Service (Org, Project, Discipline, Types).                      | Simplifies maintenance.                  |

 ### ⚠️ Technical Notes / Minor Deviations
+
 1.  **Workflow Engine:** Uses a hybrid approach. While fully functional, future refactoring could move strict "Routing Template" logic entirely into DSL to remove the "Legacy" support layer.
 2.  **Search Indexing:** Currently uses **Direct Indexing** (service calls `searchService.indexDocument` directly) rather than a strictly decoupled **Queue Worker**. This ensures immediate consistency but may impact write latency under extreme load. For current scale, this is acceptable.

@@ -44,6 +47,7 @@ This report summarizes the current implementation state of the **LCBP3-DMS** pro
 **Overall Frontend Status:** ✅ **Complete** (~100%)

 ### ✅ Implemented Features (Integrated)
+
 The following modules have UI, Logic, and Backend Integration:

 | Module               | Features Implemented                                                  |
@@ -68,9 +72,11 @@ The following modules have UI, Logic, and Backend Integration:
 ## 4. Summary & Next Steps

 ### Current Status
+
 The LCBP3-DMS application is **feature-complete and production-ready**. All core functionality, end-user modules, and administrative tools are fully implemented and operational.

 **Completion Status:**
+
 - ✅ Backend: ~95% (18 modules fully functional)
 - ✅ Frontend: 100% (All 15 tasks completed)
 - ✅ Overall: ~98% production ready
@@ -78,22 +84,22 @@ The LCBP3-DMS application is **feature-complete and production-ready**. All core
 ### Recommended Next Steps

 1.  **End-to-End Testing & UAT:**
-    *   Perform comprehensive user journey testing across all modules
-    *   Test workflow: *Login → Create RFA → Approve RFA → Search → Check Dashboard*
-    *   Validate all RBAC permissions and role assignments
+    - Perform comprehensive user journey testing across all modules
+    - Test workflow: _Login → Create RFA → Approve RFA → Search → Check Dashboard_
+    - Validate all RBAC permissions and role assignments

 2.  **Load & Performance Testing:**
-    *   Test concurrent document numbering under load
-    *   Verify Redlock behavior with multiple simultaneous requests
-    *   Benchmark Elasticsearch search performance
+    - Test concurrent document numbering under load
+    - Verify Redlock behavior with multiple simultaneous requests
+    - Benchmark Elasticsearch search performance

 3.  **Production Deployment Preparation:**
-    *   Finalize environment configuration
-    *   Prepare deployment runbooks
-    *   Set up monitoring and alerting
-    *   Create backup and recovery procedures
+    - Finalize environment configuration
+    - Prepare deployment runbooks
+    - Set up monitoring and alerting
+    - Create backup and recovery procedures

 4.  **User Training & Documentation:**
-    *   Prepare end-user training materials
-    *   Create administrator guides
-    *   Document operational procedures
+    - Prepare end-user training materials
+    - Create administrator guides
+    - Document operational procedures