Ý tưởng & lộ trình phát triển

Cẩm nang vận hành cho cán bộ & điều phối viên HMT

Một tài liệu hướng dẫn tổng thể, bằng tiếng Việt, theo bộ nhận diện HMT, ở dạng HTML — giải thích cho người dùng không rành kỹ thuật toàn bộ cách Trung tâm điều hành được thiết kế và vận hành: dữ liệu được lưu ở đâu, ai thấy gì, các quy trình chạy ra sao, và người dùng dùng hub & Drive thế nào.

Vì sao cần

• Hub nay đã chạm cả 4 lĩnh vực (Học sinh · Truyền thông · Nhà tài trợ · Tài chính); người dùng mới cần một bức tranh "tất-cả-trong-một" để biết hệ thống là gì và tin tưởng nó.
• Phần lớn nguyên tắc quan trọng (mọi bài cần duyệt, bảo vệ tài liệu, nhân phẩm, dữ liệu ở 2 nơi) hiện chỉ nằm trong tài liệu kỹ thuật. Cán bộ cần bản kể bằng lời, dễ đọc.
• Giảm hỏi-đáp lặp lại ("tôi xem được gì?", "báo cáo nằm đâu?", "ảnh có tự đăng không?") bằng một nguồn tra cứu duy nhất.

Phạm vi — dàn ý các chương (mức tổng quan)

1. Trung tâm điều hành là gì & vì sao có nó.Một ứng dụng, một lần đăng nhập cho mọi việc của Quỹ; triết lý "máy lo phần nặng nhọc, con người giữ quyền quyết định".
2. Bức tranh tổng thể: dữ liệu sống ở những đâu.Sơ đồ không-kỹ-thuật của ba nơi — Google Drive (nơi con người đọc), Hub (ứng dụng để xem & làm việc), kho máy trên đám mây (nơi hệ thống xử lý). Quy tắc "mỗi tài liệu lưu ở 2 nơi".
3. Dữ liệu được lưu & sắp xếp thế nào.Các "ngăn" của Drive (Hoạt động, Học sinh, Nhà tài trợ, Tài chính, Quản trị…); sổ tay học sinh, hồ sơ, tài liệu gốc; cách đặt tên để tra cứu được sau nhiều năm.
4. Ai thấy gì — tài liệu được bảo vệ ra sao.Đăng nhập hub; phân quyền theo khu vực (Học sinh / Nội dung / Tài trợ); quyền thư mục Drive cấp theo từng người; tài liệu nhạy cảm; xóa định vị GPS khỏi ảnh; nguyên tắc nhân phẩm; "tường lửa" dữ liệu; đồng thuận do Quỹ quản lý bên ngoài hệ thống.
5. Các biểu mẫu — điểm khởi đầu.Mọi việc thường bắt đầu từ một biểu mẫu (Google Form): Phiếu thông tin sự kiện điều phối viên điền sau mỗi hoạt động (khởi động luồng truyền thông & tự tạo thư mục sự kiện); Phiếu khảo sát ứng viên (đưa một em mới vào diện xét chọn); Phiếu nhà tài trợ. Điền form xong, hệ thống tự dựng thư mục/hồ sơ tương ứng — cán bộ không phải tạo tay.
6. Các quy trình chính, kể bằng lời.Truyền thông & câu chuyện (ảnh hiện trường → xử lý → chọn → viết bài → kiểm duyệt → duyệt của người → đăng tay); Chăm sóc học sinh (tài liệu → phân loại → trích xuất → sổ tay & báo cáo); Nhà tài trợ & tài chính (đóng góp → thư cảm ơn + biên nhận → báo cáo minh bạch); Khảo sát & xét chọn (ứng viên → được chọn → hồ sơ học sinh).
7. Tự động hoá & AI — máy làm gì, người quyết gì.Ranh giới rõ ràng để cán bộ tin tưởng: máy lo phần nặng & lặp (đọc chữ trong ảnh/scan, gợi ý lời bài, sắp xếp tài liệu, dựng báo cáo), còn con người luôn giữ quyền quyết định — không bài nào tự đăng, không thư cảm ơn quan trọng nào tự gửi nếu chưa duyệt. AI có thể nhầm; vì vậy mọi thứ AI tạo đều qua mắt người trước khi ra ngoài.
8. Đưa tài liệu vào hệ thống — lúc đầu & về sau.Bốn cách một tài liệu (học bạ, sổ điểm, biên nhận, ảnh…) đi vào hệ thống: tải lên qua hub (chọn đúng học sinh/loại — gọn nhất), gửi email vào hòm thư chuyên dụng, thả vào thư mục Drive được quét định kỳ, hoặc đính kèm theo biểu mẫu. Tất cả chảy vào một mạch: phân loại → đưa đúng chỗ → trích xuất; tài liệu chưa chắc chắn được chuyển vào hàng đợi rà soát, không bao giờ lưu nhầm âm thầm.
9. Cách dùng hub hằng ngày.Đăng nhập; đi qua từng trang (Tổng quan, Hoạt động, Học sinh, Báo cáo, Phân tích, Tài trợ, Khảo sát, Quản lý tài khoản); các việc thường làm — tạo báo cáo, nạp học bạ/sổ điểm, duyệt bài, quản lý tài khoản.
10. Báo cáo & sổ tay học sinh — tạo thế nào, tin được vì sao.Cách bấm tạo một báo cáo (cá nhân / trường / lứa), nó xuất hiện ở đâu trên Drive, và vì sao đáng tin: mỗi con số/ghi chú đều truy được về tài liệu gốc (nguồn gốc). Sổ tay mỗi em là hồ sơ sống, cập nhật dần theo thời gian.
11. Truy cập Google Drive.Được cấp quyền thế nào (theo khu vực, qua địa chỉ email); đọc được gì, không đụng được gì; nguyên tắc "chỉ đọc vào, không ghi đè"; báo cáo & sổ tay xuất hiện ở đâu trên Drive.
12. Nguyên tắc an toàn & vận hành.Giai đoạn hiện tại: không gì tự đăng — mọi bài đều cần người duyệt; an toàn trẻ em & nhân phẩm; minh bạch; "sai thì nói thẳng".
13. Hỏi–đáp & xử lý sự cố thường gặp."Tôi xem được gì?", "báo cáo nằm đâu?", "ảnh có tự đăng không?", "quên mật khẩu thì sao?", "thấy nhầm/thiếu dữ liệu báo ai?".
14. Phụ lục — thuật ngữ.Giải nghĩa ngắn gọn các từ hay gặp (sổ tay, ngăn/band, bản nháp, kiểm duyệt, ảnh đã chỉnh…) cho người không kỹ thuật.

