Integrate pi-lens' post-edit verification loop into billion-context-pi (native, cache-safe)

[Juna9969]

Summary

billion-context-pi (bcp) is the sole context manager in a session — it intercepts the context event and runs an 8-stage pipeline (assign refs → sync blocks → prune → filter → hide calls → recommend → nudge → emergency truncate). pi-lens is a post-edit verification engine — after every write/edit it runs LSP diagnostics, lint, format, autofix, structural rules, and security scans, and feeds findings back to the agent.

This issue proposes integrating pi-lens' verification loop into bcp as a native, config-gated engine (checks.*), so one extension owns both token economics and edit correctness. The integration is not a copy-paste: the two extensions conflict in seven concrete places. Each conflict and its resolution is detailed below. The guiding rule for every resolution: the check loop stays, the delivery mechanisms that damage the provider prefix cache are replaced by bcp-native primitives (same-turn tool-result attachment, ACP refs, pull tool, existing nudge slot).

Why merge pi-lens into bcp

The benefit: token savings compound, error costs compound faster

A compression engine that lets broken code through is a false economy. Concrete numbers from the same corpus behind the conflict attributions below (2105-turn, multi-provider):

• A type error that survives the editing turn costs 2–5 extra agent turns to discover, diagnose, and fix (test failure → read traceback → re-read file → fix → re-verify). At ~10–30K tokens per agentic turn, that is 50–150K wasted tokens per missed defect — versus ~0.5–2K tokens for a same-turn diagnostic summary.
• The failure mode gets worse precisely where bcp shines: long sessions. The deeper the conversation, the more context must be re-paid for every wasted turn, and the more likely an unnoticed early error is to be carried into compressed summaries — then the agent keeps building on a corrupted premise with no record of when it went wrong.
• pi-lens' check loop attacks exactly this: typecheck/lint/format/security-scan after every write/edit, results back same-turn, fixed on the spot. Defect cost drops from "turns later, at full context price" to "this turn, at summary price".

Why bcp is the right host (not pi-lens alone, not coexistence)

• Single-handler architecture: bcp is designed to be the only context handler; a post-bcp handler can rewrite what bcp already decided. Checks findings are context — routing them through bcp's own primitives (D1–D3) is the only architecture that keeps bcp's guarantees intact.
• The compression pipeline needs the checks data more than the checks need compressing: severity-tiered findings (🔴/🔑/advisory) with honest labels are short-lived working-set data — ideal absorb/protect candidates. Living outside bcp, lens' findings are just more unmanaged transcript; living inside, they become first-class, ref-addressable, auto-compressible citizens.
• One tool surface: no duplicated tool schemas per request, one config system, one honest-labeling discipline for both context state and code health.

What bcp gets (revenue)

1. Post-edit verification loop (the core claim — currently missing entirely).
2. Defect-cost reduction as measured by the A/B protocol below (tokens billed, turns-to-green, residual errors).
3. A defensible answer to the recurring community question "why does my session spend more with checks extensions installed" — because bcp will ship the loop without the cache-hostile delivery.

What the merged engine avoids (cost avoided by not porting lens as-is)

