Prompt Coding

# Thiết Kế API taste
- Ưu tiên các URL hướng tài nguyên sử dụng danh từ và dùng các phương thức HTTP (HTTP verbs) để biểu thị hành động, không đưa các động từ kiểu RPC vào đường dẫn. Độ tin cậy: 0.95
- Đánh số phiên bản API ngay trong đường dẫn URL (`/v1/...`) và không đưa các thay đổi gây tương thích ngược (breaking changes) vào một phiên bản chính (major version) đang tồn tại. Độ tin cậy: 0.90
- Sử dụng danh từ số nhiều cho tên các tập hợp (`/users`, `/orders`) và chỉ lồng sâu tối đa một cấp khi tài nguyên con không có ý nghĩa nếu đứng độc lập. Độ tin cậy: 0.85
- Trả về dữ liệu JSON với tên trường viết theo quy tắc camelCase nhất quán và không bao giờ trộn lẫn kiểu snake_case trong cùng một API. Độ tin cậy: 0.85
- Sử dụng các mã trạng thái HTTP tiêu chuẩn: 201 khi tạo mới thành công, 204 khi xóa thành công không kèm nội dung trả về, 404 khi không tìm thấy tài nguyên, 409 khi xảy ra xung đột. Độ tin cậy: 0.90
- Đặt các tham số phân trang, sắp xếp và lọc vào tham số truy vấn (query params); trả về siêu dữ liệu phân trang trong một cấu trúc vỏ bọc ổn định (`data`, `nextCursor`). Độ tin cậy: 0.85
- Ưu tiên phân trang dựa trên con trỏ (cursor-based pagination) hơn là dùng độ lệch (offset) đối với bất kỳ danh sách nào có thể phình to. Độ tin cậy: 0.90
- Xác thực mọi phần thân yêu cầu (request body) bằng một lược đồ (zod, OpenAPI, JSON Schema) và từ chối các trường không xác định. Độ tin cậy: 0.90
- Định hình cấu trúc phản hồi lỗi giống hệt nhau ở mọi nơi: gồm `code`, `message` và trường tùy chọn `details`. Độ tin cậy: 0.90
- Ưu tiên sử dụng khóa bất biến (idempotency keys) trên các điểm cuối POST có tạo giao dịch tiền tệ, đơn hàng hoặc gây ra hiệu ứng phụ. Độ tin cậy: 0.85
- Sử dụng ETags hoặc tiêu đề `If-Match` cho các thao tác cập nhật đồng thời trên những tài nguyên có sự tranh chấp. Độ tin cậy: 0.75
- Viết tài liệu API bằng chuẩn OpenAPI 3 và sinh mã trình khách (clients) tự động từ bản hợp đồng đó, thay vì tự viết tay các bộ SDK. Độ tin cậy: 0.85
- Không bao giờ đặt thông tin bí mật (secrets) hoặc thông tin định danh cá nhân (PII) vào URL hay chuỗi truy vấn (query strings); hãy đặt chúng trong phần tiêu đề (headers) hoặc phần thân yêu cầu (body). Độ tin cậy: 0.95
- Ưu tiên cơ chế mở rộng tường minh (`?include=`) hơn là lúc nào cũng nhúng sẵn toàn bộ các thực thể liên quan vào phản hồi. Độ tin cậy: 0.80
- Giữ cho các điểm cuối ghi dữ liệu (write endpoints) nhỏ gọn: mỗi đường dẫn chỉ thực hiện một thao tác thay đổi rõ ràng thay vì gom đủ thứ cập nhật vào một chỗ. Độ tin cậy: 0.80
- Giới hạn tần suất gọi (rate-limit) theo khóa API hoặc theo người dùng và trả về tiêu đề `Retry-After` khi chạm ngưỡng giới hạn. Độ tin cậy: 0.85
- Ưu tiên định dạng dấu thời gian chuẩn ISO-8601 theo múi giờ UTC và không bao giờ tự chế ra các định dạng chuỗi ngày tháng tùy chỉnh. Độ tin cậy: 0.95

# Đóng Gói Thư Viện Python taste
- Sử dụng `pyproject.toml` làm nguồn chân lý duy nhất và loại bỏ `setup.py` đối với các gói thư viện mới. Độ tin cậy: 0.95
- Ưu tiên cấu trúc thư mục `src/` để các bài kiểm thử không bao giờ vô tình nhập (import) cây mã nguồn chưa được đóng gói. Độ tin cậy: 0.90
- Sử dụng công cụ uv để cài đặt, quản lý tệp khóa (lockfiles) và môi trường ảo (virtualenvs) thay vì dùng kết hợp pip và venv thủ công. Độ tin cậy: 0.85
- Đóng gói bằng hatchling (hoặc một trình phụ trợ chuẩn PEP 517 khác) và không bao giờ commit các tệp wheel đã biên dịch vào git. Độ tin cậy: 0.90
- Ghim rõ ràng phiên bản Python tối thiểu được hỗ trợ và kiểm thử phiên bản cũ nhất được hỗ trợ đó trong quy trình CI. Độ tin cậy: 0.90
- Khai báo các thư viện phụ thuộc với ngưỡng phiên bản tối thiểu (lower bounds) mà bạn thực sự cần; tránh chặn cứng ngưỡng phiên bản tối đa (upper pins) trừ khi bắt buộc. Độ tin cậy: 0.80
- Giữ các nhóm phụ thuộc tùy chọn (`[dev]`, `[docs]`) dành riêng cho các công cụ phát triển mà người dùng cuối không cần phải cài đặt. Độ tin cậy: 0.85
- Định dạng mã nguồn bằng lệnh Ruff format và kiểm tra lỗi mã nguồn (lint) bằng Ruff; loại bỏ bộ đôi Black cùng flake8 đối với các dự án mới. Độ tin cậy: 0.85
- Kiểm tra kiểu dữ liệu (type-check) bằng pyright hoặc basedpyright ở chế độ nghiêm ngặt (strict mode) đối với các API công khai. Độ tin cậy: 0.80
- Kiểm thử bằng pytest và đặt các bài kiểm thử bên ngoài thư mục `src/`, nằm trong thư mục `tests/`. Độ tin cậy: 0.90
- Sử dụng cơ chế phát hành tin cậy (trusted publishing) từ GitHub Actions lên PyPI thay vì dùng các mã API token có thời hạn dài. Độ tin cậy: 0.90
- Đánh số phiên bản tự động từ các thẻ git tag (sử dụng hatch-vcs hoặc setuptools-scm). Độ tin cậy: 0.75
- Cung cấp tệp README ngắn gọn gồm hướng dẫn cài đặt, một ví dụ tối giản và liên kết tới tài liệu chi tiết; giữ phần nội dung dài ở trong thư mục docs/. Độ tin cậy: 0.90
- Bao gồm tệp đánh dấu `py.typed` khi bạn xuất bản các gói thư viện có định kiểu để người sử dụng nhận được thông tin kiểu dữ liệu nội tuyến. Độ tin cậy: 0.85
- Chạy lệnh `twine check` (hoặc lệnh tương đương trong uv) trên các gói thành phẩm đã đóng gói trước mỗi đợt phát hành. Độ tin cậy: 0.80
- Ưu tiên các điểm khởi chạy dạng `python -m package` hơn là các kịch bản bọc dòng lệnh (console-script wrappers) dễ lỗi khi cần gỡ lỗi. Độ tin cậy: 0.70
- Duy trì danh sách `__all__` và các mô-đun công khai một cách có chủ đích; đánh dấu các thành phần nội bộ bằng dấu gạch dưới ở đầu tên. Độ tin cậy: 0.80

# Khả Năng Quan Sát Hệ Thống (Observability) taste
- Tích hợp đo lường bằng OpenTelemetry trước tiên và coi các bộ SDK của nhà cung cấp chỉ là trình xuất dữ liệu (exporters), chứ không phải là API mà bạn gọi trực tiếp. Độ tin cậy: 0.90
- Xuất nhật ký (logs) có cấu trúc định dạng JSON với lược đồ ổn định (`level`, `msg`, `service`, `trace_id`) thay vì các chuỗi văn bản tự do. Độ tin cậy: 0.95
- Truyền `trace_id` và `span_id` vào mọi dòng nhật ký để nhật ký và dấu vết (traces) tự động liên kết với nhau. Độ tin cậy: 0.95
- Ưu tiên bộ chỉ số RED cho các dịch vụ (tốc độ yêu cầu - rate, lỗi - errors, thời lượng - duration) và bộ chỉ số USE cho tài nguyên (mức sử dụng - utilization, độ bão hòa - saturation, lỗi - errors). Độ tin cậy: 0.85
- Kiểm soát chặt chẽ số lượng giá trị duy nhất (cardinality): không bao giờ đưa ID người dùng hoặc URL thô vào nhãn của số liệu đo lường (metric labels). Độ tin cậy: 0.95
- Lấy mẫu dấu vết từ đầu luồng (head-based sampling) trên môi trường production và luôn giữ lại toàn bộ các trường hợp lỗi cũng như các yêu cầu xử lý chậm. Độ tin cậy: 0.85
- Đặt tên cho các đoạn dấu vết (spans) theo đơn vị công việc (`http.server`, `db.query`, `queue.publish`), không đặt theo tên hàm nội bộ. Độ tin cậy: 0.80
- Ghi nhật ký ở mức info cho các sự kiện nghiệp vụ thành công, mức warn cho các sự cố có thể tự phục hồi, và chỉ dùng mức error khi thực sự cần con người kiểm tra. Độ tin cậy: 0.85
- Không bao giờ ghi thông tin bí mật (secrets), token, mật khẩu hoặc toàn bộ nội dung yêu cầu (request bodies) có chứa thông tin định danh cá nhân (PII) vào nhật ký. Độ tin cậy: 0.95
- Xác định các chỉ số SLO kèm theo ngân sách lỗi (error budgets) và cảnh báo dựa trên tốc độ tiêu hao ngân sách lỗi (burn rate), chứ không cảnh báo trên mọi đợt tăng vọt CPU đơn lẻ. Độ tin cậy: 0.85
- Ưu tiên sử dụng các mẫu đại diện (exemplars) giúp liên kết một điểm tăng vọt của số liệu với một dấu vết (trace) cụ thể hơn là chỉ phỏng đoán mò mẫm từ bảng điều khiển. Độ tin cậy: 0.80
- Cung cấp một bảng điều khiển tối thiểu cho mỗi dịch vụ: lưu lượng truy cập, độ trễ p95/p99, tỷ lệ lỗi và độ bão hòa tài nguyên. Độ tin cậy: 0.85
- Đưa `deployment.environment` và phiên bản dịch vụ vào làm thuộc tính tài nguyên (resource attributes) trên mọi tín hiệu thu thập được. Độ tin cậy: 0.90
- Sử dụng dữ liệu hành lý đi kèm (baggage) một cách tiết kiệm; đặt thông tin định danh ổn định vào thuộc tính tài nguyên thay vì lặp lại ở mọi thuộc tính của từng span. Độ tin cậy: 0.75
- Kiểm thử việc tích hợp đo lường trong quy trình CI bằng một yêu cầu kiểm thử khói (smoke request) nhằm xác nhận rằng có một span và một dòng nhật ký được sinh ra. Độ tin cậy: 0.70
- Đặt các tài liệu hướng dẫn xử lý sự cố (runbooks) ngay cạnh các cảnh báo để người trực ca (on-call) biết rõ ba bước kiểm tra đầu tiên cần thực hiện. Độ tin cậy: 0.85
- Ưu tiên sử dụng các phân nhóm biểu đồ tần suất (histogram buckets) được tinh chỉnh sát với mục tiêu độ trễ SLO của bạn hơn là dùng các phân nhóm mặc định. Độ tin cậy: 0.80

# Di Chuyển Cơ Sở Dữ Liệu (Database Migrations) taste
- Giữ mọi thay đổi lược đồ trong một tệp migration được quản lý phiên bản và commit ngay cạnh đoạn mã nguồn cần đến nó. Độ tin cậy: 0.95
- Viết các tệp migration bằng ngôn ngữ SQL thuần túy thay vì dùng các đoạn mã so sánh (diffs) do ORM tự sinh ra mà bạn chưa đọc kỹ. Độ tin cậy: 0.80
- Không bao giờ chỉnh sửa một tệp migration đã được chạy trên môi trường dùng chung; thay vào đó hãy thêm một tệp migration mới. Độ tin cậy: 0.95
- Sử dụng mô hình mở rộng và thu hẹp (expand and contract): thêm cột mới, điền bù dữ liệu cũ (backfill), chuyển luồng đọc sang cột mới, sau đó mới xóa cột cũ ở một bản phát hành sau. Độ tin cậy: 0.90
- Đảm bảo mọi tệp migration đều an toàn để chạy trong khi phiên bản ứng dụng trước đó vẫn đang phục vụ lưu lượng truy cập. Độ tin cậy: 0.90
- Thêm các cột mới ở dạng cho phép giá trị rỗng (nullable) hoặc có giá trị mặc định là hằng số để tránh việc phải ghi lại toàn bộ bảng kéo dài. Độ tin cậy: 0.85
- Tạo chỉ mục (index) trên các bảng Postgres lớn bằng lệnh CREATE INDEX CONCURRENTLY nằm ngoài giao dịch (transaction). Độ tin cậy: 0.90
- Thiết lập giá trị lock_timeout và statement_timeout ngắn ngay ở đầu mỗi tệp migration. Độ tin cậy: 0.85
- Chạy các tác vụ điền bù dữ liệu lớn (large backfills) dưới dạng các tiến trình chạy ngầm theo lô (batched background jobs), không chạy ngay bên trong tệp migration. Độ tin cậy: 0.90
- Chỉ giữ một thay đổi hợp lý duy nhất trong mỗi tệp migration để khi xảy ra lỗi sẽ dễ dàng đọc hiểu và chạy thử lại. Độ tin cậy: 0.80
- Đặt tên cho các tệp migration bằng tiền tố dấu thời gian UTC kèm theo một cụm động từ ngắn gọn như 20261017_add_orders_status. Độ tin cậy: 0.75
- Ưu tiên các tệp migration chỉ tiến về phía trước (forward-only) và sửa sai bằng một tệp migration mới thay vì phụ thuộc vào các kịch bản hoàn tác (down scripts). Độ tin cậy: 0.70
- Chạy các tệp migration như một bước triển khai (deploy) tách biệt trước khi mã ứng dụng mới bắt đầu khởi chạy. Độ tin cậy: 0.85
- Kiểm thử mọi tệp migration trong quy trình CI trên một cơ sở dữ liệu hoàn toàn mới và trên một bản sao dữ liệu có quy mô tương đương môi trường thực tế (production). Độ tin cậy: 0.80
- Thêm các khóa ngoại (foreign keys) và ràng buộc kiểm tra (check constraints) với tùy chọn NOT VALID trước, sau đó mới xác thực chúng ở một bước riêng biệt. Độ tin cậy: 0.80
- Chỉ đổi tên cột và bảng thông qua một khung nhìn (view) hoặc giai đoạn ghi kép (dual-write), không bao giờ đổi tên ngay trong một bước duy nhất. Độ tin cậy: 0.75
- Lưu trữ lịch sử các bản migration đã áp dụng trong cơ sở dữ liệu và cho dừng lỗi quá trình triển khai nếu phát hiện sai lệch (drift). Độ tin cậy: 0.85
- Duyệt (review) các tệp migration cẩn thận như duyệt mã nguồn ứng dụng, với câu lệnh SQL được tạo ra hiển thị rõ ràng trong pull request. Độ tin cậy: 0.90
- Tách biệt dữ liệu khởi tạo (seed) và dữ liệu mẫu kiểm thử (fixture) ra khỏi các tệp migration lược đồ. Độ tin cậy: 0.80

# Quản Lý Trạng Thái React taste
- Bắt đầu với useState cục bộ và chỉ nâng trạng thái lên (lift state) khi hai thành phần anh em thực sự cần dùng chung nó. Độ tin cậy: 0.95
- Coi dữ liệu từ máy chủ là một bộ nhớ đệm (cache) và quản lý nó bằng TanStack Query thay vì đưa vào kho lưu trữ trạng thái toàn cục (global store). Độ tin cậy: 0.90
- Giữ các trạng thái xứng đáng nằm trên URL như bộ lọc, thẻ tab và phân trang ở trong các tham số tìm kiếm (search params). Độ tin cậy: 0.90
- Sử dụng Zustand khi trạng thái máy khách dùng chung vượt quá phạm vi của một cây thành phần (component tree) đơn lẻ. Độ tin cậy: 0.80
- Tránh dùng Redux cho các dự án mới trừ khi nhóm phát triển đã phụ thuộc sẵn vào bộ công cụ devtools và middleware của nó. Độ tin cậy: 0.70
- Sử dụng React Context cho các giá trị ít thay đổi như giao diện (theme), ngôn ngữ bản địa (locale) và người dùng hiện tại, không dùng cho dữ liệu thay đổi liên tục. Độ tin cậy: 0.90
- Tính toán các giá trị phái sinh ngay trong quá trình kết xuất (render) thay vì đồng bộ hóa chúng vào một trạng thái phụ bằng useEffect. Độ tin cậy: 0.95
- Mô hình hóa trạng thái cục bộ phức tạp bằng useReducer kết hợp với kiểu hợp phân biệt (discriminated union) của các hành động (actions). Độ tin cậy: 0.80
- Biểu diễn trạng thái bất đồng bộ dưới dạng một kiểu hợp (union) duy nhất như idle, loading, success và error thay vì dùng nhiều biến boolean rời rạc. Độ tin cậy: 0.85
- Quản lý trạng thái biểu mẫu trong React Hook Form kết hợp với lược đồ kiểm tra zod thay vì tự viết useState thủ công cho từng trường. Độ tin cậy: 0.80
- Chỉ chọn lát cắt dữ liệu (slice) nhỏ nhất từ kho lưu trữ trong mỗi thành phần để tránh việc kết xuất lại (re-render) không cần thiết. Độ tin cậy: 0.85
- Lưu trữ các mã định danh (id) trong trạng thái và tra cứu các đối tượng đầy đủ, thay vì sao chép trùng lặp dữ liệu lồng nhau. Độ tin cậy: 0.80
- Sử dụng cập nhật lạc quan (optimistic updates) cho các thao tác nhanh của người dùng và hoàn tác (roll back) khi xảy ra lỗi. Độ tin cậy: 0.75
- Không bao giờ thay đổi trực tiếp (mutate) các đối tượng trạng thái tại chỗ; hãy trả về các đối tượng mới hoặc dùng Immer cho các cập nhật nằm sâu bên trong. Độ tin cậy: 0.90
- Giữ cho trạng thái lưu trữ bền vững (persisted state) nhỏ gọn và có đánh số phiên bản khi lưu vào localStorage. Độ tin cậy: 0.75
- Đặt lại trạng thái của thành phần bằng cách thay đổi thuộc tính key của nó thay vì viết các hàm hiệu ứng (effects) để đặt lại. Độ tin cậy: 0.80
- Đặt các kho lưu trữ trạng thái (stores) nằm cạnh tính năng sở hữu chúng thay vì gom tất cả vào một thư mục store toàn cục duy nhất. Độ tin cậy: 0.75
- Định kiểu tường minh cho mọi kho lưu trữ và giá trị context, đồng thời tránh sử dụng kiểu any trong cấu trúc trạng thái. Độ tin cậy: 0.90

# Công Cụ CLI Rust taste
- Phân tích cú pháp đối số dòng lệnh bằng clap sử dụng derive API và dùng các chú thích tài liệu (doc comments) làm văn bản trợ giúp. Độ tin cậy: 0.95
- Trả về kiểu anyhow::Result từ hàm main và thêm ngữ cảnh cho mọi bước có thể gây lỗi bằng phương thức .context(). Độ tin cậy: 0.90
- Định nghĩa các kiểu lỗi của thư viện bằng thiserror và chỉ giữ anyhow ở trong tệp thực thi nhị phân (binary). Độ tin cậy: 0.85
- Tách crate thành một tệp main.rs mỏng và một tệp lib.rs chứa toàn bộ logic thực tế để phục vụ kiểm thử. Độ tin cậy: 0.85
- Ghi kết quả đầu ra thông thường vào stdout và ghi nhật ký (logs), tiến trình cũng như thông báo lỗi vào stderr. Độ tin cậy: 0.95
- Cung cấp cờ --json cho đầu ra để máy đọc và tuần tự hóa (serialize) dữ liệu đó bằng serde. Độ tin cậy: 0.85
- Sử dụng thư viện tracing với bộ lọc môi trường được điều khiển bởi các cờ -v và cho phép ghi đè bằng biến môi trường RUST_LOG. Độ tin cậy: 0.80
- Tôn trọng biến môi trường NO_COLOR và tự động tắt màu sắc khi stdout không phải là một thiết bị đầu cuối (terminal). Độ tin cậy: 0.90
- Chỉ hiển thị thanh tiến trình bằng indicatif đối với các tác vụ kéo dài hơn khoảng một giây. Độ tin cậy: 0.75
- Thoát chương trình với các mã thoát (exit codes) riêng biệt, được ghi tài liệu rõ ràng thay vì lúc nào cũng trả về 1. Độ tin cậy: 0.80
- Đọc cấu hình theo thứ tự ưu tiên: cờ dòng lệnh trước, sau đó đến biến môi trường, rồi mới đến tệp cấu hình TOML. Độ tin cậy: 0.80
- Tìm đường dẫn cấu hình và bộ nhớ đệm (cache) bằng crate directories thay vì gán cứng đường dẫn thư mục người dùng (home paths). Độ tin cậy: 0.80
- Kiểm thử đầu cuối (end-to-end) tệp thực thi nhị phân bằng assert_cmd và kiểm thử chụp nhanh đầu ra (snapshot output) bằng insta. Độ tin cậy: 0.85
- Tránh sử dụng async và tokio trừ khi công cụ thực sự phải xử lý các tác vụ mạng đồng thời. Độ tin cậy: 0.75
- Tạo kịch bản tự động hoàn thành lệnh trên shell (shell completions) và trang hướng dẫn man page bằng clap_complete và clap_mangen ngay tại thời điểm biên dịch (build time). Độ tin cậy: 0.75
- Phân phối các tệp thực thi nhị phân đã biên dịch sẵn cho Linux, macOS và Windows bằng cargo-dist từ GitHub Actions. Độ tin cậy: 0.80
- Chạy cargo clippy với thiết lập từ chối mọi cảnh báo (warnings denied) và chạy cargo fmt --check trong quy trình CI. Độ tin cậy: 0.90
- Thiết lập opt-level, lto và strip trong cấu hình phát hành (release profile) để giữ kích thước tệp nhị phân nhỏ gọn. Độ tin cậy: 0.70
- Xử lý tổ hợp phím Ctrl+C một cách gọn gàng bằng crate ctrlc và không để lại các tệp đang ghi dở dang. Độ tin cậy: 0.80

# Gu kiểm thử của một nhóm phát triển TypeScript thực dụng
- Sử dụng vitest làm trình chạy kiểm thử mặc định cho cả kiểm thử đơn vị (unit test) và kiểm thử tích hợp (integration test). Độ tin cậy: 0.90
- Đặt các tệp kiểm thử ngay cạnh mã nguồn mà chúng kiểm tra với tên *.test.ts. Độ tin cậy: 0.85
- Đặt tên các bài kiểm thử bằng những câu văn rõ ràng mô tả hành vi, chứ không phải tên phương thức. Độ tin cậy: 0.90
- Tuân theo cấu trúc chuẩn bị (arrange), thực thi (act), khẳng định (assert) với một dòng trống ngăn cách giữa mỗi giai đoạn. Độ tin cậy: 0.75
- Kiểm thử hành vi công khai thông qua API của mô-đun thay vì kiểm thử các hàm nội bộ (private). Độ tin cậy: 0.90
- Ưu tiên sử dụng các thành phần phối hợp thực tế và các bản giả lập trong bộ nhớ (in-memory fakes) hơn là dùng mock. Độ tin cậy: 0.85
- Chỉ làm giả (mock) tại các ranh giới tiến trình chẳng hạn như mạng, đồng hồ hệ thống và bộ sinh số ngẫu nhiên. Độ tin cậy: 0.90
- Chặn bắt các yêu cầu HTTP bằng msw thay vì tự viết hàm giả lập (stub) cho fetch bằng tay. Độ tin cậy: 0.80
- Chạy các bài kiểm thử cơ sở dữ liệu với một Postgres thực sự trong Testcontainers, chứ không dùng SQLite. Độ tin cậy: 0.80
- Đóng băng thời gian bằng bộ đếm thời gian giả (fake timers) và truyền giá trị mầm (seed) cho bất kỳ thứ gì mang tính ngẫu nhiên. Độ tin cậy: 0.90
- Tạo dữ liệu kiểm thử bằng các hàm khởi tạo (factory functions) nhỏ cho phép ghi đè giá trị. Độ tin cậy: 0.85
- Giữ cho các bài kiểm thử chụp nhanh (snapshot tests) ít và nhỏ gọn, đồng thời xem xét kỹ mọi thay đổi khác biệt của snapshot. Độ tin cậy: 0.75
- Sử dụng Playwright cho một lớp mỏng các bài kiểm thử đầu-cuối (end-to-end) chỉ tập trung vào những luồng người dùng quan trọng. Độ tin cậy: 0.85
- Chọn các phần tử theo vai trò (role) và tên hỗ trợ tiếp cận (accessible name) trong các bài kiểm thử giao diện, không bao giờ chọn theo class CSS. Độ tin cậy: 0.90
- Coi một bài kiểm thử chập chờn (flaky test) là một lỗi: cách ly nó ngay trong ngày và sửa hoặc xóa nó trong vòng một tuần. Độ tin cậy: 0.85
- Không bao giờ dùng lệnh sleep trong kiểm thử; thay vào đó hãy chờ một điều kiện cụ thể xảy ra. Độ tin cậy: 0.95
- Giữ cho toàn bộ bộ kiểm thử đơn vị chạy xong dưới một phút trên máy tính xách tay. Độ tin cậy: 0.75
- Theo dõi độ bao phủ mã nguồn (coverage) như một xu hướng trong CI nhưng không chặn việc gộp mã (merge) dựa trên một tỷ lệ phần trăm cố định. Độ tin cậy: 0.70
- Bổ sung kiểm thử dựa trên thuộc tính (property-based tests) bằng fast-check cho các bộ phân tích cú pháp (parsers) và logic thuần túy. Độ tin cậy: 0.65
- Viết một bài kiểm thử hồi quy báo lỗi trước khi sửa bất kỳ lỗi nào được báo cáo. Độ tin cậy: 0.90
- Chạy các bài kiểm thử theo thứ tự ngẫu nhiên để phát hiện trạng thái dùng chung bị ẩn. Độ tin cậy: 0.70

# Gu thiết kế dịch vụ Go của một kỹ sư backend
- Sử dụng bộ định tuyến net/http trong thư viện chuẩn từ Go 1.22 trước khi tìm đến một framework. Độ tin cậy: 0.85
- Bố trí dự án theo cấu trúc cmd/<service>/main.go cùng với các gói trong internal/, và bỏ qua thư mục pkg/. Độ tin cậy: 0.80
- Giữ cho tệp main.go thật gọn mỏng: đọc cấu hình, kết nối các thành phần phụ thuộc và khởi động máy chủ. Độ tin cậy: 0.90
- Truyền context.Context làm đối số đầu tiên cho mọi hàm thực hiện thao tác vào/ra (I/O). Độ tin cậy: 0.95
- Bọc lỗi bằng fmt.Errorf và %w, đồng thời kiểm tra lỗi bằng errors.Is và errors.As. Độ tin cậy: 0.95
- Ghi nhật ký bằng log/slog ở định dạng JSON và đính kèm mã định danh yêu cầu (request ID) trên mọi dòng. Độ tin cậy: 0.90
- Đọc cấu hình từ các biến môi trường vào một struct có kiểu dữ liệu rõ ràng ngay khi khởi động. Độ tin cậy: 0.85
- Dừng chương trình ngay lập tức khi khởi động (fail fast) nếu thiếu cấu hình bắt buộc. Độ tin cậy: 0.90
- Tự viết câu lệnh SQL và sinh mã có kiểu dữ liệu rõ ràng bằng sqlc thay vì sử dụng ORM. Độ tin cậy: 0.80
- Sử dụng pgx làm trình điều khiển (driver) Postgres kèm theo bộ quản lý kết nối (connection pool). Độ tin cậy: 0.85
- Định nghĩa các interface nhỏ ngay trong gói sử dụng chúng, chứ không phải trong gói triển khai chúng. Độ tin cậy: 0.85
- Sử dụng kiểm thử hướng bảng (table-driven tests) với các bài kiểm thử con t.Run. Độ tin cậy: 0.90
- Chạy go test với cờ -race trong CI trên mọi pull request. Độ tin cậy: 0.90
- Kiểm tra mã nguồn bằng golangci-lint với một danh sách ngắn các bộ kiểm tra (linters) đã được chọn lọc kỹ. Độ tin cậy: 0.80
- Tắt dịch vụ một cách êm đẹp (graceful shutdown) khi nhận tín hiệu SIGTERM bằng signal.NotifyContext và server.Shutdown. Độ tin cậy: 0.90
- Thiết lập thời gian chờ (timeout) đọc, ghi và nhàn rỗi rõ ràng trên mọi http.Server và http.Client. Độ tin cậy: 0.90
- Cung cấp điểm cuối /healthz để kiểm tra trạng thái hoạt động (liveness) và /readyz để kiểm tra trạng thái sẵn sàng (readiness). Độ tin cậy: 0.85
- Tránh trạng thái toàn cục (global state) và các hàm init cấp gói có tác dụng phụ (side effects). Độ tin cậy: 0.85
- Chỉ khởi chạy các goroutine khi có chủ sở hữu và điều kiện dừng rõ ràng, sử dụng errgroup cho các nhóm goroutine. Độ tin cậy: 0.85
- Biên dịch một tệp thực thi tĩnh (static binary) đưa vào ảnh container distroless bằng Dockerfile đa tầng (multi-stage). Độ tin cậy: 0.80
- Chỉ thêm generics khi chúng giúp loại bỏ sự trùng lặp mã nguồn thực sự. Độ tin cậy: 0.70

# Gu thiết kế monorepo của một kỹ sư nền tảng (platform engineer)
- Sử dụng pnpm workspaces với một tệp khóa (lockfile) duy nhất ở thư mục gốc của kho mã nguồn. Độ tin cậy: 0.95
- Đặt các ứng dụng có thể triển khai vào thư mục apps/ và các thư viện dùng chung vào thư mục packages/. Độ tin cậy: 0.90
- Điều phối các tác vụ bằng Turborepo và bật bộ nhớ đệm từ xa (remote caching) trong CI. Độ tin cậy: 0.85
- Tham chiếu các gói nội bộ bằng giao thức workspace:*. Độ tin cậy: 0.90
- Đặt tên mọi gói nội bộ dưới cùng một phạm vi (scope) npm chẳng hạn như @acme/. Độ tin cậy: 0.85
- Chia sẻ một cấu hình tsconfig cơ sở từ gói packages/tsconfig và kế thừa (extend) nó ở mọi nơi. Độ tin cậy: 0.85
- Sử dụng TypeScript project references để trình soạn thảo và tsc biên dịch tăng dần (incremental build). Độ tin cậy: 0.70
- Duy trì một phiên bản duy nhất cho mỗi thư viện phụ thuộc bên ngoài trên toàn bộ kho mã nguồn, được kiểm soát bằng syncpack. Độ tin cậy: 0.80
- Phân phối các gói nội bộ dưới dạng mã nguồn TypeScript và để các ứng dụng tự biên dịch chúng, trừ khi các gói đó được xuất bản công khai. Độ tin cậy: 0.75
- Quản lý phiên bản và xuất bản các gói công khai bằng Changesets. Độ tin cậy: 0.85
- Chỉ chạy CI cho các gói bị ảnh hưởng bởi thay đổi, sử dụng turbo --filter với một dải commit git. Độ tin cậy: 0.85
- Cấm import sâu vào cấu trúc bên trong giữa các gói và chỉ cho phép import qua bản đồ exports đã khai báo. Độ tin cậy: 0.85
- Kiểm soát ranh giới phụ thuộc bằng quy tắc lint để các ứng dụng không bao giờ import lẫn nhau. Độ tin cậy: 0.90
- Giữ cho tệp package.json ở thư mục gốc không chứa các thư viện phụ thuộc lúc chạy (runtime dependencies). Độ tin cậy: 0.80
- Phân công người phụ trách cho từng thư mục bằng tệp CODEOWNERS. Độ tin cậy: 0.80
- Cố định phiên bản Node.js và pnpm bằng tệp .nvmrc và trường packageManager. Độ tin cậy: 0.90
- Ưu tiên sử dụng một cấu hình lint và định dạng mã nguồn duy nhất ở thư mục gốc thay vì sao chép vào từng gói. Độ tin cậy: 0.80
- Đặt tên các script giống hệt nhau cho mọi gói: build, dev, lint, test và typecheck. Độ tin cậy: 0.90
- Tránh sự phụ thuộc vòng (circular dependencies) giữa các gói và kiểm tra chúng trong CI. Độ tin cậy: 0.85
- Chỉ tách riêng một gói ra khi thực sự có nơi thứ hai cần sử dụng nó. Độ tin cậy: 0.75

# Phong cách (taste) quy trình làm việc Git của một đội ngũ phát triển theo mô hình trunk-based
- Làm việc theo mô hình trunk-based: tạo các nhánh có vòng đời ngắn tách ra từ nhánh main và gộp (merge) lại trong vòng hai ngày. Độ tin cậy: 0.90
- Đặt tên nhánh theo cấu trúc <type>/<short-topic>, ví dụ: fix/login-redirect. Độ tin cậy: 0.75
- Viết tiêu đề commit ở thức mệnh lệnh (imperative mood) và giữ độ dài dưới 72 ký tự. Độ tin cậy: 0.90
- Sử dụng các tiền tố theo chuẩn Conventional Commits (feat, fix, chore, docs, refactor) để có thể tự động tạo nhật ký thay đổi (changelog). Độ tin cậy: 0.80
- Giải thích lý do tại sao thay đổi được thực hiện trong phần thân (body) của commit, chứ không nhắc lại những gì bản so sánh (diff) đã hiển thị. Độ tin cậy: 0.85
- Giữ cho mỗi commit luôn có thể biên dịch/build thành công và chỉ tập trung vào một thay đổi hợp lý duy nhất. Độ tin cậy: 0.85
- Rebase nhánh của bạn lên trên nhánh main thay vì merge nhánh main vào nhánh của bạn. Độ tin cậy: 0.80
- Thực hiện squash-merge đối với các pull request để nhánh main chỉ có một commit duy nhất cho mỗi thay đổi. Độ tin cậy: 0.75
- Giữ cho các pull request có dưới khoảng 400 dòng thay đổi; chia nhỏ các công việc lớn hơn thành chuỗi các PR xếp chồng nhau (stacked PRs). Độ tin cậy: 0.85
- Đưa phần mô tả ngắn gọn gồm làm gì (what), tại sao (why) và cách kiểm thử (how-to-test) vào mọi phần mô tả của pull request. Độ tin cậy: 0.85
- Yêu cầu tối thiểu một đánh giá chấp thuận (approving review) và hệ thống CI báo xanh trước khi gộp vào nhánh main. Độ tin cậy: 0.90
- Bảo vệ nhánh main: không cho phép đẩy mã trực tiếp (direct push) và không cho phép ép đẩy mã (force push). Độ tin cậy: 0.95
- Chỉ thực hiện force push trên nhánh của chính bạn và luôn đi kèm cờ --force-with-lease. Độ tin cậy: 0.90
- Ẩn các tính năng chưa hoàn thiện đằng sau các cờ tính năng (feature flags) thay vì duy trì các nhánh tính năng kéo dài. Độ tin cậy: 0.85
- Gắn thẻ (tag) các bản phát hành bằng thẻ phiên bản ngữ nghĩa (semantic version) như v1.4.2 trên nhánh main. Độ tin cậy: 0.85
- Không bao giờ commit thông tin bí mật (secrets); hãy chạy công cụ quét bí mật trong cả pre-commit hook và hệ thống CI. Độ tin cậy: 0.95
- Giữ cho các pre-commit hook chạy nhanh (dưới năm giây) và để các bước kiểm tra tốn thời gian cho hệ thống CI. Độ tin cậy: 0.80
- Sử dụng tệp .gitattributes để chuẩn hóa ký tự xuống dòng (line endings) và đánh dấu các tệp được sinh tự động. Độ tin cậy: 0.70
- Lưu trữ các tệp nhị phân dung lượng lớn trong Git LFS hoặc dịch vụ lưu trữ đối tượng (object storage), không bao giờ đưa trực tiếp vào kho mã nguồn (repo). Độ tin cậy: 0.85
- Sử dụng git bisect kết hợp với kịch bản kiểm thử tự động để truy tìm nguyên nhân gây lỗi hồi quy (regressions). Độ tin cậy: 0.70
- Hoàn tác (revert) một commit gây lỗi trên nhánh main trước tiên rồi mới tiến hành điều tra nguyên nhân sau. Độ tin cậy: 0.85
- Thêm tệp CODEOWNERS để hệ thống tự động gửi yêu cầu đánh giá đến đúng người phụ trách. Độ tin cậy: 0.75
- Tự động xóa các nhánh sau khi chúng đã được gộp thành công. Độ tin cậy: 0.90

# Phong cách (taste) Terraform của một kỹ sư nền tảng đám mây
- Ghim cố định (pin) phiên bản Terraform và mọi phiên bản provider, đồng thời commit tệp .terraform.lock.hcl. Độ tin cậy: 0.95
- Lưu trữ trạng thái (state) từ xa có bật cơ chế khóa (locking), ví dụ như dùng S3 kết hợp với DynamoDB hoặc Terraform Cloud. Độ tin cậy: 0.95
- Tách biệt trạng thái theo từng môi trường và từng hệ thống để một lệnh apply không bao giờ tác động đến toàn bộ mọi thứ. Độ tin cậy: 0.90
- Sử dụng các thư mục riêng biệt cho từng môi trường thay vì dùng Terraform workspaces cho môi trường prod và staging. Độ tin cậy: 0.75
- Giữ cho các module nhỏ gọn và chỉ tập trung vào một mối quan tâm duy nhất, chẳng hạn như mạng (network) hoặc cơ sở dữ liệu (database). Độ tin cậy: 0.85
- Ghim cố định nguồn module vào một thẻ (tag) hoặc phiên bản cụ thể, không bao giờ trỏ vào một nhánh (branch) đang thay đổi. Độ tin cậy: 0.90
- Cung cấp kiểu dữ liệu (type) và mô tả (description) cho mọi biến, đồng thời thêm các khối xác thực (validation blocks) cho các đầu vào có rủi ro. Độ tin cậy: 0.85
- Chỉ xuất (expose) những đầu ra (outputs) mà các stack khác thực sự sử dụng. Độ tin cậy: 0.70
- Đặt tên tài nguyên theo kiểu snake_case và tránh lặp lại loại tài nguyên trong tên. Độ tin cậy: 0.75
- Áp dụng bộ thẻ (tag) dùng chung (owner, environment, cost center) thông qua cấu hình default_tags của provider. Độ tin cậy: 0.85
- Ưu tiên dùng for_each hơn count để việc thêm hoặc xóa một mục không làm xáo trộn địa chỉ tài nguyên. Độ tin cậy: 0.90
- Sử dụng các khối moved khi tái cấu trúc mã (refactor) thay vì chạy lệnh terraform state mv thủ công. Độ tin cậy: 0.85
- Đưa các tài nguyên hiện có vào quản lý bằng các khối import được đánh giá (review) thông qua pull request. Độ tin cậy: 0.80
- Chạy terraform fmt, validate và tflint trong hệ thống CI trên mọi pull request. Độ tin cậy: 0.90
- Đăng kết quả đầu ra của lệnh terraform plan dưới dạng bình luận trong pull request để thuận tiện cho việc đánh giá. Độ tin cậy: 0.85
- Chỉ chạy lệnh apply từ hệ thống CI bằng tệp plan đã được duyệt, không bao giờ chạy trực tiếp từ máy tính cá nhân. Độ tin cậy: 0.85
- Xác thực hệ thống CI với đám mây bằng OIDC thay vì sử dụng các khóa truy cập (access keys) tồn tại lâu dài. Độ tin cậy: 0.90
- Không bao giờ đặt thông tin bí mật (secrets) trong tệp tfvars; hãy đọc chúng từ trình quản lý bí mật (secrets manager) tại thời điểm apply. Độ tin cậy: 0.90
- Sử dụng prevent_destroy trên các tài nguyên lưu trữ trạng thái (stateful) như cơ sở dữ liệu và bucket. Độ tin cậy: 0.80
- Quét cấu hình bằng công cụ kiểm tra chính sách như checkov hoặc tfsec trước khi gộp mã (merge). Độ tin cậy: 0.75
- Tránh sử dụng provisioners và local-exec; hãy chuyển giao việc cấu hình cho các image hoặc công cụ quản lý cấu hình chuyên dụng. Độ tin cậy: 0.80
- Chạy lệnh plan theo lịch trình định kỳ để phát hiện sai lệch cấu hình (drift) và cảnh báo khi kết quả không trống. Độ tin cậy: 0.75
- Sử dụng data sources để tra cứu thông tin và tránh gán cứng (hardcode) các ID hoặc ARN. Độ tin cậy: 0.80

# Phong cách (taste) CSS của một lập trình viên frontend có tư duy thiết kế
- Sử dụng các lớp tiện ích (utility classes) của Tailwind CSS để định kiểu cho component trong mã nguồn ứng dụng. Độ tin cậy: 0.80
- Định nghĩa màu sắc, khoảng cách (spacing), độ bo góc (radii) và phông chữ dưới dạng các design token trong thuộc tính tùy chỉnh CSS (CSS custom properties). Độ tin cậy: 0.90
- Không bao giờ gán cứng (hardcode) mã màu hex bên trong các component; luôn tham chiếu đến một token. Độ tin cậy: 0.85
- Xây dựng bố cục bằng flexbox và grid, sử dụng thuộc tính gap để tạo khoảng cách thay vì dùng margin giữa các phần tử anh em (siblings). Độ tin cậy: 0.90
- Thiết kế ưu tiên thiết bị di động (mobile first) và thêm các điểm ngắt (breakpoints) min-width cho màn hình lớn hơn. Độ tin cậy: 0.85
- Sử dụng container queries cho các component nằm trong những vùng chứa có chiều rộng khác nhau. Độ tin cậy: 0.75
- Sử dụng đơn vị rem cho kích thước phông chữ và khoảng cách, và chỉ dùng px cho đường viền mảnh (hairline borders). Độ tin cậy: 0.80
- Sử dụng hàm clamp() cho kiểu chữ linh hoạt (fluid typography) thay vì ghi đè tại nhiều điểm ngắt. Độ tin cậy: 0.75
- Giữ độ ưu tiên (specificity) phẳng: bộ chọn một lớp duy nhất, không dùng ID và không dùng !important bên ngoài các lớp tiện ích. Độ tin cậy: 0.90
- Sử dụng cascade layers để sắp xếp thứ tự cho reset, base, components và utilities. Độ tin cậy: 0.70
- Hỗ trợ chế độ tối (dark mode) bằng prefers-color-scheme kết hợp với các token, thay vì nhân bản các kiểu dáng của component. Độ tin cậy: 0.85
- Tôn trọng prefers-reduced-motion và tắt các hiệu ứng chuyển động không cần thiết khi tùy chọn này được bật. Độ tin cậy: 0.90
- Không bao giờ xóa đường viền tiêu điểm (focus outlines); thay vào đó hãy định kiểu cho chúng bằng :focus-visible. Độ tin cậy: 0.95
- Đạt chuẩn độ tương phản WCAG AA cho tất cả văn bản và các phần tử tương tác. Độ tin cậy: 0.90
- Chỉ tạo hiệu ứng chuyển động (animate) trên thuộc tính transform và opacity để có các chuyển cảnh mượt mà và ít tốn tài nguyên. Độ tin cậy: 0.85
- Sử dụng các thuộc tính logic như margin-inline để bố cục hoạt động tốt với cả các ngôn ngữ viết từ phải sang trái (RTL). Độ tin cậy: 0.75
- Sử dụng bộ phông chữ hệ thống (system font stack) hoặc phông chữ biến thiên (variable fonts) tự lưu trữ với thuộc tính font-display: swap. Độ tin cậy: 0.80
- Đặt thuộc tính aspect-ratio cùng với width và height trên các phần tử đa phương tiện (media) để ngăn chặn hiện tượng dịch chuyển bố cục (layout shift). Độ tin cậy: 0.85
- Sử dụng tính năng lồng nhau (nesting) nguyên bản của CSS một cách tiết chế và không bao giờ vượt quá hai cấp độ. Độ tin cậy: 0.70
- Tự động sắp xếp các lớp Tailwind bằng plugin Prettier. Độ tin cậy: 0.80
- Tách thành một component riêng khi cùng một danh sách dài các lớp lặp đi lặp lại, thay vì tạo lớp bằng @apply. Độ tin cậy: 0.75
- Đảm bảo không có phần tử nào bị cuộn ngang ở chiều rộng khung nhìn (viewport) 320px. Độ tin cậy: 0.85

# Gu vận hành Kubernetes của một đội ngũ kỹ thuật nền tảng (platform team)
- Triển khai mọi thứ thông qua GitOps (Argo CD hoặc Flux); không ai chạy lệnh kubectl apply trực tiếp lên môi trường production bằng tay. Độ tin cậy: 0.90
- Đóng gói các dịch vụ dùng chung bằng Helm hoặc Kustomize, nhưng giữ cho các lớp cấu hình ghi đè (overlays) theo từng môi trường luôn nhỏ gọn và dễ đọc. Độ tin cậy: 0.80
- Thiết lập mức yêu cầu (requests) về CPU và bộ nhớ trên mọi container, và đặt giới hạn (limit) bộ nhớ bằng đúng mức request. Độ tin cậy: 0.90
- Tránh đặt giới hạn trần CPU (CPU limits) trên các dịch vụ nhạy cảm với độ trễ; hãy dựa vào thông số requests và việc tính toán kích thước node để ngăn chặn tình trạng bóp băng thông xử lý (throttling). Độ tin cậy: 0.70
- Trang bị readiness probe cho mọi Deployment; chỉ thêm liveness probe khi ứng dụng thực sự có nguy cơ rơi vào trạng thái treo cứng (deadlock). Độ tin cậy: 0.85
- Sử dụng startup probe cho các ứng dụng khởi động chậm thay vì đặt giá trị initialDelaySeconds quá dài trên liveness probe. Độ tin cậy: 0.80
- Chạy ít nhất hai bản sao (replicas) đứng sau một PodDisruptionBudget đối với bất kỳ dịch vụ nào mà người dùng phụ thuộc vào. Độ tin cậy: 0.90
- Phân bổ đều các bản sao qua nhiều vùng khả dụng (zones) bằng cách sử dụng topologySpreadConstraints. Độ tin cậy: 0.80
- Ghim cố định các image bằng mã băm (digest) hoặc một thẻ phiên bản bất biến (immutable version tag), tuyệt đối không bao giờ dùng thẻ latest. Độ tin cậy: 0.95
- Chạy các container dưới quyền người dùng không phải root (non-root) với hệ thống tệp gốc chỉ đọc (read-only root filesystem) và loại bỏ toàn bộ các quyền capabilities. Độ tin cậy: 0.90
- Thực thi tiêu chuẩn bảo mật Pod mức hạn chế (restricted Pod Security Standard) trên các namespace chứa ứng dụng. Độ tin cậy: 0.80
- Khởi đầu mọi namespace bằng một NetworkPolicy mặc định chặn toàn bộ (default-deny) và chỉ mở đúng những luồng kết nối mà bạn thực sự cần. Độ tin cậy: 0.80
- Cấp cho mỗi workload một ServiceAccount riêng biệt và tắt tính năng tự động gắn kết token (automount) khi workload đó không bao giờ gọi tới API server. Độ tin cậy: 0.85
- Giữ các thông tin bí mật (secrets) nằm ngoài Git; đồng bộ chúng từ trình quản lý bí mật bằng External Secrets hoặc sử dụng Sealed Secrets. Độ tin cậy: 0.90
- Sử dụng một namespace cho mỗi nhóm (team) hoặc mỗi ứng dụng, đi kèm với ResourceQuota và LimitRange. Độ tin cậy: 0.80
- Áp dụng bộ nhãn tiêu chuẩn app.kubernetes.io cho mọi tài nguyên. Độ tin cậy: 0.75
- Xử lý tín hiệu SIGTERM và thêm một khoảng chờ ngắn (sleep) trong preStop để các yêu cầu đang xử lý dở (in-flight requests) hoàn tất trước khi tắt hẳn. Độ tin cậy: 0.85
- Mở rộng quy mô (scale) các dịch vụ không trạng thái (stateless) bằng HorizontalPodAutoscaler dựa trên mức sử dụng CPU hoặc chỉ số tốc độ yêu cầu thực tế. Độ tin cậy: 0.75
- Chạy cơ sở dữ liệu trên dịch vụ đám mây được quản lý (managed cloud service) thay vì dùng StatefulSets trừ khi có lý do thực sự thuyết phục. Độ tin cậy: 0.80
- Xác thực các tệp manifest trong quy trình CI bằng kubeconform và một công cụ kiểm tra chính sách như Kyverno hoặc OPA Gatekeeper. Độ tin cậy: 0.80
- Duy trì phiên bản của các cụm (clusters) không tụt hậu quá hai phiên bản phụ (minor versions) so với bản phát hành Kubernetes mới nhất và nâng cấp theo lịch trình định kỳ. Độ tin cậy: 0.75
- Phơi bày (expose) các dịch vụ HTTP thông qua một bộ điều khiển ingress dùng chung hoặc Gateway API controller, thay vì tạo một LoadBalancer riêng cho từng dịch vụ. Độ tin cậy: 0.75

# Gu xử lý lỗi của một kỹ sư backend TypeScript
- Báo lỗi sớm ngay tại ranh giới hệ thống (fail fast at the edges): xác thực mọi dữ liệu đầu vào từ bên ngoài bằng thư viện schema như Zod trước khi dữ liệu chạm tới tầng logic nghiệp vụ. Độ tin cậy: 0.90
- Tách biệt rõ các lỗi miền nghiệp vụ đã lường trước (không tìm thấy, xung đột, lỗi xác thực dữ liệu) với các lỗi hệ thống (bugs) bất ngờ, và xử lý chúng theo cách khác nhau. Độ tin cậy: 0.90
- Mô hình hóa các lỗi thất bại có thể dự đoán trước dưới dạng giá trị trả về hoặc kiểu dữ liệu Result; chỉ dành lệnh throw cho những trường hợp ngoại lệ thực sự bất thường. Độ tin cậy: 0.70
- Định nghĩa một tập hợp nhỏ các lớp lỗi có kiểu dữ liệu rõ ràng (typed error classes) kèm theo một trường mã lỗi (code) ổn định để máy có thể đọc hiểu. Độ tin cậy: 0.85
- Không bao giờ nuốt lỗi trong im lặng; một khối catch trống bắt buộc phải có dòng chú thích giải thích lý do tại sao. Độ tin cậy: 0.95
- Khi ném lại lỗi (rethrowing), hãy bọc lỗi gốc bằng tùy chọn cause để giữ nguyên chuỗi ngăn xếp lệnh gọi (stack chain). Độ tin cậy: 0.85
- Chỉ bắt (catch) lỗi tại nơi bạn có thể bổ sung thêm ngữ cảnh, khôi phục trạng thái hoặc chuyển đổi lỗi đó; hãy để mọi lỗi khác tự nổi lên tầng trên (bubble up). Độ tin cậy: 0.85
- Ánh xạ các lỗi thành phản hồi HTTP tại một bộ xử lý lỗi tập trung duy nhất, thay vì xử lý rải rác bên trong từng route. Độ tin cậy: 0.90
- Trả về phần thân phản hồi theo chuẩn RFC 9457 problem+json gồm mã lỗi (code), thông điệp dành cho người dùng và mã định danh yêu cầu (request id). Độ tin cậy: 0.75
- Tuyệt đối không làm rò rỉ dấu vết ngăn xếp (stack traces), câu lệnh SQL hoặc tên máy chủ nội bộ cho các API client. Độ tin cậy: 0.95
- Chỉ ghi log mỗi lỗi một lần duy nhất tại ranh giới nơi xử lý lỗi đó, không ghi log lặp lại ở mọi tầng mà lỗi đi qua. Độ tin cậy: 0.85
- Đưa ngữ cảnh có cấu trúc vào nhật ký lỗi (request id, user id, tên thao tác), tuyệt đối không bao giờ ghi kèm các khóa bí mật (secrets) hay token. Độ tin cậy: 0.90
- Chỉ thực hiện thử lại (retry) đối với các thao tác có tính bất biến (idempotent), sử dụng exponential backoff, jitter và có giới hạn cứng về số lần thử. Độ tin cậy: 0.90
- Đặt thời gian chờ (timeout) cho mọi lệnh gọi mạng; một lệnh gọi thiếu timeout chính là một lỗi (bug). Độ tin cậy: 0.95
- Sử dụng AbortController để hủy bỏ các tác vụ phía hạ nguồn (downstream) khi bên gọi đã ngắt kết nối. Độ tin cậy: 0.75
- Bọc các dịch vụ phụ thuộc chập chờn bên trong một bộ ngắt mạch (circuit breaker) để một dịch vụ chậm không thể kéo sập toàn bộ ứng dụng. Độ tin cậy: 0.70
- Coi các lỗi từ chối promise chưa được xử lý (unhandled promise rejections) là lỗi nghiêm trọng làm dừng chương trình (fatal): ghi log chúng và để tiến trình khởi động lại. Độ tin cậy: 0.85
- Để trình giám sát tiến trình (supervisor) khởi động lại một tiến trình bị sập thay vì cố gắng duy trì hoạt động của một tiến trình đã rơi vào trạng thái hỏng. Độ tin cậy: 0.80
- Báo cáo các lỗi bất ngờ tới công cụ theo dõi lỗi (error tracker) kèm theo nhãn phiên bản phát hành (release) và môi trường (environment). Độ tin cậy: 0.85
- Viết kiểm thử (test) cho cả các luồng thất bại chứ không chỉ riêng luồng thành công (happy path). Độ tin cậy: 0.85
- Viết thông báo lỗi nêu rõ cái gì đã thất bại, với dữ liệu đầu vào nào, và bên gọi có thể làm gì tiếp theo. Độ tin cậy: 0.85
- Sử dụng kiểu dữ liệu never trong các câu lệnh switch vét cạn (exhaustive switch) để các mã lỗi mới làm quá trình biên dịch (build) báo lỗi ngay cho đến khi được xử lý đầy đủ. Độ tin cậy: 0.75

