Review complete. Findings are in .imd-findings.json (7 findings, one with a proof). No tracked file was changed; the only writes are the findings file and the scratch proof, both git-ignored.

What was read. Every source file in src/ (CabalGate, CabalHook, CabalCoin, QuestionBuilder, ImpactEstimator, HookFlags, the five libraries, IIntake), the full test suite, launch.json, ADAPTATION.md, docs, and the pinned skills and protected floor test. The suite builds and all 162 tests pass. I also read the live mainnet hook and Intake over a public RPC: gate is unset, the owner is 0xFc3C…1774, the pool key and PoolManager match the brief, the price is 0.5 IMD, and the live hook runtime is byte-for-byte the repo's CabalHook apart from immutables. Nothing was unreachable.

Findings, most severe first.

• High, src/CabalGate.sol:142. The constructor calls the hook (initialized, poolManager, cabal, poolKey, imd) and requires code at intake and IMD. In the launch floor's empty EVM the first call reverts and the probe reports "application constructor failed", which is why launch 990 parked. The proof in test/scratch/Proof_ConstructorNeedsChainState.t.sol deploys the gate with the brief's 19 manifest words and no code at any dependency address. It fails today for that reason and passes once the constructor makes no external calls or code checks.
• Medium, launch.json:6. The committed manifest still lists the 13 old words and its notes describe the hook-reading constructor. Against the 19-parameter constructor the words decode short, and left as is it reproduces the parked outcome.
• Low, src/CabalGate.sol:222. The owner can configure quorum 1 or panelSize up to 1000. The oracle only accepts 2 to 300, so every request under such a config pays 0.5 IMD and is never answered.
• Low, test/GateLaunch.t.sol:71. The launch rehearsal etches mock code at the hook, Intake and IMD addresses, and one test asserts deployment must fail without that code. The suite therefore never ran in the state the launch checks use, and none of the brief's required tests exist yet.
• Info. Runtime is 23,967 bytes, 609 under EIP-170, before the adapter adds the submission-time pool-key check. The tickSpacing word must be declared unsigned since the launch ABI forbids signed integers. The live hook's one-time setGate only compares hook() and cabal(), so a gate built from a wrong key word would be bound irreversibly; the hook owner should compare the key hash before binding.

Trust assumptions, not defects. The owner can swap the Intake, signer and verifier, and a user pays whatever the configured Intake quotes. Signatures are ECDSA-only, so an ERC-1271 registry signer would never verify. Refused or undecided oracle requests are never refunded. All three are already recorded in ADAPTATION.md.

The runtime paths of the gate (request, callback, execution, settlement, fee accounting, replay protection) held up against the checklist. I found no loss-of-funds or accounting defect there.

The review is complete. The findings file is valid JSON, the scratch directory is removed, and the working tree is otherwise untouched.

Outcome: no substantiated defects in the Economic Security, Invariant or Flow Gap areas. The file .imd-findings.json holds an empty findings list and 33 coverage rows: one for each of the 28 listed entry points, plus five invariants I checked.

What I verified

• Value conservation. The gate ends every transaction with zero token balances and zero allowances. Buys pull input plus fee, send input to the pool and fee to the hook. Sells pull CABAL, take the fee from the IMD output, and forward the rest. The oracle price is pulled and forwarded exactly, with a balance delta check that rejects fee-on-transfer or pretend-success tokens.
• Fee economics. The gate's fee base matches the hook's (input for buys, IMD output for sells), so the return-value equality cannot fail on a full fill. Burn and protocol-owned liquidity legs are equal. Trades under 400 wei pay zero fee, but each request costs 0.5 IMD, so there is no profitable amplification.
• Price protection. Only the gate can swap, so third parties cannot move the price. Liquidity changes and other approved trades can only make an execution revert, never worsen a fill past the requester's minimum. The impact and drift caps are re-measured at execution.
• Oracle flow. Attestations are consumed once, bound to the stored question and window, signed for this gate's domain, and accepted only from the snapshot intake before the deadline. A "no" answer is stored, not reverted.
• Request state machine. The active-request lock, clear paths, config-version invalidation and approval expiry are consistent across all writers.
• Launch. The constructor makes no external calls, the nineteen manifest words match the live hook values in declaration order, and the empty-EVM rehearsal passes.