Sản phẩm đi kèm

• Cẩm nang đầy đủ — tài liệu HTML nhiều chương ở trên (bản chính).
• Thẻ tra nhanh 1 trang — "việc thường làm" rút gọn (đăng nhập, nạp tài liệu, tạo báo cáo, duyệt bài, báo lỗi) để cán bộ dùng hằng ngày mà không phải mở cả cẩm nang.
• Lối "Bắt đầu từ đây" 15 phút — đường đọc ngắn cho người mới, để cẩm nang kiêm luôn vai trò đào tạo nhập môn.

Cách trình bày (để người không kỹ thuật đọc được)

• Kể bằng lời & theo việc thật, tránh từ kỹ thuật; có thì giải nghĩa ngay tại chỗ.
• Sơ đồ đơn giản cho "dữ liệu sống ở đâu" và cho từng quy trình (mũi tên, không thuật ngữ).
• Ảnh chụp màn hình có khoanh vùng & chú thích — đã che thông tin nhận dạng học sinh.
• Mục lục nhảy nhanh, đọc tốt trên điện thoại (cán bộ hay xem bằng điện thoại), in ra được.
• Mỗi chương mở đầu bằng một câu "chương này trả lời câu hỏi gì".

Một ví dụ xuyên suốt (đề xuất dùng trong cẩm nang)

"Tôi vừa đi thực địa về." Theo chân một điều phối viên: điền Phiếu thông tin sự kiện → hệ thống tự tạo thư mục → tải ảnh lên → hệ thống xoá định vị & chọn ảnh đẹp → gợi ý lời bài → điều phối viên/Editor rà soát & bấm Duyệt → nhận gói sẵn-sàng để đăng tay. Một mạch duy nhất minh hoạ gần hết các khái niệm — dùng làm "sợi chỉ đỏ" cho cả tài liệu.

Ngoài phạm vi (để khỏi phình)

• Không phải sổ tay kỹ thuật/triển khai (không các bước deploy, khoá bí mật, mã nguồn).
• Không phải tài liệu pháp lý/chính sách (đồng thuận & tuân thủ do Quỹ quản lý bên ngoài hệ thống).
• Không thay thế tài liệu nội bộ kỹ thuật hiện có — đây là bản "kể cho người dùng".

