Design: default starting autonomy/quality-gate baseline for zero-history projects (APR + never-configured BYOR repos)

[JSONbored]

Problem

applySelfTuneOverrideToSettings (src/settings/repository-settings.ts:20-30) can only ever raise an existing qualityGateMinScore — by design it refuses to create one where none exists ("a repo with no readiness threshold keeps none, respecting the operator's choice"). That's the right call for BYOR, where a human operator sets the initial .loopover.yml baseline themselves. It leaves a real gap for APR: an APR project has no operator to set that baseline, ever — so this isn't an edge case for APR, it's the default case. Every APR project starts with literally nothing for the existing tightening-only self-tune loop to act on.

Area

Product spec / platform. Directly triggered by #7591 (APR completion signal), but the gap applies just as much to any BYOR repo that was installed but never had its .loopover.yml configured — not APR-specific plumbing.

Proposal

Define a conservative default starting baseline — autonomy level per action class, and optionally a starting qualityGateMinScore — for any project with no operator-configured settings. This is the "indexing period" concept: a defined observation window with a deliberately conservative floor, so the existing soak-then-promote self-tune loop has a real starting point to tighten from, rather than either (a) silently inventing a permissive default that was never chosen by anyone, or (b) leaving APR permanently unable to benefit from the self-tune mechanism at all. Keep the system's existing deny-by-default philosophy (DEFAULT_AUTONOMY_LEVEL = "observe", autonomy.ts:18) as the honest starting point rather than pre-authorizing anything.

Deliverables

• A written decision: the default starting autonomy level per action class for a zero-history project, whether a starting qualityGateMinScore is set at all (and if so, what informs its value), and what evidence/duration constitutes the "indexing period" before self-tune's promote logic is trusted to act on it.

Resources

• src/settings/repository-settings.ts:20-30 (the tightening-only mechanism this needs to feed)
• packages/loopover-engine/src/settings/autonomy.ts (the dial, deny-by-default default)
• Design spec: idea-completion determination + customer-facing status for APR (no GitHub UI exposure) #7591 (APR completion — the direct trigger for this issue)
• The new audit issue (linked, informs this decision with real data before it's made)

Boundaries

Spec-level only — no change to the tightening-only self-tune contract itself, that stays as-is; only the cold-start default is in scope. No reward/pricing figures.

maintainer-only — this sets the gate's own merge/close authority defaults, a trust/safety-critical decision, not a build task.

[linear-code]

JSO-5379

[JSONbored]

Decided (2026-07-20): default a zero-history project (every APR project, plus any BYOR repo that never configured .loopover.yml) to the system's existing deny-by-default floor — every action class at observe (DEFAULT_AUTONOMY_LEVEL, packages/loopover-engine/src/settings/autonomy.ts:18), no invented qualityGateMinScore. This doesn't require the real unset-population percentage to be defensible: deny-by-default is already this codebase's consistent convention everywhere else (the autonomy dial, the self-tune loop's own refusal to invent a threshold, gittensor-wire.ts's plugin gating) — there's no principled reason a zero-history project should start more permissively than that. The "indexing period" is simply: stay at observe until an operator (or, for APR, the customer via the loopover dashboard once built) explicitly raises it, exactly like every other repo in the system today.

Note: #7596/#7598's audit script landed but its findings were never posted here as intended — the real unset-population number is still worth having for future tuning, but doesn't block this decision, which holds regardless of what that number turns out to be.

Closing — the decision itself was this issue's deliverable.