Decide AMS's own autonomy-level dial for iterate-policy.ts's decideNextAction

[JSONbored]

Problem

packages/loopover-engine/src/miner/iterate-policy.ts's own header documents an explicitly deferred design gap: decideNextAction (the policy governing whether an iteration continues, hands off for auto-submission, or abandons) is "autonomy-level-agnostic today." The header names the intended reusable primitive — src/settings/autonomy.ts's resolveAutonomy/isActingAutonomyLevel, the existing deny-by-default pattern ORB already uses to gate maintainer actions — but says wiring it in is "explicitly left to a later phase," pending .loopover-miner.yml defining autonomy fields that don't exist yet.

Verified current state: packages/loopover-engine/src/ams-policy-spec.ts (the type .loopover-miner.yml parses into) has no autonomy-level field today, and decideNextAction never consults src/settings/autonomy.ts in any form.

Area

packages/loopover-engine/src/miner/iterate-policy.ts (the policy), packages/loopover-engine/src/ams-policy-spec.ts (the config surface that would need a new field), src/settings/autonomy.ts (the existing pattern to reuse). Adjacent to the Miner Wave 5 / Rent-a-Loop per-tenant autonomy work (#4782 "Third-party autonomy & security governance spec", #4885 and siblings) and the general contributor-vs-maintainer write-action boundary this repo already treats as maintainer-reviewed-design-first.

Proposal

Decide what an autonomy-level field on MinerGoalSpec/.loopover-miner.yml should mean for the miner's OWN self-directed loop (as distinct from Rent-a-Loop's customer-facing autonomy dial, which is a separate, already-tracked design question under #4782/Wave 5 — this issue is scoped to AMS's own single-operator self-hosted loop, not the hosted multi-tenant product): what levels exist, what each gates (does a lower level force "abandon" instead of "handoff" regardless of a clean predicted-gate pass? does it cap iteration count or write-action scope?), and how decideNextAction should consult resolveAutonomy/isActingAutonomyLevel without breaking today's deny-by-default posture (a repo with no autonomy field configured must behave exactly as it does today — default-OFF, byte-identical, per this repo's own house convention for every new knob).

Deliverables

• A short ADR-style decision doc: the autonomy-level vocabulary for AMS's self-hosted loop, what each level actually gates in decideNextAction, and the .loopover-miner.yml/MinerGoalSpec field shape.
• Once decided, this can be decomposed into concrete contributor-eligible implementation sub-issues (the wiring itself, once the shape is fixed, is a clear-precedent mechanical task like most of Miner Wave 4's work) — do not decompose before this decision lands.

Resources

• packages/loopover-engine/src/miner/iterate-policy.ts (header's "AUTONOMY DIAL (not yet wired)" section, decideNextAction)
• src/settings/autonomy.ts (resolveAutonomy/isActingAutonomyLevel, the pattern to reuse)
• packages/loopover-engine/src/ams-policy-spec.ts (current config surface, no autonomy field yet)
• #4782 (Third-party autonomy & security governance spec — the adjacent but distinct Rent-a-Loop customer-facing question)

Boundaries

This is a maintainer design decision, not a contributor implementation task: it touches the loop's own autonomous-write-action boundary (a trust/safety-critical control the "what's safe to unleash" framework reserves for maintainer-reviewed design first) and requires picking a config-surface shape with no existing precedent to follow mechanically. Do not decompose into contributor-open sub-issues until this decision is made.

maintainer-only — planning/decision issue, not itself a build task.

[linear-code]

JSO-4152

[JSONbored]

Decided: selfLoopAutonomy on AmsPolicySpec (not MinerGoalSpec)

Correction to this issue's own framing first: the issue text (and iterate-policy.ts:18-21's own header) named .loopover-miner.yml/MinerGoalSpec as where the autonomy field should land. That's wrong. ams-policy-spec.ts:5-18 explains why: .loopover-miner.yml (miner-goal-spec.ts:9-14) is the target repo's own checked-in preferences file, while .loopover-ams.yml/AmsPolicySpec is the operator's own local execution-risk policy, deliberately kept out of the target repo's reach: "a target repo's own checked-in file ... must NEVER get to say 'let the operator's agent spend more budget' ... since that would let a malicious or compromised repo talk an operator's own miner into raising its own risk tolerance against that exact repo" (ams-policy-spec.ts:9-13). A dial that can turn a "pass" into "handoff" vs "abandon" is exactly that kind of risk-tolerance knob. It belongs alongside submissionMode/capLimits on AmsPolicySpec, resolved operator-locally (ams-policy-spec.ts:15-18), never in the target-controlled file.

Field

selfLoopAutonomy: AutonomyLevel on AmsPolicySpec (ams-policy-spec.ts:40-54), reusing the type imported the same way settings/autonomy.ts:1 does (from types/manifest-deps-types.ts:138). A normalizeSelfLoopAutonomy validator mirrors normalizeSubmissionMode (ams-policy-spec.ts:93-98), validated against AUTONOMY_LEVELS (settings/autonomy.ts:7) instead of a locally hardcoded set. Wired into cloneDefaultAmsPolicySpec, hasConfiguredPolicyFields (ams-policy-spec.ts:159-171), and parseAmsPolicySpec (ams-policy-spec.ts:196-212) — same pattern as every existing field.

Default: "auto", not "observe"

This is the one deliberate deviation from settings/autonomy.ts's own DEFAULT_AUTONOMY_LEVEL = "observe" (settings/autonomy.ts:18), and it's required, not optional. ORB's dial correctly defaults deny-by-default because it gates a capability with zero prior acting behavior. decideNextAction is the opposite: today, with no dial at all, a clean self-review pass already returns "handoff" unconditionally (iterate-policy.ts:154-156). Defaulting the new field to "observe" would silently flip every unset-field repo's behavior from "handoff" to "abandon" -- a real behavior change, violating this repo's own "byte-identical for any repo with the field unset" convention for new knobs. "auto" is the only default that reproduces today's code path exactly. Mirrored at the IterationState level: the new autonomyLevel?: AutonomyLevel | undefined field defaults to treated-as-"auto" when undefined, same precedent as costCeilingReached (iterate-policy.ts:71-77).

Levels and exact decideNextAction effect

The check narrows the existing step-3 branch ONLY (iterate-policy.ts:154-156), leaving rejectionSignaled (step 1) and ambiguous (step 2) untouched -- those stay absolute per the header's "wins over EVERYTHING" constraint (iterate-policy.ts:10-13):

• "auto" (default): unchanged -- pass -> "handoff".
• "auto_with_approval": pass still -> "handoff", but the decision gains a new optional requiresApproval: true field on IterateLoopDecision (iterate-policy.ts:111-118), mirroring autonomyRequiresApproval (settings/autonomy.ts:46-48). Additive-only. Not consumed downstream yet (Phase 4/submission doesn't exist -- iterate-policy.ts:90-91), so it's inert today by design, same as HandoffPacket itself.
• "observe": pass downgrades to "abandon" with a new AbandonReason variant "autonomy_observe_only" (extending iterate-policy.ts:30-38), with a reason string noting a clean pass WAS reached but the configured level keeps the loop observe-only.

Does it cap iteration count or write-action scope? No.

Single responsibility: this field only gates the pass->handoff transition. maxIterations/capLimits (ams-policy-spec.ts:45,49-50) remain the sole iteration/budget controls.

Next steps

This decision is being decomposed into two contributor-eligible implementation issues, filed as native GitHub sub-issues of this one (see the Sub-issues panel): (1) the AmsPolicySpec.selfLoopAutonomy config-schema addition, and (2) the decideNextAction consultation plus the caller wiring through iterate-loop.ts/attempt-input-builder.js (blocked by #1). Closing this issue -- its own deliverable, a decided design, is now satisfied.

[JSONbored]

Design decided (see comment above). Implementation filed as two contributor-open issues under this one.