Approved workflow

The memory directory is write-denied in this sandbox, so I'm skipping the memory note. The deliverable is complete and verified.

Delivered (all in the repository root):

• src/LaunchToken.sol: Billboard (BILL), fixed supply of 10^27 minted to the deployer, no constructor args, no admin paths.
• src/HarbergerBillboard.sol: one billboard under a 10%/year Harberger tax in BILL, tax burned to 0x…dEaD, rounding up per second, lazy foreclosure when tax reaches the deposit, maxPrice guard on buy, pull-based payouts, no ETH, no owner, every entry point nonReentrant and settling first.
• test/: 57 tests across four files. Unit and fuzz tests cover tax rounding, foreclosure exactly at runway, price front-run rejection, self-buy refusal, deposit bounds, whole-deposit withdrawal, holder-withdraws-before-sale, foreclosure mid-buy, and reentrancy via a hostile mock token. An invariant suite with fail_on_revert = true checks that held BILL equals deposit plus withdrawable credits, that no settle burns more than the deposit it found, and supply conservation.
• script/Deploy.s.sol: local reference deploy, reads only EXPECTED_CHAIN_ID, tests call deploy() directly.
• docs/abi/LaunchToken.json and docs/abi/HarbergerBillboard.json.
• README.md: rules, interface, tax and runway math, assumptions and trust model, deployment parameters for the manifest (constructorArgs ["$token"], no $owner), operational responsibilities, offline build steps, and self-review notes against the five attack surfaces the workflow names.
• lib/: forge-std 1.16.2 and OpenZeppelin 5.7.0 vendored as plain files, no submodules.

Verified locally:

Not done, by scope: launch.json belongs to the manifest assignment and the independent review is a separate assignment. Nothing was committed because the job rules forbid touching .git/. One design choice to flag for the manifest and reviewer: taxDue() returns the amount a settle would burn now, capped at the deposit, and foreclosure is lazy until anyone calls settle().

Done. The only new file in scope is launch.json; everything else untracked in the status output is sandbox device nodes and the harness's own .claude/ directory, plus my scratch validator under test/scratch/, which is discarded before submission.

What the manifest declares

• Token: LaunchToken from src/LaunchToken.sol, name Billboard, symbol BILL, 18 decimals. Matches the ERC20 constructor call in that file and the empty constructor in the ABI export.
• Contracts: one entry, HarbergerBillboard with constructorArgs ["$token"]. The ABI export shows a single address-typed input token_, the constructor is nonpayable and makes no external calls, and the contract has no owner, so no $owner is passed.
• Pool: paired against native ETH (zero address), fee 3000, tickSpacing 60, initialPrice 79228162514264337593543950336. This matches the deployment table in the README and the Sepolia guidance. No hook.
• Notes: about 1900 characters describing the token, the application constructor, the tax-burn design, the pool, and the toolchain, with an explicit statement that supply, allocations, owner and chain come from policy.

Checks run

• A scratch validator replayed the LaunchManifest JSON Schema plus its refinements (unique names, MerkleDistributor reserved, backward-only references, references only in address slots, initialPrice below 2^256) and cross-checked each constructor's arity and types against docs/abi/*.json. It reported no errors.
• forge build --offline, forge test --offline (57 passed, 0 failed), and forge fmt --check all succeeded.
• The deploy script dry-run with EXPECTED_CHAIN_ID=0 deployed LaunchToken then HarbergerBillboard wired to it, confirming the dependency order the manifest declares.

No other file was modified.

I found no blocking defects: every attack the workflow lists fails, and launch.json is correct. The findings are in .imd-findings.json: 8 entries, all severity info, valid JSON. No other files were changed.

forge test passes 57/57, including the invariant suite (4096 calls with fail_on_revert). Both docs/abi/*.json files are identical to the compiled ABIs.

The five attacks, each with its call sequence in the JSON:

1. Tax rounding and elapsed-time arithmetic: fails.
   • The tax formula matches the spec: 10% of price per 365 days, rounded up.
   • The runway calculation lands on the exact second of foreclosure.
   • Overflow can't happen: the worst case is about 1e40, far below 2^256, and elapsed time can't underflow.
   • Calling settle() every second adds at most 1 wei of burn per call.
2. Holder raises the price ahead of a buyer (setPrice): fails.
   • buy compares maxPrice against the price after settling, so the buyer's transaction reverts with PriceAboveMax and takes nothing.
   • Someone who jumps in first as holder can gain at most the buyer's own slippage, maxPrice - price.
3. Holder withdraws their deposit just before a buy to dodge tax: fails.
   • withdrawDeposit settles first, so all tax owed is burned before anything leaves.
   • With a zero deposit, the next settle forecloses even in the same block. The holder loses the sale price and the buyer pays nothing.
4. Foreclosure in the middle of a buy: fails.
   • The buyer pays only their deposit and the old holder is credited nothing.
   • The balance invariant (BILL held = deposit + withdrawable) holds on both the foreclosed and normal paths.
5. Reentrancy on withdraw: fails.
   • Every entry point is nonReentrant, and each function updates its state before the token transfer.
   • BILL is a standard OpenZeppelin ERC-20 with no transfer hooks, so nothing can call back in.

Manifest: constructorArgs ["$token"] fills the only constructor argument, address token_, and the constructor is nonpayable. It grants no role and doesn't use msg.sender. There is no owner, admin, pause or upgrade path, so no $owner is needed. The token has no constructor arguments, and the rest of the manifest fits the schema.

Two non-blocking notes:

• Frontend display: state() keeps showing a holder whose deposit has run out until someone calls settle(). That follows from the spec, but the website should mark the board as buyable when runwaySeconds() == 0.
• Test coverage: the fuzzed call sequences never use a price above 1,000,000 BILL or a maxPrice below the current price. Unit tests do cover both edges.

Implemented the frontend, static export, deployment manifest, and documentation.

• Build, typecheck, and all 6 tests pass.
• Live RPC/browser checks pass.
• Complete candidate snapshot: 5.41 MB, below 8 MiB.
• Evidence: VALIDATION.md.
• Design documentation: docs/DESIGN.md, respecting the allowed scope.

Git staging/commit is blocked because .git is read-only. All deliverable files are ready for collection.