Repository navigation
adopt-project.py: what plan, execute and AGENTS.md say around a run is what the run does: the plan's last follow-up is a review of the pull request execute opens itself, a failed verification names the pull request and the topic it left in place, AGENTS.md says check passes an answer with no resolution:, NEXT under --local-remote-dir names the split's branch, and the ruleset hint no longer calls a seed branch and a pull request the scaffold's other exit (#523) - #582
Merged
Merged
Conversation
…un is what the run does: the plan's last follow-up is a review of the pull request `execute` opens itself, a failed verification names the pull request and the topic it left in place, AGENTS.md says `check` passes an answer with no `resolution:`, NEXT under `--local-remote-dir` names the split's branch, and the ruleset hint no longer calls a seed branch and a pull request the scaffold's other exit (#523) - N1: the plan's last follow-up said "open the split as a pull request …; the legs <Project>-spec and <Project>-code are seeded before it", and the split commit and the pull request's body list it under the FOLLOW-UPS the commit does NOT do, though against GitHub `execute` opens that pull request itself, and the legs are extracted. It is now a review of the root's diff with the two new repositories `execute` creates and pushes before the split, and says `execute` opens the pull request itself, still naming its base by the plan's `tracking_branch` key (#493's review, F3). - auA-12: against GitHub `execute` sets the topic and opens the pull request before it verifies, so a failed verification leaves both in place, and neither the exit-1 text nor AGENTS.md said so (AGENTS.md said "the source is untouched"). `_finish_by_hand` now names the open pull request as one for a failed split, which deleting its branch (the way out's command) closes, and the topic as staying set; AGENTS.md step 7 says the split branch is pushed and, on GitHub, its pull request may be open and the topic set. - N3: AGENTS.md step 2 said an answer with no reason "will be read as a finding"; `check` never reads `resolution:` and says `plan ok`. It now says `check` passes it and the human reads the reasons at step 4. - Ruleset hint: `ADOPT_RULESET_HINT` called a seed branch and a pull request "the scaffold's other exit", which #506 removed from the scaffold. It names that route only as what cannot finish an adoption. - N2 (rides along): under `--local-remote-dir` no pull request is opened, yet NEXT said "review the pull request" and cloned the default branch. It names the split on its branch and clones that branch. AGENTS.md stays at its 490-line cap: the two-line "`execute` opens a pull request …" paragraph is folded, nearly word for word, into step 4. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
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 22 hours by commenting |
Reviewer's GuideThis PR is a user-facing accuracy pass for adopt-project.py and AGENTS.md: it revises plan/check guidance, failure recovery output, ruleset wording, and local-mode NEXT instructions to match the actual execution paths, with exact-output regression tests covering GitHub and local runs. Sequence diagram for execute verification failure recoverysequenceDiagram
participant User
participant Execute
participant GitHub
participant Source
participant Repositories
User->>Execute: cmd_execute
Execute->>Repositories: _set_the_topic
Execute->>GitHub: _open_the_pull_request
GitHub-->>Execute: pull request opened
Execute->>Execute: _verify
Execute-->>User: verification failed
Execute-->>User: name open pull request and topic left in place
User->>Source: delete split branch
Source-->>GitHub: branch deletion closes pull request
User->>Execute: re-run
Execute->>Repositories: set topic again
Sequence diagram for local execute follow-upsequenceDiagram
participant User
participant Execute
participant LocalRemote
User->>Execute: cmd_execute --local-remote-dir
Execute->>LocalRemote: push split branch adopt/three-repo-shape
Execute-->>User: review split on its branch
Execute-->>User: clone branch with git clone -b adopt/three-repo-shape
Note over Execute,LocalRemote: No pull request is opened
Flow diagram for plan and execute follow-up ownershipflowchart LR
Plan[plan prints follow-up] --> Review[review root diff with spec and code repositories]
Review --> Execute[execute creates and pushes repositories]
Execute --> Mode{execution mode}
Mode -->|GitHub| PullRequest[execute opens split pull request]
Mode -->|--local-remote-dir| Branch[review split on pushed branch]
File-Level Changes
Assessment against linked issues
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
…es `-c protocol.file.allow=always` and names the repository the split is pushed to, so it clones both legs and bootstraps when pasted as printed, and a failed verification says a leg left behind keeps the topic (#523) #582's review (RV582), fix round: - MUST: NEXT under `--local-remote-dir` printed `git clone --recurse-submodules -b adopt/three-repo-shape <X url>`. Pasted, it died `transport 'file' not allowed` for both legs, because the split's `.gitmodules` names each leg by its plain path. The line is now `git -c protocol.file.allow=always clone --recurse-submodules -b <branch> <source>`, from the module's `FILE_PROTOCOL`. Branch and url are quoted for `sh`. The url is the source the split is pushed back into, not a placeholder (the review's nit 4). The GitHub-mode NEXT is unchanged. - The e2e test parses NEXT's clone line and runs it as printed. The only change is the transport every test gives a just-pushed remote (#440): `--no-local`, and leg paths read as `file://`. It then runs the printed bootstrap in that clone. The fixture's own clone, which passed while the pasted line failed, is no longer used. The unit test asserts the arguments, `-c protocol.file.allow=always` among them. - nit: the failed-verification topic sentence said "the re-run sets it again", which a leg left behind by a re-run into fresh legs does not get undone. It now says "the re-run sets it again on the root and the legs it makes, and a leg left behind keeps it". - nit: `test_step_7_says_what_a_failed_verification_leaves_on_github` drops two asserts that checked only the test's own constants. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 15, 2026
…581's conftest import with #582's follow-up import, and fail #582's verification test with #581's hook Two resolutions, one textual and one semantic: - tests/test_adopt_github_exits.py, the import block (the only conflict). Kept #581's whole `from conftest import (ADOPT, REPO, WINDOWS_SKIP, a_hook_that_unstages, git, make_source_repo, run_script, write_plan)`, and #582's `from test_adopt_tracking_branch import OPEN_THE_SPLIT, PULL_REQUEST_FOLLOW_UP` after it. - tests/test_adopt_github_exits.py, `test_a_failed_verification_says_what_it_left_in_place` (#582's). #581 (#524) refuses a kept `contracts/shape-pin.yaml` before any leg exists, so it deleted `FAILING_TREE`, `CONTRACTS_TO_SPEC` and `KEEP_CONTRACTS`, and renamed `github_run`'s `keep_contracts` to `failing`, which fails the verification with `a_hook_that_unstages`. The test now calls `github_run(tmp_path, refuses, failing=True)`. No other use of the removed names is left in tests/. AGENTS.md step 7 and the auA-12 texts name no cause of a failed verification, only what one leaves in place, and #581 changes neither, so neither needed an edit. The auto-merged adopt-project.py and tests/test_adopt_late_failure.py carry exactly main's change (the same `git patch-id` as 2e6c6fa..fb786c1). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
brettheap
added a commit
that referenced
this pull request
Oct 15, 2026
…e `--link-source` is the first chain link's tree alone, and a source that names no path is refused (#441, #442) (#576) **README change.** This PR edits one README paragraph. #551 is on main and this branch has merged it, so the handbook step follows #551's rule: the three page parts that read the README section "The three legs" record its new hash. No page text changes. ### #441: one bare tree answered for two links `link_pins_from_trees` passed its `default_source` to every link of a recorded chain. That value is the naming gate's bare `--link-source PATH`, and the scaffold's `--pin-source`. In the chain `openXdox → openYdox → openInk`, with one bare tree that is `openXdox`'s, `openYdox` was read from the same `project.yaml`. That file declares `openYdox`, not `openInk`, so the gate said "openYdox declares openYdox, not openInk". For `codexInk`, which holds no direct pin on its referent, that was a FINDING, exit 1, for a chain that holds. The scaffold refused the same chain as `chain-not-declared`. Now: - **Which links read a bare value (for #540 and anyone else relying on it):** only the FIRST link of each chain, `links[0]`, the pin the project holds. That is true for a chain of any length, one link included: a chain of one link has only its first link, and that link reads the bare tree as before. A later link is never offered the bare value. It is read from its own `LINK=PATH`, its `SHAPE_PIN_SOURCE_<LINK>` or a checkout beside the project; otherwise it is declared-unverified (a warning, exit 0). For the first link the order is unchanged: keyed, variable, checkout beside the project, then the bare value. - `link_pins_from_trees` and `resolve_link_source` keep their signatures and return shapes. The only code change in `repo_shape.py` is `None if index else default_source` in the loop. - The two-link case (`openXdox → openDox` with a bare path) reads exactly as before and prints the same lines. The one difference is inside the returned mapping, and only for a chain of two or more links: the chain's END link no longer gets an entry read from the bare tree. Nothing reads that entry; only holders' declarations are read. In a chain of one link the only link is both the first and the end, and it still reads the bare tree, as before. - In the naming gate, `LinkSources` finds the first link of every chain a name will READ before any chain is read. `_first_links_read` uses the same `reads_link_declarations` test the lookup uses, and counts a chain only if it has two or more links: a chain of one link has no holder, reads no declaration, and so has no first link to count. The bare value is offered only while there is at most one first link: with a lone one-link chain there are none, and the bare tree is still returned for that chain's link to read, as before (nothing reads what it finds, so the output is unchanged). If a run reads two chains that begin at different links (a name on the command line plus `--project`, or one project with two legs), the bare value is read for neither. Before, one tree answered both, and `used` counted it once. - A bare value no link took is a NOTE saying why. In a two-link run the sentence is the one it always was. In a longer chain it reads "a bare PATH is the tree of a chain's first link alone, openXdox, which had a more specific source (...)". With two first links it reads "the chains read here begin at openXdox, openYdox: name the link it is, as --link-source <link>=PATH". ### #442: an empty path was the current directory `--link-source openXdox=` and `--pin-source openXdox=` became `Path("")`, which is `.`. From a project root, the naming gate read the project's own manifest as `openXdox`'s and called the chain broken. `validate-pins.py` asked the project root for the pinned commit, and its finding blamed `.`. Now both tools refuse, exit 2, naming the key: ``` REFUSED link-source-no-path: `--link-source openXdox=` names no path for openXdox. An empty path would be read as the directory this runs in. Give the tree's path (`--link-source <link>=<path>`), or `.` to mean this directory. REFUSED pin-source-no-path: `--pin-source openXdox=` names no path for openXdox. An empty path would be read as the directory this runs in. Remediation: give the checkout's path (`--pin-source <product>=<path>`), or `.` to mean this directory. ``` - An empty bare value (`--link-source ''`, `--pin-source ''`) is refused the same way. - A typed `.` still means the current directory. - A value whose key is NOT a chain link or a declared pin (`openZdox=`) is still the bare PATH `openZdox=`, as #338 and #295 decided. It is not empty, so it is not refused. - **Behaviour change: an empty value is refused even when a later value replaces it.** `--link-source openXdox= --link-source openXdox=<tree>` was a NOTE ("the later `--link-source ...` replaced it"), exit 0. It is now `REFUSED link-source-no-path`, exit 2. `validate-pins.py` changes the same way: `--pin-source openXdox= --pin-source openXdox=<clone>` was `pins ok`, exit 0, and is now `REFUSED pin-source-no-path`, exit 2. A typo is a typo, and the refusal names it when it is typed; a script that passed an empty value first and the real one after must drop the empty one. - The naming gate refuses in `main`, right after the values are read and before stdin is read or any name is classified, like its own `REFUSED naming-no-target`. - `validate-pins.py` raises a `Refusal` from `PinSources`. It reaches `main`'s existing handler with its own remedy, not the lockstep one. **It is raised late:** `PinSources` is built inside `_check_neutral_product_pins`, which `_run_all_checks` calls after `_check_leg` and `_check_shape_pin`. So an earlier refusal wins: a damaged `contracts/spec-pin.yaml` plus `--pin-source openXdox=` prints `REFUSED pin-tag-only`, and the empty path is named on the run after that is fixed. The hunk stays inside `PinSources` on purpose, to stay clear of the lines #539 edits in `_run_all_checks`. The refusal also has to wait for the declared pins, because they decide whether `openXdox=` is keyed or a bare PATH. Nothing is printed before the refusal, and the exit is 2 as in every other refusal of that tool. ### Docs - `--help` for `--link-source`, the naming validator's module docstring (exit code 2 included), `resolve_link_source`'s rule 4, `link_pins_from_trees`'s docstring and the scaffold's `_declaration` docstring say what a bare value means in a longer chain. - The `--link-source` help also says that a bare PATH is read for neither link when the chains read begin at two different links, and that a later link is read from its own `PRODUCT=PATH`, its `SHAPE_PIN_SOURCE_<PRODUCT>` or a checkout beside the project (it said "needs its own `PRODUCT=PATH`"). - `docs/cli.md` is regenerated. - README's lookup-order sentence now reads "then a bare `--link-source <path>`, for the first link's tree only: the order `validate-pins.py` uses below for the same checkout." The paragraph keeps its 12 lines, and README keeps its line count. - The handbook names no `--link-source`. The three parts that read "The three legs" (the masthead, "Reading private legs in CI", "The three legs, and naming") move to that section's new hash, 6ebed796 → 39ec2c23. No other README section changed. - `validate-pins.py`'s `--help` and EXIT CODES docstring do not name `pin-source-no-path`. Nothing in them is false: the exit-2 list gives examples. I left them, because the module docstring sits near lines #539 edits. The review of 04c9d77 (APPROVE WITH NITS) found five nits. Each, and what this commit does: 1. **A chain of one link counted as a first link.** `--referent-chain openInk` beside a project whose leg records `openXdox → openQuill`, with a bare `openXdox` tree, gave two first links, so the bare tree went to neither. `codexQuill`, verified through it on bfed143, was declared-unverified, with a NOTE naming `openInk` as a first link. Both places now count `chain[0]` only when the chain has more than one link: `_first_links_read`, and the `firsts` update in `LinkSources.link_pins`. The run is verified again, with no WARNING and no NOTE, as on bfed143. New test `test_a_chain_of_one_link_is_no_first_link_read`. 2. **A test gap: the project half of `_first_links_read`.** Reverting `if data is not None:` to `if False:` (mutation M14) left all 20 tests passing, yet it changes the output for one project whose two legs begin at different links: the first classification pass counted the bare value used, and the NOTE went missing. New test `test_a_project_whose_legs_begin_at_two_links_reads_a_bare_tree_for_neither`: `openXdox → openInk` and `openYdox → openQuill` in one project, a bare `openXdox` tree, two WARNINGs and the two-first-links NOTE. M14 now fails it (see the mutation probes). 3. **`pin-source-no-path` is raised late in `validate-pins.py`.** No code change. The behaviour and the reason are written above, under #442. 4. **The `--link-source` help.** It now says a bare PATH is read for neither link when the chains read begin at two different links, and "needs its own `PRODUCT=PATH`" now names the variable and the checkout beside the project too. `docs/cli.md` is regenerated, and `render-cli-reference.py --check` is ok. 5. **This body.** It now says: #539 is on origin and merges clean (see the merge checks); an empty value is refused even when a later one replaces it; the END-link sentence holds for chains of two or more links; and the checklist candidate below. The commit changes `scripts/validate-repository-naming.py`, `docs/cli.md` and `tests/test_link_source_chain_defaults.py` only. The re-review of 31a6f21 (APPROVE WITH NITS) found that all five nits are fixed, and two new ones. This commit changes `tests/test_link_source_chain_defaults.py` only. - **A test gap at the two-link boundary of `link_pins`.** Changing `if len(target.chain) > 1:` there to `> 2` passed the whole new file and `tests/test_naming_policy.py` (264 passed), yet it changes the output for a name read from stdin whose chain has two links: the first-link list is empty, and the NOTE for an unused bare value reads "a bare PATH is the tree of a chain's first link alone, , which had a more specific source". New test `test_a_two_link_chain_read_from_stdin_counts_its_first_link`: stdin `codexInk`, `--referent-chain openXdox,openInk`, `openXdox=<tree>` keyed and a second tree bare, asserting the whole stderr, the one NOTE "each link whose own declaration is read had a more specific source (...)". The `> 2` mutant fails it (see the mutation probes). The existing three-link stdin test and the new one share a helper, `stdin_naming`. - **This body.** "exactly one first link" now reads "at most one", and the merge paragraph names the current main. - **First link only, not a refusal.** The coordinator recommended this rule. Nothing documented or tested depended on a bare value answering a later link: no test passes `default_source` to `link_pins_from_trees`, and every scaffold test with a three-link chain sets `SHAPE_PIN_SOURCE_<LINK>` for each link. A refusal "when more than one link would take it" would depend on what is on the disk (checkouts beside the project, variables). #338 ruled that the reading is decided by the chains, never by the disk. - **Refuse #442, not note it.** A note would still have to stop the value reading `.`. A refusal names the typo when it is typed, and both tools already exit 2 for a question they cannot ask. - **The scaffold is fixed too.** It reads its `--pin-source` through the same function, so its three-link refusal goes away (see the reproduction). Its `--pin-source` is the pinned product's checkout, which is the first link's tree. New file `tests/test_link_source_chain_defaults.py`: 23 tests (22 until round 3). On bfed143, 17 fail and 5 pass (the controls: the one-link rows and the rows that already worked). On 04c9d77, the one-link test fails and the other 21 pass. Targeted runs (each `run9.sh`: `gh` stub, bogus token, empty `GH_CONFIG_DIR`, git-filter-repo 2.47.0), on the head 31a6f21 unless a row says otherwise. Round 3 (head a707d4b) changes the new test file only, and its own run is the last row: | set | result | |---|---| | new file, naming policy, referent-chain links, pin-source env collisions, pin-source unreadable, CLI reference, repo hygiene, README sections, AGENTS.md codes, validate-pins without git, unreadable workflow | `774 passed in 117.48s` | | manifest validator, scaffold pin and reuse, YAML flow quotes, neutral pin validator | `205 passed in 91.75s` | | CLI reference alone | `22 passed in 26.08s` | | template text placeholders, adopt plan leg-path help | `187 passed in 87.54s` | | predicted merge with origin/main 7d9bec9 (tree 908b3214): repo hygiene, README sections, CLI reference, new file, naming policy | `415 passed in 53.10s` | | round 3, head a707d4b: new file, naming policy, CLI reference | `287 passed in 95.29s` | Round 1 (head 73c4c255, before the merge of #551 and this commit; `docs/handbook.html`, `README.md` and the validators are unchanged by this commit apart from `validate-repository-naming.py`): | set | result | |---|---| | doctor, doctor validator rows, scaffold e2e, setup-project.py, setup.sh, adopt e2e, adopt pins, adopt spec-only, adopt submodules, adopt ignored shape files, adopt plan YAML quoting, adopt root symlinks, scaffold leg-path collisions, update-shape landing | `27 failed, 1796 passed, 3 skipped in 1433.51s`; every failure the same `UnicodeDecodeError` from a bytecode file my own `py_compile` probe had left in `templates/assembly-root/scripts/__pycache__`. With it removed, the two files that held all 27 (`test_adopt_root_symlinks.py`, `test_scaffold_leg_path_collisions.py`) gave `253 passed in 140.50s` | The three skips are `test_shape_doctor.py:9119`, which runs only on a Windows host. None of those files passes `--link-source`, and the one-link change and the help text cannot change a run that gives no bare value. **The 27 failures.** `template_values()` and its twin in `test_scaffold_leg_path_collisions.py` read every file under `templates/assembly-root` as UTF-8. A `validate-pins.cpython-312.pyc` had appeared there the second I ran `python3 -m py_compile` over the changed files. Its first byte is `0xcb`, the 3.12 bytecode magic, which is the byte every failure names. CI never runs `py_compile`. | row | bfed143 | this head | |---|---|---| | #441: one bare `--link-source <openXdox tree>`, chain `openXdox → openYdox → openInk`, `codexInk` | `FINDING ... is broken (openYdox declares openYdox, not openInk)`, exit 1 | `domain-descendant/assembly`, one `declared-unverified` WARNING for openYdox naming `--link-source openYdox=<path>`, exit 0 | | #441: each link keyed | exit 0 | exit 0, unchanged | | #441: no `--link-source` | two WARNINGs, exit 0 | unchanged | | #441, scaffold `--dry-run`, same chain, `--pin-source <openXdox clone>` | `REFUSED chain-not-declared`, exit 2 | WARNING declared-unverified for openYdox, plan printed, exit 0 | | #441, one link: `--referent-chain openInk` beside a leg `openXdox → openQuill`, bare openXdox tree | no warnings, exit 0 | the same: no warnings, exit 0 (04c9d77 printed a WARNING and a NOTE) | | #441, one project, legs `openXdox → openInk` and `openYdox → openQuill`, bare openXdox tree | `FINDING codexQuill: the declared chain openYdox → openQuill is broken (openYdox declares openInk, not openQuill)`, exit 1: the bare tree answered both first links | two WARNINGs and the two-first-links NOTE, exit 0 | | #442: `--link-source openXdox=` from the project root | `FINDING ... (openXdox declares openXdox, not openInk)`, exit 1 | `REFUSED link-source-no-path`, exit 2 | | #442: the same from another directory | WARNING about `.`, exit 0 | `REFUSED link-source-no-path`, exit 2 | | #442: `--link-source ''` from the project root | FINDING, exit 1 | `REFUSED link-source-no-path`, exit 2 | | #442: `--link-source openXdox= --link-source openXdox=<tree>` | NOTE "the later ... replaced it", exit 0 | `REFUSED link-source-no-path`, exit 2 (the behaviour change above) | | #442: `--link-source openXdox=.` from the project root | FINDING (reads the project's own manifest, as typed) | unchanged: a typed `.` is read | | #442: `--pin-source openXdox=` (scaffolded `codexDox`) | `FINDING neutral-pin-source-unreadable: ... . (--pin-source openXdox=...)`, exit 1 | `REFUSED pin-source-no-path`, exit 2 | | #442: `--pin-source ''` | the same FINDING, exit 1 | `REFUSED pin-source-no-path`, exit 2 | | #442: `--pin-source openXdox= --pin-source openXdox=<clone>` | `pins ok`, exit 0 | `REFUSED pin-source-no-path`, exit 2 | | control: `--pin-source openXdox=<clone>` | `pins ok`, exit 0 | unchanged | No row needs real GitHub. Round 1 ran every row except the two new ones and the two "a later value replaces it" rows. The one-link and two-legs rows are the new tests: on bfed143 the one-link test passes and the two-legs test fails; on 04c9d77 the one-link test fails and the two-legs test passes. The two "a later value replaces it" rows are the review's reproductions of bfed143 against 04c9d77; this commit does not change them. Each hunk was reverted alone in a throwaway worktree, and the new file run against it. Round 1 (20 tests), every hunk fails at least one test: | hunk reverted | tests that fail | |---|---| | `repo_shape.py`: offer `default_source` to every link again | 6: the long-chain row, the later-link NOTE, the stdin NOTE, the lookup `[two]` and `[three]`, the scaffold | | `LinkSources._bare_path`: drop the two-first-links gate | 1: two chains beginning at two links | | `_not_asked_why`: drop the two-first-links sentence | 1: the same test | | `_not_asked_why`: always the old two-link sentence | 2: the later-link NOTE and the stdin NOTE | | `main`: drop the `link-source-no-path` refusal | 6: every `--link-source` no-path row | | `PinSources`: drop the `pin-source-no-path` refusal | 3: every `--pin-source` no-path row | | `link_pins`: drop `firsts.setdefault` (stdin names) | 1: the stdin NOTE | | `_first_links_read`: return nothing | 1: two chains beginning at two links | | naming `no_path`: keyed values only | 2: the two empty bare rows | | pins `no_path`: keyed values only | 1: the empty bare row | Round 2 (22 tests, head 31a6f21): | hunk reverted | tests that fail | |---|---| | `_first_links_read`: `if data is not None:` → `if False:` (the project's legs; the review's M14, which survived 04c9d77) | 1: `test_a_project_whose_legs_begin_at_two_links_reads_a_bare_tree_for_neither`; stderr has the two WARNINGs and no NOTE | | `LinkSources.link_pins`: count a one-link chain's first link again | 1: `test_a_chain_of_one_link_is_no_first_link_read` | | `_first_links_read`: count a one-link chain again | 1: `test_a_chain_of_one_link_is_no_first_link_read` | Round 3 (23 tests, head a707d4b): | hunk changed | tests that fail | |---|---| | `LinkSources.link_pins`: `if len(target.chain) > 1:` → `> 2` (the re-review's boundary mutant, which survived 31a6f21) | 1: `test_a_two_link_chain_read_from_stdin_counts_its_first_link` (`1 failed, 22 passed in 10.59s`); stderr has "first link alone, , which had" where the test expects "each link whose own declaration is read had" | The existing `test_a_link_source_no_link_used_is_a_note_and_changes_no_exit` in `tests/test_naming_policy.py` holds the two-link NOTE sentence byte for byte, and it passes. - origin/main 9f80939 (it holds the README, handbook and `tests/readme-cap.d/550.txt` of f6eaab7): clean. The re-review found it clean at 31a6f21 (tree 71ea0d30), and `test_repo_hygiene.py`, `test_readme_sections.py` and `test_cli_reference.py` gave `151 passed in 58.81s` on that merged tree, with `render-cli-reference.py --check` ok. The README cap there is 1427 = 1422 + 5 from main's `tests/readme-cap.d/550.txt`, and this PR adds 0 README lines; its three handbook markers for "The three legs" are 39ec2c23 on the merged tree. a707d4b changes the test file only: merge-tree of it with 9f80939 is clean (tree dfc650f). Earlier mains were clean too: 7d9bec9 (after #552, #553, #554, #561 and #562; `415 passed` on the merged tree) and bbcfd34 (tree 10acc9c). The two `docs/cli.md` regenerations (this PR's `--link-source` help, #561's `bump-leg.py`) touch different tools' sections. - Lane 2's `fix/539-validators-lockstep-remedies` (#575, 93b68f6), now on origin: clean. The reviewer ran the lockstep-lines test, the new file, `test_validate_pins_without_git.py` and `test_validate_pins_unreadable_workflow.py` on the merge with 04c9d77: `103 passed in 48.45s`. This commit does not touch `validate-pins.py` or any of those tests. The `validate-pins.py` hunk stays inside `PinSources`, away from #539's regions (`:99-544` and `:1109-1143`). - Lane 2's `fix/540-pin-source-unread` (#570, 79dfd33): clean. On a merge with 04c9d77, the new file, `test_pin_source_unreadable.py`, `test_scaffold_referent_chain_links.py`, `test_scaffold_leg_path_collisions.py`, `test_cli_reference.py` and `test_adopt_pins.py` gave `371 passed`. #540 counts any `--referent-chain` as a reader of `--pin-source`; that stays true, because every chain's first link reads it. One sentence of #540 needs a word once both are in: `pin-source-unused` says the clone is read for "each --referent-chain link's declaration" (`scripts/shape_materialize.py:2706-2707` and the docstring at `:2681-2683`, and `tests/test_pin_source_unreadable.py:445`, the `UNUSED` text at `:455-457` and `:498`). After this PR it is the FIRST link's alone. Whichever lands second should change "each" to "the first". - The other PR heads #556 to #582 that git still serves (23 heads; #561 is on main): all clean, except #577 (`install.sh`, d0cdbf4). #577 conflicts with main itself, in `docs/handbook.html` and `tests/test_repo_hygiene.py`; against this head the same two files conflict. This PR is not the cause. Both edit `README.md` and the handbook's hash markers, so they land one at a time. Only #575 touches a file this PR changes (`validate-pins.py`, clean). - Lane 5's other branches: #568 `fix/family-bump-to-checks` 8024f9c, #571 `fix/family-remove-gitmodules-missing` b1120c3, #574 `fix/family-members-case-variants` 40eda84 and #578 `fix/family-siblings-tracking-branch` 43d32eb: clean. - The scaffold's and `adopt-project.py`'s own `--pin-source ''` (see the checklist candidates). - `validate-pins.py`'s `--help` and module docstring: nothing in them became false, and the module docstring sits near lines #539 edits. - Making `validate-pins.py` refuse the empty path before its leg and shape-pin checks: it would put the hunk in `_run_all_checks`, where #539 edits. - The v1.0.0 release notes keep #441 and #442 as known limits of 1.0.0, which they are. - **`scaffold-project.py` and `adopt-project.py`: `--pin-source ''` is `Path("")`, so the current directory is read as the pinned product's clone.** Both take `--pin-source` as `type=Path`, and `shape_materialize.declared_pin_values` computes the digest from it. The scaffold also hands it to `link_pins_from_trees` as the first link's tree. Run from the product's own clone, `scaffold-project.py --pin openXdox@<sha> --pin-source '' --referent-chain openXdox,openDox --dry-run` plans with `local-clone (.)`, exit 0; run from anywhere else it reads whatever directory it stands in. This is #442's shape in the two tools that create a project, and neither was in #442. (The review confirmed it for the scaffold on the head; `adopt-project.py` was not re-run.) - **The scaffold's `declared-unverified` warning names remedies the scaffold does not have.** It says "(a sibling checkout, SHAPE_PIN_SOURCE_<LINK>, or --link-source <link>=<path> would let it be read)". `scaffold-project.py` has no `--link-source` (none in its `--help`) and reads no sibling checkout: `link_pins_from_trees(chain, None, ...)` at `scaffold-project.py:799` passes no root. The text is `_chain_link_findings`' (`scripts/repo_shape.py:1419`). It was already printed on bfed143 for a two-link scaffold with no manifest. Since this PR, every chain of three or more links scaffolded with `--pin-source` alone prints it for the second link, where only `SHAPE_PIN_SOURCE_<LINK>` helps. The wording should name only the remedies the caller has. - **`tests/test_cli_reference.py` alone writes `templates/family-root/scripts/__pycache__/bootstrap.cpython-312.pyc`** (proved on 04c9d77 and on two merged trees: `22 passed`, then the file is there). A `.pyc` under `templates/` breaks `template_values()` and its twin in `test_scaffold_leg_path_collisions.py` in any later adoption run in the same tree: round 1's 27 failures were the same kind of break, from a `.pyc` under `templates/assembly-root`. #554's `load_without_bytecode` does not cover it. It is outside #441 and #442, and is named here only. Review: rv441 found 5 nits on 04c9d77 (APPROVE WITH NITS), fixed in 31a6f21; re-review rv441b found all five fixed or answered and 2 new nits (a test gap at the two-link boundary of `link_pins`, and this body), fixed in a707d4b. CI (Brett Heap's ruling 27): H0 a707d4b passed tests, tests-macos, tests-windows and SonarCloud; the head 8971ad5 is a clean update-branch merge of main bcfa364, with tests and SonarCloud green, and the local gate passed on its predicted squash: the scaffold, pins, naming, link-source, setup-by-hand and hygiene sets, 1174 passed, over bcfa364; then the hygiene, AGENTS.md-code, README-section, CLI-reference, link-source and naming sets, 468 passed, over 526cd2c; and 334 passed over b9f65be. Landed on Brett Heap's word of 2026-10-15T13:32:47Z, "All five, once green". Closes #441 Closes #442 Lane: openreposhape-5 (openRepoShape-5) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brettheap
pushed a commit
that referenced
this pull request
Oct 15, 2026
#582 rewrote what `adopt-project.py`'s `plan` and `execute` say around a run, so this branch conflicted with main in `adopt-project.py` and `gh pr update-branch` refused. The merge also takes main's bcfa364 (#538), 709eec1 (#532) and 40b476d (#407), which touch no file this branch changes. One conflicted hunk, in the docstring of `follow_ups_for`. Both sides appended a paragraph after the #493 F3 paragraph that ends "(#493's review, F3)": #582's about the last follow-up being a review, and this branch's about the Makefile follow-up naming `legs.spec_path` and no path (#522, F1). Both are kept. #582's comes first because "It is a review" continues the paragraph above it, and this branch's follows, reworded from "does the same" to "names the key too", which would otherwise point at #582's paragraph. No code was in conflict. The code from the two sides merged by itself and does not overlap: #582 changed the last follow-up's text, `_finish_by_hand`, `_next_steps`, `cmd_execute` and the ruleset hint; this branch changed `cross_leg_references` (via `spec_leg_from_code_leg`), the Makefile follow-up and `_commit_the_split`'s Makefile block. pyflakes on the merged `adopt-project.py` prints nothing, as on both parents. Lane: openreposhape-2 (openRepoShape-2) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
brettheap
added a commit
that referenced
this pull request
Oct 15, 2026
…eck`'s finding for a link kept above a path the shape writes says the clone holds it as a file, so `scripts -> tools/deep` no longer says where the scripts land and sends the person to change where it points, on to `adopt-symlinks-off` (#531) (#584) Some disks check a symlink out as a plain file: under `core.symlinks=false`, which is Git for Windows' default and what `git init` writes on a filesystem that cannot hold a symlink. On such a disk, a symlink the plan keeps in the root ABOVE a path the shape writes is a plain file in the assembly's clone, and nothing can be written beneath it. When `check` reports such a link as `plan-root-symlink`, its finding now says that, in `adopt-symlinks-off`'s words, and gives a fix that works on that disk: send the link to a leg or `drop` it in the plan, and run `check` again. `execute` refuses with the same line, word for word, before any leg exists, as it refused the old line. Only the text of a finding `check` already made changes. A link above that the walk follows cleanly (`scripts -> ci`) stays `execute`'s `adopt-symlinks-off` before any leg, as #504 designed. With symlinks on, the output is byte-identical to `main`'s. `_a_file_above(walk, probe)` runs only for a walk that is about to be reported, so a plan with no such finding makes no new probe, and no network or gh call is added. Tests: tests/test_adopt_root_symlinks.py holds 149 tests on `main` and 156 here. `test_with_symlinks_off_a_link_above_a_path_is_named_as_a_file` (6 cases) and `test_with_symlinks_off_the_fix_the_finding_gives_works_there` (`code`, `drop`) are new. Three existing tests of a followed link gain `links_as_links`, so they keep asserting the symlinks-on line wherever the runner's checkout writes a plain file, which a Windows runner's may (Git for Windows' default). Main's test of the old reason is now the D6 row. Review: the adversarial review found the change PR-READY at 0a178e4, with five text corrections, all in the PR body. The edge cases it found outside #531 are left for #457's checklist. `main` was merged in five times, and the branch was never rebased. - **The first merge** was GitHub's update-branch, at 348f8a8 (main 2e6c6fa). 348f8a8 is green on Linux, macOS, Windows and SonarCloud. - **The second merge was by hand,** at cae5a98 (main 654c476), after #581 (#524) changed `adopt-project.py`. Its one conflict was a comment in `_SymlinkProbe`, about a work directory no repository can be made in. The resolution keeps both #531's sentence and #524's. - **cae5a98c** passed 71 adopt test files in both modes: 5,796 passed and 5,482 passed, with 0 failed. - **The third merge** was GitHub's update-branch, at 7f439a5 (main a61cf47), after #589 changed `adopt-project.py`. It was a clean merge. - **The fourth and fifth merges** were also GitHub's update-branch, both clean, after #566 and #582 changed `adopt-project.py`: 250b070 (main 1d809ea) and c43cde1 (main 526cd2c). - **Since #597, CI is Linux only.** The head is green on Linux and SonarCloud (ruling 27). Closes #531 Lane: openreposhape-1 (openRepoShape-1) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brettheap
pushed a commit
that referenced
this pull request
Oct 15, 2026
…n-source-unread Merges origin/main 66267f0 so the PR's CI merge ref and the fix that follows run on current main. The fourteen landings since 2bf8fd4: #597, #578, #593, #589 (#449), #586, #573 (#537), #575 (#539), #566 (#528), #571, #588, #569 (#538), #582 (#523), #616 and #576 (#441, #442). Those that touch this PR's files: - adopt-project.py: #589 (`check` recomputes each pin's digest in the clone `plan` read it from: LOCAL_CLONE_RE, _recorded_clone, _why_not_rechecked, _recomputed_pin_finding, _pin_digest_findings), #582 (what `plan`, `execute` and AGENTS.md say around a run) and #566 (a source's own `single-repository.yaml`). - scaffold-project.py and docs/cli.md: #573, #569 and #576 (the `_declaration` docstring: `--pin-source` verifies the first chain link alone, which this PR's N3 wording already says). - tests/test_adopt_pins.py: #589's thirteen cases. - tests/test_scaffold_leg_path_collisions.py: #573. This commit holds the textual resolution only. One hunk conflicted, the `from shape_materialize import (...)` list at adopt-project.py:261. It is resolved as the union of both sides' changes to the list: main's added `pin_digest_from_source` (#589), and this PR's added `DIGEST_FROM_CLONE`, `DIGEST_FROM_GH`, `pin_source_path` and `refuse_an_unread_pin_source` and its removal of `one_printable_line`, whose last caller this PR deleted and to which main added none (keeping it is pyflakes' "imported but unused"). pyflakes adopt-project.py is clean on the merge. Every other file merged without a marker, and `scripts/render-cli-reference.py --check` is ok. The merge alone does not keep #589 working: this PR's `plan` records a bare `local-clone`, which names no clone for #589's `check` to read, and `check` refuses `local-clone (<path>)` as `plan-pin-malformed`. The next commit reconciles the two. Lane: openreposhape-2 (openRepoShape-2) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brettheap
pushed a commit
that referenced
this pull request
Oct 15, 2026
…his PR's head carries the newest main before rv540c's fix round (#540, #451, #450) #591 is the only commit main gained since d62a03c (GitHub's update-branch merge of main 77bb5f0, #574, #584, #587, #615): adopt-project.py and shape-doctor.py read `origin` one way (#521, #427). It touches this PR's adopt-project.py, in the `_checked_plan_inputs` neighbourhood and elsewhere, and no other file this PR changes: git merge-tree --write-tree says the merge is clean, so this commit holds the textual resolution only (none was needed) and every change of behaviour comes after it. #589 (#449) and #582 stay as f540n merged them. Lane: openreposhape-2 (openRepoShape-2) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
brettheap
pushed a commit
that referenced
this pull request
Oct 15, 2026
…s, so PR #620 merges cleanly (#601) Main moved through #566, #582, #584, #591, #572 and #570 since this branch's base, 2989b4c. One hunk in adopt-project.py conflicted, in `_checked_plan_inputs`: this branch replaced the inline `adopt-bad-id` check with `_refuse_bad_id`, and #591 (#427, #521) replaced the inline organisation block just below it with `_planned_org` and `org_given`. The resolution keeps both: `_refuse_bad_id(args.id, args.project, id_passed)` where the id is checked, and main's `org_given = bool(args.org)` and `_planned_org(...)` where the organisation is read. Everything else, the two new test files' hunks included, merged on its own. Lane: openreposhape-2 (openRepoShape-2) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
brettheap
pushed a commit
that referenced
this pull request
Oct 15, 2026
… the Free-plan hint now named by the root is tested on main's tools (#602) This branch was made from 2989b4c. Main has moved through #582, #584, #591, #569, #572, #570 and the rest since, and changed adopt-project.py and scaffold-project.py. The merge is clean, with no hunk of main's inside this PR's: main's adopt hunks sit away from `_create_leg_remotes` and the new `_free_plan_hint_by_the_root` and `_root_visibility`, and its scaffold hunks (shell_line, pin_source_path, the `--pin-source` text, the NEXT STEPS block) sit away from `_private_leg_note`. `import json`, `run`, `CommandFailed` and `VISIBILITY_CHOICES` are still what adopt-project.py imports, and scripts/repo_shape.py's `free_plan_secret_hint` and `FREE_PLAN_HINT` are byte for byte as they were, so nothing needs re-pinning. Lane: openreposhape-2 (openRepoShape-2) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
11 of 15 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lane: openreposhape-3 (openRepoShape-3)
Claim: #523 (comment)
What
Each line of #523 kept its premise on
bfed143(v1.0.0). For each, the text now says what the code does. The only behaviour change is printed text.adopt-project.py:1748-1753,follow_ups_for).tracking_branch, the branch the assembly root and both legs track; the legs -spec and -code are seeded before it, so review the root's diff and the two new repositories together".planprints this follow-up, andcheckprints it too. The split commit lists it under "FOLLOW-UPS, which this commit does NOT do", and that commit message is also the pull request's body. Against GitHub,executeopens that pull request itself. Under--local-remote-dirit opens none. The legs are extracted, and "seeded" is the word kept for a leg made from a template.executecreates and pushes before the split; against GitHub it opens the split's pull request itself, whose base is the plan'stracking_branch, the branch the assembly root and both legs track".adopt-project.py:7879-7893,_finish_by_hand, called fromcmd_execute;AGENTS.md:149-153).executesets the topic and opens the pull request before_verifyruns. A failed verification therefore leaves that pull request open on the source and the topic set on each repository that took it.mainis where it was, the split is on a branch".gh pr createwas refused, the existing "No pull request was opened, and none should be…" comes first.mainis where it was, but the split branch is pushed and, on GitHub, its pull request may be open and the topic set — so fix the plan, delete the split branch (closing that pull request), and re-run …". The module's EXIT CODES paragraph says the same (adopt-project.py:143-146).resolution:(AGENTS.md:134-136, step 2).checknever readsresolution:and saysplan ok. Onlyexecutereads it, to copy it into a kept submodule's record.checkpasses it: the human reads the reasons at step 4."adopt-project.py:6716-6724,ADOPT_RULESET_HINT, and its comment above it).--reuse-empty-reporeuses a leg that is empty or whose one commit is the scaffold's own seed, and the ruleset hint offers that re-run, by an operator holding the bypass right, as its one exit, so a project a ruleset refused part-way is finished by one re-run, not refusedscaffold-remote-existsfor its own legs or sent to a pull request with no base (#462) #506 removed that exit from the scaffold.--local-remote-dir(adopt-project.py:8905-8916,_next_steps).--local-remote-dir, no pull request is opened, and the split is pushed back into the source asadopt/three-repo-shape. The split's.gitmodulesnames each leg by its plain path.-cis the module'sFILE_PROTOCOL, and without it git refuses both leg clones. The branch and the path are quoted forshwithshlex.quote.AGENTS.md stays at its 490-line cap. Step 7's honest text costs one line. To pay for it, the two-line paragraph "
executeopens a pull request, because these organisations are pull-request only. Never suggest a direct push to the default branch, and never--admin." is folded, nearly word for word, into step 4: "… andexecutedoes not make them; it opens the split's pull request itself, because these organisations are pull-request only. Never suggest a direct push to the default branch, and never--admin."README.md and docs/handbook.html make none of these claims, so neither needs a follow-up. The v1.0.0 release notes list these limits as v1.0.0's and are left as they are.
--helpis unchanged, so docs/cli.md is too.Why
#523 collects four places, plus N2 riding along, where adopt-project.py's printed text, or AGENTS.md about it, says something the tool does not do. The lines come from the v1.1.0 triage of the v1.0.0 known limits on #457 (N1, N2, N3, auA-12) and #459 (the ruleset hint).
Tests
New and changed tests pin each corrected sentence, and each one fails against the old text. I checked this by running the changed tests over an export of
bfed143with only the new test files copied in: 13 failed, and the 4 that passed are the unchanged scaffold and family hint parameters.tests/test_adopt_tracking_branch.py: the whole new follow-up, and no follow-up that says "open the split as a pull request" or "seeded".tests/test_adopt_github_exits.py:test_a_failed_verification_says_what_it_left_in_place, which runsexecuteagainst theghshim with a failing split, for three cases: pull request and topic, topic only, pull request only;test_step_7_says_what_a_failed_verification_leaves_on_github;tests/test_adopt_plan.py: newtest_check_passes_an_answer_with_no_resolution_as_agents_md_says, wherechecksaysplan okand step 2 says so.tests/test_ruleset_hint_tracking_branch.py: the new hint, byte for byte, and no "other exit" in any hint.tests/test_adopt_e2e.py: NEXT after a real--local-remote-dirrun, and a unit test of the branch form. Since the fix round, the e2e test also runs NEXT's clone line as printed, then the printed bootstrap in that clone.tests/test_adopt_late_failure.py: docstring only.Every run used a stub
ghfirst on PATH,GH_TOKEN=bogus, and an emptyGH_CONFIG_DIR.tests/file that exercises adopt-project.py, every test that reads this repository's AGENTS.md,test_agents_md_codes.py,test_repo_hygiene.py,test_shape_doctor.py,test_scaffold_leg_path_collisions.pyandtest_cli_reference.py. Result: 5994 passed, 13 skipped in 53:06.SHAPE_MEDXEHR_CLONEunset), Windows-only cases, and empty parameter sets intest_leg_path_yaml_scalars.py.bfed143(tests/test_repo_hygiene.py and docs/handbook.html: each handbook section records the hash of every README section it reads, and README.md's line cap is 1422 plus one file per raise in tests/readme-cap.d/, so two README pull requests no longer conflict on the footer's one blob or the cap's one line, and a stale page names exactly which sections to re-read (#519) #551, shape-doctor.py: themachinerow of a machine that is not ready names the preflight checks that failed, in the[!!]lines the preflight printed, so its reason no longer ends onthis machine is not ready yet (see above).with nothing above it (#549) #552, tests: every test that clones a just-pushed local remote by its plain path now clones it withclone_just_pushed, so the macOSfailed to copy filerace of #440 cannot reach it;load_without_bytecodekeeps the doctor's and the Windows-path tests' loads of the family root's scripts from writing.pycinto the templates; the not-a-list doctor cases hold INVALID, exit 1; andGOOD_KEYSholds th #554).git merge-treeof this head withorigin/main2247dbfis clean. On that merged tree,test_agents_md_codes.py,test_repo_hygiene.py,test_adopt_e2e.py,test_adopt_github_exits.py,test_adopt_plan.py,test_adopt_tracking_branch.pyandtest_ruleset_hint_tracking_branch.py: 236 passed, 1 skipped.Fix round (RV582's review of
76e680b1), commitfe8d5550RV582 found N1, auA-12, N3 and the ruleset hint accurate. Its fixes are one new commit on top, a fast-forward.
git clone --recurse-submodules -b adopt/three-repo-shape <source>exited 1 withtransport 'file' not allowedfor both legs. The test had passed only because theadopted_clonefixture ran a different command.-c protocol.file.allow=always.protocol.file.allow. Pasted as printed, the new line exits 0 andpython3 scripts/bootstrap.pyprintsbootstrap ok. The same line without the-cexits 1 (Failed to clone 'code' a second time).<Northwind url>, so it pastes as printed.test_next_names_the_bootstrap_a_root_with_its_own_makefile_can_runparses NEXT's clone line, asserts it beginsgit -c protocol.file.allow=always, and runs it as printed. It then runs the printed bootstrap in that clone, not in the fixture's.--local-remote-dirbare repository is git's local clone, which links or copies each loose object file while git's background maintenance can pack and delete them, so on the macOS runner it diesfailed to copy file to ... No such file or directory, every doctor test errors at setup, andsetup.shrefuses after creating all three repositories #440):--no-local, and the legs' plain paths read asfile://URIs. A URI is thefiletransport too, so the printed-cis still what lets the legs clone.["-c", "protocol.file.allow=always"], not conftest'sFILE_PROTOCOL, because tests: every test that clones a just-pushed local remote by its plain path now clones it withclone_just_pushed, so the macOSfailed to copy filerace of #440 cannot reach it;load_without_bytecodekeeps the doctor's and the Windows-path tests' loads of the family root's scripts from writing.pycinto the templates; the not-a-list doctor cases hold INVALID, exit 1; andGOOD_KEYSholds th #554 removed that import from this file on main.test_step_7_says_what_a_failed_verification_leaves_on_githubdrops two asserts that checked only the test's own constants.Fix-round runs, under the same stub-
ghenvironment:test_agents_md_codes.py,test_repo_hygiene.pyandtest_cli_reference.py: 344 passed, 1 skipped (the MedxEHR clone).test_adopt_e2e.pyandtest_adopt_plan.py: 84 passed, 1 skipped.test_shape_doctor.py -k adopt: 7 passed, 365 deselected.test_scaffold_leg_path_collisions.py: 104 passed.origin/mainbbcfd34(git merge-treeclean):test_scaffold_leg_path_collisions.py: 448 passed, 1 skipped;test_shape_doctor.py -k adopt: 14 passed.Lands after the v1.0.0 tag (v1.1.0).
Closes #523
🤖 Generated with Claude Code
Summary by Sourcery
Make adoption output and guidance accurately describe what plan, check, and execute do across GitHub and local-remote runs.
Bug Fixes:
Enhancements:
Documentation:
Tests: