fix(gstr3b): wait 5 s, then re-click once when the portal ignored the click

[lamemustafa]

Summary

Part of #386; the automatic re-click was approved by the owner on 2026-09-21.

A live "Everything last year" run measured GSTR-3B PDF captures as bimodal: 38 captured in 219–1549 ms (median 362 ms), and 8 produced nothing for the full 20 s, each needing a manual retry that then succeeded. The portal either answers the click almost at once or not at all, so a longer wait would not help.

Now:

• The first capture waits 5 s (more than 3× the slowest observed success).
• If it times out and the browser created no download from that tab, Pack clicks once more and waits 15 s. The total stays within the old 20 s.
• After a re-click, the step carries filed-gstr3b-capture-reclicked whether or not the second capture succeeds, so a review of a failed target can see that two clicks reached the portal. It is not added to the durable signal allowlist (that would widen what is persisted), so it appears on the step and in panel diagnostics but not in the saved ledger.

Root Cause / Decision Record

• Why a re-click is safe here, and not a "blind retry". AGENTS.md routes unknown, zero-byte, interrupted, ambiguous and unrelated downloads to review. This case has no download at all:
  • the safety net's new sawDownload() reports whether the browser created any blob download from the tab, and any download keeps today's path, with no re-click;
  • the capture re-verifies the page's financial year, period and return type before it clicks (hasExpectedTarget), so the second click cannot land on another target;
  • GSTR-3B PDFs are generated in the page (finding chore(deps): bump pnpm/action-setup from 4 to 6 #2), so a click has no server-side effect;
  • Known limitation, found in review and not yet guarded: the shim suppresses the portal's own blob save only while a capture is installed and bound to that exact blob URL. If the first click's blob arrives late, in the gap between the two captures or after the second capture has bound its own blob, the portal's save can run natively and leave an untracked duplicate GSTR-3B PDF in Downloads. It cannot mark a target complete, and it was not seen in 46 live captures, but it is possible. The owner chose to merge with this limitation on 2026-09-21; a guard (cancel a stray blob download from the tab after a re-click) is a possible follow-up.
• Only generation-timeout is re-clicked. control-not-found, page-period-mismatch, too-large and unexpected-content are not, and each is pinned.
• At most one re-click, pinned.
• GSTR-3B only. GSTR-1 Excel now stops early on its no-details dialog (fix(capture): stop waiting when the portal shows the GSTR-1 no-details dialog #390), and GSTR-1 and GSTR-2B PDFs showed no stalls in the same run (52 and 27 captures, ≤ 187 ms).

Scope

• Runtime: src/background/gstr3b-artifact-acquisition.ts (two named waits, one re-click); src/background/artifact-download.ts (sawDownload() on the existing safety net).
• Tests: tests/background/gstr3b-artifact-acquisition.test.ts (re-click keeps the file; at most once; none after a seen download; none for four other failure reasons; waits sum to ≤ 20 s).
• Docs/governance: none.
• Explicitly out of scope: why the portal ignores some clicks (not established); GSTR-2B dashboard loop (fix(gstr2b): reopen the Returns Dashboard instead of re-searching a stale page #391).

Live verification

Needed: the timing probe on the qualification build should show GSTR-3B stalls ending at about 5 s, followed by a capture.

Pack Workflow Preflight

• pnpm workflow:preflight was run before editing/push, or the skip reason is documented.
• This PR was opened from a Pack branch, not master.
• I checked latest master Pack AGENTS guidance or recorded the stale-guidance warning.
• PR body keeps the required Pack privacy/review/verification checklist visible.

Sanchika Adoption Gate

Not applicable: no Sanchika adoption.

• If this PR consumes @sanchika/* packages or copied Sanchika guidance, I
  read sanchika/docs/adoption-pack.md in the coordinated parent worktree.
• If this PR consumes Sanchika, it links ComplyEaze and Axal completion evidence
  and records the Sanchika commit or copied guidance used.
• This PR does not import ../sanchika, sanchika/packages/*/src, or parent
  source paths.

Privacy And Data-Flow Impact

• No new browser permissions.
• No new host permissions.
• No new network calls.
• No analytics, telemetry, ads, or session replay.
• No credential, OTP, CAPTCHA, cookie, token, GST file, or taxpayer-data capture.
• Public copy and privacy declarations are updated if behaviour changed — no user-facing copy changed.

Sensitive Surface Review

• Current tab / portal target binding is preserved or intentionally changed.
• Download completion remains evidence-backed and fail-closed.
• Ambiguous side-effect delivery cannot be reported as confirmed success.
• Service-worker durability impact is understood and documented.
• Real taxpayer data, local paths, raw URLs/referrers, and portal HTML are absent from the diff.

Chrome Web Store Impact

• This PR does not expand beyond the existing Chrome Web Store V0 listing unless every gate in docs/PUBLICATION_READINESS.md is checked.
• Full fiscal year remains source-only and excluded from the next packaged Store build until its evidence gates are recorded.
• Store copy, README status, Privacy QA, and reviewer instructions were reviewed if user-facing behavior changed — no user-facing copy changed.
• CI ZIP creation, provenance, and protected publishing are treated as release evidence, not manual store-submission sign-off.
• PR title uses Conventional Commits so Release Please can bump Pack after merge.

Verification

• pnpm install --frozen-lockfile
• pnpm audit --audit-level high
• pnpm exec wxt prepare
• pnpm exec prettier --check .
• pnpm exec eslint . --max-warnings 0
• pnpm exec tsc --noEmit
• pnpm exec vitest run
• pnpm exec wxt build
• node scripts/verify-extension-package.mjs .output/chrome-mv3
• pnpm exec wxt zip
• node scripts/verify-extension-zip.mjs
• node scripts/write-release-provenance.mjs
• node scripts/verify-github-release-assets.mjs --tag <tag> --zip <zip> --checksum <sha256> --provenance <json> when release assets exist
• node scripts/publish-chrome-web-store.mjs --zip .output/<zip> --provenance .output/pack-release-provenance.v1.json --publisher-id <id> --dry-run true
• git diff --check
• pnpm review:gate -- --strict-head-review --wait-head-review-ms 180000 before merge/readiness claim; a missing Codex review blocks readiness:

Artifact Evidence

• CI run:
• ZIP artifact:
• ZIP SHA-256:
• Clean source/tag or head SHA:

PR Review Follow-Up

• GitHub Actions completed.
• Autogenerated Codex/bot review comments inspected after checks completed for the latest head SHA.
• Inline review threads are resolved, outdated, or answered with evidence.
• No commits were pushed after the last required human/bot review without re-review.
• Any follow-up PRs or issues are listed here instead of being left implicit.

Thread/comment	Disposition	Commit or evidence
Local Sonnet review, Medium: a late first blob can become an untracked duplicate download (the PR body claimed it could not)	body corrected; owner accepted the limitation and asked to merge	see Root Cause
Local Sonnet review, Medium: sawDownload() sees only blob: downloads, so a server-URL download would not stop a re-click	accepted with evidence	GSTR-3B PDFs are generated in the page (finding #2), so the portal's save is always a blob
Local Sonnet review, Low/Medium: a failed re-click carried no trace of the second click	fixed	signal now added on failure too, pinned by the at-most-once test
Local Sonnet review: target re-bound before each click; no worker-restart path replays only the second click	confirmed

Screenshots

Use synthetic data only.

Verification detail

Exit codes captured directly: prettier 0 · eslint 0 · tsc 0 · build 0 · package verification 0 · git diff --check 0 · workflow preflight passed.

All tests related to the two changed modules: Test Files 18 passed (18), Tests 785 passed (785).

Driven to failure, each on its own: ignoring the seen-download guard fails the no-re-click-after-download test; re-clicking for any reason fails the four other-reason tests; removing the re-click fails the success and at-most-once tests.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.