Sheet 8 · Use Case Specifications

Đặc tả Use Case

Đặc tả chi tiết các yêu cầu chức năng: vai trò (Role), điều kiện tiên quyết, luồng hoạt động chính/phụ và điểm kiểm soát dữ liệu. Hệ thống gồm 30 Use Cases chia theo 4 nhóm chuẩn (Manage / Workflow & Delivery / Tài chính & Kế toán / Other). Ba Use Case then chốt được đặc tả đầy đủ 6 khối chuẩn theo tiêu chuẩn ISO/IEEE/BMAD.

8
UC Dữ liệu nền & Thiết lập
10
UC Vận hành & Delivery
7
UC Tài chính & Kế toán
5
UC Hệ thống & Bảo mật

1. Danh mục 30 Use Cases toàn hệ thống

1.1. Nhóm Manage — Dữ liệu nền & Cấu hình 8 UC

IDTên Use CaseVai trò chínhModule liên quan
UC 01Xem / tạo / sửa Hồ sơ Đối tác (Contact) & Gắn tag ngành, giải phápSales, Admin/crm
UC 02Quản lý Nhà cung cấp (Vendors AP) & Hợp đồng đối tácKế toán chi, Admin/vendors
UC 03Thiết lập Thông tin Doanh nghiệp & Mẫu hoá đơnAdmin/settings
UC 04Quản trị Tài khoản người dùng & Phân quyền Module (RBAC)Admin/settings (tab Users)
UC 05Đấu nối Email per-user qua Google Apps Script Web AppMember, Admin/mail
UC 06Quản trị Chatbot Telegram & Whitelist TokenAdmin/bots
UC 07Quản lý Kho tài liệu dùng chung (Library Boards & Items)Admin, Member/library
UC 08Quản lý Sổ tay Kỹ năng chuẩn hoá (Skills & SOP Versioning)Admin, Member/skills

1.2. Nhóm Workflow & Delivery — Vòng đời Dự án & Công việc 10 UC

IDTên Use CaseVai trò chínhModule liên quan
UC 09Tiếp nhận Lead tự động từ Ingest API / HubSpot SyncHệ thống, Sales/crm
UC 10Lập Báo giá per-user (Pricing BG-*) & Gửi kháchSales Lead/pricing
UC 11Chốt Deal & Khởi tạo Dự án (dealStage: won → status: planning)Sales Lead, BOD/projects
UC 12Bóc tách WBS Deliverables & Sinh Task tự tăng CTC-*Project Manager/tasks
UC 13Phân công nhân sự & Gắn tag 3 chiều (gp:, nganh:, viec:)PM, Lead/tags
UC 14Thực thi công việc trên Kanban & Chế độ Focus ModeDeveloper, Member/tasks, /focus
UC 15Ghim Comment toạ độ & Review đa tầng (@mention)Reviewer, QAReview Layer
UC 16Cấu hình Quy trình tự động hoá (React Flow Canvas)PM, Tech Lead/workflows
UC 17Gửi Đề xuất / Yêu cầu phát triển tính năng (Dev Requests)Mọi nhân sự/requests
UC 18Nghiệm thu Deliverable & Đóng dự án (Project Acceptance)PM, BOD/projects/[id]

1.3. Nhóm Finance — Tài chính, Hoá đơn & Dòng tiền 7 UC

IDTên Use CaseVai trò chínhModule liên quan
UC 19Xuất Hoá đơn GTGT (CTC-INV-*) & Quét ảnh OCRKế toán doanh thu/invoices
UC 20Ghi nhận Giao dịch Thu / Chi thực tếKế toán viên/finance
UC 21Cấu hình Khoản định kỳ tự sinh hàng tháng (Recurrences)Kế toán chi phí/finance
UC 22Duyệt chi Hợp đồng Nhà cung cấp > 5.000.000đBan Giám đốc (BOD)/vendors
UC 23Đối soát công nợ phải thu AR & Cảnh báo hoá đơn quá hạnKế toán trưởng/finance, /invoices
UC 24Tính hoa hồng dự án & Thuế TNCN (Income Module 2026)Member, Kế toán/income
UC 25Xem Báo cáo Lãi Lỗ (P&L) dự án & Tỷ trọng Doanh thuAdmin, BOD/dashboard, /reports

