ກົມຈັດຕັ້ງDepartment of Organization

Employee Evaluation System

ລະບົບປະເມີນຜົນງານພະນັກງານ

ລະບົບກາງສໍາລັບຈັດການຮອບປະເມີນ, ມອບໝາຍຜູ້ປະເມີນ, ລວມຄະແນນ, ກວດສອບອະນຸມັດ ແລະອອກລາຍງານຕາມສິດ.

ຫຼຸດຄວາມຜິດພາດຈາກ Excel ແລະສູດຄໍານວນທີ່ບໍ່ຄົງທີ່

ຄວບຄຸມສິດການເບິ່ງຂໍ້ມູນຕາມ role ແລະ ພະແນກ

ຕິດຕາມສະຖານະການປະເມີນ, ກວດສອບ, ອະນຸມັດ ແລະປິດຮອບ

ຮອບປະເມີນ 2026Open

8.7ຄະແນນສະເລ່ຍ

Self 100%Peer 82%Review 64%Export Ready

ພາບລວມຂັ້ນຕອນ

ແຜນວາດພາບລວມຂັ້ນຕອນ

ແຜນວາດນີ້ສະແດງລໍາດັບວຽກຕັ້ງແຕ່ການກຽມຂໍ້ມູນ ໄປຈົນຮອດການອະນຸມັດ ແລະອອກລາຍງານ.

ພາບລວມຂັ້ນຕອນ

1. ກຽມຂໍ້ມູນພື້ນຖານ

2. ສ້າງຮອບປະເມີນ

3. ມອບໝາຍຜູ້ຮັບຜິດຊອບພະແນກ

4. ສ້າງລາຍການມອບໝາຍຜູ້ປະເມີນ

5. ກວດຄວາມຄົບຖ້ວນ

6. ຄໍານວນຄະແນນ

7. ກວດສອບ ແລະ ອະນຸມັດ

8. ປິດຮອບ ແລະ ອອກລາຍງານ

Developer Flowchart

Flowchart ອະທິບາຍຄົບ 8 Process

ສ່ວນນີ້ແຍກ flow ຍ່ອຍຂອງແຕ່ລະ process ໃຫ້ dev ອ່ານ logic, permission, validation, decision ແລະ output ທີ່ API/UI ຄວນໃຊ້ຮ່ວມກັນ.

1.1

ກວດຄວາມພ້ອມຂໍ້ມູນພື້ນຖານ

Flow ນີ້ໃຫ້ dev ເຫັນ logic ກ່ອນສ້າງຮອບປະເມີນ: ລະບົບຕ້ອງກວດຂໍ້ມູນຫຼັກ, permission, scope ແລະ master data ໃຫ້ຜ່ານກ່ອນ.

Super Admin / System Admin

Startເລືອກເມນູຂໍ້ມູນພື້ນຖານ

Admin ເຂົ້າໜ້າ setup ຫຼື core data ເພື່ອເລີ່ມ readiness check.

UI actionRun readiness check

UI ສົ່ງ request ໄປ `/api/core/validation` ໂດຍແນບ session user ແລະ scope ປັດຈຸບັນ.

DecisionSession ແລະ permission ຖືກຕ້ອງບໍ?

NoReject request

ສົ່ງ `401/403`, ບໍ່ດຶງຂໍ້ມູນ DB ແລະສະແດງ permission error.

YesContinue validation

ອ່ານ role, department scope ແລະເລີ່ມກວດ core data ຕາມລໍາດັບ.

DB validationກວດຂໍ້ມູນຫຼັກ 4 ກຸ່ມ

1.1.2

ກວດ Organization Unit

ຕ້ອງມີກົມ, ພະແນກ ຫຼື section ທີ່ active ແລະໃຊ້ເປັນ department scope ໄດ້.

1.1.3

ກວດ Employee

Employee ຕ້ອງ active, ມີ employee code, position, level ແລະ org_unit_id.

1.1.4

ກວດ User, Role, Scope

User ຕ້ອງ active, ມີ role ຖືກຕ້ອງ ແລະ Department Admin/Reviewer/Approver ຕ້ອງມີ scope.

1.1.5

ກວດ Master Data

ກວດ category, criteria, score grade, position type ແລະຊ່ວງຄະແນນ 1-10.

1.1.6ສ້າງ Readiness Result

API ສົ່ງຜົນກັບມາເປັນ passed/failed ພ້ອມ missing items ໃຫ້ UI ສະແດງ. Output ຄວນມີ `passed`, `missing`, `warnings` ແລະ `nextProcess`.

Decisionຂໍ້ມູນພື້ນຖານຄົບບໍ?

Noບໍ່ຄົບ: ສະແດງ missing items, ໃຫ້ Admin ແກ້ຂໍ້ມູນ ແລະ run check ໃໝ່.

UI ສະແດງ checklist ທີ່ຂາດ, Admin ແກ້ organization/user/employee/master data ແລ້ວກົດ check ໃໝ່.

Loop back -> Run readiness check

Yesຄົບ: ອະນຸຍາດໃຫ້ໄປ process 2.1 ສ້າງຮອບປະເມີນ.

UI enable ປຸ່ມສ້າງຮອບປະເມີນ ແລະສົ່ງຕໍ່ໄປ setup process ຖັດໄປ.

Next -> Process 2.1

Dev notes

Route/API ທີ່ຄວນຜູກ: `/api/core/validation` ຫຼື setup readiness endpoint.
ຜົນ check ຄວນສົ່ງກັບເປັນ structured JSON: `passed`, `missing`, `warnings`, `nextProcess`.
ທຸກການແກ້ role, employee, master data ແລະ scope ຄວນບັນທຶກ audit log.

2.1

ສ້າງຮອບປະເມີນ

Flow ນີ້ໃຫ້ dev ເຫັນ logic ການສ້າງ evaluation period ຈາກ core data ທີ່ຜ່ານ readiness check ແລ້ວ.

Super Admin

Startເລືອກເມນູສ້າງຮອບ

Super Admin ເຂົ້າໜ້າ evaluation periods ແລະກົດສ້າງຮອບໃໝ່.

API actionCreate evaluation period

UI ສົ່ງ `POST /api/setup/evaluation-periods` ພ້ອມ payload ຂອງ period form.

Decisionຜູ້ໃຊ້ສ້າງຮອບໄດ້ບໍ?

NoBlock create period

ສົ່ງ `403`, ບໍ່ບັນທຶກ period ແລະແຈ້ງວ່າບໍ່ມີ permission.

YesValidate period payload

ກວດ readiness, form payload, date range ແລະ duplicate period.

Period validationກວດຂໍ້ມູນຮອບ 4 ກຸ່ມ

2.1.2

ກວດ Readiness Result

ຕ້ອງມີ readiness passed ຫຼື core data ພ້ອມກ່ອນຮັບ period form.

2.1.3

ຮັບຂໍ້ມູນຮອບ

ຮັບຊື່ຮອບ, ປີ, ວັນເລີ່ມ, ວັນສິ້ນສຸດ ແລະ result visibility policy.

2.1.4

Validate Date ແລະ Policy

ກວດ date range, duplicate period name/year ແລະ policy ທີ່ UI ເລືອກ.

2.1.5

ບັນທຶກ Draft Period

ສ້າງ evaluation period ສະຖານະ draft ແລະບັນທຶກ audit log.

2.1.6ສົ່ງ Period Result

API ສົ່ງ period id, status, validation warnings ແລະ next action ກັບ UI. Output ຄວນມີ `periodId`, `status`, `warnings` ແລະ `nextProcess`.

Decisionສ້າງຮອບສໍາເລັດບໍ?

Noບໍ່ສໍາເລັດ: ສະແດງ validation errors ແລະໃຫ້ Admin ແກ້ form.

UI ເນັ້ນ field ທີ່ຜິດ, ບໍ່ປ່ຽນ state ແລະໃຫ້ submit ໃໝ່.

Loop back -> Period form

Yesສໍາເລັດ: ໄປ process 3.1 ມອບໝາຍຜູ້ຮັບຜິດຊອບພະແນກ.

UI ເປີດໜ້າ department assignment ດ້ວຍ period id ທີ່ສ້າງແລ້ວ.

Next -> Process 3.1

Dev notes

Route/API ທີ່ຄວນຜູກ: `POST /api/setup/evaluation-periods`.
ສະຖານະ period ຫຼັງສ້າງຄວນເປັນ `draft` ກ່ອນເປີດຮອບ.
ການສ້າງ, ແກ້, ເປີດ ແລະປິດ period ຄວນມີ audit log.

3.1

ມອບໝາຍຜູ້ຮັບຜິດຊອບພະແນກ

Flow ນີ້ກໍານົດວ່າໃນຮອບປະເມີນໜຶ່ງ ແຕ່ລະພະແນກມີ owner, reviewer ແລະ approver ໃຜ.

Super Admin / Department Admin

Startເລືອກ Period ແລະ Department

Admin ເລືອກຮອບປະເມີນ draft/open ແລະ org unit ທີ່ຈະມອບໝາຍ.

API actionSave department assignment

UI ສົ່ງ `POST /api/setup/department-assignments` ພ້ອມ period, org unit, owner, reviewer ແລະ approver.

DecisionAdmin ຈັດການພະແນກນີ້ໄດ້ບໍ?

NoReject assignment

ສົ່ງ `403`, ບໍ່ບັນທຶກ assignment ແລະແຈ້ງ scope error.

YesContinue assignment

ກວດ period, org unit, active user ແລະ reviewer/approver role.

Assignment validationກວດການມອບໝາຍ 4 ກຸ່ມ

3.1.2

Load Organization Scope

ດຶງລາຍຊື່ພະແນກທີ່ active ແລະຢູ່ໃນ scope ຂອງ Admin.

3.1.3

ເລືອກ Department Owner

ກໍານົດຜູ້ຮັບຜິດຊອບພະແນກທີ່ຈະຕິດຕາມ setup ແລະ progress.

3.1.4

ເລືອກ Reviewer / Approver

ກໍານົດຜູ້ກວດຂັ້ນ 1 ແລະຜູ້ອະນຸມັດຂັ້ນ 2 ທີ່ active.

3.1.5

Validate Duplicate ແລະ Scope

ກວດວ່າ department ບໍ່ຊໍ້າໃນ period ແລະ user ທຸກຄົນຢູ່ໃນ scope ທີ່ຖືກຕ້ອງ.

3.1.6ບັນທຶກ Assignment Result

API ບັນທຶກ department assignment ແລະສົ່ງ coverage ກັບ UI. Output ຄວນມີ `assignmentId`, `departmentCoverage`, `missingDepartments` ແລະ `nextProcess`.

Decisionພະແນກຖືກມອບໝາຍຄົບບໍ?

Noບໍ່ຄົບ: ສະແດງພະແນກທີ່ຍັງບໍ່ມີ owner/reviewer/approver.

UI ໃຫ້ Admin ເພີ່ມ assignment ຂອງພະແນກທີ່ຂາດ ຫຼືແກ້ scope ຂອງ user.

Loop back -> Department assignment

Yesຄົບ: ໄປ process 4.1 ສ້າງລາຍການມອບໝາຍຜູ້ປະເມີນ.

UI ສົ່ງ period ແລະ department assignment ໄປສ້າງ evaluator assignments.

Next -> Process 4.1

Dev notes

Route/API ທີ່ຄວນຜູກ: `/api/setup/department-assignments`.
ຄວນມີ unique key ປ້ອງກັນ period + org unit ຊໍ້າ.
Reviewer ແລະ Approver ຕ້ອງກວດ role/scope ກ່ອນບັນທຶກ.

4.1

ສ້າງລາຍການມອບໝາຍຜູ້ປະເມີນ

Flow ນີ້ສ້າງ evaluator assignment ວ່າໃຜຕ້ອງປະເມີນໃຜ ແລະແຍກ self/peer ໃຫ້ຊັດເຈນ.

Super Admin / Department Admin

Startເລືອກ Department Assignment

Admin ເລືອກພະແນກທີ່ມີ owner/reviewer/approver ແລ້ວ.

API actionCreate evaluator assignments

UI ສົ່ງ `POST /api/setup/evaluator-assignments` ແບບ bulk ຫຼື single assignment.

DecisionAdmin ສ້າງ assignment ໃນ scope ນີ້ໄດ້ບໍ?

NoReject assignment request

ສົ່ງ `403`, ບໍ່ສ້າງ evaluator assignment ແລະແຈ້ງ scope error.

YesContinue assignment build

ກວດ employee, department assignment, assignment type ແລະ duplicate rule.

Evaluator validationກວດ evaluator assignment 4 ກຸ່ມ

4.1.2

Load Eligible Employees

ດຶງ employee active ໃນ org unit ແລະກວດ employee code, position, level.

4.1.3

Generate Self Assignment

ສ້າງ self assignment ໃຫ້ employee ແຕ່ລະຄົນປະເມີນຕົນເອງ.

4.1.4

Select Peer Assignment

ກໍານົດ evaluator ແລະ evaluatee ສໍາລັບ peer evaluation ຕາມນະໂຍບາຍ.

4.1.5

Validate Rule ແລະ Duplicate

ກວດວ່າ self ເປັນຄົນດຽວກັນ, peer ບໍ່ແມ່ນຄົນດຽວກັນ ແລະ assignment ບໍ່ຊໍ້າ.

4.1.6ບັນທຶກ Evaluator Assignments

API ສ້າງ pending assignments ແລະສົ່ງ progress ຂອງພະແນກກັບ UI. Output ຄວນມີ `created`, `skipped`, `duplicates`, `coverage` ແລະ `nextProcess`.

Decisionລາຍການຜູ້ປະເມີນຄົບບໍ?

Noບໍ່ຄົບ: ສະແດງ employee ຫຼື peer assignment ທີ່ຂາດ.

UI ໃຫ້ Admin ສ້າງ assignment ເພີ່ມ ຫຼືແກ້ evaluator/evaluatee ທີ່ຜິດ rule.

Loop back -> Evaluator assignment

Yesຄົບ: ໄປ process 5.1 ກວດ setup ກ່ອນຄໍານວນ.

UI ສົ່ງ period ໄປ final setup check ເພື່ອກວດຄວາມຄົບຖ້ວນ.

Next -> Process 5.1

Dev notes

Route/API ທີ່ຄວນຜູກ: `/api/setup/evaluator-assignments`.
Self assignment ຄວນຖືກ generate ອັດຕະໂນມັດຈາກ active employees.
ການສ້າງ assignment ແບບ bulk ຄວນສົ່ງ result ແຍກ created/skipped/errors.

5.1

ກວດຄວາມຄົບຖ້ວນ

Flow ນີ້ເປັນ final setup check ກ່ອນເດີນຕໍ່ ໂດຍກວດ department, evaluator, criteria ແລະ approval chain.

ລະບົບ / Super Admin

Startເລືອກ Period ເພື່ອກວດ

Admin ກົດ check completeness ຈາກ period ທີ່ກໍາລັງ setup.

API actionRun setup completeness check

UI ສົ່ງ request ໄປ setup check endpoint ພ້ອມ period id ແລະ session user.

DecisionAdmin ກວດ setup ຂອງ period ນີ້ໄດ້ບໍ?

NoReject check

ສົ່ງ `403`, ບໍ່ສະແດງ coverage ນອກ scope ແລະບັນທຶກ failed access.

YesRun coverage validation

ກວດ department, evaluator, criteria, grade ແລະ approval chain ຕາມລໍາດັບ.

Completeness validationກວດ setup ຫຼັກ 4 ກຸ່ມ

5.1.2

ກວດ Department Coverage

ກວດວ່າພະແນກ active ທີ່ຕ້ອງປະເມີນມີ department assignment ຄົບ.

5.1.3

ກວດ Evaluator Coverage

ກວດວ່າ employee ແຕ່ລະຄົນມີ self ແລະ peer assignment ຕາມ policy.

5.1.4

ກວດ Criteria ແລະ Grade

ກວດ active criteria, score range, grade mapping ແລະ position type ທີ່ຈໍາເປັນ.

5.1.5

ກວດ Reviewer / Approver

ກວດ approval chain ຂອງທຸກພະແນກວ່າ active ແລະມີ scope ຖືກຕ້ອງ.

5.1.6ສ້າງ Completeness Result

API ສົ່ງ passed/failed, missing items, blockers ແລະ next action ກັບ UI. Output ຄວນມີ `passed`, `blockers`, `missing`, `coverage` ແລະ `nextProcess`.

DecisionSetup ຄົບຖ້ວນບໍ?

Noບໍ່ຄົບ: ສະແດງ blockers ແລະສົ່ງກັບໄປແກ້ process 3-4.

UI ແຍກ missing items ຕາມພະແນກ, evaluator, criteria ແລະ approval chain ໃຫ້ Admin ແກ້.

Loop back -> Process 3-4

Yesຄົບ: ໄປ process 6.1 ຄໍານວນຄະແນນ.

UI unlock ຂັ້ນຕອນຖັດໄປ ຫຼືສົ່ງ period ເຂົ້າ calculation workflow.

Next -> Process 6.1

Dev notes

Endpoint ຄວນສົ່ງ structured coverage ເພື່ອໃຫ້ UI ແຍກ blockers ຕາມປະເພດ.
ບໍ່ຄວນໃຫ້ calculation ເລີ່ມຖ້າ setup check ຍັງ failed.
ຄວນ cache ຫຼື recompute coverage ທຸກຄັ້ງທີ່ assignment/master data ປ່ຽນ.

6.1

ຄໍານວນຄະແນນ

Flow ນີ້ໃຫ້ dev ເຫັນ service ກາງສໍາລັບລວມຄະແນນ self/peer, ຫາ average ແລະສ້າງ result ເພື່ອ review.

ລະບົບ

Startເລືອກ Period ຫຼື Employee

System ຫຼື Admin trigger calculation ຕາມ period, department ຫຼື employee.

Service actionRun score calculation

System ເອີ້ນ calculation service ຫຼື `POST /api/workflow/calculations` ດ້ວຍ period/employee scope.

Decisionຜູ້ trigger ເຫັນຂໍ້ມູນຄະແນນນີ້ໄດ້ບໍ?

NoReject calculation

ສົ່ງ `403`, ບໍ່ຄໍານວນນອກ scope ແລະບັນທຶກ audit log.

YesContinue calculation

ກວດ submitted scores, active criteria, calculation policy ແລະ grade mapping.

Calculation validationກວດ input ຄໍານວນ 4 ກຸ່ມ

6.1.2

Load Submitted Scores

ດຶງ self/peer scores ທີ່ submitted ແລະຜູກກັບ active criteria.

6.1.3

Validate Score Range

ກວດຄະແນນ 1-10, missing criteria, duplicate score ແລະ assignment status.

6.1.4

Compute Average

ຄໍານວນ self average, peer average ແລະ final score ຈາກຈໍານວນຜູ້ສົ່ງຈິງ.

6.1.5

Map Grade ແລະ Summary

ຜູກ final score ກັບ score grade, position type ແລະ summary ທີ່ report ໃຊ້.

6.1.6ສ້າງ Calculation Result

API ສົ່ງ result summary, warnings ແລະ review queue readiness ກັບ UI. Output ຄວນມີ `selfAverage`, `peerAverage`, `finalScore`, `grade`, `warnings` ແລະ `nextProcess`.

Decisionຄໍານວນຖືກຕ້ອງບໍ?

Noບໍ່ຖືກ: ສະແດງ missing scores/warnings ແລະໃຫ້ແກ້ input ກ່ອນຄໍານວນໃໝ່.

UI ຫຼື Admin queue ສະແດງ assignment/criteria ທີ່ຂາດ ແລະໃຫ້ rerun calculation ຫຼັງແກ້.

Loop back -> Fix score input

Yesຖືກຕ້ອງ: ໄປ process 7.1 ກວດສອບ ແລະ ອະນຸມັດ.