# Gu bảo mật web của một lập trình viên full-stack
- Sử dụng cơ chế xác thực có sẵn của framework hoặc một thư viện đã được kiểm chứng kỹ lưỡng; không bao giờ tự viết thủ công phần lưu trữ mật khẩu hay quản lý phiên đăng nhập (session). Độ tin cậy: 0.95
- Băm (hash) mật khẩu bằng Argon2id hoặc bcrypt với hệ số chi phí tính toán (work factor) hợp lý. Độ tin cậy: 0.95
- Lưu trữ phiên làm việc (session) trong cookie có bật cờ HttpOnly, Secure, SameSite=Lax thay vì lưu trong localStorage. Độ tin cậy: 0.90
- Xoay vòng (đổi mới) mã định danh phiên (session id) khi đăng nhập và khi có sự thay đổi về quyền hạn. Độ tin cậy: 0.85
- Cung cấp passkey hoặc TOTP làm yếu tố xác thực thứ hai, và bắt buộc áp dụng đối với các tài khoản quản trị viên (admin). Độ tin cậy: 0.85
- Kiểm tra phân quyền (authorization) ở phía máy chủ cho mọi yêu cầu (request), bao gồm cả việc kiểm tra trên các mã định danh đối tượng (object ids), để ngăn chặn lỗ hổng IDOR. Độ tin cậy: 0.95
- Mặc định từ chối (Deny by default): các route mới tạo đều ở trạng thái riêng tư cho đến khi có người chủ động cấu hình công khai chúng. Độ tin cậy: 0.85
- Sử dụng truy vấn tham số hóa (parameterized queries) hoặc ORM ở mọi nơi; không bao giờ tạo câu lệnh SQL bằng cách nối chuỗi. Độ tin cậy: 0.95
- Dựa vào cơ chế tự động escape của template engine và coi mọi cơ chế chèn HTML thô (raw HTML) là một cờ cảnh báo cần rà soát kỹ khi duyệt mã nguồn. Độ tin cậy: 0.90
- Triển khai chính sách Content Security Policy (CSP) nghiêm ngặt sử dụng mã nonce, bắt đầu ở chế độ chỉ báo cáo (report-only mode). Độ tin cậy: 0.80
- Gửi kèm các header HSTS, X-Content-Type-Options: nosniff và frame-ancestors trên mọi phản hồi (response). Độ tin cậy: 0.85
- Bảo vệ các yêu cầu làm thay đổi trạng thái bằng cookie SameSite kết hợp với CSRF token hoặc kiểm tra nguồn gốc (origin check). Độ tin cậy: 0.85
- Giới hạn tần suất gọi (rate-limit) đối với các điểm cuối (endpoints) đăng nhập, đăng ký, đặt lại mật khẩu và các điểm cuối tốn nhiều tài nguyên khác. Độ tin cậy: 0.90
- Trả về cùng một thông báo giống nhau cho cả trường hợp email không tồn tại và trường hợp sai mật khẩu để tránh lỗ hổng dò tìm tài khoản (account enumeration). Độ tin cậy: 0.80
- Xác thực các tệp tải lên theo loại nội dung (content type) và kích thước, lưu trữ chúng bên ngoài thư mục gốc của web (web root), và phục vụ chúng từ một tên miền riêng biệt. Độ tin cậy: 0.80
- Chặn các yêu cầu từ phía máy chủ gọi tới các dải IP nội bộ và IP metadata để ngăn chặn lỗ hổng SSRF. Độ tin cậy: 0.80
- Lưu giữ các thông tin bí mật (secrets) trong trình quản lý bí mật (secret manager) hoặc biến môi trường, tuyệt đối không lưu trong kho mã nguồn (repo) hay gói mã phía client (client bundle). Độ tin cậy: 0.95
- Chạy kiểm toán gói phụ thuộc (dependency audits) và tự động tạo PR cập nhật (Dependabot hoặc Renovate) trên mọi kho mã nguồn. Độ tin cậy: 0.85
- Ghi nhật ký (log) các sự kiện bảo mật như đăng nhập thành công, đăng nhập thất bại và thay đổi quyền hạn, nhưng tuyệt đối không ghi thông tin xác thực (credentials) vào log. Độ tin cậy: 0.85
- Cấu hình CORS với danh sách cho phép (allowlist) gồm các origin tường minh; không bao giờ phản chiếu nguyên xi origin của yêu cầu đi kèm với thông tin xác thực (credentials). Độ tin cậy: 0.90
- Sử dụng các API token có thời hạn ngắn, phạm vi quyền hạn hẹp và có khả năng thu hồi (revocable). Độ tin cậy: 0.85
- Thực hiện kiểm tra nhanh theo danh sách OWASP Top 10 trong quá trình duyệt mã (code review) cho mọi tính năng liên quan đến xác thực, dữ liệu đầu vào hoặc xử lý tệp tin. Độ tin cậy: 0.75

# Phong cách (taste) sử dụng PostgreSQL của một kỹ sư Backend
- Sử dụng cột định danh kiểu bigint (GENERATED ALWAYS AS IDENTITY) cho khóa chính (primary key); chỉ dùng đến UUIDv7 khi định danh (id) bắt buộc phải được tạo bên ngoài cơ sở dữ liệu. Độ tin cậy: 0.80
- Lưu trữ dấu thời gian dưới dạng timestamptz theo múi giờ UTC, tuyệt đối không dùng timestamp without time zone. Độ tin cậy: 0.95
- Sử dụng kiểu text kết hợp với ràng buộc CHECK thay vì varchar(n) để giới hạn độ dài chuỗi. Độ tin cậy: 0.80
- Lưu trữ tiền tệ dưới dạng kiểu numeric hoặc kiểu số nguyên tính theo đơn vị tiền tệ nhỏ nhất (minor units), tuyệt đối không dùng kiểu số thực dấu phẩy động (float). Độ tin cậy: 0.95
- Đặt tên bảng ở dạng số nhiều theo quy tắc snake_case và đặt tên khóa ngoại (foreign key) theo định dạng <singular>_id. Độ tin cậy: 0.70
- Khai báo NOT NULL theo mặc định và chỉ cho phép NULL khi "chưa xác định" (unknown) là một trạng thái thực tế có thật. Độ tin cậy: 0.85
- Thực thi các quy tắc bất biến (invariants) ngay trong cơ sở dữ liệu bằng khóa ngoại (foreign keys), ràng buộc UNIQUE và CHECK, chứ không chỉ kiểm tra trong mã nguồn ứng dụng. Độ tin cậy: 0.90
- Đánh chỉ mục (index) cho mọi cột khóa ngoại được sử dụng trong các phép nối (join) hoặc xóa dây chuyền (cascading delete). Độ tin cậy: 0.85
- Đọc kết quả EXPLAIN (ANALYZE, BUFFERS) trước khi thêm một chỉ mục, và đọc lại lần nữa sau khi thêm để chứng minh rằng chỉ mục đó thực sự mang lại hiệu quả. Độ tin cậy: 0.90
- Ưu tiên chỉ mục từng phần (partial index) và chỉ mục biểu thức (expression index) hơn là các chỉ mục phức hợp (composite index) trải rộng đối với các bộ lọc có phân phối dữ liệu lệch (skewed filters). Độ tin cậy: 0.70
- Tạo chỉ mục trên các bảng lớn bằng câu lệnh CREATE INDEX CONCURRENTLY. Độ tin cậy: 0.90
- Sử dụng kiểu jsonb cho các thuộc tính thực sự không có lược đồ cố định (schemaless), nhưng hãy tách các trường mà bạn thường xuyên lọc ra thành những cột thực thụ. Độ tin cậy: 0.80
- Phân trang bằng phương pháp tập khóa keyset (WHERE id > $last ORDER BY id LIMIT n) thay vì dùng giá trị OFFSET lớn. Độ tin cậy: 0.85
- Giữ các giao dịch (transactions) diễn ra ngắn gọn và tuyệt đối không giữ một giao dịch mở trong suốt quá trình gọi mạng (network call). Độ tin cậy: 0.90
- Thiết lập tham số statement_timeout và idle_in_transaction_session_timeout cho từng vai trò (role) của ứng dụng. Độ tin cậy: 0.85
- Đặt một bộ điều phối kết nối (connection pooler) chẳng hạn như PgBouncer ở chế độ giao dịch (transaction mode) đứng trước cơ sở dữ liệu. Độ tin cậy: 0.80
- Sử dụng cú pháp SELECT ... FOR UPDATE SKIP LOCKED cho các hàng đợi công việc (job queues) đơn giản trước khi quyết định thêm một hệ thống message broker riêng biệt. Độ tin cậy: 0.70
- Sử dụng cú pháp INSERT ... ON CONFLICT cho các thao tác thêm mới hoặc cập nhật (upsert) có tính lũy đẳng (idempotent). Độ tin cậy: 0.85
- Cấp cho mỗi dịch vụ một vai trò (role) riêng với đặc quyền tối thiểu (least privilege); ứng dụng tuyệt đối không bao giờ kết nối dưới quyền siêu người dùng (superuser). Độ tin cậy: 0.90
- Bật tiện ích mở rộng pg_stat_statements và rà soát các truy vấn chậm nhất mỗi tuần. Độ tin cậy: 0.85
- Viết các biểu thức bảng chung (CTEs) để mã dễ đọc hơn, với lưu ý rằng Postgres 12+ sẽ tự động nội tuyến (inline) chúng trừ khi bạn thêm từ khóa MATERIALIZED. Độ tin cậy: 0.65
- Kiểm thử khả năng khôi phục tại một thời điểm (point-in-time recovery) từ các bản sao lưu một cách định kỳ; một bản sao lưu chưa từng được kiểm thử coi như không có giá trị. Độ tin cậy: 0.95

# Phong cách (taste) tối ưu hiệu năng Web của một kỹ sư Frontend
- Đo lường các chỉ số Core Web Vitals (LCP, INP, CLS) từ người dùng thực tế, chứ không chỉ dựa vào các lần chạy Lighthouse trong môi trường thử nghiệm (lab). Độ tin cậy: 0.90
- Thiết lập ngân sách hiệu năng (performance budget) cho dung lượng JavaScript và chỉ số LCP, đồng thời cho dừng lỗi CI khi có thay đổi vượt quá giới hạn đó. Độ tin cậy: 0.80
- Kết xuất (render) khung nhìn đầu tiên trên máy chủ hoặc dưới dạng tĩnh; không phân phối một trang trắng phải chờ tải xong JavaScript. Độ tin cậy: 0.90
- Giảm lượng mã JavaScript gửi đi trước khi tối ưu hóa số JavaScript mà bạn gửi. Độ tin cậy: 0.90
- Chia nhỏ mã (code splitting) theo từng tuyến đường (route) và tải trễ (lazy-load) các thành phần nặng như trình soạn thảo, biểu đồ và bản đồ. Độ tin cậy: 0.85
- Kiểm tra bằng công cụ phân tích gói mã (bundle analyzer) trước khi thêm một thư viện phụ thuộc, và ưu tiên các thư viện nhỏ gọn, hỗ trợ loại bỏ mã thừa (tree-shakable). Độ tin cậy: 0.80
- Phân phối hình ảnh ở định dạng AVIF hoặc WebP với thuộc tính srcset đáp ứng (responsive) cùng chiều rộng (width) và chiều cao (height) tường minh. Độ tin cậy: 0.90
- Đánh dấu hình ảnh LCP bằng thuộc tính fetchpriority="high" và tuyệt đối không tải trễ (lazy-load) nó. Độ tin cậy: 0.85
- Tải trễ các hình ảnh và thẻ iframe nằm bên dưới màn hình đầu tiên (below-the-fold) bằng thuộc tính loading="lazy". Độ tin cậy: 0.85
- Tự lưu trữ (self-host) phông chữ, rút gọn bộ ký tự (subset), tải trước (preload) phông chữ chính và sử dụng thuộc tính font-display: swap. Độ tin cậy: 0.80
- Dành sẵn không gian trống cho quảng cáo, nội dung nhúng và nội dung tải muộn để bố cục trang không bị xê dịch. Độ tin cậy: 0.85
- Chia nhỏ các tác vụ kéo dài trên 50 ms và nhường quyền xử lý lại cho luồng chính (main thread) để giữ chỉ số INP ở mức thấp. Độ tin cậy: 0.80
- Tải các tập lệnh của bên thứ ba bằng thuộc tính defer hoặc sau khi có tương tác của người dùng, đồng thời kiểm tra giá trị thực sự của từng tập lệnh. Độ tin cậy: 0.85
- Lưu bộ nhớ đệm (cache) cho các tài sản tĩnh đã gắn mã băm (hashed) với tiêu đề Cache-Control: immutable trong thời hạn một năm. Độ tin cậy: 0.90
- Phân phối mọi tài nguyên qua giao thức HTTP/2 hoặc HTTP/3 từ mạng phân phối nội dung (CDN) có bật nén Brotli. Độ tin cậy: 0.85
- Chỉ khởi tạo kết nối trước (preconnect) tới một hoặc hai nguồn (origin) thực sự cần thiết cho lần kết xuất đầu tiên. Độ tin cậy: 0.70
- Nhúng trực tiếp (inline) phần CSS quan trọng (critical CSS) cho khung nhìn đầu tiên và tải phần còn lại mà không chặn quá trình kết xuất. Độ tin cậy: 0.65
- Ảo hóa (virtualize) các danh sách dài thay vì kết xuất hàng nghìn nút DOM cùng lúc. Độ tin cậy: 0.80
- Chỉ tạo hoạt ảnh (animate) trên hai thuộc tính transform và opacity, đồng thời tôn trọng tùy chọn prefers-reduced-motion của người dùng. Độ tin cậy: 0.85
- Tránh gây tính toán lại bố cục liên tục (layout thrashing): gom nhóm các thao tác đọc DOM trước khi thực hiện các thao tác ghi DOM. Độ tin cậy: 0.75
- Kiểm thử trên điện thoại Android tầm trung với mạng bị bóp băng thông (throttled), chứ không chỉ thử nghiệm trên máy tính xách tay của lập trình viên. Độ tin cậy: 0.90
- Xem sự suy giảm hiệu năng (performance regression) giống như một lỗi phần mềm (bug), cần có người chịu trách nhiệm và ngày ấn định khắc phục. Độ tin cậy: 0.80

# Phong cách (taste) viết kịch bản Shell của một kỹ sư DevOps
- Bắt đầu mọi kịch bản với #!/usr/bin/env bash và set -euo pipefail. Độ tin cậy: 0.90
- Chuyển sang sử dụng Python hoặc Go một khi kịch bản vượt quá khoảng 100 dòng hoặc cần đến các cấu trúc dữ liệu thực thụ. Độ tin cậy: 0.85
- Chạy ShellCheck trong CI và sửa các cảnh báo thay vì tắt chúng đi. Độ tin cậy: 0.95
- Định dạng kịch bản bằng shfmt để các bản so sánh thay đổi (diff) luôn nhỏ gọn. Độ tin cậy: 0.75
- Đặt mọi biến khi khai triển trong dấu ngoặc kép ("$var") trừ khi việc tách từ (word splitting) là có chủ đích và đã được chú thích rõ. Độ tin cậy: 0.95
- Sử dụng [[ ]] cho các phép kiểm tra điều kiện và $(...) để thay thế lệnh, tuyệt đối không dùng dấu huyền (` `). Độ tin cậy: 0.90
- Khai báo các biến bên trong hàm bằng từ khóa local. Độ tin cậy: 0.85
- Đặt phần xử lý logic vào trong các hàm và gọi hàm main "$@" ở cuối tệp. Độ tin cậy: 0.80
- Dọn dẹp các tệp tạm bằng mktemp và bẫy sự kiện trap '...' EXIT. Độ tin cậy: 0.90
- Ghi các lỗi và nhật ký (log) ra luồng stderr và giữ luồng stdout dành riêng cho dữ liệu để các công cụ khác có thể nối ống (pipe). Độ tin cậy: 0.85
- Thoát chương trình với mã trạng thái khác không (non-zero) cùng thông báo rõ ràng khi có lỗi xảy ra. Độ tin cậy: 0.90
- Cung cấp hàm hướng dẫn sử dụng (usage) và xử lý các cờ -h cũng như --help. Độ tin cậy: 0.80
- Phân tích cú pháp các tùy chọn bằng getopts hoặc vòng lặp case đơn giản, không kiểm tra tham số vị trí một cách tùy tiện. Độ tin cậy: 0.75
- Kiểm tra trước các lệnh bắt buộc phải có bằng command -v và báo lỗi dừng sớm ngay khi thiếu một lệnh. Độ tin cậy: 0.85
- Đọc cấu hình từ các biến môi trường kèm theo giá trị mặc định, chẳng hạn như -8080. Độ tin cậy: 0.80
- Không bao giờ phân tích cú pháp (parse) đầu ra của lệnh ls; hãy dùng mẫu glob hoặc find -print0 kết hợp với xargs -0. Độ tin cậy: 0.90
- Đọc tệp từng dòng một bằng cú pháp while IFS= read -r line. Độ tin cậy: 0.85
- Sử dụng mảng (array) cho danh sách đối số thay vì ghép nối các chuỗi lệnh. Độ tin cậy: 0.85
- Tránh sử dụng eval, và tuyệt đối không truyền dữ liệu đầu vào không đáng tin cậy vào đó. Độ tin cậy: 0.95
- Thiết kế các kịch bản có tính lũy đẳng (idempotent) để việc chạy chúng hai lần vẫn đảm bảo an toàn. Độ tin cậy: 0.85
- Thêm cờ --dry-run vào bất kỳ tác vụ nào thực hiện xóa hoặc thay đổi trạng thái từ xa. Độ tin cậy: 0.80
- Chỉ bó buộc trong chuẩn POSIX sh khi kịch bản bắt buộc phải chạy trong các container tối giản; còn lại hãy nhắm tới mục tiêu bash 4+. Độ tin cậy: 0.70

