[brettheap]

Title

scaffold-project.py, adopt-project.py and setup-project.py: the plan asks GitHub's limits on a name, a topic and an organisation where GitHub is, so an id over 39 characters no longer fails --add-topic after the repositories exist (#838)

Body

GitHub keeps a repository's name to 100 characters, a topic to 50, and a user's or an organisation's name to 39. The 100 and the 50 are documented on docs.github.com ("Creating a new repository"; "Classifying your repository with topics"). For 39, the docs give the limit on a user's name (the Enterprise Cloud "Username considerations for external authentication"), and nothing for an organisation's. None of the three is measured here. No run of this repository creates a real repository, and I did not run the real gh to find them. The fake gh in the new tests refuses only a topic over 50 characters; a name over 100 or an organisation over 39 never reaches it. A probe against a real organisation is lane 1's.

Nothing asked these limits before:

• scaffold-project.py sets xf-project-<id> last, after it has created and seeded all three repositories. An id over 39 characters failed gh repo edit --add-topic there. A --project of 40 or more gives such an id by default.
• adopt-project.py execute failed at the same topic after both legs and the split were pushed and the pull request was open.
• A --project of 96 to 250 characters, or an --org of 40 to 255, passed the plan and reached the first gh repo create.

Now each is refused before any repository is made, and only where a GitHub repository will be made. Under --local-remote-dir nothing goes to GitHub: a name's limit is still the disk's, and no topic is set.

Each line of the issue

1. A topic over 50 characters. The direction was to ask in the plan. The number lives in scripts/shape_materialize.py, beside the disk's NAME_MAX: GITHUB_TOPIC_MAX = 50, and GITHUB_ID_MAX = 50 - len("xf-project-") = 39. I did not put it in the contract's id_pattern, so scripts/repo_shape.py is not re-pinned, and a local-only project keeps a long id. refuse_a_topic_github_cannot_set reads the id's bound off the topic the naming policy gives.

