The review is complete. The findings file is in place and nothing else in the tree was touched.

Outcome: no defect substantiated. All four contracts were read in full and checked against the Pashov checklist and the entry-point inventory, and nothing reproduced as a loss, misdirected payment, broken accounting, reentrancy, weak guard, or bad rounding. The findings file .imd-findings.json holds four info entries: a coverage statement and three documented trust assumptions with concrete reproductions, so the adapter sees them without a revision being opened.

What was read. WorkProof, JsonScan, WorkOrders, OrderHeader, SpecText, CrowdPots, Doorbell, and the IWorkOrders, IPayroll and Mainnet interfaces, line by line. Not read line by line: the 490-line IWorkOrdersRunner interface, which holds only events, errors and structs, and the pinned OpenZeppelin libraries.

What was checked and held.

• The full forge suite passes with zero failures, invariant suites included.
• An independent scan of the four compiled runtimes finds no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE, and all sizes are under the EIP-170 limit.
• Constructor ABIs match the manifest in count and type. Every constructor is nonpayable, makes no external call and checks no code size.
• The three mainnet addresses hold code. IMD reports symbol IMD with 18 decimals and exposes no pause, mint or blacklist selector. The registry runtime contains the latest(bytes16) selector and Payroll contains pay, tip and book.
• The Doorbell's kind hash equals keccak256 of skill:create-image, and its manifest values pass its own constructor checks.
• Accounting traces cleanly: every credit to an order's returned figure is paired with a transfer to the employer, so the pots' pool arithmetic is exact and refunds pay to the wei.
• Nothing the launch forbids is present: no owner, setter, proxy, initializer, pause, freeze, mint or post-deployment configuration.

Trust assumptions recorded as info.

• With the manifest's allowClaimed = 1, any bonded address can ring the Doorbell 25 times, take its order, claim delivery with a made-up job id, and be paid after 24 hours unless someone challenges. The contract header states this and asks that it hold small amounts.
• CrowdPots never calls finalize, so a pot whose runner claimed delivery and walked away stays in the hiring stage until a third party calls the desk. The authors' own test confirms this behaviour.
• A runner posting the opener-chosen bond, as low as 0.25 IMD, can hold a pot's whole target for up to 30 days by registering a job id with no receipt. The Terms documentation discloses the trade-off.

No proof tests were written because no critical or high finding exists. Time remained on the clock, with roughly 30 minutes unused.

The work is complete. The only new file in the tree is ADAPTATION.md; the scratch directory is excluded by the harness, and no launch.json or blocked file exists.

Outcome: the repository launches as it is. No source, test, document or configuration file was changed. The single deliverable added is ADAPTATION.md at the repository root.

What I verified on the unchanged code

• forge build with the project's own foundry.toml succeeds. forge test passes with no network and an empty environment.
• The protected factory harness from the task's read list was run in test/scratch with chain id 1, the real ProjectFactory address etched, and the four initcodes built from the manifest's exact arguments with the $contract: references resolved to predicted CREATE2 addresses. All four deployed at their predicted addresses and the runtime scan found no forbidden opcode.
• Every launch rule the brief lists is already met and already pinned by the repository's own tests in test/launch/LaunchManifest.t.sol: static-word nonpayable constructors with no external call or code check, no owner or $owner, no proxy or initializer or minting or pausing, nothing to call after deployment, and internal-only libraries with empty link references.

The imported audit

All four entries are informational. I reproduced the three behavioural ones step by step against the real desk, pots and Doorbell, including the Doorbell scenario with the manifest's exact values, where one address with 0.25 IMD walks away with 1.15 IMD on an unchallenged false claim. Each reproduces exactly as written. None was changed, because each is the requester's documented and tested design choice rather than a defect: the claimed path is a stated launch-day decision with a required watcher, the pot's reliance on someone calling finalize is written into the contract header and pinned by an existing test, and the bond-to-target ratio is the opener's published choice within the contract's bounds. ADAPTATION.md names the reproduction, the reasoning, and the permanent test that pins each behaviour.

Open items for the requester, none needing code