1.4. Nhóm Other — Xác thực, Tìm kiếm & Audit 5 UC

IDTên Use CaseVai trò chínhModule liên quan
UC 26Đăng nhập / Đăng xuất qua Cookie ode_sessMọi người dùng/login
UC 27Tự đổi mật khẩu tài khoản cá nhânMọi người dùng/account
UC 28Tìm kiếm toàn cục ⌘K (Không dấu, Phân quyền scope)Mọi người dùng/search, ⌘K
UC 29Xem Nhật ký thay đổi hệ thống (System Log & Revision Diff)Admin, Member/system-log
UC 30Đấu nối Webhook Relay an toàn (Telegram / GWS Whitelist)Mọi người dùng/settings (Relay)

1b. Use Case bổ sung — trợ lý ngoài & các tính năng thêm 03/09/2026

Use CaseTác nhânLuồng chính
UC-31Trợ lý ngoài dựng kỹ năng nhápNhân sự qua trợ lý AI (Claude Code / antigravity / bot Telegram)Người dùng mô tả kỹ năng bằng lời với trợ lý → trợ lý soạn JSON đúng lược đồ → gọi POST /api/agent/action action tao_ky_nang kèm header X-Agent-Key → ERP kiểm khoá, suy ra chủ sở hữu, kiểm phân hệ skills bằng hasModule, cắt bớt trường theo kiểu và độ dài rồi lưu thành kỹ năng trạng thái nháp → trả câu xác nhận kèm mã. Người dùng vào ERP đọc lại và sửa. Ngoại lệ: thiếu phân hệ → 403 kèm missingModule; quá 40 bản/24 giờ → 429; JSON sai → từ chối tử tế, không tạo gì.
UC-32Trợ lý ngoài dựng quy trình tự động nhápNhư trênGiống UC-31 với action tao_quy_trinh và phân hệ workflows. Quy trình sinh ra luôn TẮT — nó chạy nền và ghi vào dữ liệu thật nên việc bật thuộc về người, sau khi đọc.
UC-33Chia sẻ kỹ năng cho đồng nghiệp theo mứcChủ sở hữu kỹ năngMở kỹ năng → khối "Chia sẻ cho đồng nghiệp" → chọn mức cho từng người: Không · Xem · Sửa (mỗi người đúng một mức) → lưu ngay, không đi qua nháp. Người mức Sửa đổi được nội dung nhưng không đổi được chia sẻ, không phát hành, không xoá — server bỏ qua lặng lẽ nếu họ gửi các trường đó lên.
UC-34Phát hành kỹ năng cho trợ lý của một ngườiChủ sở hữu kỹ năngKhối "Phát hành cho trợ lý của" liệt kê các khoá API kèm tên chủ khoá → tích chọn → ghi vào bot_api_keys.skill_ids qua POST /api/api-keys/by-skill. Ai chưa có khoá hiện tách riêng kèm nhắc cấp khoá. Khác UC-33: chia sẻ cho một người không làm trợ lý của họ biết kỹ năng, và ngược lại.
UC-35Đổi hình nền bằng ảnh của mìnhMọi nhân sựCài đặt → Giao diện → chọn áp dụng cho Cả hai/Ngày/Đêm → bấm "Tải ảnh từ máy" hoặc kéo thả ảnh → POST /api/wallpaper (multipart, ≤8MB) → server lưu tệp mang id chủ ảnh, trả đường dẫn nội bộ → áp ngay. Ảnh chỉ chính chủ xem được, kể cả quản trị cũng không. Giữ 3 tệp gần nhất rồi tự dọn.
UC-36Sửa một sự kiện thuộc chuỗi lặpMọi nhân sựMở sự kiện có lịch lặp → sửa giờ/nội dung → hệ thống hỏi phạm vi: chỉ lịch hôm đó · lịch này và các lịch sau · toàn bộ chuỗi. Chọn "này và sau" hoặc "toàn bộ" thì các trường chung áp cho cả nhóm và eventRecurrences đồng bộ theo; ngày thì chỉ đổi đúng lịch đang sửa.
UC-37Sửa việc ngay trong phiên Tập trungMọi nhân sựTrong màn Tập trung, bấm Tạm dừng → bấm vào đồng hồ, tiêu đề hoặc mô tả để sửa. Rời ô là lưu, Esc huỷ. Chạy tiếp hoặc chuyển việc thì ô đang sửa tự đóng để không ghi nhầm sang việc khác. Đang chạy thì các ô khoá — màn đó là chỗ làm việc, không phải chỗ soạn thảo.
UC-38Thu hồi toàn bộ phiên đăng nhậpOwner (ERP_OWNERS)Nghi ngờ rò rỉ → POST /api/me/sessions/revoke-all → server tăng session_ver của mọi tài khoản trong tenant → mọi cookie đang có mất hiệu lực ngay vì chữ ký phiên phủ cả cột đó.
Đã gỡ: use case "Dựng kỹ năng/quy trình bằng AI ngay trong ERP" không còn — tính năng đó thêm và gỡ trong cùng ngày 03/09/2026 vì nó cho mọi tài khoản đăng nhập chạy lệnh tuỳ ý dưới unix user erp. Thay bằng UC-31 và UC-32.

