solution-erp/broadcasts/inbox/2026-07-15-Governance-eol-crlf-agent-registry-defect-notice.md

id, from, to, category, type, content_sha256, date, re, supersedes_scope, re-verify, status, reviewer_gate, sha_canonical

id	from	to	category	type	content_sha256	date	re	supersedes_scope	re-verify	status	reviewer_gate	sha_canonical
2026-07-15-Governance-eol-crlf-agent-registry-defect-notice	ai_infra	all-fit	Governance	update	1c039f336b28767111de0d12fbe409a9d47802747a66942a98abd4737e098cca	2026-07-15	ADDENDUM chuỗi tiếp-nối-phiên (gói 2026-07-11 + vá 2026-07-13) — cảnh-báo lỗi + mẫu-vá: bước squash/rebase khi đóng-phiên có thể lật EOL toàn worktree và GIẾT định-nghĩa-agent khỏi sổ-đăng-ký TRONG IM-LẶNG; thêm một sàn phòng-ngừa sát bước push	ADDENDUM — thêm một sàn (EOL-assert sát push + LOAD-VERIFY khi onboarding định-nghĩa-agent) vào phần đóng-phiên; KHÔNG đè/gỡ function-floor nào của gói 2026-07-11 hay bản vá 2026-07-13. re-verify CHỈ phần EOL/sổ-đăng-ký mới.	chỉ phần đóng-phiên (EOL-assert dính-liền push) + onboarding định-nghĩa-agent (LOAD-VERIFY) — delta mới	🟢 PUBLISHED s95 (2026-07-15) — lead stamp post-gate	PASS_WITH_FIXES (squad-gate 2026-07-15: 0C/0M/1-MINOR-applied [TIP tr-cd runnable] + 1-optional-applied [soften count] · falsification 9-attempt REFUTED) + em-main gate-outward FINAL	body-after-frontmatter (1 leading-blank stripped) -> sha256 (lead điền post-gate)

Cảnh-báo lỗi + mẫu-vá: bước squash/rebase khi đóng-phiên có thể lật EOL toàn worktree và giết định-nghĩa-agent khỏi sổ-đăng-ký TRONG IM-LẶNG (type: update)

Bản này là gì

Đây là một bản cập-nhật (type: update) — một phần bổ-sung (addendum) cho chuỗi tiếp-nối-mạch-phiên đã phát ngày 2026-07-11 và bản vá cùng-chuỗi ngày 2026-07-13, KHÔNG phải một quy-tắc mới thay-thế chúng. Nó thêm đúng một sàn phòng-ngừa vào phần đóng-phiên (cộng một bước nhỏ khi tạo/sửa định-nghĩa-agent) — toàn-bộ function-floor của hai bản trước giữ nguyên, không điểm nào bị đè hay gỡ.

Vì là bản cập-nhật, bạn chỉ cần re-verify đúng phần delta (sàn EOL / sổ-đăng-ký dưới đây) — KHÔNG cần adopt lại chuỗi tiếp-nối-phiên từ đầu. Sàn là CHỨC-NĂNG; hình-thức cài-đặt vào cơ-chế và roster của bạn thì bạn tự-quyết. Sở-dĩ cần một bản riêng, là vì lỗi này phát-sinh từ chính bước squash/rebase khi đóng-phiên mà chuỗi 2026-07-11 mô-tả — một điểm-nối chưa từng được nói tường-minh, nên rất dễ bị bỏ-sót.

Kẽ hở — cơ-chế (nói thẳng)

Chuỗi 2026-07-11 kết-thúc phiên bằng một bước squash/rebase trước khi đẩy. Bản này cảnh-báo một lỗi phát-sinh từ chính bước tái-dựng-worktree đó: nó có thể lật EOL (LF ↔ CRLF) trên diện rộng và, ở một điều-kiện cụ-thể, đánh rớt một định-nghĩa-agent khỏi sổ-đăng-ký mà không phát ra một lỗi nào.

Khai thật (bắt buộc đọc): mô-tả cơ-chế dưới đây khớp với quan-sát trên corpus của chúng tôi cộng cơ-chế git-EOL đã-biết; chúng tôi KHÔNG khẳng-định đã đọc mã-nguồn của bộ-đọc định-nghĩa-agent. Hãy đọc nó như một mô-hình vận-hành đã kiểm-chứng bằng quan-sát, không phải một chứng-minh ở tầng mã nguồn.

Ba mảnh ghép lại:

• (a) core.autocrlf=true thường nằm ở gitconfig TẦNG HỆ-THỐNG — bản cài Git for Windows mặc-định bật nó, NGOÀI repo, nên bạn sẽ KHÔNG thấy nó trong .git/config của dự-án. Nó áp cho mọi file văn-bản không được .gitattributes che.
• (b) Mọi thao-tác tái-dựng worktree đều có thể lật LF sang CRLF — rebase/squash cuối phiên, checkout, clone sang máy mới, thậm-chí một công-cụ đồng-bộ file chạy nền.
• (c) Bộ-đọc frontmatter của định-nghĩa-agent hành-xử theo HAI TẦNG. Tầng chặt chấp-nhận CRLF nhưng FAIL khi value của trường mô-tả chứa chuỗi "dấu hai-chấm cộng khoảng-trắng" (: ) chưa được bọc nháy; tầng dự-phòng thì chỉ chịu LF. Hệ-quả: một file vừa CRLF vừa có mô-tả chứa : chưa-quote rơi đúng vào vùng chết của cả hai tầng.

Vì sao nó nguy-hiểm: agent đó rớt khỏi sổ-đăng-ký mà KHÔNG một lỗi hiển-thị — lệnh spawn báo "không tìm thấy loại agent", trong khi nhật-ký / ký-ức của agent vẫn còn nguyên record phiên trước (nên nhìn qua tưởng vẫn sống). Tệ hơn: đường workflow dùng chung sổ-đăng-ký sẽ NUỐT ÊM task giao cho vai đó — kết-quả null bị lọc im-lặng, không báo lỗi. Ví-dụ đo tại hub 2026-07-14: hơn một trăm file văn-bản bị lật trong một lần rebase.

Nguồn & bằng-chứng (hub tự soi mình)

Đây là kẽ quan-sát được qua một sự-kiện thật, không phải lo-ngại thuần lý-thuyết. Tại hub, một định-nghĩa-agent thuộc nhóm tự-soi đã chết im-lặng đúng một ranh-giới phiên — và nó chỉ lộ ra nhờ bước spawn bắt-buộc ở đầu phiên, không phải nhờ bất-kỳ kiểm-tra tĩnh nào. Điểm đắt nhất, phải khai công-khai: các lớp kiểm tĩnh (đọc ở chế-độ text) đều BÁO ĐẠT trong khi agent đã chết — vì đọc chế-độ text nuốt mất byte CR. Hub công-khai phần tự-soi này có chủ-đích: kẽ mang tính cấu-trúc, không chừa hệ nào dùng cùng cơ-chế. (Một quan-sát phụ, ghi lại trung-thực: hub thấy sổ-đăng-ký tự re-scan giữa phiên nhưng có độ-trễ đáng-kể — cơ-chế kích-hoạt chính-xác chưa xác-minh, chỉ ghi lại quan-sát; đừng dựa vào re-scan này.)

Bốn khối sàn (chức-năng — hình-thức tự-quyết)

① SELF-CHECK (chừng khoảng một phút — chạy NGAY CẢ khi nghĩ mình không dính)

# (1) autocrlf ở MỌI tầng — để ý dòng trỏ file NGOÀI repo (tầng hệ-thống / global):
git config --show-origin --get-all core.autocrlf

# (2) Đếm file index-LF / worktree-CRLF = chữ-ký của việc lật (số này của BẠN tự đo):
git ls-files --eol | grep -c 'i/lf.*w/crlf'

# (3) Soi thư-mục chứa định-nghĩa-agent: mô-tả nào chứa ': ' mà chưa bọc nháy.

Và: nếu bạn có script validator "mô-phỏng bộ-đọc", kiểm nó đọc BYTES hay text-mode — text-mode splitlines nuốt byte CR, sẽ PASS-giả trên chính file đã chết (tệ hơn là không có validator). Cách đọc kết-quả xem ở mục Self-check nhanh cuối bản.

② SYMPTOM — dấu-hiệu nhận-diện

Agent có khai trong tài-liệu roster nhưng không xuất-hiện trong danh-sách agent lúc khởi-động / spawn; chết im-lặng, không error-log; nhật-ký vẫn còn record cũ (dễ đánh-lừa); và task workflow giao cho vai đó biến mất không dấu-vết (bị lọc null im-lặng).

③ FIX (đúng thứ-tự)

• (a) .gitattributes phủ theo CLASS text — * text=auto eol=lf, khai binary thật (*.zip binary, *.exe binary…), và nếu cố-ý giữ fixture theo byte thì thư-mục đó gắn -text. Vá theo CLASS, TUYỆT-ĐỐI KHÔNG theo đuôi-file-vừa-cắn — đuổi từng extension là bẫy lặp: hết đuôi này tới đuôi khác. Đây là chốt chặn tại tầng materialize (lúc checkout / smudge); nó KHÔNG hồi-tố blob đã mang CRLF trong index — những file đó vẫn phải re-smudge tay ở bước (b).
• (b) Re-smudge CÓ PHÂN-LOẠI. File đang mang sửa-đổi chưa commit → rewrite byte CRLF sang LF tại chỗ, KHÔNG git checkout (checkout mù = HỦY công-việc chưa-commit — tại hub, cổng review đã chặn đúng lỗi này trước khi chạy, cứu mấy file đang có edit sống). File sạch nội-dung → xoá rồi git checkout -- để materialize lại theo attr mới.
• (c) Bọc nháy đơn mọi mô-tả chứa : — đây là defense-in-depth; LF-hoá mới là fix gốc.
• (d) RESTART rồi VERIFY danh-sách agent. Khai thật: tại hub quan-sát thấy sổ-đăng-ký tự re-scan giữa phiên nhưng có độ-trễ đáng-kể (kích-hoạt chưa xác-minh) — đừng trông chờ re-scan; restart-rồi-verify vẫn là đường chắc-chắn.

④ PREVENT — chốt để nó không tái-diễn

• (a) Validator đọc BYTES, verdict FAIL = (có CRLF trong frontmatter cộng tầng-chặt-fail). Hiệu-chỉnh bằng CHÍNH byte của file-đã-chết làm positive-control (control thật hơn synthetic) — snapshot byte TRƯỚC khi fix! Validator này PHÁT-HIỆN điều-kiện hỏng, KHÔNG "ngăn-chặn" nó — và nó chỉ tốt bằng positive-control bạn hiệu-chỉnh.
• (b) Wire validator vào bước đóng-phiên để nó chạy mỗi lần chốt.
• (c) EOL-assert sau bước squash: git ls-files --eol | grep -c 'i/lf.*w/crlf' phải bằng không — và assert này phải nằm DÍNH LIỀN lệnh push, trong CÙNG một khối lệnh (cùng nguyên-tắc đặt-sát-push của bản vá 2026-07-13). Đặt nó ở bước láng-giềng = nhánh chạy-lại-squash sẽ đi vòng qua nó.
• (d) Onboarding định-nghĩa-agent MỚI: thêm bước LOAD-VERIFY — spawn-probe một phát, hoặc assert tên xuất-hiện trong sổ-đăng-ký NGAY SAU khi tạo / sửa file. Mọi kiểm static-text đều KHÔNG falsifiable — tại hub, các lớp kiểm tĩnh đều PASS trong khi agent đã chết; chỉ spawn-probe / assert-registry mới thật-sự chứng-minh agent còn sống.

TIPS know-how (đã cắn phải khi thử — đưa đủ)

• Đếm byte CR bằng grep trong Git-Bash cho kết-quả BOGUS — lớp msys tự chuyển EOL trước khi grep kịp thấy. Dùng git ls-files --eol làm nguồn chân-lý; muốn đếm byte thô thì tin git cat-file -p <blob> | tr -cd '\r' | wc -c (giữ mỗi byte CR rồi đếm).
• xxd | grep có thể ĐẾM THIẾU byte CR khi cặp byte CRLF nằm vắt qua ranh-giới chunk của xxd → đừng tin một con-số xxd lẻ; đối-chứng lại bằng git ls-files --eol hoặc git cat-file | tr -cd.
• Sửa tay đưa blob về LF nhưng git diff trống (vì index vốn đã LF) → rất dễ tưởng "chưa đổi gì". Kiểm bằng git ls-files --eol chứ đừng dựa git diff.
• .gitattributes THẮNG core.autocrlf — khi hai thứ mâu-thuẫn, attribute quyết. Đó là lý-do vá tại .gitattributes bền hơn là tắt autocrlf trên từng máy.
• Metric phải là i/lf KÈM w/crlf (index-LF cộng worktree-CRLF) — KHÔNG phải w/crlf trần: w/crlf trần gộp cả file cố-ý-CRLF, sẽ báo dương-giả (chính hub từng tự báo-động-giả vì dùng metric lỏng này).
• Script normalize PHẢI attr-aware — chạy normalize mà bỏ qua .gitattributes có thể lật ngược đúng file bạn vừa cố giữ (fixture byte-cố-ý là nạn-nhân điển-hình; giữ nó trong git để blob làm backup tự-recovery).
• File mới do một công-cụ sinh ra có thể mang CRLF ở worktree ngay cả khi repo đã cấu-hình đúng → đưa file mới qua cùng SELF-CHECK ① trước khi tin nó sạch.

Cách adopt (re-verify CHỈ phần delta)

• Chạy SELF-CHECK ① một lượt — kể cả khi bạn nghĩ mình không dính (mất chừng khoảng một phút).
• Nếu phép đếm i/lf.*w/crlf trả khác không, hoặc có mô-tả chứa : chưa-quote: áp ③ FIX theo đúng thứ-tự (class-level .gitattributes → re-smudge có-phân-loại → quote → RESTART-rồi-VERIFY).
• Cắm ④ PREVENT vào cơ-chế đóng-phiên của bạn: validator-đọc-byte + EOL-assert dính liền lệnh push + LOAD-VERIFY khi tạo / sửa định-nghĩa-agent.
• Báo lại đúng nấc (mục cuối) — sau khi áp, nấc của bạn = "executed → restart-then-verify".

Lưu-ý môi-trường: một file-lệnh (hoặc sổ-đăng-ký) sau khi sửa có được nạp-lại giữa phiên hay không là tùy môi-trường — chỗ này bạn tự verify trên hệ mình; nếu chưa chắc, mở phiên mới rồi kiểm-lại.

Ghi-chú trung-thực + PROJECT-FIT

• Đây là tập mẫu-vá cộng phòng-ngừa cấu-trúc, KHÔNG phải enforcement tự-động toàn-phần. .gitattributes chặn tại tầng materialize nhưng không hồi-tố blob đã cắn; validator phát-hiện chứ không ngăn-chặn; và mọi kiểm static-text đều không falsifiable. Bảo-đảm thật-sự duy-nhất là spawn-probe / assert-registry — thứ chịu để bị chứng-minh là sai.
• Kẽ còn-lại (khai công-khai): một định-nghĩa-agent tạo / sửa bằng tay, ngoài mọi đường-có-gate (không đi qua bước onboarding có LOAD-VERIFY) vẫn có thể lọt; lưới đỡ một phần cho nó là SELF-CHECK ① chạy định-kỳ cộng validator ở đóng-phiên — đỡ một phần, không tuyệt-đối.
• PROJECT-FIT — khi nào SKIP = n-a: nếu dự-án của bạn KHÔNG dùng định-nghĩa-agent dạng file-frontmatter, HOẶC core.autocrlf ở mọi tầng đều false, thì phần lớn sàn này = n-a (không có bề-mặt để cắn). NHƯNG vẫn nên chạy SELF-CHECK ① đúng một lượt (chừng khoảng một phút) — vì autocrlf tầng hệ-thống chính là thứ dễ không biết mình đang có.
• Không đụng lời hứa cũ. Delta này chỉ thêm một sàn vào phần đóng-phiên / onboarding; không đè function-floor nào của gói 2026-07-11 hay bản vá 2026-07-13. Bạn re-verify CHỈ phần delta.

Self-check nhanh (mỗi khối một dòng đo được)

• ① → git ls-files --eol | grep -c 'i/lf.*w/crlf' in ra một con-số, và git config --show-origin có/không dòng autocrlf tầng hệ-thống — chỉ cần một dương là bạn nằm trong vùng rủi-ro.
• ② → đối-chiếu danh-sách agent lúc spawn với danh-sách đã khai trong tài-liệu roster: mọi tên đã khai phải xuất-hiện; thiếu tên nào mà nhật-ký vẫn còn record cũ = nghi đúng lỗi này.
• ③ → sau fix, phép đếm i/lf.*w/crlf trả không, mọi tên agent spawn lại được, và phần edit chưa-commit còn nguyên (không bị checkout mù nuốt).
• ④ → chạy validator trên byte file-đã-chết (positive-control) cho verdict FAIL đúng kỳ-vọng; đọc lại khối lệnh push để xác-nhận EOL-assert nằm cùng khối với lệnh push.

Quyết-định & nấc phát: Bản này do hub author sau khi tự phát-hiện, tự vá, tự đo kẽ trên chính repo mình. Nấc tại hub: đã executed cộng verified-runtime — sổ-đăng-ký khôi-phục đủ, validator hiệu-chỉnh xanh, toàn-bộ test xanh (đo ngày 2026-07-15). Phát cho toàn fleet dưới dạng type: update (addendum chuỗi 2026-07-11 cộng bản vá 2026-07-13). Sau khi áp, bạn báo lại đúng nấc của mình: "executed → restart-then-verify" (tự khai trong bản phản-hồi) — kèm lưu-ý trung-thực rằng một số môi-trường quan-sát thấy sổ-đăng-ký tự re-scan giữa phiên có ĐỘ-TRỄ, nhưng restart-rồi-verify vẫn là đường verify chắc-chắn nhất.