Watch

WIP: feat(forge): reuse an owned direct fork with a different name #640

Draft

NitnekLeBorgne wants to merge 1 commit from NitnekLeBorgne/Longshot-contributions:feat/reuse-direct-renamed-fork-20261115 into main

NitnekLeBorgne commented

2026-11-15 02:00:29 +00:00

First-time contributor

Type: feat · Risk: low · Tested on: Linux, game-free synthetic API fixtures · Needs: complete game-free suite and native Windows tests

Why

A contributor may already own a direct fork under a different repository name. The helper currently expects <login>/Longshot; it does not discover and reuse an existing renamed direct fork, even though the rest of the fork/PR flow can use the selected repository's full name.

This is a feature for that workflow, not a regression claim about the existing guard. Refusing a fork whose immediate parent is another fork is correct and remains required. An occupied unsuitable homonym does not become permission to create or select an unrelated repository.

What changed

Reuse a uniquely owned direct fork even when its repository has a different name. Incomplete or ambiguous discovery fails closed without selecting or creating a repository.

scripts/forge.py: retain the valid direct homonym fast path. Otherwise complete a bounded, paginated direct-fork listing and reuse the unique coherent fork owned by the signed-in login whose immediate parent is the main repository.
Incomplete, malformed, repeated, oversized, errored or ambiguous discovery fails closed before selection or creation. Only a genuine missing-homonym HTTP 404 plus a complete absence of suitable forks permits normal creation.
The 404 classification examines the official error's expected GET/status prefix, not occurrences in a response body; an HTTP 503 or transport error mentioning HTTP 404 cannot authorize creation.
tests/test_forge_pr.py: direct/renamed fork, paging, identity, refusal and caller-routing cases. The existing 32 methods are unchanged.
docs/forge.md: describe direct renamed-fork reuse and refusal conditions.

Selected full_name is retained by fork setup and branch lookup. The existing owner/branch PR head syntax is unchanged. Authentication, OAuth renewal and the login/token workflow are untouched.

Settings scope: None. Existing commands learn to reuse a uniquely owned direct fork with another name. Discovery is limited to 100 pages of at most 50 rows and requires an empty terminal page; exhausting the bound is an error, not permission to create.

Measurements

Verdict: the synthetic renamed-fork case fails on the original source and passes with the feature. The complete focused test module passes 50 methods: 32 original methods and 18 new methods. The original 32-method compatibility replay is included in those 50 identities, not additional new coverage.

Hardware: Linux game-free fixtures; no GPU/driver used; CPU and RAM not reported in these receipts.
Scene: Synthetic regression/control inputs, not a game scene.
Method: Functional outcomes from the adopted receipts below, not timing benchmarks; no fabricated repetitions or medians.
How to reproduce: Replay the named focused tests described below on the pinned baseline and candidate with identical fixtures.

	Before: main @ `6c9edffe5d`	After: this PR @ `db2579165f`
Renamed-fork regression	Synthetic renamed-fork case fails	Case passes; focused module: 50 methods (32 original + 18 new)

Baseline: main 6c9edffe5da1f5b5383977aeab3f544c0de25d4c. Exact source/test snapshots, before/after hashes, command/environment metadata, complete native stdout/stderr and exit codes were retained. Negative controls on the old implementation remain failures for the intended reason. Independent SPEC found an overly broad initial 404 text check; targeted RED/GREEN tests and a revised patch resolved that finding before independent QUALITY review.

The final revision's misleading-HTTP503 and misleading-transport-error tests fail on the previous candidate, then pass with the corrected classifier. The genuine-404/complete-absence positive control still creates through the explicit in-memory fake.

Read-only server qualification is separate: the existing contribution fork is a direct child of the main repository; a complete direct-fork inventory and an already-existing PR's head repository were checked. This was not a new experimental PR POST, nor a claim that the modified CLI was executed live.

No gameplay or speed improvement is claimed: this is a contributor-tool workflow feature.

Flags and settings

None

Testing

