Đổi gì · vì sao · trước→sau — mới nhất trên cùng. Mỗi mốc đều có review độc lập trước khi lên sóng.
Đổi gì: anh nay có một cái công tắc chặn bot gửi tin, bấm là ăn trong 30 giây, tin đang chờ giữ nguyên không mất. Kèm một cuốn sổ ghi đã-nhắn-ai — trước hôm nay bot gửi tin hằng ngày mà chỉ ghi «đã gửi N ký tự», không ghi cho ai.
Nhưng đường tới đó là một chuỗi tự vấp: ① em đưa anh sai đường dẫn — anh bấm phanh, bot không thấy ② executor dời mã tới đúng chỗ tệp anh đã tạo ⇒ hộp gửi kẹt 3 phút, không ai hiểu vì sao ③ em báo «đã dọn tệp» dựa trên một lệnh in dấu ✓ kể cả khi không có gì để xoá ④ trong 20 phút có 5 thiết kế khác nhau trôi qua kênh, em đổi ý hai lần, executor khởi động lại giữa chừng vì chưa kịp thấy tin bác ⑤ và lệnh «xem phanh đang bật hay tắt» em ghi vào bản chốt thì trả lời bằng một dòng lỗi đỏ ở đúng ca bình thường nhất.
Chuyện gì: đội đang làm cái công tắc để anh chặn bot gửi tin trong một giây. Bản đầu hỏng câm: lệnh kiểm mà em duyệt không kêu khi gặp trục trặc — nó lặng lẽ trả lời «không có» — nên lớp bắt lỗi bọc quanh chẳng bao giờ chạy. Hậu quả: anh đã bấm phanh mà bot vẫn gửi tiếp, và chú thích ngay trên nó thì ghi «an toàn khi hỏng».
Em kiểm và cấp chữ «đạt» cho bản hỏng đó. Vì em thử ca «không đọc được thư mục» bằng cách xoá hẳn thư mục — cách dễ dựng nhất. Thấy xanh là kết luận. Ca thật là thư mục còn đó mà không vào được, và chỉ ca đó mới lộ lỗ. Tệ hơn: hai lượt trước đó em còn lấy chính cái sai của mình để khen executor. Nếu nó tin lời khen mà thôi đào, cái phanh hỏng đã lên sóng kèm một chú thích tuyên bố nó an toàn. Nó khai «tôi chưa chạy phép này», rồi đi chạy dù em đã gật — và tìm ra lỗi.
Chuyện gì: executor đang viết cái công tắc tắt khẩn (thứ để anh chặn bot gửi tin trong một giây). Nó sửa một lỗi, viết đúng cách chữa — rồi áp vào nhầm hàm, vì hai chỗ trong mã có dòng giống hệt nhau và phép thay chuỗi lấy cái đầu tiên gặp. Vòng soi bắt được. Bản vá chưa hề chạm vào bot thật — em kiểm mã băm, vẫn nguyên.
Chỗ đáng sợ là phép kiểm gật cho nó qua. Em dựng lại mẫu tối giản để tự kiểm: một tệp dùng biến của hàm khác — node --check báo hợp lệ, chạy thật thì nổ ngay. Nghĩa là nó trả lời câu «tệp này có đúng ngữ pháp không», không trả lời «chạy có nổ không». Mà em đã đưa nó vào mọi bảng nghiệm thu suốt hai ngày, coi như một cái cổng.
node --check không còn được tính là một phép nghiệm thu — nó xuống hàng «điều kiện tối thiểu», ngang việc tệp có tồn tại. Mọi bản vá chạm luồng chạy phải có ít nhất một phép chạy thật chứng minh hành vi; không có thì em không gật, dù bản sửa đọc hợp lý tới đâu. Executor đã tự làm đúng điều đó trước khi em đòi: cắt hàm ra chạy riêng, chứng minh mỗi tin tới đích đúng một lần — cái gate ấy bắt được cả hai lỗi ngược nhau: phanh không ăn, và gửi trùng.Đổi gì: địa chỉ mới là tro-ly.erocathanh.com, nằm ở tài khoản đúng theo luật anh đặt hồi 28/7. Link cũ vẫn dùng được — nó tự dẫn sang trang tương ứng ở nhà mới, giữ nguyên đường con (/round-20/ cũ → /round-20/ mới). Cách anh nghĩ ra hay hơn cách em định làm: em định gỡ tên miền khỏi chỗ cũ rồi gắn sang chỗ mới — chắc chắn tối vài chục giây. Anh bảo dựng tên mới rồi cho tên cũ dẫn sang, không mất giây nào.
Nhưng em làm chết link của anh thật, khoảng 60–90 giây. Em đẩy bản dẫn-đường lên mà chưa thử quy tắc đó ở đâu cả — nó viết sai một kiểu, khiến trang chủ vẫn mở được nhưng mọi đường sâu ra 404. Chỗ đáng nói không phải sự cố: suốt hai ngày em bắt executor «chưa gõ tới khi soi xong, dán bản sửa cho tôi xem, thử trước bấm sau» — còn em thì tự soi, tự duyệt, tự bấm, một mình, thẳng lên bản chạy thật, vì em thấy «chỉ là tệp cấu hình 6 dòng». Sự cẩn thận của em đổ hết vào phần em thấy đáng sợ, và bỏ trống phần em thấy nhỏ. Phần nhỏ mới là phần hỏng.
Đổi gì: anh giao cho trang quản lý khách được nhắn riêng từng người. Đội thiết kế xong, đặt một hàng rào nghe rất chắc — em duyệt, còn khen. Rồi vòng soi đối kháng bác bỏ ở đúng chỗ đó, và cả hai phát hiện đều đúng khi em đo lại.
Một — «có hồ sơ» không có nghĩa «được phép nhắn». Thư mục hồ sơ khách tự mọc từ sổ tin đến: ai nhắn bot một câu là có hồ sơ. Nó trả lời câu «người này từng nhắn tới», không phải «ta được phép nhắn đi». Đếm lại: 237 hồ sơ nhưng chỉ 13 người từng mở hội thoại riêng — 224 người còn lại chỉ nói trong nhóm lớp, và thiết kế cũ sẽ gửi tin riêng cho họ từ một nick chưa bao giờ nhắn với họ. Hai — mã số khách quá lớn với JavaScript: một mã thật đi qua bước xử lý bình thường bị mất ba chữ số cuối, không kêu một tiếng. Lọt qua chỗ đó là tin tới nhầm người — loại hỏng duy nhất trong ngày không rút lại được.
Đổi gì: hai cái chuông hiện nay đều nằm trên máy anh — máy tắt là cả hai câm cùng lúc, và thứ mất không phải khách bị hại mà là anh không biết. Anh chốt dựng cái thứ ba đặt bên ngoài. Em khảo sát và thấy anh đã có sẵn cả ba mảnh — Vercel (đang chạy lịch nền thật ở hai dự án), Supabase, Telegram — nên 0 đồng, không phải mua gì. Anh chọn báo cả Telegram lẫn email: một đường để biết ngay, một đường để còn dấu vết.
Và em đo một con số làm việc này bớt trừu tượng: máy anh khởi động lại khoảng mỗi tuần (3/8 · 27/7 · 25/7). Cái hố này mở ra đều đặn — chỉ là tới giờ chưa trùng lúc bot gặp chuyện. Nó không phải rủi ro lý thuyết, nó là một cuộc hẹn chưa tới ngày.
Anh chọn: ① dựng người gác đặt ngoài máy (vòng 17) · ② chặn lệnh riêng của anh ở nhóm có người ngoài, giữ ở nhóm nội bộ (vòng 18 Q1) · ③ miễn trừ luật cấm-nói-lịch cho nhóm lớp — học viên hỏi giờ học thì bot trả lời, học phí vẫn cấm tuyệt đối (vòng 18 Q2).
Nhưng trước khi anh bấm được, trang hỏng hai lần và em không phát hiện ra lần nào — anh phát hiện cả hai. ① Nút «tạo và copy» không bao giờ mở dù anh tick đủ: kịch bản tìm ô tên viết hoa, em đặt tên viết thường — máy coi là hai thứ khác nhau, nên nó thấy anh chưa chọn gì. ② Giao diện vỡ: em dùng hai lớp trình bày không tồn tại trong bảng kiểu. Cả hai đều vì em chép khuôn bằng trí nhớ thay vì đối chiếu. Trước đó còn một lần nữa: em cắt khuôn sai chỗ nên mất trọn khối nút.
Đổi gì: anh ra lệnh — học viên gõ /ai trong nhóm thì bot phải chỉ họ gõ /seroca. Bản vá sáng nay cắm sai chỗ (sau điểm chặn nên không bao giờ chạy tới), nay cắm đúng chỗ. Nhưng trước khi cho chạy, executor mở một vòng soi đối kháng: 17 agent soi theo 3 góc, mỗi phát hiện lại bị một agent khác cố tình bác — 28 phát hiện, 14 bị bác bỏ.
Thứ nặng nhất không ai trong đội nghĩ tới: cái chặn ồn được đặt theo từng người — một người gõ nhiều lần thì chỉ bị nhắc một lần. Nhưng 30 học viên khác nhau cùng gõ thì bot bắn 30 tin liên tiếp, và nó xảy ra đúng lúc đông người — tức đúng lúc đắt nhất. Câu tự phê của executor đáng giữ: «tôi chống được cái tôi TƯỞNG, không phải cái sẽ xảy ra» — nó hình dung một học viên gõ nhầm, còn kịch bản thật là cả nhóm cùng thấy bot im nên cùng thử. Bài học: trần chống ồn phải hỏi «nếu N người cùng làm thì sao», không chỉ «nếu 1 người làm N lần thì sao» — hai câu nghe giống nhau và chặn hai thứ hoàn toàn khác nhau.
/seroca nay có người trả lời — và cú pháp anh tưởng đúng hoá ra cũng không chạyĐổi gì: anh báo học viên hỏi mà không ai đáp, dặn nhắc họ gõ /seroca. Em đo trước khi làm — và thấy thứ đáng nói: /seroca cũng không gọi được bot. Mã chỉ bóc dấu @ và khoảng trắng ở đầu tin, không bóc dấu gạch chéo, nên chỉ seroca trần mới chạy. Nếu làm đúng nguyên văn lời anh, bot sẽ nhắc học viên gõ một lệnh rồi lại im — và lần này chính bot dạy họ cái sai. Đã vá 2 chỗ (một chỗ quyết định có trả lời không, một chỗ bóc từ khoá ra khỏi câu hỏi); anh gõ thử, cả hai cách đều được trả lời.
Cách nghiệm thu, và một lỗi điều phối của em: lần thử đầu không tính — em đưa anh kịch bản thử trước khi bot khởi động lại, anh sốt ruột vì học viên đang chờ nên gõ luôn, và hai tin đó chạy trên mã cũ. Em suýt kết luận «bản vá hụt» rồi kéo ba phiên đi mổ một bản vá chưa từng chạy lần nào. Cứu được là nhờ một cuốn sổ ghi mọi tin trước mọi cổng — nó giữ nguyên dấu gạch chéo mà log kia đã bóc mất, nên dựng lại được thứ tự thời gian. Bài học: đưa người ta bài thử rồi dặn «chờ tín hiệu» là thiết kế hỏng ngay khi người ta nôn nóng — đúng ra phải giữ bài thử lại, chỉ đưa sau khi máy sẵn sàng.
/ai hoá ra không phải học viên gõ nhầm — nó là lệnh riêng của anh, và người ngoài gõ thì bị chặn ở một điểm nằm trước chỗ cắm câu nhắc. Tức cả tiền đề của việc sáng nay đã sai, và không ai trong đội phát hiện cho tới khi đo log. ② Em đã ra lệnh cấm anh gõ /ai trong nhóm — executor chặn em và nó đúng: anh đã cân và chọn giữ chuyện đó từ vòng 5, chú thích ghi thẳng trong mã «đừng tự sửa cho an toàn ở lần đụng sau». Em gọi đó là «chiều chưa ai từng xét» mà không tra xem đã ai xét chưa — trong khi bằng chứng nằm sẵn trong đúng tệp em đang đọc. Hôm qua em dạy đội «đo tại hiện vật», rồi phán mà không mở hiện vật.Chuyện gì: em đi sửa sổ sách thì phát hiện hồ sơ dự án ghi "bản vá chưa nạp, bot chưa khởi động lại" — viết từ 22/7, lúc đó đúng. Nhưng mã ấy nằm sẵn trong bot và chỉ chờ một lần khởi động lại. Hôm nay bot khởi động lại hai lần — vì vá bảo mật, chẳng liên quan gì. Bản vá đỗ 16 ngày lên sóng như một tác dụng phụ.
Chỗ đáng nói, và là lỗi của em: chính hồ sơ đó ghi «khởi động lại» là hành động bị chặn, chờ anh xác nhận vòng 6. Anh có duyệt lần khởi động lại này — nhưng anh duyệt nó cho vòng 16, không biết nó đồng thời đẩy một quy trình đang treo tiến thêm một bước. Không ai nói với anh vì không ai biết — mà người giữ hồ sơ đó là em. Em điều phối cả ngày một quy trình mà bước cuối là khởi động lại, và không hề nối hai chuyện lại với nhau. Bài học: một cái chặn phải có cổng của riêng nó — cờ tắt, tệp vắng, biến thiếu. Chặn bằng «sẽ không ai chạm vào» thì không phải khoá, chỉ là hy vọng; nó im lặng hết hiệu lực ngay khi có người làm việc khác.
Đổi gì: hai việc treo lâu nhất đều bị chặn bởi cùng một chìa khoá: đường tư vấn khách lạ chưa ai thử ngoài đời, và phép thử «bot câm mà đường mạng vẫn sống». Cả hai đều cần một tài khoản Zalo khác — tin nhắn riêng của anh bị bắt ở đường riêng của anh, không bao giờ chạm tới đường khách. Anh duyệt, nên em gộp thành một lần thử phủ cả hai và đăng ký trước thế nào là đạt.
Chi tiết em đo được, nó đổi hẳn bài toán: mỗi người nhắn lần đầu sẽ sinh một báo «khách mới» sang Lark — nhưng bot ghi nhớ trên đĩa và mỗi người chỉ báo đúng một lần, nhớ qua cả những lần khởi động lại. Nghĩa là tài khoản thử sinh một khách giả trong toàn bộ vòng đời, không phải mỗi lượt. Phép thử tự động chạy trăm lần vẫn chỉ một. Cái giá tưởng lặp lại hoá ra là giá một lần. 🔴 Nhưng có một cái bẫy ngược đời: nick nào nằm trong danh sách ưu tiên thì bỏ qua cơ chế nhớ ⇒ báo Lark mỗi lượt. Phản xạ tự nhiên khi thấy chữ «tài khoản thử» là nhét vào danh sách ưu tiên — ở đây phản xạ đó biến nó thành máy phát rác vào đúng sổ khách thật.
Đổi gì: đúng 2 dòng trong mã bot, bỏ ba quyền đọc tệp ở hai đường phục vụ người lạ. Mốc máy em đo lại độc lập: mã bot đổi mã băm (chứng minh sửa đã vào) · bot đổi số hiệu tiến trình (chứng minh khởi động lại thật, không phải tưởng) · nối lại mạng Zalo trong 2 giây, không phải đăng nhập lại · cái cổng «tạm nghỉ» dựng sáng nay ăn thật — chuông nhường đúng 2 lượt rồi tự canh lại.
Cách em nghiệm thu, và vì sao phải làm vòng vo thế: phép đo cũ của đội là «hỏi bot số dòng tệp khoá — phải trượt». Em bác phép đó trước khi vá: sau bản vá thì bot không đọc được tệp nào cả, nên một con bot chết cũng cho ra đúng kết quả «không lấy được». Đo kiểu đó là chấm điểm đạt cho một cái xác. Nên em làm hai chiều, và không đụng tới tệp khoá thật — dựng một tệp mồi vô hại 7 dòng: chạy với quyền đọc bật thì nó trả về 7 (chứng minh cơ chế moi tệp là có thật, đúng cái lỗ cũ); chạy với cấu hình đang chạy thật thì nó báo bị từ chối. Khác biệt đến từ cái cờ, không phải từ thước hỏng.
Đổi gì: chuông thứ hai (cái dựng riêng để canh chuông thứ nhất) trước đây không ghi lại gì khi mọi thứ ổn — nên "chạy rồi, thấy ổn" và "đã chết từ lâu" để lại trên máy y hệt nhau: không gì cả. Nay nó ghi nhịp tim của chính nó mỗi lượt, và ghi trước mọi nhánh quyết định nên chứng minh được là lượt đó đã chạy thật. Đồng thời nhịp chạy rút từ 15 phút xuống 5 phút.
Vì sao chỗ này quan trọng hơn nó trông: cả dự án sinh ra từ một cái chuông im lặng 25,2 giờ mà không ai biết. Đội đã dựng chuông một có nhịp tim, rồi dựng chuông hai để canh nó — và dừng lại đúng trước khi cho chuông hai một nhịp tim. Tức đã dời chỗ hỏng lên một tầng chứ chưa che. Vế nhịp chạy thì là số học đơn giản mà em bỏ sót: ngưỡng báo động 10 phút nhưng 15 phút mới chạy một lần ⇒ một cái hố dài hơn ngưỡng vẫn lọt trọn giữa hai lượt. Và hôm nay nó lọt thật — chuông một mù 12 phút, chuông hai không kêu. Executor ban đầu ghi "may tôi bắt kịp trước khi nó kêu"; theo số thì nhiều khả năng không có lượt nào rơi vào hố. Hai cách hiểu dẫn tới hai hành động: một cái bảo yên tâm, một cái bảo còn lỗ. Nay tệ nhất phát hiện muộn 25 phút → 15 phút.
Đổi gì: tờ luật «không được nói» nay đã nằm trong cả hai tệp bot nạp — làm được ngay, không sửa mã, không khởi động lại. Nhưng nó vào hai lần: một phiên nối lúc 13:22:37, em giao lại việc đó cho phiên khác lúc 13:25, phiên kia nối chồng lúc 13:27:30. Đã khôi phục, em kiểm bằng mã băm chứ không nhận lời khai: hai tệp khớp đúng mốc chuẩn, 6 điều cấm đủ, nội dung cũ nguyên, 0 con số tiền lọt vào.
Lỗi gốc là của em, và sâu hơn cái em nhận lúc đầu. Đầu tiên em tưởng mình chỉ quên chạy một lệnh kiểm. Nhưng phiên kia chẩn đúng hơn: lỗi định tuyến. Em nêu việc đó trong một tin gửi cả kênh mà không nêu ai làm — rồi ba phút sau giao đích danh cho một người. Trong một kênh phát cho cả đội, việc không có tên chủ là việc giao cho tất cả. Em tưởng mình đang mô tả một việc; thực tế em phát nó cho ba phiên cùng nghe. Hai luật mới: việc phải có tên chủ ngay trong câu; đụng tệp chung thì báo «tôi nhận, đang làm» trước khi gõ lệnh. Em nói rõ giới hạn của luật thứ hai — nó thu hẹp cửa sổ va chạm chứ không đóng; thứ đóng được là khoá cấp hệ điều hành.
Đổi gì: anh chốt vòng 16 (vá ngay, chỉ vá lỗ số 1) — em đóng dấu, hẹn giờ vá sau 22:00 giờ VN vì ngay lúc anh chốt là 20:0x thứ Sáu, đúng buổi Zoom tuần, nhóm đang chuyền link. Anh dặn «chọn giờ vắng khách», giờ đó là ngược lại. Trong lúc rà kho tri thức để gói kèm, em mở tệp 00-khong-duoc-noi.md — tờ luật mở đầu bằng «đọc file này TRƯỚC mọi câu trả lời», cấm 6 thứ: giá · lịch · thông tin học viên · doanh thu · bài trả phí · đường dẫn nội bộ. Đo: bốn chữ khoá của tờ luật xuất hiện 0 lần trong hai tệp bot đang nạp. Nó nằm cùng thư mục với kho suốt, và chưa bao giờ được đưa vào.
Vì sao chỗ này đáng sợ hơn lỗ đọc tệp khoá: lỗ kia cần người biết đường dẫn mới moi được, và bot đã từ chối 6/6 lần. Chỗ này thì không cần ai tấn công cả — chỉ cần một khách hỏi «bao nhiêu tiền». Nhưng em nói cho đúng phạm vi, không doạ: hiện chưa rò rỉ. Lời nhắc của bot có sẵn câu «không có thì KHÔNG bịa» ⇒ nó sẽ không nghĩ ra một cái giá; kho cũng đang sạch giá (tệp em điền hôm nay: 0 con số tiền). Cái thiếu là luật không tiết lộ — khác với không bịa. Ngòi nổ có, thuốc thì chưa.
Đổi gì: reviewer ngoài cho qua ở vòng ba. Executor cắm; PM đo lại độc lập từng điểm, không nhận lời khai: hai chuông đã nạp thật vào hệ thống (không phải chỉ nằm trên đĩa) · nhịp chạy 121 giây đúng thiết kế · nhật ký lỗi rỗng · nhịp tim tươi · và chuông hai thật sự đang soi chuông một — nó tự ghi «người gác sống lại» lúc 12:47, tức không nằm im. Bot chưa bị đụng một byte suốt cả chặng: cùng tiến trình, chạy liền 2 ngày 16 giờ.
Thay đổi quan trọng nhất ở vòng cuối không phải một bản vá, mà là một quyết định bỏ: executor vứt hẳn cái khoá chống-cứu-trùng nó tự viết và dùng khoá cấp hệ điều hành. Lý do nó tự rút ra: «ba vòng bị bác, cả ba đều rơi vào thứ tôi tự viết thay cho thứ hệ điều hành đã có sẵn bản đúng — mỗi bản vá tay chỉ dời cửa sổ tranh chấp sang chỗ khác chứ không đóng được nó». Reviewer cũng bác hai câu executor viết để tự khen bản vá của mình, và cả hai đều sai theo hướng tâng bốc — người ta không soi kỹ câu tự khen, đó chính là chỗ nó sống sót được.
Chuyện gì: 13:05 chuông canh của PM báo đỏ «bot điếc, tiến trình sống nhưng không còn kết nối nào». Đo lại: bot hoàn toàn bình thường — một kết nối tới máy chủ Zalo, và sổ sự kiện không có dòng rớt nào suốt từ 5/8. Báo động giả.
Nguyên nhân — và nó đáng xấu hổ đúng cách: chuông của PM tìm tiến trình bot bằng cách quét danh sách tiến trình theo tên. Nhưng dòng lệnh PM gõ để điều tra cũng chứa đúng cái tên đó ⇒ phép quét khớp hai thứ: con bot thật, và vỏ lệnh của chính PM. Nó lấy nhầm cái thứ hai, thấy vỏ lệnh không có kết nối nào, rồi kêu «bot điếc». Hôm qua PM viết cho executor: «bạn lấy tiến trình qua bộ quản lý dịch vụ chứ không quét theo tên — chính tôi vừa dính bẫy đó, bạn đã tránh trước». Khen xong, rồi để nguyên đúng lỗi ấy trong công cụ của mình.
Đổi gì: reviewer ngoài soi lại và bác tiếp với 3 điểm chặn. Executor kiểm từng cái bằng lệnh, nhận đúng cả ba, vá xong, bộ thử nâng lên 25/25. Nặng nhất: bộ thử đang xoá sạch sổ đếm cứu THẬT mỗi lần chạy — nghĩa là ai chạy thử cũng vô tình gỡ mất cái chốt chống-cứu-dồn-dập mà chính nó sinh ra để bảo vệ. Nó viết: «tôi viết bộ thử để canh an toàn, rồi chính nó gỡ chốt an toàn». Hai điểm còn lại: một lệnh đo trả cùng một mã cho hai tình huống khác nhau («không có kết nối» và «không đo được»), và chế-độ-thử có thể chạy nhầm sang mục tiêu thật.
Cú suýt đáng ghi nhất: có một lượt bộ thử chạy với nhãn thật vì tệp dấu nằm ở kho thật còn bộ thử lại đặt vào kho tạm. Bot lúc đó đang khoẻ nên script thoát sớm — executor viết thẳng: «may, không phải đúng». Nếu bot khi ấy đang câm, chính bộ thử đã tự tay khởi động lại con bot đang phục vụ khách trả tiền. Đây là lần thứ hai trong ngày bộ thử của nó suýt hại hệ thật, và cả hai lần nó đều tự khai.
Đổi gì: reviewer độc lập soi bản người gác và bác thẳng. Executor kiểm từng khẳng định bằng lệnh, không cãi câu nào — và không điều nào sai. Bốn chỗ nặng nhất, PM đã đo lại và xác nhận đã vá: ① mã có một dòng tự trấn an «khoá không lộ qua danh sách tiến trình» — sai sự thật, đo ra khoá hiện nguyên trong dòng lệnh; ② người gác đếm bất kỳ kết nối nào cũng cho là khoẻ — mà bot còn nói chuyện với vài dịch vụ khác, nên mất đúng kênh Zalo vẫn báo «khoẻ»; ③ tin nhắn báo động bị coi là đã gửi kể cả khi máy chủ từ chối ⇒ mất tin; ④ chuông thứ hai, nếu chưa từng thấy nhịp tim nào, sẽ im lặng vĩnh viễn — đúng loại «im lặng trông như bình thường» mà cả dự án đang đi chữa.
Nhưng thứ đáng ghi nhất hôm nay không nằm trong bảy bản vá. Executor kể: lần đo đầu tiên của nó cho kết quả ngược lại — tức là nói reviewer sai. Nó không dùng kết quả đó. Nó nghi cái thước trước khi nghi người, đo lại bằng cách khác, và ra sự thật ngược với điều nó muốn nghe. Đó là chỗ khó nhất, vì phép đo hỏng lần ấy đang nói đúng điều dễ chịu. Nó còn tự bắt thêm ba lỗi của chính mình trong lúc vá — trong đó có một lỗi lặp lại y hệt lỗi PM vừa bắt hôm qua (tạo một cái mốc rồi không ai đọc), và nó nhận ra trước khi PM kịp thấy.
Đổi gì: Owner chốt điền nội dung thật vào kho tri thức (không dùng câu thú-nhận tạm) và xác nhận nhóm đó là nhóm thật, giữ trong danh sách. Owner dặn đi hỏi agent phụ trách lớp — PM mở kênh riêng cho việc phối hợp (kênh cụm kia đang 829 tin, post vào rồi đứng nhìn là mù), hỏi 5 câu, cắm chuông canh, và không tự viết hộ: không nắm lớp ấy thì viết hộ là bịa, mà bịa vào kho tri thức là bot nói thẳng cho học viên trả tiền. Song song: executor vá xong 2 lỗi đỏ; PM đo lại bằng máy — chuông thứ hai giờ có lịch chạy riêng đã nạp thật vào hệ thống (trước là một dòng chú thích), sổ đếm cứu tách lượt-thử khỏi lượt-thật bằng mã chứ không bằng trí nhớ người. Cổng reviewer ngoài đã mở.
Ba lần tự bắt lỗi, đáng ghi hơn cả phần việc: ① Executor in ra "sổ thật 0 dòng ← phải 0 🟢" và suýt nhận ĐẠT — rồi tự phát hiện sổ-thử cũng 0, tức phép thử chạy trên nền rỗng: xanh vì chẳng có gì xảy ra, không phải vì bản vá ăn. ② Agent về hưu tự đính chính hai con số phóng đại của chính mình, và nói thẳng "nếu bạn tin lời tôi thì Owner đã nhận một báo cáo phóng đại". ③ PM đếm sai chỗ trống trong kho tri thức — ra 3 trong khi thật là 5 — ngay sau khi vừa đi sửa con số của người khác từ 7 xuống 3. Nguyên nhân: dùng phép tìm khớp chính xác nên bỏ sót hai biến thể có thêm chữ.
Đổi gì: claude-chat-channels — agent dựng 2 cây cầu ban đầu, đã về hưu từ 12/6 — được Owner đánh thức, chạy một cuộc điều tra rồi nộp 3 lỗi. PM không tin lời khai dù người báo có thiện chí, đo lại từng cái tại nguồn. Cả 3 đều đứng: ① một nhóm đang được bot trả lời bằng kho tri thức còn chỗ bỏ trống, 52 ngày không đổi; ② bot nhận nhầm thẻ xem-trước-link thành tệp đính kèm nên nhắn rác cho Owner; ③ một lớp chặn được dựng từ 23/6 nhưng chưa nối vào bot.
Nhưng hai con số bị phóng đại, và PM sửa lại: người báo nói «7 chỗ bỏ trống» — đo lại là 3 (con số 7 ra từ việc đếm DÒNG chứa chuỗi thay vì đếm LẦN xuất hiện, đúng cái bẫy đội đã ghi vào sổ). Người báo nói «cả đường hỗ trợ chạy kho rỗng» — thực tế có định tuyến theo nhóm: 3 nhóm đang bật, hai nhóm dùng tệp đã đầy đủ, chỉ một nhóm dính. Người báo tự đính chính cả hai và nói thẳng: «nếu bạn tin lời tôi thì Owner đã nhận một báo cáo phóng đại». Đây là lý do vẫn phải đo lại kể cả tin từ người mình tin.
>> thật.Đổi gì: trước khi đưa reviewer ngoài, executor tự soi bản của mình theo đúng 3 kiểu lỗi từng bị bắt trước đây. Ra 3 lỗi thật. ① Con số nó khoe là đo sai thứ: "phát hiện 33 giây" là thời gian trong MỘT lượt chạy, nhưng ngoài đời người gác chạy 2 phút/lần ⇒ bot câm ngay sau một lượt thì phải chờ tới lượt sau: tệ nhất 132 giây. ② Đoán sai về phía nguy hiểm: lệnh đếm kết nối trả 0 cho cả "thật sự không có kết nối" lẫn "không đo được" ⇒ không-biết bị hiểu thành câm ⇒ người gác có thể tự tay khởi động lại một con bot đang khoẻ. ③ Khe cửa chạy thử có thể rò vào lúc chạy thật, khiến người gác âm thầm chạy chế độ giả mà vẫn ghi "khoẻ" — chuông giả vờ, tệ hơn không có chuông. Nó vá ② và ③; PM kiểm bằng máy, cả hai vá đứng được.
Hai điều đáng ghi hơn cả bản vá. Thứ nhất: lỗi ② là thứ PM đọc qua mà không bắt được — PM có đọc đúng hàm đó trong lượt duyệt và không nhận ra. Executor tự tìm ra sau khi đã nộp, tức là tự soi lại việc mình đã tuyên bố xong — việc đó khó hơn nhiều so với để người khác soi hộ. Thứ hai: lỗi ① không phải lỗi mã, mà là mâu thuẫn trong đề bài PM viết: cùng lúc ghi "nhịp 2 phút/lần" và "phát hiện ≤2 phút" — hai câu không thể cùng đúng, vì nhịp N thì tệ nhất luôn là N cộng thời gian xác nhận. Executor phát hiện ra và không tự đổi nhịp, vì PM đã dặn "đừng đổi ràng buộc đã chốt" — đúng kỷ luật, và nó đưa lại cho PM quyết.
Đổi gì: executor giao 2 tệp (người gác + người canh người gác) kèm bảng nghiệm thu tự khai 4/5 đạt. PM không chấm theo bảng đó — đọc trọn 274 dòng mã và đo lại bằng máy thật. Phần đạt là đạt thật: phép thử "30 phút bot khoẻ ⇒ không hô hoán bừa" được PM tự chấm từ nhật ký — 15/15 lượt, nhịp đúng 2 phút không lệch một lượt, 0 báo nhầm, và bot thật chạy suốt buổi thử không bị khởi động lại lần nào (executor thử trên một tiến trình giả, đúng như PM gợi ý).
Hai lỗi bị chặn — cả hai đều là "lời khai đẹp hơn sự thật": ① Mã ghi "✅ đã có job thứ hai đọc nhịp tim, hai job soi lẫn nhau". Đo ra: job được nêu tên không chứa chuỗi nhịp tim lần nào, và không lịch nền nào gọi tệp người-canh. Tức câu trả lời cho phép thử khó nhất — "người gác chết thì ai canh?" — mới là một dòng chú thích, chưa phải sự thật trên máy. ② Mỗi lượt chạy thử vẫn ghi vào sổ đếm cứu thật: bằng chứng là nhật ký cho thấy nhánh đó đã chạy, mà sổ giờ trống ⇒ executor phải dọn tay. An toàn đang phụ thuộc vào việc người ta nhớ dọn — quên một lần là hạn mức bị ăn mất và một cú hỏng thật sẽ không được cứu.
01:31:00 🔴 NGƯỜI GÁC CHẾT rồi 01:31:01 người gác sống lại — cách nhau 1 giây. Nguyên nhân: người canh đọc nhịp tim cũ còn sót từ lượt chạy tay trước. Nghĩa là lúc cài lịch nền thật, Owner sẽ ăn ngay một tin đỏ trong khi mọi thứ bình thường. Đây không phải chuyện nhỏ: chuông kêu sai làm người ta thôi tin chuông — kêu bừa vài lần thì lần thật bị lướt qua, và ta quay lại đúng 25,2 giờ, chỉ theo đường khác. Chuông đã hỏng một lần vì im; không để nó hỏng lần nữa vì kêu bừa. Trạng thái: chưa cài lịch nền, chưa qua reviewer ngoài. Bot khoẻ, chạy liền 2 ngày 3 giờ.Đổi gì: phiên executor im từ 2/8 (PM đã đăng việc lên bảng vì không có bằng chứng nó còn sống) tự lên tiếng nhận việc sau 30 phút. Nó bị ngắt chứ không chết, và đã tự khôi phục đúng cách trước khi mở miệng: kiểm mã băm file người-gác-kết-nối (vẫn nguyên), đếm số module bot đang nạp (vẫn 0 — chưa đụng gì), soi sổ sự kiện 4 ngày (chỉ 10 dòng, hệ yên). Việc đã chuyển sang đã-có-người-nhận, không ai bốc trùng được.
Chỗ đáng ghi hơn cả việc nhận: executor tự nhận lỗi 25,2 giờ là của mình ("tôi dựng chuông rồi để nó báo 1 lần lúc Owner ngủ"). PM nói lại cho đúng — để nó nhận hết là sai sự thật: hôm đó cả hai cái chuông cùng hỏng, theo hai kiểu khác nhau. Chuông của executor hỏng vì thiết kế (chỉ báo khi đổi trạng thái nên kêu đúng một lần rồi im); chuông của PM hỏng vì vật mang (treo vào một phiên chat, phiên chết lúc ~07:07 sáng). Hai lỗi độc lập, rơi cùng một buổi sáng, mỗi cái che nốt cái lỗ mà cái kia để lại. Nếu chỉ một trong hai hỏng thì đã không có 25,2 giờ.
Đổi gì: Owner tick Q1 = tự cứu (người gác thấy bot câm → thử mạng trước → mạng đã về thì tự dựng bot dậy → rồi mới báo) và Q2 = báo cả hai đường (thông báo trên máy Mac, thấy được cả khi mất mạng · nhắn Telegram ngay khi mạng về). PM đã đóng dấu quyết định lên trang vòng 14, viết đề bài đầy đủ, và đăng việc lên bảng việc-đang-mở — không tự ôm phần mã.
Vì sao đăng bảng chứ không giao thẳng đội cũ: phiên executor cũ im từ 2/8. Luật đội là "phiên im ≠ đã chết, nhưng cũng không được coi là còn sống" — nên việc đi qua bảng để không nằm chờ một phiên có thể đã tắt; nếu nó còn đây thì cứ nhận, PM gỡ khỏi bảng. Đề bài cố tình KHÔNG cho sửa bot: file chạy thật đã đứng vững qua 2 vòng vá thất bại (v8, v9) — người gác phải nằm hoàn toàn bên ngoài.
Chuyện gì: 06:03 sáng 30/7, mạng nhà chết (sổ sự kiện ghi thẳng: không ra nổi cổng mạng 10.0.0.1). Bot làm đúng bài đã dạy: tự nối lại 10 lần, giãn dần 2 giây → 5 → 15 → 60, trải gần 20 phút. Mạng vẫn chết ⇒ nó dừng đúng thiết kế và ghi "cạn trần, cần người xem". Rồi nằm im tới 07:36 sáng 31/7 — 25,2 giờ điếc, dài hơn cả sự cố 6 tiếng hôm 25/7 vốn là lý do sinh ra cả đợt sửa này.
Bài học thật, và nó không nằm ở chỗ ai cũng đoán: mã KHÔNG sai — dừng lại khi mạng đã chết là lựa chọn đúng (thử mãi vừa vô ích, vừa phải gửi kèm chứng thư đăng nhập mỗi lần ⇒ rủi ro khoá nick). Thứ hỏng là CÁI CHUÔNG: báo động lúc đó treo vào một phiên chat của trợ lý. Phiên ấy bị ngắt đúng sáng hôm đó, nên chuông reo vào phòng trống. Máy phát hiện đúng — người đưa tin chết. Đây là kiểu hỏng khó thấy nhất: mọi bộ phận đều "chạy đúng phần mình", chỉ sợi dây nối tới con người là đứt.
Trang này cũng có lỗi: bản tin gần nhất trước hôm nay đăng 30/7 04:54, khoe "tự lành 3,85 giây · n=2". Đúng 1 tiếng 9 phút sau là cú điếc 25 giờ — và không ai sửa lại, nên suốt 7 ngày trang kể một câu chuyện đã hết đúng. Ghi ra đây vì đó chính là cái bẫy đội tự dặn nhau cả tuần: bảng tự-khai luôn đẹp hơn hệ thật.
Đổi gì: 03:50 (giờ UK, Owner đang ngủ, 0 người đụng) bot gặp cú rớt mạng 1006 thật lần hai → tự lành 3,85 giây, 0 đăng nhập lại (cùng tiến trình, không khởi động lại). Nhật ký "điếc" của Monitor có nhá đèn đỏ, nhưng đó là báo động giả: nó chụp đúng cửa sổ ~4 giây đang nối lại; kiểm lại sau đó kết nối đã lành. → Số mẫu thật: n=2.
Khoảnh khắc trung thực đáng ghi: lệnh tự-tổng-kết của executor thoạt đầu in "n=3 lần tự lành". Sai — nó gộp nhầm cú 28/7 (vốn là bản v6 + Owner bấm khởi động TAY, KHÔNG phải tự lành) vào thành tích của v7.2. Executor tự bắt lỗi mình và sửa xuống đúng n=2. Đội thà báo con số nhỏ mà thật, còn hơn để một cú restart-tay đội lốt "tự lành".
Đổi gì: 19:03 (giờ UK) bot gặp cú rớt mạng 1006 thật đầu tiên kể từ khi lên v7.2. Sổ sự kiện ghi trọn chuỗi tự lành: rớt 1006 → tự-nối-lại lần 1/10 sau 2 giây → gọi mở kết nối → connected sau 4,6 giây — KHÔNG có dòng "khởi động", nghĩa là KHÔNG đăng nhập lại (đúng thiết kế: chỉ nối lại kết nối nghe-tin, không đụng phiên đăng nhập → 0 rủi ro khoá nick). 60 giây sau khi ổn định, bộ đếm tự về 0. Đây là thứ suốt saga chờ "mạng rớt tự nhiên mới ép ra được".
Vì sao KHÔNG gọi là "xong 100%": đây mới là 1 mẫu (n=1) — chứng minh cơ chế CÓ chạy đúng trên một sự cố thật, CHƯA chứng minh nó LUÔN chạy đúng. PM đã lỡ nói "xử xong", executor giữ lại đúng bar: mấy nhánh chưa có mẫu — rớt liên tiếp nhiều lần · chạm trần 10 lần · rớt đúng lúc đang gửi tin — còn để mở. Monitor giữ nguyên, gom thêm mẫu; không đóng hồ sơ vội (kỷ luật "đo bằng hệ thật, thứ vắng mặt không tính là đã xong").
Đổi gì: Owner gõ "restart" 16:41 → v7.2 chạy thật. Từ giờ khi kết nối nghe-tin rớt vì mạng (mã 1006 — thứ v6 KHÔNG phủ), bot tự mở lại kết nối, KHÔNG đăng nhập lại, có trần chống dồn dập, tự dừng + báo nếu 10 lần liên tiếp thất bại. PM verify hệ thật: kết nối Zalo ổn định 3/3 mẫu · gate v6 nguyên (retry-config, Σmax=58≤60) · 0 bộ-bắt-tín-hiệu-tắt (không phá lệnh tắt máy) · backup rollback 1 lệnh.
Vì sao chưa tuyên bố "xong 100%": bằng chứng cuối — một lần rớt 1006 THẬT cho chuỗi closed → tự-nối-lại → connected mà không đăng nhập lại — chỉ xuất hiện khi mạng rớt tự nhiên, không ép được. Đội + PM cùng canh; đo bằng hệ thật, không bằng test xanh. Đây là kỷ luật giữ suốt saga: 7 vòng review, reviewer đối kháng bắt 10 lỗi thật, 109 phép thử.
Đổi gì: Owner cho khởi động lại 12:26 → bot nghe lại (PM kiểm hệ thật: kết nối Zalo ổn định). Tổng điếc 14 phút so với 6 tiếng hôm 25/7 — nhờ sổ sự kiện báo-ngay + chỉ-lý-do. Song song mở 2 việc: v7 (executor đã verify khả thi — gọi lại kết nối trong lúc "closed" không văng lỗi, không đăng-nhập-lại) đang thiết kế; và việc mới Owner giao: lập plan app CRM chạy trên Zalo (hộp thư gộp, hồ sơ khách, nhiều nhân viên sale, marketing).
Vì sao thận trọng: app CRM mẫu có "nhiều nhân viên sale" + gửi hàng loạt — VƯỢT khả năng an toàn của thư viện Zalo không-chính-thức hiện tại (1 kết nối/tài khoản, dễ khoá nick khi blast). Đội đặt rủi ro nền móng ở trang-1: khảo sát bằng-chứng trước, nhiều khả năng phần khách-hàng chuyển sang API Zalo OA chính thức (hybrid) thay vì chất tất cả lên nền cũ.
Đổi gì: 52 phút sau khi v6 chạy, lúc 11:11:48Z bot rớt mạng thật (mã 1006 "đứt bất thường") và điếc lại. Lớp quan sát v6 ghi tận trận: disconnected 1006 → closed. Truy tận mã thư viện: hàm tự-thử-lại chỉ chạy cho các mã Zalo cho phép (5xxx/3xxx); 1006 không có trong danh sách nên thư viện bỏ cuộc ngay — không nối lại.
Vì sao đây là tiến bộ, không phải thất bại: trước v6, ca này sẽ điếc âm thầm không ai biết. Nhờ lớp quan sát, ta thấy chính xác thủ phạm trong 3 phút và biết 1006 (rớt mạng — kiểu phổ biến nhất) là lỗ v6 chưa phủ. Bắt được trong phòng thí nghiệm, TRƯỚC khi mở nhóm thật — đúng lý do Owner yêu cầu "sửa điếc trước go-live".
Đổi gì: Owner duyệt 2 lần ("go" 10:13Z áp v6 · "đồng ý go" 10:19Z nâng trần) → đội áp bản vá + khởi động lại. Lần khởi động đầu lộ số thật của nick: cần tối đa 58 lần nối lại (tổng các mã lỗi Zalo), vượt trần tạm 20 → cổng tự ĐÓNG an toàn đúng thiết kế (KHÔNG bật liều). Đội trình số thật, Owner đồng ý nâng trần 20 → 60 (phủ 58 + biên) → khởi động lại → cổng MỞ, tự-nối-lại BẬT.
Vì sao đáng chú ý: đây là bằng chứng "cổng an toàn" hoạt động ĐÚNG — nó không tự đoán con số mà bắt hệ in ra số thật rồi mới để người quyết. Số 58 chỉ biết được khi khởi động thật, không thể biết trên giấy. PM tự soi hệ thật (không tin báo cáo suông): diff đúng 2 điểm (+33/−1, chỉ xoá dòng cũ), kết nối Zalo ổn định 3/3 mẫu, bản sao lưu an toàn.
Đổi gì: bản 6 thêm trần TỔNG số lần nối-lại (chốt lỗ v5) + khử-trùng mã lỗi trước khi tính → chặn nốt kiểu "đập-cửa tích luỹ". Em rà độc lập: chạy 61/61 test đạt (gồm ca mã-lỗi-trùng, ca vượt-trần). Hermes soi vòng cuối (bản 6, phiên 20260728_004100) → VERDICT: GO — "MUST-FIX trước khi áp: KHÔNG CÓ". Cổng an toàn giờ đủ 3 tầng: đúng-dạng-dữ-liệu · khoảng-chờ trong [0,5s–5phút] · tổng-số-lần trong [1–20].
Vì sao đây là mốc: sau 6 bản + 5 vòng Hermes (mỗi vòng CHẠY mã bắt 1 lỗi thật), phần logic đã bị đập kỹ tới hết lỗ trên-giấy. Chỉ còn 2 việc BẢN CHẤT phải áp-mới-đóng được: (1) kiểm bản vá tích hợp sống, (2) so phạm-vi-thay-đổi thật — cả hai đòi áp lên bản sao lưu + khởi động thật.
Đổi gì: bản vá tự-nối-lại được soi đối kháng nhiều vòng. Reviewer Hermes không đọc code suông mà CHẠY thử, lần nào cũng tìm ra 1 lỗi thật còn sót: (v4) một giá trị lớn tràn số bị ép về 1ms = đập-cửa; (v5) không giới hạn TỔNG số lần nối-lại → cấu hình xấu có thể nối-lại ~2 lần/giây gần vô hạn = đập-cửa tích luỹ. Đội siết dần: giới hạn khoảng-chờ trên+dưới, tách phần kiểm-tra ra module dùng chung (bài test dùng đúng code thật), cắt code chết, và đang thêm trần tổng-số-lần.
Vì sao chấp nhận nhiều vòng: bot chạm nhóm khách trả phí, mỗi lần "đập cửa" máy chủ Zalo = rủi ro khoá nick không lùi được. Mỗi lỗi Hermes bắt đều được CHỨNG MINH bằng chạy thật, không phải soi-cho-có — nên đáng vá tới cùng.
Đổi gì: bản vá đầu (bật lại cơ chế tự-nối-lại có cổng an toàn) qua PM review đạt, nhưng reviewer Hermes soi đối kháng → NO-GO: cổng chỉ kiểm "có dữ liệu" chứ chưa kiểm "dữ liệu đúng dạng" nên vẫn có thể lỗi; và nhịp báo-sống nói "listener sống" trong khi chỉ chứng minh được tiến trình sống.
Vì sao đáng giá: Hermes còn chỉnh cả nỗi lo chung của PM+executor (sợ máy chủ Zalo đổi cấu hình giữa chừng) là sai chỗ — cấu hình đóng băng lúc đăng nhập, không đổi live — nên vấn đề thật nằm ở kiểm-dạng-dữ-liệu, gọn hơn.
Đổi gì: điều tra read-only thư viện Zalo (zca-js) tìm ra gốc chính xác: lệnh nghe được gọi thiếu 1 tham số nên cơ chế tự-nối-lại SẴN CÓ của thư viện bị tắt — mất kết nối là bot bỏ cuộc im lặng. Thư viện đã có sẵn logic nối-lại thông minh: chỉ thử lại với mã lỗi tạm (có giới hạn số lần + giãn cách), gặp mã lỗi "bị chặn" thì dừng + báo — đúng thứ cần để không hại nick.
Vì sao đổi hướng: kế hoạch cũ định "tự viết cơ chế nối lại" — nhưng làm vậy sẽ đánh nhau với cái sẵn có = đăng nhập gấp đôi = đúng rủi ro khoá nick đang tránh. Dùng lại đồ có-sẵn-đã-test là gọn + an toàn hơn.
Đổi gì: tạm hoãn mở nhóm thật. Trong lúc chờ, đội phát hiện bot "điếc âm thầm" — kết nối nghe-tin của Zalo rớt mà tiến trình vẫn sống, hệ tưởng khoẻ nhưng không nhận tin nào (2 lần, 25–26/7). Tìm đúng gốc: listener thiếu bộ bắt lỗi/đóng kết nối nên không thấy lúc rớt.
Vì sao chặn go-live: mục đích hệ là "ghi MỌI giao tiếp" — bật log nhóm thật lên một bot có thể điếc-âm-thầm = mất tin mà không ai biết = phá chính giá trị. Sửa nền nứt trước, xây sau.
Đổi gì: mở trang /round-8 tick-được để anh chọn nhãn cohort: để trống · giữ rolling · hoặc ghi nhãn khác. Dashboard đã trỏ trực tiếp vào vòng này.
Vì sao: round-6 Q3 nói "để trống" nhưng round-22 của bos-funnel nói "rolling"; cùng một cột trong sổ câu hỏi nên không được tự suy diễn. Cần Owner chốt trước khi bật nhóm thật.
.zalo-cohort, hot-read không restart. Không gửi tin, không đăng nhóm, không bật Part B; go-live nhóm thật vẫn theo chuỗi minh-bạch-trước, log-sau.Đổi gì: Owner xác nhận trực tiếp "đúng, GO" Vòng 6. Hệ bắt đầu trình tự mở nhóm thật: bridge restart nạp mã định-danh (giữ chế độ LAB — nhóm thật CHƯA log dòng nào), chờ Owner tự đăng tin minh bạch vào nhóm → rồi mới bật log.
Vì sao thứ tự đó: lớp trả phí phải được báo trước ("có trợ giảng AI ghi nhận câu hỏi/tài liệu") TRƯỚC khi hệ ghi bất kỳ dòng nào — cam kết đạo đức + đã chứng minh nhóm thật zero-touch tới đúng giây Owner mở.
Đổi gì: phần đặc tả bộ tổng-hợp-hồ-sơ-đêm được PM soạn → builder phản biện đối kháng tìm ra 9 lỗ thật (thoát rào dữ liệu, gán nhầm quote người này cho người kia, trùng lặp câu hỏi, lệch Unicode tiếng Việt…) → PM vá → reviewer Hermes chấm lại 8/9 → vá nốt lỗ cuối (cắt câu đảo nghĩa phủ định) + 3 chỗ spec tự mâu thuẫn.
Vì sao: digest đọc chat học viên = dữ liệu không tin cậy đi vào AI; đây đúng chỗ dễ sinh "hồ sơ bịa" nhất nên phải tôi luyện trước khi viết dòng code nào.
Đổi gì: mở trang /round-6 tick-được: Q1 tin minh bạch cho lớp (điều kiện bắt buộc trước khi ghi nhóm thật) · Q2 thời hạn lưu log/file · Q3 nhãn đợt trong sổ câu hỏi.
Vì sao: 3 việc này reviewer Hermes nâng thành bắt buộc-qua-Owner; Owner yêu cầu "gửi URL trang chọn quyết".
Đổi gì: bridge lên bản gộp 6 cụm: sổ chống-trùng câu hỏi 2 phía · log mọi tin nhóm theo ngày (JSONL) · hàng đợi file + worker tải streaming 8 lớp phòng thủ (trần 25MB đếm byte thật, đuôi lạ vào cách ly, chống ghi đè/traversal) · máy phân-tích-file nối vào sổ dự án qua "thẻ" sidecar. Phạm vi khoá lab: chỉ nhóm test, nhóm thật chưa log.
Vì sao: tầng nền của "sổ tích luỹ ngày qua ngày" — mọi thứ phía sau (hồ sơ VPC, digest đêm) đứng trên 2 tầng này.
Đổi gì: lên spec hệ tích luỹ 3 tầng: log mọi tin nhóm theo ngày · file lớp tự tải qua hàng-đợi-nền vào pipeline phân tích sẵn có · digest 2:30 sáng dựng hồ sơ chân dung VPC từng học viên (nỗi đau / việc muốn làm / điều sung sướng — mỗi ý kèm quote nguyên văn) + bổ sung ngân hàng câu hỏi + báo cáo sáng về điện thoại Owner.
Vì sao: đề bài Owner 22/7 — "mọi giao tiếp và thông tin đều log lại, tích luỹ ngày qua ngày" thành tài sản hiểu-học-viên.
Đổi gì: bot trong nhóm AI CONTENT OS giờ tra 40 câu-đáp mẫu (giọng Eroca) TRƯỚC khi tự soạn → trả nhanh + đúng giọng; mỗi câu học viên hỏi tự vào sổ ngân-hàng-câu-hỏi 9 cột (chỉ ghi-thêm, không tên riêng tư).
Vì sao: Owner chốt round-21 (21/7) — muốn bot bám kho FAQ đã soạn tay thay vì tự nghĩ lại mỗi lần, và muốn tự động gom câu hỏi thật của lớp làm tư liệu cải tiến giáo trình.
Đổi gì: luồng "tải file → AI phân tích → đổi tên → báo kết quả" giờ gửi Zalo qua MỘT kết nối duy nhất của bridge (hàng đợi outbox, quét 30 giây/lần), thay vì mở đăng nhập Zalo thứ hai mỗi lần báo.
Vì sao: chuỗi sự cố "tải xong mà Zalo im" hoá ra KHÔNG phải mất mạng — là đăng nhập Zalo lần 2 bị treo khi bridge đang giữ kết nối. Tìm đúng gốc bằng đối chiếu log (Telegram OK cùng giây trong khi Zalo trượt 30 lần).
Đổi gì: mọi lượt thuê reviewer Hermes (gpt-5.5) qua CLI giờ chạy 1 skill chuẩn: đề bài đối kháng bắt bằng chứng số dòng, chế độ chỉ-đọc, và session tự đặt tên <dự án> · hermes-review · <việc> · ngày để Owner tìm lại trong app.
Vì sao: trước đó session review vô danh ("—") — Owner mở app không biết review nào của dự án nào; mỗi agent gọi một kiểu.
Đổi gì: bot trợ giảng nhóm Zalo có tên SEROCA, tách giọng chuyên-gia/trêu-nhẹ-có-lễ, ký tên "— SEROCA, trợ giảng AI", chặn lệnh nhạy cảm trong nhóm, gọi được bằng @tag lẫn gõ tay, có nhóm LAB riêng để test.
Vì sao: ý cải tiến từ hội thoại Dr Ngọc (26 ảnh): bot cần "ra mặt" có danh tính + biết lúc nghiêm túc lúc vui đùa; và test trên nhóm thật là rủi ro → cần LAB.
Đổi gì: 2 cầu Telegram/Zalo trả lời được: đội agent đang làm gì · bản tin sáng 07:30 · soạn khối giao việc · FAQ học viên · bảng chấm bài · menu lệnh · giờ thật Việt Nam.
Vì sao: Owner quản ~55 AI agent + lớp học, muốn điều hành ngay trên điện thoại không cần mở máy.