[CLAUDE] Docs: S94 nâng cap lead 220K→380K (anh-directed) + re-tier STATUS/HANDOFF mega-line
All checks were successful
Deploy SOLUTION_ERP / build-deploy (push) Successful in 5m24s

- Cap lead_tokens 220K→380K (memory-budget.json canonical; SE-override, lead KHÔNG còn AI_INFRA-parity, subs giữ 60K/50K). Mark H-15 v4-delta RC-pqhuy1987-29-06-2026-23-25-50. Flush 3 derived echo (ACTIVE-MARKS · session-start §2.1.6 · engine §G adopt-delta).
- Re-tier mega-line (fix Read-25K/call OOM + token-cost): STATUS 389→89 dòng (mega-line 59.6K→7.1K char) · HANDOFF 732→12 dòng. Live 332KB→34KB (−90%). Session ≤S90 → docs/_archive/STATUS-HANDOFF-tier-S94 (0 byte-loss: new+archive = orig + 995B pointer).
- Verify: detector 27=baseline (0 broken-pointer mới) · canonical mig59/test434/gotcha76/table88 intact · MFE live-read 380K · conservation spot-check PASS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
pqhuy1987
2026-06-29 23:46:04 +07:00
parent ea075bac00
commit 5f61b038e4
7 changed files with 1085 additions and 1032 deletions

View File

@ -78,9 +78,9 @@
"_note": "Harness-15-v2 (S82, 2026-06-21): UPDATED by delta broadcast 2026-06-20-Governance-harness-15-v2-hot-feed-update (supersedes_scope = tier-1-sizing + L2/L3-caps ONLY; rest of H15 unchanged). TWO CHANGES vs S81: (1) Tier-1 = HOT-FEED LARGE per-role (was flat 12K -- too thin, caused lead to forget work across sessions); (2) L2/L3 caps REMOVED (on-demand, no artificial tier-limit, bounded only by model context window). Still the SECOND governor (token) ORTHOGONAL to the BYTE governor (tiers/archive_gate above) -- keep BOTH (B(e)); byte measures file-size-on-disk, token measures context-loaded; VN text ~3.0-3.5 byte/tok so byte/4 = upper bound => real headroom LARGER. Budget = MINIMUM-to-USE floor (FILL Tier-1 with real work-state up to the number; under-fill ONLY when high-value content exhausted; NEVER garbage-stuff -- token-saving = forgetting work).",
"role_boundary_note": "v2 §6 ROLE BOUNDARY (🔴): the budget numbers (Tier-1 per-role cap + per-bucket allocation) are ANH's (project-owner / chu-du-an) RIGHT to set -- NOT the AI-lead's. em-main's job is exactly two parts: (1) EXECUTE the config faithfully (load Tier-1 to the number, no-truncate, pull each bucket to target) + (2) REPORT %-composition at session-start (§2.1.6) and session-end (§L.b(c)) so anh decides. em-main self-measures + proposes numbers; em-main does NOT auto-tune them down. This corrects the S81 'LEAD-AUTHORITY' framing which conflated AI-lead with project-owner.",
"tier1_hotfeed_tokens": {
"_note": "Tier-1 always-loaded HOT-FEED, PER-ROLE (v3 S83 2026-06-22: FULL AI_INFRA parity, owner-set). FILL with the 4 work buckets: (1) WIP work-state, (2) recurring-bugs/anti-patterns/gotcha (value_protect, kept regardless of age), (3) backlog, (4) pending-decisions. anh-set: lead 220K / mem-sub 60K / wf-sub 50K = EXACT AI_INFRA parity. This SUPERSEDES the S82 'SE numbers are SMALLER (lead 60K; subs stay 20K/16K because the byte-cap binds first)' self-justification -- that was the AI under-shrinking, forbidden by role_boundary_note + mark RC-...01-58-01 (token-saving = forgetting work). KEY CORRECTION on subs: the sub MEMORY.md byte-cap (30720B ~9.3K tok) is ONLY ONE SLICE of a sub's Tier-1 -- the SPAWN PROMPT (relevant gotchas + state + full task-context + related docs/memory, written by em-main) fills the REST up to the token budget. So 60K/50K is NOT 'unusable headroom'; it is the target em-main fills via a RICH spawn prompt (see spawn_fill_directive). %-print at the two session ends shows the REAL composition.",
"lead_tokens": 220000,
"lead_note": "ANH-SET 220K (S83 2026-06-22 owner-directive, full AI_INFRA parity; raised from the 200K interim earlier in S83 and the 60K S82 self-shrink). DO NOT auto-reduce (role_boundary_note + mark RC-...01-58-01). Hot-feed = STATUS full current-state + 4-bucket work-state block + ACTIVE-MARKS + recent-3-session HANDOFF + active roadmap (migration-todos) + roster-slice + task-relevant gotchas + active-task files + task-relevant docs/code -- read GENEROUSLY ('dau phien nap them tier1_lead cho du'), NOT 'on-demand-deferred', but HIGHEST-VALUE distilled only, NEVER garbage-stuff. Opus 4.8 1M window => 220K is ~22% of window, ample. anh-adjustable (owner authority).",
"_note": "Tier-1 always-loaded HOT-FEED, PER-ROLE (v3 S83 2026-06-22: FULL AI_INFRA parity, owner-set). FILL with the 4 work buckets: (1) WIP work-state, (2) recurring-bugs/anti-patterns/gotcha (value_protect, kept regardless of age), (3) backlog, (4) pending-decisions. anh-set: lead 380K (S94 2026-06-29 owner-override, SE-SPECIFIC -- diverged from AI_INFRA-parity to fit the full ~368K read-set) / mem-sub 60K / wf-sub 50K (subs STILL AI_INFRA parity). This SUPERSEDES the S82 'SE numbers are SMALLER (lead 60K; subs stay 20K/16K because the byte-cap binds first)' self-justification -- that was the AI under-shrinking, forbidden by role_boundary_note + mark RC-...01-58-01 (token-saving = forgetting work). KEY CORRECTION on subs: the sub MEMORY.md byte-cap (30720B ~9.3K tok) is ONLY ONE SLICE of a sub's Tier-1 -- the SPAWN PROMPT (relevant gotchas + state + full task-context + related docs/memory, written by em-main) fills the REST up to the token budget. So 60K/50K is NOT 'unusable headroom'; it is the target em-main fills via a RICH spawn prompt (see spawn_fill_directive). %-print at the two session ends shows the REAL composition.",
"lead_tokens": 380000,
"lead_note": "ANH-SET 380K (S94 2026-06-29 owner-directive RC-pqhuy1987-29-06-2026-23-25-50 -- raised 220K->380K so the FULL canonical read-set ~368K fits; SE-SPECIFIC override, NO LONGER AI_INFRA-parity for lead, sub caps unchanged). History: 220K (S83 full-parity) <- 200K interim <- 60K S82 self-shrink. DO NOT auto-reduce (role_boundary_note + mark RC-...01-58-01). Hot-feed = STATUS full current-state + 4-bucket work-state block + ACTIVE-MARKS + recent-3-session HANDOFF + active roadmap (migration-todos) + roster-slice + task-relevant gotchas + active-task files + task-relevant docs/code -- read GENEROUSLY ('dau phien nap them tier1_lead cho du'), NOT 'on-demand-deferred', but HIGHEST-VALUE distilled only, NEVER garbage-stuff. Opus 4.8 1M window => 380K is ~38% of window. CAVEAT: at ~368K loaded the hot-feed is ~97% full => near-zero headroom + HIGHER context-rot (honest_caveat trade-off accepted by owner). TOOLING NOTE: the 380K BUDGET cap is ORTHOGONAL to the harness Read-tool 25K/call cap -- STATUS/HANDOFF mega-lines STILL cannot be fully Read until re-tiered (mega-line not line-paginatable); cap raise alone does NOT unblock the Read. anh-adjustable (owner authority).",
"memory_sub_tokens": 60000,
"memory_sub_note": "memory-bearing sub (agent-chinh), anh-set 60K (S83 full parity): own MEMORY.md (<=30720B ~9.3K tok auto-inject) + archive _INDEX map + work-state slice + THE RICH SPAWN PROMPT em-main writes (relevant gotchas + current state + full task-context + related docs/memory) = fills toward 60K. The byte-cap on MEMORY.md is NOT the binding limit on the sub's Tier-1; the spawn prompt is. em-main MUST write a context-rich brief, NOT a thin 8K brief (that old anti-truncation heuristic guarded RETURN-truncation #53, mitigated by lean memoryDelta RETURN -- not by starving INPUT).",
"workflow_sub_tokens": 50000,