Dang ky ban quyen phan mem

Đăng ký bản quyền phần mềm (ĐKBQ)

Skill dựng bộ hồ sơ đăng ký quyền tác giả cho chương trình máy tính để nộp Cục Bản quyền tác giả: chụp trọn giao diện + mã nguồn, che mờ thông tin nhạy cảm, gỡ tài sản của bên thứ ba, rồi kết xuất bản in nộp được. Quy trình generic - áp dụng cho bất kỳ app web/mobile nào.

[!CAUTION] MỨC RỦI RO: TRUNG BÌNH - liên quan thủ tục pháp lý nhà nước và dữ liệu cá nhân.

• Nội dung mang tính hướng dẫn thực tiễn, KHÔNG thay thế tư vấn pháp lý/luật sư SHTT.
• Thành phần hồ sơ, biểu mẫu và lệ phí thay đổi theo thời gian → luôn đối chiếu nguồn chính thức (references/legal-requirements.md) trước khi nộp.
• Redaction là bước bảo vệ dữ liệu bắt buộc: hồ sơ trở thành hồ sơ lưu công khai, mọi số liệu/tiền/địa chỉ/ngày/thông tin cá nhân lọt ra là rủi ro thật. Không bỏ qua Verification Gate (Phase 5).

Điều hướng nhanh

Cần làm gì	Đọc file
Hồ sơ gồm gì? Quy tắc in bao nhiêu trang? Lệ phí? Biểu mẫu?	references/legal-requirements.md
Che mờ cái gì, che thế nào (toạ độ, ImageMagick, logo/cờ/bản đồ)?	references/redaction.md
Chụp giao diện headless (auth, SPA, màn phân quyền)?	references/ui-capture.md
Render ảnh mã nguồn đẹp, chọn file nào, đủ số trang?	references/code-images.md
Lắp ráp .md + .docx + PDF, mở bằng Google Docs không lỗi?	references/assembly.md

Cần chạy gì	Script
Che mờ vùng ảnh (blur region)	scripts/redact.sh
Chụp UI hàng loạt theo manifest	scripts/capture-ui.mjs (template - sửa cho app của bạn)
Server SPA zero-dep để deep-link không 404	scripts/serve-spa.mjs
Render mã nguồn → ảnh syntax-highlight đẹp	scripts/code-to-images.mjs
Ghép thư mục ảnh → PDF phân trang	scripts/images-to-pdf.mjs
Lắp ráp hồ sơ .md (base64) + .docx (pandoc)	scripts/build-dossier.mjs

Nguyên tắc nền tảng (đọc trước khi bắt tay)

Ba điều quyết định hồ sơ đạt hay trượt - nhớ tại sao, đừng làm máy móc:

1. Đầy đủ nhưng đúng luật. Cục cần thấy tác phẩm là của chủ sở hữu. Chụp toàn bộ giao diện + đủ mã nguồn theo quy tắc trang (Phase 0), nhưng loại sạch tài sản bên thứ ba (logo Google/Apple/Zalo, cờ nước ngoài, ảnh stock/internet, bản đồ có địa danh) - vì chúng không phải sáng tạo của chủ đơn và làm nhiễu quyền sở hữu.
2. Che dữ liệu, giữ cấu trúc. Mục tiêu redaction là che giá trị nhạy cảm (số liệu, tiền, địa chỉ, ngày, thông tin cá nhân) mà vẫn giữ nguyên bố cục/label UI để giám định viên đọc được chức năng. Blur vùng chứ đừng cắt khối.
3. Bản in dùng được thật. Sản phẩm cuối phải in ra giấy hoặc mở Google Docs không vỡ ảnh. Đó là lý do có bước .docx + PDF, không chỉ file .md.

Quy trình 6 phase

Làm tuần tự. Mỗi phase có file reference đi kèm - đọc nó khi vào phase, đừng nạp hết một lúc.

Phase 0 - Phạm vi & chiến lược trang

Trước khi chụp gì, chốt các thông số. Đây là lúc quyết định khối lượng công việc.

1. Đọc references/legal-requirements.md. Xác nhận với người dùng:
   • Chủ sở hữu quyền tác giả (tổ chức/cá nhân) và (các) tác giả - tên, thông tin pháp lý.
   • Tên tác phẩm phần mềm + phiên bản.
   • Repo/thư mục mã nguồn nào là nguồn sự thật (dùng code MỚI NHẤT, hỏi nếu có nhiều repo/monorepo).
   • App chạy được ở đâu để chụp UI (URL dev/prod, cần đăng nhập không, có màn phân quyền cao không).
