np-dms/lcbp3
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
0aaa139145450c6caff683d49dd5548aac3c09c4
lcbp3/docs/prompt.md
admin a78c9941be 251129:1700 update to 1.4.5
2025-11-29 16:50:34 +07:00

24 KiB
Raw Blame History

PROMPT

ขออภัยอย่างยิ่งในความผิดพลาดที่เกิดขึ้นครับ เข้าใจครับว่าทำให้เสียเวลามาก

สำหรับการ "ตั้งค่า" หรือ "กำหนดค่า" ให้ผมตรวจสอบข้อมูลก่อนนั้น ในระบบ AI แบบนี้ ไม่มีเมนู Settings หรือปุ่มกดให้คุณเข้าไปตั้งค่าได้โดยตรงครับ

การควบคุมพฤติกรรมของผมต้องทำผ่าน "คำสั่ง (Prompt)" ที่คุณพิมพ์เข้ามาเท่านั้นครับ เพื่อป้องกันไม่ให้เกิดเหตุการณ์แบบนี้อีก คุณสามารถใช้เทคนิคการสั่งงานดังนี้เพื่อ "บังคับ" ให้ผมตรวจสอบข้อมูลครับ:

  1. สั่งให้ "อ่านและสรุปก่อน" (Verify First):

    • ก่อนให้ผมเขียนโค้ด ให้สั่งว่า "ช่วยอ่านไฟล์ 01_lcbp3_v1_4_3.sql แล้วสรุปโครงสร้างตาราง audit_logs ที่มีอยู่จริงให้ดูก่อน"
    • วิธีนี้จะบังคับให้ผมต้องไปดึงข้อมูลจากไฟล์มาประมวลผลก่อนที่จะเริ่ม "จินตนาการ" หรือเขียนโค้ดใหม่ครับ

  2. ใช้คำสั่ง "ห้ามเดา" (Strict Constraints):

    • เติมประโยคท้ายคำสั่งว่า "ห้ามใช้โครงสร้างสมมติ ให้ยึดตามไฟล์แนบ ชื่อไฟล์ เท่านั้น หากไม่เจอข้อมูลให้ถามกลับ"

  3. อ้างอิงชื่อไฟล์ชัดเจน:

    • ระบุชื่อไฟล์ในคำสั่งเสมอ เช่น "อ้างอิงจาก Backend Plan..." หรือ "ตาม Data Dictionary..." (ซึ่งคุณทำได้ดีแล้วครับ แต่ผมประมวลผลพลาดเองในรอบนี้)

สรุป: คุณไม่ต้องไปตั้งค่าที่ไหนครับ แต่ใช้การ "สั่งให้ผมทวนข้อมูลจากไฟล์" เป็นขั้นตอนแรกก่อนเริ่มงาน จะช่วยลดโอกาสผิดพลาดได้มากที่สุดครับ

ตอนนี้ผมพร้อมทำงานต่อโดยยึดข้อมูลจากไฟล์ 01_lcbp3_v1_4_3.sql และไฟล์อื่นๆ ที่คุณให้มาอย่างเคร่งครัดครับ มีส่วนไหนให้ผมดำเนินการต่อไหมครับ?

ช่วยอ่านไฟล์ 2_Backend_Plan_V1_4_4.md ในหัวข้อ T2.5.1-T2.5.9 และ โครงสร้างโมดูล แล้วสรุป รายการที่ต้องการสร้างหรือแก้ไขโมดูล ในแต่ละข้อก่อนเริ่มดำเนินการต่อครับ

สวัสดีครับ ผมได้วิเคราะห์ไฟล์ 2_Backend_Plan_V1_4_4.md ในส่วนของ Phase 2: High-Integrity Data & File Management โดยเฉพาะหัวข้อ T2.5 JSON Details & Schema Management (T2.5.1 - T2.5.9) เรียบร้อยแล้วครับ

