fix: distinguish "no release yet" from "could not reach github" in --doctor

[iskyiskyisky]

Summary

• browser-harness --doctor prints (could not reach github) whenever GET /repos/.../releases/latest doesn't return a tag — including the common case where the repo has no releases yet (HTTP 404). The wording implies a network problem when the API is reachable and simply has nothing to report. Right now the repo has no releases published, so every doctor invocation shows the misleading message.
• Split the cases in _latest_release_tag by returning a (tag, reachable) pair. Doctor prints (no release published yet) when reachable, (could not reach github) only on genuine HTTP/network failure.
• Cache 404 responses the same way as successful ones so repeated --doctor calls don't re-hit the API within the 24h TTL.

Test plan

• rm /tmp/bu-version-cache.json && browser-harness --doctor — shows (no release published yet) against current repo state
• Cache written; subsequent runs reuse it for 24h
• Simulate genuine network failure — still prints (could not reach github) (unchanged path)

🤖 Generated with Claude Code

---

Summary by cubic

Fixes misleading “(could not reach github)” in browser-harness --doctor when a repo has no releases. Now shows “(no release published yet)” and caches 404s to avoid repeat API calls.

• Bug Fixes
  • _latest_release_tag now returns (tag, reachable) to distinguish no-release from network errors.
  • --doctor prints the correct status: shows the latest tag, “(no release published yet)”, or “(could not reach github)” on actual failure.
  • 404 responses are cached for 24h, same as successful responses.

^{Written for commit 2184fec. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="admin.py">

<violation number="1" location="admin.py:388">
P2: `check_for_update` drops the new `reachable` signal, so `run_update` misreports "could not reach github" when GitHub is reachable but has no releases.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}

[cubic-dev-ai]

P2: check_for_update drops the new reachable signal, so run_update misreports "could not reach github" when GitHub is reachable but has no releases.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At admin.py, line 388:

<comment>`check_for_update` drops the new `reachable` signal, so `run_update` misreports "could not reach github" when GitHub is reachable but has no releases.</comment>

<file context>
@@ -371,9 +382,10 @@ def _version_tuple(v):
+    and no cache exists, or if no release has been published yet."""
     cur = _version()
-    latest = _latest_release_tag()
+    latest, _ = _latest_release_tag()
     newer = bool(cur and latest and _version_tuple(latest) > _version_tuple(cur))
     return cur, latest, newer
</file context>