Đo lường "thành công"

• Một điều phối viên mới tự làm được việc cốt lõi sau khi đọc, không cần hỏi từng bước.
• Giảm rõ các câu hỏi lặp ("tôi xem được gì?", "báo cáo nằm đâu?", "ảnh có tự đăng không?").
• Cán bộ nói được bằng lời của mình: dữ liệu của em được bảo vệ thế nào & vì sao không gì tự đăng.

Đầu vào cần có & rủi ro

Quyết định khi thực thi (chưa chốt)

Bước tiếp theo

Khi muốn làm: tách Ý tưởng 01 thành một kế hoạch thực thi riêng — chốt nơi xuất bản & cấu trúc, viết nội dung từng chương, (tuỳ chọn) chụp & che ảnh màn hình, rà soát rồi xuất bản. Lúc đó mục này chuyển nhãn sang KẾ HOẠCH.

Hai pháp nhân song song — tách dòng tài trợ theo đúng tổ chức

Hoạt động được vận hành qua hai tổ chức đăng ký riêng với Bộ Nội vụ: Quỹ Hoa Mặt Trời (mục đích từ thiện — hỗ trợ cá nhân/hộ được công nhận nghèo hoặc tương đương) và Quỹ Thanh Nhân (mục đích xã hội — được tài trợ cả đối tượng không thuộc diện nghèo, và giải ngân trực tiếp cho trường). Hai quỹ dùng chung bộ máy vận hành, nhưng mỗi khoản tài trợ/giải ngân phải xuất phát từ đúng pháp nhân để tuân thủ. Trung tâm điều hành là nơi vận hành cả hai, nên cần một số cập nhật cấu trúc để phản ánh điều này.

Hai pháp nhân, một bộ máy

Nguyên tắc tuân thủ — định tuyến dòng tiền

Cốt lõi của ý tưởng: mỗi khoản chi gắn với đúng pháp nhân theo đối tượng nhận.

• Hỗ trợ cá nhân/hộ được công nhận nghèo → có thể đi từ Hoa Mặt Trời (đúng mục đích từ thiện).
• Hỗ trợ người không thuộc diện nghèo → phải đi từ Thanh Nhân (mục đích xã hội).
• Giải ngân trực tiếp cho trường → phải đi từ Thanh Nhân (Hoa Mặt Trời bị giới hạn).
• Hệ thống cảnh báo/chặn khi ghép sai (ví dụ: gắn một khoản chi-thẳng-cho-trường vào Hoa Mặt Trời) — giống một "luật định tuyến" nhẹ, kiểm tra trước khi ghi sổ.

(Ranh giới chính xác của từng quỹ phải lấy từ điều lệ/giấy đăng ký — phần "Cần làm rõ" bên dưới. Trang này phác nguyên tắc, không phải kết luận pháp lý.)

Các thay đổi cấu trúc (mức tổng quan)

1. "Pháp nhân" trở thành một trường hạng nhất. Thêm thuộc tính tổ chức vào mọi nơi có dòng tiền: khoản đóng góp của nhà tài trợ (tiền vào tài khoản của quỹ nào), khoản phúc lợi/giải ngân cho học sinh, biên bản tài trợ cho trường, và sổ tài chính. Ghi sổ tách theo quỹ.
2. Hai bộ sổ tài chính tách bạch. Mỗi quỹ tự lập báo cáo minh bạch/báo cáo nộp Bộ Nội vụ riêng; số dư, dòng tiền, đánh số biên nhận không trộn lẫn.
3. Dữ liệu điều kiện (eligibility) của học sinh. Ghi nhận tình trạng được công nhận nghèo / cận nghèo / không (sổ hộ nghèo, giấy xác nhận…) làm đầu vào định tuyến. Đây là dữ liệu nhạy cảm — lưu nguồn nhưng chỉ trích "dữ kiện cần cho chăm sóc", theo quy tắc tài liệu nhạy cảm (care-data §3).
4. Cầu nối tài trợ → học sinh có dấu pháp nhân. Biên bản tài trợ cho trường (bien-ban-tai-tro) toả thành các khoản phúc lợi từng em — mỗi nhánh phải mang đúng quỹ (chi-thẳng-trường = Thanh Nhân; hỗ trợ em thuộc diện nghèo = Hoa Mặt Trời).
5. Biên nhận, thư cảm ơn, báo cáo theo từng quỹ. Mỗi quỹ có nhận diện riêng (letterhead/logo Thanh Nhân vs Hoa Mặt Trời), tài khoản ngân hàng/QR riêng (tiền vào đúng nơi), dãy số biên nhận riêng. Biên nhận do đúng quỹ phát hành.
6. Phía nhà tài trợ. Một khoản đóng góp thuộc về một quỹ; biên nhận & ghi nhận đến từ quỹ đó. Ý định của nhà tài trợ ("tôi muốn tài trợ trực tiếp cho trường X") có thể quyết định khoản đó phải vào Thanh Nhân.
7. Giao diện hub. Nhãn/bộ lọc theo quỹ; Phân tích & Tài chính tách theo quỹ; mỗi khoản chi hiển thị rõ thuộc quỹ nào; có thể có "bộ chuyển quỹ" hoặc một cột pháp nhân.

Điều KHÔNG đổi

• Bộ máy vận hành dùng chung. Truyền thông, câu chuyện, chăm sóc học sinh, đội ngũ, một hub một lần đăng nhập — không tách đôi. Chỉ lớp tiền & pháp lý chia theo quỹ.
• Phase A nguyên vẹn. Không gì tự đăng; biên nhận tự gửi (nếu bật) vẫn chỉ trong phạm vi đã duyệt — nay thêm điều kiện "đúng quỹ".
• Tường lửa dữ liệu & nhân phẩm giữ nguyên.

Cần làm rõ trước khi thực thi

Bước tiếp theo

Khi muốn làm: lấy ranh giới pháp lý từ điều lệ hai quỹ, rồi tách thành một kế hoạch thực thi — mô hình dữ liệu (trường pháp nhân + dữ liệu điều kiện), tách sổ tài chính, luật định tuyến + cảnh báo ghép sai, nhận diện & biên nhận theo quỹ, và giao diện hub. Lúc đó mục này chuyển nhãn sang KẾ HOẠCH.

Trang Pháp lý & Quản trị

Một surface trong hub tập hợp hồ sơ pháp lý & nền tảng của cả hai tổ chức (Hoa Mặt Trời & Thanh Nhân — xem Ý tưởng 02): chi tiết đăng ký hiển thị rõ, tài liệu chứng minh tải lên xem được ở panel bên phải (giống cách xem hồ sơ gốc của học sinh), cùng thông tin quản trị — hội đồng & thành viên. Là "một nơi đáng tin" để tra cứu tư cách pháp nhân khi cần (nhà tài trợ, đối tác, thủ tục).

Nội dung cốt lõi

• Hồ sơ pháp lý & nền tảng (mỗi quỹ). Giấy đăng ký với Bộ Nội vụ, điều lệ, quyết định thành lập, mã số thuế, mẫu con dấu, người đại diện theo pháp luật — với tài liệu gốc tải lên, mở ở panel bên phải.
• Chi tiết đăng ký hiển thị. Tên đầy đủ, số & ngày đăng ký, cơ quan cấp, mục đích hoạt động (từ thiện / xã hội), phạm vi — đọc nhanh không cần mở file.
• Quản trị. Hội đồng quản lý/sáng lập (trustees) & thành viên: họ tên, vai trò, nhiệm kỳ; gắn với quyết định bổ nhiệm khi có.

Các nhánh có thể tách thành ý tưởng riêng (spin-off)

Cần làm rõ trước khi thực thi

• Ai xem được. Trang pháp lý/quản trị có tài liệu nhạy cảm → giới hạn truy cập (chỉ quản trị viên?); phân quyền theo khu vực như phần còn lại của hub.
• Lưu ở đâu. Tài liệu gốc nên nằm ở band Quản trị trên Drive (5_Quản-trị) — thống nhất hai-không-gian như dữ liệu khác.
• Phạm vi đợt đầu. Bắt đầu với hồ sơ đăng ký + hội đồng/thành viên; HR & quan hệ NGO tách sau khi cần.

Bước tiếp theo

Khi muốn làm: chốt phạm vi đợt đầu (hồ sơ đăng ký + quản trị của hai quỹ + panel xem tài liệu), quyền truy cập, và band lưu trữ; rồi tách thành kế hoạch thực thi. HR & quan hệ NGO ghi nhận là nhánh spin-off, kích hoạt khi quy mô đòi hỏi. Lúc đó chuyển nhãn sang KẾ HOẠCH.

Chuẩn hoá & thể chế hoá vận hành và đối ngoại