ຜົນຄໍານວນຖືກສົ່ງເຂົ້າ review queue ໂດຍມີ summary ພ້ອມໃຊ້.

Next -> Process 7.1

Dev notes

Calculation logic ຄວນຢູ່ server-side service ກາງ ບໍ່ໃຫ້ UI ຄໍານວນຊໍ້າ.
ຄວນບັນທຶກ calculation version ຫຼື timestamp ເພື່ອ audit ຜົນຄະແນນ.
Report ແລະ queue ຄວນອ່ານ result ຈາກ source ດຽວກັນ.

7.1

ກວດສອບ ແລະ ອະນຸມັດ

Flow ນີ້ລວມ review ຂັ້ນ 1 ແລະ approval ຂັ້ນ 2 ເພື່ອໃຫ້ dev ເຫັນ return/approve path ຊັດເຈນ.

Reviewer / Approver

StartLoad Review Queue

Reviewer ເຫັນລາຍການທີ່ calculation ພ້ອມ ແລະຢູ່ໃນ department scope.

Workflow actionReview and approve result

UI ເອີ້ນ `/api/workflow/reviews` ແລະ `/api/workflow/approvals` ຕາມຂັ້ນຕອນ.

DecisionReviewer/Approver ມີ scope ຂອງລາຍການນີ້ບໍ?

NoReject workflow action

ສົ່ງ `403`, ບໍ່ update status ແລະບັນທຶກ failed access.

YesContinue workflow action

ກວດ current status, scope, reason ແລະ action ທີ່ອະນຸຍາດ.

Review validationກວດ workflow 4 ກຸ່ມ

7.1.2

Reviewer Check

ກວດ summary, score, comment, missing data ແລະເລືອກ reviewed ຫຼື returned.

7.1.3

Handle Review Return

ຖ້າ return ຕ້ອງມີ reason, update status ແລະສົ່ງກັບໄປໃຫ້ແກ້.

7.1.4

Load Approval Queue

Approver ເຫັນສະເພາະລາຍການ reviewed ແລະຢູ່ໃນ approval scope.

7.1.5

Approver Decision

Approver ເລືອກ approve ຫຼື return ພ້ອມ reason ແລະ final comment.

7.1.6ສ້າງ Approval Result

API update status, lock approved result ແລະສົ່ງ approval summary ກັບ UI. Output ຄວນມີ `status`, `action`, `reason`, `locked`, `auditLogId` ແລະ `nextProcess`.

Decisionກວດສອບ ແລະ ອະນຸມັດຜ່ານບໍ?

Noບໍ່ຜ່ານ: return ພ້ອມ reason ແລະສົ່ງກັບໄປແກ້ຕາມ status.

UI ສະແດງ reason, ປົດ lock ຕາມ policy ແລະສົ່ງວຽກກັບໄປ Employee/Admin queue.

Loop back -> Fix and resubmit

Yesຜ່ານ: ໄປ process 8.1 ປິດຮອບ ແລະ ອອກລາຍງານ.

ຜົນ approved ຖືກ lock, report ສາມາດໃຊ້ຂໍ້ມູນ final ແລະລໍຖ້າປິດຮອບ.

Next -> Process 8.1

Dev notes

Review action ແລະ approval action ຄວນແຍກ endpoint ແຕ່ໃຊ້ status policy ກາງ.
Return ທຸກຄັ້ງຕ້ອງມີ reason ແລະ audit log.
Approved result ຄວນ lock ເພື່ອປ້ອງກັນ score drift ກ່ອນປິດຮອບ.

8.1

ປິດຮອບ ແລະ ອອກລາຍງານ

Flow ນີ້ປິດ lifecycle ຂອງ evaluation period, lock ຂໍ້ມູນສໍາຄັນ ແລະເປີດການ export/report ຕາມສິດ.

Super Admin

Startເລືອກ Period ເພື່ອປິດ

Super Admin ເລືອກ period ທີ່ open ແລະກວດ final status ກ່ອນປິດ.

Admin actionClose period and export

UI ເອີ້ນ close endpoint ແລະ report/export routes ຕາມ permission ຂອງ user.

DecisionSuper Admin ປິດຮອບນີ້ໄດ້ບໍ?

NoBlock close period

ສົ່ງ `403`, ບໍ່ປ່ຽນ status ແລະບັນທຶກ failed close attempt.

YesContinue close validation

ກວດ approval coverage, report readiness, export permission ແລະ audit trail.

Closure validationກວດກ່ອນປິດຮອບ 4 ກຸ່ມ

8.1.2

Verify Approval Coverage

ກວດວ່າລາຍການທີ່ຕ້ອງປະເມີນຜ່ານ review/approval ຕາມ policy.

8.1.3

Generate Reports

ສ້າງ employee report, department status, organization summary ແລະ stage reports.

8.1.4

Validate Export Permission

ກວດ role, department scope, result visibility ແລະ export contract ກ່ອນດາວໂຫຼດ.

8.1.5

Close Period ແລະ Lock Data

ປ່ຽນ period status ເປັນ closed, lock result ແລະບັນທຶກ audit log.

8.1.6ສົ່ງ Close Result

API ສົ່ງ close status, report availability, export links ແລະ audit summary ກັບ UI. Output ຄວນມີ `periodStatus`, `closedAt`, `reportReady`, `exportReady` ແລະ `auditLogId`.

Decisionປິດຮອບສໍາເລັດບໍ?

Noບໍ່ສໍາເລັດ: ສະແດງ blockers ເຊັ່ນ approval ບໍ່ຄົບ ຫຼື report ບໍ່ພ້ອມ.

UI ສະແດງ blockers, ໃຫ້ Admin ກັບໄປ review/approve/report check ແລ້ວກົດ close ໃໝ່.

Loop back -> Resolve blockers

Yesສໍາເລັດ: workflow ຂອງຮອບນີ້ຈົບ ແລະ report/export ພ້ອມໃຊ້.

UI ສະແດງ status closed, ປິດປຸ່ມແກ້ຂໍ້ມູນສໍາຄັນ ແລະເປີດ export/report.

Done -> Workflow complete

Dev notes

Route/API ທີ່ຄວນຜູກ: `/api/setup/evaluation-periods/[id]/close` ແລະ report/export routes.
Close action ຄວນເປັນ atomic transaction ເພື່ອປ້ອງກັນ status/report ບໍ່ກົງກັນ.
Export ຕ້ອງກວດ role, scope, visibility policy ແລະບັນທຶກ audit log.

Workflow

ຂັ້ນຕອນຫຼັກຂອງການປະເມີນ

01ກຽມຂໍ້ມູນພື້ນຖານ

02ສ້າງຮອບປະເມີນ

03ມອບໝາຍຜູ້ຮັບຜິດຊອບພະແນກ