Sao chép (clone) phần tai thỏ LaunchMe từ A–Z với hình ảnh và hành vi chính xác đến từng pixel. Trước tiên, hãy liệt kê và lập bản đồ toàn bộ các công cụ MCP `rea` và `hopper`, sau đó dịch ngược (reverse-engineer) hoàn toàn bản gốc: hình học, giao diện người dùng (UI), các trạng thái, tương tác, hoạt ảnh, cài đặt, diện mạo và các trường hợp biên (edge cases). Đo đạc mọi thứ; tuyệt đối không đoán mò. Tạo tệp SPEC.md kèm theo bằng chứng trước khi viết mã. Chờ sự phê duyệt của tôi, sau đó mới triển khai. Cuối cùng, thực hiện đối chiếu sự khác biệt (diffing) về mặt thị giác/hành vi giữa bản gốc và bản sao, sửa mọi điểm chưa khớp, chạy toàn bộ các bài kiểm thử và báo cáo bất kỳ trở ngại nào.

# Gu thiết kế API GraphQL của một kỹ sư nền tảng (platform engineer)
- Thiết kế lược đồ (schema) xoay quanh các ca sử dụng (use cases) của phía client và ngôn ngữ nghiệp vụ (domain language), chứ không xoay quanh các bảng cơ sở dữ liệu. Độ tin cậy: 0.90
- Tự động sinh kiểu dữ liệu (types) cho cả phía server và client từ schema (sử dụng GraphQL Code Generator hoặc công cụ tương đương); không bao giờ tự viết tay các kiểu dữ liệu phản hồi. Độ tin cậy: 0.90
- Chỉ đặt các trường (fields) là non-null theo mặc định khi server luôn có thể phân giải (resolve) được chúng; giữ cho các trường phụ thuộc vào dịch vụ khác ở trạng thái có thể null (nullable) để một lỗi đơn lẻ không làm mất trắng toàn bộ phản hồi. Độ tin cậy: 0.80
- Sử dụng một đối tượng đầu vào duy nhất cho mỗi thao tác biến đổi dữ liệu (mutation) (ví dụ: createOrder(input: CreateOrderInput!)) và trả về một kiểu payload chuyên biệt, không trả về trực tiếp thực thể gốc (bare entity). Độ tin cậy: 0.85
- Trả về các lỗi nghiệp vụ dự kiến dưới dạng các thành phần kiểu hợp (typed union members) trong payload (ví dụ: OrderCreated | InsufficientStock); dành riêng mảng errors ở cấp cao nhất cho các lỗi hệ thống bất ngờ. Độ tin cậy: 0.75
- Phân trang danh sách bằng kết nối con trỏ theo phong cách Relay (edges, node, pageInfo) và giới hạn tham số first/last ở một mức tối đa hợp lý. Độ tin cậy: 0.80
- Gom nhóm (batch) và lưu đệm việc tải dữ liệu theo từng yêu cầu bằng DataLoader để triệt tiêu hoàn toàn vấn đề truy vấn N+1. Độ tin cậy: 0.95
- Áp dụng giới hạn độ sâu (depth) và độ phức tạp (complexity) của truy vấn ngay tại cổng giao tiếp (gateway). Độ tin cậy: 0.90
- Sử dụng truy vấn cố định (persisted queries - danh sách cho phép các mã băm thao tác) cho các ứng dụng client nội bộ (first-party) trên môi trường production. Độ tin cậy: 0.80
- Tắt tính năng tự tra cứu lược đồ (introspection) trên các điểm cuối (endpoints) production công khai trừ khi API đó thực sự được thiết kế để công khai cho bên thứ ba. Độ tin cậy: 0.70
- Phát triển mở rộng schema theo hướng bổ sung thêm (additively) và đánh dấu các trường cũ bằng chỉ thị @deprecated(reason: ...); không bao giờ phân tách phiên bản endpoint bằng đường dẫn như /v2. Độ tin cậy: 0.90
- Chỉ xóa bỏ một trường đã đánh dấu @deprecated sau khi số liệu đo lường mức sử dụng trường đó cho thấy không còn lưu lượng truy cập nào trong suốt một chu kỳ phát hành đầy đủ. Độ tin cậy: 0.85
- Chạy kiểm tra so sánh sự khác biệt của schema (schema diff) trong quy trình CI và cho dừng quá trình build nếu phát hiện các thay đổi gây phá vỡ tương thích (breaking changes). Độ tin cậy: 0.90
- Sử dụng các định danh ẩn (opaque IDs) duy nhất trên toàn cục và triển khai giao diện Node để hỗ trợ truy xuất lại dữ liệu (refetching). Độ tin cậy: 0.70
- Giữ cho các hàm phân giải (resolvers) thật mỏng gọn: chúng chỉ gọi các dịch vụ miền nghiệp vụ (domain services), và việc phân quyền (authorization) phải nằm ở tầng dịch vụ đó chứ không nằm trong các câu lệnh if của resolver. Độ tin cậy: 0.85
- Đặt tên rõ ràng cho mọi thao tác (operations) trong từng truy vấn của client để dữ liệu truy vết (traces), nhật ký (logs) và số liệu đo lường (metrics) dễ đọc hiểu. Độ tin cậy: 0.90
- Đặt các mảnh truy vấn (fragments) nằm cùng chỗ với chính các thành phần giao diện (UI components) sử dụng chúng. Độ tin cậy: 0.80
- Ưu tiên các kiểu vô hướng tùy chỉnh (custom scalars như DateTime, URL, Email) có kiểm tra tính hợp lệ hơn là dùng kiểu String thuần túy. Độ tin cậy: 0.75
- Chỉ sử dụng cơ chế đăng ký nhận dữ liệu (subscriptions) cho dữ liệu thời gian thực thực sự; cơ chế hỏi vòng định kỳ (polling) là hoàn toàn ổn đối với bất kỳ dữ liệu nào chỉ thay đổi sau mỗi vài phút. Độ tin cậy: 0.70
- Chỉ sử dụng kiến trúc liên hợp (federation) khi có nhiều nhóm khác nhau cùng sở hữu các đồ thị con (subgraphs) riêng biệt; một nhóm duy nhất thì chỉ nên dùng một schema duy nhất. Độ tin cậy: 0.75
- Truy vết mọi resolver bằng OpenTelemetry và thiết lập cảnh báo cho các trường xử lý chậm, chứ không chỉ cảnh báo các yêu cầu (requests) chậm nói chung. Độ tin cậy: 0.80
- Viết tài liệu cho mọi kiểu dữ liệu và mọi trường bằng phần mô tả trực tiếp trong schema; bản thân schema chính là tài liệu tham chiếu API. Độ tin cậy: 0.85

# Gu thiết kế Bộ nhớ đệm Redis (Redis Caching) của một kỹ sư backend
- Mặc định sử dụng mô hình cache-aside: đọc từ Redis, truy xuất lại từ nguồn dữ liệu gốc (source of truth) khi không tìm thấy trong cache (cache miss), sau đó nạp dữ liệu vào cache. Độ tin cậy: 0.90
- Coi bộ nhớ đệm là dữ liệu có thể loại bỏ bất cứ lúc nào; hệ thống vẫn phải hoạt động chính xác (chỉ chậm hơn) nếu toàn bộ dữ liệu Redis bị xóa sạch (flushed). Độ tin cậy: 0.95
- Thiết lập thời gian hết hạn (TTL) trên mọi khóa cache; một khóa không có thời hạn sử dụng chính là mầm mống gây rò rỉ bộ nhớ (memory leak). Độ tin cậy: 0.90
- Thêm độ lệch ngẫu nhiên (random jitter) vào các giá trị TTL để các khóa được ghi cùng lúc không bị hết hạn đồng loạt. Độ tin cậy: 0.85
- Đặt không gian tên (namespace) cho khóa theo định dạng service:entity:id:version (ví dụ: catalog:product:42:v3) và tăng số phiên bản khi có thay đổi định dạng gây phá vỡ tương thích. Độ tin cậy: 0.85
- Vô hiệu hóa cache bằng cách xóa khóa sau khi ghi dữ liệu thành công, thay vì cập nhật trực tiếp giá trị đang lưu trong cache. Độ tin cậy: 0.80
- Bảo vệ các khóa có tần suất truy cập cao (hot keys) khỏi hiện tượng quá tải đột ngột (cache stampede) bằng khóa ngắn hạn (SET key value NX PX) hoặc gộp nhóm yêu cầu (request coalescing). Độ tin cậy: 0.80
- Lưu vào cache cả các kết quả rỗng (không tìm thấy) với TTL ngắn để giảm tải các truy vấn lặp lại cho những ID không tồn tại. Độ tin cậy: 0.70
- Lưu trữ các giá trị đã tuần tự hóa (serialized) nhỏ gọn (dùng JSON để dễ gỡ lỗi, dùng MessagePack khi kích thước là yếu tố quan trọng) và giữ kích thước giá trị dưới khoảng 100 KB. Độ tin cậy: 0.75
- Sử dụng kiểu dữ liệu hash cho các đối tượng có từng trường (fields) được đọc riêng lẻ, và dùng chuỗi đơn thuần (plain strings) cho các giá trị được đọc nguyên khối. Độ tin cậy: 0.70
- Không bao giờ chạy lệnh KEYS trên môi trường thực tế (production); hãy sử dụng lệnh SCAN với con trỏ (cursor). Độ tin cậy: 0.95
- Tránh tạo các khóa quá lớn (big keys) và các tập hợp khổng lồ; hãy tách nhỏ bất kỳ dữ liệu nào có thể khiến một lệnh đơn lẻ bị chặn (block) tới vài mili-giây. Độ tin cậy: 0.85
- Sử dụng kỹ thuật pipelining hoặc lệnh MGET để đọc theo lô (batch reads) thay vì gửi từng yêu cầu mạng riêng biệt cho mỗi khóa. Độ tin cậy: 0.85
- Đưa các logic nguyên tử (atomic) gồm nhiều bước vào một kịch bản Lua (Lua script) hoặc một hàm, chứ không thực hiện kiểm tra rồi mới gán giá trị (check-then-set) ở phía client. Độ tin cậy: 0.80
- Thiết lập maxmemory kèm theo chính sách trục xuất dữ liệu (eviction policy) rõ ràng (allkeys-lru cho bộ nhớ đệm thuần túy, noeviction cho dữ liệu tuyệt đối không được mất). Độ tin cậy: 0.90
- Tách biệt bộ nhớ đệm và dữ liệu bền vững (hàng đợi, giới hạn tốc độ, phiên đăng nhập) vào các phiên bản (instances) Redis riêng với các chính sách riêng. Độ tin cậy: 0.80
- Sử dụng Redis Streams hoặc một hệ thống message broker thực thụ cho các tác vụ nền (jobs); kiểu danh sách (lists) đơn thuần sẽ làm mất tác vụ khi tiến trình xử lý (consumer) bị sập. Độ tin cậy: 0.70
- Triển khai giới hạn tần suất (rate limiting) bằng kịch bản cửa sổ trượt (sliding window) hoặc xô thẻ bài (token bucket), không dùng cách kết hợp lệnh INCR và EXPIRE tạm bợ dễ gây lỗi tranh chấp (race conditions). Độ tin cậy: 0.75
- Thiết lập thời gian chờ (timeouts) ở phía client và bộ ngắt mạch (circuit breaker) để khi Redis bị chậm thì hệ thống chỉ chuyển sang trạng thái cache miss chứ không làm sập toàn bộ dịch vụ. Độ tin cậy: 0.90
- Giám sát tỷ lệ trúng cache (hit ratio), số lượng khóa bị trục xuất (evictions), độ phân mảnh bộ nhớ và độ trễ, đồng thời cảnh báo khi tỷ lệ trúng cache sụt giảm. Độ tin cậy: 0.85
- Bắt buộc xác thực (auth) và mã hóa TLS, vô hiệu hóa hoặc đổi tên các lệnh nguy hiểm (FLUSHALL, CONFIG), và tuyệt đối không phơi bày Redis trực tiếp ra ngoài internet. Độ tin cậy: 0.95
- Đừng đưa vào cache những gì vốn đã nhanh; hãy đo lường độ trễ của nguồn dữ liệu gốc trước khi thêm một lớp bộ nhớ đệm. Độ tin cậy: 0.80

# Gu thiết kế Khả năng Tiếp cận Web (Web Accessibility) của một kỹ sư frontend
- Ưu tiên sử dụng HTML ngữ nghĩa trước tiên (button, a, nav, main, label); chỉ thêm ARIA khi không có phần tử gốc nào phù hợp. Độ tin cậy: 0.95
- Không bao giờ gắn trình xử lý sự kiện click (click handlers) vào thẻ div hoặc span; nếu nó hoạt động như một nút bấm, nó phải là thẻ button. Độ tin cậy: 0.95
- Liên kết (links) dùng để điều hướng và nút bấm (buttons) dùng để thực hiện hành động; đừng tráo đổi chúng chỉ vì lý do tạo kiểu giao diện (styling). Độ tin cậy: 0.90
- Mọi trường nhập liệu trong biểu mẫu (form input) đều phải có nhãn (label) hiển thị rõ ràng và được liên kết về mặt lập trình; văn bản gợi ý (placeholders) không phải là nhãn. Độ tin cậy: 0.95
- Giữ một thẻ h1 duy nhất trên mỗi trang và không bao giờ nhảy cóc các cấp tiêu đề (heading levels) chỉ để chỉnh kích thước hiển thị; hãy tạo kiểu bằng CSS để thay thế. Độ tin cậy: 0.80
- Viết văn bản thay thế (alt text) mô tả đúng mục đích của hình ảnh, và sử dụng alt="" cho các hình ảnh thuần túy mang tính trang trí. Độ tin cậy: 0.90
- Giữ chỉ báo tiêu điểm (focus indicator) hiển thị rõ ràng trên mọi phần tử tương tác; sử dụng :focus-visible thay vì xóa bỏ đường viền (outlines). Độ tin cậy: 0.95
- Mọi tính năng phải hoạt động được khi chỉ dùng riêng bàn phím, theo thứ tự phím Tab hợp lý và không có bẫy bàn phím (keyboard traps). Độ tin cậy: 0.95
- Tránh các giá trị tabindex dương; hãy sửa lại thứ tự DOM để thay thế. Độ tin cậy: 0.90
- Đạt chuẩn độ tương phản WCAG AA: tỷ lệ 4.5:1 đối với văn bản nội dung và 3:1 đối với văn bản cỡ lớn cùng các thành phần giao diện người dùng (UI). Độ tin cậy: 0.90
- Không bao giờ truyền tải ý nghĩa chỉ bằng màu sắc đơn thuần; hãy kết hợp màu sắc với văn bản, biểu tượng hoặc họa tiết. Độ tin cậy: 0.90
- Sử dụng phần tử dialog gốc (hoặc một thư viện đã được kiểm thử kỹ lưỡng) cho các hộp thoại modal, giữ tiêu điểm (trap focus) bên trong khi đang mở và trả tiêu điểm về phần tử kích hoạt khi đóng lại. Độ tin cậy: 0.85
- Thông báo trạng thái bất đồng bộ và các lỗi bằng vùng aria-live hoặc role="alert", đồng thời di chuyển tiêu điểm đến phần tóm tắt lỗi sau khi gửi biểu mẫu thất bại. Độ tin cậy: 0.80
- Tôn trọng tùy chọn prefers-reduced-motion và tránh tự động phát các hiệu ứng chuyển động kéo dài quá năm giây. Độ tin cậy: 0.85
- Thiết kế các vùng chạm (touch targets) có kích thước tối thiểu 24x24 CSS pixel, lý tưởng nhất là 44x44. Độ tin cậy: 0.75
- Đặt kích thước chữ bằng đơn vị rem và đảm bảo bố cục vẫn hiển thị tốt khi phóng to 200% và ở chiều rộng 320px mà không bị cuộn ngang. Độ tin cậy: 0.85
- Thêm liên kết "Chuyển đến nội dung chính" (Skip to main content) làm phần tử có thể nhận tiêu điểm (focusable) đầu tiên. Độ tin cậy: 0.80
- Thiết lập thuộc tính lang trên thẻ html và trên bất kỳ đoạn văn bản nội dòng nào được viết bằng ngôn ngữ khác. Độ tin cậy: 0.85
- Chạy các bài kiểm tra axe hoặc Lighthouse trong quy trình CI, đồng thời hiểu rõ rằng chúng chỉ phát hiện được khoảng một phần ba số vấn đề. Độ tin cậy: 0.85
- Kiểm thử thủ công các luồng quan trọng bằng trình đọc màn hình (VoiceOver và NVDA) trước mỗi đợt phát hành lớn. Độ tin cậy: 0.80
- Kiểm tra lỗi mã nguồn JSX bằng eslint-plugin-jsx-a11y và coi các lỗi của nó là lỗi dừng quá trình build (build failures). Độ tin cậy: 0.75
- Ưu tiên các thành phần giao diện nguyên thủy hỗ trợ tiếp cận (Radix, React Aria) hơn là tự xây dựng các hộp chọn (comboboxes) và menu từ đầu. Độ tin cậy: 0.80

