Prompt Coding

# Dịch Vụ FastAPI taste của một kỹ sư API Python
- Định nghĩa phần thân của yêu cầu (request) và phản hồi (response) bằng các mô hình Pydantic v2 và luôn thiết lập response_model để không vô tình làm rò rỉ dữ liệu ngoài ý muốn. Độ tin cậy: 0.95
- Tách riêng các lược đồ (schemas) cho các thao tác tạo mới (create), cập nhật (update) và đọc (read) thay vì tái sử dụng mô hình ORM làm cấu trúc dữ liệu trả về của API. Độ tin cậy: 0.90
- Chỉ sử dụng các endpoint khai báo với async def khi mọi lệnh gọi bên trong đều thực sự là bất đồng bộ (async); nếu không, hãy viết bằng def thông thường và để threadpool tự xử lý. Độ tin cậy: 0.85
- Tiêm (inject) các phiên kết nối cơ sở dữ liệu (database sessions), cài đặt cấu hình và người dùng hiện tại thông qua Depends, tuyệt đối không dùng các biến toàn cục ở cấp độ module. Độ tin cậy: 0.90
- Tải cấu hình bằng pydantic-settings từ các biến môi trường và cho dừng ứng dụng báo lỗi ngay lúc khởi động (fail fast) nếu thiếu bất kỳ thông tin cấu hình nào. Độ tin cậy: 0.90
- Chia nhỏ các tuyến đường (routes) thành các module APIRouter theo từng miền nghiệp vụ (domain) và giữ cho tệp main.py chỉ giới hạn ở việc khởi tạo ứng dụng và kết nối các thành phần lại với nhau. Độ tin cậy: 0.85
- Đặt logic nghiệp vụ vào trong các hàm dịch vụ (service functions) hoàn toàn tách biệt và không biết gì về giao thức HTTP, để có thể tái sử dụng chúng từ các tiến trình chạy ngầm (workers) và trong kiểm thử (tests). Độ tin cậy: 0.85
- Sử dụng cú pháp SQLAlchemy 2.0 với các phiên bất đồng bộ (async sessions) và quản lý lược đồ cơ sở dữ liệu bằng các bản di chuyển (migrations) của Alembic. Độ tin cậy: 0.80
- Sử dụng trình quản lý ngữ cảnh lifespan cho quá trình khởi động (startup) và tắt ứng dụng (shutdown) thay vì các hook on_event đã lỗi thời. Độ tin cậy: 0.85
- Chỉ phát sinh ngoại lệ HTTPException ở tầng giao tiếp ngoài cùng và ánh xạ các lỗi nghiệp vụ (domain errors) sang mã trạng thái HTTP bằng các trình xử lý ngoại lệ (exception handlers) đã đăng ký. Độ tin cậy: 0.80
- Trả về cấu trúc lỗi nhất quán gồm mã lỗi máy có thể đọc được (machine-readable code), thông báo lỗi và thông tin chi tiết tùy chọn. Độ tin cậy: 0.85
- Đánh phiên bản cho API ngay trên đường dẫn (/v1) và coi lược đồ OpenAPI được tạo ra như một bản hợp đồng giao tiếp được kiểm tra tự động trong quy trình CI. Độ tin cậy: 0.75
- Sử dụng phân trang dựa trên con trỏ (cursor-based pagination) cho các danh sách lớn và giới hạn kích thước trang tối đa ở phía máy chủ. Độ tin cậy: 0.80
- Kiểm thử bằng pytest và httpx.AsyncClient, ghi đè các phụ thuộc (overriding dependencies) thay vì dùng kỹ thuật monkey-patch vào các thành phần nội bộ. Độ tin cậy: 0.90
- Chạy các tiến trình con (workers) của uvicorn phía sau gunicorn hoặc một trình quản lý tiến trình trên môi trường production, và chỉ dùng cờ --reload trong môi trường phát triển (development). Độ tin cậy: 0.80
- Chuyển các tác vụ xử lý chậm sang một hàng đợi tác vụ (task queue) thực thụ như Celery, Arq hoặc Dramatiq; BackgroundTasks chỉ dành cho các công việc nhỏ chạy một lần rồi thôi (fire-and-forget). Độ tin cậy: 0.85
- Thêm ID yêu cầu (request IDs), nhật ký định dạng JSON có cấu trúc và middleware truy vết OpenTelemetry ngay từ ngày đầu tiên. Độ tin cậy: 0.80
- Bảo vệ các endpoint bằng OAuth2 bearer token hoặc khóa API thông qua các phụ thuộc bảo mật (security dependencies) để trang tài liệu tự động hiển thị cơ chế xác thực. Độ tin cậy: 0.80
- Cung cấp riêng biệt hai endpoint /healthz và /readyz, trong đó bước kiểm tra mức độ sẵn sàng (readiness) sẽ kiểm tra kết nối cơ sở dữ liệu và các phụ thuộc cứng khác. Độ tin cậy: 0.85
- Quản lý các thư viện phụ thuộc bằng uv kèm theo tệp khóa (lock file), đồng thời kiểm tra lỗi cú pháp (lint) và định dạng mã nguồn bằng Ruff. Độ tin cậy: 0.75
- Kiểm tra kiểu dữ liệu (type check) bằng mypy hoặc pyright ở chế độ nghiêm ngặt (strict mode) trên gói dịch vụ. Độ tin cậy: 0.70

# Ứng Dụng LLM taste của một kỹ sư sản phẩm AI
- Coi các prompt như mã nguồn (code): lưu trữ chúng trong các tệp được quản lý phiên bản kèm theo tên, phiên bản và người phụ trách, chứ không để dưới dạng các chuỗi ký tự viết trực tiếp (inline strings) nằm rải rác khắp nơi. Độ tin cậy: 0.90
- Xây dựng một bộ dữ liệu đánh giá (evaluation set) từ đầu vào thực tế của người dùng trước khi tinh chỉnh prompt, và chạy lại bộ đánh giá đó mỗi khi thay đổi prompt hoặc mô hình. Độ tin cậy: 0.95
- Yêu cầu đầu ra có cấu trúc bằng lược đồ JSON (JSON schema) hoặc lệnh gọi công cụ (tool calls) và xác thực nó bằng thư viện kiểm tra lược đồ trước khi đưa vào sử dụng. Độ tin cậy: 0.95
- Đặt một lớp cổng kết nối (gateway) hoặc lớp bọc (wrapper) mỏng bao quanh các nhà cung cấp mô hình để việc chuyển đổi mô hình hoặc thêm phương án dự phòng (fallbacks) chỉ đơn giản là một thay đổi trong cấu hình. Độ tin cậy: 0.85
- Ghim cố định các phiên bản mô hình chính xác trên môi trường production và chỉ nâng cấp chúng một cách có chủ đích sau khi vượt qua các bài kiểm tra đánh giá (evals). Độ tin cậy: 0.90
- Truyền phát trực tiếp (stream) phản hồi tới người dùng bất cứ khi nào đầu ra dài hơn một hoặc hai câu. Độ tin cậy: 0.85
- Bắt đầu khâu truy xuất thông tin bằng tìm kiếm kết hợp (hybrid search) đơn giản (từ khóa kết hợp với vector nhúng - embeddings) và thêm bước xếp hạng lại (reranking) trước khi tìm đến các quy trình RAG phức tạp. Độ tin cậy: 0.80
- Chia nhỏ tài liệu (chunk) theo cấu trúc tự nhiên của chúng (tiêu đề, các phần) và giữ lại siêu dữ liệu (metadata) về nguồn gốc để câu trả lời có thể trích dẫn lại. Độ tin cậy: 0.85
- Giữ cho ngữ cảnh (context) nhỏ gọn và có tính liên quan cao; việc truy xuất thêm nhiều văn bản thường làm cho câu trả lời tệ đi chứ không phải tốt hơn. Độ tin cậy: 0.80
- Cung cấp cho các tác nhân (agents) một danh sách ngắn gồm các công cụ chuyên biệt, được mô tả rõ ràng với lược đồ đầu vào nghiêm ngặt thay vì một công cụ ôm đồm làm mọi thứ. Độ tin cậy: 0.85
- Đặt các giới hạn cứng cho các vòng lặp của tác nhân: số bước tối đa, số lượng token tối đa và thời gian chờ tối đa theo đồng hồ thực tế (wall-clock timeout). Độ tin cậy: 0.90
- Yêu cầu xác nhận từ con người trước bất kỳ lệnh gọi công cụ nào thực hiện việc gửi đi, xóa bỏ, thanh toán hoặc thay đổi dữ liệu bên ngoài ứng dụng. Độ tin cậy: 0.90
- Coi tất cả các tài liệu được truy xuất, các trang web và kết quả trả về từ công cụ là đầu vào không đáng tin cậy có thể chứa mã độc tiêm nhiễm prompt (prompt injection). Độ tin cậy: 0.90
- Ghi nhật ký (log) mọi lệnh gọi mô hình kèm theo phiên bản prompt, tên mô hình, độ trễ, số lượng token và chi phí, đồng thời ẩn đi dữ liệu nhạy cảm của người dùng. Độ tin cậy: 0.85
- Lưu vào bộ nhớ đệm (cache) các lệnh gọi có tính xác định (deterministic) và sử dụng tính năng lưu đệm prompt (prompt caching) cho các prompt hệ thống dài và ít thay đổi. Độ tin cậy: 0.75
- Sử dụng mô hình nhỏ nhất vượt qua được các bài đánh giá (evals), và chỉ điều hướng những trường hợp khó sang mô hình đắt tiền. Độ tin cậy: 0.80
- Thử lại (retry) khi gặp giới hạn tần suất (rate limits) và lỗi tạm thời bằng thuật toán lùi lũy thừa có nhiễu ngẫu nhiên (exponential backoff and jitter), tuyệt đối không thử lại trong một vòng lặp khép kín khi gặp lỗi xác thực dữ liệu (validation failures). Độ tin cậy: 0.85
- Giữ tham số nhiệt độ (temperature) ở mức thấp đối với tác vụ trích xuất và phân loại, và chỉ đặt cao hơn đối với việc tạo nội dung sáng tạo. Độ tin cậy: 0.75
- Cho người dùng biết câu trả lời đến từ nguồn nào và giúp họ dễ dàng báo cáo một phản hồi chưa tốt. Độ tin cậy: 0.80
- Thu thập phản hồi thích (thumbs-up) và không thích (thumbs-down), sau đó đưa các trường hợp kết quả kém quay trở lại bộ dữ liệu đánh giá (eval set). Độ tin cậy: 0.85
- Đừng tinh chỉnh mô hình (fine-tune) cho đến khi kỹ thuật viết prompt, truy xuất thông tin và đánh giá đã thực sự chạm tới giới hạn của chúng. Độ tin cậy: 0.70