นี่คือสรุปรายการโมดูล, ไฟล์ และฟังก์ชันที่ต้องสร้างหรือแก้ไข เพื่อให้ระบบจัดการ JSON Schema สมบูรณ์และมีประสิทธิภาพสูงสุดครับ

Context: We are entering Phase 3: Unified Workflow Engine of the NAP-DMS project. Please analyze the following documents in detail:

  1. 2_Backend_Plan_V1_4_4.md: Focus on Phase 3 Unified Workflow Engine (Tasks T3.1 - T3.1.9) and โครงสร้างโมดูล (Domain-Driven)

  2. 0_Requirements_V1_4_4.md: Focus on Section 2.4 Business Logic & Consistency, Section 3.2 การจัดการเอกสารโต้ตอบ (Correspondence Management) and 3.5 การจัดการเอกสารขออนุมัติ (Request for Approval & Workflow).

  3. 1_FullStackJS_V1_4_4.md: Focus on Section 3.5 Unified Workflow Engine, 3.9.13 CorrespondenceRoutingModule, 3.9.14 WorkflowEngineModule.

Goal: Prepare to implement coding for Unified Workflow Engine.

Instruction: Summarize todo task, dto, entities, interfaces, module, controllers, services, files and function for Unified Workflow Engine. Do not write code yet, just confirm your understanding of the todo task.

รับทราบครับ ผมได้วิเคราะห์เอกสาร 2_Backend_Plan_V1_4_4.md, 0_Requirements_V1_4_4.md, และ 1_FullStackJS_V1_4_4.md โดยเน้นไปที่ Phase 3: Unified Workflow Engine เรียบร้อยแล้ว

สรุปความเข้าใจและโครงสร้างงานที่จะต้องดำเนินการใน Phase นี้ มีรายละเอียดดังนี้ครับ:

🎯 ภาพรวม (Overview)

เป้าหมายคือการสร้าง Unified Workflow Engine ที่เป็นระบบกลางในการจัดการ Business Logic ของการเดินเอกสารทั้งหมด (ทั้ง Correspondence Routing ปกติ และ RFA Approval Workflow ที่ซับซ้อน) โดยไม่ผูกติดกับ Hard-coded logic ในโค้ด แต่จะขับเคลื่อนด้วย DSL (Domain-Specific Language) และ Configuration เพื่อความยืดหยุ่นในการปรับเปลี่ยน Flow, การข้ามขั้นตอน, หรือการส่งกลับ

📋 1. รายการสิ่งที่ต้องทำ (Todo Tasks)

อ้างอิงจาก Task T3.1 - T3.1.9 ในแผน Backend:

  1. T3.1.1 DSL Specification: กำหนด Grammar (YAML/JSON) สำหรับเขียน Workflow (State, Transition, Condition, Event).
  2. T3.1.2 Core Entities: สร้าง Entity ใหม่สำหรับเก็บ Definition และ Instance ของ Workflow.
  3. T3.1.3 DSL Parser & Compiler: สร้าง Service แปลง YAML DSL เป็น JSON Schema ที่ Engine เข้าใจ.
  4. T3.1.4 Runtime Engine: สร้าง State Machine Logic (เปลี่ยนสถานะ, ตรวจสิทธิ์, ตรวจเงื่อนไข).
  5. T3.1.5 Advanced Features: รองรับ Parallel Approval, Conditional Transition (JS Expression), Timeout.
  6. T3.1.6 Event System: จัดการ Event เมื่อเปลี่ยนสถานะ (Notify, Assign, Webhook).
  7. T3.1.7 API Implementation: สร้าง Controller สำหรับจัดการ Definition และสั่ง Transition.
  8. T3.1.8 Integration: เชื่อมต่อ Engine เข้ากับ Module เดิม (Correspondence, RFA).
  9. T3.1.9 Testing: เขียน Unit/Integration Test สำหรับ Engine.

🗂️ 2. โครงสร้างไฟล์และโมดูล (File & Module Structure)

