fix(impl-generate): scope the retry cap to the current campaign

[MarkusNeusinger]

Problem

impl-generate.yml budgets 3 generation attempts per library, counted from hidden marker comments on the spec issue:

MARKER="<!-- impl-fail:${SPEC_ID}:${LIBRARY} -->"
FAILURE_COUNT=$(gh api --paginate ".../issues/${ISSUE}/comments" ... )
if [ "$FAILURE_COUNT" -ge 2 ]; then   # → impl:<lib>:failed, no auto-retry

Nothing ever deletes those markers — grep -rn "impl-fail:" across the repo returns exactly one hit, the read. So the count spans the issue's entire lifetime, not the current run, even though the surrounding code says "Attempt N/3" and clearly means one campaign.

Consequences, all observed on 2026-08-24 during the library backfill:

1. A pair that ever failed twice gets one attempt on every future dispatch. Observed counts: chartjs/treemap-basic 4, plotnine/wireframe-3d-basic 4, ggplot2/network-force-directed **3`.
2. Generation has an intermittent failure where the agent exits "subtype":"success","is_error":false but writes no file — 8 of 85 generate runs that day (~9%). With budget left, the built-in auto-retry absorbs it (bubble-basic/highcharts: failed 17:55, retried and succeeded 18:02, no human involved). With the budget already spent by old history, one flake is terminal.
3. Terminal means terminal: impl:<lib>:failed has no recovery path — watchdog case 3 fires once and thereafter logs already retried by watchdog — needs manual attention (seen for issues [waffle-basic] Basic Waffle Chart #998, [network-force-directed] Basic Force-Directed Graph #990, [sankey-basic] Basic Sankey Diagram #810, [line-basic] Basic Line Plot #653).
4. Repo-wide, 87 (spec, library) pairs across 54 issues carry impl:*:failed. That is a measurable slice of the 1,237 missing implementations, and part of it is self-inflicted rather than never-attempted.

Three of the pairs written off this way succeeded on the very next manual dispatch.

Fix

Count only markers newer than a 12-hour campaign window:

CAMPAIGN_CUTOFF=$(date -u -d "${CAMPAIGN_WINDOW_H} hours ago" +%Y-%m-%dT%H:%M:%SZ)
--jq "[.[] | select(.body != null and (.body | contains(\"$MARKER\")) and .created_at > \"$CAMPAIGN_CUTOFF\")] | length"

A campaign runs well under an hour, so 12 h is generous for a stalled tail while stale history ages out on its own. Choosing a time window over deleting markers keeps the audit trail intact, needs no destructive writes to issues, and unblocks the existing 87 pairs without a migration.

The cap message now states what was actually counted — 2 failed attempt(s) in the last 12h (cap: 3 per campaign) instead of a flat 3 generation attempts printed after a single attempt. That wording is what led to two pairs being written off as capability gaps during the backfill before a retry proved otherwise.

Explicitly unchanged: the fail-closed path. An unreadable counter still sets FAILURE_COUNT=999 and disables auto-retry — the zero-fallback loop that flooded ~1,200 runs in 38 h (#1010) stays impossible.

Verification

• yaml.safe_load parses the workflow; the step's run: block extracted and checked with bash -n.
• jq filter exercised against a fixture with an old marker, a fresh marker, and a null body → returns 1 (the fresh one only), so neither the age filter nor the existing null-guard regressed.
• End-to-end behaviour is only observable on real pipeline runs (a documented no-verification-loop area in CLAUDE.md); the change is one filter clause plus a message.

Follow-up (not in this PR)

The 87 parked pairs need a re-dispatch sweep to actually recover — this PR only stops the trap from re-arming. That sweep is running separately.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RbZuWNDFy7kjXh9kLfA4dP

[Copilot]

🟡 Changes recommended

The updated cap message currently reports the pre-run failure count (off by one at the cap) and should reflect the attempt that just failed to avoid misleading operators.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR fixes the retry-cap accounting in the impl-generate GitHub Actions workflow so the “3 attempts” budget applies to the current generation campaign (recent failures only) rather than accumulating across the entire lifetime of a spec issue.

Changes:

• Scope failure-marker counting to a 12-hour campaign window when deciding whether to auto-retry or mark a library as failed.
• Update operator-facing messaging to report what was counted (failures + window) instead of implying three attempts were made.
• Add changelog entries documenting the retry-cap bug and the improved messaging.

File summaries

File	Description
CHANGELOG.md	Documents the campaign-scoped retry-cap fix and updated failure messaging.
.github/workflows/impl-generate.yml	Adds a campaign window cutoff to marker counting and adjusts failure-cap messaging.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[MarkusNeusinger]

Good catch — fixed in c0aa9ba. CAP_REASON now uses ATTEMPT (FAILURE_COUNT + 1), so the cap message counts the failure being handled: at the cap it reads 3 failed attempt(s) in the last 12h (cap: 3 per campaign) instead of 2. The whole point of the reworded message was to state a number an operator can trust, so an off-by-one there defeated it.

[Copilot]

🟢 Approval recommended

The change is narrowly scoped to the failure-count filter and messaging, preserves the existing fail-closed behavior, and matches the stated retry-cap intent without introducing risky workflow-side effects.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite