Taylor, the review is done and the findings file is written. Nothing else is pending.

Outcome: no critical, high or medium defect in the registry as it arrived. One low finding and one scope note are in .imd-findings.json. No repository file was changed. Only the scratch test supporting the low finding sits under test/scratch.

What I read: all three contracts in src, the oracle library, the Intake mock, the fork test, launch.json, the panel rules and history sections 17 to 22. The live Intake v2, IntakeDelivery and IdentityMD's Sepolia test IMD have no source in the tree, so I checked them only through on-chain behavior.

What I verified live:

• The 164 offline tests pass, and all 8 fork tests pass against public Sepolia and mainnet RPCs. The live Stacker is this build byte for byte.
• Run 2's registry accepted a real signed answer at block 11,896,180 with panel 15, quorum 11, agreed 12 and chain 1, so the WrongPanel and chain checks match what the oracle signs.
• All 8 rules fit under 512 bytes. Longest is feeGuard at 472. Both questions stay under 2,000 at maximum input.
• The runtime is 22,294 bytes with no DELEGATECALL, CALLCODE or SELFDESTRUCT. Mainnet IMD has no pause or blocklist selector, so a bond recipient cannot be wedged.
• Sepolia's block gas limit is 200M, so the 35.2M deploy estimate fits.

The low finding: applications post no bond, so a griefer can hold a project's single ask slot by refiling a doomed application after each rejection, for 0.5 IMD per panel round. The owner's applyListing reverts with AskOpen each time. Nothing is lost or mis-listed. Adding an application bond changes the agreed economics, so I flagged it as an owner decision rather than a required fix.

Leads rejected: the un-pinned compat challenge cannot be redirected by a front-run handoff, because the handoff sets the pin first and the challenge reverts before paying. Replay, reentrancy, double bond payment, handoff during an open question and the expire race all hit a guard.

Untested edges worth knowing: the ERC-1271 fallback in signature verification is never reached with the EOA signer, and no test deploys through the protected factory probe with the real manifest bytes.

Everything is green. The deliverable is complete.

Outcome. The registry ships as it arrived: no change to src/, launch.json, or the build configuration, and nothing added under .github. Build is clean. The offline suite passes with an empty environment, and the 8 fork tests pass against live Sepolia and mainnet through public nodes.

Check	Result
Offline tests (delivered tree)	170 pass, 8 fork tests skipped
Fork tests with RPC URLs set	8 pass (Sepolia block 11,897,092)
Registry runtime	22,294 bytes, no forbidden opcodes

Audit finding 4bc1aedb (low, slot griefing). It reproduces exactly as described: three refused applications cost the griefer 1.5 test IMD and block the project's own application each round. I kept the contract unchanged, since the brief fixes the source and the audit itself says an application bond is an owner economics decision. The cost and the one-day bound are now pinned by five tests in test/RegistryApplicationSlot.t.sol and stated in the design doc's known limits. The info finding needed no change.

Files changed

• ADAPTATION.md (new): every rule checked, the audit decisions, each change and its reason, the checks run.
• test/RegistryApplicationSlot.t.sol (new): the finding's reproduction, refusal and failure freeing the slot at once, the day-long expiry bound, and a fuzz that refused terms never reach a listing.
• test/Deployment.t.sol: a new rehearsal reads the seven arguments from launch.json, deploys the registry through CREATE2 on an empty Sepolia-id chain, and checks the predicted address, wiring to the live Stacker, runtime limits, and the absence of an owner.
• docs/design.md: the spam limit now states the one-day bound and why no bond is added.
• README.md: a "Sepolia test run 3 (launching)" section with the registry row, address left open until deployment.

Left for after deployment. The README row's address and explorer verification can only be filled in once the registry is live, and the test-run-2 site still points at the run-2 registry.

Review complete. The math, boundary and numerical-gap audit of the ProjectRegistry found no defects, and .imd-findings.json holds an empty findings list with a coverage row for all 8 entry points plus three invariants and the manifest. The working tree is otherwise clean.

