fix(orchestrator): respect custom base branch in exec zero-diff guard (#534 follow-up)

[admarble]

Summary

The zero-diff exec guard added in #534 (phase-executor.ts:hasExecChanges) hardcodes origin/main as the base ref:

execSync("git rev-list --count origin/main..HEAD", { cwd, stdio: "pipe" })

When a worktree is created with a custom base via ./scripts/dev/new-feature.sh <issue> --base feature/X, HEAD already has commits relative to origin/main from the moment the worktree is created (the parent feature branch's diff). The guard sees count > 0, reports hasExecChanges = true, and the exec phase can produce zero new commits without being caught — the same failure mode #534 was trying to prevent, but scoped to custom-base worktrees.

/fullsolve and /exec both document --base feature/<branch> as a supported pattern (for epic-style integration branches and feature flag staging), so this is a real configuration we ship, not a theoretical edge case.

Evidence / Reproduction

1. Create a worktree off a populated feature branch:

   ./scripts/dev/new-feature.sh 999 --base feature/some-epic

2. The new worktree's HEAD shares its tip with feature/some-epic, which itself has N commits on top of origin/main.
3. git rev-list --count origin/main..HEAD → N (not 0).
4. Run exec against an agent that produces nothing.
5. hasExecChanges returns true → exec is marked success: true → same end-state as the original fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534 bug: failure surfaces only at PR creation with "No commits between main and feature/…" or passes silently into QA.

Root Cause

hasExecChanges has no notion of the worktree's configured base branch. The correct base is whatever was passed to new-feature.sh --base, stored implicitly in git (the initial commit the branch was created at), or looked up via upstream tracking.

Acceptance Criteria

• AC-1: hasExecChanges(cwd) resolves the correct base ref for the worktree before counting. At least one of:
  • Read the base ref from a worktree-local marker that new-feature.sh writes (e.g. .sequant/base-ref inside the worktree, containing origin/feature/X).
  • Use the branch's upstream tracking ref if set (git rev-parse --abbrev-ref '@{u}' inside the worktree, falling back to merge-base lookup).
  • Read the base from the branch name convention (e.g. git config branch.<current>.sequantBase) written by new-feature.sh.
• AC-2: scripts/dev/new-feature.sh records the --base value (defaulting to main) in whichever mechanism AC-1 chose. Backfill recorded base for existing worktrees as part of the migration, OR document that the fix only applies to worktrees created after this change ships.
• AC-3: hasExecChanges falls back to origin/main when no recorded base exists (backward compatibility with pre-fix worktrees and with non-sequant-managed worktrees). Behavior under fallback matches current fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534 behavior.
• AC-4: Unit tests cover: custom-base worktree with new commits (passes), custom-base worktree with zero new commits relative to the recorded base (fails with the same error string as fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534), custom-base worktree with uncommitted work (passes), worktree with no recorded base (falls back to origin/main, original fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534 behavior preserved).
• AC-5: mapAgentSuccessToPhaseResult still calls hasExecChanges(cwd) — the base-resolution logic lives inside the helper, not at the call site. Consumers don't need to know about bases.
• AC-6: Integration test or documented manual reproducer: create a worktree with --base feature/<branch> on a branch that is N commits ahead of main, run an exec that produces zero new commits, verify the phase is reported as failed. This is the primary validation that the bug is actually fixed end-to-end.
• AC-7: CHANGELOG.md entry under [Unreleased] / Fixed referencing this issue.

Non-Goals

• Not changing how new-feature.sh selects or validates the base branch.
• Not introducing a full "base-branch registry" across all sequant commands — scope is limited to what hasExecChanges needs to consult.
• Not changing the zero-diff error message — reuse the literal string "exec produced no changes (no commits, no uncommitted work)" from fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534 so logs are greppable across both scopes.
• Does not overlap with fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534's QA null-verdict guard — that branch of the helper is already base-agnostic.

Dependencies

• fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534 (PR fix(#534): treat null QA verdict and zero-diff exec as phase failure #536) must merge first — this issue modifies hasExecChanges introduced there.

Complexity

small-to-medium — single helper + one shell script, plus test matrix. Single worktree, no skill-sync. Estimated 1–2 AC-units of implementation, ~50-100 LOC including tests.

Why this matters

Custom-base worktrees are the exact case where #534's failure mode is hardest to spot: the branch is already long-lived, already has commits, and a silent zero-progress exec is easier to miss in review. Leaving this gap means #534 partially fixes the orchestrator but ships a known hole for the epic-integration pattern.

[admarble]

/spec Analysis

Complexity: Standard (7 ACs, 3 directories)
Scope: ⚠️ SCOPE_WARNING (7 ACs — above yellow threshold of 6, but tightly scoped; no split)

AC Checklist

• AC-1: hasExecChanges(cwd) resolves the worktree's base via git config branch.<current>.sequantBase (prepending origin/). Verification: Unit Test.
• AC-2: scripts/dev/new-feature.sh writes the --base value (default main) into branch.<new-branch>.sequantBase. Existing worktrees fall through to AC-3; no code migration. Verification: Integration Test.
• AC-3: Fallback to origin/main when no recorded base — preserves current fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534 behavior. Verification: Unit Test.
• AC-4: Unit test matrix: custom-base + new commits (pass), custom-base + zero diff (fail), custom-base + dirty (pass), no-config fallback (existing behavior). Verification: Unit Test.
• AC-5: mapAgentSuccessToPhaseResult still calls hasExecChanges(cwd); base resolution lives inside the helper. Verification: Unit Test (existing).
• AC-6: End-to-end reproducer (integration test preferred, markdown reproducer acceptable). Verification: Integration Test.
• AC-7: CHANGELOG.md [Unreleased] / Fixed entry extending the fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534 bullet.

Implementation Plan

1. new-feature.sh — after git worktree add, run git -C <worktree> config branch.<branch>.sequantBase <base>.
2. phase-executor.ts — add resolveBaseRef(cwd) helper: read branch.<current>.sequantBase via git config --get, prepend origin/ if needed, fall back to "origin/main" on error/missing. Update hasExecChanges to use it.
3. Tests — extend phase-executor.test.ts hasExecChanges block with the AC-4 matrix; add resolveBaseRef cases; add a real-git integration test for AC-6.
4. CHANGELOG — sub-bullet under existing fix(orchestrator): treat null QA verdict and zero-diff exec as failure, not success #534 Fixed entry referencing fix(orchestrator): respect custom base branch in exec zero-diff guard (#534 follow-up) #537.

Key Decisions

• Persistence mechanism: git config branch.<name>.sequantBase (over .sequant/base-ref or branch-name convention) — per-branch, survives worktree moves, no new files, no migration.
• Migration strategy: Document-only (no backfill). Existing worktrees use AC-3 fallback and continue to behave as-is.
• Public API: unchanged — base resolution internal to the helper.

Open Question

• AC-6 as integration test vs markdown reproducer. Recommendation: integration test (pattern exists in checkpoint.integration.test.ts); markdown fallback if harness cost is disproportionate.

Recommended Workflow

Phases: spec → exec → qa (quality loop disabled). No UI → no /test. Bug-only → no testgen.

[admarble]

/fullsolve Complete

Issue: #537
Status: READY_FOR_MERGE
PR: #538 — #538

Summary

• All 7 ACs met with literal verification
• Build, lint, and targeted test suites clean (150/150)
• Proactive shell-injection hardening on the resolved base ref (added after first-pass QA review; covered by two dedicated tests)

Iterations

Phase	Iterations	Status
Spec	1/1	Complete
Exec	1/1	Complete
QA	1/2	Complete (READY_FOR_MERGE on first pass; one in-line hardening commit before verdict)

AC Coverage

AC	Status	Evidence
AC-1	✅ MET	resolveBaseRef at phase-executor.ts:269
AC-2	✅ MET	templates/scripts/new-feature.sh:158 (symlinked to scripts/new-feature.sh)
AC-3	✅ MET	Six fallback paths to origin/main
AC-4	✅ MET	Unit matrix in phase-executor.test.ts — custom-base + new commits, zero diff (primary #537 fix), dirty, no-config fallback
AC-5	✅ MET	mapAgentSuccessToPhaseResult signature unchanged
AC-6	✅ MET	phase-executor.integration.test.ts — real bare-origin + work repo
AC-7	✅ MET	CHANGELOG sub-bullet under #534

Risk Assessment

• Likely failure mode: User creates a worktree outside new-feature.sh → AC-3 fallback applies; zero-diff on a populated parent is not detected. Documented in CHANGELOG as a scope boundary, not a regression.
• Not tested: End-to-end shell invocation of new-feature.sh. Mitigated by the integration test writing the same config key and exercising the consumer path.

---

Ready for human review and merge.