[Phase 6] Stale backstop for needs-info and weekly reporting #1207

Story

As a dev-lead,
I want shorten the stale window for outside PRs labelled needs-info and add a weekly report of auto-closed PRs and reopened false positives — both delivered via the vendored scripts/stale-manager.sh + its workflow in petry-projects/.github, so the change ships to every consumer on the next standards/v1-stable cut,
so that unanswered needs-info PRs are cleared promptly, and thresholds can be tuned from aggregate outcomes rather than per-close noise.

scripts/stale-manager.sh already lives in petry-projects/.github and is reached by consumers through the standards release channel for its callers (.github/workflows/stale-manager.yml for the host dogfood; equivalent reusable+stub for consumers if the agent is in the registry). The needs-info-specific knob is a config edit that rides standards/v1-stable on the next cut — no per-config tag.

Acceptance Criteria

1. scripts/stale-manager.sh closes outside PRs carrying the needs-info label (the Phase 3 reusable's label at the medium action) with no response after about 3 days — a shorter, configurable window than the default ~30-day PR staleness. The knob is NEEDS_INFO_STALE_DAYS (default 3), separate from STALE_DAYS_PR (default 30) and GRACE_DAYS (default 7); existing non-needs-info behavior is unchanged.
2. A weekly report surfaces the count of auto-closed spam PRs (from the spam-pr-guard reusable's high action) and the count/rate of reopened-after-close as the false-positive signal.
3. Reopen-after-auto-close is the trigger for a maintainer signal, aggregated rather than a per-close notification.
4. shellcheck scripts/stale-manager.sh passes, the relevant bats pass, and the change does not regress stale-manager's existing thresholds for non-needs-info items.
5. If the knob needs to be settable per-consumer, it is exposed as an input on the stale-manager reusable (if one exists; otherwise promoted from a bare env var to a workflow input in the reusable) and defaulted in standards/workflows/stale-manager.yml. The default change ships on the next scripts/cut-standards-release.sh cut.

Tasks / Subtasks

• Add a needs-info-specific short close window (NEEDS_INFO_STALE_DAYS) to scripts/stale-manager.sh without disturbing the general PR window (AC: Addressing PR comments #1, Add workflow, environment, and orchestration guidance #4)
• Add a weekly report of auto-closed count and reopened-after-close rate (AC: Add multi-agent isolation strategy using git worktrees #2)
• Make reopen-after-close the aggregate maintainer signal (no per-close notification) (AC: Add coding standards & principles section to AGENTS.md #3)
• Run shellcheck and bats and confirm no regression to existing thresholds (AC: Add workflow, environment, and orchestration guidance #4)
• Expose the knob at the stub level if consumers need to tune it per-repo (AC: Add stacked PR strategy and Epic-level workflow guidance #5)

Dev Notes

• scripts/stale-manager.sh already exposes STALE_DAYS_PR (default 30), GRACE_DAYS (default 7), and DRY_RUN staging via .github/workflows/stale-manager.yml (LIVE_MODE gate). Add NEEDS_INFO_STALE_DAYS as a new configurable var; do not change the general PR staleness for other items.
• The weekly report can follow the existing Class-3 weekly-report pattern (.github/workflows/token-report.yml, .github/workflows/reviewer-report.yml): scheduled off-peak at a non-round minute so validate-workflow-schedules passes.
• Per-close maintainer notification is discussion open Q2 — keep it aggregate; a reopen after auto-close is the misfire signal (enhancement answer to Q2).
• If scripts/stale-manager.sh later moves to a reusable+stub shape with its own canary rings, this short-window knob becomes a stub with: input and the needs-info semantics ride the stale-manager canary rather than the standards release. For today, it ships via the standards release channel because the config lives in the standards tree.

Project Structure Notes

Extends scripts/stale-manager.sh and its reporting; a weekly report workflow follows the Class-3 pattern. No change to the general stale thresholds. Config/defaults live in standards/ so they ride standards/v1-stable.

References

• scripts/stale-manager.sh
• .github/workflows/stale-manager.yml
• .github/workflows/token-report.yml, .github/workflows/reviewer-report.yml (Class-3 weekly-report prior art)
• standards/standards-versioning.md (how the knob default ships to consumers)
• docs/agentic-interaction-model.md
• Org standard for automatically handling spam / low-effort outside PRs #1198

Likely target surface

• scripts/stale-manager.sh
• .github/workflows/stale-manager.yml (or the stale-manager reusable + standards/workflows/stale-manager.yml stub if one exists)
• New .github/workflows/spam-pr-guard-weekly-report.yml (Class-3 weekly report)

Story prepared by the BMAD Scrum Master (Bob) for epic #1200. Realigned to the vendored-reusable + caller-stub + canary-rings shape — the needs-info knob ships via standards/v1-stable on the next cut. Status: ready-for-dev (blocked_by #1206 for the enable-at-high).