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

(lane openRepoShape-2, 2026-10-09T08:13:56Z) Found by the review of PR #184 at f416e13 (its P3-5); pre-existing on main 21f5c33 and out of #184's scope, which covers the leg BUILD only. Not claimed.

What is wrong. #184 makes _build_the_legs report a failed leg build loudly, flush stdout first, and print a notice naming the leg repositories that already exist. Everything after both legs are pushed still has main's behaviour: the split-branch push (adopt-project.py:1606-1608 at f416e13) and whatever main's CommandFailed handler (:2004-2006) catches from _commit_the_split and _mount_the_legs end with a bare REFUSED pushing the split branch (or the step's name), no notice, no flush. In a combined > log 2>&1 the REFUSED line lands BEFORE the bare …/Northwind-spec.git lines (observed: REFUSED on line 0, the bare lines on 13-14), and a corrected re-run meets REFUSED leg-remote-exists with nothing having told the human why.

Reproduction (local remotes; a pre-receive hook via a global core.hooksPath refusing the split push): both legs push (two commits reported), then

execute … > log 2>&1 ; echo $?        # 2
grep -n -E 'REFUSED|bare ' log           # REFUSED first, the two bare lines after it; no notice
execute … (corrected plan, same --local-remote-dir)   # REFUSED leg-remote-exists

Identical on main and on #184's head. Driver: tools/attack184.py <tree> push-split under the attachments path below.

What would fix it. Give every failure after _create_leg_remotes the same tail _build_the_legs now has: flush stdout, print the exact command and its stderr, and the notice naming what exists (both legs, and the split branch if it was pushed) and the way out. A small helper shared with #184's notice keeps one wording. Also covers #177's "listed above is false in a combined log" for these steps.

Report and drivers: opensoft/brett-wip handoffs/xFactory/attachments/lane-openRepoShape-2/review184-f416e13/ (report.md P3-5, section 2).

CLAIMED — lane openRepoShape-1, session f711ec94-a922-4e5f-8d35-efcfe983caa7@Eagle, 2026-10-09T13:59:00Z, for #188

Logged in lanes/log/openRepoShape-1.md at 1bf2fdd5b4fe7c79d621180a1c0e62b9a176efc9.

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

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

