Fix community loop watch stale receipt false reds

[Jonnyton]

Summary

• Make community_loop_watch fetch the required writer schedule event directly instead of relying only on the mixed recent-runs page, which can be flooded by issue-label events.
• Downgrade stale writer schedule freshness to yellow when a recent workflow_dispatch/issues success proves the writer workflow is still productive; stale scheduler freshness remains visible in details.
• Align queue classification with auto-fix discovery skip semantics: complete attempted issues are terminal, and await-primitive-layer attempted issues are deferred/yellow instead of stale-gate red.
• Classify attempted issues that already have linked open PRs as review/precheck waiting instead of writer-stuck red; keep attempted issues with no PR red.
• Downgrade stale tier3-broken alarm issues to yellow when the latest tier3 clone smoke run is a newer success than the open issues.
• Add regression tests for the live failure classes seen in community-loop watch runs 25533591057 and 2026-05-08T03:39Z local live checks.

Live evidence

Before this patch, the watch reported 42 stale attempted issues after the stale-gate label batch. The first patch reduced that false stale bucket to 18 by removing complete and await-primitive-layer skip/defer issues from the red stale class.

A second live check showed all remaining 18 stale-gate issues have linked open PRs (#598, #562, #565, #559, #552, #514, #513, #512, #511, #510, #509, #468, #561, #463, #448, #447, #560, #446). Running the patched watcher locally now reports the writer queue yellow: 18 attempted loop request(s) already have linked open PRs awaiting review/precheck; 1 PR(s) are ready_for_checker.

A third live check showed auto-fix-bug.yml scheduled success is stale, but recent issues success run 25533549650 proves the writer workflow is productive. The patched watcher reports Writer workflow yellow instead of red, preserving scheduler freshness drift in fallback_* details.

A fourth live check showed tier3 clone smoke latest run 25488453292 succeeded on 2026-05-07, newer than the newest open tier3-broken issue (#506 from 2026-05-06). The patched watcher reports tier3 yellow stale-alarm cleanup, not red current clone breakage.

After manually dispatching stale wiki-bug-sync.yml and uptime-canary.yml workflows, python scripts/community_loop_watch.py --json reports overall yellow: intake green, observation green, production deploy green, website deploy green; writer workflow yellow, writer queue yellow, tier3 yellow.

Verification

• python -m pytest tests/test_community_loop_watch.py — 26 passed
• python -m py_compile scripts/community_loop_watch.py tests/test_community_loop_watch.py — passed
• python -m ruff check scripts/community_loop_watch.py tests/test_community_loop_watch.py — passed
• python scripts/community_loop_watch.py --json — exit 0 / overall yellow with the live state above

Gate note

Codex-written PR. Needs Claude/Cowork checker review and explicit host merge key before merge.

[Jonnyton]

Codex update: I extended this PR after a fresh live watch check.

New behavior: attempted issues with linked open PRs are no longer treated as writer-stuck red. In live state, all 18 remaining stale-gate issues have linked open PRs, so the patched watcher reports Writer queue as yellow review/precheck waiting with stale_gate: [] and attempted_with_open_pr populated.

Focused verification:

• python -m pytest tests/test_community_loop_watch.py — 24 passed
• python -m py_compile scripts/community_loop_watch.py tests/test_community_loop_watch.py — passed
• python -m ruff check scripts/community_loop_watch.py tests/test_community_loop_watch.py — passed
• python scripts/community_loop_watch.py --json — overall still red due separate schedule/tier3 blockers; writer queue is now yellow instead of false red.

Still Codex-written; needs Claude/Cowork checker and explicit host merge key before merge.

[Jonnyton]

Codex follow-up on #677: added one more writer-health correction.

Live check at 2026-05-08T03:35Z showed auto-fix-bug.yml scheduled success is stale, but recent issues success run 25533549650 proves the writer workflow is still productive. The watcher now reports that as yellow scheduler-freshness drift instead of red writer-dead.

Current patched live result:

• Writer workflow: yellow (schedule stale, recent issues success)
• Writer queue: yellow (stale_gate: []; 18 attempted issues linked to open PRs)
• Overall: still red because wiki-bug-sync.yml, uptime-canary.yml, and tier3-broken remain real red blockers.

Verification rerun:

• python -m pytest tests/test_community_loop_watch.py — 25 passed
• python -m py_compile scripts/community_loop_watch.py tests/test_community_loop_watch.py — passed
• python -m ruff check scripts/community_loop_watch.py tests/test_community_loop_watch.py — passed

[Jonnyton]

Codex follow-up on #677: added tier3 recovery-aware classification.

Latest tier3 clone smoke run 25488453292 succeeded on 2026-05-07, newer than the newest open tier3-broken issue (#506 from 2026-05-06). The watcher now treats that as yellow stale-alarm cleanup rather than red current clone breakage.

After manually dispatching stale wiki-bug-sync.yml and uptime-canary.yml, patched live result is now overall: yellow / exit_code: 0:

• Intake sync: green
• Observation canary: green
• Writer workflow: yellow (schedule stale, recent issues success proves productive)
• Writer queue: yellow (18 attempted issues linked to open PRs; no stale_gate)
• Tier-3 clone smoke: yellow (latest tier3 success newer than open alarm issues)
• Production deploy / website deploy: green

Verification rerun:

• python -m pytest tests/test_community_loop_watch.py — 26 passed
• python -m py_compile scripts/community_loop_watch.py tests/test_community_loop_watch.py — passed
• python -m ruff check scripts/community_loop_watch.py tests/test_community_loop_watch.py — passed
• python scripts/community_loop_watch.py --json — exit 0 / overall yellow

[Jonnyton]

Codex coordination relay: the live brain now has Cowork checker-key YES on this PR: pages/notes/cowork-checker-key-pr677-loop-watch-false-red-fix-2026-05-08.md.

Cowork's substantive review accepts the five patch elements: direct schedule-event fetch, stale-schedule yellow fallback when recent writer success exists, terminal/deferred issue classification, linked-open-PR attempted issues as review/precheck yellow, and tier3 stale-alarm yellow after newer smoke success.

Current state from the #677 branch: python scripts/community_loop_watch.py --json exits 0 / overall yellow at 2026-05-08T03:43:50Z. No Codex checker key is needed here because this is Codex-written. Remaining gate is explicit host third-key before merge.