04ສ້າງ Assignment ຜູ້ປະເມີນ

05ກວດ Setup ໃຫ້ຄົບ

06ເປີດຮອບປະເມີນ

07Employee ປະເມີນ Self / Peer

08ກວດການສົ່ງຄົບຖ້ວນ

09ຄໍານວນຄະແນນ

10Reviewer ກວດຂັ້ນ 1

11Approver ອະນຸມັດຂັ້ນ 2

12ລາຍງານ, Export ແລະ Audit

13ປິດຮອບປະເມີນ

ອະທິບາຍ workflow ແບບລະອຽດ

ການເດີນງານຂອງລະບົບເລີ່ມຈາກການກໍານົດຮອບປະເມີນ, ກຽມຂໍ້ມູນ, ມອບໝາຍຜູ້ປະເມີນ, ຮັບຄະແນນ, ກວດສອບ, ອະນຸມັດ ແລະປິດຮອບພ້ອມລາຍງານ.

ກຽມຂໍ້ມູນພື້ນຖານ

Super Admin / System Admin

ເລີ່ມເມື່ອ: ເລີ່ມຕົ້ນກ່ອນສ້າງຮອບປະເມີນ
ວຽກທີ່ເຮັດ: ກວດ organization unit, employee, user account, role, department scope, category, criteria, grade, Reviewer ແລະ Approver.
ເງື່ອນໄຂ: ຜູ້ໃຊ້ຕ້ອງ active, employee ຕ້ອງຜູກ org unit, role/scope ຕ້ອງກົງກັບໜ້າທີ່.
ຜົນລັບ: ຂໍ້ມູນກາງພ້ອມໃຊ້ ແລະ permission ຄວບຄຸມຂອບເຂດໄດ້ຕັ້ງແຕ່ຕົ້ນ.
ຂັ້ນຕໍ່ໄປ: ໄປສ້າງຮອບປະເມີນ.

ສ້າງຮອບປະເມີນ

Super Admin

ເລີ່ມເມື່ອ: ຂໍ້ມູນພື້ນຖານພ້ອມແລ້ວ
ວຽກທີ່ເຮັດ: ກໍານົດຊື່ຮອບ, ປີ, ວັນເລີ່ມ, ວັນສິ້ນສຸດ ແລະ result visibility policy.
ເງື່ອນໄຂ: ວັນສິ້ນສຸດຕ້ອງບໍ່ກ່ອນວັນເລີ່ມ, ຜູ້ສ້າງຕ້ອງມີ permission ແລະຕ້ອງບັນທຶກ audit log.
ຜົນລັບ: ຮອບປະເມີນຢູ່ສະຖານະ draft ແລະຍັງບໍ່ເປີດໃຫ້ພະນັກງານສົ່ງຄະແນນ.
ຂັ້ນຕໍ່ໄປ: ໄປກໍານົດຜູ້ຮັບຜິດຊອບພະແນກ.

ມອບໝາຍຜູ້ຮັບຜິດຊອບພະແນກ

Super Admin / Department Admin

ເລີ່ມເມື່ອ: ມີ evaluation period ສະຖານະ draft ຫຼື open
ວຽກທີ່ເຮັດ: ເລືອກ org unit, ກໍານົດ owner, Reviewer ຂັ້ນ 1 ແລະ Approver ຂັ້ນ 2; ລະບົບສ້າງ self/peer assignment ໃຫ້ອັດຕະໂນມັດ.
ເງື່ອນໄຂ: ພະແນກໃນຮອບດຽວກັນຕ້ອງບໍ່ຊໍ້າ, owner/reviewer/approver ຕ້ອງ active ແລະ peer ຈະຖືກຈັບຄູ່ສະເພາະແຂນງ/ໜ່ວຍດຽວກັນ.
ຜົນລັບ: ລະບົບຮູ້ວ່າແຕ່ລະພະແນກມີໃຜດູແລ ແລະ assignment ຖືກສ້າງເປັນ pending.
ຂັ້ນຕໍ່ໄປ: ໄປກວດ setup ໃຫ້ຄົບກ່ອນເປີດຮອບ.

ສ້າງ Assignment ຜູ້ປະເມີນ

ລະບົບ

ເລີ່ມເມື່ອ: ບັນທຶກ department assignment
ວຽກທີ່ເຮັດ: ຂະຫຍາຍ org scope, ດຶງພະນັກງານທີ່ຜ່ານ eligibility ແລະສ້າງ assignment ປະເພດ self/peer ອັດຕະໂນມັດ.
ເງື່ອນໄຂ: Self ຕ້ອງເປັນຄົນດຽວກັນ, peer ຕ້ອງເປັນຄົນລະຄົນແລະຢູ່ແຂນງ/ໜ່ວຍດຽວກັນ, assignment ຊໍ້າໃນຮອບດຽວກັນຕ້ອງຖືກປ້ອງກັນ.
ຜົນລັບ: assignment ຖືກສ້າງເປັນ pending ແລະ Employee ຈະເຫັນສະເພາະວຽກຂອງຕົນ.
ຂັ້ນຕໍ່ໄປ: ໄປກວດ setup ໃຫ້ຄົບກ່ອນເປີດຮອບ.

ກວດ Setup ໃຫ້ຄົບ

ລະບົບ / Super Admin

ເລີ່ມເມື່ອ: ກ່ອນກົດເປີດຮອບ
ວຽກທີ່ເຮັດ: ກວດວ່າມີ department assignment, evaluator assignment, Reviewer, Approver ແລະ active criteria ພ້ອມໃຊ້.
ເງື່ອນໄຂ: ຖ້າ setup ບໍ່ຄົບ ຕ້ອງກັບໄປມອບໝາຍພະແນກ ຫຼືສ້າງ assignment ໃຫ້ຄົບ.
ຜົນລັບ: ຮອບທີ່ຜ່ານ check ພ້ອມເປີດໃຫ້ Employee ເຂົ້າປະເມີນ.
ຂັ້ນຕໍ່ໄປ: ຖ້າຄົບແລ້ວໄປເປີດຮອບ, ຖ້າບໍ່ຄົບກັບໄປ process 3-4.

ເປີດຮອບປະເມີນ

Super Admin

ເລີ່ມເມື່ອ: Setup ພ້ອມແລະ period ຍັງເປັນ draft
ວຽກທີ່ເຮັດ: ກົດເປີດຮອບ ແລະປ່ຽນສະຖານະ period ເປັນ open.
ເງື່ອນໄຂ: ຕ້ອງມີ permission ເປີດຮອບ ແລະຕ້ອງບັນທຶກ audit log.
ຜົນລັບ: Employee ເຫັນ assignment ໃນ dashboard ແລະເລີ່ມ save draft/submit ໄດ້.
ຂັ້ນຕໍ່ໄປ: ໄປຂັ້ນ Employee ປະເມີນ.

