[mashkovd]

Summary

Turns on the in-cluster pr-steward scheduler so it runs without a human prompting the live remote-control session (closes the manual-trigger gap, #276).

• Bump image.tag 0.2.5 → 0.4.0 (ships bin/pr-steward-precheck + the scheduler loop).
• Set PR_STEWARD_SCHEDULE_SECONDS: "1200" — a precheck-gated headless claude -p "Run the pr-steward skill" tick every 20 min.
• Widen the steward-log sidecar tail to also surface scheduler.log.
• Refresh the stale env comment (per-repo merge_mode + mctl-telegram scope; no RemoteTrigger dependency).

Cost safety

Each tick is gated by bin/pr-steward-precheck: it lists open PRs across the configured repos with the already-minted App token and only spawns the model run when an in-scope PR (per pr_filter) is not yet in a terminal steward:merged/:escalated state. Idle cadences therefore cost one GitHub API call, not Claude usage on the Max subscription. Each tick is timeout-wrapped (default 1800s) so a stuck turn can't wedge the loop.

Effect

The scheduler will pick up the configured scope — mctl-design (feat/agents-) and mctl-telegram (claude/, fix/, both when-green + squash). Open PRs #146/#147 should start getting ticked once the pod rolls to 0.4.0.

Test plan

• ArgoCD rolls labs-claude-remote to 0.4.0, pod Healthy, remote-control reconnects
• scheduler.log shows precheck output; a tick fires only when an in-scope PR exists
• Verify mctl-telegram MCP (escalation) is available to the headless claude -p run

[mashkovd]

@claude review

[claude]

Claude finished @mashkovd's task in 3m 11s —— View job

---

Code Review

• Read changed files and diff
• Analyze for correctness, security, and operational safety
• Post findings

---

The diff is a values-only change: image tag bump (0.3.0 → 0.4.0), one new env var, and an updated sidecar tail command. No logic, RBAC, or schema changes. No P1 or P2 findings.

Two minor observations (P3, non-blocking):

1. PR description version mismatch. The description says the tag bumps 0.2.5 → 0.4.0, but the diff shows 0.3.0 → 0.4.0. The values file is authoritative; the description is just inaccurate.

2. Tick timeout (1800 s) exceeds the schedule interval (1200 s). A tick that runs to its full timeout will still be alive when the next tick fires 20 min later. The tick_lock_stale_minutes: 15 guard limits the overlap window (a stuck tick holds the lock for only 15 min before the next tick can start), but it does mean two claude -p processes can run concurrently in a worst case. Worth keeping in mind when sizing the CPU limit if this becomes a pattern, though the current 1500m ceiling and the precheck gating make it unlikely to be a real problem in practice.

No P1/P2 findings — good to merge.