Done. The MNEMO launch contracts are implemented, tested, documented and committed on main as 01ea8c4.

What was built

• src/LaunchToken.sol: Mnemo (MNEMO), a fixed-supply OpenZeppelin ERC-20 with no constructor arguments. It mints 10^27 minor units to the deployer and has no owner, mint, pause, fee or upgrade path. The brief asked for exactly this, so nothing was left out.
• src/MnemoVault.sol: the application contract. Constructor takes the token and owner, so the manifest fills them with $token and $owner. It stores sealed notes as Noted events, burns the stamp from the payer straight to the dead address in the same call, tracks per-wallet epochs, and records agent grants. The owner (Ownable2Step, renounce reverts) can only call setStamp within 100 to 100,000 MNEMO. All numbers from the brief are constants: 2,000 MNEMO initial stamp, 2,048-byte notes, 16 notes per call.
• docs/abi/LaunchToken.json and docs/abi/MnemoVault.json: ABI exports.
• README.md: constructor table, enforced constants, open choices I made (empty notes rejected, grant requires a registered agent key, forget is all-or-nothing), trust assumptions, and operational responsibilities. Nothing needs to be set after launch.
• lib/: forge-std v1.11.0 and OpenZeppelin v5.4.0 vendored as plain files, sources and licences only, no submodules.

Verification

The suite covers success and failure paths for every function, two-step ownership, the disabled renounce, fuzz tests for stamp and epoch handling, and an invariant suite confirming the vault never holds tokens and burnedTotal always equals the dead-address balance. The constructor was tested against an address with no code, matching the launch's empty-chain check.

Left for later stages

• No launch.json: the manifest step writes it. MnemoVault must be listed after the token since it references $token.
• Slither and Mythril were not run because they are not on this worker. Forge's built-in lints produced style warnings only. An independent adversarial review remains part of this stage.

Created launch.json with Mnemo token metadata, MnemoVault arguments ["$token", "$owner"], and the required pool settings.

Checked fields and compiled constructor ABIs. forge build succeeded; all 64 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

The review is complete and .imd-findings.json holds the result. The snippet and line were validated against the source, the scratch tests were removed, and the working tree has no other changes.

Outcome. The math in MnemoVault and LaunchToken is sound. There is no division, downcast or decimal conversion anywhere, so the rounding, zero-truncation and scale-mixing failure modes from the Math Precision guide do not apply. The one multiplication is bounded by construction: the stamp is capped at 100,000 MNEMO and the count at 16, so the burn can never exceed 1.6e24, and burnedTotal is bounded by the fixed 1e27 supply because the transfer must succeed in the same call. All range checks are inclusive at exactly the bounds the brief states. The exported ABI files are identical to the compiled ABIs.

One finding, severity low. A user's write or writeFor has no maximum acceptable stamp and setStamp takes effect immediately. Reproduced with a scratch Foundry test: a user quoted 32,000 MNEMO for 16 notes, holding an unlimited approval, pays 1,600,000 MNEMO when the owner raises the stamp to the maximum before inclusion. With an exact approval the same sequence reverts, so the loss needs an unlimited allowance. The actor is the privileged owner and nobody profits, so this is reported as a material trust assumption rather than an exploit. The code conforms to the brief, which fixes the function signatures. The suggested minimal fix is a delayed effect for setStamp, which keeps both the ABI and the owner's power.

Coverage. All 13 entry points have a row: 10 hold, 3 reference the finding (setStamp, write, writeFor). Five extra rows record invariants I checked, including epoch saturation at 2^32-1, which reverts rotate and revoke but is not reachable in practice. The only unreached item is launch.json, which does not yet exist in the tree.

Also noted but not reported: the aderyn leads were all false positives or bounded by design (uninitialized loop index defaults to zero, loops are capped at 16 or self-paid).

The review is complete. All three snippets match the tree, the scratch directory is removed, and the working tree is clean apart from the findings file.

Outcome: no critical, high or medium defects in the Execution Trace, Periphery and First Principles areas. The findings file holds two low findings and one info note, with a coverage row for all 13 entry points plus three invariant rows.

Findings written to .imd-findings.json:

• Low, stamp charged at inclusion time. The write functions read the mutable stamp with no caller ceiling. A setStamp to the 100,000 MNEMO maximum mined ahead of a signed 16-note write burns 1,600,000 MNEMO instead of the quoted 32,000 when the wallet gave an unlimited allowance. The brief grants the owner this power and the README documents it, so it is reported as a privileged-power risk with a concrete mechanism. The minimal fix adds a caller-supplied maximum stamp, which changes the brief's signatures and needs the requester's decision.
• Low, no re-seal path for a still-granted agent. After rotate, or after revoking a different agent, the owner's grant call reverts with AlreadyGranted, so the fresh vault key can only be delivered by revoking the agent again, which rotates once more. A stranded agent still passes writeFor at the new epoch and burns its stamp for a note the owner cannot decrypt. Both sequences were reproduced in scratch tests.
• Info, README names an owner address absent from the brief. The constructor table correctly says the launch value is $owner but adds a literal address found nowhere else in the tree. A manifest copying the literal would fix the stamp power to an unverifiable wallet.

What held: payer is always msg.sender so no residual allowance is spendable by others, forget is all-or-nothing with owner checks, epoch rotation is caller-only, the constructor makes no external call and takes an explicit owner, burnedTotal stays coupled to the dEaD transfer, and the Ownable2Step paths behave as OpenZeppelin specifies. The three aderyn leads on the forget loop did not produce reachable defects. The existing 64-test suite passes.

Not covered: no on-chain pool or factory behaviour was traced, since the tree contains no launch.json and the manifest step has not run. Slither produced no results and no further static tools were run.

The review is complete. The findings file is on disk at the repository root, excluded from git by the repo's own exclude list, and the working tree has no other new files.

Outcome: two medium findings, no critical or high, in .imd-findings.json with 18 coverage rows (all 13 listed entry points plus 5 invariants). Existing 64 tests pass, and both exported ABI files match the compiled ABIs.

Finding 1 (medium, flow gap): granted agents cannot be re-keyed after any rotation. The sealed key only travels through grant, which refuses an already-granted agent, and the only way to grant again is revoke, which rotates. With two or more agents, no sequence of calls ever leaves every granted agent keyed at the current epoch. A stranded agent stays authorised and burns 2,000 MNEMO per note writing under a key the owner cannot match. Reproduced with three agents and one revoke.

Finding 2 (medium, economic): write and writeFor have no stamp bound. A writer with a large allowance who signs at 2,000 MNEMO pays whatever stamp is current when mined, up to 100,000 per note, if an in-range setStamp lands first. The fix needs a scope decision since the brief fixes the signatures, so the file also states the client-side mitigation of exact approvals.

What held: burn accounting against the dead address, note id monotonicity, epoch guards on pending writes after rotate or revoke, the single trailing external call to a fixed plain token, constructor beneficiaries, and the token's standard transfers. No launch.json exists in the tree yet, so the manifest could only be checked against the README's constructor description.

Not reached: nothing in the assigned area. Static analysis leads were all low style items and none reproduced as defects.

The review is complete. Nothing in the tree changed: the source hash matches HEAD, git status is clean apart from the gitignored scratch tests, and .imd-findings.json holds two findings and a 16-row coverage record.

What I audited. The Access Control, Asymmetry and Trust Gap guides against MnemoVault and LaunchToken. I mapped every writer of every storage slot, traced each of the 13 entry points, diffed docs/abi against the compiled ABI (identical), and reproduced both leads with Foundry tests under test/scratch/.

Findings, both medium:

1. grant blocks re-sealing a key after rotation (src/MnemoVault.sol:186). revoke and rotate bump the epoch, which invalidates every still-granted agent's sealed key. The only on-chain relay of a new key is grant, which reverts AlreadyGranted. The workaround, revoke then grant, rotates again, so with two or more agents the owner can never bring them all onto the current epoch. Proof attached: it fails on this code and passes once the revert on that line is dropped, which I verified by applying the change transiently and restoring the file.

2. Writes carry no price bound against setStamp (src/MnemoVault.sol:267). A writer who approved a standing allowance and is shown 2,000 MNEMO per note burns 100,000 per note if the owner's setStamp lands first, 1,600,000 MNEMO instead of 32,000 on a 16-note write. Same for agents through writeFor. This is the owner power the brief grants and the README documents, so it is reported as a trust gap with concrete loss, not a bypass. Fix options need a scope decision since the brief fixes the write signatures; a delayed two-phase setStamp keeps the ABI.

Coverage. All 13 entry points have rows. Ownership (two-step, renounce disabled, owner from the $owner argument), forget, register, revoke, rotate and the token hold. The one unreached row is the launch manifest: no launch.json exists yet, so the constructor beneficiaries the README states could not be checked against a manifest.

The static-analysis leads were all low-severity style notes and reproduced nothing beyond the above.

Added failure-path, fuzz, and multi-actor invariant tests. Only test/ changed.

Verification passed offline with the supplied fuzz seed: 95 tests passed, including 16,384 invariant handler calls. forge build also passed.

No contract defects were reproduced.

Review complete. The findings file is written at .imd-findings.json and the scratch tests are removed, so the tree is unchanged apart from that file.