Tested: Linux, standard-library game-free fixtures using explicit synthetic API responses. All 50 focused methods pass, including the unchanged original 32. Cases cover homonym fast path, later/short pages, final empty page, case-insensitive owner/parent identity with selected spelling preserved, wrong owner, intermediate parent, malformed identities/pages, repeated IDs, ambiguity, bounds, HTTP errors and selected-name caller routing. Private clean patch application reproduces all three candidate files and modes. Independent static SPEC and QUALITY completed on this exact revised patch; neither reviewer claimed a replay.

Not tested: complete python -I -B tests/run_all.py, native Windows, a live invocation of the modified helper, or a new fork/PR creation exercise. An original upload fixture emits a retained ResourceWarning under Python 3.14; the unchanged 32-method compatibility run reproduces it and exits 0. API POSTs appearing in fixture logs are in-memory fakes, not public writes. This remains WIP.

Must be tested:

Linux: audit the full game-free runner's tool/fixture closure, then compare clean main and candidate with python -I -B tests/run_all.py --jobs 1, naming missing tools and baseline failures (by hand; no farm triggered), expecting the full suite to pass or each shared main failure to be named, without treating focused checks as the full suite (by hand: an equipped contributor/tester inspects diagnostics and the stated outcomes before merge; not executed by this documentation edit).
Windows: run the focused tests/test_forge_pr.py fixtures in an isolated folder, without login or real API calls, expecting the same selection/refusal and normal PR-flow results (by hand). (by hand: an equipped contributor/tester inspects diagnostics and the stated outcomes before merge; not executed by this documentation edit).

Risks

What could break: users with multiple suitable direct forks now get an explicit ambiguity error instead of an arbitrary selection. Discovery needs additional read requests when the valid homonym fast path does not apply; an incomplete listing cannot authorize creation.
Turning it off: revert the commit.
Compatibility: no authentication, identity, visibility, game data, save, configuration, renderer ABI or cache changes. The HTTP status classifier intentionally depends on the current official error formatter; its regression tests should be preserved if that formatter changes.

Checklist

Everyone

One topic.
The title is a Conventional Commit (type(scope): description) of the status line's type.
Why gives the reason plainly and links the issues that fit (the tracker searched).
Measurements has a verdict, or one line saying why there is nothing to measure.
Testing names what was tested, what wasn't, and what must still be tested, where and how.
Rebased on current main.
python -I -B tests/run_all.py passes (any failure that also fails on main is named).
No game files, dumps, build output or generated files.
third_party/ untouched (a new folder with a PROVENANCE.md instead).
The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

When it applies

AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
A check under tests/ that reads changed source updated in this PR, not weakened.
Docs updated.

Readiness provenance and checklist notes

Current main in the frozen public readback is aa95d35f3d021b27328b6d68109666a46c340aee; this PR head is db2579165fb6b44c6aeea7146681038e203785f5. The current-main box is unchecked: historical publication/base checks are not proof of current ancestry. Current-main updating and revalidation are needed before ready, but rebase/force-push/merge are not authorized; no such operation is promised or performed. The full runner box remains unchecked; no full-suite run or Windows/host qualification is claimed by this description edit. The normal project pr ready remains blocked and must not be forced. Manual pre-merge plans are future work, not completed evidence.

Historical checklist explanations (not current-main qualification):

The title is a Conventional Commit (type(scope): description) of the status line's type, after the WIP prefix.
Why gives the reason plainly and links the issues that fit (open work and nearby authentication/attachment/review PRs checked; no matching open issue adopted).
Rebased on current main (exact unchanged base checked before publication).
python -I -B tests/run_all.py passes (not run; WIP, focused results only).
third_party/ untouched.
The license is OK: GPL-3.0-or-later; original contributor-tool/tests/docs changes, nothing incompatible or decompiled.