2. Đặc tả đầy đủ 3 Use Cases mẫu then chốt (6 khối chuẩn)

UC 12 · Bóc tách WBS Deliverables & Sinh Task tự tăng CTC-* Reference Spec
Mục tiêu (Objective)Chuyển giao mục tiêu dự án thành các gói sản phẩm bàn giao (Deliverables) và công việc cụ thể (Tasks), sinh mã tự tăng CTC-n duy nhất toàn tenant.
Vai trò chínhProject Manager (PM) / Tech Lead
TriggerDự án được phê duyệt triển khai (status: planning hoặc active)
Điều kiện tiên quyếtDự án đã tồn tại trên hệ thống; người dùng có quyền module tasksprojects.
Điều kiện sau khi xongDanh sách task mới được khởi tạo ở cột todo; bộ đếm taskCounter tăng lên; cập nhật realtime qua SSE cho mọi tab.
User StoryCTC-ERP-UC12: "Là PM, tôi muốn bóc tách nhanh công việc cho dự án kèm tiêu chí nghiệm thu để đội ngũ thực thi chính xác."

Luồng hoạt động (Activity Flow)

  1. PM mở màn hình Danh sách Công việc (/tasks) hoặc mở tab Công việc trong chi tiết Dự án (/projects/[id]).
  2. PM bấm nút "Thêm công việc" (hoặc dùng phím tắt N / nút nhanh trên đầu cột todo).
  3. Hệ thống mở Panel / Modal tạo Task: Tự động điền projectIdcontactId nếu đi từ trang Dự án.
  4. PM nhập các trường thông tin:
    • Tiêu đề task (Bắt buộc): Tên sản phẩm bàn giao / deliverable rõ ràng.
    • Mô tả & Checklist (Bắt buộc): Tiêu chí nghiệm thu (Definition of Done), checklist các bước con.
    • Người phụ trách: Chọn từ danh sách auth_users thuộc tenant.
    • Hạn hoàn thành (Due date) & Độ ưu tiên: urgent / high / medium / low.
    • Tag phân loại: Chọn tag gp:* (giải pháp) và viec:* (loại lao động).
  5. PM bấm "Tạo công việc":
    • Hệ thống validate tính hợp lệ (tiêu đề không rỗng, due date hợp lệ).
    • Hệ thống lấy taskCounter hiện tại (ví dụ: 76), tăng lên 77 và gán key: "CTC-77".
    • Hệ thống ghi bản ghi mới vào blob tasks[], tăng rev và phát sinh sự kiện SSE state_update.
    • Hiển thị thông báo thành công SM1 ("Đã tạo công việc CTC-77 thành công").