Outcome. Three findings kept, none critical or high. All nine specialist reports collapsed into two root causes plus one documentation note, and each was reproduced against the code before it was kept. The full suite of 95 tests passes, the exported ABI files match the compiled ABIs exactly, and the manifest is schema-valid with the vault's constructor arguments in declaration order and $owner for the privileged role.

Findings kept

• Medium, grant() cannot re-seal a still-granted agent. Merged from three specialists. After any rotate() or revoke() the epoch advances but other grants stay live, and the only on-chain key relay is grant(), which reverts AlreadyGranted. With two or more agents no sequence ever brings all of them onto the current epoch. A stranded agent still passes writeFor and burns stamps for unreadable notes. The specialist's proof fails on this code for exactly that reason and is attached.
• Low, writes have no caller-side stamp bound. Merged from all four specialists. An in-range setStamp mined ahead of a pending write charges the current stamp, up to 50x the quote, from any writer with a standing allowance. Reproduced in a scratch test, with the exact-allowance control reverting as expected. Calibrated low because the brief grants the owner this power and the README documents it as a trust assumption. Fixes need a scope decision since the brief fixes the write signatures.
• Info, README names a literal owner address. The address appears only in the README and nowhere in the brief, source, tests, or manifest. The manifest correctly uses $owner.

Coverage. All 13 entry points are answered, plus rows for the burn invariant, the manifest, and CREATE2 deployability. Runtime is 4,352 bytes, creation 4,800, the constructor makes no external calls, and no forbidden opcodes are present. Nothing beyond the specialists' leads surfaced in my own pass over forget, rotate, register, revoke, ownership transfer, and the token.

The shell is still refusing every command, so forge could not run in this session. The edits are complete and checked by reading them back. Here is the recap.

Outcome. The reopened finding is real and is fixed. The two advisory findings are answered: one as a documentation fix, one as a disputed scope question. All three answers are in .imd-responses.json.

What I verified and changed

• Re-seal finding (medium), fixed. grant() was the only function that relays a sealed key, and it reverted for a still-granted agent. rotate() and revoke() leave other grants in place, so a kept agent could not receive the current epoch's key without a revoke that rotates again. The AlreadyGranted check is removed from src/MnemoVault.sol: a repeated grant keeps the flag, does not rotate, and emits Granted with the owner's current epoch. The unused error is dropped from the contract and from the ABI export in docs/abi. The test that pinned the old revert is replaced by four re-seal tests, including the proof's revoke and rotate scenarios, and the invariant handler now also issues repeat grants.
• Stamp repricing (low), disputed. The behaviour reproduces as described, but it is what the brief specifies: fixed write signatures and an immediate owner-set stamp for future writes. A delay or a maximum-stamp argument is a scope change for the requester. The README now states that an exact approval is the writer's only protection and requires the site and agent script to approve exactly the quoted amount per transaction, never an unlimited allowance.
• Literal owner address (info), fixed. The address came from this assignment's launch section, which is not in the tree. It is removed from the README constructor table, which now gives only $owner and explains how the manifest step resolves it.

Not verified here. Every shell command failed with a sandbox error before starting, so forge build, forge test and forge fmt --check did not run on this machine. The source change is a one-line removal plus doc comments, and the new tests use only the suite's existing helpers and events. The verifier's run of the proof and the suite is the check for this revision. The README's test count was updated by arithmetic to 67 and should be confirmed by that run.

The manifest at launch.json is complete and needs no change for this revision. The working tree is clean.

What I checked

• The brief lists no findings, and the only change by the other contributor since the manifest was accepted touched the vault's grant re-seal behaviour, not its constructor.
• The accepted MnemoVault constructor still takes (address token_, address owner_). That matches the manifest's ["$token", "$owner"] and the exported ABI in docs/abi/MnemoVault.json.
• The token entry names LaunchToken with name "Mnemo", symbol "MNEMO" and 18 decimals, exactly what src/LaunchToken.sol sets. It has no constructor arguments.
• The pool block carries the launch's own values: paired currency 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 in lowercase, fee 12500, tick spacing 60 and the one-to-one initial price string.
• Kind is "evm_project", both contract identifiers are unique and under 32 characters, no reserved names appear, and there are no extra keys such as chainId, supply or allocations. Notes are well under the 4,000 character limit.
• The file parses as valid JSON.

Verification

forge build: ok
forge test (FOUNDRY_FUZZ_SEED=0x43cf...fdf): 67 passed, 0 failed, 0 skipped
git status --porcelain: clean

No file was modified. The accepted launch.json stays as the deliverable, and no scratch files were left behind.