Đưa hoạt động và các tương tác với bên ngoài về một khuôn chính quy: một bộ mẫu văn bản có letterhead áp dụng nơi cần, và tài khoản chính thức cho thành viên khi Google Workspace for Nonprofits được mở. Mở rộng dần sang các mảng thể chế khác.

Bộ mẫu văn bản (letterhead) — áp dụng ở đâu

• Hợp đồng · nghị quyết nội bộ · báo cáo tài chính · thông báo · biên bản review 3 bên · các báo cáo & văn bản truyền thông khác.
• Mỗi mẫu mang nhận diện đúng pháp nhân (letterhead Hoa Mặt Trời vs Thanh Nhân — gắn với Ý tưởng 02).
• Kế thừa nền đã có: quy cách document-chrome (letterhead báo cáo/sổ tay + email cảm ơn) — mở rộng sang văn bản hành chính/pháp lý.

Tài khoản chính thức

• Khi Google Workspace for Nonprofits được mở (đang vướng — cần làm rõ lý do/điều kiện): lập email theo tên miền tổ chức cho thành viên chính thức, kèm chữ ký chuẩn, phân quyền, lưu trữ tập trung.
• Gắn với Ý tưởng 03 (ai là thành viên chính thức) và phần quản lý tài khoản của hub.

Mở rộng sang các mảng khác (đề xuất thêm)

Các mảng thể chế hoá nên cân nhắc, ngoài danh sách trên:

Cần làm rõ trước khi thực thi

• Workspace for Nonprofits đang vướng gì (điều kiện duyệt, ai đứng tên) — đây là nút chặn cho phần tài khoản chính thức.
• Thứ tự ưu tiên mẫu nào trước (ví dụ biên bản review 3 bên & thông báo dùng nhiều nhất?).
• Ai ký/duyệt mỗi loại văn bản — gắn với quản trị (Ý tưởng 03).

Bước tiếp theo

Khi muốn làm: lập danh mục mẫu văn bản theo độ ưu tiên, dựng từng mẫu trên nền document-chrome với letterhead đúng quỹ; song song theo dõi mở khoá Workspace for Nonprofits để lập tài khoản chính thức. Các mảng chính sách/kiểm soát/đối ngoại có thể tách thành ý tưởng riêng khi chín. Lúc đó chuyển nhãn sang KẾ HOẠCH.

Vòng phát triển tự động qua đêm (Ralph AFK Stack)

Đây là ý tưởng về cách xây dựng hệ thống, không phải một tính năng sản phẩm. "Ralph AFK" là một harness mã nguồn mở chạy Claude Code trong một vòng lặp implementer → reviewer không cần người trực, bên trong sandbox Docker, lấy kho mã (git repo) làm bộ nhớ — để máy tự làm việc qua đêm từ một bản kế hoạch/danh sách việc. Phân tích dưới đây xem nó chạy được ở workspace này tới đâu.

Ralph AFK là gì (tóm tắt)

• Vòng 4 nhịp: kiểm tra "đã xong chưa" → làm một việc → review độc lập diff → lặp lại với ngữ cảnh mới tinh. Thoát khi agent phát tín hiệu NO MORE TASKS.
• Repo là bộ nhớ (không phải lịch sử hội thoại); mỗi vòng dựng lại từ đầu — chống "trôi" ngữ cảnh.
• Bề mặt ghi = git repo → mọi thay đổi đều diff được & hoàn tác được; reviewer không chặn vòng lặp (giữ vết kiểm).
• Điều kiện: Docker + Node 22 + linux/amd64; cần auto-approve shell & edit (vì "lời nhắc duyệt lúc 3 giờ sáng là một cú treo, không phải lá chắn"); chi phí token cho lần chạy dài; rủi ro prompt-injection từ nội dung không tin cậy.

Vì sao hợp với dự án này