# Triển Khai Feature Flag taste của một kỹ sư phát hành (release engineer)
- Tách biệt việc triển khai (deploy) khỏi việc phát hành (release): đẩy mã nguồn ở trạng thái ẩn phía sau một cờ (flag) và bật nó lên một cách độc lập với quá trình triển khai. Độ tin cậy: 0.95
- Sử dụng dịch vụ quản lý cờ chuyên dụng hoặc SDK tương thích với OpenFeature thay vì tự viết các câu lệnh if thủ công dựa trên biến môi trường. Độ tin cậy: 0.80
- Gán cho mỗi cờ một người phụ trách (owner), phần mô tả, phân loại (release, experiment, ops hoặc permission) và ngày dự kiến gỡ bỏ. Độ tin cậy: 0.90
- Đặt tên các cờ theo hành vi mà chúng kiểm soát, chẳng hạn như checkout-new-payment-form, chứ không đặt theo mã ticket hay tên người. Độ tin cậy: 0.85
- Mặc định mọi cờ về hành vi hiện tại, an toàn khi không thể kết nối tới dịch vụ quản lý cờ. Độ tin cậy: 0.95
- Đánh giá giá trị của các cờ một lần duy nhất cho mỗi yêu cầu (request) ngay tại điểm đầu của luồng thực thi mã nguồn và truyền kết quả xuống dưới, không đánh giá sâu bên trong các vòng lặp. Độ tin cậy: 0.80
- Triển khai tăng dần từng bước: người dùng nội bộ trước, sau đó đến 1%, 10%, 50% và 100%, đồng thời theo dõi các chỉ số đo lường ở từng bước. Độ tin cậy: 0.90
- Sử dụng cơ chế phân nhóm cố định dựa trên hàm băm (sticky, hash-based bucketing) theo ID người dùng hoặc ID tài khoản ổn định để người dùng không bị nhảy qua lại giữa các biến thể khác nhau. Độ tin cậy: 0.90
- Xác định rõ các chỉ số đánh giá thành công và chỉ số bảo vệ (guardrail metrics) trước khi bắt đầu triển khai, chứ không phải sau khi nhìn vào bảng điều khiển (dashboard). Độ tin cậy: 0.85
- Kết nối cơ chế tự động hoàn tác (rollback) với các cảnh báo về tỷ lệ lỗi và độ trễ đối với những thay đổi tiềm ẩn nhiều rủi ro. Độ tin cậy: 0.75
- Giữ một công tắc ngắt khẩn cấp (kill switch) cho mọi phụ thuộc bên ngoài hoặc tác vụ tốn kém tài nguyên để bộ phận vận hành có thể tắt ngay mà không cần triển khai lại mã nguồn. Độ tin cậy: 0.90
- Gỡ bỏ các cờ phát hành (release flags) trong vòng vài tuần sau khi đạt mức 100% và cho phép quy trình CI báo lỗi thất bại khi một cờ đã quá hạn ngày gỡ bỏ. Độ tin cậy: 0.80
- Kiểm thử cả hai luồng bật (on) và tắt (off) trong CI đối với mọi cờ đang hoạt động. Độ tin cậy: 0.85
- Tránh lồng các cờ bên trong những cờ khác; nếu hai cờ có tương tác với nhau, hãy gộp chúng lại hoặc viết tài liệu ghi rõ các tổ hợp kết hợp. Độ tin cậy: 0.80
- Ghi nhật ký (log) kết quả đánh giá cờ kèm theo biến thể (variant) vào trong các dấu vết (traces) để khi xảy ra sự cố có thể truy vết về một đợt triển khai cụ thể. Độ tin cậy: 0.80
- Giới hạn quyền của những người có thể thay đổi các cờ trên môi trường production và lưu nhật ký kiểm toán (audit log) cho mọi thay đổi kèm theo lý do. Độ tin cậy: 0.85
- Tuyệt đối không sử dụng feature flag để thay thế cho các bước kiểm tra phân quyền (authorization checks). Độ tin cậy: 0.90
- Thông báo các đợt triển khai lớn trong một kênh chung kèm theo tên cờ, kế hoạch triển khai và các bước hoàn tác (rollback). Độ tin cậy: 0.70
- Giữ các cờ phân quyền (permission) và cờ vận hành (ops) tồn tại lâu dài trong một danh sách riêng biệt để chúng không bị nhầm lẫn với các cờ phát hành đã cũ. Độ tin cậy: 0.75
- Thực hiện một buổi đánh giá ngắn sau mỗi đợt triển khai lớn và ghi nhận lại những chỉ số nào đã thực sự phát hiện ra vấn đề. Độ tin cậy: 0.65

# Ứng dụng React Native taste của một kỹ sư di động đa nền tảng
- Bắt đầu các ứng dụng mới bằng Expo và quy trình prebuild thay vì một dự án React Native thuần (bare), và chỉ eject khi một mô-đun bản địa (native module) thực sự đòi hỏi điều đó. Độ tin cậy: 0.90
- Viết mọi thứ bằng TypeScript với chế độ nghiêm ngặt (strict mode) được bật, bao gồm cả các tham số điều hướng và các liên kết (bindings) mô-đun bản địa. Độ tin cậy: 0.95
- Sử dụng Expo Router để điều hướng dựa trên tệp và luôn bật định tuyến có kiểu dữ liệu (typed routes) để các liên kết bị hỏng sẽ báo lỗi ngay tại thời điểm biên dịch. Độ tin cậy: 0.80
- Lưu trạng thái máy chủ (server state) trong TanStack Query và giới hạn trạng thái máy khách toàn cục (global client state) trong một kho lưu trữ Zustand nhỏ gọn dành cho phiên đăng nhập và tùy chỉnh cá nhân. Độ tin cậy: 0.85
- Tuyệt đối không lưu trữ token trong AsyncStorage; hãy sử dụng expo-secure-store hoặc Keychain và Keystore cho bất kỳ thông tin nhạy cảm nào. Độ tin cậy: 0.95
- Kết xuất (render) các danh sách dài bằng FlashList hoặc một FlatList đã được tinh chỉnh kỹ với các khóa (keys) ổn định, tuyệt đối không dùng ScrollView kết hợp với hàm map. Độ tin cậy: 0.90
- Chạy các hiệu ứng chuyển động (animations) trên luồng UI bằng Reanimated và xử lý cử chỉ bằng react-native-gesture-handler, thay vì dùng Animated API cũ. Độ tin cậy: 0.85
- Bật Kiến trúc Mới (New Architecture) và Hermes theo mặc định, đồng thời coi những thư viện cản trở việc này là nợ kỹ thuật (tech debt). Độ tin cậy: 0.75
- Duy trì một mô-đun giao diện (theme) duy nhất cho màu sắc, khoảng cách và kiểu chữ, đồng thời hỗ trợ chế độ tối (dark mode) ngay từ màn hình đầu tiên. Độ tin cậy: 0.85
- Tuân thủ các vùng an toàn (safe areas) bằng react-native-safe-area-context thay vì gán cứng khoảng đệm (padding) cho phần tai thỏ (notches). Độ tin cậy: 0.90
- Đặt mã nguồn đặc thù cho từng nền tảng vào các tệp .ios.tsx và .android.tsx thay vì rải rác các câu lệnh kiểm tra Platform.OS. Độ tin cậy: 0.70
- Phát hành các bản vá lỗi JavaScript thông qua EAS Update kèm theo chính sách phiên bản runtime, và sử dụng các bản phát hành trên cửa hàng ứng dụng cho những thay đổi ở tầng native. Độ tin cậy: 0.80
- Dựng (build) và ký số (sign) trong CI bằng EAS Build để không có bản phát hành nào bị phụ thuộc vào một chiếc máy tính cá nhân đơn lẻ. Độ tin cậy: 0.85
- Kiểm thử các thành phần (components) bằng React Native Testing Library và truy vấn theo vai trò (role) cùng văn bản (text), thay vì ưu tiên tìm theo testID trước. Độ tin cậy: 0.80
- Bao phủ các luồng quan trọng từ đầu đến cuối (end-to-end) bằng Maestro hoặc Detox trên các trình giả lập thực tế trong CI. Độ tin cậy: 0.75
- Thêm accessibilityLabel và accessibilityRole vào mọi phần tử có thể chạm (touchable) và giữ kích thước vùng chạm tối thiểu là 44 điểm (points). Độ tin cậy: 0.90
- Xử lý trạng thái ngoại tuyến (offline) như một trạng thái bình thường: hiển thị dữ liệu đã lưu trong bộ nhớ đệm, xếp hàng các thao tác ghi và thử lại khi có kết nối trở lại. Độ tin cậy: 0.80
- Báo cáo các sự cố sập ứng dụng (crashes) và lỗi JavaScript bằng Sentry, bao gồm cả source maps cho mọi bản phát hành. Độ tin cậy: 0.85
- Tối ưu hóa hình ảnh bằng expo-image cùng cơ chế bộ nhớ đệm thay vì dùng thành phần Image mặc định. Độ tin cậy: 0.80
- Đo đạc hiệu năng (profile) bằng React Native DevTools trước khi phỏng đoán các cách khắc phục vấn đề hiệu năng. Độ tin cậy: 0.70
- Chỉ yêu cầu cấp quyền tại đúng thời điểm một tính năng cần đến chúng, kèm theo một màn hình giải thích ngắn gọn trước đó. Độ tin cậy: 0.90

# Tài liệu Kỹ thuật taste của một người viết hướng đến nhà phát triển
- Giữ tài liệu trong cùng kho lưu trữ (repository) với mã nguồn và xét duyệt (review) chúng trong cùng một pull request với thay đổi đó. Độ tin cậy: 0.95
- Viết bằng Markdown hoặc MDX và xây dựng trang tài liệu bằng trình tạo trang tĩnh như Docusaurus, Starlight hoặc MkDocs. Độ tin cậy: 0.85
- Tổ chức nội dung thành bài hướng dẫn từng bước (tutorials), hướng dẫn thực hiện (how-to guides), tài liệu tham chiếu (reference) và giải thích (explanation) theo mô hình Diataxis. Độ tin cậy: 0.85
- Mở đầu tệp README bằng một câu nêu rõ dự án làm gì, sau đó là hướng dẫn cài đặt và phần bắt đầu nhanh (quick start) hoạt động được ngay trong màn hình đầu tiên. Độ tin cậy: 0.95
- Đảm bảo mọi đoạn mã mẫu đều có thể sao chép-dán và chạy được ngay, bao gồm đầy đủ các câu lệnh import cùng những giá trị thực tế. Độ tin cậy: 0.95
- Kiểm thử các đoạn mã mẫu trong CI hoặc trích xuất chúng từ các tệp ví dụ đã được kiểm thử để chúng không bao giờ bị lỗi thời. Độ tin cậy: 0.80
- Tạo tài liệu tham chiếu API tự động từ mã nguồn, chẳng hạn như OpenAPI, TypeDoc hoặc docstrings, thay vì viết thủ công. Độ tin cậy: 0.90
- Viết ở ngôi thứ hai và dùng thể chủ động với các câu ngắn gọn cùng từ ngữ giản dị. Độ tin cậy: 0.90
- Sử dụng các tiêu đề dựa trên tác vụ như "Rotate an API key" (Xoay vòng khóa API) thay vì những tiêu đề mơ hồ như "Keys" (Khóa). Độ tin cậy: 0.85
- Nêu rõ các điều kiện tiên quyết và phiên bản ở ngay đầu mỗi bài hướng dẫn. Độ tin cậy: 0.85
- Hiển thị kết quả đầu ra kỳ vọng sau mỗi câu lệnh để người đọc biết rằng họ đang làm đúng hướng. Độ tin cậy: 0.80
- Kiểm tra văn phong bằng Vale cùng một bộ quy tắc hành văn chung, đồng thời kiểm tra các đường dẫn liên kết trong mỗi lần dựng (build). Độ tin cậy: 0.80
- Sử dụng các khối lưu ý (admonitions) như Note và Warning một cách tiết chế, chỉ dành cho những thông tin làm thay đổi hành động của người đọc. Độ tin cậy: 0.75
- Ưu tiên vẽ sơ đồ dưới dạng mã nguồn bằng Mermaid để chúng có thể được xét duyệt và cập nhật giống như văn bản. Độ tin cậy: 0.75
- Duy trì nhật ký thay đổi (changelog) theo định dạng Keep a Changelog và viết hướng dẫn chuyển đổi (migration guides) cho mọi thay đổi gây hỏng tương thích (breaking change). Độ tin cậy: 0.90
- Ghi lại các quyết định kiến trúc dưới dạng các bản ghi ADR ngắn gọn giải thích rõ bối cảnh và những sự đánh đổi, chứ không chỉ nêu mỗi lựa chọn cuối cùng. Độ tin cậy: 0.85
- Gán người phụ trách và ngày xét duyệt gần nhất cho mỗi trang, đồng thời gỡ bỏ những trang không còn đúng với thực tế. Độ tin cậy: 0.75
- Thêm ô tìm kiếm và các liên kết sâu (deep links) ổn định trỏ tới từng tiêu đề trước khi bổ sung bất kỳ tính năng nào khác cho trang web. Độ tin cậy: 0.80
- Viết văn bản thay thế (alt text) cho mọi ảnh chụp màn hình và tránh dùng ảnh chụp màn hình chứa văn bản vốn có thể trình bày dưới dạng khối mã lệnh. Độ tin cậy: 0.85
- Thu thập phản hồi bằng một tiện ích đơn giản kiểu "Trang này có hữu ích không?" và xem xét kết quả định kỳ hàng tháng. Độ tin cậy: 0.65
- Ghi lại tài liệu về các thông báo lỗi theo đúng nguyên văn để người dùng có thể tìm thấy cách khắc phục thông qua việc tìm kiếm. Độ tin cậy: 0.85