# ==========================================================
# Hướng Dẫn Vận Hành LLM Phổ Quát & Quy Tắc Karpathy
# ==========================================================
# PHIÊN BẢN: 1.2.0
# TÁC GIẢ: Scott Malin, CISSP
# CẬP NHẬT LẦN CUỐI: 2026-10-22
#
# GHI NHẬN NGUỒN GỐC:
# Chuyển thể từ các nguyên tắc gắn liền với những quan sát của
# Andrej Karpathy về lập trình có sự hỗ trợ của LLM và tham khảo
# từ kho mã nguồn mở multica-ai/andrej-karpathy-skills.
#
# Tài liệu này là một bản chuyển thể thực tiễn độc lập.
# Tài liệu không tuyên bố rằng mọi quy tắc hay cách diễn đạt đều
# bắt nguồn từ Andrej Karpathy.
#
# MỤC ĐÍCH:
# Thiết lập các quy tắc vận hành thực tế cho việc phát triển
# phần mềm có sự hỗ trợ của LLM. Giảm thiểu ảo giác, sự phức tạp
# không cần thiết, các chỉnh sửa mất kiểm soát, sự lệch hướng
# kiến trúc và những tuyên bố hoàn thành không có cơ sở.
#
# NGUYÊN TẮC THIẾT KẾ:
# Thực hiện thay đổi đúng đắn nhỏ nhất, giữ nguyên những gì đang
# hoạt động tốt, xác minh những gì có thể xác minh và báo cáo
# chính xác những gì thực sự đã diễn ra.
#
# NHẬT KÝ THAY ĐỔI (CHANGELOG):
# - v1.2.0 (2026-10-22):
#   - Đã thêm phần Tóm Tắt Điều Hành / Tham Chiếu Nhanh để tăng cường
#     mức độ tuân thủ prompt mật độ cao và phân tích ngữ cảnh nhanh chóng.
#
# - v1.1.0 (2026-10-22):
#   - Làm rõ thời điểm cần đặt câu hỏi so với việc tiếp tục thực hiện kèm theo các giả định rõ ràng.
#   - Định nghĩa sự đơn giản dựa trên việc loại bỏ độ phức tạp không cần thiết, chứ không đơn thuần là
#     tối thiểu hóa độ dài mã nguồn.
#   - Tăng cường phân tích nguyên nhân gốc rễ và các thay đổi chuẩn xác có trọng tâm (surgical changes).
#   - Đã thêm bước kiểm tra trước khi thay đổi và bảo vệ chống lỗi hồi quy (regression protection).
#   - Đã thêm các biện pháp kiểm soát phạm vi và quyền hạn rõ ràng.
#   - Tăng cường việc xác minh và báo cáo dựa trên bằng chứng.
#   - Tinh chỉnh việc xử lý lỗi để tương ứng với các rủi ro thực tế.
#   - Đã thêm hướng dẫn giải quyết xung đột cho các quy tắc cạnh tranh nhau.
#
# - v1.0.0 (2026-10-22):
#   - Bản phát hành đầu tiên kết hợp các nguyên tắc lấy cảm hứng từ Karpathy với các biện pháp
#     bảo vệ đa mô hình nhằm ngăn chặn ảo giác, chỉnh sửa mã nguồn có trọng tâm, bảo toàn
#     kiến trúc và xử lý lỗi rõ ràng.

# ==========================================================
# TÓM TẮT ĐIỀU HÀNH / THAM CHIẾU NHANH
# ==========================================================
# 1. SUY NGHĨ TRƯỚC KHI VIẾT CODE: Hiểu rõ yêu cầu và kiểm tra ngữ cảnh trước tiên.
# 2. ƯU TIÊN SỰ ĐƠN GIẢN: Giải quyết vấn đề một cách đơn giản, không cồng kềnh hay thiết kế quá mức (over-engineering).
# 3. THAY ĐỔI CÓ TRỌNG TÂM: Thực hiện các chỉnh sửa tối thiểu, đúng mục tiêu; không bao giờ xóa bỏ mã nguồn đang nguyên vẹn.
# 4. THỰC THI HƯỚNG MỤC TIÊU: Xác minh kết quả bằng bằng chứng thực tế, không dựa trên giả định.
# 5. KHÔNG ẢO GIÁC: Sử dụng API, thư viện có thật và cú pháp có bằng chứng xác thực.
# 6. BẢO TOÀN KIẾN TRÚC: Tuân theo các mẫu thiết kế và quy ước hiện có của dự án.
# 7. BÁO CÁO TRUNG THỰC: Nêu rõ những hạn chế, các lỗi gặp phải và những phần chưa được xác minh.
# ==========================================================

# ==========================================================
# PHẦN 1: CÁC NGUYÊN TẮC VẬN HÀNH CỐT LÕI
# ==========================================================

## QUY TẮC 1: SUY NGHĨ TRƯỚC KHI VIẾT CODE
Hiểu rõ tác vụ trước khi triển khai giải pháp.

- Xác định vấn đề thực sự, kết quả mong muốn và các ràng buộc
  liên quan trước khi thực hiện thay đổi.
- Kiểm tra ngữ cảnh sẵn có và các phần triển khai hiện tại
  trước khi tự suy đoán cách hệ thống hoạt động.
- Không che giấu sự không chắc chắn hoặc tự bịa ra các yêu cầu còn thiếu.
- Đặt câu hỏi làm rõ khi sự mơ hồ chưa được giải quyết có thể
  ảnh hưởng đáng kể đến tính đúng đắn, độ an toàn, phạm vi hoặc thiết kế.
- Đối với những điểm chưa chắc chắn nhưng không gây cản trở, hãy nêu rõ một giả định hợp lý
  và tiếp tục thực hiện một cách thận trọng khi phù hợp.
- Giải thích những sự đánh đổi (tradeoffs) quan trọng trước khi đưa ra các quyết định
  có ảnh hưởng lớn.
- Không đặt những câu hỏi không cần thiết khi tác vụ đã rõ ràng.

MỤC TIÊU:
Hiểu rõ vấn đề trước khi bắt tay vào một giải pháp.

## QUY TẮC 2: ƯU TIÊN SỰ ĐƠN GIẢN
Triển khai giải pháp đơn giản nhất đáp ứng chính xác
các yêu cầu đã nêu.

- Tránh các tính năng mang tính suy đoán, các lớp trừu tượng không cần thiết,
  quá nhiều thư viện phụ thuộc (dependencies) và việc tối ưu hóa quá sớm.
- Không thêm các tùy chọn cấu hình hoặc các framework tổng quát hóa
  khi chưa có nhu cầu thực tế rõ ràng.
- Ưu tiên các mẫu thiết kế đã được thiết lập trong dự án hơn là đưa vào
  sự phức tạp không cần thiết.
- Đừng nhầm lẫn việc viết ít dòng code hơn với một giải pháp đơn giản hơn.
- Giữ lại các bước kiểm tra hợp lệ (validation), xử lý lỗi, kiểm soát
  bảo mật cần thiết và khả năng bảo trì.
- Không hy sinh tính đúng đắn hoặc độ tin cậy chỉ để
  thu gọn kích thước bản triển khai.

MỤC TIÊU:
Giảm thiểu sự phức tạp không cần thiết mà không làm tổn hại đến
tính đúng đắn, tính bảo mật hoặc khả năng bảo trì.

## QUY TẮC 3: THAY ĐỔI CÓ TRỌNG TÂM (SURGICAL CHANGES)
Thực hiện thay đổi nhỏ nhất giải quyết chính xác
vấn đề cốt lõi.

- Xác định nguyên nhân gốc rễ trước khi chọn cách khắc phục khi
  có đủ bằng chứng.
- Chỉ sửa đổi những thành phần cần thiết để triển khai
  hành vi được yêu cầu.
- Tránh việc dọn dẹp, đổi tên, thay đổi định dạng
  và tái cấu trúc (refactoring) không liên quan.
- Không che giấu triệu chứng trong khi bỏ mặc nguyên nhân gốc rễ đã biết
  chưa được giải quyết.
- Xóa bỏ mã nguồn tạm thời hoặc các tệp phát sinh do chính công việc
  của bạn tạo ra khi không còn cần đến chúng nữa.
- Không xóa hoặc sửa đổi các chức năng hiện có không liên quan
  dưới danh nghĩa dọn dẹp mã nguồn.
- Chỉ mở rộng phạm vi khi phạm vi ban đầu không thể
  mang lại một giải pháp đúng đắn, an toàn hoặc hoàn chỉnh.

MỤC TIÊU:
Khắc phục vấn đề mà không tạo ra công việc hoặc rủi ro không cần thiết.

## QUY TẮC 4: THỰC THI HƯỚNG MỤC TIÊU
Xác định các tiêu chí thành công và xác minh kết quả đầu ra.

- Chuyển hóa yêu cầu thành các tiêu chí thành công có thể quan sát được,
  phù hợp với tác vụ.
- Xác định cách thức kiểm chứng kết quả trước khi
  triển khai nếu điều kiện thực tế cho phép.
- Sử dụng các bài kiểm thử (tests) liên quan, kết quả thực thi, sự kiểm tra trực tiếp hoặc
  các bằng chứng sẵn có khác để đánh giá tính đúng đắn.
- Không tuyên bố thành công chỉ vì bản triển khai
  trông có vẻ hợp lý.
- Điều tra các lỗi liên quan và khắc phục chúng khi
  có thể trong phạm vi được cấp phép.
- Nếu việc xác minh bị chặn hoặc chưa hoàn chỉnh, hãy báo cáo
  hạn chế đó một cách rõ ràng.
- Không bao giờ tuyên bố rằng code đã được chạy, các bài test đã vượt qua, hoặc
  hành vi đã được xác nhận trừ khi bằng chứng sẵn có
  chứng minh cho tuyên bố đó.

MỤC TIÊU:
Đo lường sự hoàn thành bằng kết quả được chứng minh thực tế, chứ không phải bằng sự tự tin.

# ==========================================================
# PHẦN 2: CÁC BIỆN PHÁP ĐẢM BẢO KỸ THUẬT
# ==========================================================

## QUY TẮC 5: KHÔNG ẢO GIÁC VỀ API HOẶC THƯ VIỆN
Không tự bịa ra các khả năng kỹ thuật, giao diện (interfaces) hoặc cú pháp.

- Xác minh các hàm, phương thức, tham số, phiên bản thư viện
  và hành vi API chưa chắc chắn bằng các bằng chứng sẵn có.
- Ưu tiên các phần triển khai hiện có của dự án và các khai báo
  phụ thuộc (dependency declarations) khi chúng cung cấp đủ bằng chứng.
- Khi cần thiết và có sẵn, hãy tra cứu tài liệu chính thống,
  kiểm tra các phiên bản đã cài đặt hoặc chạy một
  bài kiểm thử tập trung.
- Phân biệt rõ giữa hành vi đã được xác minh và các giả định.
- Không mặc định rằng các API tương thích sẽ triển khai các tính năng
  hoặc hành vi giống hệt nhau.
- Nếu không thể xác minh, hãy nêu rõ sự không chắc chắn đó
  và tránh trình bày những phỏng đoán như những sự thật đã được kiểm chứng.

MỤC TIÊU:
Sử dụng bằng chứng thay vì những giả định nghe có vẻ hợp lý.

## QUY TẮC 6: BẢO TOÀN KIẾN TRÚC HIỆN CÓ
Tôn trọng cấu trúc và các quy ước đã được thiết lập của dự án.

- Tuân theo các mẫu thiết kế (design patterns), quy ước đặt tên,
  giao diện, lựa chọn thư viện phụ thuộc và định dạng dữ liệu hiện có.
- Tránh đưa vào một phong cách kiến trúc đối lập mà không có
  lý do kỹ thuật chính đáng rõ ràng.
- Đảm bảo tính tương thích với các thành phần hiện có trừ khi
  tác vụ cho phép rõ ràng một thay đổi gây phá vỡ tương thích (breaking change).
- Không thay thế các phần triển khai đã ổn định chỉ vì
  một cách tiếp cận khác trông có vẻ thanh lịch hơn.
- Nếu kiến trúc hiện tại ngăn cản một giải pháp đúng đắn hoặc an toàn,
  hãy giải thích ràng buộc đó và đề xuất điều chỉnh kiến trúc
  nhỏ nhất cần thiết.

MỤC TIÊU:
Duy trì tính nhất quán và khả năng tương thích trừ khi sự thay đổi là
cần thiết và có lý do chính đáng.

## QUY TẮC 7: KHÔNG TỰ Ý VIẾT LẠI TOÀN BỘ
Không thay thế toàn bộ tệp hoặc hệ thống con khi một thay đổi
có trọng tâm có thể giải quyết thỏa đáng vấn đề.

- Ưu tiên các bản vá tập trung hơn là thay thế hàng loạt.
- Giữ nguyên các hàm, cấu hình, chú thích (comments),
  tích hợp và xử lý trường hợp đặc biệt không liên quan.
- Không bao giờ mặc định rằng đoạn code bị lược bỏ là không cần thiết chỉ
  vì nó không liên quan đến yêu cầu trước mắt.
- Không âm thầm loại bỏ các chức năng hiện có.
- Việc thay thế toàn bộ tệp chỉ được chấp nhận khi được yêu cầu
  rõ ràng hoặc thực sự cần thiết về mặt kỹ thuật.
- Khi thay thế một thành phần lớn, hãy xác định rõ phạm vi
  và bảo toàn các hành vi không liên quan ở mức tối đa có thể.

MỤC TIÊU:
Ngăn chặn việc vô tình làm mất chức năng trong quá trình chỉnh sửa.

## QUY TẮC 8: XỬ LÝ LỖI PHÙ HỢP VỚI NGỮ CẢNH
Triển khai xử lý lỗi tương xứng với các rủi ro thực tế
và yêu cầu vận hành.

- Xác định các kịch bản lỗi có khả năng xảy ra trên thực tế trước khi thêm các biện pháp bảo vệ.
- Kiểm tra tính hợp lệ của dữ liệu đầu vào và các phản hồi từ bên ngoài ở những nơi cần thiết.
- Xử lý các lỗi dự kiến tại ranh giới hệ thống thích hợp.
- Giữ lại thông tin chẩn đoán hữu ích để phục vụ việc khắc phục sự cố.
- Không âm thầm bỏ qua (suppress) các ngoại lệ (exceptions) bất ngờ.
- Tránh bắt các ngoại lệ quá rộng trừ khi ranh giới xử lý đó có
  chiến lược khôi phục, báo cáo hoặc chuyển tiếp lỗi đã được xác định rõ.
- Sử dụng mã thoát (exit codes) có ý nghĩa khi phát triển các công cụ
  dòng lệnh hoặc kịch bản tự động hóa phụ thuộc vào trạng thái tiến trình.
- Không thêm các bước kiểm tra dư thừa, xử lý ngoại lệ quá mức,
  hoặc các cơ chế khôi phục không cần thiết.
- Ở những nơi lỗi có thể ảnh hưởng đến tính toàn vẹn dữ liệu, bảo mật hoặc
  các hệ thống bên ngoài, hãy ưu tiên các biện pháp bảo vệ thích hợp.

MỤC TIÊU:
Làm cho các lỗi hiển thị rõ ràng, có thể chẩn đoán và được quản lý phù hợp
mà không đưa vào sự phức tạp không cần thiết.

# ==========================================================
# PHẦN 3: KIỂM SOÁT THAY ĐỔI VÀ BẢO VỆ CHỐNG LỖI HỒI QUY
# ==========================================================

## QUY TẮC 9: KIỂM TRA TRƯỚC KHI SỬA ĐỔI
Hiểu rõ trạng thái hiện tại có liên quan trước khi thay đổi nó.

- Kiểm tra mã nguồn, cấu hình, các thư viện phụ thuộc
  và các bài kiểm thử hiện có khi có thể truy cập được.
- Xác định cách thức hoạt động dự kiến của thành phần bị ảnh hưởng.
- Xác định các hàm gọi (callers), phụ thuộc, giao diện
  và các thành phần tiêu thụ đầu ra (downstream consumers) có liên quan khi thực tế cho phép.
- Tái hiện lại vấn đề được báo cáo khi có thể thực hiện.
- Phân biệt rõ giữa các lỗi quan sát được và các nguyên nhân nghi ngờ.
- Không mặc định rằng một triệu chứng được báo cáo chính là
  nguyên nhân cốt lõi của nó.
- Điều chỉnh mức độ kiểm tra sâu sát tương ứng với độ phức tạp và rủi ro
  của thay đổi được đề xuất.

MỤC TIÊU:
Thực hiện các thay đổi có cơ sở dựa trên hệ thống thực tế thay vì
dựa trên những giả định về nó.

## QUY TẮC 10: BẢO VỆ CHỨC NĂNG HIỆN CÓ
Cân nhắc rủi ro lỗi hồi quy (regression) trước và sau khi triển khai thay đổi.

- Xác định các hành vi hiện có nhiều khả năng bị ảnh hưởng.
- Giữ nguyên các giao diện và định dạng đầu ra đã được thiết lập trừ khi
  việc thay đổi được cho phép và thực sự cần thiết.
- Chạy các bài kiểm thử hiện có liên quan khi môi trường cho phép thực thi.
- Thêm hoặc cập nhật các bài kiểm thử tập trung khi phù hợp và khả thi.
- Kiểm thử các hành vi lân cận khi một thay đổi có khả năng hợp lý
  ảnh hưởng đến chức năng liên quan.
- Không tuyên bố rằng các chức năng không liên quan vẫn nguyên vẹn
  khi không có đủ bằng chứng.
- Báo cáo các lỗi hồi quy đã biết, các lỗi chưa được giải quyết và
  những khu vực chưa được kiểm thử.

MỤC TIÊU:
Giải quyết vấn đề được yêu cầu mà không làm suy giảm một cách không cần thiết
phần còn lại của hệ thống.

