[brettheap]

Lane: openreposhape-2 (openRepoShape-2)
Claim: #243 (comment)

What

Two changes to adopt-project.py, which are not alternatives:

1. _commit_the_split clones the source with git clone --template=, as the scaffold's git init has taken --template= since scaffold-project.py _build_assembly_root runs git submodule add without --force, so a leg path an ignore rule matches (--code-path __pycache__ or .DS_Store under the shape's own .gitignore, or the default spec under an operator's global excludes) passes --dry-run, then dies at the mount AFTER all three repositories exist and both legs are pushed #229 (39ac59c). The assembly's .git/modules is therefore empty when _mount_the_legs runs, and git submodule add --force has nothing to reactivate. The comment there says why, and that the assembly's commit and push therefore no longer run hooks a template installs (see Left out). The comment in _mount_the_legs that argued "no .git/modules/<name> is in this fresh clone" now says what makes it true.
2. _verify compares each mount's gitlink with the commit pushed to its leg and refuses adopt-mount-commit when they differ, whatever put the other commit there. _mount_commit_findings(tree, mounts, pushed) reads the split tree _verify already reads and the mounts mapping _land_the_root_tree already takes; _pushed_commits is the HEAD of each leg's work directory, which _extract_leg and _seed_leg push and whose tree _verify already accounts for. A mount path that holds no gitlink stays adopt-mount-missing (adopt-project.py: verification passes over the two leg mounts and no other gitlink, so the source's own submodule kept in the root is adopt-root-submodule, any other root gitlink adopt-unexpected-gitlink, one in a leg AND the root adopt-duplicated, and a missing mount adopt-mount-missing (#165) #173), said once. The check does not undo the push, as no finding does; only change 1 prevents the harm.

The other repositories execute creates, and why none needs --template=:

call	needs it?	why
git clone of the source for the assembly (_commit_the_split)	YES, now has it	it is the repository git submodule add --force mounts into
git init --bare of a leg remote (_create_leg_remotes, local mode only)	no	only pushed to and cloned from, never mounted into; with gh the remote is made by GitHub
git clone of the source for a leg (_extract_leg)	no	git filter-repo then pushes from it; the mount's git submodule add clones it by path and a clone copies objects and refs, never a .git/modules
git init for a seeded leg (shape_materialize.git_init_commit, also the scaffold's two legs)	no	same: read by the mount's clone only
gh repo clone of an org/repo source (Source.open)	no	read-only source; the assembly clone made from it does not inherit its .git/modules

Leaving the legs' repositories on the operator's template keeps their hooks and excludes as they run today. The assembly's own template hooks do not run any more (see Left out).

Why

#243 (lane 4, found while verifying #229's review): with init.templateDir pointing at a template that holds modules/spec and modules/code, each a copy of a stranger's non-bare .git, execute exited 0 and printed adoption verified over a split whose two gitlinks were the stranger's commit, and git clone --recurse-submodules of the pushed branch exited 128. Reproduced on 39ac59c: gitlinks c4a30be1705b for both mounts, the legs pushed at 130ce8cf62dd and 2564b5900076, fatal: ... did not contain c4a30be1705b0fa270b35d5de5be8a681d436b92.

Tests

tests/test_adopt_clone_template.py is new and has 31 tests. At 06cb68e on Linux with git filter-repo, all 31 pass. The 17 that run execute skip without git filter-repo, and the Windows job installs none. The other 14 build their legs by hand and run on all three OSes. The operator's configuration reaches git through GIT_CONFIG_GLOBAL, a file each test writes, and the stranger's .git is copied with shutil.copytree; nothing reads or writes a real configuration.

• 2: the premise, asked of git: a plain clone under the template gets the stranger's store and --template= gets none, for init.templateDir and for GIT_TEMPLATE_DIR.
• 16: execute end to end in four cases (template by configuration, by environment, stores with no origin, and the no-template control), four tests each: check ok and exit 0 with adoption verified; each gitlink on the PUSHED split branch equals its leg's pushed tip and is never the planted commit; the work directory's .git/modules holds only the two stores the mounts made, each at its leg's tip; a recursive clone under a clean configuration succeeds and validate-manifest.py, validate-pins.py and bootstrap.py pass in it.
• 10: the verification on its own, no template, on hand-made splits: the control (default and the plan's own mount paths), a swapped spec, code or both mount, at both path spellings, with the exact finding text; a mount at an OLDER commit of its own leg (the comparison is exact); and a missing mount, which stays one adopt-mount-missing.
• 2: the real _mount_the_legs over a clone made under the template, with no git filter-repo: a plain clone mounts the planted commit and the verification refuses both mounts; cloned with --template= the same mounts are the legs' tips and verify.
• 1: cmd_execute with the spec mount's checkout moved after the mount: exit 1, the finding, no adoption verified, the split pushed (git add -A restages gitlinks from the work tree, so the seam moves the checkout, not the index).

Windows: at 65073c1 tests-windows failed 12 of the 14 tests that run there (run 38182070760: 12 failed, 2062 passed, 264 skipped). Each failure had one extra adopt-lost finding for the source's README.md. The cause was in the test, not in adopt-project.py. the_source() built that file with write_text, which writes CRLF on Windows, while split_of() writes the split's copy as LF with write_bytes, so they were two blobs. Fix round 1 writes the source's README.md byte-exact too (see Fix round 1). The fix was checked on Linux under an emulation of Windows' text-mode write_text, with no git filter-repo on PATH, as the Windows job runs. At 65073c1 the emulation gives CI's result exactly: 12 failed, 2 passed, 17 skipped, the same node ids and the same blob 9495404d21b8. At 06cb68e it gives 14 passed and 17 skipped. CI on 06cb68e (run 38186199801): tests, tests-macos and tests-windows all passed, tests-windows with 2474 passed, 265 skipped and no failure.

Against main's code (06cb68e's test file in a tree at main d94d155): 19 failed, 12 passed, as 65073c1's gave on 39ac59c and on 23e16ae. The failures are the issue's: the gitlinks are the planted commit (AssertionError: the template's planted commit was ...); the clean recursive clone exits 128 (Fetched in submodule path 'code', but it did not contain ...); the no-origin variant exits 2 (error: No such remote 'origin'); and the swapped or planted mounts still end adoption verified (assert 0 == 1). The 12 that pass there are the premise, the control, and the cases that hold on main.

Mutations of 06cb68e (scratch trees, this test file run in each). Without --template= on the clone, everything else kept: 12 fail and 19 pass. The 12 are the four end-to-end tests of each of the three template cases: the verification now refuses what the clone let in, so execute exits 1 where it exits 0 with the cure, and exits 2 for the stores with no origin. All 12 need git filter-repo, so Linux and macOS guard the cure and Windows does not. Without the _mount_commit_findings call, everything else kept: 9 fail and 22 pass. The 9 are the verification tests (six swapped-mount cases, the older commit, the mount over a planted store and the cmd_execute swap), each assert 0 == 1 over adoption verified.

The control is unchanged: one source repository copied twice, the same no-template adoption by main's adopt-project.py (39ac59c) and by 65073c1's, at one work path. Result: the split branch's tree is 0025586ab8d6 on both, the legs' tips, stdout (but for the split commit's own line), stderr, the assembly's .git/modules names and .git/config are identical. Fix round 1 changes no adopt-project.py code, only a comment, so this holds at 06cb68e.

Targeted at 06cb68e, with git filter-repo 2.47.0: tests/test_adopt_clone_template.py 31, test_adopt_verify.py 16 and test_shape_doctor.py 181 passed, none failed. Merged with main d94d155 (a scratch merge, tree 662b547; this branch is not merged): test_adopt_clone_template.py 31, test_adopt_verify.py 16, test_adopt_finding_spelling.py 128 and test_shape_doctor.py 208 passed, and under the Windows emulation the new file gives 14 passed and 17 skipped. At 65073c1 the implementer's run passed 413 tests over ten adopt and CLI files, and the review's run on the merge with 23e16ae passed 732 over twelve. The full suite was not run here (CI runs it on three OSes). scripts/render-cli-reference.py --check passes at 06cb68e and on the merge, because no --help text changed.

Composes with

git merge-tree --write-tree 06cb68e <head>, for every head on origin (git ls-remote at 00:00Z): 22 heads besides main and this one, and 19 of them are clean (rc 0). main is now d94d155 and merges clean (tree 662b547; 67a398a and 23e16ae did too). fix/adopt-spell-finding-paths has landed as #223 (5751460) and is no longer a head. #270's fix/adopt-template-values-utf8 (aed9190), this lane's other adopt branch, is clean.

• fix/adopt-late-failure-notice (adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188, cdfb308), rc 1, adopt-project.py, 3 hunks, all from this change meeting adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188's rewrite of _commit_the_split and _verify. Resolve:
  1. In _commit_the_split, keep adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188's step = ... and try: block, move the # NO TEMPLATE (#243) comment inside the try:, and add "--template=", to adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188's indented clone. That clone is the run([... "clone", "-q", str(source.path), ...]) just BELOW the >>>>>>> cdfb308 marker, OUTSIDE the conflict region. Taking adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188's side of the hunk compiles, and silently drops the cure. This file's 12 end-to-end template tests catch that on Linux and macOS (without --template=, 12 fail), but Windows never runs them.
  2. In the docstrings, keep both: this change's EACH MOUNT IS THE COMMIT THAT WAS PUSHED TO ITS LEG paragraph goes into _accounted_for's.
  3. In _accounted_for, where mounts is already a parameter, write split_tree = _tree_of(assembly, split_commit), root_findings = _land_the_root_tree(after, split_tree, before, mounts) and root_findings += _mount_commit_findings(split_tree, mounts, _pushed_commits(work_root, names)). DROP this change's mounts = dict(zip((spec_path, code_path), EXTRACTED_LEGS)) line, since spec_path does not exist there. A clean text merge of that third hunk would have been a NameError, which is why the call sits in the same lines as _land_the_root_tree's and conflicts visibly.
  4. In tests/test_adopt_clone_template.py's verify() helper, pass the two keywords adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188 makes required, as adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188's own tests/test_adopt_verify.py passes urls=dict(URLS, assembly=str(source_path)), branch=SPLIT_BRANCH:

         code = adopter._verify(adopter.Source(repo, None, "main", commit), root,
                                legs.work, NAMES, PATHS_FOR, split, mounts[SPEC],
                                mounts[CODE],
                                urls={**legs.urls, "assembly": str(repo)},
                                branch=BRANCH)

     The test file shows NO textual conflict, so nothing flags this step. With (1) to (3) alone, the 12 tests that call _verify directly fail with TypeError: _verify() missing 2 required keyword-only arguments: 'urls' and 'branch'; this file then gives 12 failed and 19 passed. With (1) to (4), test_adopt_clone_template.py, test_adopt_verify.py and test_adopt_late_failure.py give 93 passed (06cb68e merged with cdfb308). Step (4) cannot be in this PR alone, because main's _verify takes no such keywords. Whichever of adopt-project.py: the assembly root is cloned with no git template and the verification refuses a mount whose gitlink is not the commit pushed to its leg (adopt-mount-commit), so an operator's init.templateDir holding modules/spec and modules/code no longer ends adoption verified over a split nobody can clone (#243) #268 and adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188 lands second applies it, and if adopt-project.py: the assembly root is cloned with no git template and the verification refuses a mount whose gitlink is not the commit pushed to its leg (adopt-mount-commit), so an operator's init.templateDir holding modules/spec and modules/code no longer ends adoption verified over a split nobody can clone (#243) #268 lands first, lane openRepoShape-1 needs telling on adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188.
• fix/adopt-record-submodule-placement (adopt-project.py: check and execute judge an entry's path by one test, entry_path_problem, that admits every path git can take literally, so a source holding My Notes.md no longer checks plan ok and is then refused by execute as unsafe-value, and a path git cannot take is a check finding refused before any leg exists (#196) #231, 2f5cda9), rc 1, adopt-project.py, 1 hunk: the module docstring's execute bullet, where this change ends "two leg mounts, each at the commit pushed to its leg." and adopt-project.py: check and execute judge an entry's path by one test, entry_path_problem, that admits every path git can take literally, so a source holding My Notes.md no longer checks plan ok and is then refused by execute as unsafe-value, and a path git cannot take is a check finding refused before any leg exists (#196) #231 continues "two leg mounts. The split's project.yaml records ...". Resolve: keep both sentences, this change's first.
• fix/adopt-root-kept-symlinks (04792d2), rc 1: one hunk in adopt-project.py's imports and one in scripts/shape_materialize.py's docstring. It conflicts with main d94d155 by itself in the same two places, and no line of this change is in either hunk, so this change adds no conflict there. Whoever rebases it resolves those first.
• fix/adopt-check-shape-paths, fix/adopt-check-unsafe-path, fix/adopt-gitmodules-rejected-values, fix/adopt-plan-quote-yaml-keywords, fix/adopt-relative-submodule-url (adopt-project.py: a relative .gitmodules url the plan keeps in a leg is resolved from the source's remote and from the leg's, and where the two differ check finds it and execute refuses before any leg exists, so a recursive clone no longer fails after adoption verified (#190) #245), fix/adopt-report-filter-repo-failure, fix/adopt-template-values-utf8 (adopt-project.py: a value execute writes into a file is asked whether a file can hold it, in plan, in check and in execute before any leg exists, so a byte that is not UTF-8 in --elected-by, --reference or a local --source directory no longer pushes both legs before write_lf raises (#255) #270), fix/plan-literal-follow-up-grep and the eleven heads that do not touch adopt-project.py: rc 0.

A design note for whoever merges next: _land_the_root_tree keeps its four-argument signature on purpose. tests/test_adopt_finding_spelling.py, on main since #223, calls it with four arguments in its helper (:349), and so does every tests/test_adopt_submodules.py call. A fifth argument would merge clean and then fail at runtime, so the comparison is its own function beside it.

Left out

• The check does not undo the push (no finding does). When it fires, the finding says the split is wrong and not to merge it, and the usual closing paragraph says the legs and the branch exist.
• The leg remotes, leg work trees and seeded legs keep the operator's template (table above).
• The assembly's split commit and push no longer run hooks a git template installs, because the assembly now has no .git/hooks (its pre-commit, commit-msg and pre-push ran there before this change), while hooks set with core.hooksPath still run there and the legs keep their template's hooks. The comment at the clone says so.
• Nothing else in adopt-project.py changes: no --help text, no plan field, no other finding.

Review

Lane openRepoShape-2's own adversarial review of 65073c1 is this comment. It found the production change sound and asked for four changes, which Fix round 1 answers. A review by another lane is welcome. Lane openRepoShape-1's #188 and lane openRepoShape-3's #231 each need the resolution given under Composes with.

Fix round 1

This answers the review of 65073c1 with two commits; the head is 06cb68e.

1. P2, cdbfb7f: tests-windows failed 12 of this PR's tests. the_source() now writes the source's README.md with write_bytes, as split_of() writes the split's, so the two are one blob on every OS. Its docstring says why. split_of() is unchanged, and write_text(newline=...) is not used because it needs Python 3.10 and the baseline is 3.9. The details are under Tests.
2. P3, this body only: step (4) of the adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188 resolution under Composes with. _verify's signature does not change in this PR.
3. P3, 06cb68e: the NO TEMPLATE (#243) comment in _commit_the_split gains one sentence on hooks, and Left out gains one bullet. No behaviour changes.
4. Nit, this body only: the Windows claim, the main sha, the landed adopt-project.py: check and execute spell every path a FINDING or a refusal names as plan's questions spell it, so a source name holding a carriage return, a line feed, U+0085, U+2028 or an ESC no longer overwrites, splits or escapes the line it is printed on (#212) #223 and resolution (1)'s warning are restated at 06cb68e.

Closes #243

🤖 Generated with Claude Code

Summary by Sourcery

Ensure adopted split roots use clean submodule stores and verify that every mount points to the commit pushed to its leg.

Bug Fixes:

• Prevent adoption from accepting mounts whose gitlinks do not match the commits pushed to their corresponding legs.
• Prevent operator Git templates from planting stale submodule repositories in the assembly root during adoption.

Enhancements:

• Add explicit verification findings for mount commits and retain missing-mount reporting without duplication.

Tests:

• Add comprehensive coverage for template contamination, mount commit mismatches, older leg commits, missing mounts, recursive clones, and end-to-end adoption behavior across supported operating systems.

[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 1 day and 14 hours by commenting @sourcery-ai review. Upgrade to get a review now.

[sourcery-ai]

Reviewer's Guide

The PR hardens adoption by cloning the assembly with no Git template so planted .git/modules stores cannot be reactivated, and independently rejects any split whose mount gitlinks do not exactly match the commits pushed to the legs. A comprehensive regression suite covers both the preventive clone behavior and verification defense, including template configuration variants, malformed mounts, and downstream recursive-clone validation.

Sequence diagram for template-safe project adoption

sequenceDiagram
    participant Execute
    participant Source
    participant Assembly
    participant Legs
    participant Git

    Execute->>Source: Source.open()
    Execute->>Git: git clone --template= source assembly
    Git-->>Assembly: Empty .git/modules
    Execute->>Legs: _extract_leg() / _seed_leg()
    Execute->>Assembly: _mount_the_legs()
    Assembly->>Git: git submodule add --force leg-worktree mount
    Git-->>Assembly: Mount leg commit and create module store
    Execute->>Assembly: git add -A and push split

Loading

Sequence diagram for rejecting an incorrect mount commit

sequenceDiagram
    participant Verify
    participant Assembly
    participant LegWorktree
    participant Result

    Verify->>Assembly: _tree_of(assembly, split_commit)
    Verify->>LegWorktree: _pushed_commits(work_root, names)
    Verify->>Verify: _mount_commit_findings(split_tree, mounts, pushed)
    Verify->>Result: Report adopt-mount-commit
    Result-->>Verify: No adoption verified

Loading

Flow diagram for mount commit verification

flowchart TD
    A[Read split tree] --> B[Build mounts mapping]
    B --> C[Read each leg HEAD with _pushed_commits]
    C --> D[_mount_commit_findings]
    D --> E{Mount has gitlink?}
    E -- No --> F[adopt-mount-missing]
    E -- Yes --> G{Gitlink equals pushed leg commit?}
    G -- Yes --> H[Continue verification]
    G -- No --> I[adopt-mount-commit]
    I --> J[Reject adoption verification]

Loading

File-Level Changes

Change	Details	Files
Prevent operator Git templates from contaminating the assembly repository used for submodule mounting.	Clone the assembly with an explicit empty Git template. Document why other repositories retain the operator template and why the assembly does not. Clarify that mounts start without pre-existing module stores.	adopt-project.py
Verify that every root mount points exactly to the commit pushed to its corresponding leg.	Build the mount mapping and split tree once during verification. Compare gitlink OIDs against each leg worktree's pushed HEAD. Emit adopt-mount-commit findings while preserving existing missing-mount behavior and push semantics.	adopt-project.py
Add regression coverage for template contamination and incorrect mount commits.	Test both init.templateDir and GIT_TEMPLATE_DIR, including planted stores without an origin. Cover end-to-end adoption, clean recursive cloning, validator execution, direct verification, older commits, missing mounts, and post-mount swaps. Assert exact findings, exit codes, pushed gitlinks, and module-store contents.	tests/test_adopt_clone_template.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#243	Prevent operator Git templates from planting repositories under the assembly root's .git/modules and being reactivated by the forced submodule mounts.	✅
#243	Make verification confirm that every mounted gitlink exactly matches the commit pushed to its corresponding leg, and refuse verification when it does not.	✅
#243	Add regression coverage for template-based planted stores, incorrect or outdated mount commits, missing mounts, recursive cloning, and the normal no-template control path.	✅

Possibly linked issues

• adopt-project.py execute clones the source with the operator's init.templateDir applied, so a template holding modules/spec and modules/code makes the leg mounts' --force (#200) reactivate those planted stores: both gitlinks pushed on the split branch are a stranger's commit, the VERIFICATION still says adoption verified because it checks a mount is present and not which commit, and the recursive clone of the result exits 128 #243: PR fixes the template-planted submodule stores and adds verification that each mount matches its pushed leg commit.

---

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-2, 2026-10-11T22:51:58Z) @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-11T23:04:04.919146Z	65073c1	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: Didn't find any major issues. 🚀

Reviewed commit: 65073c1770

ℹ️ 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".

[brettheap]

(lane openRepoShape-2, 2026-10-11T23:52:19Z)

This lane reviewed its own PR #268 at 65073c1, before any fix round, read-only in its own detached worktrees.

CHANGES NEEDED. The fix works. On main 23e16ae the issue's reproduction says adoption verified over planted gitlinks, and the clean recursive clone exits 128. At 65073c1 the gitlinks are the pushed leg tips and the clone exits 0. No false adopt-mount-commit appeared for nested mount paths, a seeded leg, a trunk tracking branch or GIT_TEMPLATE_DIR.

1. P2: tests-windows fails 12 of the new tests (run 38182070760), while main passes there. the_source() at tests/test_adopt_clone_template.py:384-388 builds README.md through make_source_repo's write_text, which writes CRLF on Windows (blob 9495404d21b8). split_of() at :391-405 writes it as LF with write_bytes, so _verify rightly reports adopt-lost. Writing the source byte-exact fixes it under a Linux emulation of Windows: 12 failed before, 14 passed and 17 skipped after.
2. P3: lane 1's adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188 makes urls and branch required keywords of _verify. Resolved as the body says, head plus cdfb308 fails 12 tests with TypeError, and the test file shows no textual conflict. The verify() helper at :408-416 needs both keywords; with them, 93 pass. Whichever PR lands second applies this.
3. P3: --template= (adopt-project.py:2757) also stops hooks installed by the operator's git template from running on the split commit and push. Main ran them, and core.hooksPath hooks still run. The comment and the body should say so.
4. Nit: the body's Windows test claim, its main sha and its adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188 recipe are stale.

Tests: head's test file against 23e16ae's code gives 19 failed and 12 passed, for the issue's reasons. Mutants are killed: without the flag 12 fail, without the check 9 fail. 23e16ae plus head passes 732 tests across twelve adopt, doctor and CLI files, and render-cli-reference.py --check passes.

Merges: head merges clean with main 23e16ae and 67a398a, and with seven adopt heads including #270. #188 (3 hunks) and #231 (1 hunk) resolve as the body says, plus item 2 for #188. fix/adopt-root-kept-symlinks conflicts with main itself in the same hunks.

The full report is handoffs/xFactory/attachments/lane-openRepoShape-2/review268-65073c1/final-report.md in opensoft/brett-wip.

[brettheap]

(lane openRepoShape-2, 2026-10-12T00:40:41Z)

This lane re-verified its own PR #268 at 06cb68e after fix round 1, read-only in its own detached worktrees.

MERGEABLE WITH NITS. Before landing, update the branch onto current main ede15ce and get fresh three-OS CI. Whichever of #268 and #188 lands second applies the body's step (4).

1. Windows fix: verified. Under a Linux emulation of Windows text writes, 06cb68e gives 14 passed and 17 skipped without git-filter-repo, and 31 passed with it. Nothing else in the test file depends on text-mode writes.
2. adopt-project.py: a failure AFTER both legs are pushed (the split-branch push, the mount, the split commit) prints only REFUSED <step> with no notice of what already exists and no stdout flush, so the combined log shows REFUSED before the bare … lines and the re-run meets leg-remote-exists unexplained #188 step (4): verified as written. 06cb68e merged with cdfb308 and resolved by steps (1) to (4) gives 93 passed.
3. The comment at adopt-project.py:2756-2760: verified clause by clause. Template hooks no longer run in the assembly, core.hooksPath hooks do, and the legs keep theirs.
4. Body claims and counts: verified. Nits: the Left out hook bullet's "because" clause is misplaced, and its main sha and head counts date from 00:00Z.

Tests: main be2790e plus 06cb68e passes 749 tests across twelve adopt, doctor and CLI files. Head's tests on main's code give 19 failed and 12 passed. The mutants are killed: 12 failed without --template=, 9 failed without the check.

CI: run 38186199801 is green on Linux, macOS and Windows (2474 passed, 265 skipped). It tested the merge with d94d155.

Merges: clean with main be2790e and ede15ce. #188 cdfb308 has 3 hunks and #231 f38d543 has 1, both as the body says.

The report is handoffs/xFactory/attachments/lane-openRepoShape-2/review268-65073c1/reverify-1.md in opensoft/brett-wip.

[sonarqubecloud]

Quality Gate passed

Issues
0 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