Probes I ran. All 166 existing tests pass. Scratch tests confirmed repeated sells crossing the hook's own liquidity settle cleanly in both token orderings, a one-wei approved sell reverts with PartialFill (self-harm only), and a dust buy pays no fee.

Not reached. No mainnet fork was available, so the live hook's actual pool key, IMD address and unbound gate state remain as the brief reports them. The hook owner should still compare the hook's reported pool key hash with the manifest words before the one-time binding, as the deployment notes already instruct.

The review is complete. The findings file is written and validated, the scratch test is removed, and no tracked file was changed.

Outcome. The control flow for the gate-only launch holds. I traced the constructor, both submission paths, the oracle callback, clearing, execution and the unlock callback against the Execution Trace, Periphery and First Principles guides, and found no loss-of-funds or permanent-breakage defect reachable from the manifest's values. The full suite passes on this tree, including the three invariant campaigns at full size.

Findings written to .imd-findings.json:

• Low, constructor fee word unbounded. The constructor bounds tickSpacing but accepts any fee, including values above the v4 maximum. A gate built with such a word passes the empty-EVM launch checks, the live hook's one-time setGate binds it anyway (it compares only hook() and cabal()), and the gate then refuses every submission forever while the correct gate can never be bound. Reproduced with a scratch test on the current tree. The manifest value 12500 is correct, so this is a deploy-time backstop, not a live defect. Suggested fix: revert when fee exceeds the v4 maximum, or pin fee and tickSpacing to the live pool's values.
• Info, scope deviation. The brief says limits stay exactly as audited, but the panel and quorum bounds were tightened to the oracle's 2 to 300 range and the old mainnetConfig view was removed to recover bytes. Both are documented in ADAPTATION.md and are improvements. Recorded so the requester accepts the deviation explicitly.

Coverage. All 28 listed entry points have rows, plus rows for the constructor and four invariants I checked: no payment before the hook reports this gate and key, the request body stays inside the oracle's input limits (definition values measured at 140 to 403 characters against a 512 cap), the launch size bounds (runtime 133 bytes under EIP-170), and the passing test suite. The only rows marked finding are the constructor and CabalHook.setGate, both pointing at the fee-word backstop.

Not reached. I did not re-derive the oracle's canonical question hash or the live signature vector beyond confirming the existing live-vector tests pass, since the brief declares the oracle struct, type string and domain unchanged from the prior audit.

The findings file exists, parses, and is excluded by the harness's own exclude list, as expected. Everything is verified, so the work is complete.

Outcome

forge build and forge test pass: 179 tests across 29 suites, 0 failed, 0 skipped. The 166 existing tests were left untouched. I added one new test file and a README entry.

The brief's required tests already existed in test/GateLaunch.t.sol (empty-EVM deployment, mock hook, request only after binding, refusals on wrong key/cabal/imd/gate, one-time setGate). So the new work is adversarial coverage beyond them, in test/GateLiveHook.t.sol:

• Real hook code at the live address. The live address 0xf41b…a0c0 carries exactly CabalHook's three permission bits, so the real CabalHook runtime is placed there in the test EVM and the launch-953 beforeInitialize call is replayed from the PoolManager's address. This pins the real setGate checks and the real five-word poolKey() encoding that the gate hashes, which the mock only models. Nothing is deployed to any chain.
• Real binding paths. Non-owner refused, codeless and getter-less candidates refused, swapped-role gate refused, deployed gate accepted once with the GateBound event, second gate and rebinding refused.
• Full request flow on the live addresses. Buy and sell refused before binding without touching the intake, then accepted, followed by an approval, a rejection, replay of a consumed attestation against the same and a different request, and a clear.
• Failure paths. Hook with no code, poolKey() reverting, same key in a different ABI encoding, chain id 4663, and owner reconfiguration onto the wrong IMD or an invalid drift bound. Each refusal is checked to cost the user nothing.
• Fuzzing. 512 runs each over every pool-key field and over the CABAL, IMD and gate reads: acceptance only on exact equality, refusal otherwise, and recovery once the reads match again.
• Inert gate in the empty EVM. Submissions and reconfiguration revert while two-step ownership still works.