Đặc tả giao diện màn hình (Screen Spec)

#Thành phần UILoại controlBắt buộcMô tả / Ràng buộc
1[Tiêu đề công việc]Text InputCó (Y)Tối đa 255 ký tự; không được chỉ chứa khoảng trắng.
2[Dự án liên kết]Select / AutocompleteTuỳ chọnLọc từ danh sách projects[] đang mở.
3[Người phụ trách]User SelectTuỳ chọnMặc định là người tạo nếu không chọn người khác.
4[Hạn hoàn thành]Date PickerTuỳ chọnMặc định cuối tuần hiện tại nếu không chọn.
5[Độ ưu tiên]Dropdown / BadgeCó (Y)Mặc định là medium.
6[Checklist con]Dynamic ListTuỳ chọnMỗi item có checkbox + text, mặc định mảng rỗng [].
7"Tạo công việc"Button PrimaryThực thi lưu và đóng form.

Quy tắc nghiệp vụ (Business Rules)

Mã BRMô tả quy tắcHành động khi vi phạm
BR 1.1Tiêu đề task không được để trống hoặc chỉ có khoảng trắng.Báo lỗi inline IEM3 ("Trường này là bắt buộc").
BR 1.2Mã task key phải duy nhất toàn tenant và có định dạng <PREFIX>-<counter> (ví dụ: CTC-77).Hệ thống tự sinh, không cho phép client tự chỉ định key.
BR 1.3Khi khởi tạo, mảng subtasks, tags, links bắt buộc phải là mảng rỗng [] (không được undefined/null).Server-side sanitizer tự ép kiểu mảng rỗng trước khi lưu.
UC 19 · Xuất Hoá đơn GTGT & Quét OCR Hoá đơn đầu vào Reference Spec
Mục tiêu (Objective)Phát hành hoá đơn GTGT bán hàng cho đối tác, quản lý line-items thuế suất, và hỗ trợ quét ảnh OCR hoá đơn đầu vào từ nhà cung cấp.
Vai trò chínhKế toán Doanh thu / Kế toán trưởng
TriggerĐến mốc thanh toán hợp đồng hoặc nhận hoá đơn đầu vào từ Vendor.
Điều kiện tiên quyếtNgười dùng có quyền module invoices; đối tác đã có hồ sơ Contact trên hệ thống.
Điều kiện sau khi xongHoá đơn chuyển sang trạng thái sent hoặc paid; ghi nhận vào sổ công nợ AR; tự sinh giao dịch thu nếu mark-paid.
User StoryCTC-ERP-UC19: "Là kế toán, tôi muốn xuất hoá đơn có đầy đủ line-items và scan OCR nhanh hoá đơn chi phí để theo dõi công nợ chính xác."

Luồng hoạt động (Activity Flow)

  1. Kế toán mở màn hình Báo giá & Hoá đơn (/invoices).
  2. Chọn "Tạo hoá đơn mới" hoặc chọn "Quét hoá đơn (OCR)".
    • Nhánh tạo tay: Nhập khách hàng, mã số thuế, địa chỉ, chọn ngày xuất và hạn thanh toán.
    • Nhánh quét OCR: Upload ảnh/PDF hoá đơn → Hệ thống gọi OCR engine bóc tách: Số HĐ, Ngày lập, MST bên bán/mua, Tổng tiền trước thuế, Tiền thuế GTGT, Tổng thanh toán → Tự điền vào form.
  3. Kế toán chỉnh sửa các dòng hàng hoá/dịch vụ (Line items):
    • Nhập Tên hàng hoá/dịch vụ, Đơn vị tính, Số lượng, Đơn giá, Thuế suất (0%, 5%, 8%, 10%).
    • Hệ thống tự tính: Thành tiền = Số lượng × Đơn giá; Tiền thuế = Thành tiền × Thuế suất; Tổng cộng.
  4. Kế toán bấm "Lưu & Phát hành":
    • Hệ thống sinh số hoá đơn dạng CTC-INV-YYYY-NNNN.
    • Trạng thái hoá đơn chuyển thành sent (đã gửi cho khách).
    • Cập nhật số dư công nợ phải thu (AR) của đối tác.
  5. Khi khách thanh toán: Kế toán bấm nút "Đánh dấu đã thanh toán (Mark Paid)" → Hệ thống tự động sinh 1 bản ghi giao dịch thu (Transaction type: income) trong sổ tài chính.

