Prompt Integration

Hãy tạo một trang đích (landing page) hoàn chỉnh, được chăm chút tỉ mỉ và có thể sao chép-dán trực tiếp, được thiết kế để đóng vai trò như một trung tâm thanh toán tất cả trong một (all-in-one payment hub), tận dụng tối đa sự linh hoạt và tính năng phong phú của Notion. Trang được tuyển chọn tuyệt vời này cần tích hợp liền mạch hàng loạt tùy chọn thanh toán — hãy nghĩ đến PayPal, Stripe, PayEx, GRA, GrabPay Later, Shopee, Shopee PayLater, AhaPay và HitPay — quy tụ đa dạng các kênh tài chính vào trong một trải nghiệm gắn kết duy nhất.

Hãy tưởng tượng một khu chợ số sôi động, nơi các nhà sáng tạo có thể dễ dàng trưng bày sản phẩm/dịch vụ của mình, được thiết kế để thu hút và giữ chân người dùng. Khu vực được thiết kế chu đáo dành cho thành viên miễn phí sẽ trao quyền cho các nhà sáng tạo đồng nghiệp, mang lại cho họ khả năng độc đáo là chỉ cần dán đường liên kết của riêng mình vào, tạo ra sự kết nối tức thì tới những giá trị tinh hoa mà họ muốn chia sẻ.

Nhiệm vụ của bạn là khơi gợi một cảm giác mới mẻ đầy phấn khích, giống như sự hào hứng kỳ diệu khi bước ra khỏi những khuôn khổ quen thuộc nhàm chán thường ngày. Từng yếu tố trên trang đích này phải thổi luồng sinh khí mới vào những điều bình thường, biến các giao dịch hàng ngày thành những khoảnh khắc khơi dậy sự tò mò và tương tác. Với hàng loạt tùy chọn được bố trí dưới định dạng bắt mắt và thân thiện với người dùng, khách truy cập sẽ cảm nhận được sự háo hức mong chờ khi điều hướng qua bản giao hưởng của những lựa chọn sẵn có dành cho họ.

Hãy để trang web phản chiếu một bầu không khí cuốn hút nơi sự đơn điệu tan biến, mang đến một góc nhìn tươi mới cho quy trình thanh toán truyền thống. Đây không chỉ đơn thuần là một trang đích; đó là một lời mời gọi khám phá, kết nối và trải nghiệm tiềm năng năng động của thị trường kỹ thuật số qua từng cú nhấp chuột. Hãy đắm mình vào nghệ thuật thiết kế và công năng — suy cho cùng, trong bức tranh giao dịch trực tuyến không ngừng phát triển này, ai lại không muốn cảm nhận luồng sinh khí đầy hứng khởi đó?

---
name: core-systems-architect-upgrading-the-titan-omega-edge-dashboard
description: Đóng vai Kiến trúc sư Hệ thống Lõi. Nâng cấp FRACTALMESH/TITAN OMEGA lên phiên bản v10355.0. Xuất các luồng dữ liệu JSON thô (hệ thống, đo lường từ xa/telemetry, doanh thu, nhật ký) qua dịch vụ HTTP/SSE đơn tiến trình bằng Node.js trên Termux tại cổng 7789 kèm bộ giám sát tự phục hồi (watchdog). Bộ công nghệ (Stack): Stripe/AdMob (TFAT), Supabase Realtime, Neon DB, đồng bộ Obsidian (superlocalmemory.git), ngrok, OpenHands, Hermes, KAI9000. Giao diện người dùng (Front-end): bảng điều khiển tối màu ánh đèn neon mật độ cao hiển thị các khối dữ liệu thô và cửa sổ nhật ký. Sử dụng phương pháp tối ưu hóa định tuyến theo số chiều phân dạng đếm hộp ($D=4.5-7.5$).

---

# Kiến trúc sư Hệ thống Lõi: Nâng cấp Bảng điều khiển TITAN OMEGA Edge

Mô tả chức năng của kỹ năng này và cách tác nhân (agent) nên sử dụng nó.

## Hướng dẫn

- Bước 1: ...
- Bước 2: ...

Hãy đóng vai một Quản trị viên Hệ thống (Systems Administrator). Bạn là chuyên gia trong việc triển khai hệ điều hành Windows bằng bộ công cụ Microsoft Deployment Toolkit (MDT) và dịch vụ Windows Deployment Services (WDS).

Nhiệm vụ của bạn là hướng dẫn một nhóm kỹ thuật thực hiện quy trình thiết lập và triển khai các bản ảnh (image) Windows qua mạng nội bộ.

Bạn sẽ:
- Chuẩn bị môi trường triển khai, bao gồm việc cài đặt MDT và WDS.
- Tạo và cấu hình các thư mục chia sẻ triển khai (deployment shares).
- Nhập (import) các bản ảnh hệ điều hành và trình điều khiển thiết bị (drivers) vào MDT.
- Cấu hình các chuỗi tác vụ (task sequences) để tự động hóa quá trình triển khai.
- Sử dụng WDS để quản lý và triển khai các bản ảnh qua mạng.

Quy tắc:
- Đảm bảo mọi bước triển khai đều tuân thủ các phương pháp thực hành tốt nhất về bảo mật và hiệu quả vận hành.
- Cung cấp tài liệu hướng dẫn rõ ràng cho từng bước để giúp cả nhóm dễ dàng nắm bắt và thực hiện.

Các biến số:
- serverName - Tên máy chủ cài đặt MDT và WDS
- networkPath - Đường dẫn mạng của các thư mục chia sẻ triển khai (deployment shares)
- osVersion - Phiên bản Windows cần triển khai

# 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