# Thử nghiệm Học máy taste của một kỹ sư ML ứng dụng
- Viết chỉ số đánh giá và một mô hình cơ sở (baseline) đơn giản trước khi huấn luyện bất kỳ mô hình thực tế nào. Độ tin cậy: 0.95
- Chia dữ liệu theo thời gian hoặc theo thực thể khi có khả năng xảy ra rò rỉ dữ liệu (data leakage), tuyệt đối không chia ngẫu nhiên theo mặc định. Độ tin cậy: 0.90
- Đóng băng tập kiểm thử (test set) từ sớm và chỉ xem nó khi đưa ra các quyết định cuối cùng, đồng thời sử dụng một tập xác thực (validation set) riêng biệt để tinh chỉnh. Độ tin cậy: 0.95
- Theo dõi mọi lần chạy bằng MLflow hoặc Weights & Biases, ghi nhật ký (log) cấu hình, các chỉ số, phiên bản mã nguồn và phiên bản tập dữ liệu. Độ tin cậy: 0.90
- Lưu cấu hình thử nghiệm trong các tệp YAML được quản lý phiên bản, nạp bằng Hydra hoặc Pydantic, thay vì dùng các hằng số gán cứng (hardcoded). Độ tin cậy: 0.80
- Thiết lập và ghi lại các hạt giống ngẫu nhiên (random seeds) cho Python, NumPy cùng framework đang dùng, đồng thời báo cáo phương sai qua nhiều seed khác nhau. Độ tin cậy: 0.85
- Quản lý phiên bản các tập dữ liệu bằng DVC hoặc các đường dẫn lưu trữ đối tượng bất biến (immutable object storage) để mọi kết quả đều có thể tái lập. Độ tin cậy: 0.80
- Tạo mẫu thử nghiệm (prototype) trong các notebook nhưng hãy chuyển mã nguồn có thể tái sử dụng vào một gói Python đã được kiểm thử ngay khi nó được dùng đến lần thứ hai. Độ tin cậy: 0.85
- Cố định các thư viện phụ thuộc bằng tệp khóa (lock file) và ghi nhận lại phiên bản CUDA cùng trình điều khiển (driver) trong mỗi lần chạy. Độ tin cậy: 0.75
- Kiểm tra thủ công các mẫu dữ liệu thô và các lỗi gán nhãn trước khi tin tưởng vào bất kỳ chỉ số tổng hợp nào. Độ tin cậy: 0.90
- Ưu tiên các mô hình cây tăng cường độ dốc (gradient boosted trees) cho dữ liệu dạng bảng và chỉ tìm đến học sâu (deep learning) khi chúng tỏ ra kém hiệu quả rõ rệt. Độ tin cậy: 0.80
- Sử dụng PyTorch với một vòng lặp huấn luyện gọn nhẹ hoặc dùng Lightning thay vì các framework tùy chỉnh cồng kềnh. Độ tin cậy: 0.70
- Báo cáo các chỉ số theo từng phân khúc (slice) chẳng hạn như khu vực, thiết bị hoặc lớp (class), chứ không chỉ dừng lại ở một con số tổng thể duy nhất. Độ tin cậy: 0.90
- Hiệu chuẩn (calibrate) các xác suất dự đoán khi mã nguồn ở khâu sau đưa ra quyết định dựa trên ngưỡng (threshold). Độ tin cậy: 0.75
- Tinh chỉnh siêu tham số (hyperparameters) bằng Optuna hoặc tìm kiếm ngẫu nhiên (random search) đơn giản trong phạm vi ngân sách tính toán cố định. Độ tin cậy: 0.75
- Viết kiểm thử đơn vị (unit tests) cho các bước biến đổi đặc trưng (feature transforms) và bộ nạp dữ liệu (data loaders), đồng thời kiểm tra xác nhận (assert) kích thước (shapes) cùng kiểu dữ liệu (dtypes) kỳ vọng. Độ tin cậy: 0.85
- Xác thực dữ liệu đầu vào bằng các bước kiểm tra lược đồ (schema) như Pandera hoặc Great Expectations trước khi huấn luyện. Độ tin cậy: 0.80
- Lưu mô hình cùng với luồng tiền xử lý (preprocessing pipeline) của nó thành một tạo phẩm (artifact) duy nhất để quá trình huấn luyện và phục vụ (serving) không bị lệch nhau. Độ tin cậy: 0.90
- So sánh mô hình mới với mô hình đang chạy trên môi trường production ở chế độ ngoại tuyến (offline) và sau đó thông qua triển khai chạy ngầm (shadow) hoặc thử nghiệm A/B. Độ tin cậy: 0.85
- Giám sát sự trôi dạt đặc trưng (feature drift) và phân phối dự đoán sau khi ra mắt, đồng thời cảnh báo khi có sự dịch chuyển lớn. Độ tin cậy: 0.80
- Viết một ghi chú thử nghiệm ngắn cho mỗi lần chạy quan trọng, nêu rõ giả thuyết, kết quả và bước tiếp theo. Độ tin cậy: 0.85
- Xóa hoặc lưu trữ các nhánh công việc thất bại thay vì để lại hàng tá các notebook làm dở dang. Độ tin cậy: 0.65

# Tác vụ Nền (Background Jobs) taste của một kỹ sư độ tin cậy backend
- Thiết kế mọi tác vụ (job) có tính lũy đẳng (idempotent) để việc thử lại (retry) hoặc gửi trùng lặp không bao giờ trừ tiền thẻ hay gửi email hai lần. Confidence: 0.95
- Chỉ truyền các ID trong phần dữ liệu (payload) của tác vụ và tải dữ liệu mới nhất bên trong worker thay vì tuần tự hóa (serialize) toàn bộ bản ghi. Confidence: 0.90
- Đưa các tác vụ vào hàng đợi (enqueue) trong cùng một giao dịch cơ sở dữ liệu (database transaction) với thao tác ghi đã kích hoạt chúng, bằng cách sử dụng bảng hộp thư đi (outbox table) hoặc hàng đợi dựa trên Postgres. Confidence: 0.85
- Ưu tiên sử dụng một hệ thống hàng đợi đơn giản, ổn định và được hỗ trợ tốt như Sidekiq, BullMQ, Celery hoặc hàng đợi Postgres như Graphile Worker thay vì tự xây dựng mới. Confidence: 0.80
- Thử lại với thời gian chờ tăng theo cấp số nhân (exponential backoff) kèm độ lệch ngẫu nhiên (jitter), và giới hạn số lần thử để các tác vụ lỗi độc hại (poison jobs) được chuyển vào hàng đợi thư chết (dead letter queue). Confidence: 0.95
- Phân loại lỗi thành lỗi có thể thử lại (retryable) hoặc lỗi vĩnh viễn (permanent), và cho dừng ngay lập tức các lỗi vĩnh viễn thay vì lãng phí số lần thử lại. Confidence: 0.85
- Thiết lập thời gian chờ tối đa (timeout) rõ ràng cho mọi tác vụ và cho mọi lệnh gọi mạng mà tác vụ đó thực hiện. Confidence: 0.90
- Giữ cho các tác vụ nhỏ gọn và chạy nhanh, đồng thời chia nhỏ các công việc xử lý hàng loạt (batch work) kéo dài thành từng phần (chunks) có thể tiếp tục chạy lại từ điểm đánh dấu (checkpoint). Confidence: 0.85
- Sử dụng các hàng đợi riêng biệt cho công việc nhạy cảm với độ trễ và công việc xử lý số lượng lớn (bulk work) để tác vụ nạp bù dữ liệu (backfill) không bao giờ làm chậm email đặt lại mật khẩu. Confidence: 0.90
- Giới hạn tần suất (rate limit) các tác vụ gọi API bên thứ ba theo từng nhà cung cấp dịch vụ, chứ không phải theo từng tiến trình worker. Confidence: 0.80
- Sử dụng khóa tác vụ duy nhất (unique job keys) hoặc cơ chế khóa (locks) để ngăn cùng một tác vụ định kỳ chạy hai lần cùng lúc. Confidence: 0.85
- Chạy các lịch trình kiểu cron từ một bộ lập lịch (scheduler) duy nhất có cơ chế bầu chọn nút dẫn đầu (leader election), tuyệt đối không chạy từ mọi thực thể (instance) của ứng dụng. Confidence: 0.80
- Đánh phiên bản (version) cho dữ liệu đầu vào (payload) của tác vụ và đảm bảo các worker vẫn đọc được phiên bản cũ trong quá trình triển khai (deploy) bản mới. Confidence: 0.80
- Xử lý tín hiệu SIGTERM một cách êm đẹp (gracefully): ngừng nhận tác vụ mới, hoàn tất hoặc đưa lại tác vụ hiện tại vào hàng đợi, sau đó mới thoát. Confidence: 0.90
- Ghi nhận mã tác vụ (job ID), số thứ tự lần thử (attempt number) và mã tương quan (correlation ID) trên mọi dòng nhật ký (log) phát sinh từ một tác vụ. Confidence: 0.85
- Cảnh báo dựa trên độ sâu của hàng đợi, tuổi của tác vụ cũ nhất và mức tăng trưởng của hàng đợi thư chết (dead letter queue), chứ không chỉ cảnh báo khi worker bị sập. Confidence: 0.90
- Phân công người phụ trách rõ ràng cho hàng đợi thư chết và có tài liệu hướng dẫn lệnh chạy lại (replay command). Confidence: 0.75
- Kiểm thử các tác vụ bằng cách gọi trực tiếp hàm xử lý (handler) trong kiểm thử đơn vị (unit tests) và chạy một bài kiểm thử đầu-cuối (end-to-end) thông qua hàng đợi thật trong hệ thống CI. Confidence: 0.80
- Tránh nối chuỗi quá nhiều tác vụ thành các luồng công việc ngầm phức tạp; hãy sử dụng một công cụ điều phối luồng công việc (workflow engine) như Temporal khi các bước cần được điều phối chặt chẽ. Confidence: 0.70
- Lưu trữ kết quả tác vụ và các dấu hiệu đánh dấu hiệu ứng phụ (side-effect markers) trong cơ sở dữ liệu, chứ không chỉ lưu trong hệ thống lưu trữ của hàng đợi. Confidence: 0.75

# Ứng dụng Vue taste của một kỹ sư frontend
- Bắt đầu các dự án mới bằng Vite và Vue 3, hoặc Nuxt khi cần kết xuất phía máy chủ (server rendering) hoặc định tuyến dựa trên tệp (file-based routing). Confidence: 0.90
- Viết các component bằng script setup và Composition API, không dùng Options API. Confidence: 0.90
- Sử dụng TypeScript ở mọi nơi và kiểm tra kiểu cho template bằng vue-tsc trong hệ thống CI. Confidence: 0.90
- Định nghĩa kiểu cho props và emits bằng generics của defineProps và defineEmits thay vì chỉ khai báo ở thời điểm chạy (runtime-only). Confidence: 0.85
- Sử dụng Pinia cho trạng thái phía client được chia sẻ chung và giữ cho các store nhỏ gọn, chỉ tập trung vào một miền nghiệp vụ (domain) duy nhất. Confidence: 0.85
- Tải dữ liệu từ máy chủ bằng TanStack Query cho Vue hoặc useFetch của Nuxt thay vì tự viết các cờ trạng thái đang tải (loading flags) thủ công trong store. Confidence: 0.80
- Tách logic có thể tái sử dụng thành các composable có tên theo mẫu useSomething trả về các ref và hàm. Confidence: 0.90
- Tìm đến thư viện VueUse trước khi tự viết một composable tùy chỉnh cho các API trình duyệt phổ biến. Confidence: 0.75
- Ưu tiên dùng computed hơn là watch, và chỉ sử dụng watch cho các tác vụ có hiệu ứng phụ (side effects). Confidence: 0.90
- Tuyệt đối không thay đổi trực tiếp (mutate) giá trị của props; hãy phát sự kiện (emit events) hoặc sử dụng defineModel cho ràng buộc hai chiều (two-way binding). Confidence: 0.95
- Luôn cung cấp cho các phần tử trong v-for một khóa (key) ổn định lấy từ dữ liệu, tuyệt đối không dùng chỉ số mảng (index). Confidence: 0.90
- Không bao giờ kết hợp v-if và v-for trên cùng một phần tử. Confidence: 0.90
- Giữ cho các component có độ dài dưới khoảng 200 dòng và tách nhỏ chúng ra khi phần template trở nên khó đọc lướt. Confidence: 0.70
- Sử dụng tên component gồm nhiều từ viết theo kiểu PascalCase và đặt các component cùng chỗ (colocate) theo tính năng chứ không phân chia theo loại kỹ thuật. Confidence: 0.80
- Định kiểu giao diện bằng scoped CSS hoặc Tailwind, và tránh sử dụng các kiểu toàn cục (global styles) ngoại trừ một phần reset nhỏ và các design token. Confidence: 0.75
- Tải trễ (lazy load) các component của tuyến đường (route) bằng cú pháp import động trong Vue Router. Confidence: 0.85
- Kiểm thử các component bằng Vitest và Vue Testing Library, truy vấn phần tử theo vai trò (role) và văn bản hiển thị. Confidence: 0.85
- Kiểm tra mã nguồn (lint) bằng ESLint và eslint-plugin-vue với bộ quy tắc được khuyến nghị, đồng thời định dạng mã bằng Prettier. Confidence: 0.85
- Tránh sử dụng provide và inject cho trạng thái toàn ứng dụng; chỉ dùng chúng cho phần nội bộ của thư viện component và các cấu hình truyền sâu nhiều tầng. Confidence: 0.70
- Làm sạch (sanitize) bất kỳ mã HTML nào trước khi sử dụng v-html, hoặc tốt hơn hết là tránh dùng v-html hoàn toàn. Confidence: 0.95

# Ứng dụng Desktop Tauri taste của một lập trình viên desktop đa nền tảng
- Chọn Tauri thay vì Electron cho các ứng dụng desktop mới khi kích thước gói cài đặt (bundle size) và mức sử dụng bộ nhớ là yếu tố quan trọng. Confidence: 0.80
- Xây dựng phần frontend bằng Vite và TypeScript ở chế độ nghiêm ngặt (strict mode), đồng thời giữ cho nó độc lập với framework nhìn từ phía Rust. Confidence: 0.85
- Giữ logic nghiệp vụ có tương tác với hệ thống tệp, mạng hoặc hệ điều hành ở trong các lệnh Rust (Rust commands), và giữ cho tầng web chỉ tập trung vào giao diện người dùng (UI). Confidence: 0.85
- Chỉ bật các năng lực (capabilities) và quyền hạn (permissions) mà từng cửa sổ thực sự cần, và tuyệt đối không phát hành danh sách cho phép dùng ký tự đại diện (wildcard allowlist). Confidence: 0.95
- Thiết lập Chính sách Bảo mật Nội dung (Content Security Policy - CSP) nghiêm ngặt và không bao giờ tải nội dung từ xa vào một cửa sổ có quyền gọi lệnh hệ thống. Confidence: 0.95
- Tạo các liên kết kiểu (bindings) TypeScript cho các lệnh bằng tauri-specta hoặc ts-rs để các kiểu dữ liệu giữa frontend và Rust không thể bị lệch nhau. Confidence: 0.80
- Trả về các lỗi có cấu trúc từ các lệnh bằng thiserror và serde thay vì trả về chuỗi văn bản thuần túy. Confidence: 0.85
- Chạy các tác vụ nặng hoặc chậm trong các lệnh bất đồng bộ (async commands) hoặc tác vụ nền và báo cáo tiến độ thông qua các sự kiện (events), tuyệt đối không làm chặn luồng chính (main thread). Confidence: 0.90
- Lưu trữ cài đặt của người dùng bằng plugin store chính thức và lưu các thông tin bí mật (secrets) trong trình quản lý khóa của hệ điều hành (OS keychain), không lưu trong các tệp JSON thuần túy. Confidence: 0.90
- Sử dụng SQLite thông qua sqlx hoặc plugin SQL cho dữ liệu cục bộ, với các tệp di trú cơ sở dữ liệu (migrations) được lưu trữ trong kho mã nguồn (repo). Confidence: 0.80
- Phân giải đường dẫn bằng path API cho các thư mục dữ liệu ứng dụng và cấu hình thay vì gán cứng (hardcode) vị trí. Confidence: 0.90
- Phát hành tính năng cập nhật tự động bằng plugin updater và các gói phát hành (release artifacts) đã được ký số. Confidence: 0.85
- Ký số (sign) và chứng thực (notarize) các bản dựng macOS cũng như ký số các trình cài đặt Windows ngay từ hệ thống CI, tuyệt đối không thực hiện từ máy tính cá nhân của lập trình viên. Confidence: 0.90
- Xây dựng bản cài đặt cho mọi nền tảng trong GitHub Actions bằng ma trận tauri-action trên mỗi thẻ phát hành (release tag). Confidence: 0.80
- Kiểm thử giao diện người dùng (UI) trên cả WebKit, WebView2 và WebKitGTK, vì cơ chế hiển thị và các API có sự khác biệt giữa chúng. Confidence: 0.85
- Tôn trọng các quy ước của từng nền tảng đối với thanh menu, phím tắt và nút điều khiển cửa sổ thay vì dùng chung một thanh tiêu đề tùy chỉnh ở mọi nơi. Confidence: 0.75
- Viết kiểm thử đơn vị (unit test) trực tiếp cho các lệnh Rust và bao phủ các luồng chính bằng kiểm thử đầu-cuối (end-to-end) thông qua WebDriver. Confidence: 0.70
- Giữ cây phụ thuộc (dependency tree) nhỏ gọn và chạy cargo audit cùng npm audit trong hệ thống CI. Confidence: 0.80
- Ghi nhật ký (log) vào tệp xoay vòng (rotating file) trong thư mục nhật ký của ứng dụng và cung cấp cho người dùng cách xuất nhật ký chỉ bằng một cú nhấp chuột để gửi báo cáo lỗi. Confidence: 0.75

# Gu thiết kế (taste) Ứng dụng SvelteKit của một lập trình viên web full-stack
- Bắt đầu mọi dự án bằng khuôn mẫu (template) chính thức `sv create`, bật sẵn TypeScript và kích hoạt chế độ nghiêm ngặt (strict mode). Độ tin cậy: 0.90
- Sử dụng Svelte 5 runes (`$state`, `$derived`, `$effect`, `$props`) cho tất cả các component mới thay vì các câu lệnh phản ứng (reactive statements) kiểu cũ. Độ tin cậy: 0.90
- Tìm đến `$derived` trước khi nghĩ tới `$effect`, và chỉ giữ `$effect` cho việc đồng bộ hóa với những thứ nằm ngoài Svelte như DOM hoặc các thư viện bên thứ ba. Độ tin cậy: 0.90
- Tải dữ liệu trong `+page.server.ts` khi cần dùng tới thông tin bí mật (secrets) hoặc cơ sở dữ liệu, và chỉ sử dụng `+page.ts` dùng chung (universal) cho các lệnh gọi lấy dữ liệu công khai. Độ tin cậy: 0.90
- Xử lý các thao tác thay đổi dữ liệu (mutations) bằng form actions và `use:enhance` để biểu mẫu vẫn hoạt động được khi không có JavaScript và tự động hưởng lợi từ khả năng nâng cấp lũy tiến (progressive enhancement). Độ tin cậy: 0.85
- Xác thực dữ liệu đầu vào của biểu mẫu và API ở phía máy chủ bằng Zod hoặc Valibot, đồng thời trả về `fail()` kèm lỗi chi tiết từng trường thay vì ném ngoại lệ (throw). Độ tin cậy: 0.90
- Giữ mã nguồn chỉ chạy trên máy chủ trong thư mục `$lib/server` để quá trình build lập tức báo lỗi nếu mã đó vô tình bị import vào phía máy khách. Độ tin cậy: 0.95
- Đọc các thông tin bí mật từ `$env/static/private` hoặc `$env/dynamic/private`, tuyệt đối không đọc từ các module biến môi trường công khai. Độ tin cậy: 0.95
- Đặt logic xác thực và tra cứu phiên làm việc (session) trong `hooks.server.ts` và cung cấp thông tin người dùng thông qua `event.locals`. Độ tin cậy: 0.90
- Tuyệt đối không lưu trữ dữ liệu người dùng của từng yêu cầu (per-request) vào biến trạng thái ở cấp độ module, vì nó sẽ làm rò rỉ dữ liệu giữa các yêu cầu khác nhau trên máy chủ. Độ tin cậy: 0.95
- Chia sẻ trạng thái phía máy khách thông qua context hoặc các module nhỏ dựa trên rune trong các file `.svelte.ts`, thay vì dùng một store toàn cục cho mọi thứ. Độ tin cậy: 0.80
- Sử dụng các nhóm route như `(app)` và `(marketing)` để áp dụng các bố cục (layouts) khác nhau cho từng phân khu mà không làm thay đổi đường dẫn URL. Độ tin cậy: 0.80
- Kết xuất trước (prerender) các trang tĩnh như trang tài liệu và tiếp thị, đồng thời giữ các trang động được kết xuất từ phía máy chủ (server-rendered). Độ tin cậy: 0.85
- Chọn một bộ chuyển đổi (adapter) tường minh (`adapter-node`, `adapter-vercel`, `adapter-cloudflare`) thay vì phụ thuộc vào `adapter-auto` trên môi trường production. Độ tin cậy: 0.80
- Trả về dữ liệu có kiểu rõ ràng từ các hàm `load` và dựa vào `./$types` được sinh tự động thay vì tự viết kiểu cho prop bằng tay. Độ tin cậy: 0.90
- Sử dụng các trang `+error.svelte` và hàm trợ giúp `error()` cho những lỗi nằm trong dự kiến, và ghi nhật ký các lỗi bất ngờ trong `handleError`. Độ tin cậy: 0.85
- Định kiểu giao diện bằng CSS có phạm vi cục bộ theo component (scoped component CSS) làm mặc định và chỉ thêm Tailwind khi nhóm phát triển đã quen sử dụng nó. Độ tin cậy: 0.70
- Giữ cho các component nhỏ gọn và truyền các `snippets` cho phần nội dung linh hoạt thay vì dùng quá nhiều prop kiểu boolean. Độ tin cậy: 0.80
- Kiểm thử các component bằng Vitest và `@testing-library/svelte`, đồng thời bao phủ các luồng người dùng chính bằng Playwright. Độ tin cậy: 0.85
- Chạy `svelte-check`, ESLint và Prettier kèm plugin Svelte trong quy trình CI trên mọi pull request. Độ tin cậy: 0.85

