pr-metadata.sh + pr-merge.sh lack -r/--repo (sibling wrappers have it) → cross-repo PR ops fail with 'Unknown option: -r' #867

Open
opened 2026-07-22 08:52:45 +00:00 by jason.woltje · 0 comments
Owner

Problem

pr-metadata.sh and pr-merge.sh do not accept -r/--repo, while their sibling PR/issue wrappers all do (pr-list.sh, pr-view.sh, pr-diff.sh, pr-ci-wait.sh, issue-list.sh, and the woodpecker pipeline-list/status, ci-wait). A coordinator that needs PR metadata or a merge on a repo other than its current working directory gets:

$ pr-metadata.sh -n 2947 -r usc/uconnect
Unknown option: -r
$ pr-merge.sh    -n 2947 -r usc/uconnect
Unknown option: -r

and is forced to cd into a checkout of the target repo first (or fall back to raw Gitea API).

Evidence (24h fleet digest, 2026-07-22 — digest-20260722T084716Z)

Observed in a live mosaic-stack coordinator session (b2887dab / 41a31f21) doing cross-repo PR work on usc/uconnect PR #2947 from a mosaic-stack cwd. Unknown option: -r recurred across 2 sessions this window. Source verified in the deployed wrappers:

  • pr-metadata.sh — arg case (line ~16) handles only -n|--number; everything else hits Unknown option (line 35). No -r case.
  • pr-merge.sh — same shape; Unknown option at line 69. No -r case.
  • pr-list.shhas -r|--repo) (line 59). This is the consistency baseline.

Root cause

Flag-surface drift across the git wrapper family: -r/--repo was added to most wrappers but never to pr-metadata.sh / pr-merge.sh. Both infer the repo from the cwd git remote only, so they cannot target a foreign repo the way their siblings can.

Blast radius

Coordinators/orchestrators operating across repos (e.g. Mos on mosaic-stack handling a usc/uconnect PR) cannot use these two wrappers without a cwd-hop, so cross-repo PR metadata/merge either stalls or detours to raw API — the exact "use the wrapper first" path (AGENTS.md rule 27/28) is unavailable for these two verbs. Low severity per hit, recurring, fully preventable. Merge is the higher-stakes verb, so the gap matters most on pr-merge.sh.

Proposed fix

Add the -r|--repo <owner/repo> case to pr-metadata.sh and pr-merge.sh, mirroring pr-list.sh exactly (same flag name, same override of the cwd-inferred repo, same value passed to the platform-detect/repo-arg helper). No behavior change when -r is omitted.

Effort

Small — a few lines each, copy the existing -r|--repo) case + repo-arg plumbing from pr-list.sh. Framework/shared-runtime (packages/mosaic/framework/tools/git/, SSOT mosaicstack/stack). ⚠ Deploy-gap caveat (per #701/#702 lesson): fixing SSOT ≠ fixing web1 — the fix only lands when the framework tools are redeployed; verify the DEPLOYED copies afterward.


Filed by enhance nightly pass 2026-07-22. Evidence: fleet digest digest-20260722T084716Z; coordinator sessions b2887dab/41a31f21 (cross-repo PR #2947 on usc/uconnect). Shared-runtime → route/merge via Mos + MS-LEAD; enhance does not modify the framework directly (AGENTS.md rule 38).

## Problem `pr-metadata.sh` and `pr-merge.sh` do **not** accept `-r/--repo`, while their sibling PR/issue wrappers all do (`pr-list.sh`, `pr-view.sh`, `pr-diff.sh`, `pr-ci-wait.sh`, `issue-list.sh`, and the woodpecker `pipeline-list/status`, `ci-wait`). A coordinator that needs PR metadata or a merge on a repo other than its current working directory gets: ``` $ pr-metadata.sh -n 2947 -r usc/uconnect Unknown option: -r $ pr-merge.sh -n 2947 -r usc/uconnect Unknown option: -r ``` and is forced to `cd` into a checkout of the target repo first (or fall back to raw Gitea API). ## Evidence (24h fleet digest, 2026-07-22 — digest-20260722T084716Z) Observed in a live mosaic-stack coordinator session (b2887dab / 41a31f21) doing cross-repo PR work on `usc/uconnect` PR #2947 from a `mosaic-stack` cwd. `Unknown option: -r` recurred across 2 sessions this window. Source verified in the deployed wrappers: - `pr-metadata.sh` — arg `case` (line ~16) handles only `-n|--number`; everything else hits `Unknown option` (line 35). No `-r` case. - `pr-merge.sh` — same shape; `Unknown option` at line 69. No `-r` case. - `pr-list.sh` — **has** `-r|--repo)` (line 59). This is the consistency baseline. ## Root cause Flag-surface drift across the git wrapper family: `-r/--repo` was added to most wrappers but never to `pr-metadata.sh` / `pr-merge.sh`. Both infer the repo from the cwd git remote only, so they cannot target a foreign repo the way their siblings can. ## Blast radius Coordinators/orchestrators operating across repos (e.g. Mos on `mosaic-stack` handling a `usc/uconnect` PR) cannot use these two wrappers without a cwd-hop, so cross-repo PR metadata/merge either stalls or detours to raw API — the exact "use the wrapper first" path (AGENTS.md rule 27/28) is unavailable for these two verbs. Low severity per hit, recurring, fully preventable. Merge is the higher-stakes verb, so the gap matters most on `pr-merge.sh`. ## Proposed fix Add the `-r|--repo <owner/repo>` case to `pr-metadata.sh` and `pr-merge.sh`, mirroring `pr-list.sh` exactly (same flag name, same override of the cwd-inferred repo, same value passed to the platform-detect/repo-arg helper). No behavior change when `-r` is omitted. ## Effort Small — a few lines each, copy the existing `-r|--repo)` case + repo-arg plumbing from `pr-list.sh`. Framework/shared-runtime (`packages/mosaic/framework/tools/git/`, SSOT mosaicstack/stack). ⚠ Deploy-gap caveat (per #701/#702 lesson): fixing SSOT ≠ fixing web1 — the fix only lands when the framework tools are redeployed; verify the DEPLOYED copies afterward. --- _Filed by `enhance` nightly pass 2026-07-22. Evidence: fleet digest digest-20260722T084716Z; coordinator sessions b2887dab/41a31f21 (cross-repo PR #2947 on usc/uconnect). Shared-runtime → route/merge via Mos + MS-LEAD; enhance does not modify the framework directly (AGENTS.md rule 38)._
jason.woltje added the fleet-enhancement label 2026-07-22 08:52:45 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#867