[brettheap]

Lane: openreposhape-3 (openRepoShape-3)
Claim: #479 (comment), #480 (comment), #481 (comment)

One PR for three issues, all in adopt-project.py execute's tail, so that they cost one 3-OS CI cycle. A fix round merged main (7a8b981, #394) and closed review RV493's findings F1-F4 and codex's two threads. The rules it added are marked (fix round). A second round merged main twice more (93e3bf0, with #373 and #387, then 5a25387) and gave #373's test source the tracking branch (RV493's verification, N1).

What

#479: the tracking branch follows the source, and its remote is asked.

• plan --tracking-branch now defaults to the branch plan reads the source at, which the plan also records as source.default_branch:. An explicit flag still wins. If checked_value refuses a defaulted branch (for example feat#1), the refusal names it as --tracking-branch (not given, so the source's default branch), not as a flag nobody passed.
• New finding plan-tracking-branch-missing: check finds it, and execute refuses it before any leg exists, through the one list _entry_findings builds. It fires when the tracking branch is not a branch of the source. Which branches count:
  • the branches of the source's remote origin, once the source has fetched any, because that is the repository the pull request goes to;
  • otherwise the source's own branches.
    plan and check ask nothing of the network. plan prints the same sentence as a NOTE for the value it records, and refuses nothing.
• (fix round) execute also asks the remote the split goes to, before any leg exists: git ls-remote <assembly url> refs/heads/<tracking>, after _refuse_an_occupied_work_dir and before _refuse_a_split_branch_left_behind and the confirmation. This matters because a clone remembers what its remote has lost. An ordinary git fetch does not prune, so a branch deleted or renamed on GitHub stays as origin/<branch>. A clone made before GitHub renamed master to main also keeps origin/HEAD -> origin/master, so check passed master.
  • Branch absent: REFUSED plan-tracking-branch-missing, naming the url. The remediation is git fetch --prune origin and git remote set-head origin --auto, then renaming the clone's own branch to match where the default was renamed, then plan, check and execute again.
  • Remote unreadable: REFUSED adopt-remote-unreadable, with git's exit and output. It fails closed, at the same point.
  • Under --local-remote-dir the url is the source itself, which the split is pushed back into, so its own branches are the ones asked, and the remediation says so.
• (fix round) The plan's last follow-up names the base as "the plan's tracking_branch" and no longer names it by value. A hand edit of tracking_branch: therefore cannot leave check and the pull request's body naming the old branch. Before this PR the follow-up said "the source's default branch" while execute used --base main.
• plan --help now says what --tracking-branch is and what it defaults to. docs/cli.md is regenerated.
• (fix round 2) shape_materialize.py: RULESET_HINT names the run's tracking branch where it named main, as the pull request's base and the ref the scaffold and the family holder pushed (#324) #373's test tests/test_ruleset_hint_tracking_branch.py gives its adoption source the tracking branch beside master (git branch <tracking>), since execute now refuses a tracking branch the source lacks. The source stays on master, so the test's "master" not in printed assertion still means what it says.

#481: the topic comes before the pull request.

• execute sets xf-project-<id> on each of the three repositories before it opens the pull request. It tries each repository whatever the previous one answered. It prints set on all three, or set on <those it set> only.
• What a refused pull request and an unset topic leave to do is said in ONE notice, after the table, and only when the split verified:
  • pull request refused: The branch IS pushed., then Set the topic by hand: with a gh repo edit <repo> --add-topic <topic> for each repository left without the topic, then Open the pull request by hand: and its command, which is still the last thing the run says;
  • pull request open: The split IS pushed and the pull request IS open. Set the topic by hand:, listing only the repositories left without it.
• A split that fails verification gets no topic command, just as it gets no pull-request command. The re-run its footer names sets the topic.

#480: NEXT matches where the shape's Makefile and bootstrap script went.

• _commit_the_split now returns the materializer's collisions, and _next_steps reads the whole list:
  • The shape's Makefile went to shape/Makefile and its scripts/bootstrap.py took its own name: NEXT names python3 scripts/bootstrap.py, followed by a NOTE that says why.
  • (fix round) The source's own scripts/bootstrap.py stayed in the root, with or without its own Makefile. Both make bootstrap and python3 scripts/bootstrap.py then run the SOURCE's script, which can exit 0 having placed no leg. So NEXT names no bootstrap command, and its NOTE says which merges come first: merge shape/Makefile into Makefile and shape/scripts/bootstrap.py into scripts/bootstrap.py first, and then run make bootstrap.
  • Otherwise NEXT is byte for byte what it was, and a test checks that.
• The Makefile collision follow-up (collision_follow_up, scripts/shape_materialize.py) now says the shape's make targets (bootstrap, validate, pins, park, resume) arrive only with that merge, and what runs meanwhile. A test checks that this list matches the template's own targets.
• (fix round) collision_follow_up is told the whole collision list (_predict_collisions passes it). Where scripts/bootstrap.py is predicted aside too, the Makefile's follow-up names no meanwhile command and says both merges come first. It uses the materializer's existing BOOTSTRAP name for the path.

Unchanged:

• execute's exit codes.
• _verify.
• The leg pushes and ADOPT_RULESET_HINT; both already took the tracking branch.
• Every other message. (F4: this line said "every message when nothing is refused", which was not true. The plan's last follow-up, the Makefile follow-up and the set on all three line all change on runs where nothing is refused, as the bullets above say.)
• AGENTS.md, which is at 490 of its 490-line cap on main. Step 7's anchors (IS pushed, gh pr create, the topic, "finish with the command it prints") are still true, and the tool's own output carries the rest. AGENTS.md names no plan-* or adopt-* code, so neither new code is added there.

Why

Measured with the acceptance harness: a stub gh and local bare repositories behind url.insteadOf. Main is 8782333, and head is this PR's first commit's code.

run	main 8782333	head
trunk source (develop beside it), plan	default_branch: trunk, tracking_branch: main	tracking_branch: trunk
same, check / execute --yes	plan ok / exit 2 after both legs and the split are pushed: pull request create failed: GraphQL: Base ref must be a branch; the printed way out repeats --base main	plan ok / exit 0, pull request trunk <- adopt/three-repo-shape; the split's project.yaml has tracking_branch: trunk
trunk source, plan --tracking-branch main	(main's default run above)	plan exit 0 with NOTE the tracking branch is main, which is no branch of the source's remote origin(its branches:develop, trunk; ...); check exit 1 FINDING plan-tracking-branch-missing; execute exit 2 REFUSED plan-tracking-branch-missing, and the fake GitHub holds no leg repository
gh pr create refused: the gh calls	2× repo create, pr create; no repo edit	2× repo create, 3× repo edit, then pr create; topic xf-project-delta set on all three
source with its own Makefile: NEXT	make bootstrap, which exits 2 in a recursive clone (No rule to make target 'bootstrap')	python3 scripts/bootstrap.py plus a NOTE; exits 0 in that clone

(fix round) These rows use the review's probes, with the stub gh first on PATH, a bogus token and an empty config directory. The columns are main 03dc729, this PR's first head ac91a0b, and this head.

run	main 03dc729	ac91a0b	this head
a clone made while the default was master; GitHub renames it main; an ordinary git fetch: plan / check / execute	tracking_branch: main / plan ok / exit 0, pull request against main	tracking_branch: master / plan ok / exit 2 after both legs and the split are pushed (2× repo create, 3× repo edit, pr create): Base ref must be a branch, and the by-hand command repeats --base master	tracking_branch: master / plan ok / exit 2 REFUSED plan-tracking-branch-missing: tracking_branchismaster, which https://github.com/testorg/Northwind.git`, the repository the split is pushed to, does not have as git ls-remote reads it now; **no gh` call**, no leg repository
plan --tracking-branch release, then release deleted on GitHub after the clone's fetch	plan ok / exit 2 after both legs are pushed: Base ref must be a branch	the same, after 3× repo edit	plan ok / exit 2 REFUSED plan-tracking-branch-missing, no gh call, no leg repository
source keeps its own Makefile and scripts/bootstrap.py (scripts/ answered root): NEXT	make bootstrap: exit 2 in a recursive clone	python3 scripts/bootstrap.py, which in that clone runs the SOURCE's script and exits 0	no bootstrap command; NOTE ... merge shape/Makefile into Makefile and shape/scripts/bootstrap.py into scripts/bootstrap.py first, and then run make bootstrap.
source keeps its own scripts/bootstrap.py and no Makefile: NEXT	make bootstrap, which runs the SOURCE's script: exit 0	the same	no bootstrap command; NOTE ... merge shape/scripts/bootstrap.py into scripts/bootstrap.py first, ...
plan made with --tracking-branch develop, then tracking_branch: edited to master: check's last follow-up	... against the source's default branch; ... (main's text)	... against develop, the branch the assembly root and both legs track; ...	... against the plan's tracking_branch, the branch the assembly root and both legs track; ...

Each issue's description held when re-measured on 8782333; the line numbers have moved since 36538fd. #480's mention of the copied AGENTS-shape.md is left out, as described below.

Tests

On 56bb04d, with git-filter-repo 2.47.0 first on PATH: tests/test_adopt_*.py (30 files), every other test file that drives adopt-project.py (among them test_ruleset_hint_tracking_branch.py, test_shape_doctor.py, test_scaffold_leg_path_collisions.py and test_template_values_single_pass.py), and the guards test_repo_hygiene.py, test_cli_reference.py, test_agents_md_codes.py, test_git_output_decoding.py and test_stdout_encoding.py. Result: 3730 passed, 5 skipped in 17m23s. The first fix round's head, fc1a35b, gave 2652 passed and 5 skipped on its narrower set. N1 bites: with the merge commit's #373 test (no git branch <tracking>), its four adopt-* cases fail; with the line, the file gives 16 passed. Then main 5a25387 (bump-leg.py, shape-doctor.py; none of this PR's files) was merged clean. On that final head, 9cb9d7b, test_ruleset_hint_tracking_branch.py, test_adopt_tracking_branch.py, test_adopt_e2e.py, test_adopt_github_exits.py, test_adopt_late_failure.py, test_shape_doctor.py, test_scaffold_leg_path_collisions.py and the five guards gave 837 passed, 4 skipped in 6m43s.

Fix-round tests:

• tests/test_adopt_github_exits.py:
  • github_run takes a before_plan hook, and the refusals share assert_refused_before_any_repository.
  • New: the rename scenario is refused before any gh call, and the way out it names leads to a plan that records main and checks ok.
  • New: an unreadable remote is refused as adopt-remote-unreadable before any gh call.
• tests/test_adopt_tracking_branch.py: the follow-up names the plan's key. New: a hand edit leaves no branch named in check's follow-up.
• tests/test_adopt_e2e.py:
  • New: an execute run whose source keeps its own Makefile and scripts/bootstrap.py; its NEXT names no bootstrap command.
  • New: _next_steps with only the script aside.
  • New: _predict_collisions with Makefile and scripts/ kept.
  • The byte-for-byte control now passes an empty collision list.

Do the fix-round tests bite?

• On ac91a0b's code, the 9 fix-round test nodes give 7 failed and 2 passed. The 2 that pass are the controls: the refused base the source lacks, and NEXT where nothing went aside.
• Five mutations of this head each fail the test aimed at them, and that test's control still passes:
  • the remote's answer ignored;
  • an unreadable remote not caught;
  • NEXT ignoring the script;
  • the follow-up ignoring the script;
  • the follow-up naming a branch.

New and rewritten tests of the first commit:

• tests/test_adopt_tracking_branch.py (new):
  • plan records the source's branch, and an explicit flag still wins;
  • check finds a hand-edited branch;
  • execute refuses it before any leg;
  • origin's branches are the ones asked once fetched;
  • a defaulted unsafe branch is named as the default.
• tests/test_adopt_github_exits.py:
  • the shim now emulates GitHub's base check, takes several refusals and per-repository refusals, and logs the order of its calls;
  • new: the topic is set before a refused pull request; one notice when both are refused (pull-request command last); only the refused repository is named; master and trunk sources open against their own branch; a base the source lacks is refused before any gh call;
  • the assertion at the old 369-372, which held that a refused pull request leaves the topic unset, now holds that it is set and that the notice names only what is left;
  • the failed-verification test also refuses the topic, and asserts that no topic command is offered.
• tests/test_adopt_e2e.py: NEXT names the command that works, and it exits 0 in a recursive clone (and make bootstrap fails there, where make exists); the follow-up names the template's targets; the control, where the Makefile was not set aside, keeps NEXT byte for byte.
• tests/test_adopt_late_failure.py: its two by-hand helpers call _finish_by_hand.

On main's code, every new test and every rewritten assertion of the first commit FAILED: 19 failed, 111 passed in those four files. The extended failed-verification test passes there, as it should. Breaking each rule in a scratch copy (9 breaks) failed the tests aimed at it.

Skips:

• The GitHub-mode runs are skipped on Windows, because the gh shim is a #! script, as the rest of test_adopt_github_exits.py is.
• Every execute test needs git filter-repo.
• The plan and check tests in test_adopt_tracking_branch.py run on all three OSes.

Composes with

git merge-tree --write-tree of each open sibling, and lane 3's PR-less adopt branches, against this head, which contains main 5a25387. #373 and #387 have landed and are merged in. #387's note loop and this PR's are both kept in _print_plan_report, in _entry_findings' order. #373's test is the one changed above.

branch	result
#356 fix/adopt-check-hand-edited-plan	CONFLICT adopt-project.py: _entry_findings' docstring list and return tuple. Each side adds one entry; keep both
#382 fix/adopt-refuse-existing-split-branch	CONFLICT adopt-project.py: the module docstring's check paragraph; keep both clauses
#435 fix/adopt-plan-field-types	CONFLICT adopt-project.py: _entry_findings' docstring and return (keep both) and _commit_the_split: the same three hunks it already has with main
#384 fix/adopt-spell-question-and-submodule	CLEAN
#494 fix/refusal-default-remediation	CLEAN
#266, #374, #376 (scripts/shape_materialize.py); #395, #453 (docs/cli.md)	CLEAN
#465 fix/docs-validate-pins-gh-fallback	CONFLICT docs/handbook.html only, the conflict it has with main 5a25387 itself; none of this PR's files conflict
fix/adopt-root-kept-symlinks (lane 1, f8e7176)	CONFLICT adopt-project.py: the module docstring's check paragraph and _entry_findings' docstring and return; keep both
fix/adopt-pin-writes-pin-file (lane 5)	CONFLICT adopt-project.py and docs/cli.md: _commit_the_split, where it already conflicts with main
fix/adopt-plan-quote-yaml-keywords	CONFLICT adopt-project.py: both add a section before _checked_plan_inputs, and _entry_findings' docstring and return; keep both. Its FLAG_DEFAULTS will want this PR's label for a defaulted tracking branch. Its tests that plan --tracking-branch true or null and run execute will need the same git branch <tracking> in their source as #373's did

The first fix round added no conflict hunk with any of these. For each conflicting sibling, the hunks against this head are the same as against the merge commit before the fix round. The fix round's import of BOOTSTRAP is its own statement for that reason: fix/adopt-root-kept-symlinks and fix/adopt-plan-quote-yaml-keywords both rewrite the shape_materialize import list.

Left out

• A source that keeps a lowercase makefile or a GNUmakefile: GNU make reads it before the shape's Makefile on a case-sensitive disk, so NEXT's make bootstrap still fails there. It goes on the Tracking: adopt-project.py, converting an existing repository in place #457 checklist.
• A --tracking-branch that names a branch other than the one the split is made on: the split's pull request then also carries the difference between the two branches. It is not checked.
• The copied AGENTS-shape.md and adopt-shape-file-missing's wording ("the assembly's first make bootstrap") still say make bootstrap. Those are the shape's own words.
• check's WHAT WILL HAPPEN does not name the tracking branch, which is the pull request's base.
• (fix round) check still asks nothing of the network. A branch the clone remembers and GitHub lost passes check, and execute refuses it before any leg.
• (fix round) The plan's follow-ups are written once, by plan, from its own answers. A leg: edited afterwards is not re-derived into them. In codex's scenario (scripts/ answered root by hand), the split's Makefile follow-up still names python3 scripts/bootstrap.py as what runs meanwhile, while NEXT and the split's WRITTEN BESIDE, NOT OVER list are right. It is a candidate for Tracking: adopt-project.py, converting an existing repository in place #457's checklist.
• (fix round) plan reads the source at its local default branch. A clone with no local branch of the name origin/HEAD names is refused by plan as git-failed (git rev-parse <branch>). That is why the remediation says to rename the clone's own branch after a rename.

Closes #479
Closes #480
Closes #481

🤖 Generated with Claude Code

Summary by Sourcery

Make project adoption follow the source’s real default branch, complete topic setup before pull requests, and provide collision-aware bootstrap guidance.

New Features:

• Default the adoption tracking branch to the source repository’s default branch and validate that it exists locally and on the destination remote.
• Set project topics on all repositories before opening the pull request, while reporting only the remaining manual actions.
• Choose verified NEXT bootstrap instructions based on where the shape’s Makefile and bootstrap script are materialized.

Bug Fixes:

• Prevent adoption from creating legs or pushing changes when the tracking branch is missing or the destination remote is unreadable.
• Keep pull-request instructions and bootstrap guidance accurate for non-main source branches and root file collisions.

Enhancements:

• Improve collision follow-ups to describe the shape’s Make targets and required bootstrap merges.
• Consolidate post-verification manual recovery instructions for topic and pull-request failures.

Documentation:

• Regenerate the CLI documentation with the updated tracking-branch option behavior.

Tests:

• Add coverage for source-derived tracking branches, missing and stale remote branches, unreadable remotes, topic ordering and partial failures, and collision-aware bootstrap guidance.

[sourcery-ai]

Sorry @brettheap, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 3 days and 22 hours by commenting @sourcery-ai review. Upgrade to get a review now.

[sourcery-ai]

Reviewer's Guide

The PR updates adoption execution to track the source’s actual default branch with early validation, set repository topics before pull-request creation with consolidated recovery guidance, and choose a working bootstrap command when the shape Makefile is displaced by a source Makefile; CLI documentation and comprehensive tests are updated accordingly.

Sequence diagram for adoption execution ordering

sequenceDiagram
    participant Execute
    participant Repositories
    participant GitHub
    participant Verify
    Execute->>Repositories: _set_the_topic(repositories, topic)
    loop assembly, spec, code
        Repositories->>GitHub: gh repo edit --add-topic
    end
    Execute->>GitHub: _open_the_pull_request(..., tracking, ...)
    GitHub-->>Execute: pull request result
    Execute->>Verify: _verify(...)
    Verify-->>Execute: verification result
    Execute->>Execute: _finish_by_hand(passed, refused, topic, unset)

Loading

Flow diagram for tracking branch validation

flowchart TD
    A[plan reads source default branch] --> B[tracking_branch defaults to source.branch]
    C[explicit --tracking-branch] --> D[tracking branch value]
    B --> D
    D --> E[_tracking_branch_problem]
    E --> F{Branch exists in origin refs?}
    F -->|yes| G[check succeeds]
    F -->|no| H[plan prints NOTE]
    H --> I[check emits plan-tracking-branch-missing]
    I --> J[execute refuses before creating legs]

Loading

Flow diagram for Makefile-aware next steps

flowchart TD
    A[_commit_the_split returns materializer collisions] --> B{Shape Makefile collided?}
    B -->|no| C[_next_steps prints make bootstrap]
    B -->|yes| D[_next_steps prints python3 scripts/bootstrap.py]
    D --> E[NOTE explains shape/Makefile and pending merge]
    F[collision_follow_up] --> G[Lists bootstrap, validate, pins, park, resume]
    G --> H[Targets arrive when Makefile collision is merged]

Loading

File-Level Changes

Change	Details	Files
Align the tracking branch with the source repository and validate it before adoption work begins.	Default plan --tracking-branch to the source branch and preserve explicit overrides. Validate against fetched origin branches, or local branches when no remote branches are available. Add a shared finding used by check and early execute refusal, with matching plan notes and remediation. Use the resolved branch in follow-ups, project metadata, leg pushes, and pull-request base commands.	adopt-project.py docs/cli.md tests/test_adopt_tracking_branch.py tests/test_adopt_github_exits.py
Make GitHub topic setup independent of pull-request success and consolidate manual recovery instructions.	Set the project topic on assembly, spec, and code repositories before opening the pull request, continuing after individual failures. Report which repositories received the topic and list only missing-topic commands for manual recovery. Combine topic and pull-request recovery into one post-verification notice while preserving verification precedence and exit behavior. Update late-failure and GitHub-mode tests for call ordering, partial failures, and failed verification.	adopt-project.py tests/test_adopt_github_exits.py tests/test_adopt_late_failure.py
Make post-adoption bootstrap guidance account for a source Makefile collision.	Return materializer collisions from split creation and use the Makefile collision to select python3 scripts/bootstrap.py in NEXT. Explain that the shape's Make targets become available only after merging shape/Makefile into the root Makefile. Keep the existing make bootstrap output unchanged when no collision occurs. Verify the target list against the template and test recursive-clone bootstrap behavior.	adopt-project.py scripts/shape_materialize.py tests/test_adopt_e2e.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#479	Default the tracking branch to the source repository’s default branch, while allowing an explicit --tracking-branch value to take precedence, so adopted legs and the pull request use the intended base branch.	✅
#479	Have check detect and report a tracking branch that is not a branch of the repository the pull request targets, so an invalid plan is caught before execute creates repositories or pushes the split.	✅
#480	When the shape's Makefile is placed at shape/Makefile because the source already has a root Makefile, make execute's NEXT command work in the adopted root before the Makefiles are merged.	✅
#480	Explain that the shape's Makefile targets are unavailable until the collision follow-up is merged, and identify the bootstrap command that works meanwhile.	✅
#480	Ensure the adopted root's instructions do not continue directing users to run the unavailable make bootstrap before the Makefiles are merged.	❌	The PR updates NEXT and the Makefile collision follow-up, but explicitly leaves the copied AGENTS-shape.md unchanged; it still tells users to run make bootstrap in the adopted root.
#481	Set the project topic on all three repositories before attempting to open the pull request, so a refused pull request does not leave the topics unset.	✅
#481	When setting a topic fails, tell the person which repository still needs it and provide the corresponding gh repo edit … --add-topic … command in the post-verification notice, including when the pull request is also refused.	✅

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[brettheap]

(lane openRepoShape-3, 2026-10-12T22:45:07Z) @codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-12T22:49:41.818781Z	ac91a0b	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ac91a0b410

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Verify tracking branches against the actual remote

When a clone still has refs/remotes/origin/release after that branch was deleted or renamed on GitHub, this cached ref remains in fetched because an ordinary fetch does not prune it, so _tracking_branch_problem accepts a base that no longer exists. execute then creates and pushes both legs and the split before gh pr create rejects the missing base, leaving the user in the documented state where fresh legs must not be created. Verify the advertised refs of the assembly remote, or fail closed until its tracking refs have been fetched with pruning, rather than treating cached remote-tracking refs as proof of existence.

AGENTS.md reference: AGENTS.md:L144-L153

Useful? React with 👍 / 👎.

[brettheap]

(lane openRepoShape-3, 2026-10-13T00:25Z) Fixed in fc1a35b: execute now asks the assembly's remote itself (git ls-remote <url> refs/heads/<tracking>) before any leg exists, and refuses plan-tracking-branch-missing when the branch is absent and adopt-remote-unreadable when the remote cannot be read. The stale origin/master after a master-to-main rename is a new test in tests/test_adopt_github_exits.py.

[chatgpt-codex-connector]

Account for a colliding bootstrap script

When the source keeps both its own Makefile and scripts/bootstrap.py in the root, the materializer puts the shape's script at shape/scripts/bootstrap.py, but this command runs the source's pre-existing script instead. Because execute deliberately does not perform the collision follow-ups, the advertised next step can run unrelated code without placing the legs on their tracking branches or validating the adopted project; pass the full collision set into _next_steps and defer bootstrap until the shape script has also been merged.

AGENTS.md reference: AGENTS.md:L139-L143

Useful? React with 👍 / 👎.

[brettheap]

(lane openRepoShape-3, 2026-10-13T00:25Z) Fixed in fc1a35b: _next_steps and the plan-time Makefile follow-up now read the whole collision list, and where scripts/bootstrap.py went aside too, NEXT names no bootstrap command and says to merge shape/Makefile and shape/scripts/bootstrap.py first. An execute run of that source is a new test in tests/test_adopt_e2e.py.

[brettheap]

(lane openRepoShape-3, 2026-10-13T00:25Z) @codex review

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[brettheap]

(lane openRepoShape-3, 2026-10-13T01:05Z) @codex review

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[sonarqubecloud]

Quality Gate passed

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud