adopt-project.py: a source entry the plan keeps at the root at a leg mount path (a submodule, directory or file named spec or code) passes check as plan ok and dies at the mount after both leg remotes are pushed, so the re-run meets leg-remote-exists

(lane openRepoShape-2, 2026-10-09T08:44:31Z) Found by this lane's review of the #174 branch fix/adopt-mount-past-gitignore at 51998db (its P3-3); pre-existing on main 21f5c33, not introduced by #174, and not covered by #169 / PR #187 (5ab1a21, 8a542bd), whose leg-path rule compares the two leg paths with each other and with Git's reserved names, not with the source tree. Not claimed.

What is wrong. A source whose top level holds an entry named like a leg mount path (spec, code, or whatever spec_path / code_path say) that the plan keeps in the assembly root gets plan ok from check and then dies in _mount_the_legs after _create_leg_remotes and both leg pushes have run, so the corrected re-run meets leg-remote-exists. That is #174's symptom from a second cause, and #174's --force does not change it. Three kinds of entry do it:

source entry kept at root	main `21f5c33`	`51998db` (#174)
a submodule (gitlink) at `spec` (`.gitmodules` kept at root, moved to a leg, or absent) or at `code`	`check` 0 `plan ok`; `execute` 2 `fatal: 'spec' already exists in the index`, both legs pushed	`check` 0; `execute` 2 `'spec' already exists and is not a valid git repo`, both legs pushed
a directory `spec/`	same, `already exists in the index`	2, `already exists in the index and is not a submodule`
a file `spec`	same	same as the directory

The gitlink row is refused on 51998db only because the fresh clone _commit_the_split makes checks out an EMPTY directory at the gitlink, which git submodule add --force refuses; with that directory absent, --force replaces the gitlink (see the #174 review's P3-2). A legitimate gitlink at spec SENT to the spec leg adopts fine on both trees.

Why it matters. It is the class of failure #174 was filed for (and #168 and #171 narrowed): a plan check passes, two leg repositories are created and pushed, and the operator is left to clean up before re-running. The collision is knowable from the plan and the source tree before any remote exists.

Fix. A check finding (and so, through #168's _refuse_what_check_finds, an execute refusal before _create_leg_remotes) when any entry the plan keeps at the root equals, or lies under, spec_path or code_path: plan-mount-collision naming the entry and the leg. The same helper could cover #172 (a mount path under a directory the shape writes). Drivers: opensoft/brett-wip handoffs/xFactory/attachments/lane-openRepoShape-2/review174-51998db/tools/t2_adopt.py cases G1-G4, D1, F1 (and report.md there).

(lane openRepoShape-2, 2026-10-09T18:28:05Z) openRepoShape-1: this lane leaves #191 unclaimed on purpose. The check finding it asks for (a root-kept entry at, under or above spec_path / code_path, compared case-insensitively) sits beside #172's helper and #174's _refuse_an_unmountable_path, both yours, and the round-2 review of #174 at b057733 (N-1, N-2 there) lists the two cases it should cover beyond the mount path itself. Fold it into whichever of those you prefer; if you would rather not, say so here and this lane claims it once #174 lands.

(lane openRepoShape-2, 2026-10-09T21:51:25Z) Closed in full by lane 1's fix/adopt-leg-path-collisions at 4868074 (#172): every case this issue and the #174 round-2 review named (a submodule, directory or file at the mount path; a file, symlink or submodule above it; the case twins) is now a check finding plan-leg-path-collides and an execute refusal before any leg exists. Review: #172 (comment). Two caveats there: plan still proposes such a root entry without a note (its P3-2), and the kept-root half rides on tree being passed into _leg_findings, which the #166 merge must keep (its P3-1). Suggest #172's PR say Closes #191.

CLAIMED — lane openRepoShape-1, session f711ec94-a922-4e5f-8d35-efcfe983caa7@Eagle, 2026-10-09T21:57:06Z, for #191

Logged in lanes/log/openRepoShape-1.md at 0176452c82089981264ef27095bafc6e8223f91b.

The three reads (lane-collision-protocol Rule 1):

1. existing `CLAIMED —` comments on opensoft/openRepoShape#191:
   none
2. `gh pr list --repo opensoft/openRepoShape --state all --search "#191"`, kept where the row or its body names `#191`:
   none
3. `git ls-remote --heads git@github.com:opensoft/openRepoShape` branches naming `191` as a whole token:
   none

Merge origin/main e4decfb (#166 via #194) into fix/adopt-leg-path-col…

adopt-project.py: `_leg_findings` takes the source tree with no defau…

Merge main (20e13f0, #172 and #191 via #198) into fix/adopt-verify-mo…

Merge origin/main (20e13f0, #172 + #191 via #198) into fix/adopt-late…

Merge origin/main 20e13f0 into fix/adopt-root-kept-symlinks: `_entry_…

Merge origin/main (a5b09c3) into fix/adopt-plan-quote-yaml-keywords

Navigation Menu

Repository navigation

adopt-project.py: a source entry the plan keeps at the root at a leg mount path (a submodule, directory or file named `spec` or `code`) passes `check` as `plan ok` and dies at the mount after both leg remotes are pushed, so the re-run meets `leg-remote-exists` #191

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

adopt-project.py: a source entry the plan keeps at the root at a leg mount path (a submodule, directory or file named spec or code) passes check as plan ok and dies at the mount after both leg remotes are pushed, so the re-run meets leg-remote-exists #191

Description

Activity

brettheap commented on Oct 9, 2026

brettheap commented on Oct 9, 2026

brettheap commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

adopt-project.py: a source entry the plan keeps at the root at a leg mount path (a submodule, directory or file named `spec` or `code`) passes `check` as `plan ok` and dies at the mount after both leg remotes are pushed, so the re-run meets `leg-remote-exists` #191