implementation:implement-dispatch — pin worker->orchestrator git topology for early-pushed source before phase-boundary commit (PR #849 follow-up)

[kyle-sexton]

This was generated by AI during triage (#657 sweep housekeeping, T8h batch conversion).

Follow-up from the 2026-07-22 PR #849 verifier-resolver lane (codex re-review P2, thread PRRT_kwDOTCGFQM6SqmQK; PR #849 merged, this design decision was deferred to the author). Folded from a #657 line (checked off there, this issue is the target).

Problem

implement-dispatch/SKILL.md's "Phase boundaries" section — the plan-marks-only phase-commit exception — does not say how the orchestrator obtains the worker's early-pushed source commit before the main-side build and the plan-only commit. In a dedicated-worktree topology (two worktrees cannot share a branch, so the worker is structurally on its own branch), the orchestrator's checkout lacks that commit unless it explicitly integrates — risking a plan-only commit that omits the source (separate branch) or a non-fast-forward push rejection (same remote branch).

Not defer-forbidden: the worker's source is already pushed to a remote ref (no data loss), and the mandatory main-side build + fresh-context verifier run against the orchestrator checkout would fail loudly on a missing-source checkout (not silent/irreversible; caught at PR review before anything ships).

Decision needed

Pin the intended worker→orchestrator git topology and require the orchestrator to fetch + fast-forward / cherry-pick / merge the worker commit before the Step 4 build and the plan-marks-only commit.

Options:

1. Fetch + fast-forward — orchestrator and worker share a branch; simplest, but only works when the orchestrator's own checkout never diverges independently.
2. Cherry-pick — orchestrator stays on its own branch/commit lineage, cherry-picks the worker's source commit; works even if the orchestrator has independent commits, but rewrites the worker's commit (new SHA) which complicates later reconciliation.
3. Merge — orchestrator merges the worker's branch in; preserves both histories and the worker's original commit, matches this repo's existing merge-staleness protocol precedent (rebase deprioritized repo-wide per lane sweep: triage — week of 7/20 (rolling paper-cut batch) #657 line ~35's finding — merge avoids force-push walls).

This is genuinely open product/design intent for the dispatch topology (not a single maintainer-vetoable default) — the right choice depends on how implement-dispatch wants worker/orchestrator git history to read afterward, which this lane cannot infer from the code alone.

[kyle-sexton]

This was generated by AI during triage.

Decision brief: RECOMMENDED verdict

The issue body already frames the gap and three integration options well; this comment adds the missing piece — a grounded RECOMMENDED verdict — and pins the code and precedent citations.

Problem (2 sentences). implement-dispatch/SKILL.md tells each worker to commit + push its source early, in a dedicated worktree that is structurally on its own branch (SKILL.md:33 push-early clause; SKILL.md:81-84 worktree-anchoring), yet the phase-boundary exception has the orchestrator write a plan-marks-only commit on the orchestrator's own checkout (SKILL.md:45). Nothing specifies how the orchestrator gets the worker's early-pushed source into that checkout before the Step 4 build, the fresh-context verifier, and the plan-mark commit — so the PR risks landing plan marks without the source, or a rejected non-fast-forward push.

What the code does today

• SKILL.md:33 — every worker brief front-loads "commit and push as early as practical," explicitly a source-only checkpoint, "not a substitute for the phase-boundary plan-mark commit, which the orchestrator still runs separately."
• SKILL.md:45 (Phase boundaries) — the plan-marks-only exception: "the worker's earlier commit already carries the source." It asserts the source is already there but never says by what operation the orchestrator's checkout obtained it.
• SKILL.md:81-84 — dedicated-worktree workers anchor every git op with git -C <path>; two worktrees cannot share a branch, so the worker is on its own branch by construction. This is the exact condition that makes "the source is already in the orchestrator's checkout" false by default.
• The topology gap is genuine because SKILL.md never specifies worktree-creation topology (what base each worker worktree is cut from, what ref it pushes to) — which is why the fast-forward viability below is conditional, not decidable from the code.

Relevant precedent (bounded)

This repo has a firm integration posture: never rebase, never force-push, integrate via git merge — see plugins/source-control/skills/babysit-prs/evals/evals.json:71 and reference/orchestration.md:456. Scope note (do not over-read it): that precedent integrates the default branch into a PR branch for freshness — genuinely divergent histories — whereas worker→orchestrator is the same logical work split across worktrees for a mechanical reason. It rules out rebase and force-push; it does not by itself select merge over fast-forward or cherry-pick (all three avoid force-push). So the precedent eliminates two options; the survivors are discriminated on history shape + reconciliation cost.

Options (RECOMMENDED first)

1. RECOMMENDED — orchestrator integrates the worker's pushed ref with git merge (fetch, then git merge; never rebase, never force-push).
Plain git merge fast-forwards when the orchestrator checkout has not diverged and creates a merge commit only when it has — so this single command subsumes both "simplest thing that works" (fast-forward) and "always works" (merge commit) without the orchestrator having to branch on which case it is in. Then run the Step 4 build + fresh-context verifier, then the plan-marks-only commit on top. Rationale: it is the most robust to whatever worktree topology is ultimately pinned, it needs no force-push (honoring the repo posture), and it never rewrites the worker's commit, so later reconciliation (the worker branch may still exist / get pushed to again) stays clean. Cost: a merge commit appears in history whenever the orchestrator had diverged. Reversibility: high — it is added instruction text; changing to a different integration verb later is a doc edit, no migration.

2. Fetch + fast-forward only (git merge --ff-only).
Cleanest linear history and no merge commit — but conditional on topology the code doesn't pin. If each worker worktree is cut from the orchestrator's current tip and the orchestrator integrates before writing each plan-mark, --ff-only stays clean forever. If a worker branched from a stale base (or the orchestrator already wrote a plan-mark the worker didn't descend from), --ff-only aborts. This is not a defect of fast-forward — it is the unspecified topology surfacing. Option 1 degrades gracefully to exactly this behavior in the clean case, which is why it is preferred over pinning --ff-only outright. Reversibility: high.

3. Cherry-pick the worker's source commit.
Lets the orchestrator stay on its own lineage regardless of divergence, but it rewrites the commit to a new SHA. If the worker's branch survives or is pushed to again, you now have two SHAs for one change — the worst reconciliation cost of the three, and a duplicate-commit hazard at PR review. Deprioritized. Reversibility: high as text, but any run that already cherry-picked has divergent SHAs to untangle.

Why this stays a product-intent call

The choice hinges on how implement-dispatch wants worker/orchestrator history to read and on the worktree-creation topology that SKILL.md leaves unspecified — neither is inferable from the code. Option 1 is recommended as the choice that stays correct across the widest range of that unpinned topology; pinning the topology explicitly (worker cuts from orchestrator tip, pushes to a known ref, orchestrator integrates before its plan-mark) would additionally let you safely narrow to Option 2 if a strictly linear history is wanted.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned.

Deferred from PR #849. Worker→orchestrator git topology pin before phase-boundary commit has no fired trigger.

Re-open trigger: When early-pushed source before phase-boundary commit causes a concrete topology mismatch.