What I checked

• Every arithmetic site in src/ProjectRegistry.sol and src/oracle/OracleAttestation.sol. There is no division, multiplication or decimal scaling anywhere, so the rounding and precision failure modes in the Math Precision guide do not apply. The only operations are checked additions on time and fees, plus uint64 casts of block values. Every time comparison widens to uint256 first, and the cooldown is capped at 365 days, so none can overflow.
• Exact boundaries, each confirmed against the code with a passing test. The issued-at tolerance at ±300 s, the attestation expiry inclusive, the one-day deadline where an answer is still accepted and expire is refused, then both flip one second later. The challenge cooldown and the handoff interval at openAt - 1 versus openAt. Rate limits at 24, 25, 100 and 101. The panel floor (15, 11, 11) accepted and every single-field shortfall refused, including quorum 12 with 11 agreeing.
• Value conservation. Each ask pulls fee plus bond and approves exactly the fee, so no residual allowance survives, including after a price change. All three settlement paths move exactly one bond, and a zero-bond deployment skips the transfer consistently on every path.
• Boundaries with the live chain. A public Sepolia RPC was reachable, so all 8 fork tests ran and passed today. The live Intake returns a 0.5 test-IMD price, a 1,000,000 callback gas allowance, and a 4-word requests tuple, which is what expire decodes. The cold 200k-gas tests cover the mainnet stipend for all four outcomes.
• Body limits. All 8 definitions stay under 512 bytes at the maximum rate, and the question stays under 2000 bytes with a 48-byte name and 200-byte URL.

One trust note, not a finding. The callback accepts an attestation whose agreed exceeds panelSize. Only the oracle signer can produce that, and a signer willing to do so could sign a consistent one instead, so it has no exploit path. It is recorded in the coverage row for the callback.

Not reached. Nothing in the assigned area was left unexamined. The self-challenge pattern, where a beneficiary front-runs a hostile challenge with its own at 0.5 IMD each, is an economic design question outside this area and is left to the specialist covering it.

The findings file is valid, the quoted snippet matches line 81 of the registry, and the working tree is otherwise untouched.

Result: no permission defect found in the Access Control, Trust Gap or Asymmetry areas. The review file holds one info-level trust assumption and a coverage row for every listed entry point.

What I checked:

• Access control. Every state-changing path was traced for its guard. The two callbacks accept only the Intake and only an intake id this registry opened. A third party who pays the Intake for their own question naming this contract gets UnknownRequest. setBeneficiary is restricted to the current beneficiary of a listed project with no open ask. There is no owner, initializer, upgrade path or signer setter to escalate through.
• Asymmetry. Writers and readers of every Project field, the pin flag and the handoff clock were diffed. Defend and delist paths move exactly the bond, once, to the locked beneficiary or the challenger. The expire boundary is disjoint from the TooLate boundary. Relisting through a fresh application names a new wallet only after a panel yes, and keeps the pin and handoff clock as documented.
• Trust gap. The known residual limits, a third party holding the application slot for one fee per round and a beneficiary self-challenging to occupy the slot, are already covered by the author's tests as accepted bounds. The handoff-once-per-day fix does what it claims. A front-running handoff makes the compat challenge revert before any payment and the pinned retry always files.
• Manifest. launch.json has only the schema keys, seven string arguments in declaration order, and the exact addresses and values from the brief. The callback selectors recompute to 0x510379c7 and 0xa7980e31.

The one recorded item is informational. The oracle signer, Intake and action id are fixed for life because the registry has no owner, which the brief requests. If IdentityMD rotates the signer or retires oracle-1, every answer reverts BadSignature or every ask reverts OracleUnavailable, bonds are recoverable through expire, and the registry must be redeployed.

The full suite passes locally. The README states 172 tests, while forge reports 178 in total, 170 run and 8 fork tests skipped. That is a documentation count, not a defect.

The review is complete and .imd-findings.json is written with an empty findings list and a full coverage record. The working tree is otherwise clean (the scratch test was removed, and .imd-findings.json is ignored by git).

