# sub-reviewer-3 — L3 HONEST-NẤC / OVERCLAIM lens (S124 adap-wave-reply plan)

**VERDICT: PASS_WITH_FIXES — 0C / 3M / 2m**

Reviewer: adversarial L3 (nấc G-011 + do-token real-N logic + meta-count self-coverage + asymmetry).
Independent verification from source (broadcasts + reply + SE state + LIVE harness truncation), not from lead summary.

---

## GROUND-TRUTH measured THIS turn (the crux)

Read whole-file, no offset/limit (do-token method), observed the actual harness truncation line:

- **STATUS.md** → truncation verbatim: `showing the first 37319 of 124503 characters (70892 tokens, cap 25000); ... cannot be paginated by line`. ⇒ **whole-file = 70892 tokens** (124503 chars). File = 239 lines by `wc -l` (longest line = 69870 chars @ line 6).
- **HANDOFF.md** → truncation verbatim: `showing lines 1-3 of 13 total (32254 tokens, cap 25000)`. ⇒ **whole-file = 32254 tokens**. File = 13 lines (longest line = 59961 chars @ line 5).
- **STATUS.md offset=7 limit=240** (tail after the mega-line) → error `File content (33944 tokens) exceeds maximum allowed tokens (25000)`. ⇒ even the NON-mega tail alone = **33944 tokens** > spec's claimed whole-file 26075.

Spec D:48 claims: `STATUS folded chunk 360-dòng = 26075 tok, HANDOFF 404-dòng = 32988 tok`.

| file | spec token | real token (this turn) | spec line-count | real line-count |
|---|---|---|---|---|
| STATUS | 26075 | **70892** (2.72× under) | "360-dòng" | 239 (char-mode, "cannot paginate by line") |
| HANDOFF | 32988 | 32254 (~2% over, ~OK) | "404-dòng" | 13 |

---

## FINDING M-1 (Major) — do-token STATUS number wrong 2.72×, and it's the exact trap being adopted

**Anchor:** spec `spec-adap-wave-reply-15-07-2026.md:48` ("em ĐÃ thấy real-N từ chính harness lượt này — STATUS folded chunk 360-dòng = 26075 tok").

- Real whole-file STATUS = **70892 tokens** (my truncation line, this turn). Spec says 26075 → off by **2.72×**.
- 26075 > cap 25000, so by the do-token rule the lead *treated it as* whole-file — but it is NOT. STATUS's tail-alone (lines 7-246) is already 33944 tok. 26075 ≈ the near-cap SHOWN-chunk count, i.e. `N của phần hiển-thị`, which do-token broadcast:27 explicitly says is NOT the whole file. The lead's own word "**folded chunk**" = read a partial/folded view, violating do-token method (`Read TRỌN, KHÔNG offset/limit` — do-token:89).
- This is the do-token failure mode (wrong token constant → wrong capacity picture) committed **in the very act of adopting do-token**. Mirror of the broadcast's own §4 lesson "nhãn 'đã đo' thay cho việc đo": lead labels it "đã thấy real-N" but the number is a mis-measure.
- **Impact — feeds owner-decision #3** (spec:80 "real-token đo được → re-tier / đổi budget-số"). 70892 = 18.7% of the 380K lead hot-feed budget; 26075 = 6.9%. Surfacing 26075 under-states STATUS's always-on cost by ~2.7× → materially misleads the owner's re-tier decision (could make owner think re-tier is not urgent when STATUS alone eats ~1/5 of lead budget).
- HANDOFF (32988 vs real 32254) is within noise (~2%) — acceptable. Only STATUS is broken. Line-count labels (360/404 vs real 239/13) are both wrong but harmless mislabels.
- **Acceptance to fix:** re-Read STATUS.md FULL (no offset/limit), take the whole-file `N tokens` from the truncation line (currently 70892), correct the spec + owner surface. Do not surface 26075.

## FINDING M-2 (Major) — meta-count self-coverage: "6 adap-request R1-R6" but only 5 addressed; R5 dropped

