solution-erp/.claude/commands/session-end.md

description

description
Đóng session SOLUTION_ERP — flush memory TOÀN roster + H2 harvest-gate (5-trục) + H1 tooling-chốt + H24 counter, sync MD/RAG, commit + push (squash→count→push 1 LƯỢT), eval. Run cuối mỗi session.

/session-end — Session closeout (FLUSH + WRITE + VERIFY + REPORT + COMMIT + EVAL)

Trigger cuối session. Em main chủ trì, gọi lại sub-agent đã spawn. ⚠️ Harness note (F2 re-verified S100): SendMessage khả dụng lại, NHƯNG flush-flow GIỮ NGUYÊN — agent đã tự update MEMORY khi return (BẮT BUỘC trong agent frontmatter) → em main đọc MEMORY on-disk để synthesize, KHÔNG cần re-spawn/SendMessage chỉ để flush.

📋 BƯỚC 0 — Show command body (visibility, no wait)

Em main PHẢI echo TOÀN BỘ nội dung command body này (đầy đủ Phase 1-6 + sub-section + guard rule) trong response đầu tiên ĐỂ ANH USER ĐỌC LẠI.

Quy trình (KHÔNG wait confirm):

1. Em echo full content command (raw markdown, KHÔNG tóm tắt, KHÔNG cắt)
2. 🔴 Sàn-2 — ĐẶT SENTINEL NGAY (TRƯỚC mọi flush): ghi closing: S<nn> @<ts> vào .claude/WAL.md.
3. Em proceed execute Phase 1 → 6 sequential ngay
4. Anh user điều chỉnh cuối session nếu cần thay đổi nội dung command (KHÔNG mid-flow interrupt)

🔴 Sàn-2 sentinel (H22 — adopt S122). ĐẶT ở BƯỚC 0, XOÁ ở §6.4. Ý-nghĩa: giữa 2 mốc đó = đang đóng sổ dở. Vì sao ở BƯỚC 0, không muộn hơn: phiên bị cắt giữa lúc đóng là ca nguy-hiểm nhất — WAL đã flush một phần, chưa push, trông như sạch. Đặt dấu TRƯỚC mọi flush ⇒ phiên kế thấy closing: treo và biết là bị cắt (Sàn-3 bậc-MẠNH ③, tiep.md §0.b). Net-zero: §6.4 vốn LUÔN chạy ⇒ thêm 1 dòng xoá = 0 chi-phí. Acceptance: chạy no-op trọn-vẹn ⇒ grep -c '^closing:' .claude/WAL.md = 0; cắt giữa chừng ⇒ phiên kế thấy dấu.

Phase 1 — FLUSH (sub-agent memory)

Điều kiện: Chỉ xử lý con đã spawn trong session. KHÔNG spawn mới chỉ để flush (agent đã update MEMORY khi return).

1. Đọc MEMORY.md update của sub-agent đã spawn (Tiered L1 HOT):

   • 🟦 investigator-codebase — research findings + audit results + schema/count grounding
   • 🟦 investigator-api — external docs/CVE/lib eval + cross-project port + RAG fleet
   • 🟨 implementer-backend — BE patterns applied + scope refusals (ACCEPT vs REFUSE)
   • 🟧 implementer-frontend — FE mirror SHA256 + Pattern 16-bis 4-place + KIND_CONFIG
   • 🟪 test-specialist — test bundle added + coverage gap + spec drift detected
   • 🟥 reviewer — anti-patterns observed + Smart Friend catches + claim verification
   • 🟢 cicd-monitor — Run verdict + bundle hash rotate + Mig prod + corpus drift
   • 🟫 tooling-auditor (monitor H1) — CHỐT tooling/docs-freshness 4-mặt + new-alloc audit (chạy ở §L.b(g))
   • ⬜ harvest-curator (monitor H2) — GATE harvest-integrity 5-trục + close-gate run-trace runs/<id>/ (TRI-ACCEPT — xem §L.b(f)) (chạy ở §L.b(d)(f))
   • 🔷 lead-view-auditor (monitor H24) — view LỆCH source của cái LEAD surface (chạy theo NHỊP §L.b(j), KHÔNG mỗi phiên)
   • 🔶 lead-omission-auditor (monitor H24) — cái BỊ THIẾU trong cái LEAD surface (chạy theo NHỊP §L.b(j), KHÔNG mỗi phiên)

2. Synthesize cross-agent learnings → integrate vào:

   • User auto-memory MEMORY.md (index — append entry mới, KHÔNG rewrite)
   • docs/rules.md, docs/architecture.md, docs/gotchas.md, docs/database/, docs/flows/
   • rules, architecture, gotcha, skill, daily, hand-off (docs/HANDOFF.md), DB, luồng DB, session log (docs/changelog/sessions/)

Phase 1.5 — §L AUTO-MAINTAIN (Gov-v2 keystone — deterministic, KHÔNG daemon)

Artifact home = docs/governance/error-ledger.md (RCA + Active-Guards index + 3-ledger triad mapping). G-015: đây là step lead chạy ở session-end, KHÔNG phải daemon tự-động-vô-điều-kiện.

§L.a — Deterministic detect (scan action-signature, KHÔNG để AI tự-phán): quét session theo bảng AS-1..AS-9 trong error-ledger. Mỗi hit → 1 RCA entry blameless (5-why + fix + guard). Bug-production = lỗi KÉP → 2 fix (vá code VÀ vá guard/eval-case). List AS mở — gặp class mới thì thêm.

§L.b — auto-maintain (a)→(j) (đủ HẾT, KHÔNG skip — thiếu = ledger thối). (d)(f) = H2 harvest-curator · (g) = H1 tooling-auditor (2026-06-07 Harness 1) · (h) = User-Mark H-12/13 (S79) · (i) = H18-D(a) (S100) · (j) = H24 lead-self-audit (S122):

🔸 Nhãn cũ ghi "8-step" trong khi thân đã có (a)→(i) = 9 — view-stale-count điển-hình, vá @S122 khi thêm (j). Từ nay KHÔNG chép số vào nhãn: đếm từ thân (B1).

• (a) summary-index += 1 dòng/session vào STATUS.md Recently Done (pointer, KHÔNG full-log).

• (b) Active-Guards (error-ledger): promote guard 2-strike (episodic→procedural) · mark verified nếu held qua session · retire theo net-effect (hại>lợi → gỡ).

• (c) chore-flag: agent L1 >~30KB → archive L2 · error-ledger open-entry quá ngưỡng · 0-byte memory check (AS-8) · 🌙 sleep-check (Harness-10b, S72): last_sleep_at null hoặc ≥7d (memory-budget.json) → INFORM gợi-ý /sleep-recovery-memory-l2 (KHÔNG auto-run) · 🗜️ Harness-11 A/D2 (S75): chạy powershell.exe -ExecutionPolicy Bypass -File scripts/memory-archive-gate.ps1 (DRY-RUN) → đề-xuất dồn-archive sub over-cap (A4 hysteresis 0.85 + A5 keep-floor 5 + A6 2-strike) + A7 NO-API L1-eval (pointer-resolve + byte-0-loss). Engine → docs/governance/harness-11-engine.md. DRY-RUN báo kế-hoạch; MOVE thật do em-main (D5 AUTO semantic-null sau khi xem). · 📊 Hot-feed %-print CUỐI phiên (Harness-15-v2 §G.4, S82): in composition Tầng-1 theo %/4-bucket SAU khi đã nạp/tăng trong phiên + Headroom còn-trống so cap role (token_governor.tier1_hotfeed_tokens). Đối-xứng session-start §2.1.6 (đầu phiên). Mục-đích: anh thấy Tầng-1 phình/teo ra sao + còn trống bao nhiêu → quyết chỉnh cap. 🔴 con-số = quyền anh (chủ-dự-án); em-main chỉ báo-%, KHÔNG tự-chỉnh. · 📊 Bảng-số ngân-sách + run-loop 2-tầng (M.B/M.C — Harness-20 adap S103, engine §M): chạy powershell.exe -ExecutionPolicy Bypass -File scripts/crystallized-backfill.ps1 → in BẢNG số THẬT (cap/hotload-bytes/tok-RANGE/headroom/target/backfill, live 0-hardcode) cạnh %-print. Tầng-1 ĐO (deterministic scripts) mỗi end = khối-số tươi (chống "khai-chạy-mà-không-chạy"); Tầng-2 TINH-CHỈNH on-signal (gap-mới/drift-vs-last/orphan-TĂNG/coverage-tụt → cảnh-báo ĐỎ + refine-in-session HOẶC carry-hi-prio nếu đứt-phiên) — KHÔNG nuốt tín-hiệu; weekly full-refine backstop. backfill default 0=OFF (owner). 🟡 M.C largely-already-met (H17-loop + %-print đã có ở dưới), khối-số = formalize. · 🧪 MFE retention opt-in (Harness-16 §H): lệnh kèm eval → chạy scripts/mfe-eval.ps1 cuối-phiên (retention; chênh vs baseline §2.1.6 = rot trong-phiên) → quyết-định 2-ca: thiếu-chỗ→TĂNG budget (anh quyết) / rot→SẮP-XẾP-LẠI (ưu-tiên-giá-trị). READS budget, KHÔNG ghi/auto-tune. · 🔁 H17 loop-REFINE (§I, S95 — harness-11-engine.md §I): lệnh kèm eval → chạy thêm scripts/memory-selfimprove-audit.ps1 (spec-audit CRITERIA+GAP) → áp bảng B1 tín-hiệu→hành-động: floor-rot→reinject-verbatim (ghi reinject-ledger.md CG-1 ≤1/N=3; đo-lại vẫn thiếu→escalate anh KHÔNG tự-reinject-lần-2) · repeat≥2→promote · old+valueless→archive-gate · raw→distill (/sleep-recovery-memory-l2). Phân-loại B3 (build-gap vs floor-rot) TRƯỚC reinject. em-main single-writer D9; loop CHỈ đề-xuất (D6). Light→skip.

