Slim rain.factory to the interface library (#46) - #47
Conversation
Move the deploy half — concrete CloneFactory, LibCloneFactoryDeploy pins, src/generated snapshots, deploy scripts, and their tests — to the new rain.factory.deploy repo. What remains is the ICloneable* interface surface, which imports nothing, so the deploy-only deps (openzeppelin, rain-extrospection, rain-deploy, rain-sol-codegen), the fs_permissions/rpc/etherscan config, and the manual-sol-artifacts deploy workflow all go too. Stays on autopublish. DO NOT MERGE until rain.factory.deploy has published its first release and the deploy-pin consumers (st0x.deploy) have repointed — else bumping to this version drops the pins consumers still import from here. Co-Authored-By: Claude Opus 4.8 <[email protected]>
|
Warning Review limit reached
Next review available in: 22 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (3)
📒 Files selected for processing (14)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…pr_context fits itself to it (#81) #79 made an over-budget tool result a typed error so the caller could not improvise around it. For `pr_context` that guard never spoke. Its budget was `max_diff_bytes + MCP_MAX_RESULT_BYTES` — up to 332,000 bytes against a harness that stops at ~50,000 — so what reached the model was the HARNESS's replacement, untyped and with `is_error` UNSET, which is precisely the silent degradation #79 existed to remove. Ordering is the mechanism, not a preference: if the harness speaks first, every rule downstream about "a tool error is an instruction, re-call narrower" stops applying at the moment it is needed. THE CEILING, MEASURED. Not derived by halving a refused payload — that is how 32,000 was set, and how this gap survived #79. Probed against Claude Code 2.1.220 by calling `pr_context` through the real harness at increasing `max_diff_bytes` and reading the `tool_result` the model actually received. There are TWO independent gates and BOTH arrive with `is_error` unset: - a BYTE gate -> `<persisted-output> Output too large (NN KB)` plus a 2 KB preview. Delivered at 50,011 bytes, replaced at 50,176. NOT governed by `MAX_MCP_OUTPUT_TOKENS` (forcing it to 200,000 still replaced a 50,486-byte result). This one is the more dangerous: the preview it substitutes looks like the head of a real answer. - a TOKEN gate -> `Error: result (N characters ...) exceeds maximum allowed tokens`, governed by that variable (forcing it to 100 replaced a 4.5 KB result). This is the gate the live traces hit, at 63,742 and 56,789 chars. Isolating the token gate at `MAX_MCP_OUTPUT_TOKENS=10000` puts its boundary between 27,152 and 30,163 bytes, so this JSON measures 2.7-3.0 chars/token; nothing on the box sets the variable and 56,789 chars tripped it live, which puts the default near 19-21k tokens. Both gates land around 50 kB here. THE FIX. - `MCP_MAX_RESULT_BYTES` is 36,000, ~28% under both gates. The margin is not timidity: the token gate scales with CONTENT, and a diff of generated hex — which this org has in every `src/generated/*.pointers.sol` — tokenises far worse than the prose-and-code JSON the gate was measured on. At 36,000 even a payload at 1.5 chars/token stays inside a 19k-token cap. - ONE budget for every tool. `pr_context`'s special case is gone, and `max_diff_bytes` can no longer be raised past the budget, so no argument buys a call more room than any other call gets. - That is also what makes NARROWING CONVERGE. While the budget scaled with `max_diff_bytes` and the diff was truncated to `max_diff_bytes`, lowering the argument lowered allowance and payload equally — "re-call NARROWER" was a loop with no exit. Against a fixed allowance a smaller argument is a strictly smaller result, pinned by a monotonicity test. - `pr_context` does not wait to be refused: `fit_pr_context` shrinks the diff until the document lands under the budget. It terminates — each round removes at least the overflow from the cap, and one raw byte of diff is at least one byte of document, so it overshoots rather than undershoots. The document reports `diffBytes`, the new `diffIncluded`, and `diffTruncated`, so the gap between what exists and what was handed over is visible rather than inferred. The one case no argument can fix — metadata alone over the budget — is a typed error that says exactly that. The budget/ceiling relationship is a COMPILE-TIME assertion beside the constants, so raising the budget past the measured gate fails the build rather than quietly reinstating the defect. Four of the ten mutations for this change are killed that way; the rest by named tests. Verified live, same PR (rainlanguage/rain.factory#47), same harness: BEFORE (main @7df5496), default argument: received: HARNESS byte-gate (untyped) is_error=None chars=2248 AFTER, default argument: received: DELIVERED in full is_error=None chars=36631 AFTER, max_diff_bytes=300000: received: OUR typed refusal is_error=True chars=46 "max_diff_bytes must be an integer in 1..=36000" ...and the model then re-called within range and got the full result. No part of the existing #81 work is weakened: the pull-ref checkout, the binary postcondition, the sweep changes and the prompt rules are untouched.
|
🤖 ai:vetter |
2 participants
The library half of the deploy/library split (#46). Practise run for the pattern before st0x.deploy.
What moves out
The deploy half is now in the new rain.factory.deploy repo (created, builds clean, 15/15 offline tests): concrete
CloneFactory,LibCloneFactoryDeploypins,src/generated/<tag>/snapshots,Deploy.sol+BuildPointers.sol, and all their tests.What remains here
The
ICloneable*interface surface — the abstract API consumers import. It imports nothing, so this PR also drops the now-unused deploy-only deps (@openzeppelin-contracts,rain-extrospection,rain-deploy,rain-sol-codegen), thefs_permissions/rpc_endpoints/etherscanconfig, and themanual-sol-artifactsdeploy workflow.rain.factorystays onrainix-autopublish— it's now a pure library repo, exactly one side of the split.Verified:
forge buildclean on the interfaces-only tree; rainixpre-commitclean.Merging republishes
rain-factory(0.1.6) as interfaces-only. Consumers that import the deploy pins (LibCloneFactoryDeploy.CLONE_FACTORY_DEPLOYED_CODEHASH) —S01-Issuer/st0x.deployat least — must first repoint torain-factory-deploy. So this merges only after:rainix-tag-release) lands + the Ankr fork-RPC key is restored (rain.factory.deploy's verify gate).rain.factory.deploycuts its first release (sol-v0.1.x), publishing the deploy pins.rain-factory-deploy.Interface-only consumers are unaffected throughout — that's why the library keeps the name. Sequencing tracked in #46.