|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
|
# Rung 4: premerge
RFC 0009 §premerge, implemented. **Nothing enters the DAG.**
## The helper
`quarry-premerge --clone URL --branch-tip H --target-tip H` (library: `internal/premerge`) clones over HTTP, opens the target tip, merges the branch tip into the working tree — zit's merge writes no check-in — and prints the prepared directory; a conflicted pair exits 2 with the files, a verdict rather than an error. It never commits, and it turns **autosync off** in the prepared checkout: the integration test commits in the tree *on purpose* and asserts the source ledger is unchanged — which is how we caught autosync pushing a test commit home through the clone's saved remote. Belt (settings) and braces (read-only credentials in production).
## Pair-keyed verdicts
A premerge run's subject is `pair:<branchTip>:<targetTip>` — never a check-in, because the merge the accept later writes will hash differently. `ci_run` gained a `pair` column (migration for old stores); `check.report` accepts pair subjects, so an external CI can run the helper and report on the pair. A moved target changes the pair, so every stale verdict expires by construction — merge-queue freshness without a queue.
## Per-branch mode
The protected-branches settings row gained a **premerge** checkbox (`branch_required_checks.mode`). In premerge mode the landing's checks panel and the accept gate read pair-keyed runs and pair-subject external checks only — a green *tip* run does not satisfy a *premerge* requirement (tested) — and the panel says which tree the checks are about.
## Scope honesty
Engine-launched premerge runs (quarry starting them on landing events) arrive with the run-labels rung (dagnats#629); today the pair path is driven by workers/external CI via the helper + `check.report`. Verdict-tag carry-forward at accept and auto-accept-when-green are the next rung.
|