Employee ປະເມີນ Self / Peer

Employee

ເລີ່ມເມື່ອ: ຮອບປະເມີນເປີດແລ້ວ
ວຽກທີ່ເຮັດ: ເປີດ assignment self ຫຼື peer, ກອກຄະແນນຕາມ criteria, save draft ຫຼື submit.
ເງື່ອນໄຂ: ຄະແນນຕ້ອງຢູ່ໃນຊ່ວງ 1-10 ຫຼືຕາມ master data, submit ຕ້ອງກອກຄົບທຸກ active criteria.
ຜົນລັບ: assignment ປ່ຽນເປັນ draft ເມື່ອ save ຫຼື submitted ເມື່ອ submit ແລະຖືກ lock ຕາມນະໂຍບາຍ.
ຂັ້ນຕໍ່ໄປ: ໄປກວດວ່າສົ່ງແບບປະເມີນຄົບຫຼືບໍ່.

ກວດການສົ່ງຄົບຖ້ວນ

ລະບົບ / Department Admin

ເລີ່ມເມື່ອ: ມີການ submit assignment
ວຽກທີ່ເຮັດ: ກວດຈໍານວນ self/peer assignment ທີ່ submitted ຕໍ່ employee ແລະຕໍ່ພະແນກ.
ເງື່ອນໄຂ: ຖ້າຍັງບໍ່ຄົບ ວຽກຍັງຢູ່ dashboard Employee ຫຼື tracking ຂອງ Department Admin.
ຜົນລັບ: ຜູ້ທີ່ສົ່ງຄົບຈະພ້ອມໃຫ້ລະບົບຄໍານວນ ແລະເຂົ້າ review queue.
ຂັ້ນຕໍ່ໄປ: ຖ້າຄົບໄປຄໍານວນຄະແນນ, ຖ້າບໍ່ຄົບກັບໄປ process 7.

ຄໍານວນຄະແນນ

ລະບົບ

ເລີ່ມເມື່ອ: Employee ສົ່ງ assignment ຄົບຕາມເງື່ອນໄຂ
ວຽກທີ່ເຮັດ: ລວມຄະແນນ self ແລະ peer, ຫາຄ່າສະເລ່ຍຈາກຜູ້ສົ່ງຈິງ, ແຍກປະເພດຄະແນນ ແລະຫາ final score.
ເງື່ອນໄຂ: Report ແລະ queue ຕ້ອງໃຊ້ calculation service ກາງ ເພື່ອບໍ່ໃຫ້ UI ຄໍານວນຊໍ້າ.
ຜົນລັບ: ຜົນຄໍານວນພ້ອມໃຫ້ Reviewer ກວດສອບ ໂດຍແຍກ self, peer ແລະ final average ຊັດເຈນ.
ຂັ້ນຕໍ່ໄປ: ໄປ review queue ຂັ້ນ 1.

Reviewer ກວດຂັ້ນ 1

Reviewer

ເລີ່ມເມື່ອ: ຜົນຄໍານວນເຂົ້າ review queue
ວຽກທີ່ເຮັດ: Reviewer ກວດ summary, ຄະແນນ, ຄວາມຄົບຖ້ວນ ແລະເລືອກ review ຫຼື return.
ເງື່ອນໄຂ: Reviewer ເຫັນສະເພາະ scope ທີ່ຕົນຮັບຜິດຊອບ, ຖ້າ return ຕ້ອງມີ reason.
ຜົນລັບ: ຖ້າ review ຜ່ານ assignment ເປັນ reviewed, ຖ້າ return assignment ເປັນ returned ແລະ Employee ຕ້ອງແກ້.
ຂັ້ນຕໍ່ໄປ: ຖ້າຜ່ານໄປ approval queue, ຖ້າສົ່ງກັບໄປ process 7.

Approver ອະນຸມັດຂັ້ນ 2

Approver

ເລີ່ມເມື່ອ: Reviewer ກວດຜ່ານແລ້ວ
ວຽກທີ່ເຮັດ: Approver ກວດ final summary, ຄໍາເຫັນ Reviewer, ນະໂຍບາຍຄະແນນ ແລະເລືອກ approve ຫຼື return.
ເງື່ອນໄຂ: Approve ໄດ້ສະເພາະງານທີ່ reviewed, Approver ເຫັນສະເພາະ scope ແລະ return ຕ້ອງມີ reason.
ຜົນລັບ: ຖ້າ approve assignment ປ່ຽນເປັນ approved ແລະ lock, ຖ້າ return ກັບໄປໃຫ້ Employee ແກ້ໄຂ.
ຂັ້ນຕໍ່ໄປ: ຖ້າອະນຸມັດແລ້ວໄປລາຍງານ, ຖ້າສົ່ງກັບໄປ process 7.

ລາຍງານ, Export ແລະ Audit

Employee / Admin / Reviewer / Approver / Super Admin

ເລີ່ມເມື່ອ: ມີຂໍ້ມູນ submitted, reviewed ຫຼື approved ຕາມ policy
ວຽກທີ່ເຮັດ: ສ້າງ Employee Report, Department Status, Organization Summary, Stage 1, Stage 2 ແລະ Export Excel/PDF ຕາມສິດ.
ເງື່ອນໄຂ: Report ຕ້ອງກວດ role, department scope ແລະ result visibility policy. Export ຕ້ອງບັນທຶກ audit log.
ຜົນລັບ: ຜູ້ມີສິດເບິ່ງຜົນໄດ້ຖືກຂອບເຂດ ແລະມີ audit trail ສໍາລັບກວດຍ້ອນຫຼັງ.
ຂັ້ນຕໍ່ໄປ: ໄປກວດຄວາມພ້ອມກ່ອນປິດຮອບ.

ປິດຮອບປະເມີນ

Super Admin

ເລີ່ມເມື່ອ: ກວດ report ແລະ audit log ທີ່ຈໍາເປັນແລ້ວ
ວຽກທີ່ເຮັດ: ປິດ period, lock ຂໍ້ມູນສໍາຄັນ, ກໍານົດສະຖານະ closed ແລະເກັບຜົນເປັນປະຫວັດ.
ເງື່ອນໄຂ: ປິດໄດ້ສະເພາະ period ທີ່ open, ຜູ້ປິດຕ້ອງມີ permission ແລະຕ້ອງບັນທຶກ audit log.
ຜົນລັບ: ຮອບປະເມີນຈົບຢ່າງເປັນທາງການ, report ແລະ audit log ໃຊ້ອ້າງອີງຍ້ອນຫຼັງໄດ້.
ຂັ້ນຕໍ່ໄປ: Workflow ຂອງຮອບນີ້ສໍາເລັດ.

Status Update

ການ update ສະຖານະວຽກ

ສະຖານະວຽກຊ່ວຍໃຫ້ Admin, Reviewer, Approver ແລະ Employee ເຫັນຄວາມຄືບໜ້າດຽວກັນຕະຫຼອດຮອບປະເມີນ.

Draft

ຮ່າງ

ກໍາລັງກຽມຮອບ ຫຼືບັນທຶກແບບປະເມີນໄວ້ກ່ອນສົ່ງ.

Admin / Employee

Open

ເປີດຮອບ

ເປີດໃຫ້ assignment ປາກົດໃນ dashboard ແລະເລີ່ມນັບ progress.

Super Admin

Submitted

ສົ່ງແລ້ວ

ພະນັກງານສົ່ງຄະແນນແລ້ວ, ລະບົບ lock ແບບຟອມຕາມນະໂຍບາຍ.

Employee

Returned

ສົ່ງກັບ

ຜູ້ກວດສອບສົ່ງກັບພ້ອມເຫດຜົນ, ວຽກກັບໄປຢູ່ queue ຂອງຜູ້ຮັບຜິດຊອບ.

Reviewer / Approver

Reviewed

ກວດແລ້ວ

ຜ່ານການກວດຂັ້ນ 1 ແລະສົ່ງຕໍ່ໃຫ້ Approver ອະນຸມັດ.

Reviewer

Approved

ອະນຸມັດ

ຜົນປະເມີນຜ່ານຂັ້ນສຸດທ້າຍ, report ສາມາດນໍາໄປໃຊ້ຕໍ່ໄດ້.

Approver

Closed

ປິດຮອບ

ປິດຮອບປະເມີນ, lock ຂໍ້ມູນສໍາຄັນ ແລະເກັບເປັນປະຫວັດ.

Super Admin

ການ update ສະຖານະຕ້ອງກວດ role ແລະ department scope ກ່ອນທຸກຄັ້ງ.

ທຸກການປ່ຽນສະຖານະຄວນບັນທຶກ actor, ເວລາ, old status, new status ແລະ reason ໃນ audit log.

Dashboard, review queue, approval queue ແລະ report ອ່ານສະຖານະດຽວກັນ ເພື່ອບໍ່ໃຫ້ progress ຄາດເຄື່ອນ.

Software Design

ການອອກແບບ Software

ລະບົບແບ່ງອອກເປັນຊັ້ນຊັດເຈນ: ໜ້າຈໍ, API, business logic ແລະ database access. ການແບ່ງແບບນີ້ຊ່ວຍໃຫ້ປັບ UI, ເພີ່ມ workflow ແລະຂະຫຍາຍ report ໄດ້ງ່າຍ.

ໜ້າຈໍ App Router

Presentation Layer

ໜ້າ Login, Employee Dashboard, Group Evaluation, Admin Dashboard ແລະໜ້າອະທິບາຍລະບົບຢູ່ໃນ `src/app`. Client Component ໃຊ້ສໍາລັບ state, form, filter ແລະ navigation.

Route Handlers

API Layer

API ຢູ່ໃນ `src/app/api/.../route.ts` ເປັນຈຸດຮັບ request, ກວດ session, ກວດ permission ແລະສົ່ງຕໍ່ໃຫ້ helper ຝັ່ງ server.

Business Logic

Domain Layer

Logic ຫຼັກຖືກແຍກໄວ້ໃນ `src/lib/core`, `src/lib/setup`, `src/lib/forms`, `src/lib/workflow` ແລະ `src/lib/reports` ເພື່ອໃຫ້ UI ບໍ່ຜູກກັບ SQL ໂດຍກົງ.

MySQL Server Side

Data Layer

`src/lib/db.ts` ສ້າງ MySQL connection pool, ໃຊ້ `utf8mb4`, timezone `+07:00` ແລະ helper `query()` ສໍາລັບ server code. Client Component ບໍ່ຄວນ import database helper.

UIRoute HandlerPermissionDomain HelperMySQL PoolResponse

Folder Structure

ໂຄງສ້າງ folder ຂອງໂປຣເຈັກ

ໂຄງສ້າງນີ້ແຍກ route, API, business logic, database script ແລະເອກະສານອອກຈາກກັນ ເພື່ອໃຫ້ພັດທະນາຕໍ່ໄດ້ງ່າຍ.

src/source code ຫຼັກຂອງ Next.js app

app/App Router: page, layout, API route

page.tsxໜ້າ login ພະນັກງານ

dashboard/ໜ້າ self evaluation ແລະ group evaluation

admin/ໜ້າ admin login ແລະ dashboard

system/ໜ້າອະທິບາຍລະບົບນີ້

api/Route Handlers ສໍາລັບ server API

lib/server helper ແລະ business logic

foundation/auth, session, permission, audit log

core/employee, organization, role, master data

setup/period, department assignment, evaluator assignment

forms/self evaluation, peer evaluation, score validation

workflow/review, approval, score calculation queue

reports/employee, department, organization, export PDF/Excel

db.tsMySQL connection pool ແລະ query helper

database/schema, seed, init ແລະ validation SQL

docs/spec, development plan, workflow ແລະ test checklist

`src/app` ໃຊ້ສໍາລັບ routing ເທົ່ານັ້ນ: ມີ `page.tsx` ເພື່ອເປີດ route ແລະ `route.ts` ເພື່ອເປີດ API.

`src/lib` ເກັບ logic ຝັ່ງ server, ເພື່ອໃຫ້ API route ແລະ report ນໍາໃຊ້ຮ່ວມກັນໄດ້.

Client Component ບໍ່ import `src/lib/db.ts`; ການເຂົ້າ database ຕ້ອງຜ່ານ Route Handler ຫຼື server code.

Database Design

ການອອກແບບ Database

Database ໃຊ້ MySQL, InnoDB, foreign key ແລະ constraint ເພື່ອຄຸມຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນປະເມີນ, ສິດ ແລະການຄໍານວນຄະແນນ.

Organization & Employee

organization_units, employees

ເກັບໂຄງສ້າງກົມ, ພະແນກ, ໜ່ວຍງານ ແລະຂໍ້ມູນພະນັກງານ. `employees.org_unit_id` ເຊື່ອມກັບ organization scope.

Access Control

roles, permissions, role_permissions, app_users, user_department_scopes

ເກັບ role, permission, user account ແລະຂອບເຂດພະແນກທີ່ຜູ້ໃຊ້ເຂົ້າເຖິງໄດ້.

Master Data

eval_categories, eval_criteria, position_types, score_grades

ເກັບໝວດປະເມີນ, ຫົວຂໍ້ຍ່ອຍ, ປະເພດຕໍາແໜ່ງ ແລະ grade. ສູດຄະແນນຄວນອີງຈາກຂໍ້ມູນນີ້.