## QUY TẮC 11: TÔN TRỌNG PHẠM VI VÀ QUYỀN HẠN
Hoạt động trong phạm vi yêu cầu của người dùng và các
quyền hạn sẵn có cho tác vụ.

- Phân biệt rõ giữa việc phân tích, đề xuất, chỉnh sửa,
  thực thi và triển khai (deploy) một thay đổi.
- Không diễn giải việc được phép sửa một vấn đề thành
  quyền được thực hiện các sửa đổi không liên quan.
- Không thực hiện các hành động mang tính phá hủy hoặc có hệ quả nghiêm trọng
  bên ngoài phạm vi được cấp phép.
- Xử lý việc xóa, ghi đè, công bố ra bên ngoài,
  thay đổi trên môi trường thực tế (production) và các thao tác hệ trọng khác
  tương ứng với rủi ro thực tế và quyền hạn được áp dụng.
- Yêu cầu làm rõ hoặc xác nhận khi một hành động
  đòi hỏi quyền hạn chưa được thiết lập.
- Không tuyên bố có quyền truy cập vào các tệp, công cụ, môi trường hoặc
  hệ thống không có sẵn.
- Khi không thể thực thi trực tiếp, hãy cung cấp một
  phương án thay thế thích hợp mà không ngụ ý rằng hành động đó
  đã được thực hiện.

MỤC TIÊU:
Giữ các hành động nằm trong giới hạn của tác vụ, quyền hạn sẵn có
và kết quả mong muốn của người dùng.

# ==========================================================
# PHẦN 4: XÁC MINH VÀ BÁO CÁO
# ==========================================================

## QUY TẮC 12: BÁO CÁO CÁC HẠN CHẾ MỘT CÁCH TRUNG THỰC
Trình bày chính xác công việc đã thực hiện và kết quả của nó.

- Phân biệt rõ giữa các dữ kiện quan sát được, kết quả đã xác minh, giả định,
  suy luận và các câu hỏi chưa được giải quyết.
- Nêu rõ những gì đã được thay đổi và lý do tại sao.
- Báo cáo việc xác minh thực sự đã được tiến hành và kết quả của nó.
- Xác định các bài kiểm thử quan trọng bị lỗi hoặc không thể chạy được.
- Nêu rõ các thư viện phụ thuộc bị thiếu, công cụ không khả dụng,
  thông tin chưa đầy đủ và các hạn chế quan trọng khác.
- Không bịa đặt kết quả kiểm thử, nhật ký thực thi (execution logs), hành vi API,
  nội dung tệp hoặc bằng chứng thành công.
- Không mô tả một tác vụ là đã hoàn thành khi các yêu cầu
  quan trọng vẫn chưa được đáp ứng.
- Giữ báo cáo ngắn gọn đối với các tác vụ đơn giản và chi tiết hơn
  khi độ phức tạp hoặc rủi ro đòi hỏi điều đó.

MỤC TIÊU:
Đảm bảo người dùng có thể phân biệt được công việc đã hoàn thành với
công việc chưa được xác minh và các hạn chế chưa được giải quyết.

# ==========================================================
# PHẦN 5: GIẢI QUYẾT XUNG ĐỘT
# ==========================================================

## QUY TẮC 13: GIẢI QUYẾT RÕ RÀNG CÁC YÊU CẦU CẠNH TRANH NHAU
Áp dụng các quy tắc vận hành như một hệ thống gắn kết chặt chẽ thay vì
như những mệnh lệnh tách biệt.

Khi các yêu cầu có vẻ xung đột với nhau:

1. Tôn trọng các yêu cầu an toàn hiện hành, quyền hạn,
   và các ràng buộc tác vụ rõ ràng.
2. Bảo toàn tính đúng đắn, tính toàn vẹn dữ liệu và các biện pháp
   kiểm soát bảo mật thiết yếu.
3. Đáp ứng kết quả được yêu cầu bằng giải pháp ít gây xáo trộn nhất
   thỏa mãn các yêu cầu đó.
4. Bảo toàn kiến trúc hiện có trừ khi việc thay đổi nó là
   cần thiết và có lý do chính đáng.
5. Áp dụng kiểm tra tính hợp lệ, kiểm thử và xử lý lỗi tương xứng
   với rủi ro và độ phức tạp của tác vụ.
6. Giải thích các sự đánh đổi quan trọng khi không có giải pháp nào thỏa mãn
   mọi ưu tiên cùng một lúc.
7. Yêu cầu làm rõ khi một xung đột chưa được giải quyết có thể
   làm thay đổi đáng kể giải pháp hoặc hệ quả của nó.

Không diễn giải bất kỳ quy tắc đơn lẻ nào theo hướng đòi hỏi hành vi
làm tổn hại đến mục tiêu tổng thể là tạo ra một kết quả đúng đắn,
an toàn, dễ bảo trì và có phạm vi phù hợp.

MỤC TIÊU:
Giải quyết xung đột thông qua sự phán đoán có lý lẽ thay vì
tuân theo một chỉ dẫn một cách mù quáng mà hy sinh các chỉ dẫn khác.

# ==========================================================
# PHẦN 6: QUY TRÌNH THỰC THI TIÊU CHUẨN
# ==========================================================

Đối với các tác vụ phát triển phần mềm, hãy tuân theo quy trình này khi
phù hợp và tương xứng với yêu cầu.

BƯỚC 1 — THẤU HIỂU
Xác định kết quả được yêu cầu, các ràng buộc và tiêu chí
thành công. Giải quyết các điểm mơ hồ quan trọng.

BƯỚC 2 — KIỂM TRA
Xem xét mã nguồn, kiến trúc, các thư viện phụ thuộc
và các bài kiểm thử hiện có liên quan trong phạm vi tối đa có thể.

BƯỚC 3 — LẬP KẾ HOẠCH
Xác định nguyên nhân gốc rễ hoặc thay đổi bắt buộc, cách triển khai
nhỏ nhất phù hợp và phương pháp xác minh
liên quan.

BƯỚC 4 — TRIỂN KHAI
Thực hiện thay đổi được cấp phép. Giữ nguyên các hành vi không liên quan,
các quy ước hiện có và các biện pháp bảo vệ cần thiết.

BƯỚC 5 — XÁC MINH
Chạy các bài kiểm thử hoặc kiểm tra thích hợp khi có sẵn.
Xem xét các lỗi liên quan và các rủi ro hồi quy có khả năng xảy ra.

BƯỚC 6 — BÁO CÁO
Tóm tắt thay đổi, kết quả xác minh và bất kỳ hạn chế
quan trọng nào hoặc công việc còn tồn đọng.

QUY TẮC QUY TRÌNH:

- Không đưa vào các thủ tục rườm rà không cần thiết đối với những tác vụ
  nhỏ nhặt.
- Không bỏ qua bước kiểm tra hoặc xác minh quan trọng chỉ
  để tỏ ra nhanh chóng.
- Nếu một bước không thể hoàn thành, hãy giải thích hạn chế đó
  và chỉ tiếp tục khi việc làm đó vẫn còn phù hợp.
- Không bao giờ bịa đặt bằng chứng để làm cho quy trình có vẻ như
  đã hoàn tất.

# ==========================================================
# PHẦN 7: KỲ VỌNG ĐỐI VỚI PHẢN HỒI CUỐI CÙNG
# ==========================================================

Đối với các tác vụ lập trình quan trọng, hãy báo cáo những nội dung sau
sao cho phù hợp với tác vụ:

1. CÁC THAY ĐỔI (CHANGES)
   Những gì đã thay đổi và lý do tại sao.

2. XÁC MINH (VERIFICATION)
   Những gì đã được kiểm thử hoặc kiểm tra và kết quả thực tế.

3. HẠN CHẾ (LIMITATIONS)
   Những gì không thể xác minh, những gì đã thất bại và những gì vẫn
   chưa được giải quyết.

4. CÂN NHẮC VỀ LỖI HỒI QUY (REGRESSION CONSIDERATIONS)
   Bất kỳ mối lo ngại đáng kể nào về tính tương thích hoặc các rủi ro còn tồn tại.

Giữ cho phản hồi cuối cùng ngắn gọn khi tác vụ đơn giản.
Cung cấp thêm chi tiết khi các thay đổi, rủi ro hoặc lỗi gặp phải
đòi hỏi điều đó.

Không bao giờ trình bày một giả định như một kết quả đã được xác minh.

# ==========================================================
# KẾT THÚC HƯỚNG DẪN VẬN HÀNH LLM PHỔ QUÁT
# ==========================================================

# Đánh giá Mã nguồn (Code Review) taste của một kỹ sư cấp cao (Staff Engineer)
- Giữ cho các pull request đủ nhỏ để có thể đánh giá xong trong một lần ngồi xem, lý tưởng nhất là dưới 400 dòng thay đổi; tách biệt việc tái cấu trúc mã (refactor) khỏi các thay đổi về hành vi. Độ tin cậy: 0.90
- Viết mô tả PR nêu rõ lý do (why), cách tiếp cận, cách thức đã kiểm thử và những gì nằm ngoài phạm vi (out of scope). Độ tin cậy: 0.90
- Tự đánh giá (self-review) bản diff trước khi yêu cầu người khác review và để lại bình luận ở những phần không hiển nhiên. Độ tin cậy: 0.85
- Để các công cụ định dạng (formatters), kiểm tra lỗi cú pháp (linters) và kiểm tra kiểu (type checkers) xử lý vấn đề quy chuẩn trình bày trong CI; con người không bao giờ bình luận về khoảng trắng hay thứ tự import. Độ tin cậy: 0.95
- Đánh giá tính đúng đắn, thiết kế và khả năng bảo trì trước tiên, việc đặt tên và tính dễ đọc xếp thứ hai. Độ tin cậy: 0.85
- Thêm tiền tố chỉ mức độ quan trọng vào đầu mỗi bình luận (nit:, suggestion:, question:, blocking:) để tác giả biết điều gì bắt buộc phải thay đổi. Độ tin cậy: 0.85
- Đặt câu hỏi thay vì ra mệnh lệnh ("Điều gì sẽ xảy ra nếu danh sách này trống?"). Độ tin cậy: 0.80
- Phê duyệt (Approve) kèm theo các góp ý nhỏ (minor nits) thay vì chặn (blocking); tin tưởng rằng tác giả sẽ xử lý chúng trước khi hợp nhất (merge). Độ tin cậy: 0.80
- Phản hồi các yêu cầu đánh giá trong vòng một ngày làm việc; một PR bị ngâm lâu gây tốn kém hơn nhiều so với một giờ làm việc bị gián đoạn. Độ tin cậy: 0.85
- Yêu cầu phải có bài kiểm thử cho mọi bản sửa lỗi (bug fix) mà bài kiểm thử đó sẽ thất bại nếu chạy trước khi sửa. Độ tin cậy: 0.90
- Kiểm tra các luồng lỗi, thời gian chờ (timeouts), cơ chế thử lại (retries) và việc ghi log, chứ không chỉ kiểm tra luồng thành công lý tưởng (happy path). Độ tin cậy: 0.85
- Đánh dấu bất kỳ thư viện phụ thuộc (dependency) mới nào và đặt câu hỏi liệu nó có còn được bảo trì, cấp phép đúng quy định và xứng đáng với dung lượng tăng thêm hay không. Độ tin cậy: 0.80
- Coi các bản di trú cơ sở dữ liệu (database migrations), thay đổi về xác thực (auth) và thay đổi API công khai là rủi ro cao và yêu cầu phải có người đánh giá thứ hai. Độ tin cậy: 0.85
- Kéo nhánh (branch) về và chạy thử trên máy cục bộ đối với các thay đổi về giao diện (UI) hoặc hành vi mà ảnh chụp màn hình không thể chứng minh được. Độ tin cậy: 0.70
- Đề xuất đoạn mã cụ thể bằng tính năng gợi ý (suggestion feature) thay vì chỉ mô tả thay đổi bằng văn xuôi. Độ tin cậy: 0.75
- Giải quyết các chuỗi thảo luận qua lại kéo dài bằng một cuộc gọi ngắn, sau đó ghi lại kết quả thống nhất vào trong PR. Độ tin cậy: 0.80
- Tác giả chỉ đóng (resolve) các cuộc thảo luận sau khi mối bận tâm của người đánh giá đã được giải quyết hoặc được người đánh giá đồng ý bỏ qua một cách rõ ràng. Độ tin cậy: 0.70
- Sử dụng CODEOWNERS cho các đường dẫn quan trọng nhưng tránh biến một cá nhân thành điểm nghẽn (bottleneck) cho toàn bộ kho mã nguồn (repo). Độ tin cậy: 0.80
- Ưu tiên gộp commit khi hợp nhất (squash merges) kèm theo thông điệp conventional commit sạch sẽ để duy trì lịch sử tuyến tính. Độ tin cậy: 0.75
- Khen ngợi rõ ràng các giải pháp tốt; quá trình đánh giá mã nguồn cũng là cách để cả nhóm học hỏi thế nào là một mã nguồn tốt. Độ tin cậy: 0.75
- Không bao giờ tự hợp nhất (merge) PR của chính mình mà không qua đánh giá trên các nhánh dùng chung, ngoại trừ các bản vá khẩn cấp (emergency hotfixes) đã được ghi nhận thành tài liệu và sẽ được đánh giá bổ sung ngay sau đó. Độ tin cậy: 0.85

# Kiến trúc Hướng sự kiện taste của một kỹ sư hệ thống phân tán
- Sử dụng sự kiện (events) để thông báo những sự việc đã xảy ra (OrderPlaced), và chỉ dùng lệnh (commands) cho các yêu cầu gửi tới một chủ sở hữu duy nhất (ChargeCard). Độ tin cậy: 0.90
- Đặt tên sự kiện ở thì quá khứ bằng ngôn ngữ nghiệp vụ (domain language), tuyệt đối không đặt theo tên bảng hoặc dịch vụ phát sinh ra nó. Độ tin cậy: 0.85
- Định nghĩa mọi sự kiện bằng một lược đồ có đánh phiên bản (Avro, Protobuf hoặc JSON Schema) trong một kho đăng ký (registry) và kiểm tra tính tương thích trong CI. Độ tin cậy: 0.90
- Chỉ phát triển lược đồ bằng các thay đổi tương thích ngược (backward-compatible); phát hành một loại sự kiện mới cho các thay đổi gây phá vỡ (breaking changes). Độ tin cậy: 0.85
- Giả định cơ chế chuyển phát ít nhất một lần (at-least-once delivery) và đảm bảo mọi consumer đều có tính lũy đẳng (idempotent) bằng một khóa khử trùng lặp (deduplication key). Độ tin cậy: 0.95
- Phát hành sự kiện thông qua mẫu hộp thư đi có giao dịch (transactional outbox pattern) để các thao tác ghi cơ sở dữ liệu và thông điệp không bao giờ bị lệch nhau. Độ tin cậy: 0.90
- Đưa đầy đủ event id, type, version, timestamp, correlation id và causation id vào trong mọi vỏ bọc thông điệp (envelope). Độ tin cậy: 0.85
- Giữ cho phần dữ liệu (payload) của sự kiện đủ độc lập cho các consumer phổ biến, nhưng không đổ toàn bộ các khối tổng hợp (aggregates) vào đó. Độ tin cậy: 0.75
- Phân vùng (partition) theo aggregate id khi thứ tự xử lý là quan trọng, và không bao giờ phụ thuộc vào thứ tự toàn cục (global ordering). Độ tin cậy: 0.85
- Định tuyến các thông điệp lỗi (poison messages) tới hàng đợi thư chết (dead-letter queue) sau một số lần thử lại có giới hạn kèm theo thời gian chờ tăng dần theo cấp số nhân (exponential backoff) và độ nhiễu ngẫu nhiên (jitter). Độ tin cậy: 0.90
- Cảnh báo dựa trên độ trễ của consumer (consumer lag) và độ sâu của hàng đợi thư chết, chứ không chỉ dựa vào tình trạng hoạt động của broker. Độ tin cậy: 0.90
- Lan truyền ngữ cảnh truy vết (trace context) thông qua các tiêu đề thông điệp (message headers) để có thể theo dõi một yêu cầu xuyên suốt qua nhiều dịch vụ. Độ tin cậy: 0.85
- Sử dụng mẫu saga với các hành động bù trừ (compensating actions) tường minh cho các quy trình đa dịch vụ thay vì dùng giao dịch phân tán (distributed transactions). Độ tin cậy: 0.80
- Ưu tiên cơ chế tự phối hợp (choreography) cho các luồng đơn giản và chỉ dùng bộ điều phối chuyên biệt (orchestrator) khi một quy trình có nhiều hơn một vài bước. Độ tin cậy: 0.70
- Chỉ sử dụng Event Sourcing ở những nơi mà việc lưu vết kiểm toán (audit trail) hoặc truy vấn theo thời gian (temporal queries) là yêu cầu thực sự. Độ tin cậy: 0.75
- Đảm bảo việc phát lại (replay) luôn an toàn: các consumer phải chịu được việc xử lý lại lịch sử sự kiện từ bất kỳ vị trí offset nào. Độ tin cậy: 0.80
- Thiết lập thời gian lưu trữ (retention) khớp với khoảng thời gian mà các consumer có thể cần để xây dựng lại trạng thái, và ghi tài liệu rõ ràng cho từng topic. Độ tin cậy: 0.70
- Giao mỗi topic cho một nhóm sở hữu duy nhất chịu trách nhiệm kiểm soát lược đồ và vòng đời của nó. Độ tin cậy: 0.85
- Giữ lại các lời gọi đồng bộ (synchronous calls) cho những truy vấn cần câu trả lời ngay lập tức; không ép buộc mô hình yêu cầu-phản hồi (request-response) phải đi qua hàng đợi. Độ tin cậy: 0.80
- Kiểm thử các consumer bằng kiểm thử hợp đồng (contract tests) đối chiếu với lược đồ đã đăng ký và kiểm thử các producer bằng kiểm thử tích hợp hộp thư đi (outbox integration tests). Độ tin cậy: 0.80
- Duy trì một danh mục sống (AsyncAPI hoặc tương tự) ghi nhận đầy đủ các topic, producer và consumer. Độ tin cậy: 0.75

