/integrate: advisory in-flight check + documented rebase-retest loop on non-fast-forward push refusal #25

New issue

Open

opened 2026-08-12 08:17:02 +00:00 by jbr870 · 0 comments

jbr870 commented

2026-08-12 08:17:02 +00:00

Owner

Requested by the operator (2026-08-12, during the #21 run).

Problem

Two features finishing at ~the same time can both run /integrate against the same
integration branch (usually develop). Git itself prevents the silent failure — the
merge is a rebase + plain non-force git push origin HEAD:<base>, so the second pusher
gets a loud non-fast-forward refusal — but three gaps remain:

The refusal path is not normative. The loser's full verification ran against a tree
that did not contain the winner's merge. The only correct continuation is
re-fetch → rebase → re-run the verification suite → re-push. Today that recovery is
improvised by whatever session hits it; it should be written into /integrate (and
rebase-onto-base.md) as the documented loop, with an explicit prohibition on
retry-without-rebase and on any force variant.
Wasted work. Both runs execute a full sweep + integration test; one is discarded.
An advisory in-flight check before the expensive part — e.g. "does any other issue
currently sit in the integrating phase?" (already forge-visible via phase labels; no
new machinery) — lets the second run wait/queue instead of racing. Advisory, not a hard
lock: a crashed run must never wedge the pipeline, and git's push atomicity remains the
real serializer.
Deploy interleaving on the merge path: two integration deploys + UAT confirmations
overlapping is at minimum confusing for the UAT surface; the in-flight check should
cover the deploy-confirm window too.

Proposed direction

/integrate: add the in-flight advisory check (list issues in integrating; if another
is active, report and wait/abort per operator choice), and make the non-fast-forward
refusal a first-class documented branch: fetch → rebase → re-verify (full suite; the
qa-playbook §7 invariant applies — what ships changed) → push again.
rebase-onto-base.md: cross-reference the loop for the pre-merge call site.
Keep it forge-portable (phase labels only — works on tea/glab/gh/local-fs adapters).

This issue carries no PREQ yet. Run /requirements --issue=<this> to flesh it out before planning.

Requested by the operator (2026-08-12, during the #21 run). ## Problem Two features finishing at ~the same time can both run `/integrate` against the same integration branch (usually `develop`). Git itself prevents the *silent* failure — the merge is a rebase + plain non-force `git push origin HEAD:<base>`, so the second pusher gets a loud non-fast-forward refusal — but three gaps remain: 1. **The refusal path is not normative.** The loser's full verification ran against a tree that did not contain the winner's merge. The only correct continuation is re-fetch → rebase → re-run the verification suite → re-push. Today that recovery is improvised by whatever session hits it; it should be written into `/integrate` (and `rebase-onto-base.md`) as the documented loop, with an explicit prohibition on retry-without-rebase and on any force variant. 2. **Wasted work.** Both runs execute a full sweep + integration test; one is discarded. An **advisory** in-flight check before the expensive part — e.g. "does any other issue currently sit in the `integrating` phase?" (already forge-visible via phase labels; no new machinery) — lets the second run wait/queue instead of racing. Advisory, not a hard lock: a crashed run must never wedge the pipeline, and git's push atomicity remains the real serializer. 3. **Deploy interleaving** on the merge path: two integration deploys + UAT confirmations overlapping is at minimum confusing for the UAT surface; the in-flight check should cover the deploy-confirm window too. ## Proposed direction - `/integrate`: add the in-flight advisory check (list issues in `integrating`; if another is active, report and wait/abort per operator choice), and make the non-fast-forward refusal a first-class documented branch: fetch → rebase → re-verify (full suite; the qa-playbook §7 invariant applies — what ships changed) → push again. - `rebase-onto-base.md`: cross-reference the loop for the pre-merge call site. - Keep it forge-portable (phase labels only — works on tea/glab/gh/local-fs adapters). This issue carries no PREQ yet. Run `/requirements --issue=<this>` to flesh it out before planning.

jbr870 added the

labels

2026-08-12 08:17:02 +00:00

jbr870 referenced this issue

2026-08-12 19:50:51 +00:00

Worktree and devcontainer are provisioned separately — concurrent features collide in one container #21