The review is complete and .imd-findings.json holds the result: no critical, high or medium defects, two substantiated low findings, and one coverage note. No source file was changed and the tree is clean.

What I read. All three contracts in full (Rules, Endowments, Zap), the frozen interfaces, the mainnet address library, both docs, and the stand-ins for the desk, vault, pots and token. Every state-changing entry point was walked for access, value flow, reentrancy, rounding, time and external trust. Build and the default plus fork suites pass: 442 tests, 0 failures. The manifest in docs/LAUNCH.md matches the constructors, the brief and the schema. No owner, proxy, initializer, minting, pausing, DELEGATECALL, CALLCODE or SELFDESTRUCT is present, and constructors make no external call.

What I could not reach. The real sources of Questions, WorkOrders and CrowdPots are not in this checkout, so the integration project cannot build here. Conclusions about those three rest on the interface comments, the stand-ins, and the fork tests that call the live contracts. The invariant suites were not re-run in the time budget.

Findings, both reproduced in a scratch Foundry test:

• Low, Endowments line 497. Anyone can deposit 1 wei into sIMD in Endowments' name every block. That holds the vault each block, so every harvest and every IMD withdrawal reverts with the vault's error for as long as the attacker pays gas. Principal is safe via in-kind exit. Documented as accepted in THREATS.md E3, but worth a conscious decision by the panel.
• Low, Endowments line 777. If Questions stops pricing a feed for good, a meter endowment's accrued yield has no exit at all: harvest reverts forever, nothing else can move the shares, and after the last depositor leaves the yield sits locked. A creator-chosen fallback, as pot endowments have, would preserve the design.

Neither carries a proof file, since neither is high severity. The two rules the requester asked to keep, the tip to the first firer and harvest paying a contract target, were checked and read as correct for the stated design.

The work is complete and verified. No source file changed.

Outcome. The project already meets every rule of the contracts-only launch: nonpayable constructors with literal address arguments, no external call or code check at construction, no owner, no token, no proxy, and no forbidden opcode in any runtime. The project's own launch suite proves each of these. Both audit findings reproduce, and neither required a code change.

What I did.

• Added test/endowments/Endowments.audit.t.sol with two tests that follow the auditor's steps exactly. The first shows a stranger holding the vault for five consecutive blocks with one wei each, with harvest and withdrawal reverting on the vault's error and the in-kind exit working throughout. The second shows a meter endowment's yield stuck after Questions stops pricing the feed, surviving the last depositor's exact withdrawal, and leaving only once the feed is priced again.
• Tightened docs/THREATS.md at E3, E5 and E12 to say plainly what the auditor showed was left unsaid: the external hold has no upper bound, and a meter endowment's yield has no exit at all while its feed is not sold.
• Updated the test count in the README and wrote ADAPTATION.md with each change, the reason, and why both findings were kept as they are.

Why no code change. The hold finding states itself that no code change is required, since the hold is the vault's rule. Its optional suggestion would only rename an error path that the docs and existing tests already describe. The stranded-yield finding calls itself a documented trade-off, and its sketched fix would change a public function's signature, the launch runbook that the tests hold against the code, and the design's rule that yield has no address but the one fixed at creation. The requester asked for the code as it is, and the launch asks for the smallest diff.

Verification. The build is clean. The full default suite passes with the verifier's fuzz seed.

Fork suites were not run, since they need a mainnet RPC. Nothing was committed, and no launch.json was written.

The review is complete. The findings file is written, the scratch tests are removed, and the working tree is otherwise untouched.

Outcome. No substantiated money-losing defect in the Math Precision, Boundary or Numerical Gap areas. I recorded one informational note and a full coverage record (all 19 entry points plus two invariants) in .imd-findings.json.

What I checked, with concrete values