Quy tắc nghiệp vụ (Business Rules)

Mã BRMô tả quy tắcHành động khi vi phạm
BR 2.1Mã số thuế doanh nghiệp phải đúng định dạng 10 số hoặc 13 số (chi nhánh).Báo lỗi inline IEM4 ("Mã số thuế không đúng định dạng").
BR 2.2Hoá đơn có ít nhất 1 dòng hàng hoá với số lượng > 0 và đơn giá ≥ 0.Báo lỗi EM1 ("Hoá đơn phải có ít nhất 1 mặt hàng hợp lệ").
BR 2.3Hoá đơn quá hạn thanh toán (hôm nay > dueDate và chưa trả đủ) tự động chuyển tag cảnh báo màu đỏ overdue.Hệ thống tự tính toán và hiển thị trên Dashboard AR.
UC 11 · Chốt Deal & Khởi tạo Dự án từ Phễu Bán hàng Reference Spec
Mục tiêu (Objective)Chuyển đổi cơ hội bán hàng thành công sang dự án thực thi, đồng bộ doanh số và thiết lập hồ sơ dự án chính thức.
Vai trò chínhPhòng Sales & Ban Giám đốc (BOD)
TriggerĐối tác ký kết hợp đồng dịch vụ hoặc chuyển khoản tiền cọc đợt 1.
Điều kiện tiên quyếtHồ sơ đối tác đã tồn tại; đã có báo giá hoặc thoả thuận giá trị hợp đồng.
Điều kiện sau khi xongProject được tạo mới với dealStage: wonstatus: planning; doanh số được ghi nhận vào KPI; gửi thông báo nội bộ.
User StoryCTC-ERP-UC11: "Là Sales Lead, tôi muốn chốt deal và chuyển nhanh sang dự án triển khai để không bị gián đoạn khâu bàn giao."

Luồng hoạt động (Activity Flow)

  1. Sales mở màn hình Phễu Bán hàng / Dự án (/projects ở chế độ Phễu Deal).
  2. Kéo thẻ Deal từ cột negotiation sang cột won (hoặc mở form sửa Project và đổi dealStage: won).
  3. Hệ thống hiển thị Modal xác nhận Chốt Deal:
    • Yêu cầu xác nhận giá trị hợp đồng chính thức (dealValue).
    • Chọn ngày bắt đầu dự án và ngày bàn giao dự kiến.
    • Đính kèm file hợp đồng đã ký hoặc link tài liệu trên Google Drive.
  4. Sales bấm "Xác nhận Chốt Deal":
    • Hệ thống cập nhật dealStage = 'won', giữ nguyên hoặc chuyển status = 'planning'.
    • Hệ thống tự động kích hoạt Workflow Relay: gửi tin nhắn chúc mừng chốt deal tới nhóm Telegram công ty qua /api/me/relay/telegram.
    • Giá trị hợp đồng được cộng dồn vào tổng giá trị đối tác (Rollup Contract Value) trên màn hình /crm.
    • Thông báo tới Ban Giám đốc để thực hiện phân công nhân sự (Pha 4 trong quy trình).

Quy tắc nghiệp vụ (Business Rules)