No defect found in the gate. One informational note went to .imd-findings.json: the launch deployment costs about 7.95 million gas because the constructor creates two helper contracts, and the brief does not state the deployment service's gas ceiling. That is for the manifest and deployment steps to confirm, not something a test can decide.

Two of my first drafts failed for harness reasons, not contract reasons: expectRevert latched onto a preceding external call, and clearMockedCalls also dropped the PoolManager mocks. Both are fixed in the committed file.

The review is complete and .imd-findings.json is written with 2 findings and 29 coverage rows covering all 28 listed entry points plus two invariants. No source files were changed. The only files I created are the findings file and two investigation tests under the gitignored test/scratch/.

Outcome. The gate's permission model holds. Every state-changing entry point has the guard its effect needs, both Config writers reach the same validation except for one field, and the launch handoff works against the live chain.

What I verified beyond reading the code

• The full suite passes. 166 tests, 0 failures.
• Live mainnet state at block 26152283 matches the brief's words. The hook's owner is 0xFc3C…1774, its gate is unset, it is initialized, and its CABAL, IMD and pool key equal the manifest values. The Intake quotes 0.5 IMD. Every dependency address has code.
• The live hook's runtime bytecode is byte-identical to the compiled src/CabalHook.sol apart from the two immutables, so the test mocks model the real setGate.
• On a mainnet fork, the gate deployed from the 19 words, the real hook accepted it via setGate from its owner, and a 10 IMD buy went through the real Intake. Exactly 0.5 IMD left the user, the allowance returned to zero, and a second request was refused as active.
• Sells currently estimate 10000 bps on the live pool because it is one-sided with no liquidity below the current tick. Buys above roughly 40 IMD exceed the 300 bps cap. This is chain state and launch design, not a gate defect, and the owner can retune the limits.

Findings

1. Low. configure accepts any boolAnswerType, while the constructor hard-wires zero and the body and canonical hash always say bool. A single mistaken owner call makes every later request pay 0.5 IMD and never be answerable. Reproduced in a scratch test. Suggested fix is one extra clause in the shared validation.
2. Info. Submission pays whatever the configured Intake quotes with no cap. The live Intake's price is controlled by a third party distinct from both the gate and hook owners. This is already documented in the deployment notes, so it is recorded as the trust assumption with the exact actor and amounts.

Not covered. No findings carry a proof file, since neither is critical or high. I did not simulate the oracle writer's callback against the real Intake. The existing live-vector test pins that format.

The review is complete. The findings file is written and validated, and no repository files were changed (scratch tests live only under the ignored test/scratch/ directory).

Outcome

Two defects, both in the price-impact estimator, both reproduced with Foundry tests:

• Medium, src/ImpactEstimator.sol:52. The estimate applies the single-range formula to the liquidity active at the current price as if that range were unbounded in the swap direction. When the price sits at the lower edge of a CABAL-only seed (the state a token-only launch starts in, with CABAL as currency0 as on mainnet), a sell of 100 CABAL is estimated at 1 bps, accepted, charged the oracle price, and approved. Execution then reverts with PartialFill because the v4 swap leaves the range at its first step and finds no liquidity below. The same happens after a first 100 IMD buy for a 1000 CABAL sell estimated at 2 bps. Users lose the non-refundable oracle price and the panel approves on a wrong impact figure. The attached self-contained proof test fails on the current code with PartialFill and passes once the estimator refuses a trade whose path exits the active range into empty liquidity.
• Low, src/ImpactEstimator.sol:36. The mirror case. While no other liquidity is active at the current tick, a permissionless 1-wei full-range position makes the estimate return 10000 for every amount, so every buy and sell submission reverts with LimitExceeded. Without the dust the gap branch would have followed the swap into the protocol position and returned about 115 bps.

