- 残留缺口：护栏量整段装配请求（字符），注入预算是单份 ⇒ 1M 窗口下 2×349525 就顶到旧上限 699050、5 份必被拦。根因是两套换算（上限按 1char=1token，注入按 loop 的 4char=1token）。 - 修法：上限 = max(262144, 推导预算 tokens × loop.CharsPerToken) ⇒ 1M 窗口 2,796,200 字符（5 份满额注入 1,747,625 有余量）；不变量升级为「N 份」（maxChatDocumentsPerTurn=5，带出处注释）；WARN 文案升级为多附件口径（max_documents/document_inject_chars/document_inject_total_chars/guardrail_max_input_chars/hint）。 - 同一换算常量复用：在 loop/compactor.go 的既有无导出常量旁加导出别名 loop.CharsPerToken = charsPerToken（2 行、零行为改动、不重命名）—— 这是本切片唯一触及「不要碰」清单的改动，已由主会话复核接受（替代方案是复制一个字面量 4，会重新造出两套换算）。 - 同步陈旧注释（config/guardrail.go、wire_runtime.go 里的旧公式）与 .env.example（新公式 + 多附件口径 + 1M 算例 2796200/1747625），并有「模板 ↔ 代码现算值」的一致性用例。 - 主会话独立验收：隔离 worktree（G2b 的 7 文件，排除 B1/ST1 在途）build/vet 绿、全树 59 包 0 FAIL、护栏用例 17 PASS、双平台交叉编译绿。 - 残留（未修，需裁决）：预算关闭或落在 (0,81920) token 的部署，派生态上限 = 262144 而 5×64K = 327680 ⇒ 满载附件回合仍可能被拦（启动会记 WARN，不静默）；真正的下限应取 max(262144, maxDocs×每份注入)。
- 真 bug：文档注入预算（1M 窗口 ⇒ 349525 字符）> 输入护栏硬编码上限（262144）⇒ 带 744KB 附件的 POST /chat 直接 input_length_exceeded/guardrail_input，整个回合作废（主会话活服务实测）。 - 修法：guardrailMaxInputChars → guardrailMinInputChars(256Ki 下限) + 纯函数 deriveGuardrailInputLimit(log, override, budgetTokens, docInjectChars)：派生值 = max(下限, 推导预算 tokens)（1M ⇒ 699050）；新增 env GUARDRAIL_MAX_INPUT_CHARS（未设/0=派生、>0=覆盖、<0=WARN 回落）；预算只在 wire_context 推导一次并经 buildGuardrailPipeline(ctxBudget) 传入（避免「窗口未声明」WARN 记两遍）；输出上限 65536 刻意不参与派生（有显式回归钉住）。 - 关系不变量：文档注入预算 ≤ 输入上限，人为破坏 ⇒ 一条 WARN（不静默）。 - 第 5 条 flake（exec/TestTerminal_Timeout_Killed）：仅改测试、terminal.go 保持 pristine；根因不是「杀进程失效」而是旧断言的 ~200ms 精度把宿主负载下的进程创建耗时算了进去（重压下 cmd.Start 会直接返回 deadline exceeded，红行却报 process not killed）⇒ 改为「控制组证明同命令不设短超时正常退出」的确定性证明 + 把墙钟断言降级为 10s 语义判别界（子进程自然存活期拉到 30s）。 - 主会话独立验收：隔离 worktree（G2 的 10 个文件，排除 M1 在途的 wire_channels.go）build/vet 绿、全树 59 包 0 FAIL、双平台交叉编译绿、Guardrail* 全 PASS、exec -count=20 绿；变异独立复现（把派生值退回硬编码 ⇒ 4 条红，含 budget=699050 → 262144）。 - 残留缺口（已排 G2b）：护栏量的是整段装配请求、注入预算是单份 ⇒ ≥2 份各撞注入预算的大附件仍可能被拦。
AskaEth
AskaEth
AskaEth
AskaEth