• Đã có sẵn backlog đúng kiểu Ralph thích: punch-list giao diện (P1–P29), các track bù dữ liệu, và chính sổ ý tưởng này — việc lặp, theo kế hoạch, trên codebase có sẵn.
• Khớp cách dự án đã vận hành: kế hoạch dạng markdown, cổng QC (ruff/mypy/pytest + brand-voice), "eval ratchet"/autoimprove — vốn đã là kiểu implementer→reviewer.
• Repo đáng tin (repo riêng của đội) — đúng yêu cầu "chỉ trỏ Ralph vào repo/kế hoạch bạn tin tưởng".
• Đã có tiền lệ: Claude Code Web hiện đã chạy build tự động qua đêm tạo PR nháp claude/* cho dự án này — tức mô hình AFK-tạo-PR đã hoạt động, chưa cần dựng Docker.

Nút chặn & lan can bắt buộc ở workspace này

Điểm mấu chốt: Ralph cần auto-approve để chạy không người trực — mà workspace này có những luật cứng. Vòng lặp phải bị rào để KHÔNG bao giờ làm các việc sau:

• KHÔNG deploy. Đưa Cloud Run/Cloudflare lên là hành động ra ngoài, khó đảo — luật yêu cầu người duyệt từng lần, không bao giờ tự động/cron. Lệnh deploy phải nằm trong danh sách cấm của sandbox.
• KHÔNG đăng bài (Phase A). Không gì rời workspace mà chưa /approve. Vòng lặp chỉ đụng mã/tài liệu/test, tuyệt đối không chạm đường xuất bản.
• KHÔNG ghi vào bucket care/tài chính sống. Bucket chăm sóc là bản duy nhất của dữ liệu thụ hưởng — chỉ sửa khi có backup + quiesce + verify, có người giám sát. Loại hẳn khỏi tầm với của loop.
• KHÔNG có secret/.env. .env giữ token nền tảng/GCP/Anthropic sống. Sandbox chỉ được cấp đúng khoá API để chạy agent, không khoá nào hành động ra ngoài được; mount repo không kèm .env/khoá SA.
• Tường lửa dữ liệu. Chỉ mount đúng repo này; repo là mật, không bao giờ đẩy lên remote công khai. Mô hình "bề mặt ghi = repo" của Ralph hợp tường lửa nếu loại trừ creds ra ngoài.
• Prompt-injection. Chỉ nạp kế hoạch/issue do đội viết (tin cậy) làm "mệnh lệnh"; không đưa nội dung OCR/dữ liệu thụ hưởng vào làm bề mặt chỉ thị.

Cấu hình an toàn đề xuất

• Phạm vi: chỉ các việc thuần mã/giao diện từ một kế hoạch tuyển chọn — ví dụ nhóm sửa template/CSS trong punch-list (P5, P8, P9, P16, P18, P19, P21, P22, P23, P25, P26, P27), không các việc bù-dữ-liệu hay deploy.
• Đầu ra = PR nháp / nhánh claude/* để người review, chạy QC, rồi deploy thủ công (deploy luôn do người).
• Nhịp reviewer = kỷ luật QC sẵn có (ruff/mypy/pytest, brand-voice) làm vòng phản hồi build/test.
• Host: box là Windows → chạy qua WSL2 + Docker Desktop, hoặc một máy Linux dùng-một-lần trên cloud; hoặc đơn giản dựa vào Claude Code Web (đã làm việc này, không cần Docker cục bộ).

So với cái đang có (Claude Code Web)

Claude Code Web đã cho kết quả AFK cốt lõi (build qua đêm → PR nháp) mà không cần Docker/WSL. Ralph thêm phần tự host vòng lặp có kỷ luật rõ (một việc/vòng, ngữ cảnh mới mỗi vòng, tín hiệu thoát, nhịp reviewer). Lựa chọn: (a) mượn kỷ luật của Ralph áp lên luồng Web hiện có; (b) tự dựng Ralph trên WSL/cloud cho các đợt lớn; (c) hybrid.

Nhận định

Hứa hẹn cho backlog phía mã (punch-list giao diện, dọn dẹp, tooling). Quyết định then chốt là cái rào auto-approve (cấm deploy/đăng/ghi-bucket-sống/secret) và host (Windows → WSL/cloud). Khuyến nghị mở đầu nhẹ nhàng: thí điểm trên một lát cắt thuần-mã, loại trừ mọi creds ra ngoài, đầu ra là PR nháp để người duyệt — hoặc trước mắt chính quy hoá luồng Claude Code Web đang dùng và mượn kỷ luật vòng lặp của Ralph, thay vì dựng ngay Docker stack trên Windows.

Cần làm rõ / Bước tiếp theo

• Chốt danh sách cấm (deploy/publish/bucket-sống/secret) và cách rào ở tầng sandbox/network.
• Chọn host (WSL2 vs cloud Linux vs dựa Web) và một kế hoạch hạt giống nhỏ, thuần-mã để thí điểm.
• Đặt ngân sách token cho mỗi đợt; đo "được/mất" sau lần chạy đầu.

Tham khảo: bài "The Ralph AFK Stack explained" — daonhan.substack.com/p/the-ralph-afk-stack-explained.