What held

I traced the remaining arithmetic against the Math Precision, Boundary and Numerical Gap checklists and found it sound: the symmetric movement formula and its one-bps round-up, the fee legs and their zero-fee path, the exact match between the gate's fee and the hook's fee base, the holdings and cost-basis reductions, the uint128 and int24 narrowing casts, the tick-bitmap walk for negative ticks, the attestation time-window boundaries, the question-length bound, and the spot-price chained divisions (relative error below 1e-20). Coverage rows answer all 28 listed entry points plus six invariant rows.

Not reached

The estimate-at-exact-cap versus execution rounding check could not be exercised in the fixture because the configured buy cap keeps the estimate at 20 bps. Slither and Mythril were not run; the static-analysis leads about division-before-multiplication and strict equalities were checked by hand and are not defects.

The work is complete and verified. Nothing more is needed from the tree.

Outcome. The CabalGate constructor now takes the 15 flat words the operator asked for, in the order hook, poolManager, cabal, initialOwner, intake, imd, signer, action, maxBuyAmount, maxSellAmount, maxImpactBps, maxDriftBps, panelSize, quorum, windowHours. The compiled ABI confirms 15 nonpayable static inputs. The build and the full test suite pass with the project's own configuration.

What changed in the contract (src/CabalGate.sol):

• The pool fee and tick spacing are now the constants POOL_FEE (12500) and POOL_TICK_SPACING (60), matching the only pool CabalHook accepts.
• The constructor sorts cabal and imd by address into currency0 and currency1 and builds the PoolKey from them with hooks set to the hook.
• Validation that needed the removed words is gone. The constructor now rejects a zero hook, pool manager, cabal or imd, and cabal equal to imd. The numeric limits are unchanged.
• The constructor still makes no external calls and no code-length checks. The request path is byte-for-byte as accepted: chain id 1, the poolKey hash, hook.gate, hook.cabal and hook.imd, all before any payment.

Tests updated to the 15 words in test/GateLaunch.t.sol, test/GateFactoryEdges.t.sol and test/CabalFixture.sol, including the empty-EVM deployment with no code at the hook, intake, IMD or pool manager. One new test deploys a gate for a CABAL whose address sorts above IMD and shows the derived key matches the hook's, a request passes once bound, and a hook reporting the unsorted order is refused. The fixture's two token orderings already run the real hook and PoolManager through both sort directions.

Documentation in ADAPTATION.md, README.md, docs/DEPLOYMENT.md and the test READMEs now describes the fifteen-word constructor and the manifest's sixteen-argument limit. No launch.json or blocked file exists in the tree.

One note for the reviewer. The operator's instruction describes the request path as checking hook.initialized and poolManager. The accepted code never read those two in the submission path, and I did not add reads there, since the instruction also says to keep the rest exactly as accepted and the runtime has only 54 bytes of headroom. ADAPTATION.md explains why those facts are implied by the existing hook.gate and poolKey checks.

forge build passes, and forge test now passes all 179 tests in 28 suites, with none failing or skipped. Before my change one test failed. I also found a high-severity mismatch with the brief that tests can't resolve, so I've reported it in .imd-findings.json instead.

The failing test (fixed). In test/GateLiveHook.t.sol (around line 106), test_realHookRefusesGateBuiltWithSwappedTokenRoles was still using a byte offset from an older 19-argument layout. It meant to overwrite the imd argument but hit maxSellAmount instead, so the gate never deployed. I corrected the offset; that one line is the only change to a delivered file.

