fix(ci): raise max_turns to 100 so weekly maintenance can finish

[bamr87]

Problem

Queue candidate 2: bamr87/githubai · .github/workflows/claude-maintenance.yml · signal failing.

The weekly scheduled run fails. Recent history:

run	date	conclusion
34092704491	2026-09-07	failure
33365833613	2026-08-31	success
32697595057	2026-08-24	success
32001887424	2026-08-17	failure
31363214609	2026-08-10	failure

The two clusters are different bugs. The July–August failures were auth:

Action failed with error: Environment variable validation failed:
  - Either ANTHROPIC_API_KEY, CLAUDE_CODE_OAUTH_TOKEN, or workload identity
    federation ... is required when using direct Anthropic API.

That was fixed — Aug 24 and Aug 31 went green. The current failure is unrelated and new.

Root cause

Run 34092704491, step Run maintenance with Claude, after 8m17s:

Claude reported a successful result after 68 turns, exceeding the configured maximum of 60
Action failed with error: Claude reported a successful result after 68 turns, exceeding the configured maximum of 60
Process completed with exit code 1

The agent finished its work and reported success. claude-code-action then failed the run solely because 68 > the --max-turns 60 it was launched with, so a completed maintenance pass was thrown away and reported red.

The cap traces back to .github/githubai.yml:

claude:
  max_turns: 60          # -> steps.cfg.outputs.max_turns -> --max-turns

This is not an agent that ran away. claude-maintenance.yml drives five tasks in a single invocation — docs_drift, todo_sweep, dependency_report, stale_nudge, health_report — each costing several gh / Grep / Read round trips, plus the mandatory dedupe search before filing anything. As the repo grew, that workload crossed 60 turns. 68 for five tasks is proportionate; the cap simply sits below the job's real cost.

Fix

Raise this repo's own cap to 100 in .github/githubai.yml — 47% headroom over the observed 68, so ordinary growth does not re-break it next quarter.

Deliberately not changed:

• profiles/_base.yml (max_turns: 50) and template/githubai.yml — these are the framework's public API for consuming repos. This failure is about this repo's own workload, so the override belongs in this repo's config, not in the defaults every consumer inherits.
• The workflow file itself. claude.max_turns is a single repo-wide scalar consumed by all five claude-*.yml workflows; there is no per-task override in load-config, so the repo config is the correct and only knob.

No continue-on-error, no retry: the run failed for a real reason and the reason is being removed.

Expected impact

• Weekly maintenance completes and its findings reach issues/PRs instead of being discarded at turn 61.
• Cost is bounded by timeout-minutes: 45, which is untouched and remains the real backstop — the 68-turn run took 8m17s, so even 100 turns lands around 12 minutes, well inside it.
• Removes one workflow from the fleet's 28 standing failures.

Verification

Config-only change; the value flows through actions/load-config unmodified (load_config.py:245 writes claude.max_turns straight to the output). tests/test_load_config.py already covers repo-config override of claude.max_turns. The real proof is the next scheduled run (cron: 17 6 * * 1) or a workflow_dispatch; worth dispatching once from this branch rather than waiting a week.

Links

• Failing run: https://github.com/bamr87/githubai/actions/runs/34092704491
• Prior (distinct, fixed) auth failure: https://github.com/bamr87/githubai/actions/runs/32001887424
• Dash: /actions/

[claude]

Verdict: no blockers, no important issues — sound, self-contained config fix.

Findings: 0 blocker, 0 important, 1 nit.

• [nit] .github/githubai.yml:16-24 — claude.max_turns is a single repo-wide scalar consumed by all five claude-*.yml workflows (triage/implement/review/maintenance/release), so this bump raises the ceiling for all of them, not just the maintenance job that actually needed it. The PR body explicitly acknowledges this and explains why a per-task override isn't available in load-config today — reasonable given the constraint, just flagging it as a side effect worth remembering if a different workflow starts running long for the wrong reasons.

What I checked from the review focus list:

• Consumer-facing compatibility: not touched — only .github/githubai.yml (this repo's own dogfood config) changes; profiles/_base.yml (max_turns: 50) and template/githubai.yml (public API/defaults) are untouched, so no consumer-facing schema or default change.
• Self-containment of template/: N/A, no files under template/ changed.
• Least-privilege / untrusted-input handling: N/A, no workflow permissions or run:/prompt content changed.
• Installer/docs sync: not required — this is a value change to this repo's own config instance, not a schema key or workflow input, so setup/install.sh, docs/workflows.md, and docs/configuration.md don't need updates.
• Test coverage: adequate — tests/test_load_config.py already covers repo-config override of claude.max_turns generically (fixture uses max_turns: 7); this is a value bump, not new logic, so no new test is needed. gh pr checks shows tests, shell, and relay passing.

Semver classification: patch (internal/operational change to this repo's own dogfooding config; no public API — workflow names, inputs, schema keys, or template paths — is touched).

Note: this PR was already merged (40faa4d) by the time of this review; findings above are for the record.