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

description

description
Bootstrap session SOLUTION_ERP — load context, audit state (roster ĐẦY-ĐỦ + RAG + tests + monitor RE-REPORT), report plan. Run đầu mỗi session.

/session-start — Session bootstrap (READ + AUDIT + REPORT)

Trigger đầu session. Em main chủ trì, spawn sub-agent khi task match delegate criteria. ⚠️ Harness note (F2 re-verified S100): SendMessage KHẢ DỤNG lại (deferred tool — load qua ToolSearch; resume agent đã spawn TRONG-session, context giữ). Cross-session vẫn = fresh spawn (MEMORY on-disk auto-inject giữ context). agentId chỉ valid trong-session.

📋 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-3 + 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. Em proceed execute Phase 1 → 3 sequential ngay
3. Anh user điều chỉnh cuối session nếu cần thay đổi nội dung command (KHÔNG mid-flow interrupt)

📋 BƯỚC 0.5 — HMW-mode marker check (T3 — broadcast ultracode-hmw-mem-governance)

Em main đọc .claude/hmw-mode.on → BÁO ngay đầu response (anh khỏi quên đang ở mode đốt-token):

• Marker TỒN TẠI → 🔥 HMW-mode = ON — task LỚN sẽ chạy Workflow hmw fan-out theo /ultra-on (đốt-token cao). Gõ /ultra-off để tắt.
• Marker KHÔNG có → HMW-mode = OFF — vận hành thường (Agent-tool spawn lẻ / solo theo agents/README.md). Workflow fan-out chỉ chạy sau /ultra-on.

🚦 T4 + H6.1 (governed-ultracode, adopt S63): keyword "workflow"/"ultracode" = QUYỀN hỏi khi mode-OFF (+ "chạy workflow" → em TỪ CHỐI + nhắc gõ /ultra-on). 🟢 Mode-ON (H6.1): task SUBSTANTIVE (≥2 bước độc-lập · multi-file · sweep/audit/review/migration/research/verify-heavy) → em TỰ author+chạy Workflow HMW (KHÔNG cần gõ "workflow"; marker-ON = consent); TRIVIAL (<2-3' · 1-file · hỏi-đáp · governance-authoring single-writer) → solo. CẤM native /effort ultracode (mất guard).

📋 BƯỚC 0.5b — Engine-đắt per-invocation (H21 — adopt S110, supersede H19 marker)

KHÔNG còn mode/marker để đọc — .claude/fable-real-mode.on retired S110 (H19 marker-toggle nghỉ). Engine-đắt (nâng 1 vai lên hạng-nhất) CHỈ chạy trong lượt anh gõ lệnh, KHÔNG persist qua session/compact:

• /fable-real <vai> <đề-bài> → lệnh-A: vai anh gán chạy SINGLE top-model THẬT deep-pass, 1 lượt.
• /fable-clone <vai> <đề-bài> → lệnh-B: vai anh gán chạy ENSEMBLE tier-2 (N lane CÙNG vai + em-main synthesize), 1 lượt.
• Vai anh gán đích-danh ∈ roster (số vai canonical → docs/STATUS.md §Sub-agents — B1, KHÔNG chép số ở đây); thiếu/sai vai → em main hỏi anh, KHÔNG tự chọn.
• Mỗi run sinh spec-file 3-mục (engine propose → lead verify + ghi .claude/workflows/runs/<run-id>/spec-<tên>-<dd-mm-yyyy>.md → worker thực-thi THEO spec bơm qua args). ⚠️ Lead KHÔNG tự ý gọi engine-đắt (kể cả HMW-mode ON).

🧊 Lịch-sử: H19 marker-toggle + 2-vai-cố-định (reviewer + investigator-codebase), S101→S110 → retired H21; 2 lệnh chuyển per-invocation (vai anh gán bất-kỳ ∈ roster). Chi-tiết → harness-11-engine.md §K + fable-real-runbook.md.

📌 Mark RC-pqhuy1987-11-07-2026-20-42-01 (Active-High) neo con-số roster của thời-điểm ký (2026-07-11) — đó là ảnh chụp, KHÔNG phải giới-hạn. Anh chốt @S122: ý-định điều-khoản = "∈ roster" (bất-kỳ vai nào trong roster hiện-hành) ⇒ 2 lệnh engine-đắt hợp-lệ với TOÀN roster. Bản ký giữ nguyên (P4/P8) + chú-thích tại ACTIVE-MARKS.md.

📋 BƯỚC 0.6 — Model-availability check (H5 — adopt S63 · MTv3 reword S110)

Em main xác nhận lead model resolve được đầu session. Lead = frontier-class do ANH CHỌN per-session {Fable 5 (1M) Max | Opus 4.8 (1M) Max} — owner-choice hợp-lệ CHÍNH THỨC (đổi giữa phiên OK, ghi 1 dòng session-record); CẤM lớp model thấp (Sonnet/Haiku-class) ngồi ghế lead (§A1 floor).

Outage-path (H5, GIỮ): lead-model DOWN = lỗi "Model isn't available — claude-fable-5[1m]" → fallback /model claude-opus-4-8[1m] (Opus 4.8 · 1M · Max — top-tier, KHÔNG hạ §A1; KHÔNG sửa frontmatter agent — promote inherit tự theo lead → two-tier tạm collapse single-tier Opus, revert-FREE). Phản-xạ THỦ-CÔNG (không hook tự-switch).

Outage đóng: phiên ĐẦU TIÊN sau đó em main hỏi anh ĐÚNG 1 DÒNG ("model hạng-nhất resolve lại — giữ hạng-hai hay đổi?"), hỏi 1 lần, không lặp (thay auto-revert cũ). Flip-record từ nay gắn nhãn {owner-choice | outage} khi ghi: owner-chọn-hạng-hai ≠ outage → 0 caveat / 0 nghĩa-vụ revert; chỉ outage-fallback mới mang caveat tạm-thời.

Lịch-sử flip-chain đầy-đủ (S98→nay) = canonical [docs/STATUS.md §Sub-agents] (🔴 S106 gộp 1-chain per anh-confirm — reader này KHÔNG enumerate/cập-nhật mỗi flip; chống churn 4-file/flip). BƯỚC 0.6 probe MỖI phiên xác-định runtime SỐNG (per-session — KHÔNG tin note phiên trước, KHÔNG steady-state).

🔴 H23 note — LỖ CHƯA-TEST (khai bắt-buộc theo H23 §2(2), adopt S122). Nguyên-văn broadcast đòi khai: "thứ-tự ưu-tiên giữa 'tham-số tại spawn' và 'pin ở tệp định-nghĩa' khi CẢ HAI cùng hiện-diện — rất có thể chưa từng được test". Ở SE, cả hai ĐANG cùng hiện-diện: hmw.js trả alias → agent(…, {model:…}) trong khi frontmatter toàn roster = inherit (H8 all-inherit). 🔴 Chưa ai test bên nào THẮNG. Vì sao nghiêm-trọng: nếu frontmatter thắng ⇒ mọi tier:'opus' per-task = NO-OP ⇒ floor-2 vẫn thủng khi Fable UP — đúng lỗi reviewer đã bắt @S108. Phép thử ĐÚNG (H23 §6 phép-thử-phá #3): chạy 1 lane tier:'opus' KHI lead=Fable → đọc model THỰC-TẾ resolve → lệch ⇒ báo anh. ⚠️ Lead=Opus thì KHÔNG phân-biệt được (cả hai đường đều ra Opus) ⇒ DEFER tới phiên lead=Fable. 🔴 Khai thẳng: CHƯA test, KHÔNG giả-vờ đã test. Đang có (PA-2, anh chốt O1) = 2 lớp GIÁN-TIẾP, KHÔNG phải phép thử trên: PA-2a hằng-số TIER2_EXPECTED_FULL_ID trong hmw.js + PA-2b scripts/spawn-model-audit.ps1 so resolved-vs-expected. 🔸 Neo-tại-spawn = bất-khả-thi (param chỉ nhận enum alias sonnet|opus|haiku|fable) — và chính mệnh-đề "chỉ nhận alias" đó cũng CHƯA thử truyền full-id để xem có bị từ-chối không (fix #8a, anh đã ack hình-thức PA-2a+PA-2b).

📋 BƯỚC 0.6b — Registry-probe: RESTART rồi VERIFY danh-sách agent (broadcast ③(d) — adopt S122)

🔴 0.6 ở trên là MODEL-probe, KHÔNG phải REGISTRY-probe. Hai thứ khác nhau — trước S122 chỉ có cái đầu, nên "restart xong" không ai kiểm vai có sống thật không.

Registry sub-agent = ảnh-chụp lúc khởi phiên (đo 2 lần S120 + S121: file agent MỚI không hot-reload). Sau khi roster đổi:

• Vai có trên đĩa + có tên trong VALID_ROLES = 2 điều-kiện CẦN, KHÔNG ĐỦ. File .md đúng chuẩn vẫn có thể liệt-kê được tên mà chết lúc instantiate (vd frontmatter block-scalar parse ra rỗng).
• 🔴 Bằng-chứng falsifiable DUY-NHẤT = spawn-probe THẬT → spawn vai đó, nhận return. Static-check (ls + grep VALID_ROLES) KHÔNG đủ — đúng nguyên-văn broadcast ③(d): "RESTART rồi VERIFY danh-sách agent".

Khi nào chạy: phiên ĐẦU TIÊN sau khi roster đổi (thêm/xoá/sửa vai), hoặc khi nghi registry lệch đĩa. Roster ổn-định → skip (không cần mỗi phiên). Cách: spawn từng vai với task PROBE tối-thiểu (trả đúng ALIVE|<role>, cấm gọi tool) → đếm N/N sống. Đo S122: 14/14 ALIVE, 0 error, 0 garble; 2 vai mới lean nhất (~26K tok).

🔸 Khai chặt phạm-vi (S122) — đừng đọc thành "đã phủ hết": probe này phủ đường Agent-tool registry. Đường hmw.js VALID_ROLES → agentType là BỀ-MẶT KHÁC, chỉ chứng được khi có workflow THẬT gọi vai đó. Đổi roster = đổi CẢ HAI bề-mặt — 1 probe KHÔNG phủ cả 2. 🔸 tool_uses=0 ở probe = ĐÚNG THEO LỆNH (mình cấm gọi tool, câu hỏi không cần tool) — KHÔNG phải chữ-ký #53 (= tool_uses=0 CỘNG VỚI bịa đã-làm-việc). Đừng nhìn cột đó rồi tưởng dính garble.

📋 BƯỚC 0.7 — WAL-check mạch-việc-dở (H22 — adopt S111 · Sàn-3 wire S122)

Em main đọc .claude/WAL.md (sổ mạch-việc-dở H22 — ghi-đè ≤40 dòng, tầng persist = Stop-hook) → chạy Sàn-3 → 2 nhánh:

🔴 Sàn-3 = định-nghĩa CANONICAL ở tiep.md §0 — bước này CHỈ TRỎ, CẤM chép logic (B1). ⚠️ Bản trước S122 tự suy "sổ trống ⇒ sạch" — ĐÓ LÀ BUG, và Sàn-3 sinh ra để vá đúng nó (cùng cặp với tiep.md:15 cũ; lead mắc thật, không phải giả-định).

• (a) SẠCH = WAL không còn mục dở VÀ cả 4 tín-hiệu BẬC MẠNH Sàn-3 đều im → báo 1 dòng "WAL sạch — Sàn-3 4/4 im" rồi tiếp Phase 1 (no-wait).
• (b) CÓ mạch dở = WAL có [!]/[ ] HOẶC 🔴 Sàn-3 bắt ≥1 tín-hiệu MẠNH — KỂ CẢ KHI SỔ TRỐNG → BÁO goal + mục [!] đầu-tiên (hoặc tín-hiệu Sàn-3 nào kêu + đường-dẫn) + câu "có mạch dở — gõ /tiep để nối, hoặc bảo em bootstrap tiếp bỏ mạch" rồi CHỜ anh chọn. 🔴 NGOẠI-LỆ CHỜ DUY-NHẤT của quy-trình no-wait (BƯỚC 0 GIỮ no-wait — echo body rồi chạy thẳng).

🧭 Toàn-bộ Sàn-3 (3 bậc + DUAL-ACCEPT orphan [dạng-3 retired S123] + 2 kẽ khai thật) và quy-trình recovery (verify-trước-next · ground-truth-thắng · relaunch-cắt-gọt cho wf:) viết Ở MỘT CHỖ = tiep.md §0–§4. Chặn TRƯỚC Phase 1 READ = tiết-kiệm read-set ~368K khi anh chọn /tiep (khỏi nạp full context rồi mới nối).

Phase 1 — READ (load context)

Đọc theo thứ tự, KHÔNG skip:

1. CLAUDE.md (root) — AI agent context + quick rules (BE Clean Arch + FE 2 app + DB conventions + commit scope)
2. docs/STATUS.md — snapshot HIỆN TẠI (current state verified + recently done 3 session)
3. docs/HANDOFF.md — brief 5 phút: session trước làm gì + next tasks
4. docs/PROJECT-MAP.md — bản đồ tổng quan module
5. docs/changelog/migration-todos.md — atomic tasks theo phase (Phase 11 polish hiện tại)
6. docs/workflow-contract.md — state machine 9 phase HĐ (base pattern cho PE/Proposal workflow V2)
7. .claude/agents/README.md — decision tree + skill matrix + split boundary (roster ĐẦY-ĐỦ; số vai canonical → docs/STATUS.md §Sub-agents)
8. .claude/agent-memory/{spawned-agent}/MEMORY.md — L1 HOT auto-inject (Tiered Memory v1 ~30KB) + L2 archive/ Read-on-demand + L3 RAG search_memory just-in-time
9. User auto-memory MEMORY.md — auto-loaded bởi harness (index feedback_* entries)
10. Liên quan task hiện tại: docs/rules.md, docs/architecture.md, docs/gotchas.md (số hiện tại → docs/STATUS.md), docs/database/schema-diagram.md, docs/flows/

Phase 2 — AUDIT (state check)

2.1 Sub-agent state (topology — 10 product/quality + 4 monitor INFORM-only; số vai canonical → docs/STATUS.md §Sub-agents, B1 KHÔNG chép số ở đây)

• Check TOÀN roster đã spawn chưa:
  • 🟦 investigator-codebase — internal SQL/EF/grep/reference mirror audit
  • 🟦 investigator-api — external docs/CVE/lib/cross-project reference
  • 🟨 implementer-backend — .NET Domain+App+Infra+Api scaffold
  • 🟧 implementer-frontend — FE 2 app cookie-cutter SHA256 mirror
  • 🩷 frontend-designer — FE design/redesign visual-verification loop (FD1–FD10)
  • 🔵 database-agent — read-advisory DB lens (DB1–DB11: schema/migration-review/perf/concurrency)
  • 📄 office-document — Office document WRITE (docx·xlsx·pptx·pdf + form-engine — template/spec-extract/report/screenshot→docx, OD1–OD10)
  • 🟪 test-specialist — tests/ xUnit dedicated
  • 🟥 reviewer — adversarial pre-commit + live curl prod
  • 🟩 cicd-monitor — post-deploy Gitea + bundle hash + smoke
  • 🟫 tooling-auditor (monitor H1, INFORM-only) — tooling/docs-freshness 4-mặt (skill·sub-role·plugin·docs)
  • ⬜ harvest-curator (monitor H2, INFORM-only) — harvest-integrity 5-trục (Coverage/Completeness/Fidelity/Placement/Corruption)
  • 🔷 lead-view-auditor (monitor H24, INFORM-only, +S121 W2) — soi VIEW LỆCH SOURCE của chính cái LEAD surface (bản-tóm-tắt trỏ số cũ · tiêu-đề chưa bump · chú-thích-trạng-thái chưa lật · số trong mô-tả một VAI lệch · dư-lượng bất-đối-xứng)
  • 🔶 lead-omission-auditor (monitor H24, INFORM-only, +S121 W2) — soi CÁI BỊ THIẾU trong cái LEAD surface (việc rớt khỏi work-state · carry rớt/quá-già · yêu-cầu owner ghi chung-chung mất specifics · quyết-định-treo chìm · memory nạp dưới hạn-mức)
• 🔴 2 vai H24 = trục KHÁC H1/H2, KHÔNG gộp: H1 = tooling-freshness · H2 = harvest-integrity · H24 = soi chính LEAD. Class-flag lấy từ enum ĐÓNG lead_self_audit.flag_classes (.claude/agent-memory/memory-budget.json) — vai KHÔNG tự chế class. Nhịp = h24_cadence (cùng file), KHÔNG chạy mỗi phiên.
• Task match delegate criteria (ACCEPT) → BẮT BUỘC delegate (xem .claude/agents/README.md decision tree)
• Con cũ rảnh TRONG-session → resume qua SendMessage (khả dụng lại — F2 S100) HOẶC fresh spawn re-inject MEMORY; cross-session luôn fresh spawn
• Nạp full context project cho sub-agent spawn, giữ context sống đến cuối session
• Em main solo CHỈ khi: schema/UX/architecture decision · cross-stack tight · bug reasoning chain · gotcha #53/#54/#55 fallback (truncate/529)

2.1.1 Monitor RE-REPORT — H1 tooling-freshness + H2 harvest-integrity (2026-06-07 Harness 1)

Đầu session: 2 monitor sub BÁO LẠI trạng-thái + diff vs session trước (floor Harness 1 H1.2 + H2.2). INFORM-only — em main đọc + VERIFY→APPEND nếu có delta hợp-lệ (B3), KHÔNG sub tự sửa.

• 🟫 tooling-auditor (H1): spawn → báo tooling-state 4-mặt (skill · sub-role · plugin · docs) + DIFF vs last-session (THÊM/ĐỔI/XÓA/stale). Bắt drift doc-vs-thực-tế ngay đầu session (vd roster/count lệch, skill stale, plugin pending).
• ⬜ harvest-curator (H2): spawn → báo harvest-MD mới (run-trace runs/<id>/ — file sub-*/*-synthesis.md phẳng h10-refine / sub-agent / agent-team kể từ last) + delta mồ-côi chưa-APPEND + scan runs/*/ tìm folder có run.md mà *-synthesis.md VẮNG/0-byte = orphan run (🧊 tiêu-chí ledger-⏳ retired H18-B S100; run cũ S71 dual-accept harvest/<stage>-synthesis.md) (C5 Layer2 post-exec rescan — bù khi C4 per-turn miss hoặc session trước chết giữa run). Bắt 0-byte memory (gotcha #53) + delta chưa thu-hoạch.
• Cơ-chế = báo-lại-diff đầu session (FORM tự do trình bày). 2 monitor spawn parallel OK. Light session / hỏi-đáp → có thể skip; bug/feature/multi-agent/wave session → nên chạy.

2.1.2 Memory L2 budget-audit (Harness-9 — 2026-06-17)

Read-side "vật-chất-tối": archive agent-memory/<sub>/archive/*.md KHÔNG vào RAG. Inject mục-lục (archive/_INDEX.md), nội dung verbatim + .gist.md đọc-theo-nhu-cầu. "Inject tấm bản-đồ, KHÔNG inject lãnh-thổ."

• 🌙 Sleep-check (Harness-10b, S72): trong lúc đọc memory-budget.json (cùng file budget-audit), lấy last_sleep_at → nếu null HOẶC today − last_sleep_at ≥ 7 ngày → INFORM gợi-ý chạy /sleep-recovery-memory-l2 <agent|all> (nén L2 verbatim→gist additive). 🔴 KHÔNG auto-run — anh consent mới chạy.

• Đọc .claude/agent-memory/memory-budget.json → so kích-thước THẬT _INDEX.md mỗi sub vs cap. Nếu cắt-cho-vừa-ngân-sách đang rớt dấu-mốc quan trọng → bump budget (chốt-chặn chống "quên chỉnh ngân sách"). Đo lại bằng scripts/measure-agent-memory.ps1 (seed-by-measure — KHÔNG đặt cap bằng số tưởng tượng).

• L1 over-cap → curate L1→L2 (byte-exact additive) + build/refresh _INDEX.md (con-trỏ substring sha-keyed, fallback Ctrl-F) + <period>.gist.md (nén 4-field, distill-gen counter, verbatim FROZEN). Rollout đầu: 4 over-cap sub (S70).

2.1.3 Harness-11 D1 — DÒ+BÁO governance-detectors (2026-06-18 S75)

Engine bộ-nhớ-và-governance tự-bảo-trì spec → docs/governance/harness-11-engine.md (canonical — KHÔNG copy luật ở đây, B1). DÒ tự-động; SỬA qua em-main single-writer (D6/D9).

• Chạy powershell.exe -ExecutionPolicy Bypass -File scripts/governance-detectors.ps1 → báo cờ: C1 con-trỏ-gãy (gotcha#/wikilink) · C2/B3 derived-doc stale vs docs/STATUS.md canonical (mig#/test#/gotcha#/table#) · C3 vocab-fork (1-khái-niệm-nhiều-tên). NO-API, DÒ+NÊU-CỜ-only KHÔNG tự sửa (D6 tầng). Cờ → em-main soạn bản sửa (gated B4).
• Nấc: detector = LƯỚI giảm-sót (khoảng-mù giữa 2 nhịp), count-token soft-net có false-pos (sev LOW khi |lệch|<10) → đọc cờ bằng phán-đoán, KHÔNG auto-fix. Light/hỏi-đáp session → có thể skip; governance/doc-heavy session → nên chạy.

2.1.4 User-Mark display — hiển-thị sổ-cái mark ĐẦU phiên (H-12/13 canonical §P/P7, S79)

Floor User-Mark (🔴 P7 harness-11-engine.md §E.4): danh-sách quyết-định-mark hiển-thị đầu + cuối mỗi phiên cho anh đọc lại. Canonical sổ-cái → .claude/governance/ACTIVE-MARKS.md. INFORM-only.

• Đọc .claude/governance/ACTIVE-MARKS.md → báo status-filtered (P7): 🔴 Active-High + 🟢 Active HIỆN rõ (ID + what gọn) · 🟡 Medium tóm-tắt (1 dòng đếm) · 📦 Disable/superseded ẨN. Mục-đích: anh thấy lại các LỆNH governance đã ký ("vì quan-trọng").
• Mark cấp Active-High = LỆNH (P3 binding); vi-phạm → error-ledger.md §L.a RCA (P9). KHÔNG tự đóng dấu / đổi cấp (P4/P8 — chờ anh confirm).
• Light/hỏi-đáp session → có thể skip; governance session → nên chạy.

2.1.5 Work-state block — LEAD nạp + phát-biểu trạng-thái-công-việc ĐẦU phiên (Harness-15 B(c), S81)

Floor H15 B(c) (🔴 harness-11-engine.md §G.2): khoảng-trống quên-việc hay rơi đúng vào chính LEAD (em main tự-nạp kiến-trúc/luật nhưng bỏ quên trạng-thái-công-việc). Chốt-chặn = LEAD PHẢI nạp + phát-biểu rõ 4 thành-phần (ở Phase 3 REPORT). KHÔNG bỏ qua vì "tiết-kiệm token" — tiết-kiệm-token = quên-việc (rơi trạng-thái giữa phiên, làm-lại tốn HƠN).

• 4 thành-phần work-state block (phát-biểu ở Phase 3 REPORT):
  1. Lộ-trình đang chạy (active-roadmap) — phase/plan hiện-tại (docs/STATUS.md Phase line).
  2. Việc đang-làm-dở (WIP) — docs/STATUS.md §🔥 In Progress + HANDOFF last-session "🔴 NEXT (em)".
  3. Quyết-định đang-chờ (pending-decisions) — carry product/ops + AskUserQuestion chưa chốt + mark Medium (neo chưa-rõ).
  4. Lỗi-lặp-lại cần nhớ (recurring-bugs) — gotcha/anti-pattern liên-quan task (docs/gotchas.md; các mục này = value_protect §G.2(b), GIỮ-L1 bất-kể tuổi).
• Nạp-đầy L1 (B(a)): dùng-đủ ngân-sách token (memory-budget.json:token_governor) bằng nội-dung-THẬT, KHÔNG dè-xẻn / KHÔNG nhồi-rác. Budget = sàn-tận-dụng, KHÔNG trần-tiết-kiệm.
• Light/hỏi-đáp session → tóm-tắt gọn; feature/bug/governance → phát-biểu đủ 4 thành-phần.

2.1.6 Hot-feed %-print — LEAD báo composition Tầng-1 theo % ĐẦU phiên (Harness-15-v2 §6, S82)

Floor H15-v2 (🔴 harness-11-engine.md §G.4): Tầng-1 = HOT-FEED LỚN → cần "kính soi" để anh thấy phần luôn-nạp đang chứa gì, bucket nào mỏng, còn trống bao nhiêu → anh quyết điều-chỉnh. 🔴 Ranh-giới vai-trò: con-số = quyền anh (chủ-dự-án); em-main chỉ THỰC-THI-đúng-số + BÁO-% (KHÔNG tự-tinh-chỉnh con-số).

• In ở Phase 3 REPORT (đầu phiên): ước-lượng composition Tầng-1 theo % / 4 bucket (tỉ-lệ đủ, KHÔNG cần đo chính-xác): (1) WIP work-state · (2) lỗi-lặp/anti-pattern/gotcha · (3) tồn-đọng · (4) quyết-định-chờ. + Headroom = phần còn-trống so cap role (memory-budget.json:token_governor.tier1_hotfeed_tokens — lead 380K (v4 S94 owner-override, SE-specific — fit full read-set ~368K; subs giữ parity) · mem-sub (agent-ký-ức) 60K · wf-sub (agent-workflow) 50K; canonical = budget.json → đọc số sống ở đó, đừng tin echo này khi anh đổi cap).
• 📊 Bảng-số ngân-sách THẬT (M.B — Harness-20 adap S103, engine §M): chạy powershell.exe -ExecutionPolicy Bypass -File scripts/crystallized-backfill.ps1 → in BẢNG số live (cap / hotload-đo-bytes / tok-RANGE / measured_headroom / target / expected_backfill) BÊN CẠNH %-ước-lượng. Số đọc-sống budget.json 0-hardcode; backfill default 0=OFF (owner-authority, script READ-ONLY). 🟡 measured_headroom = UPPER-BOUND (file-floor 6-file; peak thêm task-context biến-thiên → real NHỎ HƠN). Light→skip.
• 🔴 Headroom > 0 mà CÒN nội-dung giá-trị-cao chưa nạp = under-fill (SAI) → nạp tiếp tới khi đầy hoặc cạn nội-dung giá-trị-cao. Headroom = cờ-báo, KHÔNG phải đích-tiết-kiệm; nạp-đầy ≠ nhồi-rác (giá-trị-thấp KHÔNG vào Tầng-1).
• Light/hỏi-đáp → gọn 1 dòng; feature/bug/governance → in đủ 4-bucket %. Đối-xứng session-end §L.b(c) (% cuối phiên + Headroom).
• 🧪 MFE opt-in (Harness-16 §H — memory-fidelity-EVAL, KHÁC H6.7 memoryDelta-routing): lệnh kèm tham-số eval → chạy thêm baseline powershell.exe -ExecutionPolicy Bypass -File scripts/mfe-eval.ps1 = LEAD coverage-FIT (must-remember vs cap, token-RANGE) + age-band (flag-not-cut) + Goodhart-anchor (strikes/RCA) + SUB per-role coverage (đo-thật, prose-only→N/A). KHÔNG eval = bỏ qua (tương-thích-ngược). MFE READS budget single-source, KHÔNG ghi. Light → skip; governance/audit → nên chạy.

2.1.7 Harness-17 loop-DÒ — spec-audit + floor-rot check (Đo→Kiểm nhánh đầu-phiên, S95)

Floor H17 (🔴 harness-11-engine.md §I): vòng tự-cải-thiện bộ-nhớ — đầu-phiên chạy khâu Kiểm (spec-audit) + Đo (floor-rot) để BÁO cờ; khâu Tinh-chỉnh (reinject/promote/archive/distill) do em-main làm ở session-end §L.b(c). INFORM-only — loop = tầng D6 DÒ+NÊU-CỜ, em-main = D9 writer.

• Chạy powershell.exe -ExecutionPolicy Bypass -File scripts/memory-selfimprove-audit.ps1 → báo CRITERIA+GAP set (KHÔNG frozen-tally): (a) write-gov D9 [tool-scope + hmw.js schema + propose-only] · (b) change-gov [COMPOSE governance-detectors] · (c) distillation-spectrum [over-cap agent có _INDEX/gist] + HCV proxy. GAP → em-main soạn bản sửa (gated).
• reinject-ledger CG-1 check: đọc .claude/governance/reinject-ledger.md → nếu có dòng status=escalated chưa xử → nhắc anh (build-gap? tăng-budget?). floor-rot (MFE age-band) → phân-loại B3 (build-gap vs floor-rot) trước khi reinject.
• 🔴 con-số budget = quyền anh; spec-audit READS token_governor, KHÔNG ghi. Light/hỏi-đáp → skip; governance/audit/memory-heavy → nên chạy (đối-xứng session-end §L.b(c) loop-REFINE).

2.1.8 H24 lead-self-audit — TICK counter + OVERDUE check (adopt S122 W3; file+shape = W2)

Floor H24: 2 vai lead-view-auditor + lead-omission-auditor soi chính LEAD, chạy theo NHỊP chứ KHÔNG mỗi phiên. Nhịp đọc từ h24_cadence; trạng-thái đếm ở .claude/governance/.session-counter.json. 🔴 Lead = single-writer của counter. W2 sở-hữu file + hình-dạng; W3 (đây) sở-hữu NGHI-THỨC tick.

(a) TICK — content-addressed, KHÔNG blind-increment:

head = git rev-parse HEAD
nếu head == last_ticked_head  → NO-OP (idempotent)
ngược lại → counter += 1 ; last_ticked_session = S<nn> ; last_ticked_head = head ; last_ticked_at = <date>

🔴 Vì sao content-addressed: Stop-hook wal-flush.ps1 auto-commit ở MỌI turn-boundary ⇒ counter++ mù sẽ tick nhiều lần trong một phiên thật ⇒ nhịp thành vô-nghĩa. Neo vào HEAD làm 2 lần /session-start cùng HEAD = +1, KHÔNG +2.

🔸 Khai thật giới-hạn: counter đếm "phiên có làm HEAD đổi", không phải "phiên". Hai phiên liên-tiếp mà không commit gì (Q&A thuần, không chạm WAL) ⇒ cùng HEAD ⇒ chỉ 1 tick. Thực-tế hook chạm WAL gần như mọi phiên nên hiếm; nhưng đừng đọc counter thành "số phiên tuyệt-đối".

(b) FAIL-LOUD, CẤM tự chữa: counter đến THẤP HƠN giá-trị đã lưu, HOẶC last_ticked_head trỏ commit không reachable từ HEAD → 🔴 BÁO ANH, KHÔNG silent-reset. Counter lùi = file bị rollback/sửa tay; reset lặng sẽ giấu mất khoảng nhịp đã trôi.

(c) OVERDUE:

• OVERDUE(light) khi counter − last_audit.light_at_counter >= h24_cadence.light_every
• OVERDUE(deep) khi counter − last_audit.deep_at_counter >= h24_cadence.deep_every
• Bỏ phiên KHÔNG xoá nợ — khoảng đo từ counter, không từ đồng-hồ ⇒ phiên nhỡ hiện ra thành OVERDUE, không biến mất.

(d) JUMP: một class trong lead_self_audit.flag_classes lặp ≥ jump_on_class_repeat lần → kéo audit tới sớm, bất-kể counter.

(e) BÁO: in 1 dòng counter=<n> · light <a>/<light_every> · deep <b>/<deep_every> · OVERDUE: <none|light|deep>. 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 §2.1.2).

🔴 Số nhịp = quyền anh. Bước này ĐỌC h24_cadence, KHÔNG ghi. CẤM hardcode nhịp ở đây — copy số vào doc dẫn-xuất chính là drift mà single-source sinh ra để chặn (detector governance-detectors.ps1 H24-2 fail-loud nếu key thiếu, không giả-định default).

🟡 Honest-caveat mang theo khi báo hub: hub nói rõ "số của các em = config của các em; ĐỪNG chép 3 số này". SE chọn cùng 6/15/3 là điểm khởi-đầu anh CỐ Ý chọn, KHÔNG phải chép vô-thức. Chỉnh lại sau chu-kỳ-2 — n=1 ở hub là mocc-0, chưa ai được bán câu "đã chứng minh hiệu-quả".

2.2 Skill registry (6 skill)

• Liệt kê: contract-workflow · form-engine · permission-matrix · dependency-audit-erp · ef-core-migration · iis-deploy-runbook
• Dùng skill khi task khớp (KHÔNG tự suy luận lại). Phân bổ per agent: xem README skill matrix.
• Skill staleness audit: chỉ chạy theo lịch định kỳ (xem 2.4)

2.3 RAG + MCP health

• mcp__rag-unified__list_projects — verify collection proj_solution_erp còn sống (baseline ~3076 chunks)
• Chunk count + last_indexed_at delta (drift > 20% → flag AI_INFRA). ⚠️ Re-index = AI_INFRA op (charter v2, cần VOYAGE_API_KEY) — KHÔNG tự chạy bootstrap.py; SE stopgap = store_memory key facts.
• Voyage rerank quota OK (verify 1 query có rerank_score)
• Kiểm tra RAG chủ trì + sub: prompts đã store + đánh dấu re-rank đầy đủ chưa

2.4 Audit cadence

• Monthly (ngày 1): skill + doc drift audit — thủ-công em-main session đầu-tháng (🧊 ghost-wire cron gỡ S100, CronList=0 — frontier P2 honest-retire). Next → docs/STATUS.md Maintenance backlog (canonical — B1, KHÔNG hard-date ở đây).
• KHÔNG tự chạy audit ngoài cadence, trừ khi user yêu cầu hoặc drift nghiêm trọng
• Check trạng thái audit định kỳ (đã audit chưa? kết quả ra sao)

2.5 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 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.

2.6 Unit test check

• dotnet test SolutionErp.slnx --nologo --verbosity minimal — verify count cho tính năng mới + bug fix gần đây.
• Baseline hiện tại → docs/STATUS.md Tests row (canonical — B1, KHÔNG hard-count ở đây; H1 F-class fix S100). Phase 9 UAT mode: test-after feature (skip per chunk per feedback_uat_skip_verify), test-before BẮT BUỘC cho bug fix + critical algo. test-specialist owns; coverage gap backlog xem STATUS.

2.7 Cross-agent synthesis (post-audit) [GENERIC — GIỮ NGUYÊN]

• Audit MD/RAG của sub-agent đã spawn, synthesize cross-agent learnings
• Integrate vào: rules, architecture, gotcha, skill, daily, hand-off, DB, luồng DB, session log

Phase 3 — REPORT (plan status)

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

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

SOLUTION_ERP report

• Trạng thái spawn TOÀN roster (idle/working) + agentId reuse-able trong session · + 1 dòng H24 cadence (§2.1.8)
• Plan progress: ✅ Phase 10 COMPLETE 11/11 · ⬜ Phase 11 polish (wire ApproveV2 skeleton) · 🚫 Phase 9 Ops (anh main coordinate)
• Critical signal: state counts (mig/table/endpoint/page/menu/test/gotcha) + bundle hash prod + RAG health
• (SE KHÔNG copy phần "6 sister report" của AI_INFRA — đó là vai trò host)

---

Trigger sau Phase 3: Em main đợi user input task cụ thể. Sub-agent spawn theo decision tree khi ACCEPT criteria match.