My test suite compiles again and fits the updated vault. forge build succeeds, and forge test with the verifier's seed passed all 103 tests across 6 suites with 0 failures. The model-based invariant campaign ran 256 sequences (16,384 calls) with no unexpected reverts.

Why it broke: another contributor changed src/MnemoVault.sol so that calling grant on an agent that's already granted no longer fails with AlreadyGranted. It now succeeds as a "re-seal": the grant stays, the epoch doesn't change, and the Granted event carries the owner's current epoch. My test helper still referred to the removed error, so the project wouldn't compile.

What I changed:

• test/helpers/MnemoModelHandler.sol: a grant to an already-granted agent is now expected to succeed and to emit Granted with the current epoch. The handler counts these re-seals in a new successfulReseals counter. Grants with an empty key, to yourself, or to an unregistered agent are still expected to fail with their exact errors.
• test/MnemoVault.stateful.t.sol: the fixed replay test now re-seals once successfully, tries an empty re-seal that must fail, checks every invariant, and asserts exactly one re-seal happened.
• test/MnemoVault.adversarial.t.sol: five new tests for the re-seal path:
  • After two rotations, a re-seal emits only Granted, carrying epoch 2. It never rotates, moves no tokens, and a write at the old epoch fails.
  • A failed re-seal (empty key, self, zero address) leaves the existing grant working.
  • Re-sealing one agent after revoking another doesn't bring the revoked agent back.
  • A re-seal in one owner's vault doesn't touch another owner's grants or epoch, and it works after the agent registers a new key.
  • A fuzz test (1,000 runs) does up to 24 re-seals mixed with rotations. The epoch only moves on rotations, no funds move, and one revoke still ends access.
• test/TESTING.md: updated to describe the re-seal coverage.

I found no contract defect, so I wrote no .imd-findings.json. One caveat stays a trust assumption the README already documents: after rotate or revoke, the agents an owner keeps can still call writeFor while holding only an older key until the owner re-seals them. The contract can't tell which key a note was sealed with, so this can't be tested on chain.

Only files under test/ changed, and I haven't committed them.

Review complete. All three earlier findings are settled and nothing new reproduces, so the findings list is empty.

Settled findings

• grant() re-seal (medium): fixed. The revert on an already-granted agent is gone. grant() now sets the flag idempotently and emits Granted at the owner's current epoch without rotating, at src/MnemoVault.sol:184. The attached proof passes on the revised code, the stale error is removed from the source and the ABI export, and docs/abi matches the compiled ABI exactly. The full suite passes with 107 tests.
• Stamp repricing of pending writes (low): accepted as designed. The author kept the brief's fixed signatures and immediate setStamp, and applied the README option I offered. The README now states that a signed write pays the stamp current at inclusion, that an exact approval makes a repriced write revert, and that the site and agent script must never use an unlimited allowance. It remains a documented trust assumption on the launch owner, not a defect to reopen.
• Literal owner address in README (info): fixed. The address no longer appears anywhere in the tree. The constructor table gives only $owner and explains how the manifest step resolves it. launch.json uses $token and $owner.

Fresh pass

I re-read every state-changing entry point and the manifest. Both contracts are far under the size limits, the vault constructor makes no external calls, and launch.json is schema-valid with lowercase addresses and a short notes string. The coverage record in .imd-findings.json marks all 13 entry points as holds, plus three invariant rows for the deployment model, the manifest schema, and the ABI exports.

The scratch test directory was removed after running, so the tree is unchanged apart from the findings file.

Wrote the findings to .imd-findings.json. Each includes an exact source citation, proposed correction and measured reproduction.

1. bug: opening the vault discards chat proposals. Following the instruction to open the vault clears the conversation, proposed notes and unsaved API key. Preserve session state across routes.
2. bug: changing providers forwards the previous provider’s API key. A custom endpoint receives the Anthropic credential. Clear credentials when destinations change or associate them with individual origins.
3. bug: an older swap quote overwrites the current minimum. A delayed 10-IMD quote replaced the 100-IMD quote, changing the displayed minimum from 198 to 19.8 MNEMO. Reject stale responses.
4. bug: a pending memory seal can be submitted twice. The mock wallet recorded two write requests for one proposal. Disable submission while confirmation is pending.
5. accessibility: Skip to content changes the active screen. On Chat, pressing Tab then Enter opens the home route. Focus the current main element without changing its hash.

Build/typecheck and all nine unit tests passed. The supplied interaction suite passed 33/33 in Chromium and 33/33 in WebKit. Rebuilding produced an identical export. Both RPCs returned chain ID 1 and deployed contract code. WebKit’s live RPC requests encountered access-control errors in this runner; its interaction suite used mocked RPCs.

“Met” below means the requested capability is present; the five defects above remain.