[FEATURE] Foreman: first-class review-feedback revision cycles (revise from prior branch, review-as-spec, revision-tuned profile)

[Defilan]

Feature Description

First-class review-feedback revision cycles: when a reviewer returns REQUEST-CHANGES (or a maintainer supplies review findings), Foreman should spawn a follow-up coder task that starts FROM the prior attempt's branch with the review as its spec, instead of requiring a hand-authored Pipeline Workload per round.

Problem Statement

Today the loop from review back to code is manual. It works (validated live: a maintainer REQUEST-CHANGES review with 6 findings was hand-packed into a Pipeline Workload's payload.prompt and converged to GO + GATE-PASS on the third round), but the manual orchestration surfaced three problems the feature should own:

1. Branch restore does not belong in the prompt. Round 1 asked the model to git fetch + git checkout its prior work via bash; the multi-step restore collided with the stuck-loop forcing window (bash was disabled mid-restore) and the task died at turn 7. The executor owns git everywhere else; it should own this too.
2. Forcing profiles are task-shape dependent. Round 2 fixed the restore (single mandated first command, worked) but died anyway: the issue-fix ModelProfile's editFreeTurnsLimit: 4 cannot hold a restore plus the source-verification reads a review demands, and the model collapsed under the nudge (degenerate str_replace("placeholder","placeholder") x3). A revision-tuned profile (editFreeTurnsLimit: 12, verification-oriented addendum) converged in round 3. A revision task dispatched with an issue-fix forcing profile is a config bug the controller can prevent.
3. Per-round Workload authoring is boilerplate. Rounds differ only in prompt text and branch names.

As an operator running local-model coder fleets, I want review feedback to flow back into a bounded revision loop natively, so that REQUEST-CHANGES converges to a mergeable branch without hand-authored Workloads per round.

Proposed Solution

Sketch, open to design review:

• Payload: add reviseFromBranch to AgenticTaskPayload. On an issue-fix task, the executor creates the working branch FROM that ref (fetched from the fork remote) instead of from baseBranch, so the prior attempt's files are simply present. No prompt-driven git.
• Review-as-spec: keep the existing semantics where a non-empty payload.prompt suppresses the lazy issue-body fetch; the revision prompt is the review findings (each item ideally citing the source file that proves the correct answer).
• Profile pairing: allow the revision path to select a revision-tuned Agent or ModelProfile (e.g. Workload.spec.revisionAgentRef, or a revisionModelProfileRef on the Agent). The controller rejects or warns when a revision task would run under an issue-fix forcing profile.
• Controller loop: when a reviewer task on an issue returns REQUEST-CHANGES/NO-GO with structured findings, the WorkloadReconciler emits one revision code+verify pair (findings -> prompt, prior branch -> reviseFromBranch), bounded by a maxRevisionRounds cap (default 1-2). The verdict-triggered fan-out pattern already exists in the escalation-reviewer tier.

Alternatives Considered

• Keep hand-authored Pipeline Workloads per round (status quo): works, validated, but repeats the three failure modes above for every operator who discovers them the hard way.
• Prompt-only restore (no reviseFromBranch): empirically fragile under forcing windows (round 1), and makes the executor's "owns git" invariant leaky.

Additional Context

Live validation trail (2026-07-02): revision rounds r1/r2/r3 on issue #478; round 3 delivered GO + GATE-PASS with 5.5 of 6 review findings verified landed. Related: #944 (no-anchor feedback), #945 (workspace-absolute paths), both filed from the same runs. The escalation-reviewer tier (#546) provides the verdict-triggered fan-out precedent.