Mã BRMô tả quy tắcHành động khi vi phạm
BR 3.1Chỉ tài khoản có vai trò admin hoặc Sales phụ trách deal mới được chuyển trạng thái won/lost.Từ chối thao tác, báo lỗi EM4 ("Bạn không có quyền chốt deal này").
BR 3.2Deal chuyển won bắt buộc phải có giá trị hợp đồng dealValue > 0.Báo lỗi inline IEM5 ("Giá trị hợp đồng phải lớn hơn 0").
BR 3.3Tổng giá trị đối tác (Rollup) luôn bằng tổng dealValue của các dự án chưa lost gắn với đối tác đó.Hệ thống tự tính realtime trên client, không cho sửa tay.
UC 16 · Thiết kế & Kích hoạt Quy trình Tự động hoá (Workflow Automation Canvas) Reference Spec
Mục tiêu (Objective)Xây dựng kịch bản tự động hoá liên phòng ban bằng canvas kéo-thả (Trigger → Filter → Actions), kích hoạt realtime hoặc theo lịch quét định kỳ.
Vai trò chínhQuản lý vận hành / Trưởng bộ phận (Workflow Owner)
TriggerNhân sự muốn tự động hoá chuỗi thao tác lặp lại (ví dụ: Chốt deal tự động tạo task Kickoff và bắn tin Telegram).
Điều kiện tiên quyếtTài khoản có quyền truy cập module workflows; các kênh relay (Telegram/GWS) đã cấu hình nếu sử dụng action đối ngoại.
Điều kiện sau khi xongWorkflow được lưu và kích hoạt (is_active = true); engine client-side lắng nghe sự kiện; server snapshot 1 phiên bản mới trong lịch sử 10 bản.
User StoryCTC-ERP-UC16: "Là Trưởng dự án, tôi muốn tự vẽ kịch bản tự động hoá để hệ thống tự giao việc cho team và bắn tin cảnh báo khi có sự kiện quan trọng."

Luồng hoạt động (Activity Flow)

  1. Mở danh bạ Quy trình (/workflows): Bấm nút "Tạo quy trình mới" hoặc chọn 1 trong 5 mẫu dựng sẵn (Templates W1-W5).
  2. Chuyển sang Visual Canvas (/workflows/[id]):
    • Cấu hình Trigger Node: Chọn loại status_change (bắt đối tượng Task/Project/Invoice đổi trạng thái) hoặc daily_scan (quét hạn hoá đơn, việc quá hạn, trạng thái ngâm lâu).
    • Thêm Condition Node: Kéo dây nối từ Trigger; thiết lập bộ lọc logic (ví dụ: tags has gp:ctc-ai-transform).
    • Thêm Action Nodes: Nối các hành động cần thực thi:
      • Action 1: create_task với tiêu đề [Kickoff] {name}, hạn sau 3 ngày, gán cho phụ trách dự án.
      • Action 2: send_telegram với nội dung 🎉 Dự án {name} đã chốt! Team chuẩn bị kickoff..
  3. Kiểm thử & Lưu quy trình:
    • Bấm nút "Chạy thử (Test Run)" để kiểm tra luồng logic và cấu trúc biến thay thế.
    • Bật toggle "Kích hoạt (Active)" và bấm "Lưu quy trình".
    • Hệ thống lưu cấu trúc toạ độ Graph WorkflowGraphDef lên server và chuyển đổi sang cấu trúc phẳng WorkflowDef cho Engine chạy.
  4. Engine thực thi & Chống lặp 3 lớp:
    • Khi sự kiện thoả mãn, Engine kiểm tra Fired Key per-user trong user_data (Lớp 1).
    • Engine kiểm tra tag ẩn wf:<id>:<key> trong store trước khi tạo task (Lớp 2).
    • Engine thực thi hành động và gửi bản ghi log lên server qua POST /api/workflow-runs.

Quy tắc nghiệp vụ (Business Rules)

