test(GRD): Guard-write e2e scaffold (fixme — guard-account deploy/render blockers)#371
Merged
Conversation
GRD-04 (toggle Guard strict mode via the account's passkey UserOp): scaffold is
complete and reuses the proven S4 chain — register(dailyLimit>0 → account gets a
guard) → fund → deploy → /guard toggle → verify strictMode flips on-chain.
Marked test.fixme: a dailyLimit (guard) account has two divergences from a plain
account that need dedicated debugging — (1) it doesn't render in the dashboard/
transfer UI after create ('No Smart Account Yet'), and (2) its first/deploy UserOp
fails AA21 'didn't pay prefund' on the Pimlico bundler despite ample funding
(needs ~0.002 ETH, funded 0.2; a 30s propagation wait didn't clear it) — a
bundler balance-view issue tied to the high-gas guard deploy (~1.35M verGas).
Helpers added (reusable): register(dailyLimit), getGuardAddress/hasGuard/
getStrictMode, deployAccount. The guard-write mechanism itself ships in #362
(/guard page + GuardClient). Suite: 6 passed, 1 fixme-skipped.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
… AA24 remains Pushed the guard-write e2e further. The guard-account deploy hits a chain of guard-specific issues in its first UserOp; fixed two: - (1) UI render race — deployAccount now retries the dashboard/transfer load until DashboardContext shows the account (a guard account raced the first render). - (2) AA21 'didn't pay prefund' — depositToEntryPoint() pre-funds the account's EntryPoint deposit. Proven not an amount issue: 0.2 ETH balance + ~0.002 ETH prefund still hit AA21; a guard account can't pay prefund from plain balance, but the deposit covers it. - (3) AA24 'signature error' — OPEN. The guard account's first deploy+transfer fails signature validation (sig prefix 0x02 = Tier-2 P256+BLS) — a protocol-level interaction between tiered signing and the not-yet-deployed guard's validation. Needs backend/contract investigation, not a test-side fix. Helper added: depositToEntryPoint. test.fixme kept (suite 6 passed / 1 skipped). docs/TEST_RESULTS.md S4 documents the full chain + the two fixes.
clestons
approved these changes
Jun 24, 2026
clestons
left a comment
clestons
left a comment
There was a problem hiding this comment.
clestons review — #371 [2-round, APPROVE]
test(GRD): Guard-write e2e scaffold (fixme — guard-account deploy/render blockers) — 5 files (+205/-3). E2e test scaffold + helpers + docs. No production code changes.
Content ✅
e2e/guard.spec.ts(GRD-04): scaffold for guard strict-mode toggle via passkey UserOp.test.fixmecorrectly applied — three-layer blocker documented: (1) UI render race ✅ fixed; (2) AA21 prefund ✅ fixed (depositToEntryPoint); (3) AA24 signature error — protocol-level, requires backend/contract investigation, not testable here. Keeps suite green.e2e/helpers/account.ts— newdeployAccounthelper with retry logic.e2e/helpers/fund.ts— extended withgetGuardAddress,hasGuard,getStrictModeon-chain reads.e2e/helpers/register.ts— minor update.TEST_EOA_PRIVATE_KEY/ETH_RPC_URLread from.env.test(not hardcoded). ✅
Secret scan clean.
APPROVE. Merge is the maintainer's call.
…artifact undetermined) The guard-account first UserOp never succeeded in automation (AA21 fixed via EntryPoint deposit, AA24 remains), so the guard never actually deployed and AA24 could be a real bug OR a CDP/KMS harness artifact — undetermined. Added docs/test-manual/GRD-04-guard-write.md: a step-by-step real-device manual repro (register → create with dailyLimit → fund → first transfer/deploy → /guard write) with decision criteria (real-device success ⇒ harness artifact; real-device AA24 ⇒ real bug). User runs it + reports; results get filed back here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GRD — Guard-write e2e scaffold (fixme), reusing the proven S4 chain. The guard-write mechanism already ships in #362 (/guard page + GuardClient); this adds the e2e for it.
What's here (reusable)
e2e/guard.spec.ts(GRD-04): register(dailyLimit>0 → guard) → fund → deploy →/guardtoggle strict mode → assertstrictModeflips on-chain viaGuardClient.getConfig.registerAccount(page, {dailyLimit}),getGuardAddress/hasGuard/getStrictMode,deployAccount(page, address).Why fixme (two divergences a guard account shows vs a plain one — need debugging)
verificationGasLimit(~1.35M) seems to trip the bundler's balance/prefund view.Verification
Suite: 6 passed, 1 fixme-skipped (the other 5 L3 + GRD's scaffold compiles/lints). docs/TEST_RESULTS.md S4 documents the blockers.
Follow-up to make GRD pass: resolve the guard-account UI rendering + the deploy AA21 (likely route the guard-account deploy through the paymaster — gasless — instead of self-pay, sidestepping the prefund check).