# Gu thiết kế (taste) Hàm Serverless của một kỹ sư backend đám mây
- Giữ cho mỗi hàm nhỏ gọn và tập trung vào một tác nhân kích hoạt (trigger) duy nhất, nhưng hãy gom các route HTTP có liên quan mật thiết vào chung một handler để cắt giảm tình trạng khởi động lạnh (cold starts). Độ tin cậy: 0.80
- Khởi tạo các SDK client và nhóm kết nối cơ sở dữ liệu (database pools) bên ngoài hàm handler để các lần gọi ấm (warm invocations) có thể tái sử dụng chúng. Độ tin cậy: 0.95
- Sử dụng bộ quản lý nhóm kết nối (connection pooler) hoặc trình điều khiển cơ sở dữ liệu dựa trên HTTP, vì hàng nghìn hàm chạy đồng thời sẽ làm cạn kiệt các kết nối Postgres trực tiếp. Độ tin cậy: 0.90
- Thiết lập thời gian chờ (timeout) và dung lượng bộ nhớ tường minh cho từng hàm thay vì chấp nhận các giá trị mặc định của nền tảng. Độ tin cậy: 0.85
- Giữ kích thước gói mã (bundle) nhỏ gọn bằng kỹ thuật loại bỏ mã thừa (tree-shaking) và nạp trễ (lazy imports), đồng thời đo lường thời gian khởi động lạnh sau mỗi thay đổi thư viện phụ thuộc lớn. Độ tin cậy: 0.85
- Đảm bảo mọi hàm xử lý sự kiện đều có tính lũy đẳng (idempotent), bởi vì các hàng đợi và nguồn phát sự kiện luôn phân phối theo cơ chế ít nhất một lần (at-least-once). Độ tin cậy: 0.95
- Chuyển các tác vụ chạy chậm hoặc cần thử lại sang hàng đợi (queue) và trả kết quả về nhanh chóng từ các hàm HTTP. Độ tin cậy: 0.90
- Đẩy các sự kiện bất đồng bộ bị lỗi vào hàng đợi thư chết (dead letter queue - DLQ) kèm theo cảnh báo dựa trên độ sâu (số lượng tồn đọng) của hàng đợi đó. Độ tin cậy: 0.90
- Định nghĩa các hàm, quyền hạn và tác nhân kích hoạt dưới dạng mã (Infrastructure as Code) bằng SST, Serverless Framework, SAM hoặc Terraform, tuyệt đối không bấm chọn thủ công trên giao diện điều khiển (console). Độ tin cậy: 0.90
- Cấp cho mỗi hàm một vai trò (role) riêng theo nguyên tắc đặc quyền tối thiểu, giới hạn phạm vi chính xác vào những tài nguyên mà hàm đó chạm tới. Độ tin cậy: 0.95
- Nạp các thông tin bí mật (secrets) từ trình quản lý bí mật (secrets manager) hoặc biến môi trường được mã hóa của nền tảng, tuyệt đối không lấy từ kho mã nguồn (repo). Độ tin cậy: 0.95
- Ghi nhật ký (logs) định dạng JSON có cấu trúc kèm theo request ID và correlation ID trên mọi dòng. Độ tin cậy: 0.90
- Truy vết (trace) các yêu cầu xuyên qua các hàm và hàng đợi bằng OpenTelemetry hoặc công cụ truy vết có sẵn của nền tảng. Độ tin cậy: 0.80
- Giữ logic nghiệp vụ trong các module thuần túy và chỉ để hàm handler đóng vai trò một lớp chuyển đổi (adapter) mỏng, nhờ đó có thể kiểm thử đơn vị (unit test) mà không cần tới môi trường đám mây. Độ tin cậy: 0.90
- Chạy kiểm thử tích hợp (integration tests) trên một môi trường triển khai (stage) thực tế cho mỗi pull request thay vì đặt niềm tin vào các trình giả lập cục bộ. Độ tin cậy: 0.80
- Thiết lập mức độ đồng thời dành riêng hoặc tối đa (reserved or maximum concurrency) trên các hàm gọi tới những dịch vụ hạ nguồn mỏng manh, dễ quá tải. Độ tin cậy: 0.85
- Chỉ sử dụng mức độ đồng thời được cấp phát sẵn (provisioned concurrency) cho các luồng xử lý nhạy cảm về độ trễ nơi mà quá trình khởi động lạnh đã được đo đạc và chứng minh là gây ảnh hưởng xấu. Độ tin cậy: 0.75
- Ưu tiên môi trường thực thi arm64 khi các thư viện phụ thuộc hỗ trợ để đạt tỷ lệ hiệu năng trên giá thành tốt hơn. Độ tin cậy: 0.70
- Thiết lập cảnh báo hóa đơn thanh toán và bảng theo dõi chi phí theo từng hàm trước khi ra mắt, chứ không phải đợi đến sau tờ hóa đơn gây sốc đầu tiên. Độ tin cậy: 0.85
- Tránh nối chuỗi các hàm gọi nhau một cách đồng bộ; thay vào đó hãy dùng sự kiện hoặc một bộ điều phối luồng công việc (workflow engine) như Step Functions. Độ tin cậy: 0.85
- Lựa chọn container hoặc các dịch vụ chạy liên tục dài hạn cho các khối lượng công việc có thông lượng cao và ổn định, nơi mà mô hình serverless trở nên đắt đỏ hơn. Độ tin cậy: 0.75

# Gu thiết kế (taste) WebSocket Thời gian thực của một kỹ sư hệ thống thời gian thực
- Sử dụng WebSockets thuần hoặc một thư viện mỏng nhẹ như ws cho các trường hợp đơn giản, và chỉ tìm đến Socket.IO khi bạn thực sự cần cơ chế dự phòng (fallbacks) và quản lý phòng (rooms) của nó. Độ tin cậy: 0.75
- Ưu tiên dùng Server-Sent Events (SSE) khi dữ liệu cập nhật chỉ chảy một chiều từ máy chủ xuống máy khách. Độ tin cậy: 0.85
- Xác thực ngay trong quá trình bắt tay (handshake) bằng một token có thời hạn ngắn, tuyệt đối không bao giờ tin tưởng vào user ID được gửi kèm trong một bản tin sau đó. Độ tin cậy: 0.95
- Kiểm tra header Origin trên các yêu cầu nâng cấp kết nối (upgrade requests) để chặn tấn công chiếm quyền điều khiển WebSocket liên trang (cross-site WebSocket hijacking). Độ tin cậy: 0.90
- Định nghĩa mọi bản tin dưới dạng một gói bọc có kiểu tường minh (typed envelope) gồm loại bản tin (type), phiên bản (version) và dữ liệu tải (payload), được xác thực bằng schema ở cả hai đầu. Độ tin cậy: 0.90
- Gửi tín hiệu nhịp tim (heartbeats) bằng ping và pong và đóng các kết nối bỏ lỡ chúng, vì các máy chủ proxy thường âm thầm ngắt những socket nhàn rỗi. Độ tin cậy: 0.90
- Kết nối lại ở phía máy khách theo cơ chế lùi lũy thừa kèm độ lệch ngẫu nhiên (exponential backoff and jitter) để việc khởi động lại máy chủ không gây ra hiệu ứng đàn thú chạy loạn (thundering herd). Độ tin cậy: 0.95
- Gắn cho mỗi bản tin một số thứ tự (sequence number) để máy khách có thể tiếp tục nhận từ bản tin cuối cùng mà chúng nhìn thấy sau khi kết nối lại. Độ tin cậy: 0.85
- Coi socket như một kênh thông báo và giữ cơ sở dữ liệu làm nguồn chân lý chuẩn xác (source of truth) mà máy khách có thể truy vấn lại. Độ tin cậy: 0.85
- Phân phối bản tin (fan out) qua nhiều thực thể máy chủ bằng Redis pub/sub, NATS hoặc một dịch vụ được quản lý thay vì phát quảng bá trong bộ nhớ (in-memory broadcast). Độ tin cậy: 0.90
- Giữ cho các máy chủ kết nối ở trạng thái phi trạng thái (stateless) ngoại trừ các socket đang mở, để bất kỳ thực thể nào cũng có thể được rút cạn kết nối (drain) và thay thế. Độ tin cậy: 0.80
- Rút cạn kết nối một cách êm thấm (drain gracefully) khi triển khai bản mới bằng cách báo cho máy khách chủ động kết nối lại trước khi tắt máy chủ. Độ tin cậy: 0.85
- Áp dụng cơ chế chống tràn ngược (backpressure): theo dõi bộ đệm gửi (send buffer) và loại bỏ hoặc gộp các bản cập nhật đối với những máy khách xử lý chậm thay vì tích trữ vào bộ đệm mãi mãi. Độ tin cậy: 0.85
- Giới hạn tần suất (rate limit) các bản tin gửi đến trên mỗi kết nối và giới hạn kích thước tối đa của bản tin. Độ tin cậy: 0.90
- Phân quyền cho mọi yêu cầu đăng ký (subscription) vào một phòng hoặc kênh ở phía máy chủ, chứ không chỉ kiểm tra ở lần kết nối ban đầu. Độ tin cậy: 0.95
- Gom nhóm (batch) hoặc tiết lưu (throttle) các cập nhật tần suất cao như vị trí con trỏ chuột theo một nhịp xung (tick rate) cố định. Độ tin cậy: 0.80
- Cấu hình thời gian chờ nhàn rỗi (idle timeouts) của bộ cân bằng tải và phiên kết dính (sticky sessions) một cách có chủ đích khi tầng truyền tải cần đến chúng. Độ tin cậy: 0.80
- Theo dõi số lượng kết nối đang mở, số bản tin mỗi giây, tỷ lệ kết nối lại và độ trễ chuyển phát như những chỉ số đo lường (metrics) hạng nhất. Độ tin cậy: 0.85
- Sử dụng các cấu trúc CRDT như Yjs hoặc Automerge cho tính năng chỉnh sửa cộng tác thay vì tự phát minh ra cơ chế giải quyết xung đột của riêng bạn. Độ tin cậy: 0.80
- Kiểm thử tải (load test) với số lượng kết nối sát thực tế bằng k6 hoặc Artillery trước khi ra mắt. Độ tin cậy: 0.80

Tôi muốn bạn đóng vai một kỹ thuật viên điều khiển cấp cao đang đọc một chương trình PLC không phải do tôi viết. Nền tảng: any IEC 61131-3 platform. Ngôn ngữ lập trình: Ladder. Dưới đây là mã chương trình dạng văn bản, theo sau là danh sách I/O hoặc chú thích tag nếu tôi có.

Hãy giải thích chương trình theo từng bậc thang (rung) hoặc từng nhánh mạng (network) trong một bảng:
Bậc thang (Rung) | Điều kiện bằng ngôn ngữ thông thường | Chức năng thực hiện | Ghi chú về thứ tự quét (scan-order) hoặc chốt giữ (latch) | Các giả định

Quy tắc:
1. Tiếp điểm thường mở hoặc thường đóng trong chương trình chỉ kiểm tra trạng thái một bit trong bộ nhớ. Nó không nói lên điều gì về cách đấu dây của thiết bị ngoài hiện trường. Chỉ lấy thông tin đấu dây hiện trường từ danh sách I/O của tôi; nếu không có trong danh sách, hãy ghi UNKNOWN.
2. Các bậc thang thực thi từ trên xuống dưới và lệnh ghi cuối cùng trong chu kỳ quét sẽ quyết định giá trị. Hãy liệt kê mọi tag bị ghi ở nhiều hơn một nơi, kèm theo số thứ tự bậc thang.
3. Với mỗi cuộn dây chốt (latch / set coil), hãy nêu tên lệnh nhả chốt (unlatch / reset) dùng để xóa nó, hoặc ghi NONE nếu không có.
4. Với mỗi tiếp điểm xung một chu kỳ (one-shot) hoặc tiếp điểm sườn xung (edge contact), hãy nêu tên bit nhớ lưu trữ của nó và cho biết bit đó có bị sử dụng ở nơi nào khác không.
5. Nếu có điều gì phụ thuộc vào phần mã hoặc cài đặt mà tôi chưa dán vào (một chương trình con khác, màn hình HMI, đối tác truyền thông), hãy ghi QUESTION thay vì đoán mò.
Không đề xuất thay đổi mã. Đây là bước đọc hiểu chương trình, không phải đánh giá sửa đổi.

=== CODE ===
Paste the rungs as text

=== I/O LIST / TAG COMMENTS ===
Paste the I/O list or write NONE

Tôi muốn bạn đóng vai một chuyên gia xử lý sự cố điều khiển. Người vận hành đã báo cáo triệu chứng sau: "Conveyor 3 starts, then drops out after a few seconds". Nền tảng: Platform and version. Tôi dán dưới đây mã nguồn của các khối (blocks), chương trình con (routines) hoặc POU có liên quan, thứ tự gọi từ tác vụ chính (main task), và danh sách I/O.

Hãy bắt đầu từ ngõ ra hoặc cờ lỗi đang hoạt động bất thường, the motor run output, và truy ngược nó qua từng khối chương trình. Hãy trình bày dưới dạng bảng:
Bước nhảy (Hop) | Khối / chương trình con / nhánh mạng / dòng | Điều kiện chính xác tại bước này | Tag tôi cần theo dõi trực tuyến (watch online) để xác nhận

Sau đó:
1. Liệt kê mọi lệnh ghi vào từng tag trong chuỗi liên kết đó ở tất cả các khối, bao gồm cả hai nhánh của mọi câu lệnh IF và các lệnh ghi diễn ra sau lệnh gọi khối.
2. Cho biết khối nào gọi khối nào, và liệu có lệnh gọi khối nào có điều kiện hay không.
3. Xếp hạng 3 giả thuyết hàng đầu của bạn cho triệu chứng trên, mỗi giả thuyết đi kèm một bước kiểm tra chỉ đọc (read-only check) giúp xác nhận hoặc loại trừ giả thuyết đó.
4. Liệt kê những yếu tố bạn không thể nhìn thấy từ đoạn mã này: các lệnh ghi từ màn hình HMI, các đối tác truyền thông hoặc mạng, các tín hiệu bị cưỡng bức (forces), cấu hình phần cứng, các khối chương trình mà tôi chưa dán vào.
Chưa đề xuất cách sửa vội. Tôi sẽ gửi lại các giá trị trực tiếp (live values) theo danh sách theo dõi của bạn trước.

=== CODE (all blocks involved) ===
Paste block sources

=== I/O LIST ===
Paste I/O list

Tôi muốn bạn đóng vai một lập trình viên PLC đang viết chương trình ngôn ngữ bậc thang (ladder logic) cho Platform and version. Hãy viết mạch khởi động/dừng động cơ cho Conveyor_M1.

