Investigate + design config-as-code for ops / sweep_watchdog / pr_reconciliation

[JSONbored]

Part of #4092. Depends on the core resolver issue (config-as-code resolver) only if per-repo scoping turns out to apply.

Problem — this is a design question, not a known gap

GITTENSORY_REVIEW_OPS (src/review/ops-wire.ts), GITTENSORY_SWEEP_WATCHDOG, and GITTENSORY_PR_RECONCILIATION gate BACKGROUND/OBSERVABILITY jobs (anomaly scans over the whole review-outcome ledger, stale-sweep liveness checks, open-PR reconciliation) — not per-PR review behavior tied to one repo's PR. Unlike every other sub-issue in this epic, it's genuinely unclear whether "per-repo config-as-code" is the right shape here at all, or whether these remain closer to instance-level "bare necessity" toggles the mandate explicitly carves out.

Requirements

• For each of the three: determine whether ANY meaningful per-repo behavior exists today (e.g. does the ops anomaly scan already iterate per-repo internally? does sweep-watchdog/PR-reconciliation operate per-registered-repo?) — if so, a per-repo config opt-out ("exclude repo X from this scan") may be a real, useful feature, not just theoretical compliance with the mandate
• If genuinely global/instance-level with no meaningful per-repo axis: document that finding explicitly and propose these stay env-var-gated as legitimate "bare necessity" instance configuration, closing this issue with that written conclusion rather than forcing an artificial per-repo config that adds complexity with no real use case
• Either way, write up the reasoning so the epic has a definitive answer instead of leaving these three ambiguous

Deliverables

• Written investigation + decision for each of the 3 flags
• If a per-repo config makes sense for any of them: implement it using the shared resolver + tests
• If not: explicit sign-off that these stay env-var-only, with the reasoning recorded (in the issue/PR, and worth folding into Epic: config-as-code should fully control every review feature, not just restrict it #4092's own description once decided)

Expected outcome

A definitive, reasoned answer for whether/how config-as-code applies to background observability jobs, rather than leaving it unaddressed.

Effort

S (investigation) to M (implementation, only if warranted).

[linear-code]

JSO-3156

[JSONbored]

Closing as investigated, no code change warranted — GITTENSORY_REVIEW_OPS/GITTENSORY_SWEEP_WATCHDOG/GITTENSORY_PR_RECONCILIATION keep their current shape. Unlike #4107 (no per-repo axis at all), all three background jobs do iterate per-repo internally — but the meaningful per-repo axis is already config-as-code today, through a different, already-shipped lever, and migrating them onto feature-activation.ts's features: resolver would be a net regression, not a consistency win.

Confirmed: all three iterate a per-repo scan set, built from existing per-repo signals

• opsScanRepos (src/review/ops-wire.ts:151-165): filters listRepositories to isRegistered, then prefers the subset with isAgentConfigured(settings.autonomy) (via resolveRepositorySettings); falls back to every registered repo only when no repo anywhere is agent-configured.
• watchedRepos in both src/review/sweep-watchdog.ts:44-66 and src/review/pr-reconciliation.ts:31-53 (identical shape, doc-commented as deliberately mirroring each other): a repo is watched when isConvergenceRepoAllowed(env, repo) || isAgentConfigured(settings.autonomy).

So the per-repo axis is real, not theoretical — confirmed by reading the actual call sites, not just the isXEnabled() flag definitions.

Why that axis is already config-as-code, and adding features.ops/.sweepWatchdog/.prReconciliation would be redundant-at-best:

isAgentConfigured reads settings.autonomy, and autonomy is already a fully .gittensory.yml-driven per-repo field — FocusManifestSettings picks "autonomy" straight out of RepositorySettings (packages/gittensory-engine/src/focus-manifest.ts:290, parsed via normalizeAutonomyPolicy at :1557-1559), documented in both .gittensory.yml.example and config/examples/gittensory.full.yml (settings.autonomy: {} — the autonomy dial, settings: block, no env var, no redeploy). resolveRepositorySettings layers that manifest value over the DB dashboard setting, exactly the "config-as-code, no redeploy" outcome this epic wants. Every one of these three modules' own doc comments already say this in different words ("the SAME acting-autonomy repo set the scheduled regate sweep covers," env.d.ts:244-249) — the per-repo lever the epic is asking for has existed since #773 and all three background jobs already consult it.

Net effect today: a repo that configures zero acting autonomy classes already drops out of the isAgentConfigured arm for all three jobs, purely through .gittensory.yml, no env var involved — for ops specifically it's excluded outright whenever any other repo is agent-configured (the fallback-to-everyone path only fires when the signal is unavailable fleet-wide).

Why the remaining gap (GITTENSORY_REVIEW_REPOS) should stay operator-only, not become a repo self-service override:

The one input NOT yet yml-driven is the GITTENSORY_REVIEW_REPOS allowlist (isConvergenceRepoAllowed, src/review/cutover-gate.ts) — env-var-only by explicit design ("a comma-separated allowlist... DEFAULT IS NO REPOS," cutover-gate.ts:7-13), an operator-controlled fleet-wide cutover switch. Plugging these three into resolveConvergedFeature's existing precedence would mean a repo's own features: override could force itself in (true widens inclusion beyond today's default, same as it does for rag/reputation/safety/unifiedComment) — but for these three jobs that inclusion isn't "run this feature over my own PR," it's "spend the operator's shared, fleet-wide GitHub API budget re-enqueuing sweeps / catching up PRs for me." Both sweep-watchdog.ts and pr-reconciliation.ts already reason explicitly about not wasting "the shared GITHUB_PUBLIC_TOKEN budget" on repos that can't benefit (the uninstalled-repo skip); a self-installed GitHub App is very commonly one installationId shared across every repo in an org, so one repo opting itself into extra scanning spends budget the other repos on that same installation also depend on. Letting a repo-writable, lower-trust file (per the safety force-on-only asymmetry precedent, #2269) grant itself that is a worse trust boundary than today's operator-only allowlist, not an improvement — the same "wrong bucket, not just unbuilt" conclusion #4107 reached for the draft flow, for a related but distinct reason (there it was "no repo in the request path at all"; here it's "the repo in scope shouldn't get to spend a shared budget on its own say-so").

Decision: GITTENSORY_REVIEW_OPS, GITTENSORY_SWEEP_WATCHDOG, and GITTENSORY_PR_RECONCILIATION stay env-var-gated master switches. Their per-repo scan-set selection stays exactly as it is (isAgentConfigured — already .gittensory.yml-driven via settings.autonomy — OR'd/preferred against the operator-only GITTENSORY_REVIEW_REPOS allowlist). No migration onto feature-activation.ts's resolver; no new features.* keys added. No code change made.

If a genuine future need shows up for "exclude this one already-autonomy-configured repo from just the background scan, while keeping its normal autonomy," that's a small, separate, opt-out-only follow-up (can't reuse resolveConvergedFeature as-is since its override is bidirectional) — not warranted speculatively today.

See #4092 for the epic.