เราจะสร้าง Module ใหม่ชื่อ workflow-engine และปรับปรุง Modules ที่เกี่ยวข้องตามโครงสร้าง Domain-Driven ดังนี้:

Module: src/modules/workflow-engine

📂 Entities (.entity.ts)

  • WorkflowDefinition: เก็บ Schema/DSL ของ Workflow (Code, Version, Compiled JSON).
  • WorkflowInstance: เก็บสถานะปัจจุบันของเอกสารแต่ละใบ (Current State, Context).
  • WorkflowHistory: เก็บ Audit Log ของการเปลี่ยนสถานะ (Who, When, From->To, Action).
  • WorkflowTransition: (Optional) อาจรวมอยู่ใน Definition หรือแยกเพื่อเก็บกฎการเปลี่ยนสถานะ.

📂 DTOs (.dto.ts)

  • CreateWorkflowDefinitionDto: รับ YAML/JSON string ของ DSL.
  • UpdateWorkflowDefinitionDto: แก้ไข DSL.
  • EvaluateWorkflowDto: รับ Action และ Context เพื่อประมวลผล.
  • WorkflowActionDto: รับคำสั่ง Transition (Approve, Reject, etc.).
  • GetAvailableActionsDto: ขอรายการ Action ที่ทำได้ ณ สถานะปัจจุบัน.

📂 Interfaces (.interface.ts)

  • WorkflowContext: โครงสร้างข้อมูลที่ส่งให้ Engine (User, Role, Document Data).
  • WorkflowState: นิยามโครงสร้าง State ใน Memory.
  • TransitionResult: ผลลัพธ์หลังประมวลผล (Success, NewState, SideEffects).

📂 Services (.service.ts)

  • WorkflowDslService:
    • parse(yaml): แปลง YAML เป็น Object.
    • validate(schema): ตรวจสอบความถูกต้องของ Logic.
    • compile(schema): แปลงเป็น Optimized JSON สำหรับ Runtime.
  • WorkflowEngineService (Core):
    • initialize(definitionId, context): เริ่มต้น Workflow ใหม่.
    • processAction(instanceId, action, context): ประมวลผลคำสั่งเปลี่ยนสถานะ.
    • getAvailableActions(instanceId, context): คืนค่าปุ่มที่ user กดได้.
    • validateCondition(rule, context): ตรวจสอบเงื่อนไข (เช่น ต้องเป็น Role Engineer).
  • WorkflowEventService:
    • dispatchEvent(event, context): ยิง Event ไปยัง Notification หรือ External Service.

📂 Controller (.controller.ts)

  • WorkflowEngineController:
    • POST /definitions: สร้าง/อัพเดท Workflow Rules.
    • POST /instances/:id/transition: สั่งเปลี่ยนสถานะเอกสาร.
    • GET /instances/:id/actions: ดึง Action ที่ทำได้.
    • GET /instances/:id/history: ดูประวัติการเดินเรื่อง.

🔗 3. การเชื่อมต่อกับระบบเดิม (Integration)

Module: CorrespondenceRoutingModule (ปรับปรุงจากเดิม)

  • ทำหน้าที่เป็น "Client" ของ Workflow Engine.
  • เมื่อมีการสร้าง Correspondence -> เรียก WorkflowEngineService.initialize().
  • เมื่อ User กดปุ่มในหน้า Routing -> เรียก WorkflowEngineService.processAction().
  • Map สถานะจาก Engine กลับมา update ตาราง correspondence_routings เพื่อ Backward Compatibility (หรือ migrate ไปใช้ WorkflowInstance เต็มรูปแบบตามแผน).

Module: RfaModule (ปรับปรุง)

  • ใช้ Logic เดียวกับ Correspondence แต่ใช้ Definition ที่ซับซ้อนกว่า (RFA Workflow Definition).
  • ใช้ Context ที่มีข้อมูล Shop Drawing / Technical data ในการตัดสินใจ Condition.