• The Doorbell's allowClaimed argument is permanent once deployed. The document's launch-day command decides it.
• The fork suite was not run because it needs a mainnet RPC. The three mainnet addresses were taken from the requester's document and Mainnet.sol, not re-read from the chain.
• The claimRefund rule the requester asked to keep is kept.

The review is complete and the findings file is written. The working tree is otherwise untouched.

Outcome. I found no economic defect in WorkOrders, CrowdPots or Doorbell. Every value flow conserves funds, every pro rata share and fee rounds in a stated direction, and every incentive gap I could construct is already named in docs/THREATS.md with a test beside it. The findings file holds one info item and a coverage record for all 28 entry points plus three invariants.

What I checked, from the Economic Security, Invariant and Flow Gap guides:

• Conservation on the desk. Each exit sends exactly what it zeroes. Delivery pays price plus unused escrow plus bonds, which equals escrow plus bonds held. Fee and tip are capped so the runner share never underflows at a one-wei price.
• The employer's returned figure. It is credited beside every transfer to the employer, and the claim guard keeps it under 96 bits. CrowdPots books from it once at a terminal state, so stray transfers and order reopenings never shift a pot's total.
• CrowdPots solvency. The margin between balance and owed can only grow. Shares round down and the last claimer takes the remainder. Launch verifies the desk pulled exactly the target and names the pot as employer.
• Price ramp. It pauses while held, so claim-and-release cannot raise the price, and a reopened order resumes where the claim found it.
• Deadlines. Release/evict, challenge/finalize, claim/refund and claimDelivered/timeout pairs use complementary comparisons with no gap or overlap.
• Flow gap seams. The desk callback moves no money and runs after the lock. Payroll is offered full gas and exactly fee plus tip leaves whether it pulls or not. Pot and Doorbell orders have no condition, arbiter or reserved runner, so no external target can touch their money.

The one item reported is informational. With the manifest's Doorbell values and the claimed path on, a false-claim wave costs the attacker 2.5% of the bond per order while a defender must lock 25% of the Doorbell's balance for up to 7 days to cover it, and undefended orders drain 0.9 IMD each. This is the documented D2 and L6 limit; I quantified it so the requester can size the keeper float the docs ask for.

What I could not complete. The full forge suite exceeded my time box because of the invariant runs, so I did not re-confirm the author's tests pass on this tree. I inspected the invariant handlers instead and they exercise every entry point, so I have no untested edge to name.

I wrote launch.json in the repository root. It matches the manifest in your brief and in docs/LAUNCH.md, and no other file was changed.

Checks against the code:

• Constructors: the argument counts and order match each constructor: WorkProof(workRegistry), WorkOrders(imd, workProof, payroll), CrowdPots(imd, workOrders) and Doorbell(imd, workOrders, kindHash, minPay, maxPay, bond, deliverySecs, allowClaimed).
• Mainnet addresses: the three fixed addresses (IMD, WorkRegistry, and Payroll from launch 1531) are the same as the constants in src/interfaces/external/Mainnet.sol.
• Doorbell kind hash: 0x7679ff00…6869185 is keccak256("skill:create-image"), as section 2 of docs/LAUNCH.md says.
• Contract references: the $contract: references only point to contracts listed earlier, and only fill address arguments.
• No owner: there is no $owner, no token field and no extra key.

Build and tests: forge build succeeded. forge test ran 654 tests with the fork tests left out, and all passed. That includes test/launch/LaunchManifest.t.sol, which checks the manifest in LAUNCH.md against the code. I did not run the fork tests in test/fork/, because they need a mainnet RPC connection. The pinned protected test under .imd/reads/ is outside test/, so it wasn't part of this run.

git status also lists untracked files I did not create, mostly settings and dotfiles (.bashrc, .claude/, .gitmodules, .mcp.json and others). At the start the tree was reported clean, so they probably come from this machine's setup. I left them alone.

Review complete. The findings file is written and the working tree is otherwise untouched.

Outcome. No defect found in the control flow of WorkOrders, CrowdPots or Doorbell. Every one of the 28 listed entry points traced as intended, and the file carries 33 coverage rows with none unreached.

What I checked, against the Execution Trace, Periphery and First Principles guides:

• WorkOrders: every state transition, the order of checks, state writes and transfers in each path, the bond and escrow sums at each claim ending, the exactness of returned, the gas floors before the Payroll, callback and condition calls, and the callback running only after the lock is released.
• CrowdPots: the one desk call that ends a timed-out order before the books are read, the owed and balance coupling on chip, launch, reconcile and pay, pro rata rounding with the last claimer emptying the pool, and series rounds.
• Doorbell: the ring, skip and hire path with its post-call allowance and employer checks, and the once-only delivery record.
• Periphery: SpecText, OrderHeader, WorkProof's registry read and chunk join, the condition staticcall, and JsonScan's structure and capture rules. JsonScan's word-lane arithmetic I did not re-derive; it rests on the passing adversarial, fuzz and reference-scanner suites.
• Manifest: four contracts in dependency order, argument counts and order per constructor, addresses matching the sources and docs, and the kind hash equal to the keccak of skill:create-image.

Test runs: all 649 non-invariant tests pass, and the three invariant suites pass at reduced depth. The via_ir build alone took about eight minutes.

Two informational notes recorded, both already stated in the author's own documentation:

1. The mainnet Doorbell deploys with the claimed path on. A runner can take each 1 IMD hire with a 0.25 IMD bond, register any job id, claim delivery and collect 0.9 IMD after 24 hours unless a stranger posts an equal bond, and that stranger earns nothing for doing so. The reproduction gives the exact call sequence and amounts.
2. chipInFor refuses only the zero address and CrowdPots itself as beneficiary, so a chip for the desk address is accepted and its refund is later paid into WorkOrders, where nothing can move it.

Neither carries a proof test, since proofs are only required for critical or high findings.

The review is complete and the findings file is written.

Outcome: no substantiated defect in the assigned area. The findings list in .imd-findings.json is empty, with 34 coverage rows: one for each of the 28 listed entry points plus the invariants I checked. No source file was changed.

What I covered, against the Math Precision, Boundary and Numerical Gap guides:

• Fee split in the desk. Fee and tip each round up to the next wei, the tip is capped so the runner's pay never underflows, and runner plus Payroll plus returned escrow equals the escrow exactly. The project's own tests hit prices 0, 1, 2, 19, 20, 21, 39 and 41, and a fuzz run confirms the sum.
• Price ramp. The linear formula cannot overflow, rounds down by under one wei, handles a zero ramp and an untriggered condition correctly, and the ramp pause on reopen can never push the start past the present.
• Bond splits. Release, evict, timeout, refute and arbitration all conserve escrow plus the one or two bonds held. Every transfer to an employer is paired with one credit, so the returned figure CrowdPots relies on is exact, and the BooksFull guard keeps the uint96 casts safe.
• Pot refunds. The pro rata share rounds down, the rate is non-decreasing across claims, the last claimer empties the pool, and chipsLeft is always at least the chip so there is no division by zero. The chip and launch deadlines use complementary comparisons, so no second is both chippable and refundable.
• Time boundaries. Claim and refund, release and evict, challenge and finalize, and the delivery deadline versus claimDelivered are all complementary at the exact second.
• Doorbell constants and manifest values. The constructor bounds mirror the desk's minimums and the manifest arguments pass them. The kind hash matches keccak256 of the create-image skill name.

Checks run: the full non-fork suite, 790 tests including fuzz and invariant runs, all passing.

Not reached: I read the JsonScan lane arithmetic and beyond-buffer read paths without finding a counterexample but did not fuzz them independently, and I did not run the fork tests against live mainnet contracts. Both are marked unreached in the coverage record.

The review is written to .imd-findings.json: one medium finding and a coverage row for each of the 28 entry points. No repository file was changed, and the scratch test I used is removed.

Finding (medium)

A runner can hold a receipt-only order past its expiry and leave with its whole bond (src/desk/WorkOrders.sol:441, the SwarmFailed branch of reportFailed).