Result: no reproducible economic, invariant or flow-gap defect in the ProjectRegistry. The test suite passes offline (170 tests, 8 fork tests skipped without an RPC).

What I checked in the assigned area:

• Value flows. Every bond pulled has exactly one exit, the bond is immutable, fees are forwarded in the same transaction, and no approval lingers. The suite's accounting invariant confirms the balance equals the open bonds under repricing and donations.
• Timers and boundaries. The cooldown, handoff interval, pending expiry and the answer's TooLate boundary are consistent with each other. The defended bond always reaches the wallet named when the challenge opened, since the beneficiary is locked while a question is open.
• Answer routing. A stranger's paid question signed for this contract arrives under a foreign Intake id and reverts. Failures move only the challenger's own bond, the same outcome expire gives a day later.
• Manifest and body. launch.json has exactly the schema keys and the seven constructor arguments in the brief's order. The emitted body equals the rehearsed version-2 body character for character apart from the consumer address, with all eight rules under 512 characters and a runtime of 22,294 bytes.

Recorded as trust assumptions rather than defects: the fixed signer and action id in an ownerless contract, the writer's ability to withhold answers, and the documented slot-occupancy limit.

Not reached: the live Intake's completion semantics and callback gas (fork tests need an RPC), the off-chain indexer, and the launch policy's gas ceiling against the 35.2M estimate.