Mã BRMô tả quy tắcHành động khi vi phạm
BR 4.1Một quy trình bắt buộc phải có đúng 1 Trigger Node hợp lệ trước khi cho phép bật Active.Báo lỗi inline IEM6 ("Quy trình phải có ít nhất 1 sự kiện kích hoạt").
BR 4.2Mỗi mốc sự kiện trong ngày của 1 đối tượng chỉ được kích hoạt Action đúng 1 lần (Idempotency).Engine tự chặn ở Lớp 1 Fired-key, không bắn lặp.
BR 4.3Người được chia sẻ (Viewer) chỉ có quyền Xem và Nhân bản (Clone), không được sửa Canvas gốc.Ẩn các nút chỉnh sửa/lưu trên giao diện đối với Viewer.
UC 08 · Biên soạn Sổ tay Kỹ năng (SOP) & Yêu cầu Phát hành Phiên bản mới Reference Spec
Mục tiêu (Objective)Chuẩn hoá tri thức vận hành (Sales, Tech, Content, Ops, Finance) thành Sổ tay SOP chi tiết và quản trị phê duyệt phát hành phiên bản chính thức.
Vai trò chínhChuyên viên nghiệp vụ (Tác giả) & Ban Giám đốc / Dev Lead (Phê duyệt)
TriggerDoanh nghiệp có quy trình mới cần chuẩn hoá hoặc nâng cấp cẩm nang thực thi.
Điều kiện tiên quyếtTài khoản có quyền truy cập module skillsrequests.
Điều kiện sau khi xongSOP được phê duyệt, lưu snapshot phiên bản vX.Y (tối đa 20 bản), và phát hành công khai (published = true) cho toàn công ty.
User StoryCTC-ERP-UC08: "Là nhân sự chuyên môn, tôi muốn số hoá quy trình làm việc chuẩn thành cẩm nang Kỹ năng để đồng nghiệp cùng tuân thủ nhất quán."

Luồng hoạt động (Activity Flow)

  1. Tác giả mở module Kỹ năng (/skills):
    • Bấm nút "Tạo kỹ năng mới" hoặc "Nhập từ file Markdown (.md)".
    • Nếu nhập Markdown, hệ thống tự động bóc tách: H1 thành Tên kỹ năng, Text mở đầu thành Tóm tắt (Summary), H2 thành Các bước thực hiện (Steps), Checkbox - [ ] thành Checklist nghiệm thu, Link thành Tài nguyên (Resources).
    • Tác giả rà soát và lưu kỹ năng ở trạng thái status = 'draft' (Bản nháp cá nhân).
  2. Gửi Yêu cầu Phát hành (/requests):
    • Tác giả chuyển sang trang /requests, bấm "Gửi yêu cầu mới".
    • Chọn loại kind: 'skill', tiêu đề "Đề xuất phát hành SOP Bóc tách Deliverables v1.2", liên kết targetId tới kỹ năng vừa soạn.
    • Yêu cầu được khởi tạo ở trạng thái status: 'new'.
  3. Admin / BOD Tiếp nhận & Thẩm định:
    • Admin mở yêu cầu, xem trước nội dung kỹ năng, chuyển trạng thái sang reviewing (khoá quyền sửa của tác giả).
    • Admin đóng góp ý kiến qua trường reviewNote (hỗ trợ @mention tác giả).
  4. Phê duyệt & Phát hành Chính thức:
    • Admin bấm "Phê duyệt & Phát hành", nhập số hiệu phiên bản releasedVersion = 'v1.2'.
    • Hệ thống tự động bật cờ published = true, chuyển status = 'active' của Kỹ năng.
    • Server tự động snapshot toàn bộ nội dung def vào lịch sử versions[] (lưu 20 phiên bản).
    • Trạng thái yêu cầu chuyển thành released; thông báo chúc mừng được gửi tới tác giả.

Quy tắc nghiệp vụ (Business Rules)

Mã BRMô tả quy tắcHành động khi vi phạm
BR 5.1Kỹ năng chỉ được phát hành toàn công ty (published=true) khi có sự phê duyệt của Admin qua Dev Request.Thành viên không thể tự ý bật cờ published cho kỹ năng chưa duyệt.
BR 5.2Mỗi khi nội dung def của Kỹ năng thay đổi, server bắt buộc phải lưu lại 1 phiên bản snapshot có timestamp.Hệ thống tự động lưu vào versions[] (giữ tối đa 20 bản gần nhất).
BR 5.3Người gửi chỉ được phép sửa nội dung yêu cầu phát triển khi yêu cầu còn ở trạng thái new.Từ chối thao tác sửa khi yêu cầu đã chuyển sang reviewing hoặc approved.