safety(merge-frontier): bind the real merge adapter to a ready merge_actuation verdict + D20-lint carve + D-decision, before any merge call lands #171

New issue

Closed

opened 2026-06-24 01:49:13 +02:00 by claude · 1 comment

claude commented

2026-06-24 01:49:13 +02:00

Collaborator

Context — the decision layer just landed, the actuator is next

#170 shipped merge_actuation.py as a read-only preflight: it emits controller_may_merge + allowed_action: "merge_pull_request" as a verdict (reusing the full controller_approval_actuation_blockers stack — no-self-approval, hard-manual, head-bound, zero-blocker — plus visible_actor and live-state), but it does not call Forgejo merge. The D20 lint is intact: merge_pull_request( (call) and raw /merge URLs are still build-time-banned. 👏

This is the merge-frontier equivalent of the read-only contract chain. The next PR — the adapter that performs an actual Forgejo merge — is the single most dangerous change in the repo's history. This issue pre-states its contract (the merge counterpart of #127, which did this for the approval actuator) so it can't land decoupled or unguarded.

This is operator-gated by design — it needs a D-decision first

Crossing the build-time merge ban is not an autonomous step. Before the merge adapter is built it needs an explicit operator decision (a D29-style record), analogous to D24/D26 for approval, specifying:

whether to authorize a real merge actuator now (vs. stay verdict-only and let an external controller merge);
scope: dry-run-first? which PR classes? trust-tier conservative only? pdurlej/platform before openclaw?
identity: does the merge run under an external controller (ClawSweeper/OpenClaw) per D26 steady-state, or transitionally under patchwarden (a deliberate, recorded choice like D26's visible_actor)?

Definition-of-done for the merge-adapter PR (inspiration, not spec)

Structural binding: the adapter consumes a ready merge_actuation verdict (#170) as a required precondition input — unknown / blocked / needs_live_state / missing → no merge (fail-closed). It must not re-derive eligibility ad-hoc.
D20-lint carve, not weakening: update test_d20_architectural_boundary to permit merge_pull_request( only inside the one designated merge adapter (exactly how the lint already confines ensure_pr_approval/create_pr_review to contract_publish.py), and keep banning it — and raw /merge URLs — everywhere else. The carve must be a named single call site, never a blanket lift.
Drift-guard (sibling to the approval guard): prove the merge call is unreachable without a ready merge_actuation verdict; assert the verdict carried no-self-approval, non-hard-manual, head-bound, and visible-actor checks.
Live-head at actuation: re-fetch live PR head immediately before merge; head != verdict.target_sha or fetch-fail → refuse (don't merge a moved head).
Fail-closed everywhere; opt-in flag (default off), like --approve-on-pass.

Why now

#170 (preflight) makes the actuator imminent. Pre-stating the contract is cheaper than catching a decoupled merge in review after the live merge surface exists. Refs #170, #127 (approval precedent), #121/#129 (the guard stack), D20/D24/D26. — claude (architect loop)

## Context — the decision layer just landed, the actuator is next #170 shipped `merge_actuation.py` as a **read-only preflight**: it emits `controller_may_merge` + `allowed_action: "merge_pull_request"` as a *verdict* (reusing the full `controller_approval_actuation_blockers` stack — no-self-approval, hard-manual, head-bound, zero-blocker — plus visible_actor and live-state), but it **does not call Forgejo merge**. The D20 lint is intact: `merge_pull_request(` (call) and raw `/merge` URLs are still build-time-banned. 👏 This is the merge-frontier equivalent of the read-only contract chain. The **next** PR — the adapter that performs an *actual* Forgejo merge — is the single most dangerous change in the repo's history. This issue pre-states its contract (the merge counterpart of #127, which did this for the approval actuator) so it can't land decoupled or unguarded. ## This is operator-gated by design — it needs a D-decision first Crossing the build-time merge ban is not an autonomous step. Before the merge adapter is built it needs an explicit operator decision (a **D29**-style record), analogous to D24/D26 for approval, specifying: - **whether** to authorize a real merge actuator now (vs. stay verdict-only and let an external controller merge); - **scope**: dry-run-first? which PR classes? trust-tier `conservative` only? `pdurlej/platform` before `openclaw`? - **identity**: does the merge run under an external controller (ClawSweeper/OpenClaw) per D26 steady-state, or transitionally under `patchwarden` (a deliberate, recorded choice like D26's `visible_actor`)? ## Definition-of-done for the merge-adapter PR (inspiration, not spec) 1. **Structural binding**: the adapter consumes a **ready** `merge_actuation` verdict (#170) as a *required precondition input* — unknown / blocked / `needs_live_state` / missing → no merge (fail-closed). It must not re-derive eligibility ad-hoc. 2. **D20-lint carve, not weakening**: update `test_d20_architectural_boundary` to permit `merge_pull_request(` **only** inside the one designated merge adapter (exactly how the lint already confines `ensure_pr_approval`/`create_pr_review` to `contract_publish.py`), and keep banning it — and raw `/merge` URLs — everywhere else. The carve must be a *named single call site*, never a blanket lift. 3. **Drift-guard** (sibling to the approval guard): prove the merge call is **unreachable** without a ready `merge_actuation` verdict; assert the verdict carried no-self-approval, non-hard-manual, head-bound, and visible-actor checks. 4. **Live-head at actuation**: re-fetch live PR head immediately before merge; `head != verdict.target_sha` or fetch-fail → refuse (don't merge a moved head). 5. **Fail-closed everywhere**; opt-in flag (default off), like `--approve-on-pass`. ## Why now #170 (preflight) makes the actuator imminent. Pre-stating the contract is cheaper than catching a decoupled merge in review after the live merge surface exists. Refs #170, #127 (approval precedent), #121/#129 (the guard stack), D20/D24/D26. — claude (architect loop)

claude added the

area:v0-core

judge/codex-candidate

labels

2026-06-24 01:49:13 +02:00

codex referenced this issue from a pull request that will close it,

2026-06-24 02:02:30 +02:00

feat: add merge frontier decision gate #173

pdurlej closed this issue

2026-06-24 02:05:18 +02:00

claude commented

2026-06-24 04:32:42 +02:00

Author

Collaborator

Architect update (loop) — the build is converging on "external actuator", which may make the D20-lint carve moot

Since filing this, codex shipped the full read-only authorization chain: merge_actuation preflight (#170) → controller_bundle (#172) → merge_frontier_decision operator-gate (#173, fail-closed to operator_required) → dry-run rehearsal/receipt (#181/#182) → controller_live_authorization preflight (#183) → live receipts wired into action-receipt/loop-state (#184/#185).

Crucially, controller_live_authorization emits live_controller_may_execute as a verdict — it does not merge. It requires an operator live_authorized merge-frontier decision + a dry-run receipt + patchwarden_write_allowed=false / external_write_allowed=false. So the design is settling on: Patchwarden stays verdict-only permanently; the actual Forgejo merge is performed by the external controller (ClawSweeper/OpenClaw) under its own identity (D26).

Implication for this issue's DoD item #2 (the D20-lint carve): if Patchwarden never grows a merge adapter (the actuator is wholly external), then the lint's merge_pull_request( ban should stay permanent — never carved. The "merge adapter" framing here was the in-Patchwarden path; the architecture is choosing the safer external-actuator path instead. The remaining DoD items still apply, but to the external controller's consumption of the live-authorization verdict, not to a Patchwarden call site:

bind the external merge to a ready controller_live_authorization verdict (not re-derive),
live-head recheck at actuation,
no-self-approval / non-hard-manual / head-bound carried by the verdict,
dry-run-first (already enforced by #183 requiring a dry-run receipt).

So the operator's "authorize the merge actuator" decision is really "wire the external controller" + the D26 identity choice — not "build/carve a Patchwarden merge call." Keeping this issue open as the contract the external actuator must honor; the D20-lint stays as-is (permanent ban). — claude (architect loop)

## Architect update (loop) — the build is converging on "external actuator", which may make the D20-lint carve moot Since filing this, codex shipped the full read-only authorization chain: `merge_actuation` preflight (#170) → `controller_bundle` (#172) → `merge_frontier_decision` operator-gate (#173, fail-closed to `operator_required`) → dry-run rehearsal/receipt (#181/#182) → `controller_live_authorization` preflight (#183) → live receipts wired into action-receipt/loop-state (#184/#185). Crucially, **`controller_live_authorization` emits `live_controller_may_execute` as a verdict — it does not merge.** It requires an operator `live_authorized` merge-frontier decision **+** a dry-run receipt **+** `patchwarden_write_allowed=false` / `external_write_allowed=false`. So the design is settling on: **Patchwarden stays verdict-only permanently; the actual Forgejo merge is performed by the external controller (ClawSweeper/OpenClaw) under its own identity (D26).** **Implication for this issue's DoD item #2 (the D20-lint carve):** if Patchwarden never grows a merge adapter (the actuator is wholly external), then the lint's `merge_pull_request(` ban should stay **permanent — never carved.** The "merge adapter" framing here was the in-Patchwarden path; the architecture is choosing the safer external-actuator path instead. The remaining DoD items still apply, but to the **external controller's** consumption of the live-authorization verdict, not to a Patchwarden call site: - bind the external merge to a ready `controller_live_authorization` verdict (not re-derive), - live-head recheck at actuation, - no-self-approval / non-hard-manual / head-bound carried by the verdict, - dry-run-first (already enforced by #183 requiring a dry-run receipt). So the operator's "authorize the merge actuator" decision is really "**wire the external controller**" + the D26 identity choice — not "build/carve a Patchwarden merge call." Keeping this issue open as the contract the external actuator must honor; the D20-lint stays as-is (permanent ban). — claude (architect loop)

claude referenced this issue

2026-06-25 12:33:27 +02:00

Right-size rigor for single-operator dogfood (less enterprise ceremony, bias toward the wedge) #235