The reported defect: the brief's deploy arguments don't fit the contract. The brief lists 19 constructor arguments, starting hook, poolManager, cabal, currency0, currency1, fee, tickSpacing, initialOwner…. src/CabalGate.sol takes only 15:

• Fee and tick spacing are fixed inside the contract at 12500 and 60.
• currency0 and currency1 are worked out by sorting CABAL and IMD.

ADAPTATION.md says an operator ordered this because a launch can take at most 16 constructor arguments. That instruction isn't in this task's brief, so I can't confirm it.

Deploying with the brief's 19 values fails the same way the launch checks would ("application constructor failed"). Everything shifts by four positions: the owner becomes the CABAL token and the Intake address lands in maxBuyAmount, which is too big for its type. The proof is a test that deploys with the brief's 19 values and fails on the current code; its source is in the finding.

Decision for you: either the launch uses the 15 values recorded in docs/DEPLOYMENT.md, or the constructor goes back to the 19 arguments the brief specifies. The existing tests follow the 15-argument version.

Coverage of the brief's test list (already in the tree from earlier rounds):

• Empty-EVM deploy: GateEmptyEvmLaunchTest deploys the gate with no code at the hook, pool manager, Intake, IMD or CABAL addresses, as the launch checks do.
• Requests and setGate: using a mock hook and the real hook code placed at the live address, requests are refused until the gate is bound and succeed after. They are also refused without payment when the reported pool key, CABAL or IMD is wrong, or the gate is unset or another one. setGate accepts this gate once and refuses a second.
• Invariants: random-sequence invariant tests cover what the gate holds and the request lifecycle.

Review complete. No tracked file was changed. The findings file is at .imd-findings.json with two findings and a coverage row for all 28 listed entry points plus four invariants.

Outcome

• Medium: constructor argument count does not match the brief. The compiled constructor takes fifteen words. The brief's manifest constructorArgs lists nineteen (it still carries currency0, currency1, fee and tickSpacing). Deploying the creation code with those nineteen words reverts with "application constructor failed", so a manifest transcribed from the brief parks the launch exactly as launch 990 did. I reproduced it in a scratch test that deploys with both lists. ADAPTATION.md and docs/DEPLOYMENT.md attribute the fifteen-word list to an operator instruction, but nothing in the tree reconciles that with the brief, and no launch.json exists yet. Either the manifest must use the fifteen documented words or the constructor must match the brief. The runtime is 54 bytes under the EIP-170 limit, so restoring four parameters is not free.
• Info: drift-cap griefing, costed. Two attacker addresses executing approved buys of up to 300 bps each push a victim's submission price past the 500 bps drift cap, stranding that approval until it expires and costing the victim another oracle fee. The attacker pays two oracle fees, 1.75% in fees on roughly 5% of price movement, and needs panel approval. The existing Trading test already exercises this and accepts it. No code change recommended.

Area coverage (Economic Security, Invariant, Flow Gap). I traced the full request lifecycle and found it sound: hook identity checks run before any payment, the oracle price is pulled and forwarded exactly with allowance reset, each attestation is consumed once, buy and sell fees match the hook's finishSwap computation, the trade's own impact and the drift since submission are both re-measured on live pool state, the gate holds no tokens or allowances after any transaction, and activeRequest is set exactly when a request is Pending or Approved. Config versioning invalidates stale approvals without refunding oracle fees, which is documented. All 167 existing tests pass under Foundry 1.8.3 and solc 0.8.26. The live hook was traced only as the gate's counterparty since it is out of scope for change.

Not reached. Live mainnet pool state (liquidity depth, current tick) was not inspected, so the submission-time impact estimate against the real pool is unverified. No fork or static analysis beyond the supplied tool output was run.

Review complete. The tree is clean apart from .imd-findings.json, which holds two findings and a 31-row coverage record. No source files were changed, and the scratch tests were removed.

Outcome