• Endowments share math. At the fixture's vault state one IMD-wei is about 125,572 share-wei, so MARGIN (1e12 share-wei) and SEED (1e12 IMD-wei, about 1.26e17 share-wei) are far larger than the rounding they absorb. A batch split costs an endowment under 3 share-wei, a withdrawal at most 1. I verified with scratch tests that a 1-wei deposit round-trips exactly, that 600 tiny exits after a harvest wear at most one share-wei each, and that a harvest drained to exactly MARGIN by a donation leaves the endowment whole after the next stake.
• Rules escrow math. Every fire cost is bounded by CostTooHigh at creation, the uint96 downcast follows a held >= cost check, and uint96 additions revert rather than wrap at 2^96 IMD-wei, which is unreachable. The 32-byte-at-a-time spec filter is carry-free for every allowed byte and walks refused words byte by byte, so its positions match the desk's.
• Zap delta unpacking. The arithmetic shift and int128 truncation reproduce v4's packed-delta signs, ethSpent <= ethIn is enforced, and the price limit is one above the minimum sqrt price.
• Boundary lead closed. createRule does not pre-check orderTtl against the desk, but the desk only requires a future expiry, which the nonzero-TTL check guarantees.

The one note (info). The pot branch of _harvestPlan has no MIN_HARVEST floor on the pot's remaining, unlike the meter branch. With the pot one wei short of full, harvestable returns 1 and harvest succeeds, burning about 124k share-wei and roughly 900k gas to move one wei. No funds are lost, so it is a consistency and keeper-cost observation only.

Not reached. The real CrowdPots and Questions sources are not in this tree, so the 50k gas allowance for remaining and any minimum-chip or minimum-fund rule on the live contracts could only be checked through the project's own integration tests, not independently.

I found one low-severity issue and nothing critical, high or medium. The results are in .imd-findings.json, with a coverage row for each of the 19 entry points. I didn't run any tests: an attempt at forge build was stopped after 500 seconds, so no build finished. The finding therefore has no test file; at low severity it doesn't need one.

The finding: an endowment can pay its yield to Zap, and the next caller of Zap takes it (src/endowments/Endowments.sol:626)

• Cause: Endowments refuses recipients it knows would lose IMD, but it can't refuse Zap because no contract in this launch refers to another. At the end of every buy, chipIn or fundMeter, Zap sends its whole IMD balance to the caller (src/rules/Zap.sol:270-271).
• Reproduction: Alice calls createForRecipient(zap) and deposits. Once yield builds up, Mallory calls Endowments.harvest(id) and then zap.buy{value: 0.001 ether}(0, type(uint256).max) in the same transaction, and receives the whole harvest. createForPot(potId, zap) behaves the same way when the pot takes nothing, and so does a Rules PAY rule that names Zap as its recipient.
• Impact: Depositors' principal is safe; only the yield (or the PAY amount) goes to the wrong party.
• Fix that keeps the design: have Zap return only what the current call produced, rather than its whole balance. Otherwise, warn about Zap in the docs and pages.

What holds:

• Rules: the escrow accounting, the gas floor on condition reads, the exact check of what the hire desk pulls, the job-text character check, and the books built from the desk's own figures in reconcile and recall.
• Endowments: exit and withdraw in both payout paths, the share split when IMD is staked, the margin harvest must leave, the price-drop guard, and the gas floors for paying into crowd pots.
• Zap: the swap callback (signs of the amounts, the ETH it pays never above what was sent, settle and take) and the refunds.

Checked live on mainnet with cast:

• IMD's symbol is "IMD", and sIMD's underlying token is IMD.
• Questions, WorkOrders and CrowdPots all have code, including the functions Zap and Rules call (fundFor, chipInFor, MAX_DELIVERY).
• The ETH/IMD pool that Zap's code names (fee 1%, tick spacing 200, no hook) exists.

Not covered:

• I couldn't get the source of the live WorkOrders and Questions contracts (Sourcify has no match), so the desk's own checks are known only through the repository's stand-in contracts.
• I didn't verify sIMD's code. Endowments' price-drop guard assumes sIMD's price never falls in normal use.