Evaluation Setup

evaluation_periods, evaluation_department_assignments, evaluator_assignments

ກໍານົດຮອບປະເມີນ, owner/reviewer/approver ຕາມພະແນກ ແລະລາຍການວ່າໃຜຕ້ອງປະເມີນໃຜ.

Scores & Reports

evaluation_scores, group_evaluations, group_eval_members, peer_scores, vw_group_eval_summary

ເກັບຄະແນນຕາມ assignment/criteria, ຮອງຮັບ prototype peer score ແລະ view ສໍາລັບ dashboard/report.

Audit Trail

audit_logs

ບັນທຶກ actor, action, target, old/new JSON, reason, IP ແລະເວລາ ເພື່ອກວດສອບຍ້ອນຫຼັງ.

ກົດລະບຽບຂໍ້ມູນສໍາຄັນ

ໃຊ້ `utf8mb4_unicode_ci` ເພື່ອຮອງຮັບພາສາລາວ ແລະ Unicode ຄົບຖ້ວນ.
Foreign key ຜູກຂໍ້ມູນສໍາຄັນ ເຊັ່ນ employee, user, org unit, assignment ແລະ criteria.
Unique key ປ້ອງກັນຂໍ້ມູນຊໍ້າ ເຊັ່ນ assignment ຊໍ້າໃນຮອບດຽວກັນ.
Check constraint ກໍານົດຊ່ວງຄະແນນ 1-10 ແລະຊ່ວງ grade ໃຫ້ຖືກຕ້ອງ.

Modules

Module ທີ່ລະບົບຮອງຮັບ

Organization

ຈັດການກົມ, ພະແນກ, ໜ່ວຍງານ ແລະ scope ຂໍ້ມູນ.

User & Role

ກໍານົດບັນຊີ, role, permission ແລະ department scope.

Master Data

ຈັດການເກນຄະແນນ, ຫົວຂໍ້ປະເມີນ, ນໍ້າໜັກ ແລະ grade.

Evaluation Forms

ຮອງຮັບ self evaluation ແລະ peer evaluation ຕາມ assignment.

Score Calculation

ລວມຄະແນນ ແລະຫາຄ່າສະເລ່ຍຈາກຈໍານວນຜູ້ສົ່ງຈິງ.

Report & Export

ສ້າງລາຍງານ Employee, ພະແນກ, ອົງກອນ ແລະ Export PDF/Excel.

Access Control

ບົດບາດ ແລະສິດການເຂົ້າເຖິງ

ລະບົບແຍກຂໍ້ມູນຕາມ role ແລະ department scope ເພື່ອໃຫ້ຜູ້ໃຊ້ເຫັນສະເພາະສ່ວນທີ່ຕົນມີສິດ.

Super Adminຄວບຄຸມທັງລະບົບ, ເປີດ/ປິດຮອບ, ເບິ່ງລາຍງານອົງກອນ

System Adminດູແລຜູ້ໃຊ້ ແລະຂໍ້ມູນກາງຕາມ permission

Department Adminຈັດການຂໍ້ມູນ ແລະຕິດຕາມວຽກພາຍໃນພະແນກ

Employeeປະເມີນຕົນເອງ, ປະເມີນ peer ແລະເບິ່ງຜົນຂອງຕົນ

Reviewerກວດສອບຂັ້ນ 1 ແລະສົ່ງກັບໃຫ້ແກ້ໄຂໄດ້

Approverອະນຸມັດຂັ້ນ 2 ແລະ lock ຜົນທີ່ຜ່ານການອະນຸມັດ

Development Tasks

ສະຖານະ Task ການພັດທະນາ

ກວດລ່າສຸດ 03/06/2026: ສ່ວນນີ້ສະຫຼຸບ roadmap ຂອງທີມ dev ຕາມ `docs/development-plan.md`, `docs/development-tasks.md` ແລະຜົນ E2E.

Phase 1Done

Foundation

Role, permission, department scope, session model, policy helper ແລະ audit contract ຖືກກໍານົດແລ້ວ.

docs/foundation-*.md, src/lib/foundation

Phase 2Done

Core Data

Data model, API/helper, seed, validation ແລະ permission checks ສໍາລັບ core data ເຮັດຄົບແລ້ວ.

src/lib/core, src/app/api/core

Phase 3Done

Evaluation Setup

Period, department assignment, evaluator assignment ແລະ setup permission checks ຖືກ implement ແລ້ວ.

src/lib/setup, src/app/api/setup

Phase 4Done

Evaluation Forms

Self/peer form API, draft, submit, returned workflow ແລະ score validation policy ເຮັດຄົບແລ້ວ.

src/lib/forms, src/app/api/forms

Phase 5Done

Calculation & Workflow

Calculation service, review queue/action ແລະ approval queue/action ຖືກ implement ພ້ອມ audit log.

src/lib/workflow, src/app/api/workflow

Phase 6Done

Reports

Employee, department, organization, review stage ແລະ approval stage reports ພ້ອມ API ແລ້ວ.

src/lib/reports, src/app/api/reports

Phase 7Done

Export & Audit

Export contract, Excel/PDF export, audit log search ແລະ audit coverage verification ເຮັດແລ້ວ.

src/app/api/audit-logs, export routes

Phase 8Done

Auth & Session

src/lib/foundation/auth*, src/proxy.ts

Phase 9Working

UI Integration

Admin core data, setup, forms, workflow, reports, export ແລະ audit UI ເຊື່ອມ API ຈິງແລ້ວ.

src/app/admin/dashboard, src/app/dashboard

Phase 10Needs Browser Check

Pilot Verification

Database verification ແລະ full workflow manual test ຜ່ານ. Production build ຜ່ານແລ້ວ, ຍັງເຫຼືອ browser console smoke check.

docs/e2e-*.md, npm run build

Task ຕໍ່ໄປທີ່ຄວນກວດ

ເປີດ protected routes ແລະ workflow ຫຼັກໃນ browser ຈິງ ເພື່ອກວດ console error.
ບັນທຶກຜົນ smoke test ຮອບຫຼ້າສຸດໃນ `docs/e2e-03-production-build-and-smoke-test.md`.
ກວດ pilot environment ດ້ວຍ MySQL/session user ຈິງກ່ອນສົ່ງໃຫ້ທີມທົດລອງໃຊ້.

Audit & Reports

ກວດສອບຍ້ອນຫຼັງ ແລະອອກລາຍງານໄດ້

ທຸກ action ສໍາຄັນຈະບັນທຶກ audit log, ລາຍງານຈະອີງຈາກຖານຂໍ້ມູນກາງ ແລະ Export ຕາມສິດຂອງຜູ້ໃຊ້.

ເລີ່ມໃຊ້ງານລະບົບ