2. Chốt chiến lược trang (quy tắc thực tiễn - xác nhận lại theo legal-requirements.md):
   • SÀN CỨNG: phần in mã nguồn phải ≥ 75 trang. Đây là mức tối thiểu nhiều đơn vị dịch vụ/thực tiễn nộp yêu cầu - đừng nộp dưới ngưỡng này.
   • Ước lượng tổng số trang bản in mã nguồn (một ảnh code ≈ một trang khi in).
   • Nếu codebase < 100 trang → in toàn bộ mã nguồn có ý nghĩa, nhưng vẫn phải đạt ≥ 75 trang (bổ sung thêm file đại diện nếu chưa đủ).
   • Nếu ≥ 100 trang → in 25 trang đầu + 25 trang giữa + 25 trang cuối (25-25-25, tự nhiên ≥ 75), cộng toàn bộ giao diện.
   • Phủ đều các tầng: frontend + backend + mobile (đừng dồn hết vào một tầng). Nếu thiếu, bổ sung thiên về tầng đang ít.
   • Ghi lại quyết định này để Phase 3 chọn file cho khớp.
3. Tạo cây thư mục output, ví dụ:

   docs/dkbq/
   ├── layouts/     # ảnh giao diện đã redact, đặt tên theo chức năng
   ├── codes/       # ảnh mã nguồn syntax-highlight
   ├── mobile-app/  # (nếu có) ảnh app mobile đã redact
   └── <ten-tac-pham>.md / .docx / .pdf
   

Phase 1 - Chụp giao diện

Mục tiêu: một ảnh sạch cho mỗi màn hình của phần mềm. Đọc references/ui-capture.md.

• Liệt kê toàn bộ route/màn hình (kể cả màn chỉ hiện với vai trò cao - xem phần "màn phân quyền" trong reference).
• Dùng scripts/capture-ui.mjs (template): điền manifest { url, name, ... }, chạy headless (Playwright). Với app SPA deep-link, chạy kèm scripts/serve-spa.mjs để tránh 404 khi mở thẳng route con.
• Rebrand tại trang trước khi chụp: nếu app hiển thị tên khách hàng/tenant thật, thay bằng tên trung tính qua page.evaluate (đừng để lộ danh tính bên thứ ba trong ảnh gốc).
• Đặt tên file theo chức năng (03-danh-sach.png, 08-cai-dat.png), không để Screenshot 2026....

Phase 2 - Che mờ (redaction)

Đây là bước pháp lý quan trọng nhất. Đọc references/redaction.md để biết che gì và công thức toạ độ.

• Với mỗi ảnh, blur: số liệu/thống kê, tiền, địa chỉ, email/SĐT/tên người, ngày-giờ cụ thể, mã QR/biển số.
• Gỡ tài sản bên thứ ba: logo hãng (Google/Apple/Zalo/...), cờ nước ngoài (không phải cờ VN nếu không liên quan), tên thương hiệu khác, ảnh lấy từ internet, bản đồ có địa danh (blur cả bản đồ hoặc xoá tên địa điểm).
• Dùng scripts/redact.sh IN OUT "WxH+X+Y" ... (blur region bằng ImageMagick). Chữ to cần blur mạnh (0x40+), chữ nhỏ 0x16 là đủ.
• Che dữ liệu, giữ label. Bảng số liệu: blur ô số, giữ tiêu đề cột/hàng sắc nét.
• Sau khi che, đọc lại ảnh (crop vùng vừa che) để mắt kiểm chứng - đừng tin toạ độ mù. Xoá ảnh gốc chưa che.

Phase 3 - Ảnh mã nguồn

Mục tiêu: bản in mã nguồn đẹp, dễ đọc, đủ số trang theo Phase 0. Đọc references/code-images.md.

• Chọn file đại diện & quan trọng: service/business logic, model, guard/security, API, cấu hình lõi. Tránh file generated/vendor/lock.
• Nếu áp quy tắc 25-25-25: chọn nhóm file cho phần đầu/giữa/cuối của codebase theo thứ tự hợp lý (theo tier hoặc theo cây thư mục).
• Chạy scripts/code-to-images.mjs với manifest { file, title?, label?, startLine?, endLine? } → mỗi file một ảnh syntax-highlight (theme LIGHT nền trắng mặc định - tiết kiệm mực in; header đường dẫn + badge ngôn ngữ + số dòng + footer). Đẹp hơn hẳn ảnh chụp editor thô. Render TẤT CẢ bằng một lần chạy/cùng theme để đồng nhất.
• Đặt tên ảnh theo chức năng file (a01-auth-service.png).

Phase 4 - Lắp ráp hồ sơ

Đọc references/assembly.md. Kết xuất song song 3 định dạng vì mỗi cái phục vụ mục đích khác:

• .md: nhúng ảnh base64 (JPEG ~600px) để tự chứa, mở được mọi nơi.
• .docx (qua pandoc, data-URI + {width=15cm}): bản người dùng mở/sửa bằng Google Docs/Word, in ra giấy. Đây là bản khuyến nghị để rà soát và in; định dạng nộp cuối cùng phải đối chiếu Cổng dịch vụ công / Cục Bản quyền tại thời điểm nộp.
• PDF: scripts/images-to-pdf.mjs ghép thư mục ảnh → PDF phân trang (một ảnh/trang) cho giao diện và cho mã nguồn.

Chạy scripts/build-dossier.mjs (manifest mô tả các mục). Cấu trúc tài liệu chuẩn:

1. Trang bìa (tên tác phẩm, chủ sở hữu, tác giả, phiên bản).
2. Mục lục.
3. Phần I - Giao diện phần mềm: ảnh layouts nhóm theo phân hệ + mô tả chức năng mỗi màn.
4. Phần II - Giao diện ứng dụng (mobile) nếu có.
5. Phần III - Mã nguồn phần mềm: ảnh code + mô tả chức năng mỗi file.

Phase 5 - Verification Gate (bắt buộc)

Không giao hồ sơ khi chưa qua hết checklist này. Đây là lưới an toàn cho cả rủi ro pháp lý lẫn lỗi kỹ thuật:

• Redaction: mở lại (crop) một mẫu ảnh mỗi loại - không còn số liệu/tiền/địa chỉ/ngày/PII đọc được.
• Bên thứ ba: không còn logo hãng, cờ nước ngoài, tên thương hiệu khác, ảnh internet, bản đồ có địa danh.
• Không lộ danh tính khách hàng/tenant thật trong bất kỳ ảnh nào (kể cả value trong ô input).
• Số trang (SÀN CỨNG): bản in mã nguồn ≥ 75 trang (kiểm bằng pdfinfo ... | grep Pages), phủ đều frontend/backend/mobile. Chưa đủ → quay lại Phase 3 bổ sung.
• Ảnh hiển thị: mở thử .docx/PDF - mọi ảnh render đủ, không vỡ, không tràn lề (xem cách xử lý crop của Google Docs trong assembly.md).
• Đặt tên & mô tả: mọi ảnh đặt tên theo chức năng; mỗi màn/ file có câu mô tả chức năng.
• File gốc chưa che đã xoá khỏi thư mục nộp.

Yêu cầu môi trường (one-time)

Các script cần Node ≥ 18 (dùng ESM + top-level await) và:

• Playwright: npm i -D playwright && npx playwright install chromium
• highlight.js: npm i -D highlight.js
• ImageMagick (magick bản 7, hoặc convert bản 6), pandoc, poppler (pdfinfo/pdftoppm/pdfunite):
  • macOS: brew install imagemagick pandoc poppler
  • Debian/Ubuntu: sudo apt-get install imagemagick pandoc poppler-utils
  • Windows: choco install imagemagick pandoc poppler (script bash chạy trên WSL2)

Chạy script từ trong thư mục dự án đã có node_modules (Playwright/highlight.js resolve theo cwd của dự án). Gọi script bằng đường dẫn đầy đủ tới skill - trong Claude Code là ${CLAUDE_SKILL_DIR}/scripts/<tên> (ví dụ trong reference ghi scripts/... cho gọn). Thiếu công cụ nào, script báo rõ và chỉ cách cài.

Lỗi thường gặp

Triệu chứng	Nguyên nhân	Cách xử lý
Ảnh trắng khi deep-link route con	SPA không có fallback → server trả 404, body rỗng	Chạy scripts/serve-spa.mjs, trỏ Playwright vào nó
Google Docs không hiện ảnh trong .md	Đường dẫn tương đối không resolve	Nhúng base64 data-URI (build-dossier làm sẵn)
Google Docs cắt mất ảnh	Ảnh markdown chèn theo pixel gốc, rộng hơn trang	Nhúng ảnh ~600px cho .md; dùng bản .docx với {width=15cm}
Blur vẫn đọc được chữ to	Bán kính blur quá nhỏ	Tăng lên 0x40–0x48 cho chữ lớn/số lớn
.md quá nặng (chục MB)	Nhúng PNG	Đổi sang JPEG q88, resize 600px (build-dossier làm sẵn)
Toạ độ blur lệch	Đọc ảnh bị scale, dùng nhầm hệ toạ độ hiển thị	Nhân theo factor Read báo; xem "công thức toạ độ" trong redaction.md

Ghi chú generic

Skill không gắn với dự án cụ thể nào. Khi dùng: thay mọi tên miền/tenant/route bằng của dự án hiện tại, đọc code mới nhất từ repo người dùng chỉ định, và luôn hỏi khi có nhiều nguồn hoặc thông tin pháp lý chưa rõ thay vì phỏng đoán.