• Ephemeral injection → tail divergence every turn (lens' own docs concede: PI_LENS_NO_CONTEXT_INJECTION=1 exists "for cache-sensitive sessions").
• Lazy tool activation → whole-prefix invalidation from token 0 ("a transposition is a changed prefix, i.e. a cache miss" — lens' tool-set-policy comment).
• Full-content append → up to 2 MiB/file of permanent transcript bloat.

Why the two systems want to merge

• bcp's blind spot: it conserves tokens but verifies nothing. After an edit, nothing tells the agent whether the file still typechecks or leaks a secret. Breakage surfaces turns later (failing tests), after the context for those turns has already been paid for. An immediate loop shortens the feedback cycle — the same resource bcp exists to conserve.
• pi-lens' delivery debt: community feedback blames pi-lens for inflated token spend via cache invalidation. Mechanism-level attribution (cross-checked against pi-lens' own docs, which ship PI_LENS_NO_CONTEXT_INJECTION=1 "for cache-sensitive sessions" and warn that "a transposition is a changed prefix, i.e. a cache miss"): the damage comes from delivery (ephemeral injected user messages, mid-session tool-list mutation, full-file content appended to persisted tool results), not from running checks. All three delivery patterns are replaceable; the check loop itself is cache-neutral.

Conflict map

#	Conflict	Root cause	Resolution
C1	Both extensions hook the context event; bcp only tolerates handlers running before it	pi-lens delivers findings as ephemeral user-role message injections through its own context handler; extension load order is not contractually defined, so a post-bcp handler can rewrite what bcp already decided	Single handler. All pi-lens model-facing delivery is re-routed (see D1–D3). Context injection is deleted. bcp remains the only context handler
C2	Same-moment tool-result race: pi-lens autofix appends findings into the write tool result; bcp absorb compresses large tool results at arrival (builds/logs/greps are force-absorbed)	Both act on the tool result in the same tick, with no defined order	Fixed ordering contract: checks complete first → summary attaches → absorb evaluates the annotated result. The attachment region (bounded summary) is exempt from force-absorb in the current turn; detail goes to the ref store and is compressed later through the normal ref flow
C3	pi-lens persists the full authoritative post-fix file content in the tool result (up to 2 MiB/file, shared budget for multi-file bash writes) — permanent transcript bloat, anathema to a compression engine	AUTHORITATIVE_CONTENT optimizes for "no re-read needed" at any token cost	Replace with integrity pointer: content hash + "file was modified — re-read" notice + ref-store detail. The degraded over-cap path pi-lens already ships becomes the only path; the model re-reads on demand (cheap with warm read caching)
C4	pi-lens' lazy tool activation (activate-tools) mutates the tool block mid-session → prefix invalidated from token 0; bcp is explicitly prefix-cache-disciplined (byte-stable system header via systemToUser)	Situational tools were an optimization to shrink request payloads	Delete lazy activation. Fixed tool set registered at session start, identical every turn. The byte-stability discipline bcp applies to the system header extends to the tools block
C5	Turn-boundary duplication: pi-lens emits at agent_end/turn-end (deferred autofix/format queue, turn findings, async test results into next turn) while bcp also nudges there (block status)	Two independent emitters at the same boundary → two message sources, double cache surface	One nudge slot, fixed content contract: line 1 = block status (existing), line 2 = open blocking-findings count (only if > 0). Async test results land in the ref store, surfaced via same-turn attach when fast or via pull tool otherwise
C6	pi-lens read-guard requires read-before-edit in-session; bcp's acp_delegate subagents write files from child contexts that never "read" in the parent session	Read tracking is session-local; delegate writes are legitimate but invisible to it	Bridge-recorded mutations count as reads: delegate (and any third-party) writes register via the existing mutation bridge (globalThis[Symbol.for("pi-lens:mutation-bridge")], recordMutation({filePath, kind, editRanges, consumer})); read-guard accepts bridge-recorded mutations for guard purposes. Keeping the symbol unchanged preserves ecosystem compatibility
C7	Runtime footprint mismatch: bcp is a pure message transformer; pi-lens spawns and warms long-running LSP server children	An execution engine inside a compression extension changes the package's dependency surface	Config-gated module, default off (checks.enabled: false). Engine lifecycle bound to the pi session; warm pool + cooldown registry preserved as-is. Zero process cost when disabled

Integration design

Module mapping (pi-lens subsystem → bcp destination)

pi-lens subsystem	bcp destination	Required change
LSP server management (spawn/warm/cooldown/instance registry)	new src/checks/lsp/ execution layer	lifecycle bound to pi session; none functional
write → immediate autofix in same tool result	keep timing; attach = severity-tagged summary + ACP ref	drop full-content append (C3); ordering contract (C2)
edit → deferred autofix/format queue at agent_end	keep queue; output re-routed to ref store + nudge line 2	re-route delivery only
Unified LSP diagnostics + impact cascade (reverse-dependency neighbors)	execution layer; results to ref store	storage only
ast-grep structural rules, opengrep (always-on), gitleaks/trivy/govulncheck/knip/jscpd/madge/vulture/zizmor (config-gated)	execution layer, config-gated under checks.* (nearest-config-wins preserved)	none
Async test runner (results next turn; fixed exclusions **/integration/**, **/e2e/**)	results to ref store; surfaced same-turn when fast, else pull tool	delivery re-route (C5)
lens_diagnostics pull tool (mode=delta/all/full)	keep as checks_diagnostics, fixed registration at session start	rename + constant tool block (C4)
Read-guard (+ /lens-allow-edit one-shot bypass)	keep; accept bridge-recorded mutations	C6
Mutation bridge	keep symbol as-is	none
Severity tiers (🔴 blocking / 🔑 action-needed / advisory) + honest labels (unconfirmed/cold/partial/stale)	keep semantics verbatim — they are what makes findings trustworthy	none
Context injection (turn findings / test findings / session guidance)	deleted — replaced by D1–D3 below	the core cache-safety decision
Lazy tools / activate-tools	deleted	C4
AUTHORITATIVE_CONTENT full-content append	deleted — integrity pointer + ref (C3)	—
--lens-guard commit/push blocking (experimental)	optional flag, unchanged	none
Turn-status display items	fold into bcp's existing footer/status line	UI merge

Delivery channels (replacing all injection)

• D1 — Same-turn attachment (per edit): findings summary appended to the current write/edit tool result, severity-tagged, bounded (≤ ~10 lines; "N errors, M warnings in X — detail ref m00421" style). This is the loop: the agent sees findings before its next action, in the same turn it made the edit. Blocking findings are always in the summary; advisory counts only.
• D2 — Ref store (detail): full diagnostic output lives extension-side, referenced by ACP ref. Compressible through bcp's normal pipeline once aged out of the working set — detail costs tokens only while relevant. This is where the 8-stage pipeline earns its keep on the checks' own output.
• D3 — Pull tool (on demand): checks_diagnostics mode=delta|all|full, model-invoked, zero prefix impact (constant registration). Replaces session guidance, turn-findings push, and everything a curious agent wants beyond the summary.

Per-turn pipeline (merged ordering contract)

1. Tool call completes → checks engine runs (immediately for write; queue for edit, drained at agent_end) → findings classified → D1 summary attaches, detail → ref store (D2).
2. Absorb evaluates the annotated result; attachment region exempt from force-absorb for the current turn (C2).
3. context event: bcp 8-stage pipeline runs as the only handler; nudge stage extended per C5.
4. agent_end: deferred autofix/format queue drains; footer/status updated.
5. Compression: ref-store detail compresses via normal refs when out of the working set.

Cache-safety contract (invariant list)

• Tools block: constant for the whole session (no activation/deactivation).
• System header: byte-stable (bcp's existing discipline, unchanged).
• Zero ephemeral user-role messages injected by the checks engine.
• Same-turn attachment bounded; detail never inlined into persisted transcript.
• Every checks artifact (findings, test results, autofix diffs) addressable by ACP ref and compressible.

Config surface (namespaced under bcp's existing config)

checks.enabled: false                  # master gate, default off
checks.autofix.enabled: true           # fixer pipeline (biome/ruff/eslint/stylelint/rubocop/clippy --fix)
checks.format.mode: deferred           # deferred|immediate, deferred default (agent_end)
checks.diagnostics.pullTool: true      # registers checks_diagnostics
checks.readGuard.enabled: true
checks.scanners.gitleaks: true         # + trivy/govulncheck/knip/jscpd/madge/vulture/zizmor, config-gated
checks.opengrep: true                  # always-on when engine enabled
checks.guard: false                    # commit/push blocking (experimental)

Nearest-config-wins per project is preserved from pi-lens.

Phased rollout (each phase independently shippable)

• P0 — Delivery contract (no engine yet): ref store, D1 attachment format, nudge line-2 extension, constant tool registration. Ships the cache-safe primitives; upstream can validate the wire format cheaply.
• P1 — Engine core: LSP management + checks_diagnostics pull tool (delta/all/full) + read-guard with bridge awareness.
• P2 — Fixers: autofix pipeline + deferred agent_end queue + integrity-pointer replacement for AUTHORITATIVE_CONTENT.
• P3 — Scanners & tests: ast-grep, opengrep, config-gated scanners, async test runner, optional guard flag.

What this issue does NOT ask for

• No context-message injection of any kind (the fix: reconstruct parallel tool-call assistant message from split core messages #1 community complaint mechanism — kept out by design, not by flag).
• No mid-session tool-list mutation.
• No full-file content in persisted tool results.
• No replacement of bcp's nudge channel — checks ride in it, they don't add a parallel one.

Alternatives considered

• Keep pi-lens installed alongside bcp: functionally verified to co-exist (one historical session ran lens diagnostics 16× alongside compress 11×), but ships the injection patterns users complain about, doubles tool schemas in every request, and relies on undefined handler ordering — bcp's README explicitly cannot defend against post-bcp context handlers.
• Adapter/bridge only (bcp consumes an external checker): smaller maintenance ask, but the LSP runtime stays outside the package — worse out-of-box experience, version-skew risk, and the ordering contract (C2) becomes unenforceable across package boundaries.
• Spec-only hooks: minimal maintainer cost, but fragments the ecosystem; the check loop is core to agent quality and belongs native.

---

Local measurements behind the conflict attributions (multi-provider, 2105-turn corpus, sanitized): providers without server-side prefix caching show zero-cache-read turns regardless of extensions; on cache-equipped providers, injected-message turns diverge only at the tail (~100 tokens/turn) while tool-list mutation is the whole-prefix invalidator — matching pi-lens' own tool-set-policy comment. A/B protocol to quantify loop benefit: same task set with/without the loop, measuring tokens billed, turns to green tests, residual errors after the agent declares done.

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 This is a feature request of major architectural scope, so per project rules I evaluated it before touching any code — no implementation has started. Here is my assessment, with verification evidence from both codebases.

What I verified

pi-lens claims — all check out. pi-lens is a real, actively maintained third-party project (apmantza/pi-lens, npm pi-lens v4.1.6, MIT). Every specific internal referenced in the issue exists in its source:

• PI_LENS_NO_CONTEXT_INJECTION flag (clients/lens-flag-registry.ts, index.ts)
• The tool-set-policy comment verbatim — "a transposition is a changed prefix, i.e. a cache miss" (clients/tool-set-policy.ts:146)
• AUTHORITATIVE_CONTENT per-file cap + shared multi-file budget (clients/runtime-tool-result.ts:92,2332-2343)
• Mutation bridge globalThis[Symbol.for("pi-lens:mutation-bridge")] (clients/mutation-bridge.ts)
• /lens-allow-edit, --lens-guard, activate-tools lazy activation — all present

The cache-attribution analysis (damage comes from delivery, not from running checks) is sound and consistent with pi-lens' own docs.

bcp-side claims — two are inaccurate in ways that matter to the design:

1. C2 mischaracterizes bcp's absorb. Absorb is not "compresses large tool results at arrival." It is model-driven: the kernel appends a forced prompt to eligible large tool results demanding the model call absorb({ref, summary}); the pair is hidden only after the model actually absorbs (acp-kernel/dist/absorb.d.ts). Nothing auto-compresses at arrival. The ordering concern in C2 is still real (an annotated write/edit result over the absorb threshold would get absorb-prompt churn), but the resolution maps cleanly onto absorb's existing tool-exclusion config (isAbsorbCandidate checks excluded tools) — no new exemption machinery needed.
2. C5's "line 1 = block status" doesn't match the current nudge shape. bcp's nudge is a per-turn user-role message built by nudgeMessage() (src/index.ts:716) via renderNudgeText — compressible ranges + block status + example refs, with dedup/emergency/retry-cap logic around it. It's extensible, but the proposed fixed two-line contract would be a new format, not an extension of an existing line-based one. Also note: the nudge is itself context injection by design — the "zero ephemeral user-role messages" invariant must be scoped to the checks engine, since bcp already injects its own nudge channel (which is stable-state-derived, so cache-behavior differs; worth stating explicitly in the invariant list).

Minor: the mutation bridge (C6) is pi-lens' symbol, not an "existing" bcp primitive — it only becomes bcp-owned post-merge. And absorb isn't one of the 8 pipeline stages named in the README; it rides alongside them.

My evaluation

Reasonableness — the goal is real. A same-turn verification loop measurably cuts defect-discovery cost, and the token math (50–150K wasted per missed defect vs ~0.5–2K for a same-turn summary) is plausible. No objection to the goal.

System design & coupling — this is where I diverge. Three concerns:

1. The merge solves a problem that lives in pi-lens. By the issue's own attribution, all cache damage comes from three delivery patterns — ephemeral injection, lazy tool-list mutation, full-content append. All three are fixable inside pi-lens, and two are already half-fixed there (the NO_CONTEXT_INJECTION flag exists precisely for cache-sensitive sessions; the degraded over-cap attachment path exists and the issue itself says make it the only path). The physical merge buys little that these fixes don't:

   • D1 (same-turn attach): works today — pi-lens already writes into tool results; change the format to bounded severity-tagged summary.
   • D2 (ref store): findings in tool results are already ref-addressable, absorbable, and compressible through bcp's normal pipeline — refs attach to any message, no kernel change needed. An extension-side blob store referenced by ACP refs would instead require new ref semantics in acp-kernel (refs to non-message artifacts), which ripples into every adapter (opencode-acp, billion-context). Bounded detail-in-tool-result achieves the same economics without the kernel surgery.
   • D3 (pull tool): host-registered tools need no bcp ownership; constant registration at session start is a one-line policy change in pi-lens.
   • Ordering (C2/C5): Pi processes tool results before the next context event, so "annotate → then bcp pipeline sees it" is the natural event order across packages too. bcp rebuilding its working set from the session log makes it robust to exactly this pattern.

2. Boundary pollution. bcp is deliberately a pure message transformer: zero runtime deps (acp-kernel bundled inline, peer-deps only), one failure domain. Adding LSP server lifecycle management (long-running children), ~14 external binaries (gitleaks, trivy, govulncheck, knip, jscpd, madge, vulture, zizmor, biome, ruff, eslint, stylelint, rubocop, clippy), autofix execution, and an async test runner changes the package's install footprint, security surface (auto-fixers execute transforms derived from repo files on every edit), release process (bcp releases become gated on a scanner/LSP compatibility matrix), and failure modes (a hung LSP child now implicates the context manager). C7's config-gating mitigates runtime cost but not shipped surface — the code ships in dist regardless.

3. Third-party maintenance absorption. pi-lens is not ranxianglei's project — it's apmantza/R3LiC's, with substantial independent infrastructure (strict TS configs, stryker mutation testing, i18n, MCP server, cases/skills/rules trees, active changelog through v4.x). Merging means either taking over maintenance of an actively developed project or forking it and paying continuous re-merge cost as upstream evolves. Upstreaming the three cache fixes is far cheaper and lands the fix where the community complaint actually points.

Recommendation

Do not physically merge now. Instead, in this order:

1. Upstream the three cache-safety fixes to pi-lens: default-off context injection (make the existing flag the default or ship a cache-safe profile), constant tool registration (delete activate-tools), integrity-pointer-only attachment (drop AUTHORITATIVE_CONTENT append). These resolve C1, C3, C4 outright and C2/C5 by construction.
2. Document the coexistence contract in bcp's README (tool-result annotation precedes the context event; annotated results exempt via absorb exclusion config; single-nudge discipline).
3. Run the A/B protocol the issue proposes (tokens billed, turns-to-green, residual errors, loop on/off) to measure the loop's actual value on real task sets.
4. Revisit native integration (the P0–P3 plan) only if the data shows the loop matters enough and pi-lens upstream can't/won't ship the delivery fixes. If we get there, P0 as scoped remains shippable — but note its "constant tool registration of checks_diagnostics in bcp" presumes the engine arrives in bcp, so it should wait for that decision.

This gets users cache-safe verification immediately, keeps bcp's boundary clean, defers the big architectural commitment until it's measured rather than argued, and leaves the door open. If you'd rather go straight to native integration despite the above, say so explicitly and I'll start from P0 — but I wanted the record to show why I'm recommending the split path.

---

中文摘要：已逐条核实 issue 中关于 pi-lens 和 bcp 的技术论断（pi-lens 侧全部属实；bcp 侧 C2/C5 对 absorb 机制和 nudge 形态的描述与代码不符）。核心判断：三个破坏缓存的问题都出在 pi-lens 的投递方式上，且其中两个 pi-lens 已有半成品修复——向上游修投递 + 文档化共存契约 + 先跑 A/B 量化收益，比把整个第三方执行引擎并入 bcp（引入 LSP 子进程、14+ 外部二进制、第三方维护负担）更划算。建议不立即物理合并，方向由 owner 拍板。

[ranxianglei]

你调查一下为什么lens会缓存失效?

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 查完了。我 clone 了 pi-lens（v4.1.6 源码）逐层读了代码和它的 changelog。结论：缓存失效有一个历史根因（它自己已经修掉），当前版本还有几个仍在起作用的残余因素。

历史根因（#1016 之前）：prepend 到 index 0，每轮翻转 messages[0]

pi-lens 自己的 changelog #1016 条目原文：

the context event handler … splices pi-lens's ephemeral turn-end findings immediately before the final message instead of prepending them at message index 0. Prepending flipped messages[0] every turn, which invalidated the entire prompt-cache prefix on every prefix-caching provider (Anthropic, Bedrock, and OpenAI — all key the cache on the exact token prefix).

机制：Pi 的 context 事件在每次 provider 调用前触发（不只是轮边界）。pi-lens 早期把临时 findings 消息 splice 进每次调用的位置 0 → 请求的第一个 token 块每次都变 → 按精确 token 前缀建缓存的三家 provider 每次请求都零命中。这是最恶性的失效形态：不是多花一点 token，而是整个会话每个请求都全价。

他们发现后做了什么（这部分回答了"为什么现在还会失效"的另一半）

• #1016：注入点改为 insert-before-final（尾部是纯 user prompt 时）或纯 append（尾部是 tool_result/assistant 时——splice 进去会破坏 tool_use↔tool_result 相邻性，直接 HTTP 400）。messages[0] 从此字节稳定。
• #1018：加了三个观测信号（clients/cache-observability.ts）：cache_usage（每条 assistant 消息记录 provider 回报的 cacheRead/cacheWrite）、cache_context（每次 context 调用记录 pi-lens 自己的注入来源/放置方式/字节数）、cache_prefix_break（每次调用对 messages[0] 做哈希，变了就记 CHANGE——回归守卫）。
• #1071（2026-08-21 专项调查）：miss 归因。每个低命中轮次给一个 verdict：ttl-expired / prefix-broke / partial-eviction / model-provider-changed / unknown，会话结束输出 cache_usage_summary。代码注释里还写了他们用真实数据选了 90 个"partial break"形状的轮次（上界 2.7M tokens）做的分析。

也就是说：他们一直在量自己的缓存命中率，有专门的归因体系，知道每次 miss 归哪个因。

当前版本（v4.1.6）仍在造成失效/成本的因素

1. 懒加载工具激活 → 每次激活一次全前缀 miss（clients/tool-set-policy.ts）。他们的原话注释（line 146）："the active-tools array is what serializes into the request's tool block — a transposition is a changed prefix, i.e. a cache miss." 新会话以缩减的工具集启动，模型调 activate-tools 后工具按激活顺序加回 → tool block 变化 → 该次请求全前缀 miss。这是他们刻意的设计权衡（用偶发全 miss 换常驻全量 schema 的 token 成本），session rebuild（fork/reload/resume）时逐字符恢复 roster 就是为了不引入新的漂移。
2. 临时注入仍默认开启（session-guidance / turn-findings / test-findings / agent-nudge，context handler 在 index.ts:3787 附近）。#1016 之后放置不再破坏前缀，但消息是一次性的：出现在某次请求、被消费、下次消失 → 相邻两次请求的共享前缀止于 splice 点，其后的区域每轮重新 cache-write；注入内容本身的字节也按 input 计费。PI_LENS_NO_CONTEXT_INJECTION=1 可整体关闭（tools/LSP/read-guard/formatting 保持运行）。
3. 全文内容附件（AUTHORITATIVE_CONTENT）（clients/runtime-tool-result.ts:92,2332-2343）：把编辑后的整文件内容附到 tool result 上，per-file cap（lspMaxFileBytes）+ 跨文件共享预算；投递侧现在另有 40 KiB/text-block 硬上限（#2852）。它本身不破坏前缀（在尾部），但是间接放大器：把上下文更快推向窗口上限 → 触发宿主侧截断/压缩（bcp 的 emergency truncation 是重写历史 = 全局失效）→ 首现时更大的 cacheWrite。
4. 与 lens 无关、但其观测体系测到的 provider 侧原因：TTL 过期（归因阈值默认 60s，PI_LENS_PROVIDER_CACHE_TTL_MS 可调）、partial eviction（会话超出 provider 缓存窗口）、模型/provider 切换。这些 verdict 类型的存在本身就说明：#1016 修完后 miss 并没有消失——相当一部分来自空闲间隙和窗口驱逐，任何扩展都修不了。

对 #374 的含义

这进一步支持我之前的判断：缓存伤害集中在 pi-lens 的投递层，而上游已经把最恶性的一条修掉了（#1016），其余几条都有现成开关或半成品（PI_LENS_NO_CONTEXT_INJECTION；常注册只需删掉 activate-tools 懒激活；附件已有降级路径）。所以"上游修投递 + 文档化共存契约"相对"把整个执行引擎并入 bcp"的性价比差距比 issue 写的还要大——合并不会带来超出那些开关的任何额外缓存收益，只会带来进程监管和第三方维护负担。

需要的话我可以起草一份提交给 pi-lens 上游的具体修改清单（注入默认关 / 工具常注册 / 附件指针化）作为 #374 的第一阶段。