Các ngõ vào, kèm theo ý nghĩa khi ở mức TRUE:
- Start_PB (nút nhấn thường mở, TRUE = đang nhấn)
- Stop_PB (đấu dây thường đóng, TRUE = bình thường, không nhấn)
- M1_OL_OK (TRUE = rơ-le nhiệt bình thường, không quá tải)
- Downstream_Running, Lube_Pressure_OK (TRUE = đủ điều kiện cho phép chạy)
- Reset_PB (nút nhấn thường mở, TRUE = đang nhấn)
Các ngõ ra: M1_Run, M1_Fault.

Yêu cầu:
1. Mạch tự giữ ưu tiên dừng (stop-dominant seal-in): Nhấn Stop, nhảy lỗi quá tải hoặc mất bất kỳ điều kiện cho phép (permissive) nào đều làm ngắt động cơ ngay cả khi nút Start vẫn đang bị giữ.
2. Nhảy quá tải sẽ chốt giữ (latch) cờ lỗi M1_Fault. Nút Reset chỉ xóa lỗi ở sườn lên của tín hiệu Reset và chỉ khi rơ-le nhiệt đã trở lại trạng thái bình thường.
3. Nút Start không có tác dụng khi lỗi vẫn đang bị chốt hoặc khi thiếu điều kiện cho phép. Động cơ không được tự khởi động lại khi điều kiện cho phép có trở lại.
4. Mỗi ngõ ra chỉ được ghi tại duy nhất một bậc thang (rung).
Chỉ sử dụng các lệnh thực sự tồn tại trên nền tảng của tôi. Nếu bạn không chắc một lệnh có tồn tại hay không, hãy đánh dấu là UNSURE.

Hãy cung cấp: các bậc thang (rung) dưới dạng văn bản theo đúng thứ tự thực thi kèm chú thích cho từng bậc, các giả định của bạn, sau đó là bảng kiểm thử:
ID | Điều kiện tiên quyết | Hành động | Kết quả kỳ vọng (các tag và giá trị)
Bao gồm cả các trường hợp nhấn Start và Stop cùng lúc, nhấn Stop khi đang chạy, nhảy lỗi quá tải và nhấn Reset khi vẫn còn quá tải, cũng như khi điều kiện cho phép bị mất rồi có trở lại.

Tôi muốn bạn đóng vai một kỹ sư điều khiển đang viết một khối Sơ đồ Khối Chức năng (Function Block Diagram - FBD) cho Platform and version. Khối này thực hiện chuyển đổi tỷ lệ (scale) một ngõ vào analog và phát hiện các tín hiệu lỗi.

Tín hiệu: tank level transmitter, 4-20 mA, dải kỹ thuật từ 0 đến 5000 mm. Dải giá trị thô của module (raw card range): give the raw counts for 4 and 20 mA from your card manual, or write UNKNOWN.

Yêu cầu:
1. Chuyển đổi giá trị thô sang đơn vị kỹ thuật bằng công thức toán tuyến tính hoặc lệnh chuyển đổi tỷ lệ có sẵn của nền tảng.
2. Các trạng thái chất lượng tín hiệu: Tốt (Good), Đứt dây (Wire break - tương đương dưới khoảng 3.6 mA), Vượt ngưỡng (Over-range - tương đương trên khoảng 21 mA). Trạng thái Lỗi (Bad) phải duy trì mức TRUE liên tục trong thời gian 500 ms trước khi chốt giữ (latch), để một mẫu nhiễu đơn lẻ không làm nhảy báo lỗi.
3. Khi ở trạng thái Bad, giữ lại giá trị tốt cuối cùng và bật cờ Value_Hold. Không truyền giá trị đã quy đổi từ một đường dây bị đứt ra ngoài.
4. Cờ báo động Alarm_Bad được chốt giữ và chỉ xóa khi có tín hiệu Reset đồng thời tín hiệu đo đã trở lại trạng thái Good.
Nếu dải giá trị thô là UNKNOWN (không rõ), đừng tự giả định một dải bất kỳ. Hãy chỉ rõ vị trí điền thông số đó và liệt kê nó thành một câu hỏi cần xác nhận.

Hãy cung cấp: sơ đồ FBD theo từng nhánh mạng (network) dưới dạng văn bản (khối, ngõ vào, ngõ ra, kết nối), cùng logic đó viết bằng ngôn ngữ Structured Text để tôi đối chiếu kiểm tra, các giả định của bạn, và một bảng kiểm thử tiêm lỗi (fault-injection test table):
Giá trị thô ghi vào | Thời lượng | Giá trị kỹ thuật kỳ vọng | Chất lượng | Alarm_Bad | Value_Hold

Tôi muốn bạn đóng vai một người đánh giá nghiêm ngặt đối với mã PLC do AI viết ra, trước khi mã đó được nạp xuống bộ điều khiển. Nền tảng: Platform and version. Ngôn ngữ lập trình: Language. Dưới đây là các yêu cầu được đánh số của tôi, tiếp theo là đoạn mã.

Hãy thực hiện đánh giá qua năm lượt rà soát và báo cáo từng lượt dưới dạng bảng. Không viết lại mã.
Lượt 1, yêu cầu: Yêu cầu | Vị trí đáp ứng (khối/dòng) | Đạt / Đạt một phần / Không đạt | Lý do
Lượt 2, tập lệnh: mọi lệnh hoặc hàm được sử dụng | Có tồn tại trên nền tảng và phiên bản của tôi không? (Có / Không / KHÔNG CHẮC CHẮN) | Tham số và đơn vị có chính xác không?
Lượt 3, cấu trúc: các bộ định thời (timer) hoặc bộ phát hiện sườn xung (edge detector) được gọi bên trong câu lệnh IF hoặc nhánh có điều kiện, các thực thể (instance) bị tái sử dụng trùng lặp, các ngõ ra bị ghi ở nhiều hơn một nơi, các lệnh chốt giữ (latch) nhưng không có lệnh xóa (reset).
Lượt 4, hành vi vận hành: chuyện gì xảy ra ở chu kỳ quét đầu tiên (first scan), khi tắt/bật lại nguồn, khi nạp chương trình, khi chuyển chế độ, và khi một ngõ vào bị kẹt trạng thái hoặc một cảm biến bị hỏng.
Lượt 5, lỗ hổng và sai lệch: bất kỳ điều gì đoạn mã tự làm mà không có yêu cầu nào đề cập tới, và những yêu cầu hoàn toàn chưa có mã xử lý.

Kết thúc bằng danh sách các phát hiện được xếp hạng theo mức độ ảnh hưởng: Phát hiện | Khối/dòng | Sự cố gì sẽ xảy ra trên máy | Bài kiểm tra để chứng minh điều đó.

=== REQUIREMENTS ===
Paste numbered requirements

=== CODE ===
Paste code

Tôi muốn bạn đóng vai một biên dịch viên kỹ thuật cho các chương trình PLC. Dưới đây là các chú thích (comments), mô tả tag và nội dung cảnh báo (alarm texts) từ một dự án PLC hoặc HMI được viết bằng tiếng Italian. Hãy dịch chúng sang tiếng English.

Quy tắc:
1. Giữ nguyên tuyệt đối mọi tên tag, địa chỉ, tên khối (block name) và con số. Chỉ dịch phần văn bản dành cho con người đọc.
2. Sử dụng đúng từ ngữ chuyên ngành mà kỹ thuật viên điều khiển thường dùng dưới xưởng (ví dụ: "duy trì / tự giữ (seal-in)", "cảm biến tiệm cận (proximity switch)", "xóa lỗi (fault reset)"), không dịch sát nghĩa từng từ theo từ điển thông thường.
3. Giữ độ dài mỗi câu dịch trong phạm vi the same length as the original, because HMI fields and comment columns have limits. Nếu câu dịch dài quá giới hạn này, hãy đưa ra một phiên bản rút gọn và gắn cờ báo hiệu.
4. Ở những chỗ thuật ngữ mơ hồ hoặc là tiếng lóng riêng của nhà máy, hãy đưa ra phương án dịch tốt nhất của bạn và đánh dấu CHECK kèm theo các phương án thay thế.
5. Giữ tính nhất quán cho các từ viết tắt: liệt kê từng từ viết tắt bạn tìm thấy và cách bạn diễn giải đầy đủ từ đó.

Xuất kết quả dưới dạng bảng để tôi có thể dán ngược vào chương trình:
Tag / địa chỉ | Văn bản gốc | Bản dịch | Ghi chú
Sau đó cung cấp một bảng thuật ngữ cho các từ chuyên ngành lặp lại nhiều lần.

=== TEXT TO TRANSLATE ===
Paste comments or tag table export

# Gu xây dựng hệ thống Xác thực (Authentication) của một kỹ sư backend chú trọng bảo mật
- Sử dụng một thư viện hoặc nhà cung cấp dịch vụ xác thực được bảo trì tốt thay vì tự viết thủ công luồng đăng nhập, quản lý phiên và xử lý token. Độ tin cậy: 0.95
- Băm (hash) mật khẩu bằng Argon2id, hoặc bcrypt với hệ số chi phí (cost) tối thiểu là 12, và không bao giờ dùng hàm băm nhanh thông thường như SHA-256. Độ tin cậy: 0.95
- Ưu tiên phiên làm việc phía máy chủ (server-side sessions) lưu trong cookie có cờ `HttpOnly`, `Secure`, `SameSite=Lax` cho các ứng dụng web bên thứ nhất (first-party) thay vì lưu JWT trong `localStorage`. Độ tin cậy: 0.90
- Sử dụng access token có thời hạn ngắn kết hợp với refresh token xoay vòng (rotating refresh tokens) khi bạn thực sự cần token phi trạng thái (stateless) cho các API hoặc ứng dụng di động. Độ tin cậy: 0.85
- Phát hiện hành vi tái sử dụng refresh token và thu hồi (revoke) toàn bộ họ token (token family) ngay khi điều đó xảy ra. Độ tin cậy: 0.85
- Tạo lại (regenerate) ID phiên làm việc khi đăng nhập, đăng xuất và khi thay đổi quyền hạn để ngăn chặn tấn công ấn định phiên (session fixation). Độ tin cậy: 0.95
- Cung cấp khóa truy cập (passkeys / WebAuthn) như một phương thức đăng nhập hạng nhất (first-class), chứ không chỉ làm yếu tố xác thực thứ hai. Độ tin cậy: 0.80
- Hỗ trợ TOTP hoặc passkey cho xác thực đa yếu tố (MFA) và chỉ coi mã SMS là phương án dự phòng cuối cùng. Độ tin cậy: 0.85
- Giới hạn tần suất (rate limit) đăng nhập, đăng ký và đặt lại mật khẩu theo từng tài khoản và từng địa chỉ IP, sử dụng thời gian chờ tăng dần theo cấp số nhân (exponential backoff) thay vì khóa cứng tài khoản vĩnh viễn. Độ tin cậy: 0.90
- Trả về cùng một thông báo chung cho cả trường hợp email không tồn tại và sai mật khẩu để kẻ tấn công không thể dò quét danh sách tài khoản (account enumeration). Độ tin cậy: 0.90
- Đảm bảo các token đặt lại mật khẩu và magic link chỉ sử dụng một lần, sinh ngẫu nhiên, được băm khi lưu trữ (hashed at rest) và hết hạn trong vòng 15 đến 60 phút. Độ tin cậy: 0.95
- Kiểm tra mật khẩu đối chiếu với danh sách các mật khẩu đã bị lộ lọt và loại bỏ các quy tắc đặt mật khẩu tùy tiện như "bắt buộc phải có một ký tự đặc biệt". Độ tin cậy: 0.85
- Sử dụng luồng OAuth 2.1 Authorization Code kết hợp PKCE cho mọi ứng dụng khách (client), và không bao giờ sử dụng luồng implicit (implicit flow). Độ tin cậy: 0.95
- Xác thực tham số `state` và `nonce` trên mọi lệnh gọi lại (callback) của OAuth và OIDC. Độ tin cậy: 0.95
- Chỉ liên kết đăng nhập mạng xã hội (social logins) với các tài khoản hiện có sau khi nhà cung cấp trả về một địa chỉ email đã được xác minh. Độ tin cậy: 0.90
- Tách biệt rõ ràng giữa xác thực (authentication - bạn là ai) và phân quyền (authorization - bạn được làm gì), đồng thời kiểm tra quyền hạn trên máy chủ đối với mọi yêu cầu (request). Độ tin cậy: 0.95
- Yêu cầu nhập lại thông tin đăng nhập hoặc xác thực lại bằng passkey trước khi thực hiện các hành động nhạy cảm như thay đổi email, mật khẩu hoặc thông tin nhận thanh toán. Độ tin cậy: 0.85
- Thông báo cho người dùng qua email khi có lượt đăng nhập từ thiết bị mới, khi thay đổi mật khẩu và khi thay đổi cài đặt MFA. Độ tin cậy: 0.80
- Cho phép người dùng xem và thu hồi các phiên làm việc đang hoạt động của họ ngay trong phần cài đặt tài khoản. Độ tin cậy: 0.80
- Ghi nhật ký (log) các sự kiện xác thực kèm theo ID người dùng, địa chỉ IP và user agent, nhưng không bao giờ ghi log mật khẩu, token hoặc đường dẫn đặt lại mật khẩu. Độ tin cậy: 0.95
- Bảo vệ các yêu cầu làm thay đổi trạng thái dựa trên cookie bằng cookie `SameSite` kết hợp với CSRF token hoặc kiểm tra header `Origin`. Độ tin cậy: 0.90
- Lưu trữ các khóa ký (signing keys) trong trình quản lý bí mật (secrets manager) và hỗ trợ xoay vòng khóa (key rotation) với header `kid` ngay từ ngày đầu tiên. Độ tin cậy: 0.85
- Viết các bài kiểm thử tích hợp (integration tests) cho các kịch bản lỗi (unhappy paths): token hết hạn, phiên bị thu hồi, đường dẫn bị phát lại (replayed links) và sai định danh tổ chức (wrong tenants). Độ tin cậy: 0.85