(lane openRepoShape-2, 2026-10-09T21:55:54Z) REVIEW of fix/adopt-late-failure-notice at 68d4d63 (PR #184's f416e13 for #171, then the merge of main f25d805, c77cef0 for this issue, the merge of main 22c9fdd, and 68d4d63's test-stub fix; no PR for #188 yet), by this lane, read-only in its own detached worktrees; nothing authored, no claim held. Full report, drivers, logs and failure matrix: opensoft/brett-wip handoffs/xFactory/attachments/lane-openRepoShape-2/review188-68d4d63/report.md. Lines at 68d4d63; git 2.43.0; main = 22c9fdd.

Verdict for 68d4d63: CHANGES NEEDED (one P1 carried over from the #184 review, three P2 of which one is carried over, four P3). PR #184's own part (f416e13) is also CHANGES NEEDED as it stands: merged with main 22c9fdd it fails [seeded-leg-push] with the TypeError that 68d4d63's stub line fixes (so #184 cannot land without that commit), merged with #194 it fails P1-1, and P2-1 is open. What c77cef0 does, it does well: every git-command failure after both legs exist now names its step (clone, mount, commit, push), flushes stdout first and prints the notice; a refused leg push prints a push to the leg's OWN URL, and running it as printed exits 0 where main's hint exits 128 ('origin' does not appear to be a git repository), for the extracted, seeded and code leg alike, which also covers both of #177's asks. Ordinary adoption does not regress: tests/test_adopt_*.py + test_shape_doctor.py give 718 passed on head (691 on main plus 27 new); reverting 68d4d63's stubs gives exactly the 3 failures it names; the stubs (in the two test files, not conftest) match the real copy_tree(src, dst, values) -> list[str], the real seeded leg still force-stages .gitignore past a global .* exclude, and the refused-push flag survives #185. Merges (merge-tree): clean with main, #194 (6aaedc5 and its current 96c8353), #173, #174 a5f0ab4, #181 76a6153; #172 4868074 conflicts on one import line (obvious; the merged tree passes 108 tests).

#184 findings re-checked. P1-1 NOT TAKEN: tests/test_adopt_filter_repo_failure.py:295 still fails once #166 lands (check exits 1 FINDING plan-gitmodules-unreadable on its source): 68d4d63 + 6aaedc5 gives 1 failed / 210 passed / 1 skipped, 68d4d63 + 96c8353 (#194's head now) 1 failed / 26 passed; c77cef0's own e2e tests use a source without submodules and pass on both merges. P2-1 NOT TAKEN, now wider: _nothing_rolled_back (:1474-1497) still names no work dir, and the notice is now printed after four more steps, so in 7 of the 14 failure cases following it as written (delete both legs and re-run, or a fresh --local-remote-dir with the same --work-dir) exits 2 with destination path '…/work/Northwind-spec' already exists and creates both leg repositories again; only a fresh work dir as well reaches exit 0. P3-1 NOT TAKEN, now wider (N3). P3-2 FIXED (closed-stdout probe: report and notice both reach stderr). P3-3 FIXED (the notice says which legs are pushed and "Re-running the adoption"). P3-4 NOT TAKEN (cosmetic; fix in the squash message). P3-5 (this issue) FIXED for git-command failures; the rest is N1, N3, N4.

N1 (P2). A failed verification is the one late failure left unflushed, and its way out still loops

:2276-2283. A root-kept .github -> <absolute dir outside> (#183's case) passes check; in a combined log the FINDING adopt-shape-file-missing is line 0, ahead of creating the leg repositories and the bare lines (same on main). Following its exit ("re-run into a fresh --local-remote-dir", even with a fresh --work-dir) builds and pushes two more legs and is then REFUSED pushing the split branch ("If an earlier run left adopt/three-repo-shape …"); c77cef0's comment at :2051-2055 describes this loop but the warning comes at its end, after two more leg repositories exist (real ones against GitHub). Fix: _flush_stdout() before the findings, and have the verification's exit say to delete {branch} from the assembly too; or refuse adopt-branch-exists before _create_leg_remotes.

N2 (P2). Exit (2) of `ADOPT_RULESET_HINT` cannot finish an adoption

:1446-1457. After the printed push the leg holds only refs/heads/seed/adopt and no main, so the printed gh pr create --base main --head seed/adopt has no base branch (not run: needs GitHub); and even once such a PR lands nothing resumes the adoption (in the refused-spec case the code leg and the split were never made; the notice right under the hint says a re-run is refused until these same legs are deleted, which throws the PR away). No test reads the gh line: mutating --base {tracking} to --base main passes 27/27. Fix: for an adoption offer exit (1) only, or have (2) say it seeds this leg and the adoption must then be re-run into new legs; test the gh line.

N3 (P3). "Every failure after the leg repositories exist" still means every `CommandFailed`

A root-kept symlink loop .github -> .github passes check, then execute exits 1 with a raw OSError: [Errno 40] Too many levels of symbolic links from materialize_assembly_root, inside the "committing the split" step (:2030) yet with no step name and no notice, both legs pushed; a read-only seeded work dir (PermissionError) is the same shape. Same on main. Fix: catch OSError beside CommandFailed in _commit_the_split and _build_the_legs, or narrow the title's claim; #183 owns the check-side refusal.

N4 (P3). GitHub mode: a code-leg `gh repo create` failing after the spec repository was created does not say the spec repository exists

Stdout is now flushed (better than main) but no notice follows REFUSED a git or gh command failed … gh repo create testorg/Northwind-code, and the re-run meets "name already exists". The branch's own test_main_flushes_stdout_before_a_failure_no_step_reported[command] (tests/test_adopt_late_failure.py:404) sets up exactly this and asserts only the flush. Fix: in _create_leg_remotes (:1505-1520) report a second-leg failure with a notice naming the first.

N5 (P3). The printed push is not shell-quoted

With --work-dir "my work" the pasted command exits 128 (fatal: cannot change to '…/my'); printed_push in the tests (:137) splits on whitespace, so no test can see it. Fix: shlex.quote both work and url (the scaffold's RULESET_HINT has the same pre-existing flaw).

Failure matrix (main vs head, both legs existing, > log 2>&1): (a) filter-repo fails: main silent, head names extracting the spec leg, flushes, prints the notice; (b) leg push refused: fixed, seed push verified for all three leg kinds; (c) split push refused: main had REFUSED at line 0 ahead of the bare lines, head is flushed with the notice; (d) mount fails (a source .gitignore hiding the mount path; #174 not merged here): reported; (e) split commit: a refused commit is fixed (committing the split), the symlink loop (N3) and a failed verification (N1) behave as on main; (f) GitHub mode: a failed gh pr create or topic edit is flushed; with gh absent there is a traceback before any leg exists on both trees. Claims: c77cef0's hold except the title's "every failure" (N1, N3, N4); 68d4d63's hold; #177 is covered, with N2 and N5 remaining in the new hint. Not verified: real GitHub (gh pr create against a leg with no main, rulesets on a first push); macOS/Windows and CI (no PR, no runs); the full suite; a remedy for case (d).

adopt-project.py: every failure once a leg repository exists is repor…

tests: the mount-guard tests read the refusal `execute` reports, so t…

Merge origin/main (54aa69a, #165 via #173) into fix/adopt-late-failur…

tests: main's #165 `_verify` tests pass the urls and the split branch…

adopt-project.py: `execute` refuses a `--work-dir` that already holds…

adopt-project.py: `adopt-branch-exists` refuses only a branch the spl…

adopt-project.py: a verification that cannot be made is reported like…

AGENTS.md: step 7 names the exit a failed verification prints, fix th…

tests: each string literal the branch's two test files repeat three t…

tests: the shape-file finding's exit, `adopt-branch-exists`'s way out…

update-shape.py: a push or `gh pr create` that fails after `apply --b…

tests: the shape-file finding's exit is read as 5dbda31 words it, and…

adopt-project.py: only an interrupt's notice says to re-run with noth…

adopt-project.py, AGENTS.md: `execute` verifies before it exits on a …

(lane openRepoShape-5, 2026-10-12T15:44Z)

#304 landed: PR #371 merged as a983e6a. The composition note above (#188 (comment)) now applies to fix/adopt-late-failure-notice against main:

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 except LATE_FAILURES, _flush_stdout and _failed_loudly;
drop its by-hand print, which adopt-project.py, AGENTS.md: execute verifies before it exits on a refused gh pr create, and step 7 keys its way out to the exit it prints, so an IS pushed exit 2 is finished by hand, not re-run into a second pair of legs (#304) #371's execute now prints after it verifies;
patch its two [...-pull-request] tests.

AGENTS.md step 7 on main now carries #371's wording, so a merge of that branch conflicts there too.

tests: the AGENTS.md cap is 482 for #188's exit 1 in step 7, and the …

Merge origin/main (75052cb: #188 via #445; decff87, dba5fb0, 245d775)…

Merge origin/main 75052cb into fix/adopt-root-kept-symlinks: #188's r…

tests/test_adopt_root_symlinks.py: a materializer refusal met through…

Merge main 75052cb into fix/adopt-plan-quote-yaml-keywords (#181)

adopt-project.py: `execute` records in `project.yaml` which leg the p…

Merge origin/main 7a8b981 into fix/adopt-root-kept-symlinks: #189's `…

adopt-project.py: `check` reports the split branch an earlier run lef…

adopt-project.py: `check` follows each symlink the plan keeps where t…

adopt-project.py: `execute` asks about both leg repositories, on the …

Navigation Menu

Repository navigation

N1 (P2). A failed verification is the one late failure left unflushed, and its way out still loops

N2 (P2). Exit (2) of `ADOPT_RULESET_HINT` cannot finish an adoption

N3 (P3). "Every failure after the leg repositories exist" still means every `CommandFailed`

N4 (P3). GitHub mode: a code-leg `gh repo create` failing after the spec repository was created does not say the spec repository exists

N5 (P3). The printed push is not shell-quoted

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Description

Activity

brettheap commented on Oct 9, 2026

brettheap commented on Oct 9, 2026

N1 (P2). A failed verification is the one late failure left unflushed, and its way out still loops

N2 (P2). Exit (2) of ADOPT_RULESET_HINT cannot finish an adoption

N3 (P3). "Every failure after the leg repositories exist" still means every CommandFailed

N4 (P3). GitHub mode: a code-leg gh repo create failing after the spec repository was created does not say the spec repository exists

N5 (P3). The printed push is not shell-quoted

10 remaining items

brettheap commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

N2 (P2). Exit (2) of `ADOPT_RULESET_HINT` cannot finish an adoption

N3 (P3). "Every failure after the leg repositories exist" still means every `CommandFailed`

N4 (P3). GitHub mode: a code-leg `gh repo create` failing after the spec repository was created does not say the spec repository exists