The gate's control flow holds. The constructor makes no external calls and deploys through the floor's probe in an empty EVM, the submission path checks the hook's key, gate, CABAL and IMD before any payment, and the oracle struct, type string and domain reproduce the live vectors. Build and all 167 existing tests pass with this toolchain. Runtime is 24,522 bytes, 54 under the EIP-170 cap. Deployment through the probe costs about 7.96M gas, which the policy's gas ceiling must cover. The callback uses 78k gas with the longest question.

Findings

• Medium, constructor arity versus the brief. The brief specifies nineteen constructor words and a nineteen-entry manifest list. The compiled constructor takes fifteen. A scratch test deploying the brief's nineteen words through the floor's factory reverts with "application constructor failed", the launch 990 symptom. The tree attributes the reduction to an operator instruction about a sixteen-word manifest limit that nothing available to me verifies. The manifest step must follow the compiled ABI and the table in docs/DEPLOYMENT.md, not the brief's list, and the two sources need reconciling.
• Low, a wrong IMD word bricks the live hook's binding. A gate built with any imd word other than the hook's derives a key the hook never bound. The live hook's setGate accepts it anyway, the binding is permanent, every submission then reverts, the owner cannot repair it, and the correct gate can never be bound. Verified against the real hook and PoolManager. The only guard is the off-chain procedure in docs/DEPLOYMENT.md. A key getter on the gate would let the hook owner compare on-chain first, at the cost of trimming bytes elsewhere.

Coverage

All 28 listed entry points have rows. Every CabalGate and CabalCoin entry point holds. CabalHook rows hold as live, unchanged code, except setGate, which carries finding 2. Three invariant rows record the empty-EVM deployment, the size and gas measurements, and the oracle format check. No area was left unreached. Slither and aderyn leads on reentrancy, strict equality and unused returns were traced and none produced a reachable defect.

The review is complete. The findings file holds four findings and a full coverage record, and the working tree is otherwise untouched (the findings file is gitignored, so git status is clean).

What I audited. The Math Precision, Boundary and Numerical Gap guides against the gate's arithmetic: PriceMath.movement, the impact estimator and its tick-bitmap walk, the spot and average price formulas, fee and holding accounting, every downcast, every time-window comparison in the oracle callback, the question length bound, the callback's gas against the 200k stipend, and the constructor's numeric validation against the live manifest words. Every one of the 28 listed entry points has a coverage row, plus four invariant rows. None is unreached.

Findings, by severity.

• Low. Impact estimate under-reports across a liquidity step. The estimator prices the swap against only the liquidity active at the current price. With a deep one-spacing range beside the shallow seed, a 640,000 IMD buy estimates 114 bps, under the 300 bps cap, so the submitter pays the oracle, the panel approves a question stating 114 bps, and execution then reverts because the real movement is 632 bps. The approval is unusable and the oracle price is lost. The live hook's own 600-tick protocol-liquidity bands create this stepped profile naturally, and anyone can add such a range. A control run on a single range gives estimate 568 bps equal to the actual 568 bps, so the formula itself is right. The author documents the limitation, which is why this is low rather than medium.
• Info. Dust requests. A 1 wei buy passes the amount and impact checks, pays the oracle price, and can never execute because the swap produces zero output.
• Info. Hook fee rounds down. Volumes under 400 wei pay no fee and each trade under-collects by up to 2 wei. The gate mirrors the formula exactly, so nothing desynchronises, and the hook is live and out of scope.
• Info. Constructor arity. The brief lists nineteen constructor words but the delivered constructor takes fifteen, by operator instruction recorded in the adaptation notes. I verified that appending the nineteen brief values to the creation code fails deployment. The manifest step must use the fifteen-word order in docs/DEPLOYMENT.md.

What held. Callback gas measured at 78,063 against the 200,000 stipend with the longest possible question. The time-window checks short-circuit before any subtraction can underflow. All narrowing casts are bounded by the int128 amount cap. The tick-bitmap walk matches Uniswap v4 semantics for negative ticks and crossing direction. The full existing suite of 161 unit tests passes.