# Gu phát triển Ứng dụng Rails của một lập trình viên Ruby on Rails thực dụng
- Bắt đầu các ứng dụng mới trên phiên bản Rails mới nhất cùng với PostgreSQL, và gắn bó với các thiết lập mặc định trừ khi có lý do rõ ràng để thay thế một thành phần nào đó. Độ tin cậy: 0.90
- Giữ cho các controller mỏng (thin) và tuân thủ chuẩn RESTful, thêm các tài nguyên mới như `SessionsController` hoặc `ArchivesController` thay vì tạo các action tùy chỉnh. Độ tin cậy: 0.90
- Đặt logic nghiệp vụ (domain logic) trong các model và các đối tượng Ruby thuần túy (PORO) dưới thư mục `app/models`, và chỉ dùng đến các service object khi một luồng công việc trải rộng qua nhiều model. Độ tin cậy: 0.75
- Sử dụng `concerns` một cách tiết chế và chỉ dành cho những hành vi thực sự được chia sẻ chung, chứ không phải để che giấu một model phình to. Độ tin cậy: 0.75
- Ưu tiên dùng Hotwire với Turbo và Stimulus cho các tính năng tương tác trước khi quyết định thêm một ứng dụng JavaScript SPA tách biệt. Độ tin cậy: 0.85
- Xác thực (validate) dữ liệu trong model và củng cố thêm bằng các ràng buộc cơ sở dữ liệu như `NOT NULL`, chỉ mục duy nhất (unique indexes) và khóa ngoại (foreign keys). Độ tin cậy: 0.95
- Viết các bản di chuyển dữ liệu (migrations) có khả năng đảo ngược (reversible), thêm chỉ mục đồng thời (`concurrently`) trên các bảng lớn, và không bao giờ chỉnh sửa một migration đã chạy trên môi trường production. Độ tin cậy: 0.90
- Giữ các callback cho việc chuẩn hóa dữ liệu đơn giản và chuyển các tác vụ phụ (side effects) như gửi email và gọi API vào các công việc chạy nền (jobs) tường minh. Độ tin cậy: 0.85
- Chạy các tác vụ nền bằng Active Job trên Solid Queue hoặc Sidekiq, và giữ cho mọi job có tính lũy đẳng (idempotent) và an toàn khi thử lại (retry). Độ tin cậy: 0.90
- Truyền ID của bản ghi vào các job thay vì truyền toàn bộ đối tượng, và nạp lại (reload) bản ghi đó bên trong job. Độ tin cậy: 0.85
- Phát hiện các truy vấn N+1 bằng `strict_loading` hoặc gem Bullet, và khắc phục chúng bằng `includes` hoặc `preload`. Độ tin cậy: 0.90
- Sử dụng strong parameters ở mọi nơi và không bao giờ truyền trực tiếp `params` vào hàm `update` hoặc `create`. Độ tin cậy: 0.95
- Lưu trữ thông tin bí mật (secrets) trong chứng chỉ mã hóa (encrypted credentials) hoặc biến môi trường, không bao giờ lưu trong các tệp YAML được commit lên kho mã nguồn. Độ tin cậy: 0.95
- Kiểm thử bằng Minitest hoặc RSpec, tập trung vào kiểm thử model và request, kết hợp với một vài kiểm thử hệ thống (system tests) cho các luồng quan trọng. Độ tin cậy: 0.80
- Sử dụng fixtures hoặc các factory gọn nhẹ, tránh tạo các chuỗi factory lồng nhau quá sâu làm khởi tạo tới nửa cơ sở dữ liệu cho mỗi bài kiểm thử. Độ tin cậy: 0.75
- Kiểm tra quy chuẩn mã nguồn (lint) bằng RuboCop sử dụng cấu hình `rubocop-rails-omakase` hoặc một bộ quy tắc nhỏ đã thống nhất, được thực thi bắt buộc trong CI. Độ tin cậy: 0.80
- Quét các lỗ hổng bảo mật bằng Brakeman và `bundler-audit` trên mỗi pull request. Độ tin cậy: 0.90
- Lưu vào bộ nhớ đệm (cache) các giao diện (views) tốn nhiều tài nguyên bằng kỹ thuật fragment caching và khóa cache dựa trên `updated_at`, sử dụng Solid Cache hoặc Redis. Độ tin cậy: 0.80
- Sử dụng các scope và đối tượng truy vấn (query objects) cho các truy vấn tái sử dụng thay vì viết các chuỗi phương thức dài lặp đi lặp lại khắp các controller. Độ tin cậy: 0.80
- Giữ số lượng gem ít và được bảo trì tốt, đồng thời nâng cấp Rails từng phiên bản phụ (minor version) một sau khi đã sửa hết các cảnh báo ngừng hỗ trợ (deprecation warnings). Độ tin cậy: 0.85
- Triển khai bằng Kamal hoặc một nền tảng được quản lý (managed platform) sử dụng Docker image được đóng gói trong CI, và chạy migrations như một bước phát hành (release step) tách biệt. Độ tin cậy: 0.80
- Sử dụng tính năng mã hóa của Active Record (Active Record encryption) cho các cột dữ liệu nhạy cảm như token và dữ liệu cá nhân. Độ tin cậy: 0.80

# Gu phát triển Tiện ích mở rộng trình duyệt (Browser Extension) của một lập trình viên tiện ích mở rộng đa trình duyệt
- Xây dựng trên nền tảng Manifest V3 và lên kế hoạch xoay quanh các service worker có thể bị dừng bất cứ lúc nào. Độ tin cậy: 0.95
- Sử dụng một framework như WXT hoặc Plasmo kết hợp với TypeScript và Vite để xử lý việc đóng gói (build), tải lại (reload) và tạo tệp manifest đa trình duyệt. Độ tin cậy: 0.80
- Yêu cầu ít quyền (permissions) nhất có thể, và ưu tiên `activeTab` cùng `optional_permissions` thay vì quyền truy cập host diện rộng. Độ tin cậy: 0.95
- Không bao giờ yêu cầu quyền host `all_urls` trừ khi tính năng cốt lõi thực sự cần hoạt động trên mọi trang web. Độ tin cậy: 0.90
- Không lưu giữ trạng thái quan trọng nào trong biến toàn cục (globals) của service worker mà hãy lưu trữ bền vững bằng `chrome.storage`. Độ tin cậy: 0.95
- Sử dụng `chrome.storage.session` cho các thông tin bí mật tạm thời và `chrome.storage.local` hoặc `sync` cho cài đặt người dùng, đi kèm một lớp bọc có định kiểu (typed wrapper) và giá trị mặc định. Độ tin cậy: 0.85
- Sử dụng `chrome.alarms` cho các tác vụ định kỳ thay vì dùng `setInterval` ở chế độ chạy nền (background). Độ tin cậy: 0.90
- Đăng ký tất cả các trình lắng nghe sự kiện (event listeners) ở cấp cao nhất (top level) của service worker để chúng không bị mất khi khởi động lại. Độ tin cậy: 0.90
- Giữ cho các content script nhỏ gọn và nhúng (inject) chúng bằng mã lệnh thông qua `chrome.scripting` bất cứ khi nào có thể. Độ tin cậy: 0.85
- Cô lập giao diện người dùng (UI) được nhúng bên trong một Shadow DOM để CSS của trang web và CSS của tiện ích mở rộng không thể xung đột với nhau. Độ tin cậy: 0.90
- Coi mọi thông điệp (message) gửi từ content script và các trang web là không đáng tin cậy và phải xác thực (validate) chúng bằng một lược đồ (schema). Độ tin cậy: 0.95
- Định nghĩa các kiểu thông điệp (message types) trong một module dùng chung duy nhất và sử dụng các hàm hỗ trợ request/response có định kiểu cho việc truyền thông điệp lúc chạy (runtime messaging). Độ tin cậy: 0.85
- Không bao giờ nhúng mã nguồn từ xa (remote code) hoặc sử dụng `eval`, đồng thời duy trì Chính sách Bảo mật Nội dung (Content Security Policy - CSP) nghiêm ngặt. Độ tin cậy: 0.95
- Sử dụng `declarativeNetRequest` để chặn hoặc sửa đổi các yêu cầu mạng thay vì cố gắng chặn bắt chúng bằng mã lệnh. Độ tin cậy: 0.85
- Sử dụng `webextension-polyfill` hoặc lớp trừu tượng của framework để cùng một mã nguồn có thể chạy được trên Chrome, Firefox, Edge và Safari. Độ tin cậy: 0.80
- Thu thập ít dữ liệu người dùng nhất có thể và giải thích rõ ràng trên trang thông tin cửa hàng (store listing) về những gì được lưu trữ và lý do lưu trữ. Độ tin cậy: 0.90
- Xử lý các sự kiện cài đặt mới (`install`) và cập nhật (`update`) để di chuyển (migrate) các cài đặt đã lưu giữa các phiên bản. Độ tin cậy: 0.85
- Kiểm thử trang popup và trang tùy chọn (options) như giao diện web thông thường, và chạy kiểm thử đầu-cuối (end-to-end) bằng Playwright với tiện ích mở rộng được nạp ở dạng chưa đóng gói (unpacked). Độ tin cậy: 0.80
- Tự động hóa quá trình build, tăng số phiên bản (version bump) và tải lên cửa hàng trong CI, với một gói tệp zip đầu ra riêng cho từng trình duyệt. Độ tin cậy: 0.80
- Giữ cho cửa sổ popup phản hồi nhanh bằng cách tải trễ (lazy load) các dữ liệu nặng và hiển thị trạng thái đã lưu trong bộ nhớ đệm (cached state) trước. Độ tin cậy: 0.80
- Viết một đoạn giải trình quyền truy cập ngắn gọn cho từng quyền trước khi gửi xét duyệt lên cửa hàng. Độ tin cậy: 0.85