**Anchor:** spec:24 ("Nội-dung chính = trả lời 6 adap-request R1-R6") vs spec:25-31 enumerates R1,R2,R3,R4/EOL,r6,§8 — **R5 absent**. Reply source `reply-wave-s122.md:36-39` §6 = "R5 orphan + r5-amend RETIRE-LEGACY".

- The reply calls R5 (RETIRE-LEGACY + §3.1 citation-trap + §3.2 Goodhart) "**phần hub thấy giá-trị nhất cả wave**" and gives an explicit hub position: honest-defer, "**KHÔNG cam-kết fix**" (in truth-floor round-5, chưa chốt).
- This is the S119 meta-count self-coverage blind-spot: count-says-6, list-shows-5, and the omitted item is SE's OWN highest-value contribution. The resulting adap-report would fail to record hub's honest-defer nấc on the very cluster SE already shipped (SE marks RC-...17-23-10 = DUAL-ACCEPT + retire-legacy + citation-trap guard + H24-3).
- **Acceptance to fix:** add an R5 line to section A: SE-side nấc = `executed S123 (mark RC-...17-23-10)`, hub-side nấc = `input-received, honest-defer, no-commit` — do NOT let the adap-report imply hub accepted/verified these.

## FINDING M-3 (Major) — C h17 nấc "verified" overclaims a cadence that has never run

**Anchor:** spec:44 proposes adap-report nấc `verified, không-đổi-cơ-chế (config-based)`.

- SE's own binding caveat, mark `ACTIVE-MARKS.md RC-pqhuy1987-15-07-2026-15-32-23` (Active-High CAVEAT): "**2 vai CHƯA CHẠY lần nào · counter CHƯA tick · nhịp 6/15/3 = điểm khởi-đầu owner cố-ý chọn, KHÔNG phải 'đã chứng-minh hiệu-quả'** (hub: n=1 = mocc-0; chỉnh lại sau chu-kỳ-2)."
- `memory-budget.json h24_cadence._owner_ratified`: "HONEST-CAVEAT to carry when reporting to hub ... Re-tune after cycle-2 ... nobody may sell 'proven effective' yet."
- Hub's own expected report format (h17 broadcast:86 §6.1) = "**đã đọc, không đổi**" = an acknowledgment (`agreed` nấc), NOT `verified`. A cadence mechanism that has executed zero cycles cannot be "verified".
- The spec DOES carry the "chưa chạy / chưa dữ-liệu" caveat elsewhere (spec:44, inside the owner-decision reasoning) — but it is NOT attached to the PROPOSED NẤC. Reporting bare "verified" to hub drops SE's own caveat (S119 giữ-kết-luận-phải-giữ-caveat) and conflates "config-structure is single-source (verifiable)" with "cadence mechanism is verified (false — never ran)".
- **Acceptance to fix:** nấc → `agreed / đã-đọc-không-đổi (config single-source)` + explicit caveat "cadence chưa chạy lần nào; 6/15/3 = owner-chosen unproven starting point; re-tune after cycle-2; hub said 'do NOT copy these three'".

## FINDING m-4 (minor) — E-2 nấc "verified" drops SE's own "CHƯA VERIFY / model-incomplete" nuance

**Anchor:** spec:37 proposes E-2 nấc `verified (SE là nguồn falsification)`.

- SE's own STATUS L3 (`docs/STATUS.md:6`) documents the OPPOSITE-direction nuance: "**L3 → CHƯA VERIFY** ... regex delimiter LF-only ×2 song song bản vá ⇒ **CRLF đơn-độc CÓ THỂ đủ giết** ⇒ mô-hình broadcast THIẾU ... **hạ nấc**". Plus erratum-h8:32 + reply:17 note SE's probe lacked a control-group ("một probe đơn dễ ra kết-luận sai theo hướng có lợi").
- SE's honest position = "my one probe (a fully-CRLF agent) survived → falsifies 'always fatal'; BUT an unverified LF-only regex path might still kill CRLF-alone, so I lowered my own nấc." Bare "verified" sells a cleaner conclusion than SE holds.
- **Acceptance:** keep "credit + 0 change", but nấc caveat = "single-probe falsification (specific agent survived); full mechanism NOT verified — SE flagged an unverified LF-only path (STATUS L3), control-group recommended by hub".

