fix(ui): retry the prerequisite probe after a transient failure

[ashproto]

Addresses the P2 Codex flagged on #19 (the next → main promotion): a transient prerequisite-probe failure permanently disabled the safety gate.

Root cause: in the shared prerequisites singleton, probe()'s catch reset check to null but left loading holding the resolved promise. load() is guarded by if (!loading), so it became a no-op for the rest of the session — canEditHistory stayed true (history editing wrongly enabled), the warning banner stayed hidden, and nothing re-probed (refresh() is only called from the focus handler, which itself guarded on check).

Fix:

• prerequisites.svelte.ts — reset loading = null in the catch, so a later load() / refresh() actually re-probes.
• PrereqBanner.svelte — broadened the focus-refresh guard from check && !canEditHistory to !check || !canEditHistory, so a failed probe (check === null) also retries on window focus.

Once this merges to next, #19 will include the fix.

Testing: npm run check 0 errors · npm test 296 passed.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

git-it/src/lib/prerequisites.svelte.ts

Lines 33 to 35 in f8a1f3d

	get canEditHistory() {
	return check ? check.git && check.python3 && check.filterRepo : true;
	},

Keep history editing disabled after a failed probe

When the startup probe rejects, probe() resets check to null, and this getter consequently reports that history editing is available. Both initial callers share that failed request, and the only subsequent retry is the banner's window-focus listener, so a user who remains in the app sees no warning and can invoke the destructive rewrite despite prerequisites being unverified. Track probe failure separately or keep editing disabled until a successful check confirms availability.

---

git-it/src/lib/github/activity.ts

Lines 21 to 25 in f8a1f3d

	return (
	kind !== "NotFound" &&
	kind !== "NotAuthed" &&
	kind !== "NoRemote" &&
	kind !== "NotInstalled"

Stop retrying explicit rate-limit failures

A backend RateLimited error passes this predicate, so fetchActivityWithRetry repeats the same GitHub API call five times and delays the visible error by six seconds. An explicit rate limit will not normally clear within this fixed backoff, and the extra requests can prolong throttling; reserve these short retries for the cold-cache computing/parse case, or wait until the reported reset time.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ashproto]

Both P2s addressed:

• canEditHistory after a failed probe (09d26f9): added a probeFailed flag so editing stays disabled after a rejected probe — the getter was returning true for any null check, which included a failed probe, leaving the destructive rewrite reachable on unverified prerequisites. "Not probed yet" / non-Tauri stays optimistic (no flash of disabled); a later successful probe re-enables it.
• rate-limit retries (d39fb48): narrowed isRetryableActivityError to the transient cold-cache case only (Other/parse errors + non-GithubError blips). RateLimited, Forbidden, and the permanent kinds no longer retry — so an explicit rate limit surfaces immediately instead of being re-hit five times over ~6s.

Gate: npm run check 0 errors · npm test 296 pass (activity retry-policy tests updated).

[chatgpt-codex-connector]

💡 Codex Review

git-it/src/lib/prerequisites.svelte.ts

Lines 58 to 60 in d39fb48

	refresh() {
	loading = probe();
	return loading;

Serialize overlapping prerequisite refreshes

When a focus event calls refresh() while the initial probe or a prior refresh is still running, this unconditionally starts another probe, and both probes can update check and probeFailed. If the newer probe succeeds after prerequisites are installed but the older probe completes later with a failure or stale missing-tools result, the older response disables history editing again until another focus cycle. Reuse the in-flight promise or ignore results from superseded probes.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ashproto]

Fixed in dc01bb6. Added a monotonic probeSeq: each probe captures its id and commits check/probeFailed only if it is still the latest, so a superseded / out-of-order completion (an older failure landing after a newer success) is dropped instead of re-disabling editing.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: dc01bb6b1e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".