The review is complete and the findings file is written. No source file was changed, and the scratch test was removed.

Outcome. The permission model of Rules, Endowments and Zap holds. I found no permission bypass, no confused deputy, no asymmetry that moves money to the wrong party, and no trust gap between the three contracts and their live siblings. Two minor issues are recorded in .imd-findings.json, one low and one informational.

What I checked, in my area.

• Every state-changing entry point (19 listed, plus Rules.createRule, which the verifier's list omits) was traced for its guard, its state writes and its failure paths. All 22 coverage rows are answered: 20 hold, 2 point to the findings.
• Pashov's Access Control, Trust Gap and Asymmetry guides were applied item by item: inconsistent guards on shared storage, confused deputies through token approvals, paired functions (deposit/exit, stake/settle, create/harvest, fire/cancel/reconcile), branch diffs, and the seams between access, economics and asymmetry.
• Trust roots on mainnet: all six manifest addresses carry code, sIMD's asset is IMD, the desk's constants match the mocks, every selector called on Questions, WorkOrders, CrowdPots, sIMD and the PoolManager is present in the live bytecode, and the fixed v4 pool exists with liquidity.
• The full suite passes on this tree.

417 tests passed, 0 failed (20 suites)

Findings.

1. Low, Endowments.createForPot. A pot endowment can be created for a pot that already needs nothing, since only potId <= potCount is checked. Every harvest then goes to the fallback beneficiary, who is chosen by the creator, while the Created event labels it a pot endowment. This is asymmetric with createForMeter, which refuses a feed that cannot absorb yield. Reproduced against the repository's mock pots. Suggested fix: revert when remaining(potId) is zero at creation.
2. Info, Rules.createRule. Unused condition fields are refused, but unused action fields are accepted and published in RuleCreated, so a HIRE rule's event can name a PAY recipient that the stored rule ignores. No funds are affected. Reproduced with a scratch test.

Not reached. I could not verify, without the earlier launches' sources, whether the real CrowdPots.chipInFor for a pot-completing chip fits the 500,000 gas Endowments allows. If it does not, a harvest that would complete a pot pays the fallback instead. This is a lead for the judge, not a finding. The two documented design choices the author asked to keep, the tip to the first firer and harvests paid to contract targets, were checked and behave as described.

The suite passes in full with the verifier's seed, and the three new files are formatted and lint-clean. No defect was found, so no findings file was written.

What I added (24 tests, all under test/, on top of the 417 already there):

• test/rules/RulesEdges.t.sol covers the 96-bit escrow ceiling: a top-up past it reverts with a checked-arithmetic panic and changes nothing, a deposit exactly at it fires, and a desk return that cannot be booked into a full escrow is freed by cancel. It also pins the escrow-at-cost line as a fuzz, the widest cooldown, order lifetime and feed age a creator can set, two rules sharing one feed each firing once per round, a feed whose rounds go backwards, an answer exactly at its maximum age, unknown ids on every function, and a rule whose condition reads Rules' own books under the transient lock.
• test/rules/ZapDelta.t.sol drives the swap callback with a scripted pool manager that returns any packed 256-bit delta. A 2000-run fuzz over both signed 128-bit halves checks Zap accepts exactly the well-signed results within the ETH sent and pays out what the halves say. The corners of each half are pinned, including the lower half's sign bit not leaking into the ETH side.
• test/endowments/Endowments.edges.t.sol covers the stake interval and pot-id boundaries with exact revert arguments, the views outside their domain, one depositor's withdrawal being paid from another's fresh deposit with the other then backed by shares and still paid to the wei, the creator's seed being non-refundable and harvested to the target, and an endowment everyone has left taking deposits again.

One edge worth knowing, not a defect: a rule whose escrow sits at the uint96 ceiling cannot book a desk return through reconcile until the creator cancels. That needs about 79 billion IMD in one escrow and is recoverable, so I tested it rather than reporting it.

Still owed: the fork runs under the fork profile against live mainnet state, which cannot run here without network.

The review is complete and .imd-findings.json is in place with one info-level entry and a full coverage record.

Outcome. No reproducible loss-of-funds, wrong-party payment, or broken-guarantee defect was found in the economic area. Rules, Endowments and Zap behave as THREATS.md describes on every entry point I traced. The only item recorded is the already-documented liveness grief on Endowments, kept at info severity because the requester has accepted it and principal remains reachable through in-kind exit.

What I checked, by guide.

• Economic Security: tip front-running and keeper churn in Rules (bounded by creator-set tip, cooldown, maxFires, escrow), fallback-beneficiary capture of pot harvests (creator-fixed trust assumption), meter filling around a harvest (only delays yield), stranger-caused sIMD hold (the recorded info item), Zap sandwiching (caller sets minimum and deadline), price-mark griefing (vault rounding makes the price monotone, so no stranger can trigger PriceFell).
• Invariant: Rules balance covers totalEscrowed on every path; Endowments buffer equals pendingTotal and booked shares never exceed sIMD held; each depositor gets exactly its principal; yield only reaches the fixed target. Scratch probes confirmed harvest and withdrawal commute to within 64 share-wei of dust, 50 tiny in-kind exits wear the cushion by 48 share-wei, and a buffered donation followed by harvest and stake leaves depositors whole.
• Flow Gap: desk pull measured exactly in Rules.fire, returns credited only from the desk's books, meter must pull the whole harvest, pot chip read from balance with a fixed gas allowance, Zap delta sign and settle checks, buffer-first withdrawals handing one depositor's IMD to another while shares back the newcomer.

Not reached. The real CrowdPots, Questions and WorkOrders sources are not in this tree, so the seams that depend on them (gas of remaining for a series under 50,000, fundFor existing on the live Questions, series ids counting in potCount) rest on the integration suite's claims rather than my own trace.

Coverage record. All 19 listed entry points have rows: 18 hold, Endowments.harvest points at the info finding, plus four invariant rows. The scratch test directory was removed since nothing in it backs a finding.

The review is complete and .imd-findings.json holds five findings and a 21-row coverage record.

Outcome. No critical, high or medium defect. All five specialist findings reproduce on this tree, and I kept each at the severity its impact supports. Nothing blocks the launch.

What I verified

• The project builds with the pinned settings and all 441 tests pass. Runtime sizes are 13,161 (Endowments), 13,762 (Rules) and 3,834 (Zap) bytes.
• The manifest's argument order matches every constructor. All six mainnet addresses have code, sIMD's asset is IMD and its owner is zero, WorkOrders reports IMD, and the undeclared live functions Zap relies on (fundFor, chipInFor) are present in the deployed bytecode. The v4 pool with Zap's hard-wired key is initialized with liquidity.
• One scratch test file (test/scratch/Specialists.t.sol) reproduces four specialist findings against the real code. The fifth is covered by an existing repository test.

Findings kept, by severity

1. Low. createForPot accepts a pot that already needs nothing, so a "Pot" endowment pays all yield to its creator-chosen fallback while the on-chain record says it funds a pot. Asymmetric with createForMeter's liveness check.
2. Low. Endowments and Rules accept the sibling Zap as a payee, and Zap hands its whole IMD balance to whoever calls it next, so a harvester can collect the yield in the same transaction. Requires the creator to choose Zap. Only yield, never principal.
3. Info. The pot branch of the harvest plan has no MIN_HARVEST floor. A pot one wei short makes a gas-floored harvest move one wei.
4. Info. createRule validates unused condition fields but accepts and publishes unused action fields in the event.
5. Info. The documented every-block sIMD hold grief, recorded as accepted by design.

Coverage. All 19 listed entry points are answered: 16 hold, 3 carry a finding (createForPot, createForRecipient, harvest), plus a row for createRule and one for the manifest and dependency checks. No row is unreached.