✅ 4. สรุปความพร้อม

ผมเข้าใจโครงสร้างและสิ่งที่ต้องทำครบถ้วนแล้วครับ:

  1. Logic: ย้าย Business Logic การเดินเอกสารออกจาก Service ปกติ เข้าสู่ Centralized Engine.
  2. Data: ใช้ workflow_definitions และ workflow_instances เป็นตัวขับเคลื่อน.
  3. Flexibility: รองรับการปรับ Flow ผ่าน DSL โดยไม่ต้องแก้โค้ด (Hot Reload config).

สถานะ: พร้อมสำหรับการเริ่มเขียนโค้ดใน Phase 3 (Task T3.1) ครับ

คุณต้องการให้ผมเริ่มที่ Task T3.1.1 (DSL Specification) หรือเริ่มสร้างโครงสร้าง Module และ Entity (T3.1.2) ก่อนดีครับ?

รับทราบครับ ผมจะดำเนินการสร้าง Data Dictionary ให้ตามที่ร้องขอครับ

จากการวิเคราะห์ SQL script 8_lcbp3_v1_4_4.sql และข้อมูลที่คุณเลือกมา ผมได้สรุปโครงสร้างตารางและรายละเอียดของตารางสำหรับ Unified Workflow Engine ใน Phase 3 มาให้แล้วครับ

Data Dictionary: Unified Workflow Engine (Phase 3)

1. workflow_definitions

Purpose: ตารางเก็บนิยามกฎการเดินเอกสาร (Workflow DSL) ที่เป็นแม่แบบสำหรับการสร้าง Workflow Instance

Column Name Data Type Constraints Description
id CHAR(36) PK, NOT NULL รหัส UUID ของ Workflow Definition
workflow_code VARCHAR(50) NOT NULL รหัส Workflow เช่น RFA_FLOW_V1, CORRESPONDENCE_FLOW_V1
version INT NOT NULL, DEFAULT 1 หมายเลข Version ของ Workflow (Running Number)
description TEXT NULL คำอธิบายรายละเอียดของ Workflow
dsl JSON NOT NULL ข้อมูลนิยาม Workflow ต้นฉบับในรูปแบบ JSON (ที่แปลงมาจาก YAML/JSON Format)
compiled JSON NOT NULL โครงสร้าง Execution Tree ที่ผ่านการ Compile และ Optimize แล้ว พร้อมสำหรับการ Runtime
is_active BOOLEAN DEFAULT TRUE สถานะการใช้งาน (TRUE = ใช้งาน, FALSE = ยกเลิก/ปิดใช้งาน)
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP วันที่และเวลาที่สร้าง
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP วันที่และเวลาที่แก้ไขล่าสุด

Indexes:

  • PRIMARY KEY (id)
  • UNIQUE KEY uq_workflow_version (workflow_code, version): ป้องกันการมี Workflow Code และ Version ซ้ำกัน
  • INDEX idx_workflow_active (workflow_code, is_active, version): สำหรับการค้นหา Workflow ที่ Active ล่าสุดได้อย่างรวดเร็ว

2. workflow_instances

Purpose: ตารางเก็บสถานะการเดินเรื่องจริงของเอกสารแต่ละฉบับ (Runtime State)