• (d) flush agent-memory mỗi sub đã spawn session này — spawn-record 4-field {agent · task · nấc(agreed/executed/verified) · evidence}. (0 sub spawn → "n-a".) → ⬜ harvest-curator (H2) HỖ TRỢ: spawn → propose spawn-record cho mọi sub đã chạy → em main single-writer VERIFY → APPEND (B3 no-overwrite-unverified).

• (e) pending-request audit: request anh CHƯA-thực-thi đã log SPECIFICS chưa (KHÔNG placeholder).

• (f) 🌾 harvest-integrity GATE (⬜ harvest-curator H2 — 5-trục, Harness 1+2): verify spawn-record (d) đủ+đúng mọi sub TRƯỚC khi đóng — Coverage (0 silent-miss) · Completeness (đủ 4-field) · Placement (delta đúng agent-memory/X) · Corruption (moved-not-cut, no-mojibake/shell-baked) · Fidelity-FLAG (nghi bịa/on-behalf → escalate 🟥 reviewer, KHÔNG tự phán). + 🌊 close-gate C5 Layer3 (Harness-10, thay B5 wave-gom): với MỌI runs/<run-id>/ của session → VERIFY per-turn harvest đã xong (em-main đã viết runs/<run-id>/<stage>-synthesis.md phẳng h10-refine — run cũ S71: harvest/*.md — NGAY sau mỗi fan-out turn = C4 Layer1) + mọi runs/<run-id>/ của session có *-synthesis.md present (folder-scan — 🧊 tiêu-chí ledger CLOSE-beat retired H18-B S100). 🔴 IDEMPOTENT — close-gate chỉ VERIFY, KHÔNG re-APPEND (per-turn đã APPEND rồi → re-APPEND = DUPLICATE-HARVEST). 5-trục GATE giữ làm backstop. GATE = run còn thiếu bản-ghi-kết-quả (theo TRI-ACCEPT, xem dưới) HOẶC chưa đủ 5-trục thì CHƯA đóng.

  • 🔴 TRI-ACCEPT (S122) — định-nghĩa CANONICAL ở tiep.md §0, bước này CHỈ TRỎ (B1): ĐÓNG = dạng-1 <stage>-synthesis.md phẳng · dạng-2 harvest/<stage>-synthesis.md (C8 legacy S71) · dạng-3 heading ## synthesis trong THÂN run.md. ⚠️ Bản trước S122 chỉ nhận dạng-1 ⇒ đo thật: 8 dương-giả / 25 run = 32%, trong đó folder ghi chép đầy-đủ nhất (có cả cicd PASS + bundle-hash + smoke) vẫn bị xếp orphan. Gốc: gate hỏi "đã harvest chưa" (câu hỏi về NỘI DUNG) nhưng đo TÊN FILE ⇒ đo cái dễ đo, không phải cái cần đo.
  • 🔴 Nhận ≠ cho phép: TRI-ACCEPT = lưới PHÁT-HIỆN cho bản CŨ (đúng khuôn C8: tha di-sản, cấm viết mới kiểu cũ). Run MỚI BẮT BUỘC ghi dạng-1 — workflows/README.md:17 thiết-kế tên file mang nghĩa (RAW sub- ⟂ VERIFIED -synthesis.md). Thấy run MỚI ghi dạng-3 ⇒ NÊU (drift), đừng im.
  • 🔸 Kẽ khai thật: dạng-4 (kết-quả rải dưới heading tuỳ-ý, vd ## Stages + ## wf run-id) KHÔNG máy nào bắt được — nhận nó = phải chấp-nhận "bất-kỳ run.md nào có vẻ nói về kết-quả" ⇒ quá lỏng, thành vô-nghĩa. ⇒ để người phán. Đây là kẽ CÒN LẠI, KHÔNG phải chuyện đã xử.
  • 🚩 Sàn-5 — hậu-kiểm CỜ vs NỘI-DUNG (H22, adopt S122; informational, KHÔNG chặn): mọi runs/<id>/ sinh trong phiên này có dòng wf: … run=<id> tương-ứng trong WAL / session-log không? Lệch ⇒ NÊU + in danh-sách. Bắt ca "run dựng xong nhưng marker không ai đăng-ký" = vi-phạm Sàn-1 lộ ra SAU (hmw.js chỉ gate được đường của nó; raw Workflow/Agent đi thẳng — kẽ F2). 🔴 Scope theo git log -1 --format=%cI -- <folder>, KHÔNG theo mtime — mtime không bền (Dropbox resync ghi đè; R3-m5 chứng, FIX#4 đã bỏ mtime khỏi W0.5 vì đúng lý-do này). (v1:120 nguyên-bản ghi "mtime-trong-phiên" — đó là bản TRƯỚC khi mtime bị bác; đừng bê nguyên.) Acceptance: chênh-lệch 0, HOẶC in được danh-sách lệch.

• (j) 🔷🔶 H24 lead-self-audit — counter + spawn theo NHỊP (adopt S122; đối-xứng session-start §2.1.8):

  • (i) Đọc .claude/governance/.session-counter.json + h24_cadence (memory-budget.json) → in 1 dòng: counter=<n> · light <a>/<light_every> · deep <b>/<deep_every> · OVERDUE: <none|light|deep>. 🔴 Nhịp ĐỌC từ config, CẤM hardcode ở đây (detector governance-detectors.ps1 H24-2 fail-loud nếu key thiếu — không giả-định default).
  • (ii) OVERDUE → INFORM anh + đề-xuất spawn vai H24 tương-ứng. 🔴 KHÔNG auto-run (anh consent mới chạy, giống sleep-check (c)). Chạy xong → cập-nhật last_audit.{light,deep}_at_counter = counter hiện-tại. Lead = single-writer.
  • (iii) Flag → class: mỗi FLAG của 2 vai PHẢI thuộc enum ĐÓNG lead_self_audit.flag_classes. Vai KHÔNG tự chế class — finding không phân-loại được ⇒ báo verbatim + escalate anh để mở rộng enum. Cập-nhật class_repeat.counts; class nào lặp ≥ jump_on_class_repeat ⇒ kéo audit tới sớm.
  • (iv) 🔴 Nghi-thức RE-STAMP carry (GAP THẬT, vá @S122): khi ghi segment HANDOFF mới, ĐÓNG DẤU LẠI [carry:<slug>] cho MỌI carry còn mở — không chỉ lần đầu. Vì sao bắt buộc: carry-age detector đo streak = số segment LIÊN-TỤC mang cùng slug. Đo thật @S121: 45 logic-segment nhưng carry-lines=1 ⇒ streak luôn ≡ 1 ⇒ 0 fire VĨNH VIỄN, kể cả sau W2. Bằng-chứng: tra-bui-relogin chỉ đóng dấu seg#0 (S119), trong khi seg#2 (S118) nhắc đúng việc đó mà không có dấu ⇒ tuổi thật ≥2, máy đọc 1. ⇒ detector vacuous về CẤU-TRÚC, không phải sai ngưỡng. 🔴 Không retrofit dấu vào segment CŨ (§Q3 no-retrofit) ⇒ đường DUY NHẤT còn lại = re-stamp từ nay về sau; tuổi sẽ đo đúng từ S122 trở đi, và khai thẳng rằng carry mở trước S122 có tuổi đo-thiếu. Định-nghĩa "dòng-carry" (owner O3): = đoạn LOGIC NEXT anh / NEXT em trong mega-line — KHÔNG phải dòng vật-lý. ⚠️ Bẫy đếm: grep -c đếm DÒNG (=1 trên mega-line), grep -o | wc -l đếm occurrence (=n). Dùng đúng cái thứ hai.

• (g) 🔌 tooling-freshness CHỐT (🟫 tooling-auditor H1 — Harness 1): spawn → chốt 4-mặt (skill·sub-role·plugin·docs) đổi gì session này + new-alloc audit (skill/plugin MỚI chưa phân-bổ → đề-xuất gán em main + sub phù-hợp vai) + flag doc-drift/roster-lệch/count-stale. Propose → em main APPEND/sửa doc (single-writer). 🔴 G-015: 2 monitor = propose-only, em main VERIFY trước APPEND (Bash residual → KHÔNG "read-only enforced").

• (h) 🔏 User-Mark CHỐT cuối phiên (H-12/13 canonical §P/P7, S79 — harness-11-engine.md §E): đọc .claude/governance/ACTIVE-MARKS.md → (i) hiển-thị status-filtered (Active-High/Active hiện · Medium tóm-tắt · Disable ẩn) cho anh đọc lại (đối-xứng session-start §2.1.4); (ii) nếu session này có quyết-định cấp-governance MỚI (scope-check P6: đổi CANONICAL §-rule/authority) → chạy /user-mark-<cấp> DACI: adjust-gov → double-check → report-trước-đóng-dấu 3-7 tiêu-chí khách-quan (P4) → anh confirm → stamp RC-pqhuy1987-dd-mm-yyyy-hh-mm-ss; (iii) supersede/disable mark cũ (P5) → con-trỏ-xuôi + Active-High cần anh-confirm RIÊNG. 🔴 KHÔNG tự đóng dấu / đổi cấp trước khi báo (P4/P8). 0 quyết-định-mới → "n-a, chỉ hiển-thị".

• (i) 🎯 H18-D(a) outcome spot-check (S100 — harness-11-engine.md §J): session governance/review-heavy → chọn 3–5 artifact đã tự-động-qua-cổng trước đó (cicd GO verdict · detector verdict · monitor verdict · adap-report claim) → kiểm-lại TƯƠI bằng ground-truth (tính lại giá-trị đối-chứng · mở định-nghĩa gốc xem claim có thật-cover · đối-chiếu nguyên-văn nguồn). Gấp vào review sẵn có (chi-phí ~0). Sàn-vai trượt-THẬT khỏi nhật-ký → reinject-on-real-miss qua reinject-ledger.md CG-1 (≤1 lần/N=3 phiên, vẫn trượt → escalate anh — REUSE H17 §I B2, KHÔNG sổ mới). Light/hỏi-đáp → skip. (Nấc honest: dogfood n=1 S100 = mẫu hiệu-chỉnh, CHƯA "proven" — caveat 1 broadcast H18.)

Phase 2 — WRITE (update MD/RAG)

2.1 UPDATE/Re-rank MD/RAG đã thay đổi

• docs/STATUS.md (In Progress → Recently Done) + docs/HANDOFF.md (tiering: giữ current+2-3 session, archive cũ → session logs per feedback_status_handoff_tiering)
• rules, architecture, gotcha, skill, hand-off, DB, luồng DB, session log

2.2 Skill registry

• Liệt kê 6 skill. Dùng skill khi task khớp (KHÔNG tự suy luận lại)
• Skill staleness audit chỉ chạy theo lịch định kỳ (cron monthly — lịch kế → docs/STATUS.md, B1)
• Phân bổ skill mới phù hợp per agent (README matrix)

2.3 Memory entry mới

• Add memory entry NẾU phát hiện rule/gotcha/decision quan trọng chưa có (vd feedback_*)
• KHÔNG rewrite toàn bộ memory — chỉ append entry mới + update MEMORY.md index 1 dòng

2.4 Quy tắc consolidate MD/RAG (CRITICAL — đọc kỹ) [GENERIC — GIỮ NGUYÊN]

• Thứ 1: Rất quan trọng, đọc kỹ lại quy tắc consolidate đúng cách, những thứ quan trọng KHÔNG đc cắt, chỉ phân tầng cho gọn lại, và xóa double. Phân tầng để các session sau đọc lại đúng chính xác context, không bị over context, rất quan trọng đấy.
• Thứ 2: Nếu MD/RAG không có gì cần điều chỉnh thì KHÔNG cần phải cố gắng điều chỉnh, điều này cũng rất quan trọng.

Phase 3 — VERIFY (test + state)

3.1 Unit test verify

• dotnet test SolutionErp.slnx --nologo --verbosity minimal — verify count tăng đúng (vd 130 → 132 nếu thêm 2 test). Update STATUS Recently Done.
• Phase 9 UAT mode: feature test-after (có thể skip per chunk), vẫn npm run build × 2 app. Nếu chỉ docs/infra → ghi "N/A".

3.2 Sub-agent state

• Kiểm tra trạng thái spawn sub-agent (10 product/quality + 4 monitor INFORM-only; số vai canonical → docs/STATUS.md §Sub-agents, B1 KHÔNG chép số ở đây)
• Task bất kỳ phải phân việc đầy đủ đúng vai trò split boundary (BE→backend, FE→frontend, test→test-specialist)

3.3 RAG + MCP state

• RAG corpus health (chunk count delta, last_indexed_at). Re-index full = AI_INFRA op (charter v2).
• MCP rag-unified stdio launch verify (5 tool)
• Re-rank coverage: prompts đã store + đánh dấu re-rank đầy đủ chưa

Phase 4 — REPORT (plan status)

Đặt tên + tô màu cho Plan hiện tại, tiến độ + agent assignment:

Plan cha: [tên]
  Plan con: [tên]
    Task: [tên] — STATUS: 🟢 done | 🟡 in-progress | ⚪ pending
      - 🟦 investigator-codebase — [a]   - 🟦 investigator-api — [b]
      - 🟨 implementer-backend — [c]     - 🟧 implementer-frontend — [d]
      - 🟪 test-specialist — [e]         - 🟥 reviewer — [f]
      - 🟩 cicd-monitor — [g]            - 👤 chủ trì — [h]

SOLUTION_ERP report (per-session)

• Tóm tắt việc done + commit SHA + CI Run verdict + bundle hash rotate + plan progress
• (SE KHÔNG copy phần "6 sister report" của AI_INFRA host)

Phase 5 — COMMIT (release)

5.0 Squash wal:-trailing chưa-push (H22 — TRƯỚC commit-chốt) — PRE-PASS

🔴 §5.0 = PRE-PASS, KHÔNG phải cổng. Cổng thật nằm ở §5.2 (chained với push). Lý-do: hook fire ở turn-boundary NẰM SAU §5.0/§5.1 ⇒ đặt phép đếm ở đây là KHÔNG ĐỦ — đóng-sổ chắc-chắn còn làm bẩn path hook (§L.b ghi closing:, spawn sub → agent-memory/, ghi runs/) ⇒ mỗi turn-boundary +1 wal:.

# K = số subject LIÊN-TỤC '^wal:' tính TỪ HEAD XUỐNG, DỪNG ngay khi gặp subject KHÁC.
# 🔴 KHÔNG phải `grep -c '^wal:'` trên cả range — đó là phép đếm KHÁC (xem ghi-chú (b)).
K=0; while read -r s; do case "$s" in wal:*) K=$((K+1));; *) break;; esac
     done < <(git log --format=%s origin/main..HEAD)
[ "$K" -eq 0 ] && echo "K=0 → skip" || {
  # assert an-toàn: reset KHÔNG được tụt xuống DƯỚI remote
  [ "$(git rev-parse "HEAD~$K")" = "$(git rev-parse origin/main)" ] || \
    git merge-base --is-ancestor origin/main "HEAD~$K" || { echo "ABORT: HEAD~K tụt dưới origin/main"; exit 1; }
  git reset --soft "HEAD~$K"    # gộp wal-commit staged vào commit-chốt §5.1 (nội-dung đã ở index — file KHÔNG đổi)
}

(a) 🔴 CẤM dùng exit-code của grep -c làm điều-kiện — grep -c trả exit 1 khi đếm ra 0 ⇒ ca SẠCH bị hiểu thành lỗi. Luôn so-sánh SỐ: n=$(…); [ "$n" -eq 0 ]. (b) 🔴 CẤM đếm TOÀN lịch-sử (git log --format='%s' HEAD | grep -c '^wal:') — đó là MÌN NGỦ: đếm ra hàng chục (đo S119: 57) ⇒ -eq 0 không bao giờ đúng ⇒ chặn push VĨNH VIỄN ⇒ người sẽ bypass ⇒ cổng tự xoá chính nó. Phạm-vi đếm LUÔN = origin/main..HEAD. (c) 4 ca của FIX#3-bis KHÔNG cần ở đây. Chúng thuộc W0.3 (ca mổ một-lần, đã land 92de58f) nơi phải chọn rebase vs reset. §5.0 không bao giờ rebase ⇒ không có nhánh để chọn. Và trailing-K tự đúng cả 4 ca: đáy toàn wal: ⇒ HEAD~K chính là origin/main (≡ reset --soft origin/main của FIX#3(c)); đáy = commit-thường ⇒ chỉ gộp phần wal: phía trên, đáy không bị chạm; K=0 ⇒ skip.

• 🔒 Phạm-vi = CHỈ commit CHƯA-push (khoảng ahead-of-remote) → KHÔNG BAO GIỜ rewrite commit đã-push. wal: kẹp sâu hơn (sandwiched DƯỚI commit thường chưa-push) → GIỮ NGUYÊN, chấp-nhận noise (hard-safety đổi lấy không-rewrite-lịch-sử-đã-đẩy).
• Biên push-chết-giữa-phiên-trước: HEAD = commit-chốt cũ chưa-push → đếm DỪNG tại đó = chốt cũ KHÔNG bị fold, được push lần này (an-toàn, không mất commit).
• Squash xong = điểm review-diff wal-paths (AS-10 backstop dời về đây — hook đã commit local các residual-write nếu có; review diff các path WAL/agent-memory/runs TẠI ĐÂY trước khi chốt §5.1; push vẫn gated em-main).

5.1 Release + commit

• Kiểm tra release, commit task vừa hoàn thành. ⚠️ Update SolutionErp.slnx nếu có .cs/.csproj mới.
• Format: [CLAUDE] <scope>: <imperative message> + Co-Authored-By: <lead model hiện tại> <noreply@anthropic.com> (model = lead runtime phiên hiện-tại per BƯỚC 0.6 probe — KHÔNG hardcode; flip-chain canonical → docs/STATUS.md §Sub-agents)
• Scope: Contract · PurchaseEvaluation · Budget · Form · Workflow · Supplier · Auth · Admin · Api · App · Domain · Infra · FE-Admin · FE-User · Tests · Docs · CICD · Scripts · Skill

5.2 Push remote — 🔴 squash → count → push CHAINED TRONG 1 LƯỢT

🔴 SÀN push-guard (H22 · R3-C3 · adopt S122). BẮT BUỘC: KHÔNG được có turn-boundary giữa lần squash cuối và git push. Mỗi turn-boundary = hook fire = +1 wal: ⇒ tách ra là tự sinh lại đúng thứ mình vừa dọn. ⚠️ §5.0 chỉ là pre-pass — §5.2 RE-EXECUTE phép tính, vì §L.b/§5.1 đã làm bẩn path hook sau đó.

# ── CHẠY TRỌN KHỐI NÀY TRONG MỘT LƯỢT. KHÔNG tách turn. ──
recount() { local n=0 s; while read -r s; do case "$s" in wal:*) n=$((n+1));; *) break;; esac
            done < <(git log --format=%s origin/main..HEAD); echo "$n"; }

n=$(recount)
if [ "$n" -gt 0 ]; then                      # re-squash ĐÚNG 1 LẦN
  [ "$(git rev-parse "HEAD~$n")" = "$(git rev-parse origin/main)" ] || \
    git merge-base --is-ancestor origin/main "HEAD~$n" || { echo "ABORT: tụt dưới origin/main"; exit 1; }
  git reset --soft "HEAD~$n" && git commit -q --no-edit -C ORIG_HEAD 2>/dev/null || git commit -q -F .git/COMMIT_EDITMSG
  n=$(recount)
fi
[ "$n" -eq 0 ] || { echo "STOP: còn $n wal: trailing sau re-squash → BÁO ANH, KHÔNG bypass"; exit 1; }

# ④b EOL-check SCOPED (cạnh push — fix #9(i)). 🔴 INFORM, KHÔNG chặn (xem nấc dưới).
powershell.exe -ExecutionPolicy Bypass -File scripts/agent-frontmatter-eol-check.ps1   # exit 0 ALWAYS

git push origin main                          # → git.baocaogiaoduc.vn/vietreport-admin/solution-erp

🔴 ④b — nấc ĐÚNG của EOL-check (đừng nâng cấp nhầm): script exit 0 LUÔN LUÔN, cố-ý. Nó KHÔNG được phép chặn push. Vì sao: W0.6 spawn-probe @S121 BÁC BỎ giả-thuyết CRLF-fatal — một agent CRLF hoàn-toàn vẫn spawn qua cả 4 tầng (discovery→parse→spawn→exec). ⇒ check này chỉ enforce chính-sách .gitattributes eol=lf, KHÔNG mạnh hơn. Biến nó thành cổng chặn = overclaim đúng cái vừa bị bác, và là công-thức quen thuộc: báo-động-giả ⇒ người bypass ⇒ cổng tự xoá chính nó. Đừng tự viết lại bằng tay: script đếm scoped-set bằng glob (đo S122: 39 file = agents/ + commands/ + skills/), có synthetic control để chứng bản-thân reader còn chạy, và tự khai "GREEN-BUT-VACUOUS" khi 0 CR — tức nó tự từ-chối được ghi công cho một lần xanh rỗng. Một check grep CRLF chép tay mất sạch cả 3 tính-chất đó. Giá-trị thật = bắt REGRESSION về sau, không phải lần chạy xanh hôm nay. Luật đọc kết-quả: n>0 sau 1 lần re-squash ⇒ STOP + BÁO ANH. 🔴 CẤM lặp re-squash — lặp cùng logic ra cùng kết-quả = vòng chết; n không về 0 nghĩa là có thứ §5.0 cố-ý không đụng (vd wal: kẹp dưới commit thường, §5.0 mục 🔒) ⇒ đó là tin cần người xem, không phải thứ để máy cố thêm lần nữa. 🔴 CẤM else-branch precheck ref đếm toàn lịch-sử (mìn ngủ 57 — §5.0 ghi-chú (b)). origin/main EXISTS, đã verify ⇒ không cần precheck; nếu ref thật sự biến mất thì fail-loud báo anh, đừng đếm bù. Acceptance: (i) phiên có ≥2 commit thường xen wal: ⇒ n=0; (ii) phép đếm cuối và git push nằm CÙNG một transcript-turn; (iii) sau push, wal: trong 20 commit gần nhất không tăng so baseline.

🧪 ĐÃ fault-inject trên CÂY GIT THẬT (S122) — 10/10 PASS, không phải suy từ đọc spec:

• ca(2) base + wal + [CLAUDE] ⇒ K=0 ⇒ PUSH ĐƯỢC — 🔴 đây chính là shape FIX#3-bis dự-báo DEADLOCK; trailing-K KHÔNG deadlock (vì wal: kẹp dưới không nằm trong dải trailing ⇒ không bị đếm ⇒ không có gì để kẹt).
• ca(1) HEAD~K == origin/main — chứng trailing-K tự trùng reset --soft origin/main của FIX#3(c) khi đáy toàn wal: ⇒ nhánh riêng là thừa.
• ca(3) sau reset --soft: đáy [CLAUDE] không bị chạm + nội-dung wal: vẫn ở INDEX ⇒ 0 mất việc.
• Bẫy (a) tái-hiện được: grep -c đếm 0 → exit 1. Bẫy (b) tái-hiện được: đếm-toàn-lịch-sử=1 vs trailing=0 ⇒ đếm tổng chặn push vĩnh-viễn. Cả hai là sự-thật đo được, không phải cảnh-báo lý-thuyết.

• Docs-only commit → CI skip per gotcha #41 (paths-ignore docs/** + **/*.md + .claude/skills/**). Code commit → spawn 🟩 cicd-monitor verify deploy.

Phase 6 — EVAL (chunk + RAG)

6.1 Chunk MD/RAG update

• Cập nhật chunk MD/RAG content mới (Proposal/WorkflowApps/Phase 11...). SE-side: mcp__rag-unified__store_memory key facts (stopgap content-gap).

6.2 RAG eval

• ⚠️ Charter v2: RAG eval + full re-index (bootstrap.py, golden set, recall@5) = AI_INFRA op (cần VOYAGE_API_KEY). SE KHÔNG tự chạy.
• SE-side closeout: (a) verify store_memory chunk retrievable (1 search_memory rerank check); (b) flag drift/staleness lên AI_INFRA nếu last_indexed lag nhiều; (c) báo cáo broadcast nếu adopt infra change.

6.3 INFRA-ADOPTION report (cadence #4 — self-sustaining, AI_INFRA bundle 2026-06-01)

• NẾU session này adopt bất kỳ infra/governance change từ AI_INFRA (RAG fix / session-cmd / hygiene / charter / Gov-v2) → tự-sinh adoption-report §E TRƯỚC khi đóng (KHÔNG cần anh nhắc):
  • SERVER-VERIFIABLE (Gitea url): chain N commit sha (origin synced, tree clean)
  • Per-§: §A RAG · §B Gov · §C Hygiene (X/7 agent-mem L1 ≤30KB · bloat>50KB=0 — đo byte thật) · §D session-cmd (KHUNG added <sha> / skip <đã-có>) · §E evidence (sha list + integrity moved-not-cut) · §F mirror ledger committed <sha>
  • NẤC: agreed / executed / VERIFIED-self. Caveat by-design: L2 gitignored · CANONICAL-pull = trust.
• Surface report cho anh main relay AI_INFRA (1 lần báo = ACK+executed+evidence). Em main /session-start kế watch + double-check → cơ chế 2 chiều tự duy trì.
• Session KHÔNG adopt infra gì → ghi "N/A (no infra adoption this session)".

6.4 Reset WAL (H22 — bước CUỐI) + XOÁ sentinel Sàn-2

• 🔴 XOÁ dòng closing: (Sàn-2 — đặt ở BƯỚC 0). Bước này vốn LUÔN chạy ⇒ thêm việc xoá = net-zero. Xoá-dấu-không-tồn-tại = no-op vô-hại.
• Ghi-đè .claude/WAL.md về template rỗng (mạch dở phiên này đã đóng): updated/session/branch = — · goal = (trống — không có mạch dở) · chain = (rỗng) · next/verify = (trống).
• Acceptance Sàn-2: phiên chạy trọn-vẹn ⇒ grep -c '^closing:' .claude/WAL.md = 0. Phiên bị cắt giữa chừng ⇒ phiên kế THẤY closing: treo (Sàn-3 bậc-MẠNH ③ ở tiep.md §0.b) ⇒ tự-chữa nếu 3 tín-hiệu kia im, HỎI LẠI nếu không.
• 📝 Note: Stop-hook sẽ commit lần reset này thành wal-commit trailing sau turn cuối — vô-hại; phiên sau squash nó ở §5.0. (Đây là bước CUỐI, sau khi §5 đã commit/push xong — để WAL sạch cho /session-start §0.7 phiên kế đọc.)

---

Trigger sau Phase 6: Session đóng. Working memory có thể /clear an toàn (persistent memory đã flush + commit + push).