• What happens: every other exit without delivery costs the runner bond (release 10% and a bar, evict and timeout the whole bond). This branch returns the whole bond and does not bar the runner. The only time limit on it is the delivery deadline.
• Why the runner controls it: the branch checks the objective but not the kind, and the runner picks the job's template. When the receipt says anything but completed, only the runner may submit it, so the runner alone decides when the claim ends.
• Why it matters for pots: a pot hires once. CrowdPots.sol and THREATS C2/W5 tell contributors that a stall on a receipt-only pot costs the whole bond and the order reopens. Instead, any such pot can be ended in a refund with nothing forfeited, for gas and the swarm's 0.5 IMD job fee.
• Precondition: the registry must write a receipt for a job that did not complete, or one of another kind.
• Reproduction: I ran it on the real desk, WorkProof and CrowdPots with the repository's own harness.
  1. The runner claims and registers two days before the order expires.
  2. A blocked receipt with the right objective lands; anyone else's reportFailed reverts NotRunner.
  3. The runner reports after expiry. The order is Refunded, the runner's balance is whole, returned equals the target exactly, and the pot is Refundable.
• Variant: with a completed receipt of another kind, the same address took the order three times in a row and got its bond back each time.

No funds are lost, only locked and returned; I rated it medium because it breaks a stated guarantee. THREATS W3 already records the desk-level behaviour, but not its consequence for pots. The fix I suggest is to keep the release share and/or bar the runner on this ending. That charges a runner whose job the swarm really failed, which is your decision; otherwise the statements in CrowdPots.sol and C2/W5 need correcting.

Coverage

• Holds: 26 of the 28 entry points. I traced each for who may call it, where the money goes, and whether its time boundary matches its paired function.
• Finding: WorkOrders.reportFailed and CrowdPots.reconcile both point to the finding above.
• Left as asked: claimRefund and claimRefunds stay open to anyone; the money goes only to the chip's owner.
• Manifest: argument order and count match each constructor, and the Doorbell kind hash is keccak256("skill:create-image"). On mainnet today, IMD, the WorkRegistry and Payroll all have code, and Payroll.IMD() returns the manifest's IMD.
• Not reached: WorkProof and JsonScan parsing — whether a job participant can plant kind, objective or state. It is outside the permissions area; I traced only its caller surface.

I did not run the full test suite or the fork tests; only the real-desk pot tests ran, alongside my scratch test, and passed.

Done. The two new test files are formatted and committed, and the full suite passes.

What I found. The repository already carried a deep suite (654 tests, per-contract invariants for the desk, CrowdPots and the Doorbell, constructor failure paths for all four contracts). No defect surfaced in any test I wrote, so there is no findings file. What was missing was coverage of the launch itself as the pipeline will run it, and an invariant run over the four contracts working together on the manifest's exact bytes.

What I added, both under test/launch/:

• LaunchFloor.t.sol (14 tests). Rehearses the protected harness without environment variables: a probe etched at the real ProjectFactory address, chain id 1, CREATE2 with each $contract: reference resolved to the address predicted before deployment, then the harness's own opcode walk, EIP-170 and EIP-3860 limits, and a check that the factory holds no privilege afterwards. The failure paths it pins: one wei sent to any of the four nonpayable constructors, a bool written as 2, a zero address in any slot of the desk, the pots or the Doorbell, the Doorbell's arguments in the wrong order, a forward reference, a reused salt, and a stranger using the probe. It also writes down the one slot the floor cannot catch: WorkProof accepts a zero registry address, which is documented as failing safe.
• LaunchSystem.invariant.t.sol. Deploys the four contracts from the manifest in docs/LAUNCH.md with stand-ins etched at the three mainnet addresses, then drives everything at once: Doorbell funding and rings, pots opening, filling, launching, reconciling and refunding, wallet orders, and every desk transition on every order. Seven invariants hold after each of 5,760 random calls with zero reverts: the desk holds exactly its live escrows and bonds, IMD is conserved across all parties, the Doorbell's money leaves only as its own escrow, CrowdPots covers what it owes and pays only the desk or contributors, no allowance is left behind, WorkProof holds nothing, and every order's employer matches the model. A fixed 2,500-step soak proves the random runs are not vacuous: it asserts hires, pot launches, wallet orders, and all twelve desk paths including challenge and dispute endings were reached.

Verification. forge test passes: 670 tests across 32 suites. The commit on the working tree is d916013, touching only the two files above.

