maintainer: local create->score->self-review iterate-loop orchestrator (the control-flow core)

[JSONbored]

This is the actual autonomous LOOP that Phase 3 exists to build: given a plan/acceptance-criteria packet (from Phase 2, out of scope here) and a resolved CodingAgentDriver, repeatedly invoke the driver, self-review the resulting diff against src/rules/predicted-gate.ts (the byte-identical predicted-gate target named as THE self-review target for an autonomous miner) plus the acceptance-criteria file, and DECIDE — autonomously, with no human in the loop at this stage — whether to keep iterating, stop and hand off to Phase 4 submission, or abandon the attempt. This decision logic is the precise chokepoint the fixed architecture skeleton's safety-tier system reserves for the owner: it is the trigger surface for "does the system keep trying, or does it eventually open a PR" without a human approving each step.

Tagged maintainer per this phase's explicit safety split: the driver seam, drivers, and harness primitives (all prior issues in this batch) are reviewable, no-autonomous-trigger contributor work; this orchestration control flow is not — it is adjacent to the #1 slop-at-scale strategic risk (an autonomous fleet maximizing gate-pass rate can mass-produce gate-passing-but-low-value PRs) and the owner has stated intent to build/review this personally.

Deliverables

• packages/gittensory-engine/src/miner/iterate-loop.ts implementing the create->score->self-review->decide control flow, consuming a CodingAgentDriver + the predicted-gate self-review target
• A bounded max-iteration/max-cost ceiling enforced INSIDE the loop itself (not left to an external caller to remember to enforce)
• Every iteration's decision (continue / stop-success / abandon) is recorded via the attempt-log primitive (from the wave-2 batch) so the decision trail is auditable after the fact
• Default behavior when the loop cannot conclusively determine pass/fail (e.g. self-review itself errors) is to ABANDON, never to optimistically hand off to submission — downgrade-only on ambiguity
• Owner-reviewed test coverage proving the loop never hands off to Phase 4 submission on a predicted-gate FAIL or an ambiguous self-review result

References

• /Users/shadowbook/Documents/gittensory/.claude/worktrees/quizzical-engelbart-34f3be/src/rules/predicted-gate.ts (263 lines) — the byte-identical self-review target this loop must consult every iteration; see especially buildPredictedGateVerdict's conclusion/blockers fields
• packages/gittensory-engine/src/miner/coding-agent-driver.ts, attempt-log.ts, acceptance-criteria.ts (all wave-2 primitives this loop composes, prior issues in this batch)
• User memory note "gittensory-miner-autonomy-roadmap": "the feat(docs): add install site and mcp diagnostics #1 slop-at-scale risk" and "never auto-submit (P4) before governor+caps (P5)" ordering rule — this issue is exactly that boundary, held to maintainer per the phase brief's explicit instruction

[linear-code]

JSO-2430