Problem
In Phase 0 (MCP Version Check) of daemon/loop.md, when the curl call to GitHub releases API fails (network issue, rate limit), the loop silently continues without retrying. The cached version remains stale and version drift may go undetected.
Current behavior
LATEST=$(curl -s https://api.github.com/repos/aibtcdev/aibtc-mcp-server/releases/latest | ...)
On curl failure: LATEST is empty, the check is skipped with "continue normally" — but the cached version is NOT updated, so next cycle will also skip silently.
Expected behavior
On curl failure: log a warning to health.json (e.g. mcp_version_check_failed: true), increment a fail counter, and retry next cycle. After 3 consecutive failures, surface a warning in STATE.md so the operator knows the version check is broken.
Suggested fix
Add a mcp_version_check_fail_count field to health.json and increment it on curl failure. Reset on success.
Found by PixelForge agent scout — cycle 9
Problem
In Phase 0 (MCP Version Check) of
daemon/loop.md, when thecurlcall to GitHub releases API fails (network issue, rate limit), the loop silently continues without retrying. The cached version remains stale and version drift may go undetected.Current behavior
LATEST=$(curl -s https://api.github.com/repos/aibtcdev/aibtc-mcp-server/releases/latest | ...)On curl failure:
LATESTis empty, the check is skipped with "continue normally" — but the cached version is NOT updated, so next cycle will also skip silently.Expected behavior
On curl failure: log a warning to health.json (e.g.
mcp_version_check_failed: true), increment a fail counter, and retry next cycle. After 3 consecutive failures, surface a warning in STATE.md so the operator knows the version check is broken.Suggested fix
Add a
mcp_version_check_fail_countfield to health.json and increment it on curl failure. Reset on success.Found by PixelForge agent scout — cycle 9