solution-erp/.claude/workflows/runs/2026-07-25-S151-h24-open-bookend/sub-lead-stale-S151.md

sub-lead-stale-auditor — S151 H24 bookend @open (hình B, light-scope)

• Vai: lead-stale-auditor (H24 §2(1) vai-STALE) — soi VIEW LỆCH SOURCE của cái LEAD surface.
• Nhịp: bookend @open S151, hình B vô-điều-kiện (KHÔNG theo counter). Counter = 25 (tick TAY, §tick-incident).
• Machine baseline: governance-detectors TOTAL 44 — ĐÃ chạy bởi em-main, tôi KHÔNG chạy lại. Mọi thứ dưới đây là lớp NGỮ-NGHĨA máy không phán được.
• Contract: INFORM-only, propose-only. Class ∈ enum ĐÓNG lead_self_audit.flag_classes (5 view-*).
• Trạng thái: DONE (2026-07-25).

---

FLAG-1 — view-stale-role-desc — SEV MED

view: .claude/agents/README.md:249 (§💾 Memory discipline) — liệt kê 17 tên vai có diary, rồi khẳng-định tường-minh: "…⇒ committed-state = 17 folder-có-MEMORY.md, khớp. ls thô có thể ra 18 dir gồm dir rỗng." Câu này còn nói 3 vai ring1/ring2/ring4 chỉ "tạo khi CHẠY lần đầu" và ring1-audit/ là dir RỖNG.

source (đo tươi, 2 tuyến độc-lập):