Not reached. Nothing in my area. I did not run the invariant campaigns or any fork, and the oracle service's own character counting for the 2,000-character question limit cannot be verified from this tree.

The review is complete and .imd-findings.json holds the result. No repository file was changed; only the findings file and a scratch test under test/scratch/ were written.

Outcome. The gate's permission model holds up under the Access Control, Trust Gap and Asymmetry checks. I found one substantiated defect, which is a mismatch between the brief and the tree rather than a bug in the request flow, plus three documented trust assumptions recorded as info.

Finding 1, medium, with proof. The brief fixes a 19-word constructor and a 19-entry manifest, but the constructor in src/CabalGate.sol:139 takes 15 words in a different order. ADAPTATION.md attributes the cut to an operator instruction about a 16-word manifest limit that appears in no pinned input. I encoded the brief's exact 19 constructorArgs behind the current creation code and deployed through a copy of the protected floor's factory. It reverts with "application constructor failed", the same failure class that parked launch 990. The scratch test fails on this tree and passes once the constructor matches the brief. Either the constructor is restored to 19 words or the manifest step must use the 15-word order from docs/DEPLOYMENT.md, and that decision has to be made before the manifest is written.

Info findings, all documented in the tree.

• The live hook's setGate checks only hook() and cabal(). A gate built with a wrong imd word binds successfully and then refuses every submission forever, leaving the pool unswappable. The hook is out of scope, so this is a handoff risk.
• Owner reconfiguration strands every in-flight request. The requester's paid oracle fee is lost and the approval cannot execute.
• The gate owner can replace intake, signer and verifier, which lets the owner bypass the panel for their own trades and lets an owner-chosen Intake quote any price to submitters.

Coverage. All 29 rows answered: 25 holds, 4 finding, 0 unreached. I traced every CabalGate entry point for caller, guard, state writes and failure paths, plus the hook's setGate, swap callbacks and finishSwap. The full project suite passes with 167 tests.

Not covered. No fork or live-chain read, so the manifest values were taken from the brief as given. Runtime is 54 bytes under the EIP-170 limit, which the fix for finding 1 would have to respect.

The review is complete. The findings are in .imd-findings.json at the repository root, no source file was changed, and the scratch tests were removed.

Outcome. No critical, high or medium defect survived reproduction. The gate deploys in an empty EVM with the manifest's words, the whole suite passes, and the oracle wiring matches the live service.

Findings kept, after merging and recalibration:

1. Low, constructor ABI. Five specialists reported the same root cause: the brief fixes 19 constructor words and the code takes 15. Both specialist proofs fail as claimed when the brief's 19 words are encoded. It is low rather than medium because the tree now carries a launch.json in the 15-word ABI order, and that manifest deploys through a copy of the protected probe. The requester must still settle which document is right, since the sixteen-word operator rule is in no pinned input.
2. Low, impact estimate. The single-range estimator under-reports a trade that crosses a liquidity step. Reproduced on the fixture: estimate 114 bps, real movement 632 bps, so the request is paid for and approved, then execution reverts on the cap.
3. Low, wrong IMD word. A gate built with a wrong imd word passes the live hook's setGate and can never submit, and the binding is permanent. Reproduced against the real hook. The manifest's imd word is correct, so the risk is procedural.
4. Info, four items. A dust buy that is paid for and never executable, the owner's documented powers including the unconstrained boolAnswerType, the drift-cap stranding trade-off, and the live hook's fee rounding.

Coverage. All 28 entry points have a row, plus three invariant rows for the empty-EVM constructor, the oracle format against the live vector, and the manifest schema. One item could not be verified offline and is noted in the coverage row: the shape of the body's consumer key, which rests on the tree's own live-evidence documentation.

No proofs are attached because nothing reached high severity. Any fix to findings 2 or 3 that touches the gate must fit in its 54 bytes of remaining EIP-170 headroom.