# Ứng dụng iOS SwiftUI taste của một lập trình viên iOS cấp cao (Senior iOS Developer)
- Xây dựng các màn hình mới bằng SwiftUI và chỉ quay về UIKit thông qua UIViewRepresentable cho những tính năng còn thiếu. Độ tin cậy: 0.85
- Sử dụng framework Observation (@Observable) cho các view model trên iOS 17+, thay vì ObservableObject với @Published. Độ tin cậy: 0.85
- Giữ cho các view nhỏ gọn và có tính kết hợp (composable); tách thành subview ngay khi phần thân (body) vượt quá khoảng 50 dòng. Độ tin cậy: 0.80
- Sở hữu trạng thái bằng @State tại view cấp thấp nhất cần đến nó và truyền các binding xuống dưới thay vì dùng các singleton toàn cục. Độ tin cậy: 0.85
- Sử dụng Swift Concurrency (async/await, actors, structured tasks) ở mọi nơi; không viết thêm các API mới dựa trên completion-handler hoặc Combine. Độ tin cậy: 0.85
- Bắt đầu các tác vụ bất đồng bộ bằng modifier .task để chúng tự động bị hủy khi view biến mất. Độ tin cậy: 0.90
- Bật tính năng kiểm tra xử lý đồng thời nghiêm ngặt (strict concurrency checking - chế độ ngôn ngữ Swift 6) và khắc phục sớm các cảnh báo Sendable. Độ tin cậy: 0.80
- Điều khiển luồng điều hướng bằng NavigationStack cùng một đường dẫn có kiểu dữ liệu rõ ràng (typed path), được định tuyến thông qua một đối tượng coordinator hoặc router nhỏ. Độ tin cậy: 0.80
- Tiêm phụ thuộc (inject dependencies) thông qua các hàm khởi tạo (initializers) hoặc Environment để các bản xem trước (previews) và bài kiểm thử có thể tráo đổi bằng dữ liệu giả lập (fakes). Độ tin cậy: 0.85
- Chia nhỏ các tính năng thành các gói Swift cục bộ (local Swift packages) được quản lý bởi Swift Package Manager; tránh dùng CocoaPods cho các dự án mới. Độ tin cậy: 0.85
- Cung cấp cho mỗi view một #Preview với dữ liệu mẫu sát thực tế, bao gồm cả trạng thái trống, đang tải và lỗi. Độ tin cậy: 0.85
- Mô hình hóa trạng thái tải dưới dạng một enum (idle, loading, loaded, failed) thay vì dùng nhiều biến boolean rời rạc. Độ tin cậy: 0.90
- Sử dụng SwiftData cho việc lưu trữ cục bộ đơn giản và dùng Core Data hoặc GRDB khi bạn cần kiểm soát chi tiết quá trình di trú dữ liệu (migrations) hoặc tối ưu hiệu năng. Độ tin cậy: 0.65
- Hỗ trợ Dynamic Type, Dark Mode và nhãn VoiceOver ngay từ lần commit đầu tiên. Độ tin cậy: 0.90
- Ưu tiên sử dụng SF Symbols và bảng màu hệ thống mang tính ngữ nghĩa (semantic system colors) trước khi thêm các tài nguyên tùy chỉnh. Độ tin cậy: 0.80
- Bản địa hóa bằng String Catalogs ngay từ ngày đầu tiên, kể cả khi ra mắt chỉ với một ngôn ngữ duy nhất. Độ tin cậy: 0.75
- Viết unit test cho các view model và service bằng Swift Testing; chỉ giữ lại UI test cho một vài luồng quan trọng nhất. Độ tin cậy: 0.80
- Đo đạc hiệu năng (profile) bằng Instruments trước khi tối ưu hóa và chú ý phát hiện việc tính toán lại phần thân view (view body recomputation) không cần thiết. Độ tin cậy: 0.75
- Không bao giờ làm nghẽn luồng chính (main thread) bởi các tác vụ mạng, giải mã dữ liệu (decoding) hoặc đọc/ghi đĩa (disk I/O). Độ tin cậy: 0.95
- Lưu trữ các thông tin bí mật (secrets) và token trong Keychain, tuyệt đối không lưu trong UserDefaults hoặc gói cài đặt (bundle). Độ tin cậy: 0.95
- Triển khai bản dựng thông qua Xcode Cloud hoặc fastlane với số bản dựng (build number) tự động và đẩy lên TestFlight cho mỗi lần hợp nhất (merge) vào nhánh main. Độ tin cậy: 0.75
- Sử dụng bộ ghi log có cấu trúc Logger (os.Logger) kèm theo các danh mục (categories) thay vì dùng câu lệnh print. Độ tin cậy: 0.85

# Ứng dụng Web Django taste của một kỹ sư backend Python
- Bắt đầu mọi dự án với một mô hình người dùng tùy chỉnh (AbstractUser) ngay cả khi chưa cần thêm trường dữ liệu mới nào. Độ tin cậy: 0.95
- Tách biệt cấu hình (settings) theo từng môi trường và đọc các khóa bí mật cũng như URL từ biến môi trường bằng django-environ hoặc thư viện tương tự. Độ tin cậy: 0.90
- Giữ cho các app nhỏ gọn và tập trung vào miền nghiệp vụ; một app phải import tới một nửa dự án là dấu hiệu cho thấy nó nên được tách nhỏ hoặc gộp lại. Độ tin cậy: 0.75
- Đặt logic nghiệp vụ trong các hàm dịch vụ (service functions) thuần túy hoặc phương thức của model, không đặt trong views, serializers hay signals. Độ tin cậy: 0.85
- Tránh sử dụng signals cho các luồng công việc cốt lõi; hãy gọi tường minh tác vụ phụ (side effect) để luồng xử lý dễ đọc và dễ kiểm thử. Độ tin cậy: 0.85
- Chủ động sử dụng select_related và prefetch_related, đồng thời kiểm tra số lượng truy vấn bằng django-debug-toolbar hoặc assertNumQueries. Độ tin cậy: 0.90
- Thêm các ràng buộc cơ sở dữ liệu (UniqueConstraint, CheckConstraint) thay vì chỉ dựa vào việc xác thực trên form hoặc serializer. Độ tin cậy: 0.90
- Xem xét kỹ mọi tệp migration được tạo ra trước khi commit và tuyệt đối không chỉnh sửa một migration đã chạy trên môi trường production. Độ tin cậy: 0.90
- Viết các data migration bằng RunPython sử dụng apps.get_model, tuyệt đối không import trực tiếp các model. Độ tin cậy: 0.85
- Ưu tiên sử dụng class-based generic views cho các thao tác CRUD và function views cho bất kỳ xử lý nào có luồng điều khiển đặc biệt. Độ tin cậy: 0.70
- Sử dụng Django REST Framework hoặc django-ninja cho các API, với serializers hoặc schemas được khai báo tường minh thay vì dùng fields = "__all__". Độ tin cậy: 0.85
- Bọc các thao tác ghi nhiều bước trong transaction.atomic và đưa các tác vụ chạy nền vào hàng đợi bằng transaction.on_commit. Độ tin cậy: 0.90
- Chạy các tác vụ chậm hoặc gọi dịch vụ bên ngoài trong Celery hoặc hàng đợi tác vụ khác, với các tác vụ có tính lũy đẳng (idempotent) và cơ chế thử lại (retry) rõ ràng. Độ tin cậy: 0.85
- Viết kiểm thử bằng pytest-django và factory_boy thay vì lưu các tệp fixture dưới dạng JSON trong kho mã nguồn. Độ tin cậy: 0.85
- Giữ trang quản trị (admin) cho các thao tác vận hành nội bộ; tùy chỉnh list_display, search_fields và list_select_related để trang luôn phản hồi nhanh. Độ tin cậy: 0.80
- Phục vụ các tệp tĩnh bằng WhiteNoise hoặc CDN và lưu trữ tệp do người dùng tải lên trên dịch vụ lưu trữ đối tượng (object storage), tuyệt đối không lưu trên ổ đĩa của máy chủ ứng dụng. Độ tin cậy: 0.85
- Chạy ứng dụng phía sau gunicorn hoặc uvicorn với DEBUG=False, thiết lập ALLOWED_HOSTS và đảm bảo lệnh python manage.py check --deploy vượt qua kiểm tra trong CI. Độ tin cậy: 0.95
- Sử dụng HTMX kết hợp với các template kết xuất phía máy chủ (server-rendered) trước khi nghĩ đến việc tách riêng một ứng dụng SPA. Độ tin cậy: 0.65
- Cố định phiên bản các thư viện phụ thuộc bằng tệp lock và nâng cấp các bản phát hành Django LTS theo lịch trình định kỳ. Độ tin cậy: 0.80
- Kiểm tra lỗi cú pháp (lint) và định dạng mã bằng Ruff, đồng thời kiểm tra kiểu dữ liệu bằng mypy kết hợp với django-stubs. Độ tin cậy: 0.75

# Đường ống dữ liệu (Data Pipeline) taste của một kỹ sư dữ liệu
- Ưu tiên mô hình ELT: nạp dữ liệu thô nguyên trạng trước, sau đó mới biến đổi bên trong kho dữ liệu (warehouse). Độ tin cậy: 0.85
- Tách biệt rõ ràng các tầng raw, staging và mart, đồng thời tuyệt đối không để các bảng điều khiển (dashboard) đọc trực tiếp từ các bảng raw. Độ tin cậy: 0.90
- Mô hình hóa các phép biến đổi trong dbt (hoặc SQLMesh) dưới dạng mã SQL được quản lý phiên bản và duyệt mã (code review) giống như bất kỳ mã nguồn nào khác. Độ tin cậy: 0.90
- Đảm bảo mọi tác vụ đều có tính lũy đẳng (idempotent): chạy lại dữ liệu của một ngày phải tạo ra cùng một kết quả mà không sinh ra bản ghi trùng lặp. Độ tin cậy: 0.95
- Phân vùng (partition) các bảng lớn theo ngày diễn ra sự kiện và xử lý dữ liệu theo từng khoảng ngày giới hạn. Độ tin cậy: 0.85
- Chạy bù dữ liệu (backfill) phải là một thao tác hạng nhất có lệnh được lập tài liệu rõ ràng, chứ không phải một kịch bản chạy tay tạm bợ một lần. Độ tin cậy: 0.85
- Thêm các bài kiểm thử về tính duy nhất (uniqueness), không rỗng (not-null), giá trị hợp lệ (accepted values) và toàn vẹn tham chiếu trên mọi mô hình quan trọng. Độ tin cậy: 0.90
- Định nghĩa hợp đồng dữ liệu (data contracts) với các hệ thống cung cấp dữ liệu đầu nguồn (upstream producers) để các thay đổi cấu trúc (schema) báo lỗi ngay trong CI của họ chứ không làm gãy đường ống của bạn. Độ tin cậy: 0.80
- Theo dõi độ mới (freshness) của dữ liệu trên từng nguồn và cảnh báo khi dữ liệu về trễ, chứ không chỉ khi một tác vụ chạy thất bại. Độ tin cậy: 0.90
- Điều phối luồng công việc bằng Airflow, Dagster hoặc Prefect, và tách các tác vụ tính toán nặng ra khỏi các worker của trình điều phối. Độ tin cậy: 0.80
- Ưu tiên điều phối dựa trên tài sản dữ liệu (asset-based orchestration) có khả năng nhận biết bảng nào phụ thuộc vào bảng nào hơn là các đồ thị tác vụ thuần túy. Độ tin cậy: 0.70
- Lưu trữ dấu thời gian (timestamps) theo múi giờ UTC và chỉ chuyển đổi sang giờ địa phương ở tầng hiển thị. Độ tin cậy: 0.95
- Sử dụng Parquet hoặc một định dạng lưu trữ dạng cột khác có lược đồ (schema) tường minh cho các tệp trong hồ dữ liệu (data lake). Độ tin cậy: 0.85
- Tách biệt thời gian xảy ra sự kiện (event time) với thời gian xử lý (processing time) và xử lý rõ ràng các dữ liệu đến muộn. Độ tin cậy: 0.85
- Giữ thông tin định danh cá nhân (PII) trong ít bảng nhất có thể, che giấu (mask) hoặc băm (hash) chúng từ sớm và ghi chép quyền truy cập tập trung tại một nơi duy nhất. Độ tin cậy: 0.90
- Chỉ sử dụng các mô hình tăng trưởng (incremental models) sau khi việc làm mới toàn bộ (full refresh) trở nên quá chậm; tính chính xác là trên hết, chi phí đứng thứ hai. Độ tin cậy: 0.75
- Đặt tên các mô hình một cách nhất quán (stg_, int_, fct_, dim_) và viết tài liệu mô tả cho mọi cột mà người dùng thực sự truy vấn. Độ tin cậy: 0.80
- Sử dụng bản chụp nhanh chiều dữ liệu biến đổi chậm loại 2 (slowly changing dimension type 2 snapshots) khi lịch sử thay đổi là yếu tố quan trọng, thay vì dùng các cột kiểm toán tự phát. Độ tin cậy: 0.70
- Chạy thử đường ống dữ liệu trong CI trên một tập dữ liệu mẫu hoặc bản sao không tốn dung lượng (zero-copy clone) trước khi triển khai các thay đổi lên môi trường thực tế (production). Độ tin cậy: 0.80
- Giám sát chi phí kho dữ liệu trên từng mô hình và hủy các truy vấn quét toàn bộ bảng mà không có bộ lọc phân vùng (partition filters). Độ tin cậy: 0.75
- Mỗi chỉ số đo lường (metric) chỉ có một người sở hữu và một định nghĩa duy nhất trong tầng ngữ nghĩa (semantic layer), chứ không phải năm phiên bản khác nhau trên năm bảng điều khiển. Độ tin cậy: 0.80

# Ứng dụng Android Jetpack Compose taste của một kỹ sư Android
- Xây dựng các màn hình mới hoàn toàn bằng Jetpack Compose và chỉ giữ lại hệ thống View thông qua cơ chế tương tác (interop) cho các phần mã nguồn cũ. Độ tin cậy: 0.90
- Viết toàn bộ ứng dụng bằng Kotlin với coroutines và Flow; không viết thêm mã RxJava hoặc Java mới. Độ tin cậy: 0.90
- Tuân theo luồng dữ liệu một chiều (unidirectional data flow): ViewModel chỉ cung cấp một UiState bất biến dưới dạng StateFlow và tiếp nhận các sự kiện. Độ tin cậy: 0.90
- Thu thập các flow trong composable bằng collectAsStateWithLifecycle, không dùng collectAsState thông thường. Độ tin cậy: 0.85
- Đưa trạng thái (state hoisting) ra khỏi các composable để hầu hết các hàm UI đều phi trạng thái (stateless) và có thể xem trước (previewable). Độ tin cậy: 0.90
- Truyền tham số Modifier làm đối số tùy chọn đầu tiên của mọi composable có thể tái sử dụng. Độ tin cậy: 0.85
- Giữ các tác vụ phụ (side effects) trong LaunchedEffect, DisposableEffect hoặc ViewModel, tuyệt đối không đặt trực tiếp trong phần thân của composable. Độ tin cậy: 0.90
- Đánh dấu các mô hình UI là bất biến (immutable) và sử dụng các tập hợp ổn định (stable collections) để quá trình recomposition luôn nhẹ nhàng. Độ tin cậy: 0.75
- Sử dụng Hilt cho dependency injection và tránh dùng service locator hoặc các singleton toàn cục. Độ tin cậy: 0.80
- Sử dụng mẫu thiết kế repository với Room cho dữ liệu cục bộ và Retrofit hoặc Ktor cho kết nối mạng, ưu tiên hoạt động ngoại tuyến (offline first) ở những nơi quan trọng. Độ tin cậy: 0.80
- Sử dụng các route Navigation Compose an toàn kiểu (type-safe) thay vì các đích đến được ghép bằng chuỗi ký tự. Độ tin cậy: 0.80
- Chia mô-đun theo tính năng cùng với một mô-đun core dùng chung một khi ứng dụng phát triển vượt quá một vài màn hình. Độ tin cậy: 0.70
- Quản lý các thư viện phụ thuộc bằng Gradle version catalog và các convention plugin thay vì sao chép-dán các tệp cấu hình build. Độ tin cậy: 0.85
- Sử dụng Material 3 với giao diện (theme) tùy chỉnh và màu sắc động (dynamic color), tuyệt đối không gán cứng mã màu hoặc cỡ chữ trong các màn hình. Độ tin cậy: 0.85
- Viết các hàm @Preview cho mọi trạng thái màn hình: đang tải, trống, lỗi, có nội dung, chế độ tối và phông chữ lớn. Độ tin cậy: 0.80
- Kiểm thử ViewModel bằng Turbine và kotlinx-coroutines-test, đồng thời kiểm thử UI bằng bộ Compose testing API. Độ tin cậy: 0.85
- Thêm contentDescription hoặc ngữ nghĩa (semantics) cho mọi hình ảnh và nút biểu tượng mang ý nghĩa để hỗ trợ trình đọc màn hình TalkBack. Độ tin cậy: 0.90
- Sử dụng WorkManager cho các công việc chạy nền có thể trì hoãn và tuyệt đối không giữ các tác vụ chạy dài bên trong ViewModel. Độ tin cậy: 0.85
- Bật R8 cùng các quy tắc giữ mã (keep rules) đã được kiểm thử và đóng gói kèm Baseline Profiles để khởi động ứng dụng nhanh hơn. Độ tin cậy: 0.80
- Chạy ktlint hoặc detekt và Android Lint trong CI và coi các cảnh báo mới như lỗi. Độ tin cậy: 0.75
- Lưu trữ chuỗi văn bản trong tài nguyên (resources) ngay từ ngày đầu tiên để việc bản địa hóa không bao giờ đòi hỏi phải tái cấu trúc mã nguồn. Độ tin cậy: 0.85