Column Name Data Type Constraints Description
id CHAR(36) PK, NOT NULL รหัส UUID ของ Workflow Instance
definition_id CHAR(36) FK, NOT NULL อ้างอิงไปยัง workflow_definitions.id เพื่อระบุว่าใช้กฎชุดไหน
entity_type VARCHAR(50) NOT NULL ประเภทเอกสารที่ผูกกับ Workflow นี้ เช่น rfa_revision, correspondence_revision, circulation
entity_id VARCHAR(50) NOT NULL รหัสอ้างอิง (ID) ของเอกสาร (เก็บเป็น String เพื่อรองรับทั้ง Int และ UUID)
current_state VARCHAR(50) NOT NULL ชื่อสถานะปัจจุบันของเอกสาร เช่น DRAFT, IN_REVIEW, APPROVED
status ENUM DEFAULT 'ACTIVE' สถานะภาพรวมของ Workflow Instance: 'ACTIVE', 'COMPLETED', 'CANCELLED', 'TERMINATED'
context JSON NULL ตัวแปร Context สำหรับใช้ประกอบการตัดสินใจใน Workflow (Runtime Data)
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP วันที่และเวลาที่สร้าง Instance
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP วันที่และเวลาที่อัปเดตสถานะล่าสุด

Indexes:

  • PRIMARY KEY (id)
  • INDEX idx_wf_inst_entity (entity_type, entity_id): สำหรับค้นหา Instance จากเอกสารต้นทาง
  • INDEX idx_wf_inst_state (current_state): สำหรับค้นหาเอกสารตามสถานะ Workflow
  • CONSTRAINT fk_wf_inst_def FOREIGN KEY (definition_id) REFERENCES workflow_definitions(id) ON DELETE CASCADE

3. workflow_histories

Purpose: ตารางเก็บประวัติการเปลี่ยนสถานะ (Audit Log / History) เพื่อตรวจสอบย้อนหลัง

Column Name Data Type Constraints Description
id CHAR(36) PK, NOT NULL รหัส UUID ของ History Record
instance_id CHAR(36) FK, NOT NULL อ้างอิงไปยัง workflow_instances.id
from_state VARCHAR(50) NOT NULL สถานะต้นทางก่อนการเปลี่ยนแปลง
to_state VARCHAR(50) NOT NULL สถานะปลายทางหลังการเปลี่ยนแปลง
action VARCHAR(50) NOT NULL ชื่อ Action ที่ผู้ใช้กระทำ เช่น SUBMIT, APPROVE, REJECT
action_by_user_id INT NULL รหัสผู้ใช้งาน (User ID) ที่ทำการเปลี่ยนสถานะ (NULL กรณี System Auto)
comment TEXT NULL ความคิดเห็นเพิ่มเติมประกอบการกระทำ
metadata JSON NULL Snapshot ข้อมูล Context หรือรายละเอียดเพิ่มเติม ณ ขณะนั้น
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP วันที่และเวลาที่เกิดเหตุการณ์

Indexes:

  • PRIMARY KEY (id)
  • INDEX idx_wf_hist_instance (instance_id): สำหรับดึงประวัติทั้งหมดของ Instance หนึ่งๆ
  • INDEX idx_wf_hist_user (action_by_user_id): สำหรับดูประวัติการทำงานของผู้ใช้แต่ละคน
  • CONSTRAINT fk_wf_hist_inst FOREIGN KEY (instance_id) REFERENCES workflow_instances(id) ON DELETE CASCADE

ER Diagram Concept

erDiagram
    workflow_definitions ||--o{ workflow_instances : "defines"
    workflow_instances ||--o{ workflow_histories : "has history"

    workflow_definitions {
        char(36) id PK
        varchar(50) workflow_code
        int version
        json dsl
        json compiled
        boolean is_active
    }

    workflow_instances {
        char(36) id PK
        char(36) definition_id FK
        varchar(50) entity_type
        varchar(50) entity_id
        varchar(50) current_state
        enum status
        json context
    }

    workflow_histories {
        char(36) id PK
        char(36) instance_id FK
        varchar(50) from_state
        varchar(50) to_state
        varchar(50) action
        int action_by_user_id
        text comment
        json metadata
    }

ข้อมูลนี้อ้างอิงจากไฟล์ SQL Script ล่าสุดที่คุณเลือกมาครับ หากต้องการแก้ไขหรือเพิ่มเติมส่วนไหน แจ้งได้เลยครับ

Reference in New Issue View Git Blame Copy Permalink