rules

Approved rules this org's last nightly compute_rule_staleness run flagged as past the staleness threshold — due for a human to confirm still true, or open a deprecation/refresh PR. Backs gnt stale.

A stopgap, not the final home for this: the eventual plan is to surface this prompt in a weekly digest email, which doesn't exist yet — it's waiting on that digest itself and on the nightly contradiction-sweep worker (workers/tasks_contradictions.py), which also needs to land first. This list is the same underlying signal, surfaced as CLI visibility instead — wire it into the digest once that email exists rather than building a second parallel version of it.

Registered before /{rule_id} in this file, but doesn't actually need to be — "staleness"/"due" are two path segments, "{rule_id}" matches exactly one, so there's no route collision to order around.

Renders the rule to markdown and opens a PR against the org's connected repo. This is approve's replacement — approval now means a human merging that PR on GitHub, not an in-terminal keypress (see docs/migration/RECONCILE_V2.md). The actual approved-status transition, including the HMAC-signed write and the previous-version supersede dance approve_rule used to do here, happens in the webhook handler once a real merge is confirmed — this endpoint only ever writes pending_merge, never approved, so none of that machinery belongs in this function anymore.

propose_rule's batched sibling — one branch, one put_file per rule, ONE pull request for the whole batch, and every rule in it moves to pending_merge together carrying the SAME prNumber/prUrl. Built for gnt prebrain's draft-rule output (5-8 related rules reviewed as one PR), but not restricted to that caller.

Validation fails the WHOLE batch with a clear error naming the offending rule(s) rather than silently skipping or partially processing — a batch is one reviewable unit; a caller that asked for 5 rules and silently got 3 proposed has no way to know that happened short of diffing IDs itself. Nothing GitHub-side happens until every rule in the batch has already passed validation.

Creates a new draft version of an approved rule. The old rule stays exactly as-is (still approved, still served) until the new version is itself approved — see approve_rule's supersede step.