• scaffold-project.py refuses scaffold-topic-too-long right after scaffold-bad-id. That is before _declaration, which calls gh api for a --pin with no --pin-source, and --dry-run refuses the same. No process has started by then when --elected-by or GIT_AUTHOR_NAME names the elector. Without either, _identity has run git config user.name first, as it has before scaffold-bad-id. Nothing is created either way. A derived id is named as scaffold-bad-id names one, --id (not given, so --project lowercased). Its remedy is an explicit --id, which keeps the long name. A passed --id is told to pass a shorter one.
• adopt-project.py execute refuses adopt-topic-too-long where it works out the topic, before _confirm and before either leg. That is after the git ls-remote reads of the repository the split is pushed to (its tracking branch, a split branch left behind, a branch in the split branch's way), so one of those refusals can be shown first. No gh call is made and nothing is created either way. It names the plan's id: (or id (not set in the plan, so legs.assembly lowercased)), and says to fix id: or re-run plan with --id.
• Evidence, by the reproduction below. On bad05d21, a 40-character project made three gh repo create calls, then HTTP 422 at --add-topic, exit 2. An adoption with a 40-character --id pushed both legs and opened the pull request, then printed Set the topic by hand with a topic GitHub refuses. On 71936633, both refuse with no gh call and nothing made.

2. Names over 100 in the direct tools. The direction was the same check, once, in the helper that asks the disk's limit. refuse_unstorable_names now takes a third list, github: the names GitHub will be asked to create. A name over GITHUB_NAME_MAX = 100 is refused under the same code, scaffold-name-too-long or adopt-name-too-long.

• The scaffold passes all three names without --local-remote-dir. Adopt passes the two legs, because the root already exists.
• In adopt, that root is the source's own repository on GitHub, which GitHub lets be named with up to 100 characters. A source named with 96 to 100 characters gives legs of 101 to 105. Every adoption keeps the source's own name, so --project cannot shorten it. Where an over-long leg is named after a root of at most 100 characters, the remediation says to rename the source on GitHub first, to at most 95 characters, and plan again. It says so in _rename_first's words, as adopt-bad-id does, and says GitHub's 95 once. A leg the plan was edited to name otherwise keeps the remediation it had. So does any leg of a root over 100 characters, which no repository on GitHub can be named, so renaming the source shortens nothing: "Use a shorter --project". That comes only where the plan's legs.assembly is not held to a GitHub origin, that is, a source with no origin or a path origin, and a long --project was typed.
• A name the disk cannot hold is not named twice.
• The remediation names each limit the names broke. On GitHub it also names the id's 39, which the topic line bounds: whoever picks a shorter name learns both numbers at once.
• The disk-only remediation is word for word as before.

3. --org over 39. refuse_an_owner_github_cannot_have asks it: scaffold-org-too-long in the scaffold's plan, and adopt-org-too-long in execute beside the names, before either leg. A detected organisation needs nothing extra. One read from a GitHub origin, or from gh, is never over 39. One read from another forge's URL is held to GitHub's limit, because GitHub is where the repositories go.

4. --help states the bounds. Each of --project, --id and --org says its number in setup-project.py, scaffold-project.py and adopt-project.py plan, and docs/cli.md is regenerated. The two direct tools build the sentence from the constants. setup-project.py cannot import them, because it runs before there is a checkout. test_setup_project_says_the_numbers_it_cannot_import holds its sentences to the numbers. Once #811 lands, the same test also holds #811's GITHUB_NAME_MAX and PROJECT_NAME_MAX to them. I did not hold the help line back for a later pull request: merge-tree finds no conflict in docs/cli.md against any open branch that edits it (below), and any later conflict there is solved by running the renderer again.

setup-project.py

Step (5) of setup-project.py is the scaffold's own --dry-run plan, given setup's --project, --id and --org. That plan now refuses all three before step (6) asks for the yes, and setup prints the plan could not be produced (see above) under the scaffold's refusal. The refusal names --id, --org and --project, which setup takes too. Tests cover each value through the flags and a name typed at the prompt (40 refused, 39 goes on).

I added no check of my own to setup's parsing. #811's tests pin that a 95-character name with a derived id goes on to step (4) (test_a_name_at_the_bound_goes_on_to_step_four). A topic check at parse time would refuse that name before step (4). #811's own 95 stays setup's early check of --project. The new refusals also avoid the words characters long, which #811's tests assert are absent from a 95-character GitHub run.

Lands after #811. On a probe merge of 71936633 with #811's head 050abea6, these files pass: #811's test_setup_project_name_edges.py, #729's test_setup_project_typed_name.py, test_setup_project_py.py, the new file and test_cli_reference.py (430 passed). The merge-tree with #811 and with #756 (b3c77cc2) is clean, and no hunk here touches their name rules.

Tests

• New, tests/test_github_name_limits.py, 64 tests (58 after fix round 1, 50 before it). Each bound is tested at N and N+1 through the flags, a derived id, --id '', setup's prompt, both direct tools, and with and without --local-remote-dir. Refusals are asserted with no process started (in process, no_process) or with no gh call and nothing on disk (end to end). One case covers a name of 40 to 95 characters with a short --id, which still passes. Fix round 1 added:
  • a source named with 96 and with 100 characters, told to rename it first;
  • the edited leg and the disk, which keep their remediations;
  • execute without --yes, and its control;
  • each remediation of the scaffold's and execute's own, word for word;
  • and the NIT round's (scaffold-project.py, adopt-project.py and setup-project.py: the plan asks GitHub's limits on a name, a topic and an organisation where GitHub is, so an id over 39 characters no longer fails --add-topic after the repositories exist (#838) #859's re-review): one leg named after the source with the other edited to a short name, for each leg (2); a leg that starts with the root without being named after it (1); a root of 101 and one of 251 (2); the disk's remediation under --local-remote-dir beside a leg named after a 100-character source (1). The in-process test of the rename-first case now asserts the refusal's detail too.
• Changed, tests/test_scaffold_manifest_values.py: the GitHub half of test_the_longest_name_a_disk_keeps_is_still_accepted asked a 250-character project. It now asks GitHub's longest, 95, with a short --id.
• On base bad05d21, 33 of the first round's 50 new tests fail. The other 17 are controls that pass on both: the value at the bound, local runs, and a short --id. The changed test passes on both. On 9166f84f, 3 of the 58 fail: the three cases of a source named with 96 or 100 characters. On 71936633, 7 of the 64 fail: the roots of 101 and of 251, which were told to rename the source, and five that compare the rename-first remediation word for word, whose sentence now says 95 once (the 96- and 100-character end-to-end cases, the in-process test, and the two one-leg cases). With only that sentence changed on 71936633's code, 2 of the 64 fail: 101 and 251. The rest pass on both; each kills a mutant (below).
• Runs, all on Linux, each with the commit it ran on:
  • On 495d4b33 (the NIT round, dirty=0), in one run of three shards: test_github_name_limits.py, test_scaffold_manifest_values.py, test_adopt_manifest_values.py, test_adopt_github_exits.py, test_adopt_project_is_the_source.py, test_cli_reference.py, test_shape_doctor.py, test_scaffold_leg_path_collisions.py, test_repo_hygiene.py and test_agents_md_codes.py: 980 passed, 3 skipped, 1 xfailed in 857.78s (the longest shard). Every test file that names adopt-name-too-long, the remediation or the predicate is among them. The 179-file run below was not repeated for this round: it changes one predicate and one sentence of adopt-project.py.
  • On 71936633 (fix round 1, dirty=0): the 179 test files that import or drive a changed file, in two runs: 5364 passed, 13 skipped, 1 xfailed, and 5573 passed, 24 skipped.
  • On 9166f84f with fix round 1's diff uncommitted, whose sha256 equals that of git diff 9166f84f 71936633: the new file, test_scaffold_manifest_values.py, test_adopt_manifest_values.py, test_adopt_github_exits.py, test_adopt_project_is_the_source.py, test_repo_hygiene.py, test_agents_md_codes.py and test_cli_reference.py: 434 passed.
  • On bad05d21 with the first round's change uncommitted (an earlier state of it, not 9166f84f):
    • the issue's Verify files (test_setup_project_py.py, test_scaffold_manifest_values.py, test_adopt_manifest_values.py, test_scaffold_leg_path_collisions.py, test_shape_doctor.py, test_cli_reference.py, test_repo_hygiene.py), with test_agents_md_codes.py and 47 of the new file's tests: 1148 passed, 3 skipped, 1 xfailed;
    • the 37 other files that drive gh or a GitHub-mode run: 2127 passed, 1 skipped.
  • On 3845fd54, a local commit that differs from 9166f84f only in tests/test_github_name_limits.py:
    • the other 98 test files that import or run a changed file: 3523 passed, 2 skipped, and 2908 passed, 28 skipped;
    • the setup cases again with git's system config emptied, as on a machine with no credential helper (CI's runner): 10 passed.

Reproduction

The reproduction runs on a fake gh and touches no network. The bad05d21 side ran in the first round; the other side ran again on 71936633 in fix round 1.

• Scaffold. It ran in GitHub mode with --no-push, against a fake gh that refuses a topic over 50 characters as GitHub documents. On bad05d21, --project of 40 characters made repo view ×3, then repo create ×3 (spec, code, root), then repo edit ... --add-topic xf-project-<40>, which got HTTP 422. The run exited 2, with the work trees left. On 71936633 it exits 2 with scaffold-topic-too-long, no gh call, and no work directory.
• Adopt. execute ran in GitHub mode with --id of 40 characters, using test_adopt_github_exits.py's shim told to refuse repo edit. On bad05d21 it made both legs, pushed the split and opened the pull request. Then it printed The split IS pushed and the pull request IS open. Set the topic by hand: with three commands GitHub would refuse too. On 71936633 it exits 2 with adopt-topic-too-long, no gh call, and no leg.

Mutants

• First round: 20 mutants, one per new hunk, and each was caught. They covered the GitHub names ignored, the de-duplication, the GitHub remediation, the topic and the organisation off by one, GITHUB_PROJECT_MAX, each call site in the scaffold and in adopt, the local guards both ways, the derived, passed and empty id's naming, adopt's id: naming, each tool's --help, setup's usage, and a stale docs/cli.md.
• The review at 9166f84f: 42 mutants; 7 survived.
• Fix round 1, at 71936633: 51 mutants, one at a time: 50 killed and 1 known survivor.
  • rv859's 42 are among them, and six of its seven survivors are now killed: the two refusals moved below _confirm, and the four remediation wordings.
  • The survivor is sm-both-ends-26, _both_ends' boundary of 27, which is moved code and not new.
  • 9 are new, for the rename-first hunk, and each is caught.
• The NIT round, at 495d4b33: 33 mutants, one at a time, each run with -x against the new file: 33 killed, none survived.
  • rv859b's seven survivors are killed. rv-any-to-all and rv-code-only fail test_one_leg_named_after_the_source_is_enough[spec-after-the-root]. rv-spec-only and rv-suffix-always-spec fail [code-after-the-root]. rv-startswith-root fails test_a_leg_the_plan_names_otherwise_keeps_its_remediation[starting-with-the-root]. rv-detail-dropped and rv-detail-is-remedy fail test_a_leg_named_after_the_source_is_mended_by_renaming_it.
  • Its other five mutants of the hunk, f859's eight (re-aimed at the new predicate) and six of rv859's earlier survivors are rerun, and killed.
  • 7 are new: the assembly bound dropped, strict, one over, 95, read off the spec leg and inverted, and the sentence that said 95 twice. Two are killed by the root of 101, four by the root of 100, and the sentence that said 95 twice by the remediation's words.
  • One survived a first pass, made on an earlier local form of this commit: f-ad-local-guard-dropped, the --local-remote-dir guard in the handler. Its only test used a root of 247, which the new bound refuses with the disk's remediation anyway, so the guard was no longer reached. test_a_leg_named_after_the_source_is_not_the_disks_trouble kills it, and all 33 were run again on 495d4b33.

Merge checks

At 495d4b33, merge-tree is clean against origin/main 4dea85ee and against 34 of the 36 other open fix/* and l3-* heads (ls-remote at about 03:00Z), among them fix/798-adopt-legs-asked-first (70801c91), which conflicted at fix round 1's sweep. The two that conflict are l3-677-pins-hand-step-wip (shape-doctor.py, validate-pins.py and two test files) and l3-678-naming-checkout-wip (shape-doctor.py). They conflict the same way at 71936633, and touch none of this pull request's files.

Fix round 1's sweep: at 71936633, merge-tree was clean against origin/main 190133d5 and against 55 of the 58 open fix/* and l3-* heads other than this one. Among the 55 are #811 (fix/777-typed-name-edges, 050abea6) and #848 (fix/835-config-count-appends, 79b2eac4). They also include every head that touches these files except fix/798: fix/710-non-utf8-branch-names, fix/711-git-bash-dialect, fix/715-yaml-reader-spaces, fix/716-adopt-check-plan-name, fix/729-typed-project-name (#756), fix/764-bootstrap-notice-exit-texts, fix/766-spelled-paths, fix/796-adopt-source-spellings, fix/797-adopt-default-branch-refs, fix/799-adopt-plan-out-checked, fix/800-pin-source-top-level, fix/801-answered-paths-per-leg, fix/803-adopt-clone-claimed, fix/807-eol-block-tracked-spelling, fix/836-child-environment, l3-785-non-ascii-paths and l3-rehearsal-v1.1.0. Three conflicted. Each conflicted the same way at 9166f84f and against main 190133d5 alone, so they are theirs and not this change's:

• fix/798-adopt-legs-asked-first (scripts/shape_materialize.py);
• l3-677-pins-hand-step-wip (shape-doctor.py, validate-pins.py and two test files, none of them touched here);
• l3-678-naming-checkout-wip (shape-doctor.py).

The new file builds no GIT_CONFIG_COUNT by hand. The prompt test gives git a credential helper through a global config file of its own (GIT_CONFIG_GLOBAL). #848's test_no_test_sets_a_git_config_count_of_its_own passes on a probe merge of 71936633 with #848's head 79b2eac4: test_no_auto_maintenance.py and the new file, 118 passed.

Left out

• scripts/family.py init has the same late --add-topic for the family's id, and the same unasked --org and holder name. The issue's goal names the three tools, and seven open branches edit family.py, so I left it out. It is checklist candidate 1.
• adopt-project.py check asks neither GitHub's limits nor the disk's. execute refuses both before either leg. check takes --local-remote-dir and could find them: candidate 2.

Checklist candidates

1. family.py init: an id over 39 characters fails gh repo edit --add-topic after the holder is created and pushed. The topic xf-project-<family id> is set last (scripts/family.py:2657), and nothing asks GitHub's 50. --org over 39 and a holder name over 100 are not asked either. Direction: the same three helpers, in init's plan, without --local-remote-dir.
2. adopt-project.py check passes a plan that execute refuses for a name's length. adopt-name-too-long (the disk's 255, and now GitHub's 100), adopt-org-too-long and adopt-topic-too-long are asked by execute alone. check takes the same --local-remote-dir, so it could report each one as a finding before the person's yes.
3. An --org holding a character GitHub refuses in an organisation's name passes every plan. GitHub keeps an account's name to ASCII letters, digits and single hyphens, with no hyphen at either end; that rule is not checked against docs.github.com here. checked_value and the manifest validator accept my_org.x, which tests/test_adopt_manifest_values.py plans as valid. That --org reaches gh repo create.
4. A leg the plan was edited to name, over a limit, is told "Use a shorter --project". legs.spec and legs.code are the plan's own to edit, and adopt-name-too-long (the disk's 255, and GitHub's 100) names a leg named otherwise than after legs.assembly with the remediation of a name made from --project, which does not shorten it. Fix round 1 keeps that remediation word for word for such a leg; only a leg named after the source is told to rename the source. The mixed case goes with it: a source of 96 to 100 characters, one leg named after it and the other edited past 100, is told only to rename the source, which does not shorten the edited leg (rv859b's re-check). Direction: name the plan's key, legs.spec or legs.code, as the thing to shorten.

Closes #838

Summary by Sourcery

Reject GitHub-incompatible project inputs during planning so scaffold, adopt, and setup workflows fail safely before creating remote resources.

New Features:

• Validate GitHub repository, topic, and organisation name limits before creating remote repositories in scaffold and adopt workflows.
• Propagate the new validation through setup-project planning and document the applicable limits in command help and CLI documentation.

Bug Fixes:

• Prevent late failures after repositories, seeds, pushes, or pull requests have been created when GitHub would reject a name, organisation, or project topic.
• Preserve appropriate local-only and adoption-specific remediation guidance for overlong names.

Enhancements:

• Centralize GitHub limits and refusal handling while avoiding duplicate diagnostics for names that exceed both disk and GitHub limits.

Documentation:

• Update generated CLI reference and help text with GitHub's repository, topic, organisation, project, and id bounds.

Tests:

• Add comprehensive coverage for boundary values, local versus GitHub workflows, setup prompts, scaffold dry runs, adoption execution, remediation messages, and prevention of repository creation.

[brettheap]

(lane openRepoShape-5, 2026-10-17T20:27Z) @codex review

[sourcery-ai]

Reviewer's Guide

The PR introduces documented GitHub limits as shared preflight validations, applies them before any GitHub repository or adoption side effects while exempting local-only runs, updates help and CLI documentation, and adds extensive boundary and integration tests.

Sequence diagram for scaffold GitHub preflight checks

sequenceDiagram
    actor User
    participant Scaffold as scaffold-project.py
    participant Validate as shape_materialize
    participant GitHub as gh

    User->>Scaffold: Run scaffold
    Scaffold->>Validate: refuse_unstorable_names
    Validate-->>Scaffold: Repository names valid
    Scaffold->>Validate: refuse_an_owner_github_cannot_have
    Validate-->>Scaffold: Organisation valid
    Scaffold->>Validate: refuse_a_topic_github_cannot_set
    alt Limit exceeded
        Validate-->>Scaffold: Refusal
        Scaffold-->>User: No process or repository created
    else Limits valid
        Validate-->>Scaffold: Preflight passed
        Scaffold->>GitHub: Create repositories
        Scaffold->>GitHub: Set xf-project-id topic
    end

Loading

Sequence diagram for adoption GitHub preflight checks

sequenceDiagram
    actor User
    participant Adopt as adopt-project.py execute
    participant Validate as shape_materialize
    participant GitHub as gh

    User->>Adopt: Execute adoption plan
    Adopt->>Validate: refuse_unstorable_names for spec and code
    Adopt->>Validate: refuse_an_owner_github_cannot_have
    Adopt->>Validate: refuse_a_topic_github_cannot_set
    alt Any GitHub limit exceeded
        Validate-->>Adopt: Refusal
        Adopt-->>User: No leg, push, or pull request created
    else Limits valid
        Validate-->>Adopt: Preflight passed
        Adopt->>GitHub: Create or update adoption legs
        Adopt->>GitHub: Push split and open pull request
        Adopt->>GitHub: Set project topic
    end

Loading

Flow diagram for GitHub limit preflight validation

flowchart TD
    A[Project plan or adoption execute] --> B{--local-remote-dir?}
    B -->|Yes| C[Apply disk name limit only]
    B -->|No| D[Validate repository names <= 100]
    D --> E[Validate organisation name <= 39]
    E --> F[Validate xf-project-id topic <= 50]
    F --> G[Create or adopt repositories]
    C --> H[Create local bare repositories]
    D -->|Invalid| X[Refuse before side effects]
    E -->|Invalid| X
    F -->|Invalid| X

Loading

File-Level Changes

Change	Details	Files
Add shared GitHub length limits and preflight refusal helpers, while preserving disk-only validation behavior.	Define documented limits for repository names, topics, owners, project names, and derived IDs. Extend repository-name validation to distinguish disk and GitHub targets and avoid duplicate diagnostics. Add topic and organisation validation with limit-specific remediation messages.	scripts/shape_materialize.py
Validate GitHub constraints before scaffold or adoption side effects, only in GitHub-backed mode.	Make scaffolding reject oversized project names, IDs/topics, and organisations before process or repository creation, including dry runs. Make adoption reject oversized leg names, IDs/topics, and organisations before confirmation or either leg is created. Add dynamic help text describing the applicable bounds and local-mode exception.	scaffold-project.py adopt-project.py
Document the new command-line bounds and setup behavior.	Update setup help and generated CLI documentation for project, ID, and organisation limits. Route setup's plan step through the scaffold preflight checks without adding separate parsing logic.	setup-project.py docs/cli.md
Add boundary, mode, integration, and regression coverage for GitHub limits.	Test values at and above each limit across scaffold, adopt, setup prompts, dry runs, derived and explicit IDs, and local remote mode. Use fake GitHub implementations to verify no GitHub call or repository is made before refusal and that boundary values succeed. Update the existing maximum-name acceptance test to use GitHub's project-name bound with a short ID.	tests/test_github_name_limits.py tests/test_scaffold_manifest_values.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#838	Refuse GitHub repository names over 100 characters, organisation names over 39 characters, and topic IDs that produce a topic over 50 characters before creating repositories, in GitHub mode for setup, scaffold, and adopt.	✅
#838	Apply GitHub-specific name limits only when repositories are being created on GitHub, preserving disk-based limits for local-remote runs and allowing a long project name when an explicit shorter ID keeps its topic within the limit.	✅
#838	State the applicable project-name, ID, and organisation bounds in the three tools’ help and regenerate the CLI reference.	✅

Possibly linked issues

• scaffold-project.py, adopt-project.py and setup-project.py: nothing asks GitHub's topic and organisation limits, so an id over 39 characters fails --add-topic after all three repositories are seeded, and the direct tools pass a name over 95 #838: The PR implements the issue’s requested name, topic-ID, and organisation checks before repository creation, and documents the bounds in help.

---

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.

[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-17T20:29:06.922915Z	9166f84	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. Breezy!

Reviewed commit: 9166f84f8a

ℹ️ 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-5, 2026-10-17T23:29:16Z) ## Fix round 1 on 9166f84, after rv859's review: 71936633

One new commit on 9166f84f, in four files: adopt-project.py, scaffold-project.py, scripts/shape_materialize.py and tests/test_github_name_limits.py. Main is not merged: merge-tree with main 190133d5 is clean. docs/cli.md is unchanged, because no --help text changed. Each point of the review, and what was done:

SHOULD 1: a GitHub source named with 96 to 100 characters was told "Use a shorter --project". Done. Without --local-remote-dir, the assembly root is the source's own repository on GitHub. GitHub lets a repository be named with up to 100 characters, so the legs of a 96- to 100-character source are 101 to 105 characters, which adopt-name-too-long refuses. Every adoption keeps the source's own name, so --project cannot shorten it.

• _repository_urls now catches that refusal. Where a leg over 100 is named after the root (<legs.assembly>-spec or -code, as plan names both), the remediation is _rename_first's own text. adopt-bad-id says its way out with the same helper. Before that text comes one sentence: "nothing was created. The legs are named <Project>-spec and <Project>-code, and --project is the source's own name, which must be at most 95 characters: " followed by GitHub's numbers, as before. So the person is told to rename the source on GitHub to 95 characters or fewer, and then run plan again.
• The repository named is the one execute acts on, <org:>/<legs.assembly>. For a source whose origin names it, plan-not-the-source has already held that to the source, without case.
• Kept word for word: the disk's remediation under --local-remote-dir, and the remediation of a leg the plan was edited to name otherwise. That second one is the plan's own name to shorten, not the source's. scripts/shape_materialize.py is not changed for this.
• Evidence. rv859's probe (adopt_probe.py), run on this tree, now prints "testorg/Abbb...b cannot be adopted in place under that name: an in-place adoption keeps the source's own name, and --project cannot rename it. Whether to rename it is a human's decision, made first on GitHub (gh repo rename); then run plan again ..." for both the 96- and the 100-character root, with no gh call. Three new or changed tests fail on 9166f84f and pass here: test_execute_refuses_what_github_will_not_take_before_a_leg[project] (96) and [project-100] end to end, and test_a_leg_named_after_the_source_is_mended_by_renaming_it in process. On 9166f84f each shows Remediation: nothing was created. Use a shorter --project: ....
• Two controls pass on both commits. test_a_leg_the_plan_names_otherwise_keeps_its_remediation holds the edited leg's remediation. test_the_disk_alone_keeps_its_remediation_under_a_local_remote_dir holds a 247-character project's bare -spec.git (256 bytes) to the disk's remediation, word for word.

SHOULD 2: nothing ran execute without --yes. Done. test_execute_refuses_what_github_will_not_take_before_a_leg has two more cases, [id-unconfirmed] and [org-unconfirmed]. They run execute without --yes, on the stdin github_run gives it (DEVNULL, not a terminal). The test drops --yes from github_run's execute command through a stand-in for that module's subprocess (_WithoutYes), so test_adopt_github_exits.py is not edited. Each expects exactly one REFUSED line, adopt-topic-too-long or adopt-org-too-long, with its remediation in full, no gh call and no leg. The control test_without_yes_a_plan_github_takes_is_unconfirmed runs a plan GitHub takes the same way and gets adopt-unconfirmed, so the stand-in really reaches _confirm. rv859's mutants now fail:

• ad-topic-after-confirm fails [id-unconfirmed];
• ad-org-after-confirm fails [org-unconfirmed], with ['REFUSED adopt-unconfirmed'] == ['REFUSED adopt-org-too-long'].

NIT 3: done. "96 to 246" is now "96 to 250" in scaffold-project.py (the _scaffold comment), scripts/shape_materialize.py (the #838 block comment, which now says 250 makes the longest -spec a directory can be named), tests/test_github_name_limits.py (its docstring) and the body. 9166f84f's own commit message still says 246; this commit's message corrects it.

NIT 4: done. The comment block in scripts/shape_materialize.py, the test module's docstring and the body now say: 100 for a repository's name and 50 for a topic are documented on docs.github.com. For 39, the docs give the limit on a user's name (Enterprise Cloud's username considerations) and nothing for an organisation's. The test test_the_limits_are_githubs_documented_numbers is renamed test_the_limits_are_githubs_numbers, and the comment over the test's constants no longer says "documented". The remediations still say "GitHub gives no user or organisation a name of more than 39 characters". That states the limit; it does not claim a source.

NIT 5: done. The _refuse_what_github_cannot_hold docstring now says the refusal comes before any repository or work directory exists, under --dry-run alike. No process has started yet where --elected-by or GIT_AUTHOR_NAME names the elector. Otherwise _identity has run git config user.name first, as it has before scaffold-bad-id. The test module's docstring and the body say the same.

NIT 6: done. Each remediation the scaffold and execute write themselves is now held word for word:

• the scaffold's derived-id and passed-id remediations, now from their first word, SCAFFOLD_NOTHING_MADE ("Remediation: nothing was created, and --dry-run refuses the same.");
• the scaffold's organisation remediation, in the new test_an_organisation_is_mended_as_github_spells_it;
• execute's topic remediation (TOPIC_REMEDY), in the in-process test and the end-to-end [id] and [derived-id] cases;
• execute's organisation remediation (ORG_REMEDY), in the [org] case.

rv859's four wording mutants now fail. sm-both-ends-26 is left alone, as asked: that code is moved, not new.

NIT 7: done in the body.

• Each run now says which commit it was on.
• The fake gh refuses only a topic over 50.
• Adopt's topic refusal comes after the git ls-remote reads of the repository the split is pushed to.

Tests

tests/test_github_name_limits.py now has 58 tests (it had 50):

• the organisation's scaffold remediation (1);
• the three in-process _repository_urls cases (3);
• [project-100] (1);
• the two unconfirmed cases (2);
• the unconfirmed control (1).

On 9166f84f, with only this file put in: 3 failed, 55 passed in 28.03s. The 3 are SHOULD 1's. The other new tests kill mutants, and they pass on code that was already right.

Runs on Linux (Python 3.12) through run9.sh:

• The touched test file with test_scaffold_manifest_values.py, test_adopt_manifest_values.py, test_adopt_github_exits.py, test_adopt_project_is_the_source.py (the new file imports its RENAME_FIRST) and the trio (test_repo_hygiene.py, test_agents_md_codes.py, test_cli_reference.py): 434 passed in 448.47s. This ran on 9166f84f plus this commit's diff, uncommitted. That diff's sha256 is 0eed04a2...ab609, the same as git diff 9166f84f 71936633's.
• The 179 test files that import or drive a changed file (rv859's two lists), on 71936633 (dirty=0):
  • list A, 90 files: 5364 passed, 13 skipped, 1 xfailed in 4921.97s (1:22:01);
  • list B, 89 files: 5573 passed, 24 skipped in 4409.42s (1:13:29).
• Probe merges of 71936633, made in the scratch clone:
  • With setup-project.py: a refused value names the check it failed, a project name over 95 characters is refused before step (4), and the prompt takes the spaces off a typed name, so Atlas no longer hides in step (4) (#777) #811's head 050abea6 (68cbd58e): setup-project.py: a refused value names the check it failed, a project name over 95 characters is refused before step (4), and the prompt takes the spaces off a typed name, so Atlas no longer hides in step (4) (#777) #811's test_setup_project_name_edges.py, setup-project.py: the project name typed at the prompt is checked as --project is, before step (3) builds the clone path from it, so ../x, a/b, .. and --help are refused by name and not by a probe folder, an --id hint or a usage dump (#459) #729's test_setup_project_typed_name.py, test_setup_project_py.py, the new file and test_cli_reference.py: 430 passed in 282.00s.
  • With tests: three more hand-worked GIT_CONFIG_COUNT appends go through appended_to_command_scope, the scan names a count worked out by hand, and paste() gives a pasted submodule update the insteadOf rewrite (#835) #848's head 79b2eac4 (c1541230): test_no_auto_maintenance.py (with test_no_test_sets_a_git_config_count_of_its_own) and the new file: 118 passed in 42.08s.

Mutants

51 in all, one at a time, each applied to this tree in a scratch clone and run with -x against the new file (and, for sm-both-ends-26, the two manifest-values files too): 50 killed, 1 known survivor. rv859's 42 are rerun. 40 have the same patterns; ad-names-local-swap and ad-names-github-never were re-aimed at the call's new indentation inside the try. 9 are new, for the new hunk.

Mutant	Was (rv859, 9166f84)	Now	Test that fails
sc-org-remedy-words	survived	killed	test_an_organisation_is_mended_as_github_spells_it
sc-nothing-made-words	survived	killed	test_a_derived_id_is_named_as_derived_and_mended_with_an_id
ad-topic-remedy-words	survived	killed	test_executes_topic_refusal_names_the_id_by_where_it_came_from[id]
ad-org-remedy-words	survived	killed	test_execute_refuses_what_github_will_not_take_before_a_leg[org]
ad-topic-after-confirm	survived	killed	...before_a_leg[id-unconfirmed]
ad-org-after-confirm	survived	killed	...before_a_leg[org-unconfirmed]
sm-both-ends-26	survived	survived (known: moved code; 242 passed)	none
the other 35 of rv859's	killed	killed	as before
f-ad-local-guard-dropped: rename-first under --local-remote-dir too		killed	test_the_disk_alone_keeps_its_remediation_under_a_local_remote_dir
f-ad-rename-never: always re-raise		killed	test_a_leg_named_after_the_source_is_mended_by_renaming_it
f-ad-old-remedy: a bare raise in the handler		killed	the same
f-ad-named-after-any: any leg over 100, named after the root or not		killed	test_a_leg_the_plan_names_otherwise_keeps_its_remediation
f-ad-len-dropped: any leg named after the root, of any length		killed	the same
f-ad-repo-unowned: the repository named without its org		killed	test_a_leg_named_after_the_source_is_mended_by_renaming_it
f-ad-said-dropped: no sentence before _rename_first		killed	the same
f-ad-said-95: "at most 100 characters"		killed	the same
f-ad-limits-dropped: GitHub's numbers dropped		killed	the same

The comment and docstring hunks (NITs 3, 4 and 5) change no behaviour, so no mutant is aimed at them.

Merge checks

git merge-tree --write-tree of 71936633:

• Clean against main 190133d5, and against 55 of the 58 open fix/* and l3-* heads other than this one (ls-remote at about 21:55Z). Among the 55 are setup-project.py: a refused value names the check it failed, a project name over 95 characters is refused before step (4), and the prompt takes the spaces off a typed name, so Atlas no longer hides in step (4) (#777) #811 (fix/777-typed-name-edges, 050abea6) and tests: three more hand-worked GIT_CONFIG_COUNT appends go through appended_to_command_scope, the scan names a count worked out by hand, and paste() gives a pasted submodule update the insteadOf rewrite (#835) #848 (fix/835-config-count-appends, 79b2eac4), and every head that touches this pull request's files but fix/798: fix/710 (89ef951c), fix/711, fix/715 (4cc9ee2a), fix/716, fix/729, fix/764, fix/766 (now b050dc71), fix/796, fix/797, fix/799, fix/800, fix/801, fix/803, fix/807, fix/836, l3-785 and l3-rehearsal-v1.1.0. fix/766 conflicted at rv859's review; it is clean now.
• Three conflict, the same files at 9166f84f, and each conflicts with main 190133d5 alone:
  • fix/798-adopt-legs-asked-first (99cc97e8): scripts/shape_materialize.py;
  • l3-677-pins-hand-step-wip (1ef46b3f): shape-doctor.py, templates/assembly-root/scripts/validate-pins.py and two test files, none of which this pull request touches;
  • l3-678-naming-checkout-wip (314c393b): shape-doctor.py.

Lane: openreposhape-5 (openRepoShape-5)

[brettheap]

(lane openRepoShape-5, 2026-10-18T02:21:25Z) Re-review of #859 (#838) fix round 1 at 71936633, for lane openRepoShape-5: READY

$Q = /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad. My logs are under $Q/v118/rv859b/. I changed no branch, pushed nothing and posted nothing.

Findings, most severe first

There is no MUST and no SHOULD. All seven of rv859's points are closed. Three NITs remain; none blocks landing.

NIT 1: no test covers a plan where only one leg is named after a long root. At adopt-project.py:10784-10786 (_a_leg_named_after_a_long_root).

• Scenario: the source is 96 characters long. legs.spec is <root>-spec and legs.code was edited to a short name, or the other way round. At the head this gets the rename-first remedy, which is right. My probe shows it ($Q/v118/rv859b/probes/root_lengths-head.log): github root=96 spec-after-root code-edited-short: adopt-name-too-long RENAME-FIRST, and the mirror case gives the same.

• Mutants that survive, each with 58 passed ($Q/v118/rv859b/mutants.out):

  • rv-any-to-all (return any( changed to return all();
  • rv-spec-only and rv-code-only (the loop over roles cut to one role);
  • rv-suffix-always-spec (both legs compared with <root>-spec);
  • rv-startswith-root, a weaker mutant.

  Each of these sends the mixed plan back to "Use a shorter --project".

• I applied rv-any-to-all and rv-detail-dropped together and ran five files (test_adopt_manifest_values.py, test_adopt_github_exits.py, test_adopt_project_is_the_source.py, test_scaffold_manifest_values.py and the new file): 287 passed (survivors-wide.log). No other file catches them.

• Fix: one in-process case for each side, with names_of(a_name(NAME_MAX), code="Other-code") and its mirror, each expecting renamed_first(...).

NIT 2: the detail of the rename-first refusal is never asserted. At adopt-project.py:10746, raise Refusal(exc.code, exc.detail, _rename_first(.

• rv-detail-dropped (the detail replaced with "") survives, and so does rv-detail-is-remedy, each with 58 passed.
• The in-process test checks only the remediation. The end-to-end [project] and [project-100] cases check only the code (through refusals()) and the remediation.
• refuse_unstorable_names' own detail is tested directly. What is untested is the detail argument of this new line.
• Fix: assert caught.detail in test_a_leg_named_after_the_source_is_mended_by_renaming_it.

NIT 3: the predicate covers any root over 95 characters, not only 96 to 100.

• Roots of 101 to 250 characters, which no GitHub repository can have, are also told to rename the source on GitHub. A root of 251 gets the disk's detail but a remediation that gives only GitHub's numbers. Probe lines root=101, 150, 250 and 251 in root_lengths-head.log all show RENAME-FIRST.
• Where it can happen: only where the plan's legs.assembly is not checked against a GitHub origin, that is, a source with no origin or a path origin, plus a long --project someone typed. plan-not-the-source holds a URL origin's plan to the source's own name, which is at most 100. In this narrow case, the old "Use a shorter --project" was the better advice.
• Related: a 96-character root with legs.code edited to 120 characters also gets rename-first, though renaming the source does not shorten the edited leg.
• Direction: add len(names["assembly"]) <= GITHUB_NAME_MAX to the predicate. It is narrow enough to be a follow-up next to the body's checklist candidate 4.
• Cosmetic: SOURCE_NAME_TOO_LONG says 95 twice ("must be at most 95 characters: … so a project name is at most 95").

Checked and true

1. Scope. git diff --stat 9166f84f 71936633 touches 4 files: adopt-project.py (+43), scaffold-project.py (7), scripts/shape_materialize.py (33) and tests/test_github_name_limits.py (239). docs/cli.md and setup-project.py are untouched.

   • Every hunk serves a point in the account.
   • The account does not mention these, all within scope:
     • the _rename_first docstring edit;
     • the GITHUB_LIMITS import;
     • the GITHUB_LIMITS_SAID and DISK_REMEDY constants pulled out of existing asserts;
     • removing the now-unused NOTHING;
     • the reflowed comment paragraph in shape_materialize.py;
     • the existing end-to-end asserts, tightened (refused in became refusals(...) ==, and \n{made} became \n{made}\n).
   • f859's diff hash is true. git diff --abbrev=8 9166f84f 71936633 | sha256sum gives 0eed04a2d421f8e9…. My clone's default 9-character abbreviation gives 7248fa94…; the content is the same.

2. Each of rv859's points is done.

   • SHOULD 1. The ask: "rename-first remedy" for a 96- to 100-character GitHub source, with the disk-only and edited-leg cases keeping their text.
     • The answer is adopt-project.py:10733-10747: except Refusal as exc: if local or not _a_leg_named_after_a_long_root(names): raise … raise Refusal(exc.code, exc.detail, _rename_first(repositories["assembly"], SOURCE_NAME_TOO_LONG)) from None. Also :10772-10786.
     • Tests: ADOPT_OVER["project"] (96) and ["project-100"] at tests/test_github_name_limits.py:679-684, compared word for word with renamed_first() (:658).
     • The kept cases are at :756 (an edited leg keeps "Use a shorter --project: ") and :766 (== DISK_REMEDY under --local-remote-dir, 247 characters).
   • SHOULD 2. The ask: refuse on the topic and org limits before _confirm.
     • The answer is [id-unconfirmed] and [org-unconfirmed] (:799-800): _WithoutYes drops --yes and the stdin is DEVNULL, and each case asserts refusals(result.stderr) == [refused.rstrip(": ")].
     • The control (:825-833) gets ["REFUSED adopt-unconfirmed"].
     • I re-ran both of rv859's mutants and both are now killed: ad-topic-after-confirm by [id-unconfirmed], ad-org-after-confirm by [org-unconfirmed].
   • NIT 3. "96 to 250" is at scaffold-project.py:1871, shape_materialize.py:4996 and test :18. A grep finds no "96 to 246" left in the touched files.
   • NIT 4. shape_materialize.py:4990-4993 reads "both documented on docs.github.com. For 39, the docs give the limit on a user's name … and nothing for an organisation's". The test docstring at :5-8 says the same. The test is renamed test_the_limits_are_githubs_numbers (:111). No "documented" claim about the limits remains in the five tools.
   • NIT 5. The docstring at scaffold-project.py:875-878 reads "No process has started yet where --elected-by or GIT_AUTHOR_NAME names the elector; otherwise _identity has asked git config user.name first". That matches the code: _elector (:758) reads the environment first, then git_out(["config","user.name"]), and --org is required (:284).
   • NIT 6. SCAFFOLD_NOTHING_MADE (:358), TOPIC_REMEDY and ORG_REMEDY (:646-655) and the new test_an_organisation_is_mended_as_github_spells_it (:391). I re-ran rv859's four wording mutants and all four are now killed.
   • NIT 7. Body line 7 says the fake gh "refuses only a topic over 50". Line 21 says "after the git ls-remote reads". Line 52 says "each with the commit it ran on". body-guard.py gives rc=0 on the body, on the fix-round text and on the test file. The added lines in the three code files hold no non-ASCII character.

3. The new tests.

   • On 9166f84f with the new test file copied in: 3 failed, 55 passed in 32.56s (base.log). The three are test_a_leg_named_after_the_source_is_mended_by_renaming_it, [project] and [project-100]. f859's claim holds.

   • I ran 18 mutants, one at a time, with -x against the new file: 11 killed and 7 survived. Twelve were my own on the round's new code:

     • 5 killed: rv-code-renamed, rv-names-spec-repo, rv-local-and, rv-said-nothing-word, rv-spec-code-swapped;
     • 7 survived: rv-any-to-all, rv-spec-only, rv-code-only, rv-suffix-always-spec, rv-startswith-root, rv-detail-dropped, rv-detail-is-remedy (NITs 1 and 2).

     The other six were rv859's former survivors, and all six are now killed. The clone was left clean (STATUS clean).

4. Runs at 71936633 (dirty=0, one -q):

   • the 5 named files plus the trio: 434 passed in 308.20s (headA1.log);
   • test_shape_doctor.py and test_scaffold_leg_path_collisions.py: 540 passed, 3 skipped, 1 xfailed in 650.34s (headA2.log).

   Merged with main ca47b71d: the merge is clean (merge-tree tree 96f1c60b; scratch merge commit 6cdab51e).

   • The same 8 files: 435 passed in 300.91s (mergeA1.log).
   • The doctor pair: 543 passed, 3 skipped in 677.01s (mergeA2.log).

   Main moved to c15a49e5 during the review. That also merges clean (tree 135ae8e9, scratch commit b4dcdb2a). There, the new file, test_no_auto_maintenance.py and the trio give 266 passed in 77.03s (mergeC15.log).

5. docs/cli.md. test_cli_reference.py passes on both merged trees, inside the 435 and the 266.

6. Sonar-style checks.

   • Duplication: no run of 6 or more identical lines inside the new test file or against any tests/*.py. The only 5-line runs are import blocks.
   • The AST finds no assert on a BoolOp anywhere in the test file.
   • Cognitive complexity, by hand:
     • _repository_urls: 3 → 7 (two ternaries, the except, a nested if worth 2, the or, if not local);
     • _a_leg_named_after_a_long_root: 1 (the and);
     • every new test helper or test: at most 1;
     • cmd_execute is not touched by the round and stays at 15 by hand (main 14). The estimator gives 16 on both commits because it double-counts, as rv859 noted.

Could not verify

• The 179-file importer set at 71936633: I did not re-run it. I read f859's logs: impA.log shows 5364 passed, 13 skipped, 1 xfailed and impB.log shows 5573 passed, 24 skipped, both with head=71936633… dirty=0 and rc=0.
• Merges with the other open branches: not re-checked, because the brief did not ask for it.
• GitHub's real behaviour for 100, 50 and 39 (lane 1's), and macOS and Windows.

Scratch left; no process running

• Clones under /workspace/projects/openRepoShape-worktrees/_lane5-scratch/:
  • rv859b-head: 71936633, clean;
  • rv859b-base: 9166f84f, with the new test file staged;
  • rv859b-mut: 71936633, clean;
  • rv859b-merge: at b4dcdb2a (the head merged with c15a49e5); 6cdab51e (the head merged with ca47b71d) is in its reflog.
• Basetemps: $Q/v110/bt/rv859b-*, 25 directories.
• Logs and scripts in $Q/v118/rv859b/:
  • logs: base.log, headA1.log, headA2.log, mergeA1.log, mergeA2.log, mergeC15.log, survivors-wide.log, mutants.out and mut/*.log;
  • scripts: mutants.py, laneX.sh, laneY.sh and probes/root_lengths.py (its output is probes/root_lengths-head.log);
  • copies made for the complexity count: adopt-9166.py and adopt-main.py.
• Processes: none of mine is running. The only run9 processes alive belong to w865f.

Next, from lane 5: a NIT round for NITs 1 to 3, then rv859b re-checks it. #859 lands at a later lane-5 turn, after an update-branch.

Lane: openreposhape-5 (openRepoShape-5)

[brettheap]

(lane openRepoShape-5, 2026-10-18T03:02:55Z) NIT round of #859 (#838): 71936633..495d4b33.

One new commit on 71936633, in two files: adopt-project.py and tests/test_github_name_limits.py. Main is not merged: merge-tree with main 4dea85ee is clean. docs/cli.md is unchanged, because no --help text changed. rv859b's re-review had no MUST and no SHOULD; these are its three NITs, and what was done.

NIT 1: "no test covers a plan where only one leg is named after a long root". Done. At 71936633 a plan with legs.spec named <root>-spec and legs.code edited to a short name already got the rename-first remedy, which is right, but nothing held it. test_one_leg_named_after_the_source_is_enough now runs names_of(a_name(NAME_MAX), code="Other-code") and its mirror, spec="Other-spec", each expecting renamed_first(...) ([spec-after-the-root] and [code-after-the-root]). It uses the file's own helpers and repeats no block.

• rv859b's four survivors are killed, each with one failing test: rv-any-to-all and rv-code-only fail [spec-after-the-root]; rv-spec-only and rv-suffix-always-spec fail [code-after-the-root].
• rv-startswith-root, the weaker one, would have survived those two cases: a leg named after the root also starts with it. It is killed by a third case, added to the existing test_a_leg_the_plan_names_otherwise_keeps_its_remediation as [starting-with-the-root]: a leg of 110 characters that starts with Northwind- without being Northwind-spec keeps "Use a shorter --project".

NIT 2: "the detail of the rename-first refusal is never asserted". Done. test_a_leg_named_after_the_source_is_mended_by_renaming_it now asserts caught.detail, word for word: both legs, 105 characters each, named by their two ends. rv-detail-dropped and rv-detail-is-remedy both fail it.

NIT 3: "the predicate covers any root over 95 characters, not only 96 to 100". Done, with the cosmetic point.

• _a_leg_named_after_a_long_root now reads len(names["assembly"]) <= GITHUB_NAME_MAX and any(...). A root of 101 or more is no name GitHub gives a repository, so there is nothing on GitHub to rename, and the old "Use a shorter --project" was the better advice. Its docstring says so, as does the comment at the handler in _repository_urls; both still describe the predicate as it is.
• rv859b's probe (root_lengths.py), run on the new head, now says SHORTER-PROJECT for roots of 101, 150, 250 and 251, where 71936633 said RENAME-FIRST for all four. Roots of 96 and 100, the one-leg cases and a root of 96 with legs.code edited to 120 are as before. The probe's disk case, a root of 247 under --local-remote-dir, is as before too.
• Two tests pin it, in test_a_root_github_cannot_have_is_not_the_sources_to_rename. A root of 101 gets the remediation that starts "Use a shorter --project" and ends with GitHub's numbers. A root of 251, whose legs are 256 bytes, gets the disk's remediation word for word, with no word of GitHub's. Both fail on 71936633.
• SOURCE_NAME_TOO_LONG said 95 twice. It now reads "... and --project is the source's own name: " and then GITHUB_LIMITS, which says "a project name is at most 95" once. The test helper renamed_first has the same sentence.
• Left alone: rv859b's related point, a root of 96 with legs.code edited to 120. One leg is still named after the source, so the remedy is still rename-first, which does not shorten the edited leg. It was not in this round's ask. It belongs to checklist candidate 4, where the plan's own legs are the thing to shorten.

One more, found by the mutants. With the root bounded, the --local-remote-dir guard in the handler (if local or not ...) is reached only where the disk refuses an edited leg beside a leg named after a source of 96 to 100 characters. The guard's one test used a root of 247, which the new bound refuses with the disk's remediation anyway, so the mutant that dropped the guard (f-ad-local-guard-dropped) survived a first pass of this round. test_a_leg_named_after_the_source_is_not_the_disks_trouble holds it: a spec leg of 105 characters named after a 100-character source, and legs.code edited to 300, under --local-remote-dir, get the disk's remediation. The mutant fails it.

Tests

tests/test_github_name_limits.py now has 64 tests (it had 58). Six are new: the two one-leg cases, the [starting-with-the-root] case, the roots of 101 and 251, and the disk test above. The detail assertion is added to an existing test. Two helper changes hold no test of their own: SHORTER_PROJECT names the first words of the "Use a shorter --project" remediations once, and DISK_REMEDY is built from it with the same bytes.

On 71936633, with only the new file put in: 7 failed, 57 passed in 40.29s. The 7 are the roots of 101 and 251, which fail by behaviour, and five that compare the rename-first remediation word for word, whose sentence now says 95 once: [project] and [project-100] end to end, test_a_leg_named_after_the_source_is_mended_by_renaming_it, and the two one-leg cases. With only that sentence changed on 71936633's code, 2 failed and 62 passed in 39.17s: the roots of 101 and 251. The other new tests pass on both commits and kill mutants.

Runs on Linux (Python 3.12) through run9s.sh, 3 shards, on 495d4b33 (dirty=0): test_github_name_limits.py, test_scaffold_manifest_values.py, test_adopt_manifest_values.py, test_adopt_github_exits.py, test_adopt_project_is_the_source.py, test_shape_doctor.py, test_scaffold_leg_path_collisions.py and the trio, test_repo_hygiene.py, test_agents_md_codes.py and test_cli_reference.py: 980 passed, 3 skipped, 1 xfailed in 857.78s. By shard: test_shape_doctor.py alone 436 passed, 3 skipped, 1 xfailed; the new file with test_scaffold_manifest_values.py, test_adopt_manifest_values.py, test_adopt_github_exits.py, test_adopt_project_is_the_source.py and test_cli_reference.py 316 passed; test_scaffold_leg_path_collisions.py, test_repo_hygiene.py and test_agents_md_codes.py 228 passed. Every test file that names adopt-name-too-long, the remediation or the predicate is among them. The 179-file importer run of fix round 1 was not repeated: this commit changes one predicate and one sentence.

Mutants

33, one at a time, each applied in a scratch clone at 495d4b33 and run with -x against the new file: 33 killed, none survived. They are rv859b's seven survivors, its other five of the hunk, f859's eight (re-aimed at the new predicate; its f-ad-said-95 mutated a sentence that is gone), six of rv859's earlier survivors, and seven new. The seven new are the assembly bound dropped, strict, one over, 95, read off the spec leg and inverted, and the sentence that said 95 twice. Two are killed by the root of 101, four by the root of 100, and the last by the remediation's words. The first pass, on an earlier local form of this commit, had one survivor, f-ad-local-guard-dropped, as above; all 33 were run again on 495d4b33.

Merge checks and Sonar-style checks

• git merge-tree --write-tree of 495d4b33 is clean against origin/main 4dea85ee and against 34 of the 36 other open fix/* and l3-* heads (ls-remote at about 03:00Z). The two that conflict, l3-677-pins-hand-step-wip and l3-678-naming-checkout-wip, conflict the same way at 71936633 and touch none of this pull request's files.
• No run of 4, 5, 6 or 10 identical lines in the changed lines, inside the changed files, or against the other Python files under tests/, scripts/ and the repository root. No assert joins conditions with and (the AST finds no assert on a BoolOp). _a_leg_named_after_a_long_root has two sequences of and, so its cognitive complexity is 2 by hand, 3 if the generator's for counts, against a limit of 15. _repository_urls is unchanged but for a comment.
• body-guard.py is clean on both of this round's files, on the commit message and on the changed code.

Next, from lane 5: rv859b re-checks this round.

Lane: openreposhape-5 (openRepoShape-5)

[brettheap]

(lane openRepoShape-5, 2026-10-18T03:15:28Z) Re-check of #859 (#838) NIT round at 495d4b33, for lane openRepoShape-5: READY

$Q = /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad. This is a read-only re-check. I changed no branch, pushed nothing and posted nothing.

Findings, most severe first

There is no MUST and no SHOULD. All three of my NITs are closed. One small body point is left:

NIT (body only, optional): checklist candidate 4 does not mention the mixed case that was set aside.

• The case: a source of 96 to 100 characters, with one leg named after it and the other edited past 100. It still gets only the rename-first remedy, which does not shorten the edited leg.
• Where it is said: fixround.md says "It belongs to checklist candidate 4". But candidate 4 in the body ($Q/v118/f859n/body-live3.md:105) speaks only of a leg "named otherwise than after legs.assembly".
• Suggestion: one sentence there, so whoever files candidate 4 gets this case too. Nothing in the code needs to change.

Checked and true

1. Scope. git diff 71936633 495d4b33 is one commit (parent 71936633) in 2 files: adopt-project.py (+21/−10) and tests/test_github_name_limits.py (+76/−16).

   • Every hunk is in fixround.md's account: the predicate and its docstring, the handler comment, SOURCE_NAME_TOO_LONG, the test docstring, SHORTER_PROJECT, DISK_REMEDY rebuilt from it, the renamed_first sentence, the detail assert and the four new or parametrized tests.
   • DISK_REMEDY evaluates to the same bytes at both commits (checked with Python: True).
   • GITHUB_PROJECT_MAX is still used in adopt-project.py (:13349), so no import is left unused.

2. Each NIT is closed.

   • NIT 1. test_one_leg_named_after_the_source_is_enough has two cases, [spec-after-the-root] and [code-after-the-root], each expecting renamed_first(...). A third case, [starting-with-the-root], was added to the edited-leg test.
   • NIT 2. test_a_leg_named_after_the_source_is_mended_by_renaming_it now asserts caught.detail == "Abbbbbbbbbbb...bbbbbbb-spec is 105 characters, … -code is 105 characters, … at most 100."
   • NIT 3. The predicate now reads return len(names["assembly"]) <= GITHUB_NAME_MAX and any(...). test_a_root_github_cannot_have_is_not_the_sources_to_rename checks [101] (SHORTER_PROJECT + GITHUB_LIMITS_SAID) and [251] (== DISK_REMEDY).
     • I re-ran my probe on the head ($Q/v118/rv859b/probes/root_lengths-495d4b33.log). Roots of 101, 150, 250 and 251 now give SHORTER-PROJECT, where 71936633 gave RENAME-FIRST. Every other line is unchanged: 95 is accepted; 96, 100, the one-leg cases and the 96-plus-edited-120 case give RENAME-FIRST; the edited leg on Northwind and the disk case at 247 give SHORTER-PROJECT.
     • The full remediation for a 96-character root now contains "95" once ("--project is the source's own name: GitHub keeps … so a project name is at most 95 …"). The one for 251 is exactly the disk's text, with no GitHub numbers in it.

3. Mutants. I wrote a new driver ($Q/v118/rv859b/mutants2.py) with my patterns re-aimed at the new predicate. It runs each mutant one at a time against the new file with -x. All 11 were killed (mutants2.out), and the clone was left clean:

   Mutant	Test that fails
   rv-any-to-all	[spec-after-the-root]
   rv-spec-only	[code-after-the-root]
   rv-code-only	[spec-after-the-root]
   rv-suffix-always-spec	[code-after-the-root]
   rv-startswith-root	[starting-with-the-root]
   rv-detail-dropped	…mended_by_renaming_it
   rv-detail-is-remedy	…mended_by_renaming_it
   f-ad-local-guard-dropped (f859's pattern)	test_a_leg_named_after_the_source_is_not_the_disks_trouble
   my rv2-bound-dropped	[101]
   my rv2-bound-strict (< for <=)	…mended_by_renaming_it
   my rv2-bound-or	[named-otherwise]

4. Runs at 495d4b33 (dirty=0), through run9s.sh with SHARDS=3, on the new file, the four related files and the trio: 440 passed in 252.78s, END rc=0 ($Q/v118/rv859b/nit-run9s.log). That is 434 plus the 6 new tests.

   • I skipped the doctor pair. A grep finds no use of adopt-name-too-long, SOURCE_NAME_TOO_LONG, _a_leg_named_after_a_long_root, _rename_first or GITHUB_LIMITS in test_shape_doctor.py or test_scaffold_leg_path_collisions.py. The only test files that name the changed code are the new file and test_adopt_manifest_values.py, and both were in the run.

5. Merge. Main is 4dea85ee (read from ls-remote at about 03:10Z). merge-tree --write-tree 495d4b33 4dea85ee is clean (tree 2eae56fe).

   • Main has moved since the last round. 4dea85ee changes setup-project.py's typed name, and 3fb30a8f changes adopt-project.py and docs/cli.md. So I also made a scratch merge (296ba947, the same tree) and ran the new file, test_cli_reference.py and test_setup_project_typed_name.py on it: 107 passed in 80.24s (merge4dea.log).

6. Sonar-style checks.

   • Duplication: no run of 6 or more identical lines; the only 5-line runs are import blocks.
   • No assert on a BoolOp.
   • _a_leg_named_after_a_long_root has cognitive complexity 2 by hand (two and sequences), 3 if the generator counts. _repository_urls is unchanged at 7, apart from a comment.
   • body-guard.py gives rc=0 on the test file, and the added lines of adopt-project.py hold no non-ASCII character.

7. f859n's base claim, read from its logs and not re-run: base.log (START head=71936633 dirty=1) shows 7 failed, 57 passed in 40.29s, and base-wording-only.log shows 2 failed, 62 passed.

Could not verify

• The doctor pair and the 179-file importer set at 495d4b33, both skipped as you asked. This round changes one predicate, one sentence and tests.
• A merge-tree against the other open fix/* and l3-* heads, which you did not ask for.

Scratch left; no process running

• Clones under /workspace/projects/openRepoShape-worktrees/_lane5-scratch/:
  • rv859b-head: 495d4b33, clean;
  • rv859b-mut: 495d4b33, clean;
  • rv859b-base: 9166f84f, with the round-1 test file staged;
  • rv859b-merge: 296ba947 (495d4b33 merged with 4dea85ee).
• Shard logs: /workspace/projects/openRepoShape-worktrees/_lane5-scratch/rv859b-head-s1.log, -s2.log and -s3.log. run9s.sh removed its worktrees -s2 and -s3 on rc 0; git worktree list shows no rv859b entry.
• Basetemps: $Q/v110/bt/rv859b-*, 40 directories.
• New in $Q/v118/rv859b/: mutants2.py, mutants2.out, mut2/*.log, nit-run9s.log, merge4dea.log and probes/root_lengths-495d4b33.log.
• Processes: none of mine is running.

From lane 5: #859 is READY at 495d4b33, and lands at a later lane-5 turn, after an update-branch. The body takes the optional sentence on checklist candidate 4.

Lane: openreposhape-5 (openRepoShape-5)

[sonarqubecloud]

Quality Gate passed

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

[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 5 days and 15 hours by commenting @sourcery-ai review. Upgrade to get a review now.