The review is complete. The findings file is valid JSON with 3 findings and 13 coverage rows, the scratch test is removed, and the working tree has no stray files (the findings file is excluded by the repository's own git exclude rules, as intended).

Outcome: no critical, high or medium defect in the registry's control flow. The entry points behave as the brief specifies, and I verified the live dependencies rather than assuming them.

What I checked

• All 170 offline tests pass, and I ran the 8 fork tests against public Sepolia and mainnet RPCs. All 8 pass. The live Intake sells the question for 0.5 test IMD, gives callbacks 1,000,000 gas, and its requests getter returns the 4-word layout the registry decodes.
• The oracle library matches the canonical copy in struct, type string, domain and hashing. It differs only in formatting and an ECDSA-first signature check that is a superset of the canonical one. The conformance vector passes.
• The Intake completes a request and attempts the callback in the same transaction on Sepolia. I confirmed this from a completion transaction on the test run 2 registry, so the early expire path cannot be raced.
• The manifest lists one contract with the seven agreed arguments in order, the constructor makes no external call, and no workflow files exist.
• Question bodies stay within every paid-door limit at maximum text lengths, and the rules text matches the rehearsal body.

Findings written

1. Low. A beneficiary can front-run every honest challenge with a self-challenge carrying its own reason. The honest transaction reverts before paying, and the beneficiary's bond always returns to itself, so each cycle costs it only the 0.5 IMD fee. The project is still judged, but the challenger's hint never reaches the panel. I confirmed the sequence with a scratch Foundry test over three cycles. This is the sibling of the handoff front-run the first audit fixed, and it needs a design decision rather than a code patch.
2. Info. With no owner, a retired oracle-1 action or a moved price asset leaves the registry permanently unable to list or delist. This is the agreed design, recorded as a trust assumption.
3. Info. The answer is bound to the request only by the Intake writer's pairing, since the relative window makes the question hash uncomputable in advance. Recorded as the accepted trust boundary.

The findings for the application, challenge, failure, result, expire and handoff entry points, plus the live Stacker's credit path, each have a coverage row.

The findings file is in place and valid; git hides it by the repository's own exclude rule, which is how the network collects it. Everything is done and verified.

Summary

Delivered. Three new test files under test/, 29 tests, plus the coverage table entry. The full suite passes:

Run	Result
forge build	clean
forge test	201 passed, 0 failed, 8 fork tests skipped (no RPC)

What the new tests cover

• test/RegistrySepoliaRun3.t.sol deploys the registry from launch.json's own arguments on chain 11155111, with test doubles etched at the live Intake and test-IMD addresses. It checks the fee is read live from the Intake address, the body routes to chain 1 while naming Sepolia, the live Stacker and this registry, and the eight version-2 rules match the spec in docs/panel-rules-v2.md character for character. Since the oracle's key is not ours, it proves nothing else can settle: a fuzzed set of other keys, another registry's or chain's signature, and every plausible setter all fail. Refusals, split panels, expiry and challenges on unlisted projects run with the Sepolia bond and cooldown.
• test/RegistrySignerAuthority.t.sol covers the signature verification branches no earlier test reached: high-s, compact and zero-based-v encodings, every single-bit corruption, a signer key with delegated code, an ERC-1271 key registry that accepts and rotates, reverting or malformed contract signers, and an attacker's own 1271 contract.
• test/RegistryPayoutEdges.t.sol covers a payout the token refuses, panels larger than asked, fuzzed panel-field boundaries, a zero-bond registry and two registries sharing one signer.

Two findings reported in .imd-findings.json, neither affecting this Sepolia run:

• Low: a challenger whose wallet the oracle asset refuses to pay freezes the project's slot forever, because every clearing path pushes the bond in the same call and expire reverts with it. The Sepolia test IMD has no blocklist or pause, so this cannot happen in test run 3. It matters if the mainnet IMD gates transfers. The attached proof test fails on the current code with the token's error.
• Info: the panel check does not require agreed to fit panelSize, so a signed but impossible panel is accepted.

Still owed to live state: the 8 fork tests, including the one that checks the real Intake's requests() getter shape, need SEPOLIA_RPC_URL and ETH_RPC_URL and were skipped here. The README deployment-table entry is outside the paths this task may write.

I found nothing that blocks this launch. The registry deploys exactly as launch.json lists it, wired as the brief says. I kept two low findings and three info notes, all reproduced against the code, and wrote them with the coverage record to .imd-findings.json. No repository files were changed; my scratch tests are deleted.

Deployment checks:

• Size: the registry's deployed code is 22,294 bytes (limit 24,576) and its creation code 23,915 bytes (limit 49,152).
• Constructor: it makes no external call, and the manifest's seven arguments match the brief in order.
• Tests: the full forge test run passed 199 tests, more than the 172 the brief mentions. The fork tests need an RPC URL, which this machine doesn't have.

Kept findings:

1. Low – a beneficiary can pre-empt honest challenges (src/ProjectRegistry.sol:284). The beneficiary front-runs each challenge with one of its own. The honest call reverts AskOpen without paying, and the bond comes back to the beneficiary whatever the answer. Each round costs only the 0.5 IMD fee. The panel still judges every rule, but the honest challenger's reason never reaches it. My scratch test confirmed it: after 3 rounds the beneficiary was down exactly 1.5 IMD, the honest wallet's balance was unchanged, and the project was still listed.
2. Low – a challenger the token won't pay locks the project's question slot for good (src/ProjectRegistry.sol:424). Every path that closes a challenge sends the bond back in the same call. If the token refuses that transfer, the oracle's answer can't be applied and expire reverts every time. The project then stays listed with no way to delist it. I ran the specialist's attached proof and it fails on the current code for the stated reason, so I kept it on this finding. This can't happen on Sepolia, where the test IMD is a plain ERC-20; it matters for a token that can block wallets.
3. Info – no check that agreed and quorum are at most panelSize (line 346). A signed answer with 40 agreeing out of 15 would be accepted. Only a faulty or compromised signer could produce one.
4. Info – the signer, Intake and action can never be changed. This is the agreed no-owner design, recorded as a trust assumption. If the signer key rotates or oracle-1 is retired, nothing can be listed or delisted again without a new registry; no funds get stuck. Two specialists reported this separately and I merged them into one.
5. Info – answers are paired to questions by the Intake's writer, not by the question hash. The contract already documents this trust.

Coverage: setBeneficiary, applyListing and Stacker.credit hold. The other five entry points carry the findings above. Stacker.credit isn't deployed by this launch; it's the live Stacker at 0x0457…314d.