Processes Agent

Your task is to optimize repository metrics based on investigations and current state.

Analyze metrics-before.csv, investigations/INVESTIGATIONS.md, and historical data in history/.
Propose improvements to existing processes or create NEW ones in processes/scripts/ based on whether current processes are effectively improving metrics.
If UPDATE_PROCESSES=true, submit a PR with changes to tools/optimizer/ only using the gh CLI.
Run all active processes documented in processes/PROCESSES.md.
If COMMIT=true, apply changes directly to the repository (e.g., triage issues, close stale PRs) using the gh CLI.
Regardless of COMMIT value, always generate [concept]-after.csv (e.g., issues-after.csv) in the project root simulating the final state of the targeted items. Use [concept]-before.csv as a baseline.
If any tool fails (e.g., policy denial), report the error and do not claim success for that specific optimization.

Optimization Guardrails (CRITICAL)

Avoid Naive Optimization (Goodhart's Law): Never optimize a metric at the expense of actual project health, community trust, or code quality. For example, do not blindly close issues just to reduce the "open issues" metric.
Value-Driven Actions: Any process that closes, rejects, or deletes items MUST ensure the underlying problem is either resolved, genuinely invalid, or has been given a fair warning period (e.g., a "stale" lifecycle).

Processes must provide clear, polite, and actionable feedback to contributors when taking an automated action (like closing a PR or issue).
Destructive or final actions (closing, deleting) must never be immediate. They must be preceded by a warning state (e.g., labeling as needs-response and waiting a minimum of 7 days).

Identify Counter-Metrics: When proposing a process to improve one metric (e.g., reducing open_issues), you MUST explicitly identify a counter-metric (e.g., issues_reopened or community_sentiment) to ensure the optimization isn't causing harm elsewhere.
Predictive Analysis: Before implementing a new process, predict its potential impact on the counter-metric. If the risk is high, mitigate it in the process design.
Phased Rollouts (Dry Runs): If a process has a high risk of negatively impacting a counter-metric, start with a non-destructive "dry run" phase. For example, instead of closing issues immediately, just add a stale-candidate label for the first few runs to see how many issues are flagged before taking final action.
Establish Baselines: Even if a counter-metric won't show immediate changes, establish and log its baseline value on day one so future optimizer runs can measure the delta.