## FINDING m-5 (minor, cross-lane with L2) — F "ahead-of-broadcast" framing drops the 57-leak trade-off

**Anchor:** spec:58 frames TRAILING-K as "SE REFINEMENT ahead-of-broadcast". Confirmed mechanism `session-end.md:178`: trailing-K deliberately KEEPS sandwiched `wal:` as "GIỮ NGUYÊN, chấp-nhận noise (hard-safety đổi lấy không-rewrite)".

- Lead's own `run.md:15` flags it: TRAILING-K "= nguồn của '57 wal: lọt origin/main' S119 ... KHÔNG phải thuần 'ahead-of-broadcast'". The spec discloses the noise-acceptance ("noise-chấp-nhận") but still labels the whole thing positively without the 57-leak provenance.
- Primary framing-catch belongs to L2 (run.md explicitly routes it there); noted here as an asymmetry only.

---

## POSITIVES verified (validate, don't inflate — Smart-Friend guard)

- **D authority-classification CORRECT** (spec:50): measuring = in-frame; changing budget numbers (`tier1_hotfeed` / `harness_floor` / `crystallized_backfill.target`) = owner-gated; lead does NOT auto-tune. Matches `memory-budget.json token_governor.role_boundary_note`. No over-reach.
- **D harness_floor 55K audit is HONEST/self-critical** (spec:49): accurately flags it as mostly-estimate. `memory-budget.json:90 _s112_remeasure_note` = "55000 = honest mid estimate (~19K byte-measured + ~36K harness-injected-est)". ("nửa est" slightly understates the ~65% est-fraction — in SE's own disfavor direction, safe.) NOTE: SE's field already self-labels "ESTIMATE ... not a false-precise number", so it is NOT as bad as the do-token hub-constant ("Grounded in real measurements, NOT a guess") — the spec is being appropriately harsh on itself.
- **E-1 model-tier CORRECTLY owner-gated + deferred** (spec:35-36): nấc `agreed, deferred-owner+H23`; lead does NOT touch frontmatter. Verified all-inherit: 14/14 roster `.claude/agents/*.md` = `model: inherit` (README.md has no model line). Tangle with H23-precedence lỗ chưa-test = correctly identified.
- **r6 relocate CORRECTLY owner-gated + carries the caveat** (spec:29): "Docs-verified, CHƯA runtime-test" — faithfully mirrors reply:50 honest-note (§A2). Good.
- **Push-guard §5.0/§5.2 TRAILING claim FAITHFUL** to code: `session-end.md:159-222` (trailing-K count from HEAD, `(a)` forbid exit-code, `(b)` forbid full-history count = 57 mìn-ngủ, `:178` sandwiched kept). F "executed S122" nấc supported by mark's push-THẬT ×2.
- **E bon-vong reflection appropriately humble** (spec:55): acknowledges SE's checker-roles do NOT cross-check each other (harvest-curator KHÔNG soi tooling-auditor) → "kẽ giống hub". nấc `n-a-mostly-aligned` fits a type:new NOT-adopt. (Soft caveat: "có thể AHEAD hub" is generous — SE's lead-auditor roles have run ZERO cycles vs hub loop-3 ran once; the "có thể" hedge saves it.)

---

## What I could NOT verify
- The mechanism by which the lead obtained "26075" (stale earlier-session read vs folded-chunk vs mislabel) — I only prove it is NOT the current whole-file N (70892). Any of the three = defect for a "real-N this turn" claim.
- Whether the lead's harness build reports the same cap/format as mine (I read cap 25000, char-mode for STATUS, line-mode for HANDOFF). do-token:98 warns cap is tool-specific — but token count of identical content is tokenizer-invariant, so 2.72× cannot be a cap/format artifact.
- Ground-truth of `.session-counter.json` counter value (spec:44 says "counter=3"; mark said "counter=0 CHƯA tick" @S122) — not central; not read.
