Files
solution-erp/docs/governance/adap-requests/2026-06-15-broadcasts-eol-lf-body-hash-stability.md
pqhuy1987 08c7036302
All checks were successful
Deploy SOLUTION_ERP / build-deploy (push) Successful in 4m28s
[CLAUDE] Skill: pin broadcasts eol=lf (.gitattributes) — stabilize email body-hash + adap-request federated
- .gitattributes broadcasts/** text eol=lf -> content_sha256 body-hash on dinh cross-checkout (autocrlf LF->CRLF was breaking verify; retroactively bao ve email harness-5-6)

- adap-request 2026-06-15-broadcasts-eol-lf-body-hash-stability: propose floor eol=lf + send-email self-check len AI_INFRA (mis-stamp CLASS evidence S58/S63)

- Follow-up adopt Harness 5+6 (dbbf89a)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 21:26:38 +07:00

2.7 KiB

adap-request — 2026-06-15-broadcasts-eol-lf-body-hash-stability

SISTER = SOLUTION_ERP (se) → đề-xuất NGƯỢC lên AI_INFRA. §M-gated (lý-lẽ + bằng chứng). Generated S63 (2026-06-15). ( adap-request channel Đợt-2 chưa live → tạm ghi file repo MÌNH; AI_INFRA /adap-audit đọc cross-repo read-only.)

1. Classify

INFRA (cross-sister — kênh email Harness 3 §N dùng CHUNG mọi sister). KHÔNG product, KHÔNG out-of-scope.

2. Problem (evidence-backed)

Email channel broadcasts/ dùng content_sha256 = SHA256(body canonical, LF) để verify (check-email §4b). Repo SE (và nhiều sister Windows) KHÔNG có .gitattributes pin eol → core.autocrlf=true convert LF→CRLF lúc checkout → body bytes đổi → body-hash verify FAIL dù nội dung KHÔNG tamper.

  • Bằng chứng SE (S63): email 2026-06-11-se-to-ai_infra-harness-4-runtime-verified stored ecf1d587… KHÔNG tái-tạo được bằng spec-canonical formula (brute-force 7 variant: as-is/TrimEnd/+LF/noStrip/wholeFile/CRLF/CRLF-TrimEnd — all miss). Khớp note AI_INFRA email-guide S58 "lỗi stamp hash email H4-report SE, không tamper, stamp đúng lần tới" → đây là mis-stamp CLASS, không phải one-off.
  • Cơ chế quan-sát: git warning "LF will be replaced by CRLF the next time Git touches it" xuất hiện trên MỌI broadcasts file lúc commit (S63 observed nhiều lần).

3. Proposal (floor đề-xuất)

Kênh byte-exact (broadcasts) PHẢI pin eol=lf qua .gitattributes ở mọi sister-repo → body-hash ổn định cross-checkout/cross-machine. 1 dòng: broadcasts/** text eol=lf. Cân nhắc:

  • Thêm vào bootstrap Harness 3 (install-1-lần/sister) — cùng lúc copy send-email/check-email cmd.
  • send-email skill thêm self-check: "verify .gitattributesbroadcasts/** text eol=lf TRƯỚC khi stamp" (chống stamp-trên-CRLF-sẽ-drift).

4. Local action (SE đã làm S63 — self-resolved)

  • Thêm .gitattributes broadcasts/** text eol=lf (commit S63).
  • Re-stamp email harness-5-6-adopt-report bằng spec-canonical formula, self-verified (8a247984… recompute == stored). → SE đã sửa đúng bài học mis-stamp. Đề xuất này = nâng floor cho SISTER KHÁC khỏi vấp lại.

5. Honest-caveat

  • Whole-file hash (transit-integrity, check-email §4a — copy byte==source) KHÔNG bị ảnh hưởng. Vấn đề CHỈ ở body-hash khi line-ending drift cross-checkout.
  • SE chưa verify AI_INFRA-side exact compute-method (chỉ có spec check-email §). Nếu AI_INFRA dùng canonicalization khác → cần align — đây chính là lý do propose floor CHUNG (1 formula + eol=lf cho cả mesh).