feat(tools): disable the deferred-toolbox size bounds

[asto18089]

Summary

Sets TOOL_ACTIVATION_CACHE_MAX_NAMES and TOOL_ACTIVATION_CACHE_MAX_SCHEMA_BYTES (crates/tui/src/core/session.rs) to usize::MAX / 2 — an effectively-unbounded sentinel: comparisons against the exact usize::MAX extreme trip clippy's deny-by-default absurd_extreme_comparisons (and rustc's unused_comparisons), so the literal extreme cannot serve as the bound and any slightly smaller value compiles — so the bounded-toolbox LRU eviction never fires. This is a Pinvou fork-only decision, registered in the parent repo's fork register in the companion PR (Pinvou/pinvou-agent#694).

Why

Under 2026-10 provider prompt-cache pricing, every eviction mutates the request tools array and re-prefills system + tools + the entire conversation history at miss price (write premiums up to 2x: Anthropic 1.25x/2x, Kimi k3 1x/2x, GPT-5.6+ 1.25x), to stop paying ~0.1x on a few hundred tokens of schema. Break-even for one eviction needs ~75 further tool-free requests; the full eviction → notify → re-search → re-activate cycle costs ~2.5x the whole history. The live incident class: a strong model fabricated tool results for browser tools silently evicted mid-task. Full analysis and the alternative approaches (hysteresis, cost terms, Moonshot's append-in-context injection) are filed upstream at codewhale-hq#6969; this fork cut the mechanism off pending that discussion.

Sequencing with #101

Both this PR and #101 address the same incident class from the two sides: #101 reports every toolbox eviction to the model; this PR removes the size-eviction cause entirely. They touch the same six files from the same base blobs, so they conflict textually in either merge order. Intended sequencing: this PR lands first (smaller, and pins the posture the reporting must build on); #101 then rebases — its catalog-shrink reporting remains fully relevant, while its size-eviction reporting channels become dead-in-fork code (the bounds can no longer fire) and can be dropped or kept for upstream parity at #101's discretion.

What is preserved

• Admission bookkeeping and ordering, recency touches, hydration receipts: unchanged.
• Catalog-shrink revalidation: unchanged — a disconnected MCP server, deny rule, mode switch, eager promotion, or session sync still drops entries exactly as upstream. Only the size bounds never fire.
• [tools].always_load semantics: unchanged.

Changes

• Constants → usize::MAX / 2 with a doc comment stating the fork posture, the economics, and why the sentinel value rather than the literal extreme.
• The tool_search oversize rejection reason claims no bound and interpolates no numbers: in this fork the arm is dead except for the per-entry serde-failure sentinel (discovery pre-filters deferred membership), so the prose states the schema could not be measured for admission.
• The subagent hydration error no longer claims a bounded toolbox or misadvises a narrower query.
• docs/TOOL_SURFACE.md toolbox sections state the fork divergence truthfully: the sentinel value, the unbounded-growth tradeoff (the activated set is now the only clamp on the request tools array; very large activations can approach provider request-size or tool-count limits), and the parent-conversation wording.
• Tests rewritten for the disabled posture (upstream tests pinned the eviction semantics): activation above the historical bounds retains everything (forkguard_deferred_toolbox_bounds_are_disabled, fixtures grown past both historical bounds so a byte-bound-only revert fails too), oversized schemas are admitted (forkguard_oversized_schema_is_admitted_while_the_bounds_are_disabled), the recency touch reorders without displacing (forkguard_touching_a_cached_tool_moves_it_to_the_back_and_evicts_nothing), cached execution retains all activations (forkguard_cached_execution_keeps_every_activation_without_granting_uncached_names), and the subagent surface test — which still pinned upstream's 8-name/16KiB eviction and ran red on CI — is rewritten as forkguard_small_surface_caches_are_independent_unbounded_and_revalidated with 2 KiB schemas so a revert of either historical bound fails it.
• Round-2 review follow-ups (comment 5502767570): the activate/revalidate/execute_tool_search_with_cache doc comments state the fork posture instead of upstream's dead rejection/eviction behavior, the constants doc scopes rustc's unused_comparisons to the numeric-literal form (it does not fire through a const item), and TOOL_SURFACE.md drops the implementation literal and discloses the bookkeeping growth.

Validation

• cargo test -p codewhale-tui --lib with RUST_MIN_STACK=33554432 (locally raised; CI runs its suites at 16 MiB, and without a raised stack the tools::subagent filter aborts locally): 12091 passed / 0 failed at fd14b6a7e, including the rewritten subagent suite.
• cargo test --lib -- core::session core::engine::tool_catalog: 23 passed / 0 failed; cargo test --lib -- core::engine::tests: 404 passed / 0 failed (407 with --all-features) — re-run at fd14b6a7e.
• cargo clippy --lib -- -D warnings: clean. cargo fmt --all -- --check: clean.
• Correction to an earlier validation note: the first commit attributed a full-suite tools::subagent failure to a pre-existing local environment abort. That was wrong in effect. The filter aborts locally without a raised stack (CI runs its suites at 16 MiB); with RUST_MIN_STACK=33554432 the suite completes and exposed a real failure — small_surface_caches_are_independent_bounded_and_revalidated still pinned upstream's 8-name/16KiB eviction, CI was red on it, and it is rewritten in the second commit (196bed7fa).

No-Issue: fork-level economics decision; the upstream analysis lives at codewhale-hq#6969.

[asto18089]

Fresh review — requesting changes (1 blocker, 3 majors, minors)

Reviewed from scratch at head a7f64b5c4 (base 3118c36b8 = current pinvou3-clean tip — no rebase needed, MERGEABLE). Lanes: activation-machinery audit, tool_search-path audit, repo-wide stale-reference sweep, fork-governance/companion audit, design review, upstream-parity check, plus local gate execution (tests, clippy, fmt, and a red-green of the value-choice claim).

The core change is sound and the rationale checks out. Verified: the two constants are used only in pure comparisons with saturating_add aggregation — overflow-safe at usize::MAX/2; every policy-driven removal path (revalidate on disconnect/deny/mode-switch/eager, session-sync clear, hydration receipts, always_load bypass) is byte-identical to base; no second bound exists that still fires; the request tools array is built in catalog order, so nothing downstream depends on cache size or recency order. The red-green on the value choice is real: at usize::MAX, clippy denies with absurd_extreme_comparisons (deny-by-default, 5 errors); MAX/2 compiles clean. Upstream issue codewhale-hq#6969 exists at the correct venue, matches every number the body quotes, and does not contradict the fork route. Upstream has not touched the bounds mechanism itself (still 8/16KiB at 008d21d69).

BLOCKER

B1. CI is red: an upstream-semantics test this PR missed. tools::subagent::tests::small_surface_caches_are_independent_bounded_and_revalidated (crates/tui/src/tools/subagent/tests.rs:7599) still pins the old 8-name/16KiB posture and fails deterministically at head — confirmed on CI (check job 115210635261 → failed; gate → failed) and reproduced locally: 582 passed; 1 failed, panic at tests.rs:7611 (assert!(!first_names.contains("deferred_0")) — nine warm names no longer evict). Two further assertions behind it are now inverted too: hydrate("oversized", 17KiB).is_err() (line 7620) and the 3×6KiB byte-budget eviction (lines 7627–7633). The session.rs and tool_catalog tests were rewritten; this sibling file pinning the same semantics was missed. This also conflicts with fork-policy §3.4 (upstream tests invalidated by fork semantics must be rewritten or explicitly annotated, not left red). Merge-blocking under branch protection (check + gate required).

MAJOR

M1. The Validation claim that hides B1 is false in effect. Both bodies attribute the tools::subagent failure to a "pre-existing local environment abort … identically on pristine pinvou3-clean … not touched by this change (no subagent file is modified)." The test compiles, runs in isolation (0.07s), and fails on semantics introduced by this change. With RUST_MIN_STACK=33554432 the whole filter completes locally and reports exactly this one failure; CI's runner (which sets the same stack) shows the same. A local stack-overflow abort at most masked the failure — it does not make the claim true. "No subagent file is modified" is the wrong scope test: the PR modified the behavior that module asserts. Please correct the PR body and fix the test (the commit body is immutable).

M2. Head-on collision with open sibling PR #101 — the other fix for the same incident. #101 carries the eviction-reporting apparatus and touches all four files this PR touches, from the same base blobs (session.rs e654eb8b3): the same struct doc, the same oversize-prose line in execute_tool_search_inner, the same TOOL_SURFACE.md paragraph — guaranteed textual conflicts in either merge order. Semantically, merging #104 first turns most of #101's size-eviction reporting channels into dead-in-fork code (its catalog-shrink reporting remains fully relevant — #101 is not mooted). Neither PR references the other; only codewhale-hq#6969 ties them. Please state the intended sequencing and what survives of #101 in both PR descriptions, and expect a non-trivial rebase on whichever lands second.

M3. The fork register misstates the value it registers. docs/fork-modifications.md (companion PR codewhale-hq#694, T2 entry) and the CW commit body say the constants are set to usize::MAX; the code is usize::MAX / 2 (session.rs:32,37). The register is the single source of truth under AGENTS.md; codewhale-hq#694's own PR body states MAX/2 correctly — the register text must too.

MINOR

• m1. Value narrative overclaims (session.rs:28-31): "the largest the engine accepts" is false (usize::MAX - 1 also compiles clean — the lints reject only comparisons against the exact usize::MAX extreme) and "one ULP below arithmetic reach" is false (MAX/2 is 2⁶³ below). Suggest: "MAX is lint-rejected; MAX/2 is an effectively-unbounded sentinel."
• m2. The comment at tool_catalog.rs:1387-1390 inverts the reachability story. delta.rejected on this path has exactly two causes in activate: not-a-deferred-member — structurally impossible here, since both discovery functions pre-filter deferred membership (tool_catalog.rs:783,809) and pass the same catalog slice to activate — and per-entry oversize, including the serde-failure usize::MAX sentinel (session.rs:78-80). So the arm is unreachable outright; there are no "other causes" — and in the sentinel case the model would see "…(9223372036854775807 cached tools, 9007199254740991KiB…)". Keep the prose qualitative or fix the comment; also move the format! into the rejection closure (it currently allocates on every tool_search call).
• m3. Stale model-facing string in the child surface: tools/subagent/mod.rs:14161 "could not enter the bounded child toolbox; use tool_search with a narrower query" — the child toolbox is no longer bounded, and the remaining failure causes (membership/serde) make both the reason and the advice wrong. This repo has precedent commits specifically for aligning model-facing text with engine reality (72e98fd, 3427eb6).
• m4. session.rs:502-507: the test comment says "the bound is usize::MAX here" (it is MAX/2) and justifies the 17 * 1024 literal as overflow-avoidance — moot, since TOOL_ACTIVATION_CACHE_MAX_SCHEMA_BYTES + 1 compiles and is the stronger boundary-adjacent assertion.
• m5. The only remaining rejection path (serde-failure sentinel) lost its pin when oversized_schema_is_never_admitted was deleted; nothing exercises it now. Also forkguard_deferred_toolbox_bounds_are_disabled decisively over-covers the name bound (64 names) but only barely covers the byte bound (64 small schemas ≪ 16KiB), so a byte-bound-only revert would pass it — worth ≥1KiB-per-schema fixtures.
• m6. Companion codewhale-hq#694 housekeeping: stale guard banner strings ("62 commits" → 63; "47 registered" → 48; display-only), and the register's T2 bullet cites codewhale-hq#6969 but not CW#104 (sibling bullets cite their CW PRs).
• m7. NITs: PR body says Kimi write premium "1.25x–2x" while codewhale-hq#6969's own table gives Kimi k3 as 1x (5m) / 2x (1h); TOOL_SURFACE.md "unbounded in this fork, like the parent" reads as parent-repo but means the parent conversation — one clarifying word; forkguard_ prefix applied to only one of the four rewritten fork-posture tests (no written rule, but inconsistent within one PR).

Design notes (non-blocking)

• The mechanism choice is right for this fork: a two-constant pin keeps upstream merge surface minimal, is trivially revertible, and matches repo idiom (pinned values + forkguard_ pins + parent register). Config knobs, deleting the machinery, or a cfg feature are all worse here.
• Unbounded growth is a deliberate and disclosed tradeoff, but it is now the only clamp on the request tools array: no in-repo cap exists, so provider tool-count/request-size ceilings (e.g. OpenAI-family 128-tool caps) are newly reachable on MCP-heavy sessions, and codewhale-hq#6969 recommends cost-aware reform rather than none. One honest sentence about growth in TOOL_SURFACE.md (or a high soft ceiling) would close the disclosure gap — author's call.
• Upstream is mid-iteration on this exact mechanism (priority-aware batch insertion in activate at upstream HEAD, absent from fork base), so the next sync must re-justify and re-express this divergence against evolved code. Inherent to the idiom; worth a line in the register's revisit note.

Verified claims (selection)

Claim	Verdict
Size bounds never fire at MAX/2; arithmetic overflow-safe	SAT
Admission bookkeeping / recency touches / receipts / always_load preserved	SAT (impl byte-identical to base)
Catalog-shrink revalidation + session sync preserved	SAT
Local gates: 23/0, 404/0, clippy clean, fmt clean	SAT (reproduced locally)
"Tests rewritten for the disabled posture"	PARTIAL — one sibling file missed (B1)
Full-suite tools::subagent failure = pre-existing environment, "not touched by this change"	UNSAT as stated (M1) — one deterministic PR-caused failure
codewhale-hq#6969 supports the quoted economics	SAT
Companion codewhale-hq#694: gitlink, EXPECTED_HEAD, EXPECTED_COMMITS=63 (rev-list verified), fingerprint matches test, 168 forkguard names	SAT component-wise

Required before merge: fix B1 (rewrite or explicitly annotate the subagent test), correct the M1 framing in the PR body, state the M2 sequencing with #101, and fix the M3 register text in codewhale-hq#694 (plus its m6 banner strings). Everything else is the minor pass above.

No-Issue: none — this is a review comment.

[asto18089]

Fix wave pushed — head is now 196bed7fa (second commit fix(tools): rewrite stale subagent toolbox test for disabled posture). Disposition of the review findings:

B1 (red CI) — fixed. small_surface_caches_are_independent_bounded_and_revalidated rewritten as forkguard_small_surface_caches_are_independent_unbounded_and_revalidated with a §3.4 annotation; 2 KiB schemas so nine activations exceed both historical bounds (9 × ~2.1 KiB ≈ 19 KiB > 16 KiB), and the earlier assertions inverted to the disabled posture (all nine advertised, 17 KiB hydrate Ok, 3×6 KiB byte-budget retained) while keeping the independence and catalog-shrink pins.

M1 (false validation claim) — fixed. The PR body now states the truth: the filter only aborts without the stack size CI sets; with RUST_MIN_STACK=33554432 it completed and exposed the real PR-caused failure. (Commit body is immutable, so the correction lives in the PR body.)

M2 (#101 collision) — addressed. A "Sequencing with #101" section now states: this PR lands first, #101 rebases, its catalog-shrink reporting stays fully relevant, and its size-eviction reporting becomes dead-in-fork code to drop or keep at #101's discretion. Cross-note posted on #101.

M3 (register value) — fixed in companion Pinvou/pinvou-agent#694 (d5addc277): register T2 entry now says usize::MAX / 2 with the lint reason and cites this PR; guard banners trued up (64 commits / 49 registered); gitlink/EXPECTED_HEAD → 196bed7fa, EXPECTED_COMMITS → 64.

m1–m5, m7 — fixed in 196bed7fa: value narrative corrected (sentinel, not "largest the engine accepts"/"one ULP"); rejection comment rewritten to the real reachability (per-entry size sentinel only) with the format! moved lazily into the closure; subagent hydration error no longer claims a bounded toolbox; oversized-test comment sized against the historical bound; forkguard pin fixtures grown to 1 KiB schemas (byte-bound-only revert now fails); fork-posture tests renamed under the forkguard_ convention; TOOL_SURFACE.md states usize::MAX / 2, the unbounded-growth tradeoff (provider request-size/tool-count ceilings now the only clamp), and "parent conversation's".

m6 — fixed in codewhale-hq#694: banner strings, #104 citation, plus two new T2 fingerprints pinning the constant lines themselves (closing the ≥65-names/≥17 KiB silent-regression band); register key-test list extended with the three new forkguard pins.

Not done, deliberately: the serde-failure sentinel rejection path remains untested — it requires a Tool that fails serde_json::to_vec, which is not constructible with JSON-native field types; noted here for the record. CHANGELOG left untouched (mixed precedent; upstream-lane hunks are written at merge time).

Gates at 196bed7fa: cargo test -p codewhale-tui --lib (RUST_MIN_STACK=33554432) 12091/0; targeted 23/0 and 404/0; clippy -D warnings clean; fmt clean. Companion: ./scripts/fork-guard.sh --fast green (layer 0 at 196bed7/64, fingerprint layer incl. the two new constant pins, 171 forkguard names).

[JensenChen28]

复核 exact head 196bed7f：逐项检查了会话与子代理 toolbox 的入选、重验证和 catalog shrink 路径。两个上限改为 usize::MAX / 2 后，普通 schema 不再因 8-name/16KiB 阈值被静默 LRU 淘汰；断连、deny、模式切换和 eager promotion 的重验证仍保留，文档也明确了 provider 工具数量/请求体上限风险。git diff --check 通过；本地 cargo test -p codewhale-tui --lib --locked forkguard_ -- --nocapture 实际运行 161 项，161 passed、0 failed。未发现代码阻塞项。当前远端 check 与 CodeQL Rust 仍在运行，待 current-head 必要门禁成功后再最终批准。

[JensenChen28]

此前已完成 exact head 196bed7f 的代码与专项复核：会话及子代理 toolbox 取消大小淘汰后仍保留 catalog/policy 重验证，文档明确 provider 限制风险；本地 forkguard 专项 161/161 通过，diff check 通过。当前 check、CodeQL、DCO 与敏感信息门禁均已成功，merge state CLEAN，批准。

[asto18089]

Fresh full review at head 196bed7fa (base pinvou3-clean @ 3118c36b8 — head already descends from the current tip, no rebase needed). Eight independent lanes: bounds-completeness, test adequacy, prose audit, scope/commit hygiene, docs sweep, companion codewhale-hq#694 audit, empirical gates, and judgment. Verdict: COMMENT — 0 BLOCKER, 2 MAJOR (one in-PR, one on companion codewhale-hq#694), minors below. The change itself is verified useful, root-caused, complete for its scope, smuggle-free, and its validation numbers reproduce exactly.

MAJOR

M1 — Stale bound-prose doc comments left inside this PR's own blast radius. The PR rewrote the constant and struct docs for the disabled posture but missed three method docs that now state the opposite of the code and of this PR's own tests:

• crates/tui/src/core/session.rs:116-118 — activate() doc still reads "An oversized schema is rejected; otherwise least-recently-used entries are evicted until both bounds hold." Both halves are now false in the fork; forkguard_oversized_schema_is_admitted_while_the_bounds_are_disabled (same file) pins the contradiction.
• crates/tui/src/core/session.rs:120-121 — revalidate() doc "…and enforce both cache bounds": the membership half is live, the bounds half can never fire.
• crates/tui/src/core/engine/tool_catalog.rs:1299-1300 — execute_tool_search_with_cache doc: "retaining activated schemas in the bounded conversation cache."

M2 — Companion codewhale-hq#694 register rows were never re-trued to the review-fix head, and self-contradict the same table. In docs/fork-modifications.md at d5addc277: line 48 says the batch advanced the head "至 a7f64b5c4" and "r1 基线之上 48 个登记提交"; line 56 says "63 个带 DCO sign-off 的提交", "r1 之后 48 个", and "工具箱停用批次为保持提交形态的单提交"; line 58 says "168 条独立 forkguard_* 行为名". Actual at 196bed7fa: 64 commits above upstream, 49 above r1, a two-commit batch, 171 forkguard names — the adjacent 维护分支 row (line 53) was correctly updated to 196bed7fa/49/“含复审修正第二提交”, so the table now disagrees with itself. The drift row (line 57) is honestly labeled 实测于 a7f64b5c4 but lacks a head measurement (296 files, +51139/-14273, net 36866). One-line follow-ups before codewhale-hq#694 can merge.

MINOR

• m1 — session.rs:28-32 constant doc: the parenthetical "(and rustc's unused_comparisons)" is empirically false for the form a real bound takes. Adjudicated with the repo-pinned toolchain (stable 1.99.0, scratch project): unused_comparisons fires only on the numeric-literal form (x > 18446744073709551615usize), not via the const item / usize::MAX expression this code uses; clippy's deny-by-default absurd_extreme_comparisons alone carries the conclusion (verified it fires const-propagated, and that MAX/2 and even MAX-1 are lint-clean). Drop the parenthetical or scope it to the literal form.
• m2 — PR body Validation: "RUST_MIN_STACK=33554432 (the stack size CI sets)" — no CI in either repo sets 32 MiB: fork-ci.yml:27 and ci.yml:617,622 set 16777216, ci.yml:38,292 set 8388608; 33554432 appears nowhere in CI or scripts (CW or parent). It is the local shell value. Substance unaffected — CI is green at its own 16 MiB, and the full lib suite reproduces 12091 passed / 0 failed locally under either size. Same phrasing echoed in codewhale-hq#694's body.
• m3 — PR body Sequencing: #101 conflicts over "the same four files" — at head #101 touches all six of this PR's files, including both subagent files (it rewrites the same hydrate-error line) and the same session.rs constant-doc region. The conflict-in-either-order conclusion is right and stronger than stated; the count is stale. #101's own body still does not mention #104 or the merge order.
• m4 — Growth-cost disclosure gap: with the cap gone, revalidate's retain and activate's while-condition each pay an O(active × catalog) serde_json::to_vec scan per turn/search (upstream's 8-entry bound capped this). TOOL_SURFACE.md discloses the request-size/provider-limit risk but not the CPU/allocation growth. One sentence would close it.
• m5 — The oversize-rejection prose arm (tool_catalog.rs:1396-1405) is verifiably dead except via the serde-failure sentinel (both discovery paths pre-filter deferred membership; Tool is all JSON-native fields), and on that arm it would render "(9223372036854775807 cached tools, 9007199254740991KiB…)" while asserting a "bounded conversation toolbox" the fork removed. A bound-free message ("schema could not be measured/admitted") would be strictly better for its one reader. Cosmetic, unreachable.

NIT (no action required)

touching_a_cached_tool_moves_it_to_the_back_and_evicts_nothing pins fork posture but lacks the forkguard_ prefix its siblings carry (invisible to a forkguard_ grep); TOOL_SURFACE.md:80 leaks the implementation sentinel usize::MAX / 2 into contract prose; test comment "the fork bound has no constructible neighbor" — MAX/2 + 1 is constructible, it is the ~8 EiB schema that is not; commit 1's message says "usize::MAX" while its own tree already has MAX/2 (immutable, but disclosed in commit 2's body); revalidate()'s per-entry byte-reject leg has no test at head or base (pre-existing); LRU victim identity (pop_front vs pop_back) is now mutation-invisible — inherent to the disabled posture, and both bound reverts themselves remain caught.

Verified clean (multi-lane, adversarial)

• Root cause & completeness: size-origin eviction fully eliminated; complete enumeration of every remaining way a deferred tool leaves the request tools array (catalog-shrink revalidation — silent by design at head, reported by #101 post-rebase; session-sync clear; eager promotion keeps the tool; hydrate rejection surfaces with the corrected message; serde sentinel unreachable). No hidden consumer of the old bounds anywhere (UI copy, sizing heuristics, token budgeting — estimate_input_tokens_conservative has no tools term; the unbounded-window residual is disclosed in TOOL_SURFACE.md and the body).
• Test adequacy: every fixture's math verified against real serialized sizes (64×1.1KiB ≈ 70KiB; 17KiB single; 9×2.1KiB; 3×6KiB isolating the byte bound) — a names-only revert fails 4 tests, a byte-only revert fails 3, joint revert fails all; deleted oversized_schema_is_never_admitted coverage re-established inverted; delta.admitted == requested order-safety confirmed against the implementation.
• Sentinel justification: usize::MAX unusable confirmed empirically (clippy absurd_extreme_comparisons is deny-by-default, workspace denies warnings, CI runs -D warnings); MAX/2 clean; no arithmetic hazard (comparisons, /1024, saturating_add; neither while-loop can spin).
• Scope purity: both commits' files exactly on-topic, hunk-level; activate/revalidate/admission ordering/always_load logic byte-identical to base; codewhale-hq#694 touches exactly 3 files (gitlink 196bed7fa exact, three grep -qF fingerprints byte-exact, EXPECTED_HEAD/EXPECTED_COMMITS=64 correct under the script's above-upstream-baseline semantics, banner 49 correct); fork-guard.sh --fast exit 0 in a codewhale-hq#694 worktree with the submodule at 196bed7fa; codewhale-hq#694's fast-gate red is exactly the documented transition assertion (gitlink ahead of pinvou3-clean until this PR lands), all 15 substantive parent checks green.
• Validation: cargo fmt --check clean; cargo clippy -p codewhale-tui --lib --all-features --locked -- -D warnings (CI's exact allow-set) clean; core::session core::engine::tool_catalog → 23/0; core::engine::tests → 404/0 default features (407 all-features — body consistent); full lib suite 12091/0 reproduced; 161 forkguard_* tests green locally; CI at head: all 10 checks pass, and the correction paragraph is TRUE from CI history (run 38371890114 failed exactly on small_surface_caches_are_independent_bounded_and_revalidated at a7f64b5c4).
• Upstream/coherence: codewhale-hq/Codewhale#6969 exists and every economics number in the body matches it; #101 sequencing characterization accurate (its bounds-eviction channels go dead-in-fork, catalog-shrink reporting stays live); the sentinel-vs-delete-vs-configurable-vs-upstream-only tradeoff is judged sound for a fork awaiting the upstream decision; no undisclosed conflicts with other open PRs; docs sweep found no stale 8/16KiB prose anywhere (CHANGELOG silence is repo policy — entries are written on main at merge time).

[asto18089]

Round-2 review disposition (review 5502767570) — all actionable findings fixed in the third commit fd14b6a7e; nothing behavioral changed.

Fixed

• M1 — activate() and revalidate() doc comments now state the fork posture (upstream's oversized-schema rejection and LRU eviction are dead under the disabled bounds; only membership-based drops fire), and execute_tool_search_with_cache no longer calls the cache bounded.
• m1 — the constants doc scopes rustc's unused_comparisons to the numeric-literal form, which is the empirically verified truth (it does not fire through a const item); clippy's deny-by-default absurd_extreme_comparisons alone carries the sentinel justification.
• m2/m3 — PR body: the stack-size parenthetical now says CI runs its suites at 16 MiB (32 MiB was the local value), and "same four files" is corrected to six.
• m4 — TOOL_SURFACE.md now discloses the bookkeeping growth (revalidation/admission re-serialize cached schemas against the catalog on each pass).
• m5 — the oversize-rejection reason claims no bound and interpolates no numbers: it now states the schema could not be measured for admission (the arm's only reachable trigger is the serde-failure sentinel). The session-constants import in tool_catalog.rs went away with it.
• NITs — the recency-touch test gains the forkguard_ prefix (with a matching T2 fingerprint needle in the parent), the oversized-fixture comment no longer says the sentinel "has no constructible neighbor", and TOOL_SURFACE.md no longer leaks the usize::MAX / 2 implementation literal.

Not fixed, deliberately

• Commit 1's message saying usize::MAX is immutable history; the falsehood is disclosed in commit 2's body and in this thread.
• revalidate()'s per-entry byte-reject leg remains untested: with the bounds at the sentinel the path is unconstructible (pre-existing gap at base too).
• LRU victim identity (pop_front vs pop_back) stays mutation-invisible — inherent to the disabled posture; the bound reverts themselves are still caught by the rewritten tests.

Companion: parent codewhale-hq#694 re-trued as 5e614d318 — register rows now carry 65 commits above upstream / 50 above r1 / the two-commit batch shape / 172 forkguard names / a head drift measurement, the T2 entry describes the bound-free prose and the growth disclosure, EXPECTED_HEAD→fd14b6a7e / EXPECTED_COMMITS=65, a fourth T2 fingerprint pins the renamed test. fork-guard.sh --fast exit 0.

Validation at fd14b6a7e: cargo fmt --all -- --check clean; cargo clippy -p codewhale-tui --lib --all-features --locked -- -D warnings (CI's allow-set) clean; core::session + core::engine::tool_catalog 23/0; core::engine::tests 404/0 (407 --all-features); full lib suite 12091 passed / 0 failed.