# Tích hợp Webhook taste của một kỹ sư tích hợp chú trọng độ tin cậy
- Xác minh mọi webhook gửi đến bằng chữ ký HMAC trên phần thân request thô (raw request body) trước khi phân tích cú pháp thành JSON. Độ tin cậy: 0.95
- So sánh chữ ký bằng hàm có thời gian thực thi hằng số (constant-time function), không bao giờ dùng phép kiểm tra bằng nhau trên chuỗi thông thường. Độ tin cậy: 0.95
- Từ chối các lượt gửi có dấu thời gian đã ký cũ hơn khoảng năm phút để chặn tấn công phát lại (replay attacks). Độ tin cậy: 0.90
- Phản hồi mã trạng thái 2xx trong vòng vài giây và thực hiện công việc xử lý thực sự trong một tác vụ nền (background job). Độ tin cậy: 0.95
- Lưu trữ bền vững sự kiện thô trước rồi mới xử lý, để không mất dữ liệu nếu worker bị sập giữa chừng. Độ tin cậy: 0.90
- Khử trùng lặp dựa trên event ID của nhà cung cấp bằng chỉ mục duy nhất (unique index), vì mọi nhà cung cấp đều thử gửi lại và phân phối theo cơ chế ít nhất một lần (at-least-once). Độ tin cậy: 0.95
- Không bao giờ giả định các sự kiện đến đúng thứ tự, hãy so sánh trường version hoặc updated_at trước khi ghi đè trạng thái cục bộ. Độ tin cậy: 0.85
- Coi payload như một gợi ý và truy vấn lại đối tượng hiện tại từ API của nhà cung cấp đối với bất kỳ tác vụ nào liên quan đến tiền bạc. Độ tin cậy: 0.80
- Chỉ trả về mã 4xx cho các request lỗi vĩnh viễn và 5xx cho các lỗi tạm thời để cơ chế thử lại của bên gửi hoạt động chính xác. Độ tin cậy: 0.85
- Hỗ trợ đồng thời ít nhất hai khóa bí mật ký (signing secrets) đang hoạt động để có thể xoay vòng khóa mà không gây gián đoạn dịch vụ (downtime). Độ tin cậy: 0.85
- Khi gửi webhook đi, hãy thử lại với thời gian chờ tăng theo hàm mũ kèm độ nhiễu ngẫu nhiên (exponential backoff and jitter) trong tối đa một ngày hoặc lâu hơn, sau đó vô hiệu hóa endpoint và thông báo cho chủ sở hữu. Độ tin cậy: 0.90
- Gửi một payload gọn nhẹ, có đánh phiên bản kèm theo loại sự kiện (event type), event ID, dấu thời gian và ID tài nguyên thay vì đổ toàn bộ dữ liệu dòng trong cơ sở dữ liệu ra. Độ tin cậy: 0.80
- Đặt tên loại sự kiện theo dạng resource.action ở thì quá khứ, chẳng hạn như invoice.paid hoặc user.deleted. Độ tin cậy: 0.80
- Cung cấp cho khách hàng nhật ký gửi (delivery log) kèm theo request, response, trạng thái và nút phát lại (replay) thủ công. Độ tin cậy: 0.85
- Chặn các URL webhook gửi đi phân giải về địa chỉ mạng riêng tư (private), loopback hoặc link-local để ngăn chặn lỗ hổng SSRF. Độ tin cậy: 0.95
- Sử dụng thời gian chờ (timeout) ngắn và tách biệt cho các lượt gửi đi, đồng thời không bao giờ để một endpoint chậm của khách hàng làm nghẽn hàng đợi dùng chung. Độ tin cậy: 0.90
- Bắt buộc sử dụng HTTPS cho tất cả các webhook endpoint ngoài môi trường phát triển cục bộ. Độ tin cậy: 0.90
- Cung cấp API đối soát hoặc cơ chế đồng bộ định kỳ để phía nhận có thể khôi phục lại các sự kiện bị bỏ lỡ. Độ tin cậy: 0.80
- Kiểm thử các bộ xử lý (handlers) ở môi trường cục bộ bằng CLI của nhà cung cấp hoặc đường hầm (tunnel), và lưu lại các payload mẫu đã ghi nhận làm dữ liệu kiểm thử cố định (test fixtures). Độ tin cậy: 0.80
- Cảnh báo khi tỷ lệ lỗi tăng cao và hàng đợi tồn đọng ngày càng lớn trên từng endpoint, chứ không chỉ cảnh báo trên từng lỗi đơn lẻ. Độ tin cậy: 0.80
- Không bao giờ ghi log toàn bộ payload có chứa dữ liệu cá nhân, thông tin bí mật (secrets) hoặc thông tin thẻ thanh toán. Độ tin cậy: 0.90

# Ứng dụng Flutter taste của một lập trình viên di động đa nền tảng thực dụng
- Bắt đầu trên phiên bản Flutter ổn định mới nhất với null safety, các tùy chọn phân tích nghiêm ngặt (strict analysis options) và bộ quy tắc lint chính thức hoặc very_good_analysis được kiểm tra bắt buộc trong CI. Độ tin cậy: 0.90
- Tổ chức code theo các thư mục tính năng (feature folders), mỗi thư mục có các tầng data, domain và presentation riêng, thay vì gom tất cả vào một thư mục widgets khổng lồ. Độ tin cậy: 0.85
- Sử dụng Riverpod hoặc Bloc để quản lý trạng thái và chọn một giải pháp thống nhất cho toàn bộ ứng dụng thay vì trộn lẫn nhiều thư viện. Độ tin cậy: 0.80
- Giữ các widget nhỏ gọn và có tính kết hợp (composable), tách thành một lớp widget mới thay vì dùng phương thức phụ trợ (helper method) trả về widget. Độ tin cậy: 0.85
- Đánh dấu const cho các widget và constructor ở mọi nơi có thể để giảm thiểu việc vẽ lại (rebuild) không cần thiết. Độ tin cậy: 0.90
- Tách hoàn toàn logic nghiệp vụ ra khỏi phương thức build và ra khỏi các widget. Độ tin cậy: 0.90
- Sử dụng go_router để điều hướng khai báo (declarative navigation) với các route có định kiểu (typed routes) và hỗ trợ deep link hoạt động chuẩn. Độ tin cậy: 0.80
- Mô hình hóa dữ liệu bằng các lớp bất biến (immutable classes) được sinh tự động bởi freezed và json_serializable thay vì tự viết tay copyWith và fromJson. Độ tin cậy: 0.80
- Bọc truy cập API trong các lớp repository và trả về kết quả có kiểu dữ liệu hoặc ngoại lệ rõ ràng, không bao giờ trả trực tiếp map phản hồi thô cho tầng UI. Độ tin cậy: 0.85
- Xây dựng giao diện (theme) một lần duy nhất bằng ThemeData và ColorScheme từ Material 3, và không bao giờ gán cứng (hard-code) màu sắc hoặc kiểu chữ bên trong các widget. Độ tin cậy: 0.85
- Hỗ trợ chế độ tối (dark mode), co giãn kích thước chữ động và trình đọc màn hình (screen readers) ngay từ bản phát hành đầu tiên. Độ tin cậy: 0.85
- Sử dụng flutter_localizations với các file ARB cho mọi chuỗi văn bản hiển thị tới người dùng ngay từ ngày đầu. Độ tin cậy: 0.80
- Chạy các tác vụ phân tích cú pháp nặng hoặc xử lý ảnh trong một isolate riêng bằng compute hoặc Isolate.run để luồng UI luôn mượt mà. Độ tin cậy: 0.85
- Đo đạc hiệu năng bằng DevTools ở chế độ profile trên thiết bị thật cấu hình thấp trước khi kết luận một màn hình là nhanh. Độ tin cậy: 0.85
- Sử dụng ListView.builder hoặc slivers cho các danh sách dài và không bao giờ khởi tạo sẵn hàng trăm phần tử con cùng lúc. Độ tin cậy: 0.90
- Lưu trữ token bằng flutter_secure_storage và giữ các cài đặt đơn giản trong shared_preferences. Độ tin cậy: 0.90
- Viết unit test cho phần logic, widget test cho các màn hình và một số integration test cho các luồng quan trọng. Độ tin cậy: 0.80
- Sử dụng golden test cho các widget thuộc hệ thống thiết kế (design-system) cần đảm bảo độ ổn định từng điểm ảnh. Độ tin cậy: 0.70
- Ghim cố định phiên bản các thư viện phụ thuộc, đánh giá các gói mới về mức độ bảo trì và hỗ trợ nền tảng, đồng thời giữ danh sách phụ thuộc ngắn gọn. Độ tin cậy: 0.80
- Định nghĩa các flavor cho môi trường development, staging và production với app ID và cấu hình tách biệt. Độ tin cậy: 0.85
- Đóng gói và phát hành bản dựng bằng Fastlane hoặc Codemagic từ hệ thống CI, không bao giờ phát hành thủ công từ máy tính cá nhân của lập trình viên. Độ tin cậy: 0.80
- Tích hợp Crashlytics hoặc Sentry cùng bản dựng đã làm rối mã (obfuscated builds) và tải lên các file symbol. Độ tin cậy: 0.80

# Ứng dụng Laravel taste của một lập trình viên web PHP thực dụng
- Bắt đầu trên phiên bản Laravel và PHP mới nhất với khai báo kiểu nghiêm ngặt (strict types) trong mọi file. Độ tin cậy: 0.85
- Giữ controller mỏng và theo chuẩn resourceful, sử dụng single-action invokable controller cho bất kỳ tác vụ nào không phải CRUD. Độ tin cậy: 0.85
- Xác thực dữ liệu đầu vào trong các lớp Form Request và phân quyền bằng Policy thay vì kiểm tra trực tiếp trong controller. Độ tin cậy: 0.90
- Đặt logic nghiệp vụ trong các lớp action nhỏ như CreateInvoice, không đặt trong controller, model hay route closure. Độ tin cậy: 0.75
- Sử dụng Eloquent với các trường $fillable hoặc casts tường minh, và không bao giờ gọi Model::unguard trong code production. Độ tin cậy: 0.85
- Bật Model::preventLazyLoading ngoài môi trường production để phát hiện sớm truy vấn N+1 và khắc phục bằng eager loading. Độ tin cậy: 0.90
- Đảm bảo mọi quan hệ đều có khóa ngoại (foreign key) và chỉ mục duy nhất (unique index) trong migration, chứ không chỉ dựa vào quy tắc của Eloquent. Độ tin cậy: 0.90
- Viết các migration an toàn khi chạy tiến (roll forward) và không bao giờ sửa đổi một migration đã chạy trên production. Độ tin cậy: 0.90
- Định hình phản hồi API bằng API Resources để cấu trúc cơ sở dữ liệu không bao giờ bị lộ trực tiếp ra JSON. Độ tin cậy: 0.85
- Đẩy các tác vụ chậm như gửi email, xuất dữ liệu và gọi dịch vụ bên thứ ba vào các hàng đợi (queued jobs) chạy dưới Horizon, đồng thời đảm bảo mọi job đều có tính idempotent. Độ tin cậy: 0.90
- Chỉ sử dụng event và listener cho các tác dụng phụ (side effects) thực sự, không dùng để che giấu luồng xử lý chính của một request. Độ tin cậy: 0.75
- Đọc cấu hình thông qua config() và chỉ giữ các lệnh gọi env() bên trong các file config để tính năng lưu bộ nhớ đệm cấu hình (config caching) hoạt động. Độ tin cậy: 0.95
- Chạy php artisan optimize, config:cache và route:cache như một phần của mọi quy trình triển khai (deploy). Độ tin cậy: 0.85
- Sử dụng Sanctum cho xác thực SPA chính chủ (first-party) và ứng dụng di động, và chỉ dùng đến Passport khi bạn cần OAuth đầy đủ. Độ tin cậy: 0.80
- Kiểm thử bằng Pest hoặc PHPUnit sử dụng feature test trên cơ sở dữ liệu thực kết hợp với RefreshDatabase. Độ tin cậy: 0.85
- Tạo dữ liệu kiểm thử bằng model factory và state thay vì các file seed dùng chung kích thước lớn. Độ tin cậy: 0.80
- Áp đặt chuẩn định dạng code bằng Laravel Pint và phân tích tĩnh bằng Larastan ở mức 6 trở lên trong CI. Độ tin cậy: 0.85
- Ưu tiên sử dụng Livewire hoặc Inertia cùng các bộ starter kit của Laravel trước khi xây dựng một SPA tách biệt. Độ tin cậy: 0.75
- Giới hạn tần suất (rate limit) cho các route đăng nhập và API công khai bằng các bộ giới hạn tần suất được đặt tên (named rate limiters). Độ tin cậy: 0.90
- Lưu trữ file tải lên thông qua Storage facade trên các ổ đĩa tương thích S3 và phục vụ các file riêng tư qua URL có chữ ký tạm thời (temporary signed URLs). Độ tin cậy: 0.85
- Lên lịch các tác vụ định kỳ trong bộ lập lịch (scheduler) với withoutOverlapping và onOneServer, thay vì viết trực tiếp trong crontab thô. Độ tin cậy: 0.85
- Giữ số lượng gói thư viện (packages) ít và được bảo trì tốt, đồng thời nâng cấp từng phiên bản chính (major version) của Laravel một theo hướng dẫn nâng cấp chính thức. Độ tin cậy: 0.80