The review is complete. The findings file .imd-findings.json is written at the repository root (it is excluded from git by a global ignore rule, as is .imd/), no source or configuration file was changed, and my scratch tests were removed.

Outcome. No critical, high or medium defect in src/CabalGate.sol or the contracts it creates. The gate, as it arrived, works end to end against the live mainnet contracts: I deployed it on a fork from the current source with the manifest's thirteen values, the live hook owner's setGate accepted it and refused a second gate, the real Intake accepted the body and pulled 0.5 IMD, a signed result delivered under the 200,000 gas stipend approved the request, and a 25 IMD buy and a sell settled with the fee burned and hook liquidity added. The live hook and token runtimes are byte-identical to the local build.

Findings written (1 low, 5 info), each with a concrete input or state:

• Low. validForSeconds 900 is compiled into the body and not owner-settable. A result delivered 900 seconds after issue is refused, the Intake does not retry, and the user's 0.5 IMD is spent. Observed live latency is 64 to 85 seconds, so this is a margin, not an observed failure.
• Info, live economics. Against today's seed (zero active liquidity, a single CABAL range starting 59 bps above price) the 300 bps cap admits buys up to about 28 IMD and refuses every sell until price enters that range. Two approved buys ahead of a third leave 479 bps drift and it still executes; three strand it.
• Info. Gate runtime is 23,630 bytes, 946 under the EIP-170 limit. The flat-constructor change touches only init code, but nothing may be added to the runtime. Opcode scan is clean for all four contracts.
• Info. The constructor reads the live hook, Intake and IMD, so the deployment rehearsal needs a fork or etched mocks. All live preconditions were verified: hook initialized, gate unbound, owner is the named EOA, pool key is CABAL/IMD 12500/60, Intake price 0.5 IMD, IMD plain 18-decimal token.
• Info. Signer check is ECDSA only; an ERC-1271 registry as signer would never verify. The live signer is a bare key today.
• Info. Owner powers as trust assumptions: redirect approvals via signer or intake, halt trading via limits, and every reconfigure invalidates pending approvals at users' cost.

Coverage. Read in full: CabalGate, CabalHook, CabalCoin, QuestionBuilder, ImpactEstimator, IIntake, and the five libraries, plus all tests, docs and the pinned skill references. Reached live on Ethereum: the hook, CabalCoin, Intake, IMD, the identity NFT, the PoolManager pool state, and the oracle API record the hash rule was derived from, which confirmed that a request's consumer field is excluded from the signed hash. Not reached: the live Intake's source (behaviour verified by calls only) and the oracle's wording screen, so whether the gate's fixed question passes the ambiguity check without allowAmbiguous remains unverified; the existing suite of 115 tests passes.

Implemented the 13-argument CabalGate constructor and fixed the reproduced oracle-validity issue. Gate runtime remains identical; CabalHook and CabalCoin are unchanged.

forge build passes. All 147 tests pass, including factory deployment and one-time hook binding.

Changes and audit dispositions are in ADAPTATION.md. The old manifest still requires replacement by the separate gate-only manifest step.

Updated only launch.json to deploy CabalGate with the exact 13 arguments, $owner, and notes for the hook owner’s one-time binding.

Validation passed: schema and compiled ABI checks, offline build, all 147 tests, and a second fuzz seed with 1,024 runs.

The findings file is written and validated. Snippets match the tree, all 27 listed entry points have a coverage row, and the scratch test lives in the ignored test/scratch/ directory, so no tracked file changed.

Outcome. The gate's permission model holds across the Access Control, Trust Gap and Asymmetry checklists. I found one low-severity trust gap and one informational configuration gap. No critical or high defects, so no fix-proving test is attached.

Finding 1, low. The gate charges the oracle price and files requests even when the hook has not bound it. The launch deploys only the gate; swap permission is granted later by the hook owner through setGate. In that window, or forever if binding never happens, a user pays 0.5 IMD, the oracle approves, and every execute path reverts inside the hook's beforeSwap. The slot also stays stuck for the five-minute approval window. Reproduced on the real PoolManager and hook with a second, unbound gate. The brief forbids changing the gate, so the remedy is operational: bind immediately after deployment and treat the hook's gate pointer as the go-live condition.

Finding 2, info. The tracked launch.json is still the old token-and-hook manifest. It fails the evm_contracts schema and names contracts this launch must not redeploy. The manifest step is expected to replace it, and the constructor, argument order and the thirteen manifest words all check out against the source and the launch rehearsal test.

What I verified in my area.

• Every state-changing gate function has the right guard: owner, requester, intake-of-version, or PoolManager with a consumed capability.
• The flat constructor matches the brief's order, builds Config with the gate as verifier and bool type 0, and runs the unchanged validation.
• Both getters the hook's setGate needs exist, and the mock-hook and real-hook tests confirm accept-once and refuse-second.
• Paired paths are symmetric: buy and sell, one-arg and two-arg execute, approve and reject branches, deadline and approval expiry boundaries.
• Owner powers (reconfigure, renounce, verifier change) are documented trust assumptions with no unprivileged amplifier.

Not reachable offline. Whether the live hook is currently unbound with a reachable owner, and whether the oracle plane accepts the body's consumer key. Both are recorded as unreached rows. The full suite still passes at 147 tests.

Added constructor, failure-path, oracle-vector, and randomized accounting tests.

• forge build: passed.
• forge test: 157 passed, zero failures or skips.
• Slither completed; 35 alerts reviewed.
• Aderyn unavailable.

Reported a high-severity defect in .imd-findings.json: launch.json still selects CabalHook/CabalCoin deployment instead of only CabalGate.

Production contracts and configuration remain unchanged.

Review complete. The findings file is at .imd-findings.json with one finding and 30 coverage rows, and my scratch tests are removed so the tree is unchanged.

Result for the assigned area (Math Precision, Boundary, Numerical Gap): clean. Every CabalGate entry point holds. What I traced and measured:

• Amount and cast bounds. Amounts are capped at int128.max in configuration, so the uint128 store and the negated swap amount are safe. The manifest values of 1e24 and 1e25 pass, as do 300/500 bps, 30/20 panel and the 1-hour window.
• Fee rounding. The gate's pre-pulled buy fee, the callback's recomputed fee and the hook's finishSwap all compute floor(volume/400)*2 on the same volume, so they always agree. The sell-side subtraction cannot underflow. Fees below 400 wei round to zero, which is dust and clears the hook's state correctly.
• Impact estimator versus v4. The estimator reproduces v4's computeSwapStep: same net-of-fee input, same sqrt-price update, floor rounding that is equal or conservative. The empty-gap case and the tick-bitmap walk match v4's compress and position logic. Under-estimation across range boundaries is caught by the post-swap re-check, which reverts before any state is kept.
• Attestation boundaries. All fifteen field checks were traced. The live vector's one-day validity lands exactly on the gate's MAX_VALIDITY and is accepted. The subtraction is guarded. The widest stored question fits the 200k callback budget per the existing test.
• Service-side limits. The widest possible question measures 1388 scalars and 1668 UTF-16 units, and the body is 3597 bytes, so neither counting convention can breach the 2000-character or 16 KiB caps. Each definitions value is under 512 characters.
• Hook liquidity rounding. I fuzzed the single-sided liquidity formulas 20k runs per side against v4's round-up mint cost. The required amount never exceeded the hook's balance, so the fee leg inside the gate's unlock cannot revert on rounding.

One finding, low, outside my area. The committed launch.json is still the old univ4_hook manifest describing CabalHook, CabalCoin and a pool. It does not validate as an evm_contracts manifest, and consumed as-is it would redeploy the hook and token the brief says not to launch. ADAPTATION.md states the separate manifest step must replace it, so this blocks nothing yet but the tree cannot launch as described until that happens.

Not reported, by the validation gates: the documented single-range estimate can let a request pass at submission and revert at execution, costing the requester the non-refundable 0.5 IMD oracle fee. That is self-harm under stated design and is already covered by the definitions text and a test.

