feat(orchestrate): reconcile mode needs dir=/owner_repo — the merge-conflict error rail points foreign-repo PRs at a tool that cannot reach them #14

New issue

Closed

opened 2026-07-11 21:35:05 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-11 21:35:05 +00:00

(Migrated from codeberg.org)

Problem

When a merge fails because the base moved under an open PR, the error message steers to the sanctioned force-push-free recovery:

Recover with the push-compatible reconcile flow (merges the latest base into the PR head, no force-push):
  madt_orchestrate reconcile=29        (or: madtea orchestrate reconcile 29)

But madt_orchestrate has no dir= or owner_repo= parameter — it only operates on the repo at the server's working directory. For a PR in a FOREIGN repo (the ADR 0019 worktree flow: madt_worktrees add dir= → madt_commit dir= → madt_finish dir= branch=), the rail is unfollowable — worse, following it literally would target the same-numbered PR in the wrong repo (from a madtea session, reconcile=29 would look up madtea#29, not the other repo's #29).

Live reproduction (2026-07-10, a second repo's PR #29, driven from a madtea-cwd session)

madt_finish dir=<path-to-the-other-repo> branch=docs/issue-labels-standard — merge step failed: base had moved (add/add conflict on a file that landed on main after the worktree was cut).
Error rail says madt_orchestrate reconcile=29 → not usable: no dir/owner_repo, would resolve against the wrong repo.
Hand-rolling the same merge-base-into-head flow in the linked worktree then hit the guard seams one by one:
- raw git merge origin/main in the worktree → conflict (expected), but now the worktree holds merge-in-progress state madtea did not create;
- madt_commit dir=<worktree> → refused: "foreign repo ... has a merge in progress. resolve or abort that operation directly in the target repo" — correct guard, but the Bash hook then steers raw git commit right back to madt_commit, so the two guards point at each other;
- working exit: madt_add dir=<worktree> (allowed during the merge) + raw git merge --continue (safe local merge-flow op) + madt_push dir= branch= + madt_prs action=merge owner_repo=.

So a recovery is possible, but it is undiscoverable, partly hook-fighting, and not the documented rail.

Ask

madt_orchestrate reconcile mode accepts dir= (local repo/worktree to operate in) and/or owner_repo= (which repo's PR number is meant), consistent with the other tools.
Reconcile in a foreign repo should target that repo's linked worktree holding the PR head (or refuse with a precise message when none exists) — never the foreign primary checkout (hard rule: primaries are read-only).
The merge-failure error rail includes the dir/owner_repo forms when the failing finish/merge itself was invoked with dir=/owner_repo=, so the suggested command is copy-pasteable and correct for the repo it came from.
madt_commit's foreign merge-in-progress refusal should name the working exit (madt_add dir= + git merge --continue, or reconcile once it supports dir=) instead of the bare "resolve or abort directly in the target repo" — today that text bounces against the Bash hook's steer back to madt_commit.

Acceptance

madt_orchestrate reconcile=N dir=<foreign worktree> (or owner_repo=) completes the merge-base-into-head + push flow for a foreign repo's PR.
Reconcile never touches a foreign primary checkout.
Error rails emitted from a dir=/owner_repo= invocation carry those params in the suggested reconcile command.
Hermetic tests for the foreign-dir reconcile path and the rail text.

## Problem When a merge fails because the base moved under an open PR, the error message steers to the sanctioned force-push-free recovery: ``` Recover with the push-compatible reconcile flow (merges the latest base into the PR head, no force-push): madt_orchestrate reconcile=29 (or: madtea orchestrate reconcile 29) ``` But `madt_orchestrate` has no `dir=` or `owner_repo=` parameter — it only operates on the repo at the server's working directory. For a PR in a FOREIGN repo (the ADR 0019 worktree flow: `madt_worktrees add dir=` → `madt_commit dir=` → `madt_finish dir= branch=`), the rail is unfollowable — worse, following it literally would target the *same-numbered PR in the wrong repo* (from a madtea session, `reconcile=29` would look up madtea#29, not the other repo's #29). ## Live reproduction (2026-07-10, a second repo's PR #29, driven from a madtea-cwd session) 1. `madt_finish dir=<path-to-the-other-repo> branch=docs/issue-labels-standard` — merge step failed: base had moved (add/add conflict on a file that landed on main after the worktree was cut). 2. Error rail says `madt_orchestrate reconcile=29` → not usable: no dir/owner_repo, would resolve against the wrong repo. 3. Hand-rolling the same merge-base-into-head flow in the linked worktree then hit the guard seams one by one: - raw `git merge origin/main` in the worktree → conflict (expected), but now the worktree holds merge-in-progress state madtea did not create; - `madt_commit dir=<worktree>` → refused: "foreign repo ... has a merge in progress. resolve or abort that operation directly in the target repo" — correct guard, but the Bash hook then steers raw `git commit` right back to `madt_commit`, so the two guards point at each other; - working exit: `madt_add dir=<worktree>` (allowed during the merge) + raw `git merge --continue` (safe local merge-flow op) + `madt_push dir= branch=` + `madt_prs action=merge owner_repo=`. So a recovery is *possible*, but it is undiscoverable, partly hook-fighting, and not the documented rail. ## Ask 1. `madt_orchestrate` reconcile mode accepts `dir=` (local repo/worktree to operate in) and/or `owner_repo=` (which repo's PR number is meant), consistent with the other tools. 2. Reconcile in a foreign repo should target that repo's linked worktree holding the PR head (or refuse with a precise message when none exists) — never the foreign primary checkout (hard rule: primaries are read-only). 3. The merge-failure error rail includes the dir/owner_repo forms when the failing finish/merge itself was invoked with dir=/owner_repo=, so the suggested command is copy-pasteable and correct for the repo it came from. 4. `madt_commit`'s foreign merge-in-progress refusal should name the working exit (`madt_add dir=` + `git merge --continue`, or reconcile once it supports dir=) instead of the bare "resolve or abort directly in the target repo" — today that text bounces against the Bash hook's steer back to madt_commit. ## Acceptance - `madt_orchestrate reconcile=N dir=<foreign worktree>` (or owner_repo=) completes the merge-base-into-head + push flow for a foreign repo's PR. - Reconcile never touches a foreign primary checkout. - Error rails emitted from a dir=/owner_repo= invocation carry those params in the suggested reconcile command. - Hermetic tests for the foreign-dir reconcile path and the rail text.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#14

No description provided.

Rows
Columns