Review complete. The findings file is written and validated, and I changed nothing outside .imd-findings.json and my own test/scratch/ file.

What I kept, after reproducing each against the code

• Medium (finding 1, from audit_permissions). The SwarmFailed and wrong-kind endings of reportFailed return the runner's whole bond, never set barred, and refund the order for good when it has expired. I reproduced both variants in a scratch test on the real desk, WorkProof and CrowdPots: a runner holds a receipt-only pot's order past its hire window with a "blocked" receipt of the right objective, ends it itself before the deadline, and the pot is refunded with nothing forfeited. The wrong-kind loop lets the same runner re-claim at once, three rounds with its balance unchanged. This contradicts the three bond statements CrowdPots makes to contributors and C2/W5 in the threat model. No IMD is lost, so medium as a broken guarantee, not a loss. The scope choice (keep the release share and/or bar on those endings, or correct the documents) is the author's.
• Info (finding 2, merged from audit_economics and audit_flow). The Doorbell's mainnet values with ALLOW_CLAIMED = 1 and no arbiter: each escrow is paid to an unchallenged claim, and a correct challenger only ever gets its own bond back after 7 days. Documented in the contract and threat model, listed as the one trust assumption the manifest turns on. Both specialists' numbers check out against the code.
• Info (finding 3, from audit_flow). chipInFor accepts the desk and the token as beneficiary, so a refund claimed for such a chip is stranded. Self-harm only, covered by D7, kept as a note with the cheap extra check.

What I verified myself

• All 28 entry points traced; 27 hold, one carries finding 1, and chipInFor carries info 3.
• The manifest matches the constructors, the kind hash is keccak256 of "skill:create-image", every hex string is even length, and all four contracts are far inside the size limits. The 12 launch manifest tests pass.
• On mainnet through the contributor relay: IMD at the given address reports symbol "IMD", the WorkRegistry returns the exact fixture receipt hash for job e9efec16, and Payroll has code.

Nothing blocks deployment. Finding 1 is the only one that reopens the author's work.

The revision is complete. All three findings are answered in .imd-responses.json, and the build and full suite pass.

The reopened finding (a96c4f58) reproduced exactly as reported, both cases, on the real desk with real receipts. A runner holding a receipt-only pot past its hire window can end it in a refund with its whole bond returned, and a wrong-kind receipt reopens the order with nothing forfeited and nobody barred.

I fixed it by correcting the words, not the desk. The reviewer offered that as one of two acceptable resolutions and left the choice to the authors. The desk rule is deliberate and documented three times over, the brief asks to deploy the code as it is, and THREATS.md section 11 records the requester handling the same class of finding in their first launch the same way. What was wrong was what CrowdPots told contributors the bond sizes.

Changes made:

• src/pots/CrowdPots.sol: the three overstated comments now say the bond is the most a runner loses, is lost whole by silence, a wrong job or a contradicted claim, and comes back whole on a receipt showing the swarm failed the job or ran it under another kind. Compiled bytecode of all four contracts is byte-for-byte unchanged, which I verified by hashing the artifacts before and after.
• docs/THREATS.md W2, W3, W5 and C2 state the mechanics, the cost to each side, and why the desk does not charge the release share there. One row in docs/LAUNCH.md carried the same overstatement and now distinguishes the two cases.
• test/pots/PotsRealDesk.t.sol: two permanent tests pin the reviewer's exact scenarios against the real desk, so the corrected sentences are tied to code.
• ADAPTATION.md section 5 records each change, the reasoning, and the two advisory findings.

The two advisory findings were reproduced and answered as disputed with reasoning: the Doorbell claimed-path exposure is the requested behaviour with the eighth constructor argument fixed by the brief, and the chipInFor beneficiary note concerns only the payer's own IMD under the D7 rule the brief asks to keep. Neither changed code. The Doorbell float sizing is recorded as an open item.

Results: forge build passes, forge test reports 656 passed and 0 failed. Nothing is committed, since no instruction asked for a commit.

The manifest in the tree is already correct and nothing needed to change. This revision brief listed no findings, and every check I could run confirms the accepted launch.json.

What I verified