**Type:** feat · **Risk:** low · **Tested on:** Linux, game-free synthetic API fixtures · **Needs:** complete game-free suite and native Windows tests ## Why A contributor may already own a direct fork under a different repository name. The helper currently expects `<login>/Longshot`; it does not discover and reuse an existing renamed direct fork, even though the rest of the fork/PR flow can use the selected repository's full name. This is a feature for that workflow, not a regression claim about the existing guard. Refusing a fork whose immediate parent is another fork is correct and remains required. An occupied unsuitable homonym does not become permission to create or select an unrelated repository. ## What changed Reuse a uniquely owned direct fork even when its repository has a different name. Incomplete or ambiguous discovery fails closed without selecting or creating a repository. - `scripts/forge.py`: retain the valid direct homonym fast path. Otherwise complete a bounded, paginated direct-fork listing and reuse the unique coherent fork owned by the signed-in login whose immediate parent is the main repository. - Incomplete, malformed, repeated, oversized, errored or ambiguous discovery fails closed before selection or creation. Only a genuine missing-homonym HTTP 404 plus a complete absence of suitable forks permits normal creation. - The 404 classification examines the official error's expected GET/status prefix, not occurrences in a response body; an HTTP 503 or transport error mentioning HTTP 404 cannot authorize creation. - `tests/test_forge_pr.py`: direct/renamed fork, paging, identity, refusal and caller-routing cases. The existing 32 methods are unchanged. - `docs/forge.md`: describe direct renamed-fork reuse and refusal conditions. Selected `full_name` is retained by fork setup and branch lookup. The existing owner/branch PR head syntax is unchanged. Authentication, OAuth renewal and the login/token workflow are untouched. Settings scope: None. Existing commands learn to reuse a uniquely owned direct fork with another name. Discovery is limited to 100 pages of at most 50 rows and requires an empty terminal page; exhausting the bound is an error, not permission to create. ## Measurements **Verdict:** the synthetic renamed-fork case fails on the original source and passes with the feature. The complete focused test module passes **50 methods: 32 original methods and 18 new methods**. The original 32-method compatibility replay is included in those 50 identities, not additional new coverage. Hardware: Linux game-free fixtures; no GPU/driver used; CPU and RAM not reported in these receipts. Scene: Synthetic regression/control inputs, not a game scene. Method: Functional outcomes from the adopted receipts below, not timing benchmarks; no fabricated repetitions or medians. How to reproduce: Replay the named focused tests described below on the pinned baseline and candidate with identical fixtures. | | Before: main @ 6c9edffe5da1f5b5383977aeab3f544c0de25d4c | After: this PR @ db2579165fb6b44c6aeea7146681038e203785f5 | |---|---|---| | Renamed-fork regression | Synthetic renamed-fork case fails | Case passes; focused module: 50 methods (32 original + 18 new) | Baseline: main `6c9edffe5da1f5b5383977aeab3f544c0de25d4c`. Exact source/test snapshots, before/after hashes, command/environment metadata, complete native stdout/stderr and exit codes were retained. Negative controls on the old implementation remain failures for the intended reason. Independent SPEC found an overly broad initial 404 text check; targeted RED/GREEN tests and a revised patch resolved that finding before independent QUALITY review. The final revision's misleading-HTTP503 and misleading-transport-error tests fail on the previous candidate, then pass with the corrected classifier. The genuine-404/complete-absence positive control still creates through the explicit in-memory fake. Read-only server qualification is separate: the existing contribution fork is a direct child of the main repository; a complete direct-fork inventory and an already-existing PR's head repository were checked. This was not a new experimental PR POST, nor a claim that the modified CLI was executed live. No gameplay or speed improvement is claimed: this is a contributor-tool workflow feature. ### Flags and settings None ## Testing **Tested:** Linux, standard-library game-free fixtures using explicit synthetic API responses. All 50 focused methods pass, including the unchanged original 32. Cases cover homonym fast path, later/short pages, final empty page, case-insensitive owner/parent identity with selected spelling preserved, wrong owner, intermediate parent, malformed identities/pages, repeated IDs, ambiguity, bounds, HTTP errors and selected-name caller routing. Private clean patch application reproduces all three candidate files and modes. Independent static SPEC and QUALITY completed on this exact revised patch; neither reviewer claimed a replay. **Not tested:** complete `python -I -B tests/run_all.py`, native Windows, a live invocation of the modified helper, or a new fork/PR creation exercise. An original upload fixture emits a retained `ResourceWarning` under Python 3.14; the unchanged 32-method compatibility run reproduces it and exits 0. API POSTs appearing in fixture logs are in-memory fakes, not public writes. This remains WIP. **Must be tested:** - Linux: audit the full game-free runner's tool/fixture closure, then compare clean main and candidate with `python -I -B tests/run_all.py --jobs 1`, naming missing tools and baseline failures (by hand; no farm triggered), expecting the full suite to pass or each shared main failure to be named, without treating focused checks as the full suite (by hand: an equipped contributor/tester inspects diagnostics and the stated outcomes before merge; not executed by this documentation edit). - Windows: run the focused `tests/test_forge_pr.py` fixtures in an isolated folder, without login or real API calls, expecting the same selection/refusal and normal PR-flow results (by hand). (by hand: an equipped contributor/tester inspects diagnostics and the stated outcomes before merge; not executed by this documentation edit). ## Risks **What could break:** users with multiple suitable direct forks now get an explicit ambiguity error instead of an arbitrary selection. Discovery needs additional read requests when the valid homonym fast path does not apply; an incomplete listing cannot authorize creation. **Turning it off:** revert the commit. **Compatibility:** no authentication, identity, visibility, game data, save, configuration, renderer ABI or cache changes. The HTTP status classifier intentionally depends on the current official error formatter; its regression tests should be preserved if that formatter changes. ## Checklist ### Everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`) of the status line's type. - [x] Why gives the reason plainly and links the issues that fit (the tracker searched). - [x] Measurements has a verdict, or one line saying why there is nothing to measure. - [x] Testing names what was tested, what wasn't, and what must still be tested, where and how. - [ ] Rebased on current `main`. - [ ] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### When it applies - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [x] Docs updated. ## Readiness provenance and checklist notes Current main in the frozen public readback is `aa95d35f3d021b27328b6d68109666a46c340aee`; this PR head is `db2579165fb6b44c6aeea7146681038e203785f5`. The current-main box is unchecked: historical publication/base checks are not proof of current ancestry. Current-main updating and revalidation are needed before ready, but rebase/force-push/merge are not authorized; no such operation is promised or performed. The full runner box remains unchecked; no full-suite run or Windows/host qualification is claimed by this description edit. The normal project pr ready remains blocked and must not be forced. Manual pre-merge plans are future work, not completed evidence. Historical checklist explanations (not current-main qualification): - The title is a Conventional Commit (`type(scope): description`) of the status line's type, after the WIP prefix. - Why gives the reason plainly and links the issues that fit (open work and nearby authentication/attachment/review PRs checked; no matching open issue adopted). - Rebased on current `main` (exact unchanged base checked before publication). - `python -I -B tests/run_all.py` passes (not run; WIP, focused results only). - `third_party/` untouched. - The license is OK: GPL-3.0-or-later; original contributor-tool/tests/docs changes, nothing incompatible or decompiled.

NitnekLeBorgne added 1 commit

2026-11-15 02:00:29 +00:00

feat(forge): reuse an owned direct fork with a different name

CI / Conventional Commit title (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions

Details

CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions

Details

Third-party parts / The same as upstream (pull_request) Blocked by required conditions

Details

Third-party parts / As their notes say (pull_request) Blocked by required conditions

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

PR description / Description follows the template (pull_request_target) Successful in 5s

Details

db2579165f

Keep the valid homonym fast path and discover a unique owned direct fork
through complete bounded pages. Refuse ambiguous or incomplete discovery
and permit creation only after a genuine missing-homonym HTTP404.
Preserve authentication and selected-name caller routing.

Assisted-by: Hermes Agent (OpenAI GPT-6.1-sol)
Co-Authored-By: Claudia (OpenAI GPT-6.1-sol)