Files
stack/packages/mosaic/framework
code-be-02 578716a0ed
ci/woodpecker/pr/ci Pipeline failed
fix(git-tools): pr-create API fallback resolves base from forge default branch (E4)
The API-fallback payload hardcoded "base": "main", mistargeting every
fallback PR on repos whose trunk is not main. With zero fleet tea logins
(measured under T53) every pr-create takes the fallback, so stack repos
(default branch next) got main-targeted PRs.

gitea_pr_create_api now resolves the base when -B is omitted:
gitea_default_branch() queries the provider repo API
(GET /api/v1/repos/<owner>/<repo> -> default_branch) using the same
host/repo/token resolution as the POST itself. Explicit -B still wins and
skips the lookup entirely. A failed or empty resolution fails loud
(-B remedy named) instead of guessing a base; the "main" literal is gone.

Hermetic suite test-pr-create-fallback-default-base.sh (PATH-stubbed curl,
sandbox HOME, git.example.test fixture): no -B -> payload base equals the
stubbed forge default (next) with the repo GET performed; explicit -B wins
with zero repo GETs; lookup failure -> loud refusal, no POST; the literal
main never appears as a fallback. Fixture stubs in
test-gitea-login-resolution.sh and test-issue-create-interactive-auth.sh
gain repo-root answers (assertions unchanged) because the fallback now
makes a call those stubs predated.

Sweep: 32/33 git-tools suites green; test-issue-close-fail-closed.sh fails
identically at baseline origin/next (pre-existing, untouched).
2026-08-23 20:51:03 -05:00
..