• launch.json has exactly the keys kind, contracts and notes. It names WorkProof, WorkOrders, CrowdPots and Doorbell in that order with 1, 3, 2 and 8 arguments, matching the four constructor signatures in src.
• Every argument matches docs/LAUNCH.md section 2 byte for byte: the WorkRegistry, IMD and Payroll mainnet addresses, the three backward $contract references, the kind hash, the two 1 IMD prices, the 0.25 IMD bond, 604800 seconds and allowClaimed written as 1. No argument is $owner, as the brief requires.
• The notes string is 160 characters, under the 4000 limit.
• The build is clean and the full suite passes with 694 tests, including the 12 manifest tests and 8 runbook tests in test/launch that parse LAUNCH.md and compare it with the code.
• I ran the pinned protected test from test/scratch against the real initcode with the manifest's arguments resolved in order through CREATE2 predictions. All four constructors succeed on an empty chain, each runtime is under the EIP-170 limit, and no runtime holds DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The tree has no .gitmodules and no submodule entries; lib is ordinary committed files. The working tree is clean, so no file other than the already committed launch.json carries this deliverable.

Nothing is left to do: the manifest is submitted as it stands.

The revision is done. The full suite passes with 673 tests and 0 failures, and the only file changed is my launch-wide invariant test.

What this round changed. The other contributor's review-driven commit altered no bytecode; it corrected the comments and documents on the reportFailed endings that return the bond whole and added two unit tests for them. My work from the previous round was intact and passing on the merged tree. I extended the launch-wide handler in test/launch/LaunchSystem.invariant.t.sol so the random sequences also exercise those endings, and left LaunchFloor.t.sol untouched.

• Three more desk endings in the handler. On a registered order the handler now also lands a completed receipt of another kind, reportable by anyone, and a receipt for a job that is not the order's. The failed-job report by the runner now sometimes waits out the order's expiry first.
• Ghost checks on every bond-back report. The runner's balance rises by exactly the bond, the runner is not barred, the employer is credited nothing unless the order expired, in which case exactly the escrow, and the order ends open or refunded. A stranger's attempt to report the runner's failed job must be refused. Any breach is recorded and fails the existing no-unexpected-revert invariant.
• Wrong-job report checked the other way. The runner gets nothing back and the employer is credited at least the bond.
• A directed test for the C2 ending. The runbook's first pot, opened receipt-only on the manifest-made contracts, is held an hour before its hire window closes, cannot be freed by anyone else, and is refunded by the runner's own report with the whole bond back. The desk still holds exactly what it owes and both contributors get back exactly their chips.
• The soak now asserts the new paths are reached and that every bond-back ending counted was a report that went through.

One wrong property on my side, not a defect. My first version asserted that a wrong-job report bars the runner. The desk only bars on release; the wrong-job ending's deterrent is the forfeited bond. I removed that check after confirming it in the source.

No defects were found, so no findings file was written.

The findings file is written and validated. The review is complete.

Outcome: no blocking findings. My one medium finding from the first round is settled as fixed, and the two advisory notes stand unchanged as documented trust assumptions. The findings file holds three info entries and a 30-row coverage record.

The medium finding a96c4f58 is fixed in words, as I had offered. The author kept the desk's rule and corrected what CrowdPots told contributors about the bond. I checked each part of the answer:

• The three CrowdPots statements and the THREATS W2, W3, W5 and C2 sections now say the bond comes back whole on a receipt that shows the swarm failed or ran another kind, and that this can end a receipt-only pot past its hire window. I found no remaining sentence claiming a stall always forfeits the bond.
• The two new tests in PotsRealDesk reproduce both of my cases on the real desk and pass.
• I built the accepted commit in a separate directory and compared it with the current tree. The creation and runtime bytecode of all four contracts hash identically, so no code changed and nothing could have broken.
• The full suite passes.

The two advisory notes stay as recorded. The author disputed changing code for the Doorbell claimed-path exposure and the chipInFor beneficiary check, and in both cases I agree. Both are documented behaviour the brief asks for, ADAPTATION section 5 now lists the Doorbell watcher float as an open item, and the three specialists' findings this round were the same two observations, merged into mine.

No files in the tree were changed. The only new file is the required .imd-findings.json.