• đĩa: ls -1 .claude/agent-memory/*/MEMORY.md | wc -l → 20
• git: git ls-files .claude/agent-memory/ | grep 'MEMORY.md$' | wc -l → 20 (gồm ring1-audit · ring2-audit · ring4-audit)
• commit sinh 3 diary ring: git log -1 -- .claude/agent-memory/ring{1,2,4}-audit/MEMORY.md → 398d343 (S149–S150 closeout)
• đối-chứng máy: machine-baseline.md:18 — "H25-role-notebook: roster=20, diaries-ok=20"

lệch cụ-thể: view nói "committed-state = 17 folder-có-MEMORY.md" + "ring1-audit/ = dir RỖNG"; source nói 20 folder, cả 3 ring đều CÓ MEMORY.md và đều đã COMMIT.

🔴 Điểm máy mù (giá-trị của lane này): con số 17 không sai vì "quên bump" — nó sai vì chính commit 398d343 vừa land 3 diary đó lại không chạm dòng mô-tả. Đây là bản mô-tả cơ-chế ("folder tạo khi chạy lần đầu") đã thành hiện-thực ở đúng phiên trước, nhưng câu văn vẫn kể ở thì tương-lai. Đọc dòng này hôm nay, người kế-nhiệm sẽ kết-luận sai rằng 3 vai ring chưa chạy lần nào — trong khi ring1 + ring2 đã chạy THẬT @S150 (sub-ring1-S150.md 26.982B · sub-ring2-S150.md 30.461B).

resolve: dòng :249 bỏ con số + bỏ mệnh-đề "dir RỖNG", trỏ canonical (docs/STATUS.md §Sub-agents) theo đúng luật dòng-3 của chính file này ("vá bằng BỎ số, không ĐỔI số"); hoặc nếu giữ enumeration thì phải đếm phần-tử rồi so canonical (bài S143).

---

FLAG-2 — view-stale-count — SEV MED

view: .claude/commands/session-start.md:294 - mcp__rag-unified__list_projects — verify collection proj_solution_erp còn sống (baseline ~3076 chunks)

source (tôi tự gọi, không lấy của máy): mcp__rag-unified__list_projects → proj_solution_erp chunk_count = 2447 (last_indexed_at 2026-05-29). Đối-chứng canonical: docs/STATUS.md:453 row | RAG chunks | **2441** |. Đối-chứng máy: machine-baseline.md:9 — "chunk_count=2447".

lệch cụ-thể: view nói baseline ~3076; source nói 2447 (live) / 2441 (canonical). Lệch ~629 chunk ≈ 25,7%, và lệch cùng chiều với cả hai nguồn.

🔴 Điểm máy mù: đây KHÔNG phải một con số trang-trí — nó là mốc so-sánh của một phép kiểm sức-khoẻ chạy MỖI phiên (BƯỚC verify "collection còn sống"). Với mốc 3076, kết-quả 2447 đọc ra thành "collection mất hơn 600 chunk" ⇒ hoặc lead báo động giả mỗi phiên, hoặc (khả năng cao hơn, và tệ hơn) lead liếc qua rồi bỏ, tức phép kiểm đã chết mà vẫn còn trong nghi-thức. Máy chỉ biết "3076 ≠ 2447"; nó không biết con số này là cái thước, nên hỏng thước = hỏng cả phép đo đứng sau.

resolve: :294 bỏ số cứng, trỏ canonical docs/STATUS.md row RAG chunks (B1 derived-trỏ-canonical) — cùng khuôn mà :311 ở NGAY DƯỚI đã làm đúng cho test-count ("Baseline hiện tại → docs/STATUS.md Tests row (canonical — B1, KHÔNG hard-count ở đây)"). Hai dòng cách nhau 17 dòng, một dòng đã theo luật, một dòng chưa.

---

FLAG-3 — view-residual-asym — SEV MED

view: docs/STATUS.md:472 (§Recently Done S148), cuối đoạn: "→ log 2026-07-24-1800-S148-session-model-form-hub.md · commit 977ba18+."

source (git, đo tươi):

• git cat-file -t 977ba18 → commit (object CÒN sống trong repo local)
• git merge-base --is-ancestor 977ba18 HEAD → NOT-ancestor ⇒ KHÔNG nằm trên nhánh main hiện-hành
• git log -1 977ba18 → "[CLAUDE] Docs: S148 — session-model port form hub + /check-email 4 cửa + Sàn-3 dual-accept" (đúng nội-dung S148)
• commit S148 THẬT trên main: 2448393 (cùng tiêu-đề) + 932d607 + aaf95ef + 2f39a7e

lệch cụ-thể: view neo bằng-chứng phiên S148 vào 977ba18; source cho thấy sha đó đã bị squash/rewrite thay bằng 2448393 và ba commit closeout kế tiếp.

🔴 Điểm máy mù (và đây là ca TÁI PHÁT): detector broken-pointer soi đường-dẫn file, không soi sha có reachable từ HEAD hay không — nên nó im. Nguy hiểm thật nằm ở chỗ git cat-file VẪN trả commit: sha còn sống nhờ dangling-object/reflog trên đúng máy này, nên mọi phép kiểm tại chỗ đều xanh; nhưng trên một git clone mới nó biến mất sạch. Đây đúng lớp E-012/AS-16 bằng-chứng-tự-huỷ-sau-squash đã RCA @S143 (7 report + email phải re-anchor về 2757e41 + errata gửi hub). Lần đó re-anchor làm ở phía report; lần này phía git đã đổi mà ô narrative STATUS không được re-anchor ⇒ dư-lượng sửa-một-phía.

🔸 Khai thật về phân-loại: ca này nằm ở rìa enum. Tôi chọn view-residual-asym vì trục là một phía (git) đã đổi, phía gương (STATUS narrative) chưa theo. Nếu anh đọc nó thành một lớp riêng (con-trỏ-sha-chết) thì đó là đề-nghị MỞ RỘNG enum, không phải tôi tự chế class.

resolve: đổi 977ba18 → 2448393 (+ liệt 3 commit closeout S148 nếu muốn đủ), và thêm 1 phép kiểm rẻ vào nghi-thức closeout: mọi sha trích trong STATUS/HANDOFF phải git merge-base --is-ancestor <sha> HEAD = true.

---

FLAG-4 — view-stale-count — SEV LOW

view: docs/HANDOFF.md:25 (NEXT em, thuộc segment HIỆN-HÀNH dòng 1–25): "H24 deep CHƯA tới hạn (counter 24 − deep_at 17 = 7 < 15, mốc ~32…)"

source: .claude/governance/.session-counter.json → counter = 25 (tick TAY @S151, machine-baseline.md:22 §tick-incident) · đối-chứng machine-baseline.md:19 — "counter 25 ≥ light_at 24 ≥ deep_at 17".

lệch cụ-thể: view nói counter 24 / hiệu 7; source nói 25 / hiệu 8.

🔸 Khai thẳng, không thổi: kết-luận không đổi (8 < 15 ⇒ vẫn chưa tới hạn), nên đây là LOW. Lý do vẫn phát: dòng này là phép tính có ba số hạng in sẵn đặt trong segment hiện-hành để phiên sau đọc-và-tin; số hạng đầu vừa trôi ngay trong phiên này. Bài S148 (HANDOFF:15) đã trả giá đúng lớp này: "bảng chờ-anh là view dẫn-xuất, khẳng-định trạng-thái = phải chạm đĩa 1 lệnh".

resolve: hoặc bỏ hai số hạng dẫn-xuất chỉ giữ "deep chưa tới hạn — tra .session-counter.json vs h24_cadence.deep_every", hoặc re-stamp counter ở closeout S151.

---

FLAG-5 — view-residual-asym — SEV LOW

view: .claude/agents/README.md:302 (§🎯 Project tunings): "State (S38 — 2026-05-28): 40 mig · 84 tables · ~223 endpoints · 53 FE pages · 130 test PASS · 53 gotchas · 27 memory · 6 skills · 7 sub-agents · Phase 10 COMPLETE…"

source: docs/STATUS.md §CURRENT STATE — Mig 67 (:441) · tables 89 (:442) · endpoints ~253 (:444) · FE pages 68 (:445) · tests 532 (:448) · gotchas 83 (:449) · user-memory 31 (:450) · skills 6 (:451) · Sub-agents 20 (:452).

lệch cụ-thể: 8/9 con số lệch; riêng trục vai: view 7 sub-agents vs canonical 20.

🔴 Vì sao KHÔNG xếp vào "đóng-băng-có-chủ-đích" (đây là phần máy không phán được):

1. Dòng nằm dưới heading "Project tunings (SOLUTION_ERP)" — mục mô-tả cấu-hình ĐANG dùng, không phải mục lịch-sử; docs/_archive/** mới là vùng frozen.
2. .claude/agents/README.md là 1 trong 6 hot-load source luôn nạp mỗi phiên (memory-budget.json:102-109 crystallized_backfill.hotload_sources) ⇒ dòng này được bơm vào context mọi phiên, không nằm im trong kho.
3. 🔴 Quyết-định: cùng file, cách 17 dòng phía trên (:285-287), chính lead đã viết luật: "khi roster đổi hoặc số đo lệch >30% so lần ghi trước ⇒ đọc lại + cập nhật NGAY trong phiên đó" — và đã re-ground §Cost-reality @S144 theo đúng luật đó ("đóng băng từ thời roster 7 vai" → sửa). Đợt sửa ấy chạm một bảng roster-7 và bỏ lại bảng roster-7 thứ hai trong cùng file ⇒ đúng chân-dung sửa-một-phía. Roster 7→20 và mọi trục lệch xa hơn 30%, tức chính điều-kiện lead tự đặt đã kích-hoạt mà nhánh này không chạy.

resolve: hoặc đổi nhãn thành "State snapshot LỊCH-SỬ (S38) — số hiện-hành → docs/STATUS.md" (giữ giá-trị lịch-sử, cắt hiểu-nhầm hiện-hành), hoặc bỏ số + trỏ canonical như đã làm cho §Cost-reality.

---

INFORM-1 — canonical nghi sai, KHÔNG tự phán (báo riêng anh)

docs/STATUS.md:453 row | RAG chunks | **2441** | re-verify S126 … vs list_projects live 2447 (+6). Lệch nhỏ và row có ghi rõ mốc đo (S126), nhưng đây là ô canonical mà derived-doc phải khớp — nên theo contract của tôi (nghi canonical ⇒ INFORM, không FLAG canonical) tôi chỉ nêu: nếu anh muốn dùng row này làm thước cho FLAG-2, nên re-stamp về 2447 cùng lượt, kẻo vá session-start:294 xong lại trỏ vào một thước lệch 6.

INFORM-2 — chuyển lane (cái THIẾU, không phải cái LỆCH)

memory-budget.json khối measured có 17 row vai, thiếu ring1-audit/ring2-audit/ring4-audit trong khi roster = 20. Đây là hàng bị thiếu, thuộc lead-gap-auditor, không phải trục của tôi — nêu để không rơi vào khe. (Ghi-chú _note của khối tự khai "chờ full re-sync bằng script @drift-audit 2026-08-01", nên nhiều khả năng là nợ có chủ-đích, không phải rớt.)

INFORM-3 — VERIFIED-CLEAN (chống dương-giả + để ring2 có chỗ cắn)

Các trục tôi đã soi và KHÔNG phát flag, kèm số đo để ring2 tái-dựng được:

Trục	Đo	Kết luận
STATUS:452 Sub-agents = 20	ls -1 .claude/agents/*.md | wc -l = 21, trừ README.md ⇒ 20	✅ khớp (né đúng bẫy glob bắt README, README:6)
M-1 @S150 (STATUS:452 ô ring2-audit mang tên vai đã chết)	đọc lại :452 → nay ghi "no-self-exempt ≠ lead-stale/lead-gap (m-3; tên mới @rename S149)"	✅ ĐÃ VÁ, không tái-phát
STATUS:448 Tests = 532 (45D + 487I)	machine-baseline.md:8 run tươi S151 = 45 + 487 = 532	✅ khớp — canonical-poison S148 không tái-phát
STATUS:449 Gotchas = 83	máy: max anchor ### 83.	✅ khớp
Dư-lượng rename 5 vai trên bề-mặt HIỆN-HÀNH	Grep lead-view-auditor|lead-omission-auditor|h24-audit|tooling-harvest-audit|sleep-audit ngoài runs/**	✅ hit còn lại chỉ ở: thân mark đã ký (ACTIVE-MARKS:23,:44 — P4/P8 cấm sửa), chú-thích quy-nguồn .session-counter.json:24,35,37, và _context-s-3.md:44 = chính bản ghi RENAME. Tất cả là frozen/attribution ⇒ 0 residue mới
ACTIVE-MARKS chú-thích rename	:27-28 có khối "CHÚ-THÍCH S149 … BẢN KÝ GIỮ NGUYÊN" phủ đúng mark RC-…15-32-23 (§-target còn ghi lead-{view,omission}-auditor.md)	✅ xử đúng khuôn (chú-thích cộng thêm, không sửa bản ký)
agent-memory/ring4-audit/	S150 (sub-lead-stale-S150.md:167) báo thư-mục KHÔNG tồn tại; nay có + MEMORY.md git-tracked	✅ RESOLVED
Dải JUMP {5,4,4,3}+asym{1,4} · HANDOFF #14 ô canonical flip-chain	owner-held (#21) / câu hỏi MỞ	⏸️ KHÔNG re-litigate theo đúng ranh được giao

---

🔴 Khai giới-hạn coverage (bắt buộc — không được đọc thành "sạch")

• Mega-line chưa phủ trọn: docs/STATUS.md:6 (CURRENT header) và docs/HANDOFF.md:5 vượt trần Read 25K token/lệnh ⇒ tôi KHÔNG đọc hết hai dòng này; phần soi của tôi trên chúng chỉ tới mức trích-đoạn qua các lane khác. ⇒ "0 flag trên STATUS:6" KHÔNG có nghĩa STATUS:6 sạch — nó có nghĩa tôi chưa đo được. (Nhắc lại vết S150: trục H24-3 session-label hiện 0 file có hiệu-lực; im ≠ sạch.)
• Vùng FROZEN cố ý (STATUS:8-172 mega-diary · runs/** · docs/_archive/** · thân mark đã ký) — không soi staleness, đúng luật.
• Tôi không chạy lại governance-detectors.ps1; mọi số máy trích từ machine-baseline.md.

---

TOTAL

TOTAL: 5 FLAG + 3 INFORM

Phân-rã theo class (để tính jump_on_class_repeat):

• view-stale-count — 2 (FLAG-2, FLAG-4)
• view-residual-asym — 2 (FLAG-3, FLAG-5)
• view-stale-role-desc — 1 (FLAG-1)
• view-stale-status — 0
• view-stale-header — 0

🔸 Lưu ý cho lane ghi tally: view-stale-count và view-residual-asym đều đã fire ở các lượt trước (asym ∈ {1,4} đang bất-định, đã FROZEN chờ anh #21) ⇒ không tự cộng dồn, để em-main/h24-signal-write xử theo khoá _frozen_until_owner.