Review complete. The findings are in .imd-findings.json with all 27 entry points covered, one embedded proof, and the tracked tree unchanged.

What I found

1. Medium. The gate charges the oracle price while the hook is not bound to it (src/CabalGate.sol:237). This launch deploys the gate alone and relies on the hook owner's later setGate call. In that window, and forever if the handoff never happens or binds another gate, every submission pulls 0.5 IMD, forwards it to the Intake, and records a request that can never execute because the hook refuses swaps from an unbound sender. Neither the constructor nor _submit reads hook.gate(). I verified the live hook is initialized and unbound right now, and the live Intake quotes 0.5 IMD. The proof test under test/scratch/ fails on this tree and passes with a one-line guard that keeps the runtime under the EIP-170 limit. A second scratch test confirms an approved request on the unbound gate reverts at execution, keeps the user's slot blocked, and refunds nothing.

2. Medium. launch.json is still the old univ4_hook manifest (launch.json:2). As committed it names CabalHook and CabalCoin and has no contracts array, so it either fails the evm_contracts schema or would relaunch the token and hook with no gate. The docs defer this to a later manifest step, but nothing in the tree supersedes the file. The expected thirteen-word CabalGate entry is spelled out in the finding.

What held in my area (execution trace, periphery, first principles)

• The flat constructor builds the same Config the audited gate used, with the gate as verifier and bool type zero, and runs the same validation.
• Submit, callback, execute, clear and slippage flows were traced end to end, including state consumed before external calls, version snapshots, replay consumption, and the unlock capability.
• The live request record fetched from the oracle API shows the exact consumer object shape the gate emits, and the live vector reproduces the question hash with non-ASCII text, closing the periphery leads on body shape and hash rule.
• The live hook bytecode equals the vendored CabalHook runtime except for its two immutables, so setGate, beforeSwap and feeFor behave as the gate assumes.
• Callback gas measured about 78k of the 200k stipend.

Left unverified

• Launch gas: factory deployment of the gate and its two helpers measured about 7.75M gas locally, and the policy ceiling is not available offline.
• Oracle latency for a 30-member panel against the one-hour request timeout is a service property I could not measure.

Review complete. The findings file is at .imd-findings.json in the repository root, with three findings and coverage rows for all 27 listed entry points plus four invariant rows.

What I found

• Low, with proof: the gate charges the oracle price for submissions while the hook is not bound to it. Submission never checks that the hook's gate is this contract, and the hook refuses every swap from an unbound sender, so an approved request reverts at execution and the 0.5 IMD is never refunded. The live hook is unbound today, so this state exists for every launch until the owner's binding call, and permanently if the hook is ever bound elsewhere. The proof under test/scratch/UnboundSubmissionProof.t.sol fails on the current code and passes against a scratch copy of the gate with a one-line check added to the submit path.
• Low: the tree's manifest is still the previous univ4_hook token and hook launch. It fails the evm_contracts schema and describes exactly the redeployment the brief forbids. The brief's thirteen constructor words themselves are correct: they deployed and traded successfully on a mainnet fork.
• Info: deployment measures about 7.8M gas at the factory call with a 37,035-byte init code, because the constructor creates two helper contracts. The pinned policy's gas ceiling is the evidence still needed.

What held up

The buy and sell paths, fee legs, holdings accounting, drift and impact caps, approval window, clearing, and the unlock callback all trace cleanly. The gate retains no tokens after any flow. The existing suite passes with 147 tests. Live chain reads confirm the handoff preconditions: hook initialized, unbound, owned by 0xFc3C..., paired with IMD as currency1, Intake quoting 0.5 IMD, and the live hook bytecode matches the local build byte for byte outside immutables. A fork rehearsal at block 26145662 deployed the gate, bound it, bought 20 IMD with the estimate matching the executed movement exactly, compounded the resulting protocol position, and sold back. The 300 bps cap admits roughly 28 IMD per buy, and sells are refused until price enters the seed range, as the earlier audit recorded. A live oracle request answered an 11-member panel in 85 seconds, so the compiled one-hour deadline has headroom.

Not reached

The policy gas ceiling, the oracle service's acceptance of a 30-member panel and the body's consumer field, and the full semantics of the 45 KB ownable IMD token are outside what I could verify locally.

Review complete. The findings file is written at .imd-findings.json with 2 findings and a 28-row coverage record (all 27 listed entry points plus the manifest).

What I kept

• Medium, merged from three specialists: the gate charges the non-refundable 0.5 IMD oracle price for requests while the live hook's gate() is still zero. Every execute path then reverts inside beforeSwap with Unauthorized, and the user's slot stays blocked until the approval expires. Nothing in the constructor or _submit ever reads hook.gate(). I ran both specialist proofs on this tree and both fail with "next call did not revert as expected". The flow specialist's proof is attached as test/scratch/UnboundGateSubmission.t.sol. Because the brief forbids changing the request flow, I state the fix as a scope decision: a one-line hook.gate() != address(this) check before the price pull, or an operational go-live rule that binds the gate in the same block and refuses submissions until the getter matches.
• Info, trust assumption: the gate owner can point configure() at any Intake, and whatever price that contract quotes is pulled from the submitter without a cap. Reported as a documented owner power with its preconditions, not as a defect.

What I dropped

• The four manifest findings (one per specialist) no longer reproduce. The tree's launch.json is now the gate-only evm_contracts manifest with the thirteen words in the brief's order, $owner in the second slot, and notes under the 4000-character limit.
• The deployment-gas note is not a code defect; the deployer's simulation decides it.

What I verified myself

• forge build and the full suite pass: 157 tests, 0 failures, including the factory rehearsal with a mock hook and the setGate accept-once/refuse-second test the brief asked for.
• The attestation struct, type string, domain and callback selector match the oracle-consumer reference, and the request body's keys are all ones the reference names.
• Hook entry points are the live, unchanged contract. I traced each and marked them holds.

One observation outside the findings: the earlier accepted round changed QuestionBuilder's requested validity from 900 to 3900 seconds to fix an imported audit finding. It is within protocol bounds and the gate runtime is unchanged, so I did not report it.

Fixed the reproduced fee-loss issue: CabalGate now rejects submissions before charging unless the hook is bound to it.

forge build and forge test pass: 153 tests, including the supplied proof.

Updated ADAPTATION.md and recorded all eight finding responses in .imd-responses.json. CabalHook and CabalCoin are unchanged. Nothing was deployed.

The review is complete and the findings file is written. Nothing more is needed.

Outcome: the previous medium finding is fixed, and nothing blocks this launch.

• Unbound-hook fee sink (medium, previous round): fixed. The only production change is one line at src/CabalGate.sol:238, which refuses both submission paths while the hook is not bound to this gate, before any question is built, the Intake is called or IMD is pulled. I copied all three attached proofs into test/scratch and ran them on this tree. All three pass, and the author's new HookBinding tests cover buys and sells in both currency orderings, including a differently bound hook and a refused second binding. Runtime size after the fix is 23,967 bytes, under the EIP-170 limit.
• Uncapped Intake quote (advisory): settled as documented. The author kept the owner power as the brief requires and now states it in ADAPTATION.md and docs/DEPLOYMENT.md. I carried it once more as info so the trust assumption stays on record. It is not a defect.
• Manifest findings from all four specialists: resolved. launch.json is now an evm_contracts manifest with exactly one CabalGate entry whose thirteen words match the brief in order, and it passes the schema's key, pattern and length rules.
• Full suite: 27 suites, 165 tests pass, including the three proofs.

The coverage record answers all 27 entry points. The one open item is operational, not a defect: the economics specialist measured roughly 7.8M gas for the factory call, and the deployer's simulation against the policy ceiling is the check for that.

One environment note: the process memory cap of 1.5 GB kills a single via_ir compile of the whole project. I compiled source first and then each test file on its own, which worked. The verifier may need the same staging.