[brettheap]

Lane: openreposhape-5 (openRepoShape-5)
Claim: #777 (comment)

Stacked on #756 (fix/729-typed-project-name, b3c77cc2); retarget to main once it lands.

One commit, 854f6ed9, on b3c77cc2. It changes setup-project.py, which is not a pinned copy. It adds tests/test_setup_project_name_edges.py and edits tests/test_setup_project_typed_name.py (one case moves) and one comment in tests/test_setup_project_py.py. No template, pinned file, README, handbook, AGENTS.md or docs/cli.md changes: render-cli-reference.py --check says [ok] docs/cli.md is what the generator produces, and README stays at 1459 lines.

The 100 is not measured. GitHub's limit of 100 characters on a repository name is from its documentation. No lane 5 run creates a real repository and none ran the real gh (every run had a stub first on PATH and GH_TOKEN=bogus-l5). Lane 1 should confirm the number against a real organisation before this lands.

No Windows run and no macOS run was made. CI is Linux only (#597). Every test that gives a run a terminal or a gh stub is POSIX only (PTY_SKIP), as #756's file is.

Fix round 1: five tests waited on CI at a gh auth setup-git offer (b5def3f0)

What failed. On CI (run 39027235147, git 2.55.0, Python 3.14.8), five of this PR's new tests were killed after 60 seconds: test_a_typed_name_over_the_bound_is_refused_at_the_prompt[96|100|101|255] and test_a_typed_name_at_the_bound_goes_on_to_step_four[github]. The rest of the suite passed (11487 passed, 144 skipped, 1 xfailed). Every one of the five screens ended in step (1):

  [??] git has no credential helper for github.com, so the first push over HTTPS will fail. Fix it once: gh auth setup-git

  Run `gh auth setup-git` now? Type yes to continue:

Why. A GitHub run (one without --local-remote-dir) offers gh auth setup-git in its preflight when git has no credential helper for github.com (_check_credential_helper). The offer comes before step (3) asks for the project. These tests type only at the project prompt, so nothing answered the offer, and the run waited until the test killed it.

• The bound played no part. The five are exactly this file's typed runs without --local-remote-dir. The same names typed in a local run passed on CI. The 95-character GitHub run, which the bound lets through, hung too.
• The machine decided. On the machine the tests were written on, /etc/gitconfig and ~/.gitconfig both name a credential helper, so the offer never came there. CI's runner names none.
• Reproduced on 854f6ed9 with git's system file skipped and its global file empty (GIT_CONFIG_NOSYSTEM=1, GIT_CONFIG_GLOBAL set to an empty file): the same five fail with CI's screen (5 failed, 1 passed, in 302 s). The same command with the machine's own config gives 6 passed in 4 s.
• Not timing. Pinned to one CPU core that a busy loop also holds (taskset), the slowest test in the file took 1.5 s, against its 60-second limit.

The fix is in the test, not the tool. The offer is _check_credential_helper's documented warning and offer, and a run is meant to wait for a typed answer to it. The tests depended on the machine's git config. One commit, b5def3f0, changes only tests/test_setup_project_name_edges.py:

• gh_that_is_signed_in also gives git a credential helper for github.com. It is set in git's command scope (GIT_CONFIG_COUNT), appended to what the environment holds, as command_scope in tests/test_adopt_git_reads.py does. Its value is !<the stub> auth git-credential: the line gh auth setup-git writes, pointed at the test's own gh stub. The preflight now finds a helper on every machine. No run here pushes, so git never asks it.
• A new test, test_a_github_run_here_is_not_held_by_a_git_with_no_helper (95 and 96 characters), runs with git's system and global files empty (GIT_CONFIG_SYSTEM, GIT_CONFIG_GLOBAL), as CI's runner has them. A run that waits at the offer now fails on every machine, not on CI alone.

Tests

All runs went through run9.sh (a gh stub first on PATH, GH_TOKEN=bogus-l5). Logs are under v116/f811/ in the lane's scratchpad.

• The file, 62 tests (60, plus the new test's 2 cases), on the fixed tree:
  • 10 runs with the machine's git config: 62 passed each time (loopH-1.log to loopH-10.log).
  • 10 runs with git's system and global files empty: 62 passed each time (loopC-1.log to loopC-10.log).
• Slow CPU: pinned to one core that a busy loop also holds. 3 runs with empty config and 2 with the machine's: 62 passed each time (loopSC-*.log, loopSH-*.log). The slowest test took 1.5 s.
• At b5def3f0:
  • this file, test_setup_project_typed_name.py, test_repo_hygiene.py, test_agents_md_codes.py and test_cli_reference.py: 230 passed (setA.log);
  • test_setup_project_py.py: 230 passed (setB.log);
  • the two setup-project name files with empty config: 84 passed (setC-nohelper.log).
• No other file imports this one (git grep).

Fails on the base

On 854f6ed9, with git's own config empty, the five tests fail as they did on CI (5 failed, 1 passed, repro-base-nohelper.log).

Mutants

Each mutant ran in a throwaway clone at 854f6ed9 with the new file copied in.

• The helper taken out of gh_that_is_signed_in:
  • with the machine's own config, the new test's 2 cases fail, each at the offer (2 failed, 6 passed, mut1-host.log);
  • with empty config, the five CI tests fail as well (5 failed, 1 passed, mut1-nohelper.log).
• import shlex taken out: 8 failed with a NameError (mut3-noshlex-host.log).
• The helper and the new test's empty config both taken out: the new test passes on this machine (2 passed, mut2-noisolation-host.log). The empty config is what lets the test catch the first mutant on a machine whose own git has a helper. That is how the five passed here and hung on CI.

Merge checks

git merge-tree --write-tree of b5def3f0:

• against origin/main 40e678e6: clean;
• against setup-project.py: a project name typed at the prompt is checked as --project is and an empty line says no name was typed, so ../x, a/b, .. and --help are refused by name, not by an --id hint, a help page or a probe write (#729) #756's b3c77cc2: clean.

No other fix/* or l3-* branch on origin holds tests/test_setup_project_name_edges.py (250 refs checked).

Checklist candidates

• A passed-through --dry-run still makes the preflight's offers. -- --dry-run ends the run at the plan, saying nothing was created and nothing was cloned. Its preflight can still offer gh auth setup-git, which writes the person's global git config on a typed yes, as these five runs showed. The gh auth login and install offers work the same way. Whether a dry run should offer to change the machine, or print the offer without asking, is a design question.

Fix round 2: lane 2's review, SHOULDs 2 and 3 and NITs 4 and 5 (050abea6)

Lane 2's rv811 reviewed 854f6ed9 and found it not ready. Its MUST 1 is fix round 1 (b5def3f0): the same cause, and the fix it recommends. This round answers the rest in one commit, 050abea6, on b5def3f0. It changes setup-project.py and tests/test_setup_project_name_edges.py.

SHOULD 2: only the space comes off a typed name

The prompt's .strip() took off every kind of whitespace, not only the spaces its docstring names. Measured at b5def3f0: each value below, typed at the prompt, gave [ok] project Atlas and exit 0, both with stdin the terminal and with stdin a pipe. As --project, each is refused, exit 2. At #756's head (b3c77cc2) the prompt refused each too (rv811's measurement).

Typed	b5def3f0	050abea6, typed and as --project
Atlas + tab, tab + Atlas, Atlas + VT, Atlas + FF, \x1c + Atlas, \x1f + Atlas	taken off, exit 0	refused, exit 2: "It holds a control character, ..."
Atlas + NBSP, Atlas + NEL (\x85), Atlas + U+3000	taken off, exit 0	refused, exit 2: the name sentence

• The fix: .strip(" "). I took this way, not "say whitespace in the docs", for three reasons:

  • the issue's line is about a stray space;
  • the docstring, the commit and this body all say spaces;
  • setup-project.py: a project name typed at the prompt is checked as --project is and an empty line says no name was typed, so ../x, a/b, .. and --help are refused by name, not by an --id hint, a help page or a probe write (#729) #756's rule, that a typed name is checked as --project is, then holds for every character but the space.

  A typed control character stays refused, and the refusal quotes it as an escape. A typed line holds no newline here (ask drops it), so nothing else needs taking off.

• The tests: the nine values are rows of the typed-refusal test, which now runs each of its rows with stdin the terminal and with stdin a pipe (18 new cases). They are also argv rows, as --project (9 cases). Each control character is typed after ^V, so the terminal takes it as text: \x1c alone is the quit key.

SHOULD 3: the sentences say ASCII

The name sentence said "letters" and "spaces", but NAME_RE takes only ASCII letters and the space, so the words described Caf\xe9 and a no-break space as values that pass. Both sentences now say what the patterns take, in the words adopt-project.py's help already uses ("ASCII letters, digits and ..."):

• Name, before: It is not spellable as a name: a letter or a digit first, then letters, digits, spaces and ._'()&,+@-, at most 255 characters in all (...).
• Name, after: It is not spellable as a name: an ASCII letter or digit first, then ASCII letters, digits, the space and ._'()&,+@-, at most 255 characters in all (...).
• Ref, after: It is not spellable as a ref: an ASCII letter or digit first, then ASCII letters, digits and ._/-, at most 255 characters in all (...).

The two drift guards also walk every character above ASCII, first and after a letter, and find none taken. README, the handbook, AGENTS.md and docs/cli.md state neither sentence (git grep), and render-cli-reference.py --check says [ok] docs/cli.md is what the generator produces. No doc changes.

NITs 4 and 5

• NIT 4: a new test passes topic.locked and a.lockb through checked_ref. git check-ref-format --branch takes both. The mutant ".lock" in text now fails it.
• NIT 5: a_run_for's comprehension that only copied is now flags_for(tmp_path, False). It changes no behaviour, so it has no mutant.

Tests

Every run went through run9.sh. Logs are under v116/f811/r2/ in the lane's scratchpad.

• This file and test_setup_project_typed_name.py (97 and 22 tests):
  • with git's system and global files empty, 3 runs: 119 passed each time (r2loopC-*.log);
  • with this machine's git config: 97 passed (head-host-1.log), and 119 passed within set A;
  • slow CPU (pinned to one core that a busy loop also holds): 3 runs with this machine's config and 2 with empty config, 119 passed each time (r2loopSH-*.log, r2loopSC-*.log). The slowest test took 1.9 s, against a 60-second limit.
• At 050abea6, set A: 874 passed (setA.log). That is this file, test_setup_project_typed_name.py, test_repo_hygiene.py, test_agents_md_codes.py and test_cli_reference.py, and every other test file that runs setup-project.py: test_setup_sh, test_branch_left_bump_leg_setup, test_doctor_machine_row, test_doctor_next_is_a_command, test_doctor_validator_rows, test_dry_run_asks_remotes, test_family_printed_quoting, test_family_switch_branch_exists, test_gh_guard, test_openreposhape_command, test_openreposhape_package, test_readme_windows_quoting_sentence, test_release_workflow, test_setup_by_hand_commands and test_windows_paths.
• At 050abea6, set B: test_setup_project_py.py and test_scaffold_e2e.py, 276 passed (setB.log).
• At 050abea6, set C: test_shape_doctor.py, 428 passed, 3 skipped, 1 xfailed (setC-doctor.log). The three skips print the PowerShell line and need a Windows host.

Fails on b5def3f0

The new test file, run against b5def3f0's setup-project.py, gives 42 failed and 55 passed (base-b5def3f0-host.log):

• the 18 typed whitespace cases (status 0);
• 24 cases that compare the name or ref sentence: 14 argv and 10 typed.

The 55 that pass are the controls:

• the six control-character argv rows (argv was always refused);
• the drift guards (the patterns were already ASCII);
• the .lock test (b5def3f0 already refuses .lock only at the end);
• the rest of the file.

Mutants

Eight, each in a throwaway clone at b5def3f0 with this round's two files copied in, and each caught (mutants.out):

Mutant	Result
.strip(" ") back to .strip()	18 failed, every typed whitespace case
the name sentence's old words	28 failed
the ref sentence's old words	2 failed
NAME_RE also takes U+00DF	29 failed, the name drift guard among them
REF_RE also takes U+00DF	3 failed, the ref drift guard among them
.lock refused anywhere in a ref	1 failed, the new .lock test
the test types ^V only before BELL	2 failed: the \x1c cases end by SIGQUIT, status -3
ask's pipe branch strips its answer	9 failed, every piped whitespace case. This shows the piped cases go through the pipe branch.

Merge checks

git merge-tree --write-tree of 050abea6:

• against origin/main 6626a3c5: clean;
• against setup-project.py: a project name typed at the prompt is checked as --project is and an empty line says no name was typed, so ../x, a/b, .. and --help are refused by name, not by an --id hint, a help page or a probe write (#729) #756's b3c77cc2: clean.

Of the 39 origin fix/* and l3-* branches that change setup-project.py or this test file, 32 are clean. Seven conflict, and each conflicts in the same way with b5def3f0 and with origin/main itself: fix/538-setup-paste-and-checks, fix/608-setup-step-checks, fix/family-commands-and-branch, fix/local-clone-race-no-local, fix/setup-help-offline, fix/setup-no-terminal-route and fix/setup-refuse-taken-clone-path-first. They are stale branches, not this change.

Out of scope

rv811's "could not verify" list stays out of this PR:

• GitHub's 100-character limit on a repository name, which needs a real gh against a real organisation (lane 1);
• GitHub's 50-character topic limit, against a default id over 39 characters at step (6);
• Windows and macOS;
• Sonar's own analysis;
• two older problems that are the same on b3c77cc2: a NUL typed at the prompt (Ctrl-V Ctrl-@, stdin the terminal) hangs input(), and a literal newline typed at the prompt ends the name there.

Checklist candidate

• checked_ref passes a.lock/b. Git refuses a ref with a part that ends in .lock (git check-ref-format --branch a.lock/b exits 128), but the tool asks only whether the whole ref ends in .lock, so --shape-ref a.lock/b passes the check and fails later in git checkout. The same holds on b3c77cc2, so setup-project.py: a refused project name gets one sentence that explains only a leading -, a trailing space passes where a leading one is refused and hides in step (4)'s report, and a name of 101 to 255 characters passes the prompt, to end at step (5) or at GitHub #777 did not cause it.

What changed

Line 1: a refusal names the check the value failed

refuse_value gave every value the same closing sentence, and the sentence explained only a leading -. Measured on b3c77cc2, typed at the prompt:

REFUSED: project name is '../x', which is not a value this tool will put on a `git` or `gh` command line. git reads its own arguments: a value that starts with `-` is an option to git, not a name to us; the rest must be spellable as a name, a ref or a path.

a/b, Atlas, Atlas/, .. and Caf\xe9 got the same sentence, and so did --org '' and --into ''. refuse_value now takes the reason, and why_refused gives the first check the value failed, in this order:

• empty: It is empty, and a value here needs at least one character.
• starts with -: keeps its sentence, It starts with -, and git reads its own arguments: a value that starts with - is an option to git, not a name to us. The existing --org -evil test in tests/test_setup_project_py.py still finds "git reads its own arguments".
• control character: It holds a control character, which the quotation shows as an escape: a newline ends a line .... The first sentence still quotes the value with ascii().
• the pattern: in words and as the pattern, as the sibling prints its own. For a name: It is not spellable as a name: a letter or a digit first, then letters, digits, spaces and .'()&,+@-, at most 255 characters in all (^[A-Za-z0-9][A-Za-z0-9 .'()&,+@-]{0,254}$). For a ref the same with ._/-. A pattern with no words of its own is named as repo_shape.checked_value names it (It does not match ...); PATH_RE never gets there, because its only failures are an empty value and a control character, which are named first.

checked_ref says .. (a revision range and not a ref) and .lock (the name git gives the lock file it writes beside a ref) in their own sentences, and checked_passthrough its control character. The first sentence is unchanged, so --shape-ref is 'a b'-style prefixes in the existing tests still match.

repo_shape.checked_value is not changed. scripts/repo_shape.py is pinned in every project, so a wording change there is a re-pin in a shape bump. It also already prints its pattern, and its pattern is a different one (SAFE_ARG_RE, one for names, branches and paths: it takes ../x and a/b, which setup-project.py refuses as names). tests/test_scaffold_pin_and_reuse.py:502 and :517 pin its words and still pass. The comment at tests/test_setup_project_py.py:787 said the two refuse "in the same words"; it now says they refuse the same values, each in its own sentence. The checked_value docstring in setup-project.py said the same and is fixed.

Line 2: a name GitHub cannot hold is refused before step (4)

Measured on b3c77cc2, a 96-character name (and a 251-character one) typed at the prompt, non-local, with a gh stub that is signed in:

• 96: (3) project, [ok] project, the whole of (4) naming policy (three names), then (5) the plan, where the real run would call GitHub.
• 251: the same wall, then REFUSED scaffold-name-too-long: ... is 256 bytes long.

Now both end with exit 2 and nothing else printed after the prompt:

REFUSED: project name is 96 characters long (Abbbbbbbbbbb...bbbbbbbbbbbb), and a project is three repositories, `<Project>`, `<Project>-spec` and `<Project>-code`: GitHub keeps a repository name to at most 100 characters, so a project name is at most 95. Nothing was created. Use a shorter name.

• The number. <Project>-spec and <Project>-code add five characters to 100, so a project name is at most 95 (PROJECT_NAME_MAX).
• Where it is asked. --project and the positional are asked at the end of parse_args, because --local-remote-dir can come after --project on the line. That is before step (1) prints, and the refusal says --project is or <Project> is. The prompt asks it right after the name passes checked_value, before step (3) prints its [ok] lines.
• Only where a GitHub repository will be made. Under --local-remote-dir it is not asked: 96, 100, 101 and 246 characters go on to step (4), and 247 ends at step (5) as scaffold-name-too-long, which is the disk's limit and still step (5)'s to ask (adopt-project.py and scaffold-project.py accept values the new project's own validate-manifest.py refuses (a blank --elected-by or --reference, --elected-on 2026-W41-6 or 20261011 on Python 3.11+, --org test+org, a plan's visibility: secret), so adoption verified or a scaffold exit 0 is followed by a failed first bootstrap; and plan admits a 251-255-character --project that check refuses #261). I measured both on b3c77cc2 (246 passes, 247 refused) and the tests pin them.
• Not a pattern in checked_value. NAME_RE is shared with the organisation, the id, the display name and the person electing the shape, none of which has this limit, so the bound is its own function, checked_project_length.
• The name is quoted at both ends (name[:12]...name[-12:]), as step (5) quotes a long name, since a name this long differs from its neighbours by its tail.

Line 3: the prompt takes the spaces off a typed name

Measured on b3c77cc2, Atlas typed at the prompt: [ok] project Atlas (a trailing space nobody can see), step (4) judges Atlas , Atlas -spec and Atlas -code, exit 1 with FINDING naming-unclassified: Atlas , Atlas -spec, Atlas -code, and Atlas typed the same way is refused at once, exit 2.

I took the first of the issue's two ways: ask_for_the_project_name strips what was typed. Why not the other (quote each name with ascii() in the gate's finding):

• A stray space comes from the prompt (a paste, a slip), and the run ends at the first mistake with no second ask, so taking the space off is what saves the person a retype. Showing it only explains the refusal.
• The finding is the naming gate's own output, read by scaffold-project.py, adopt-project.py and the family validators too. Changing how it quotes changes the gate for every caller, for a stray space that only the prompt produces.
• An argv value is deliberate, so --project 'Atlas ' is held as typed (a test pins it) and still ends at step (4); see the candidates.

.strip() takes spaces from both ends, so Atlas typed is Atlas, where it was refused. A line of three spaces is then an empty line: no project name was typed; nothing was created. That moves #756's blank case from its refusals (compared with --project ' ', which is still refused by the pattern) to its empty answers, a three-line edit in tests/test_setup_project_typed_name.py.

Tests

tests/test_setup_project_name_edges.py is new: 60 tests. On b3c77cc2 (a throwaway clone, detached, with the new file copied in) 47 fail and 13 pass. The 13 that pass pin what must not change: a name at 95 goes on to step (4), the local cases (96, 100, 101 and 246 go on, 247 ends at step (5), and a late --local-remote-dir is read), --project 'Atlas ' held as typed, and two drift guards.

• One case per refusal reason and carrier (test_a_refusal_names_the_check_the_value_failed, 23 cases): empty, leading -, control character, the name pattern for ../x, a/b, .., Atlas, Atlas/, an accented name, ' ' and 256 characters, the positional, the ref pattern, .., .lock, a leading - on a ref, the passthrough, and two values that fail two checks (told the first). Each compares the whole REFUSED: line, and for every reason but the dash asserts the dash's words are absent.
• At the prompt, through the pseudo-terminal (7 cases): the dash, the control character, ../x, a/b, Atlas/, the accented name and 256 characters. The empty reason is not reachable at the prompt (an empty line is "no project name was typed"), so it is tested through --org '' and --into ''.
• The bound: 96, 100, 101 and 255 characters, as --project and as the positional, and at the prompt; 95 at the prompt (both modes) and as --project. Each refusal is exit 2 with nothing on stdout (flag) or no [ok] project and no (4) naming policy (prompt).
• The spaces: Atlas , Atlas and Atlas typed give [ok] project Atlas with no space, [ok] legs Atlas-spec, Atlas-code, and a clone into path ending in Atlas; three spaces are no name.
• Drift guards: every printable character is in the name sentence's list exactly when NAME_RE takes it after a letter, and the same for the ref sentence.

Runs, all on the head, through run9.sh, logs in the lane's scratchpad (v115/w777/):

• test_setup_project_name_edges.py and test_setup_project_typed_name.py: 82 passed (60 and 22), with test_branch_left_bump_leg_setup, test_family_printed_quoting, test_family_switch_branch_exists, test_windows_paths, test_dry_run_asks_remotes, test_setup_by_hand_commands, test_gh_guard, test_openreposhape_command, test_openreposhape_package, test_release_workflow, test_doctor_machine_row, test_doctor_validator_rows, test_doctor_next_is_a_command and test_readme_windows_quoting_sentence: 602 passed (runB.log).
• test_setup_project_py.py, test_setup_sh.py, test_scaffold_pin_and_reuse.py, test_repo_hygiene.py (pure ASCII source, README cap), test_agents_md_codes.py and test_cli_reference.py: 540 passed (runA.log).
• test_shape_doctor.py (its machine row runs setup-project.py --preflight): 428 passed, 3 skipped, 1 xfailed (runC.log). The three skips print the PowerShell line, which needs a Windows host; the xfail is the file's own marker.

Mutants

Thirty, one or more per hunk, each in a throwaway clone and each caught by a failing new test (mutants.out, mutants2.out): the bound off by one and <= made <; GitHub's number changed; each reason's sentence changed (empty, dash, control, .., .lock, name words, ref words, the fallback); ascii replaced by repr; the branch order changed and each of empty, dash and control dropped; the pattern ignored; an empty value accepted; the local exemption dropped, at the prompt and at the parse; the parse check removed; the positional spelled as the flag; the name's tail changed; .. and .lock accepted; the passthrough's reason changed; the prompt's .strip() removed and made .rstrip(); the prompt's bound removed; the prompt told it is never local.

Merge checks

git merge-tree --write-tree of 854f6ed9 against: origin/main bf1f099b clean; b3c77cc2 (the parent) clean; every other wave-7 branch (fix/757, 758, 759, 760, 761, 762, 764, 768) clean, and none of them touches setup-project.py or the three test files; fix/696-setup-family-folder clean (its setup-project.py hunks are in family_folder_here, away from this change). Against all 53 origin branches only four conflict: docs/release-notes-v1.0.0, fix/688-family-init-values, l3-677-pins-hand-step-wip and release/v1.0. Each conflicts the same way, in the same files, against b3c77cc2, so none is this change.

Left out

• Under --local-remote-dir, 247 to 255 characters still print step (4)'s wall before step (5) refuses them. The issue's direction is to ask only where a GitHub repository will be made, and step (5)'s refusal is exact, so this is left as it is.
• --help for --project does not state the 95. The refusal does. A help change regenerates docs/cli.md, which other lanes' PRs regenerate too.

Checklist candidates

• GitHub's topic limit may bound the name lower than 95. scaffold-project.py sets xf-project-<id> on each repository (_set_topics, scaffold-project.py:1668, through run, which raises on any non-zero exit). GitHub's documentation says a topic is at most 50 characters, so an id over 39 characters (the default id is the project lowercased) would fail at step (6), after the three repositories exist. A name of 40 to 95 characters passes this PR's bound. Not measured; it needs the real gh (lane 1), and the bound may be 39 for the default id.
• scaffold-project.py and adopt-project.py run directly have no GitHub bound. A bound in the scaffold's plan, beside scaffold-name-too-long, would cover them too. This change covers setup-project.py only, as the issue directs.
• --project 'Atlas ' (argv) still reaches step (4) with a space nobody can see. The naming gate's finding does not quote the names it lists. Either the gate quotes with ascii() or NAME_RE stops ending a project name in a space.
• --org has GitHub's own limit (39 characters, documented) and nothing asks it: a 40-to-255-character --org passes NAME_RE and fails at GitHub.

Closes #777

🤖 Generated with Claude Code

Summary by Sourcery

Improve setup-project.py validation so refused values explain their failed check, GitHub-backed project names respect repository-name limits, and interactively entered names handle surrounding spaces predictably.

New Features:

• Reject project names longer than 95 characters before GitHub-backed runs reach the naming-policy step.
• Trim leading and trailing spaces from project names entered interactively while preserving other whitespace and command-line values.
• Report the specific validation rule that caused each refused value.

Bug Fixes:

• Prevent interactive project names with stray spaces from being misclassified by the naming policy.
• Ensure validation behavior is consistent across terminal and piped input, including environments without a Git credential helper.

Enhancements:

• Clarify validation messages for project names, refs, control characters, revision ranges, and lock-file suffixes, including the applicable ASCII patterns.
• Preserve the local-run length behavior by applying the GitHub repository-name limit only when remote repositories will be created.

Tests:

• Add comprehensive edge-case coverage for refusal reasons, project-name length boundaries, interactive whitespace handling, ASCII validation descriptions, and ref suffix behavior.
• Harden terminal tests against machine-specific Git credential-helper configuration and verify GitHub runs do not stall during preflight.

[brettheap]

(lane openRepoShape-5, 2026-10-17T11:03Z) @codex review

[sourcery-ai]

Reviewer's Guide

The PR refines setup-project.py's validation flow: refusals now explain the specific failed check, non-local project names longer than 95 characters are rejected before step (4), and interactive names are trimmed while command-line values remain unchanged. New edge-case and regression tests cover validation precedence, platform-independent argument paths, GitHub/local length boundaries, and prompt behavior.

Flow diagram for project name validation paths

flowchart TD
    A[Receive project name] --> B{Source}
    B -->|Command line| C[checked_value]
    B -->|Interactive prompt| D[ask_for_the_project_name]
    D --> E[strip spaces]
    E --> C
    C --> F{Validation passes}
    F -->|No| G[why_refused]
    G --> H[refuse_value]
    H --> I[Exit 2]
    F -->|Yes| J{Local mode}
    J -->|Yes| K[Continue to step 4]
    J -->|No| L[checked_project_length]
    L --> M{At most 95 characters}
    M -->|Yes| K
    M -->|No| N[Refuse scaffold-name-too-long]
    N --> I

Loading

File-Level Changes

Change	Details	Files
Make validation refusals identify the first failed check and provide check-specific guidance.	Added ordered reason selection for empty, dash-prefixed, control-character, pattern, range, and lock-file failures. Updated callers and documentation while preserving the pinned repository-shape validator and ASCII-safe quoting. Added exhaustive tests for refusal carriers, precedence, wording, and pattern drift.	setup-project.py tests/test_setup_project_name_edges.py tests/test_setup_project_py.py
Reject overlong non-local project names before naming-policy evaluation.	Added a 95-character project limit derived from GitHub's documented 100-character repository limit and the five-character suffixes. Applied the check to flags, positional arguments, and prompts, including options parsed after the project name, while exempting local mode. Added boundary tests covering 95 through disk-limit behavior and ensuring no earlier output or filesystem changes.	setup-project.py tests/test_setup_project_name_edges.py
Normalize whitespace entered through the interactive project-name prompt without changing argv semantics.	Strip leading and trailing whitespace before validation and apply the project-length check to the normalized value. Treat whitespace-only answers as an empty response while retaining explicitly supplied argv values verbatim. Updated existing typed-name expectations and added PTY coverage for whitespace normalization and resulting project paths.	setup-project.py tests/test_setup_project_name_edges.py tests/test_setup_project_typed_name.py

Possibly linked issues

• setup-project.py: a refused project name gets one sentence that explains only a leading -, a trailing space passes where a leading one is refused and hides in step (4)'s report, and a name of 101 to 255 characters passes the prompt, to end at step (5) or at GitHub #777: The PR adds reason-specific refusals, rejects overlong GitHub project names before step (4), and strips spaces from prompted names.

---

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-17T11:05:02.876578Z	854f6ed	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

Here are some automated review suggestions for this pull request.

Reviewed commit: 854f6ed95c

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

[chatgpt-codex-connector]

Strip only ordinary spaces from prompted names

When a prompted name starts or ends with a tab, non-breaking space, or another Unicode whitespace character, Python's unrestricted str.strip() removes it before checked_value runs, so input that CONTROL_RE or NAME_RE deliberately rejects is silently converted to a valid name such as Atlas and scaffolding proceeds. This makes prompt validation differ from --project and can conceal pasted invalid characters; restrict trimming to the intended ASCII space character.

Useful? React with 👍 / 👎.

[brettheap]

(lane openRepoShape-2, 2026-10-17T16:18:08Z) Independent review of #811 (#777) at 854f6ed9, for lane openRepoShape-5: NOT READY

Findings, most severe first

1. MUST: CI is red because five new terminal tests depend on the machine's git credential helper. This is a test defect; setup-project.py behaves as designed.

   • Where: tests/test_setup_project_name_edges.py:143-158 (gh_that_is_signed_in) and :170-180 (at_the_prompt), used in GitHub mode (local=False) at :289-297 and :300-306.
   • What happens: without --local-remote-dir, the stub answers gh auth with 0. The preflight then runs _check_credential_helper (setup-project.py:1144-1175), which reads the real git config. With no helper for github.com it asks Run `gh auth setup-git` now? Type yes to continue: before step (3). The test types only once the project prompt shows, so the run waits at the offer until the 60 s timeout.
   • Evidence:
     • All five CI screens (run 39027235147) end at that offer, right after [ok] gh is authenticated as tester. (3) project never prints, and nothing was typed.
     • This host has credential.helper = !/usr/bin/gh auth git-credential for github.com, so here the five pass in 0.16 s to 0.73 s each.
     • With GIT_CONFIG_GLOBAL=<empty file> and GIT_CONFIG_NOSYSTEM=1, the same five hang here at the same offer: 5 failed, 60.0 s each.
     • With that hidden config plus GIT_CONFIG_COUNT=1, GIT_CONFIG_KEY_0=credential.https://githubproxy.fjygbaifeng.eu.org.helper and GIT_CONFIG_VALUE_0=!gh auth git-credential, they pass: 5 passed, slowest 1.33 s.
   • Not the other suspects (terminal width, readline, TERM, the 255-byte canonical line):
     • The run stops before anything is typed.
     • The local-mode prompt tests of the same lengths (95, 96, and the 256-character long case) passed in the same CI run (5 failed, 11487 passed).
   • A person does not hit this. At a terminal with no helper, they get the offer, answer it, then get the project prompt, and the bound applies the same way.
   • What the fix round must do:
     • Make the GitHub-mode runs independent of the host. Either:
       • have gh_that_is_signed_in also return a github.com helper through GIT_CONFIG_COUNT/_KEY_0/_VALUE_0, as tests/test_setup_project_py.py:1199 and tests/conftest.py:1409 already do for other keys; or
       • point GIT_CONFIG_GLOBAL at a file under tmp_path that holds the helper, and set GIT_CONFIG_NOSYSTEM=1.
     • Do not answer the offer with a second prompt. On a host that has a helper the offer never appears, so the test would wait there instead.
     • Prove the fix with the git config hidden (GIT_CONFIG_GLOBAL=<empty file> GIT_CONFIG_NOSYSTEM=1), not only on a machine that has a helper.

2. SHOULD: the prompt strips every whitespace character, not just the spaces its docs name. A typed tab, \x1f or NBSP is accepted where --project refuses it.

   • Where: setup-project.py:1590, .strip(). Python's str.strip() also removes tab, VT, FF, \x1c-\x1f, NEL, NBSP, U+3000 and the other Unicode spaces.
   • Measured at the head, local mode, typed both with stdin the terminal and with stdin a pipe. Each of these gives [ok] project Atlas and exit 0:
     • Atlas<TAB>, <TAB>Atlas
     • Atlas\x0b, Atlas\x0c, \x1fAtlas
     • Atlas\xa0, Atlas\x85, Atlas　
   • The same values given as --project exit 2, refused as a control character or by the name pattern. At b3c77cc2 each one was refused at the prompt too.
   • So 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 breaks setup-project.py: a project name typed at the prompt is checked as --project is and an empty line says no name was typed, so ../x, a/b, .. and --help are refused by name, not by an --id hint, a help page or a probe write (#729) #756's rule, that a typed name is checked as --project is, for these values. Yet the docstring (:1581-1588), the commit message, the test file's docstring and the PR body all say "the spaces".
   • The mutant .strip(" ") survives the new file and setup-project.py: a project name typed at the prompt is checked as --project is and an empty line says no name was typed, so ../x, a/b, .. and --help are refused by name, not by an --id hint, a help page or a probe write (#729) #756's file (41 passed).
   • It is not a safety hole: the value that goes on is clean.
   • Fix: .strip(" "), which matches the docs and keeps a typed control character refused. A typed line never carries \r or \n here: ask drops the newline, and a raw-mode terminal is refused (tests/test_setup_project_py.py:2866). The other option is to keep .strip(), say "whitespace" in the docstring and the PR, and pin a tab case.

3. SHOULD: the name sentence says "letters" and "spaces", but the pattern takes only ASCII letters and U+0020, so the words are wrong for the accented name the issue lists.

   • Where: setup-project.py:386-392 (WHY_PATTERN).
   • For Caf\xe9, Café or Atlas\xa0, the words "a letter or a digit first, then letters, digits, spaces and ..." describe a value that would pass. Only the pattern in backticks shows why it fails.
   • The drift guards (tests/test_setup_project_name_edges.py:355-381) only walk string.printable, so they cannot catch this.
   • The issue's own suggested wording has the same gap.
   • Fix: "an ASCII letter or a digit first, then ASCII letters, digits, spaces and ..." (or "A to Z"). Make the same change in the ref sentence and in the test's NAME and REF.

4. NIT: .lock anywhere in a ref passes the tests.

   • Where: setup-project.py:485. The mutant if ".lock" in text: survives (100 passed: the new file plus test_setup_project_py.py -k ref).
   • The new sentence says "ends in .lock", but no test shows topic.locked going through. One control case would pin it.

5. NIT: a list comprehension that only copies.

   • Where: tests/test_setup_project_name_edges.py:228, flags = [f for f in flags_for(tmp_path, False)] (ruff C416).
   • flags_for already returns a new list, so this can be flags = flags_for(tmp_path, False).

Checked and true

• setup-project.py: a refused project name gets one sentence that explains only a leading -, a trailing space passes where a leading one is refused and hides in step (4)'s report, and a name of 101 to 255 characters passes the prompt, to end at step (5) or at GitHub #777 line 1, refusal words. Each case ran three ways: as --project, typed with stdin the terminal, and typed with stdin a pipe.

  • Same verdict and same reason sentence on all three paths, differing only in --project is versus project name is, for: ., .., .hidden, /, \, a\b, a/b, Caf\xe9, Café, a leading or trailing U+200F, -x, and 256 characters.
  • No reason other than the dash prints the dash's words.
  • These differ by design, and all exit 2:
    • empty: --project '' says "It is empty"; an empty typed line says "no project name was typed" (setup-project.py: a project name typed at the prompt is checked as --project is and an empty line says no name was typed, so ../x, a/b, .. and --help are refused by name, not by an --id hint, a help page or a probe write (#729) #756).
    • three spaces: --project gets the pattern sentence; typed, it counts as no name.
    • -x and --help: --project gets the pattern sentence; typed, the space is stripped and the dash sentence follows.

• setup-project.py: a refused project name gets one sentence that explains only a leading -, a trailing space passes where a leading one is refused and hides in step (4)'s report, and a name of 101 to 255 characters passes the prompt, to end at step (5) or at GitHub #777 line 2, the 95 bound, in GitHub mode.

  • 95 characters go on.
  • 96, 100, 101 and 255 are refused with exit 2, in the same words apart from the label: before step (1) with nothing on stdout for --project and the positional, and before [ok] project at the prompt.
  • Under --local-remote-dir, 96 to 246 go on and 247 ends at step (5) with scaffold-name-too-long.
  • A --local-remote-dir given after --project is still read.

• setup-project.py: a refused project name gets one sentence that explains only a leading -, a trailing space passes where a leading one is refused and hides in step (4)'s report, and a name of 101 to 255 characters passes the prompt, to end at step (5) or at GitHub #777 line 3, spaces. Typed Atlas , Atlas and Atlas all become Atlas from step (3) on. --project 'Atlas ' is kept as given and ends at step (4) with exit 1. Choosing to strip is accepted, for the PR's reasons.

• Departures accepted:

  • repo_shape.checked_value is left as it is: it is pinned, so changing it means a re-pin, and it already prints its pattern.
  • The local 247-255 wall is left.
  • --help does not state 95.

• PR body numbers.

  • The new file has 60 tests.
  • On b3c77cc2 47 fail and 13 pass, and the 13 are exactly the controls it names.
  • render-cli-reference.py --check is ok, README is 1459 lines, and both changed files are ASCII only.

• Mutants: 6 of my 8 are caught: the positional spelled as the flag, the prompt always treated as local, control characters checked only at the start, the tail quoted one character short, the dash refused only when doubled, and the bound set to 94.

• Cognitive complexity (S3776), all under 15:

  • parse_args 13 (was 10), why_refused 5, checked_passthrough 3.
  • checked_project_length 2, checked_ref 2, checked_value 1, ask_for_the_project_name 1, refuse_value 0.
  • resolve_project_and_elector 14, unchanged.

• Test quality: no composite asserts in added test lines, and no run of 4 identical lines shared with another test file.

• Docs:

  • docs/cli.md, --help, README.md, docs/handbook.html and AGENTS.md only say "ONE CamelCase token". None states 255, 95 or the old dash sentence, so none disagrees with the head.
  • No other test asserts the old sentence. tests/test_adopt_git_reads.py:421 pins repo_shape's first sentence, which is unchanged.

• Paste lines: 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 adds none. The cleaned-up name only reaches the existing shell_word lines.

• Merges:

  Merge	Result	Tree	Tests
  main 24a977c0	clean	f2a7da0b	3 files: 312 passed
  b3c77cc2 merged with main first, then 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 on top	clean	same tree, f2a7da0b	as main
  repo_shape.py, setup-project.py, shape-doctor.py, README and the handbook: under Git Bash (MSYSTEM set) the lines that follow the host are quoted for sh, through one question, host_shell_dialect, so the doctor's lines, setup's family lines and family.py's NEXT, switch -c, add and cd lines paste whole in the shell that printed them, and README's Windows sentence says so #821 7581ffb9	clean	1314614f	3 files plus test_git_bash_dialect.py: 405 passed
  shape-doctor.py: a path that is not ASCII is printed as that path in every NEXT, keep line and WHY, as itself where the report's encoding writes its bytes and escaped whole where it does not, so a line naming Projets/Équipe or a Latin-1 name runs as printed (#785) #792 26d61255	clean	4991c7dc	3 files: 312 passed

• --preflight change: --preflight --project <96 characters> is now refused at parse, where b3c77cc2 ran the preflight. That matches how --preflight --project a/b is already refused.

Could not verify

• GitHub's 100-character limit. Checking it needs a real gh against a real organisation (lane 1).
• The PR's topic-limit concern. PROJECT_ID_RE (scripts/repo_shape.py:70) has no length limit, so a default id over 39 characters may fail --add-topic at step (6), after the three repositories exist. Not measured.
• Windows and macOS.
• Sonar's own analysis. The complexity figures come from the reviewer's own AST counter, checked by hand.
• Two older problems that 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 did not cause (same on b3c77cc2 and the head):
  • a NUL typed at the prompt (Ctrl-V Ctrl-@) with stdin the terminal hangs input();
  • a literal newline typed at the prompt ends the name at that point.

Since this review (lane 2's coordinator):

• The branch has moved to b5def3f0 (16:12:40Z), one commit on 854f6ed9. Its message says it answers MUST 1 the first way above: a helper in git's command scope, plus one run that empties git's own config.
• rv811 re-verifies the delta once you post the head that also answers SHOULDs 2 and 3, or say they stay.

Lane: openreposhape-2 (openRepoShape-2)

[brettheap]

(lane openRepoShape-2, 2026-10-17T17:11:13Z) Re-verification of #811 (#777) at 050abea6, for lane openRepoShape-5: READY

The delta from 854f6ed9 is two commits, b5def3f0 and 050abea6, with no merge of main. It touches only setup-project.py and tests/test_setup_project_name_edges.py.

The five findings from the review at 854f6ed9

1. MUST 1, the CI hang: FIXED (b5def3f0). The GitHub-mode typed runs depended on the machine's git credential helper.
   • The fix: gh_that_is_signed_in (tests/test_setup_project_name_edges.py:164) now gives git a github.com helper that points at the stub. It sits in git's command scope, at index GIT_CONFIG_COUNT, after any entries already set.
   • With git's own config hidden (GIT_CONFIG_GLOBAL=<empty file>, GIT_CONFIG_NOSYSTEM=1, as on the CI runner), the whole new file passes: 97 passed in 14.7 s. The five tests that hung on CI take 0.09 s to 0.51 s each.
   • With an unrelated GIT_CONFIG_COUNT=1 entry already in the environment, the five plus the new test still pass: 8 passed. So the append is right.
   • The new test is test_a_github_run_here_is_not_held_by_a_git_with_no_helper[95|96] (:359). It empties git's system and global files itself, and passes.
   • It catches a regression on any machine. With the helper taken out of gh_that_is_signed_in (mutant MJ), both cases fail after 60 s each, on this machine, which has a helper of its own.
2. SHOULD 2, the prompt stripping every kind of whitespace: FIXED (050abea6).
   • The prompt now strips only spaces: typed = typed.strip(" ") at setup-project.py:1601.
   • Probed typed both ways (stdin the terminal, and stdin a pipe): leading and trailing tab, VT, FF, \x1c, leading and trailing \x1f, leading and trailing NBSP, NEL and U+3000.
     • Each is refused with exit 2 and the same reason --project gives.
     • Control characters get the control sentence; NBSP, NEL and U+3000 get the name pattern.
   • Spaces still come off: typed Atlas and Atlas become Atlas, and a typed line of spaces is no name.
   • Pinned: the 9 cases are in NOT_THE_SPACE (:76), in the refusals and in the typed cases on both entries. Mutant MA2 (.strip() back) is now caught: 18 failed.
3. SHOULD 3, the name and ref sentences saying "letters" for ASCII-only patterns: FIXED.
   • The new words are: "an ASCII letter or digit first, then ASCII letters, digits, the space and ._'()&,+@-", and for a ref "... then ASCII letters, digits and ._/-".
   • I walked every code point (U+0000 to U+10FFFF) through NAME_RE and REF_RE:
     • First character: exactly the 62 ASCII letters and digits.
     • After a letter: besides ASCII letters and digits, exactly &'()+,-.@_ for a name and -./_ for a ref.
     • So both sentences are true for every value.
   • The drift guards now walk everything above ASCII (above_ascii_taken, :422). Mutant MO, a name pattern that takes Latin-1 letters, is caught (4 failed).
4. NIT 4, .lock anywhere passing the tests: FIXED.
   • test_a_ref_is_refused_for_lock_only_at_its_end (:463) checks that topic.locked and a.lockb go through checked_ref.
   • Mutant MB (".lock" in text) now dies.
   • git check-ref-format --branch takes both names and refuses topic.lock, as the test's docstring says.
5. NIT 5, the copy-only comprehension: FIXED. Line 276 is now flags = flags_for(tmp_path, False).

Checked and true

• Tests at 050abea6:

  • the three files (test_setup_project_name_edges.py, test_setup_project_typed_name.py, test_setup_project_py.py): 349 passed;
  • test_setup_sh.py, test_scaffold_pin_and_reuse.py, test_cli_reference.py and test_repo_hygiene.py: 263 passed.

• The new test file against b5def3f0's code: 42 failed and 55 passed, as lane 5 reports. The 42 are exactly the expected tests:

  • 14 refusals whose name or ref sentence changed;
  • 28 typed cases: the 5 name-pattern cases and the 9 non-space whitespace cases, each typed both ways.

• Round-2 mutants: all six are caught. My surviving mutants from the first review are now caught too: MA2 (18 failed) and MB (1 failed). The other four:

  • ML, stripping only the right end: 2 failed;
  • MK, the name words without "ASCII": 28 failed;
  • MO, the pattern taking Latin-1 letters: 4 failed;
  • MJ, no helper given to git: 2 failed.

• Cognitive complexity (S3776), all far under 15:

  • code: ask_for_the_project_name 1, why_refused 5, checked_ref 2, parse_args 13 (unchanged);
  • tests: typed_as_text 4, above_ascii_taken 3, gh_that_is_signed_in 1, the new tests 1 each.

• Test quality: no composite assert in the file, and no run of 4 identical lines shared with another test file.

• Docs: the delta changes no doc, --help text or pinned file. No doc states the name or ref sentence. render-cli-reference.py --check is ok, README is 1459 lines, and both changed files are ASCII only.

• Merges of 050abea6:

  Merge	Result	Tree	Tests
  main 64ec47c3 (21 commits ahead)	clean	184315aa	3 files: 349 passed
  repo_shape.py, setup-project.py, shape-doctor.py, README and the handbook: under Git Bash (MSYSTEM set) the lines that follow the host are quoted for sh, through one question, host_shell_dialect, so the doctor's lines, setup's family lines and family.py's NEXT, switch -c, add and cd lines paste whole in the shell that printed them, and README's Windows sentence says so #821 7581ffb9	clean	aa68ae82	3 files plus tests/test_git_bash_dialect.py: 442 passed
  shape-doctor.py: a path that is not ASCII is printed as that path in every NEXT, keep line and WHY, as itself where the report's encoding writes its bytes and escaped whole where it does not, so a line naming Projets/Équipe or a Latin-1 name runs as printed (#785) #792 26d61255	clean	2a1d94c4	3 files: 349 passed

  siblings.py: the printed move runs as typed past a taken staging name and names a dangling link to move aside first, a NUL or lone surrogate in project: or url is a finding, .gitmodules is read as git reads it, the warning's prose is spelled, and a tag-only branch is named (#690) #805, validate-family.py and validate-pins.py: a staged gitlink removal says to commit it, member-gitlink-absent puts the gitlink back by hand, the variant mv is guarded, and a pin row with no path: is shape-pin-row (#681) #747 and repo_shape.py, shape_materialize.py and adopt-project.py: a value the YAML reader refuses for opening with an indicator is named by its line and says to double-quote it or reword it, plan --org @x names --org again under the reader's own remedy, and check names one bad tracking_branch once (#708) #817, which landed since 24a977c0, touch none of 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 files.

Read by lane 2's coordinator from GitHub:

• mergeable is MERGEABLE at 050abea6, against its base fix/729-typed-project-name (setup-project.py: a project name typed at the prompt is checked as --project is and an empty line says no name was typed, so ../x, a/b, .. and --help are refused by name, not by an --id hint, a help page or a probe write (#729) #756).
• tests-git-bash, package and SonarCloud's quality gate pass.
• tests was still running at the time of this post. READY holds once it is green.

Could not verify

• GitHub's 100-character limit, and the topic-length follow-up (an id over 39 characters): both need a real gh against a real organisation (lane 1).
• Windows and macOS.
• A live Sonar analysis: the complexity figures come from an AST counter and were checked by hand.
• Still open, from the first review and not 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 doing: a typed NUL hangs input(), and a literal newline typed at the prompt ends the name there.

Lane: openreposhape-2 (openRepoShape-2)

[brettheap]

(lane openRepoShape-5, 2026-10-18T02:56:53Z) #811's second-lander conversion after #848: f1dbbbf5..b6f56cad.

#848 landed first, and its second-lander note gives this conversion to whichever of the two lands second. One commit, b6f56cad, on f1dbbbf5, by explicit pathspec, fast-forward pushed. It touches tests/test_setup_project_name_edges.py alone (12 insertions, 12 deletions). Tests only: nothing a user runs changes, and no pinned file, README, handbook, AGENTS.md or docs/cli.md line is touched.

The restack. The branch sits on #756's squash 4dea85ee, by the merges 6400cf4f (#756's final head 946b1354) and f1dbbbf5 (the squash, taking the branch's side in setup-project.py and tests/test_setup_project_typed_name.py). The -U0 lines are unchanged: git diff -U0 4dea85ee f1dbbbf5 has the same + and - lines, in the same 19 hunks, as git diff -U0 b3c77cc2 050abea6 had before the restack. Only the start line of 15 hunks moved.

The conversion. gh_that_is_signed_in built GIT_CONFIG_COUNT, GIT_CONFIG_KEY_{held} and GIT_CONFIG_VALUE_{held} by hand from the environment's own count, for credential.https://githubproxy.fjygbaifeng.eu.org.helper. At f1dbbbf5 #848's scan, test_no_test_sets_a_git_config_count_of_its_own, failed on it: {'test_setup_project_name_edges.py': [190]}. The three entries now come from appended_to_command_scope(os.environ, [("credential.https://githubproxy.fjygbaifeng.eu.org.helper", helper)]) (helper is "!%s auth git-credential" % shlex.quote(str(gh))), merged into the returned dict beside PATH, in #848's form. The file imports the helper in its sorted place in the from conftest import line. The docstring says the entry is appended to what the environment holds, and now names the helper that does it. os and shlex are still used. git grep -n GIT_CONFIG_COUNT -- tests/test_setup_project_name_edges.py finds only that docstring line.

Behaviour is the same. The function at f1dbbbf5 and the function at b6f56cad were run side by side, in one stub directory, and their returned dicts compared:

environment held	GIT_CONFIG_COUNT	entry written	the two dicts
two entries (GIT_CONFIG_COUNT=2)	3	GIT_CONFIG_KEY_2, GIT_CONFIG_VALUE_2	equal, same key order
none	1	GIT_CONFIG_KEY_0, GIT_CONFIG_VALUE_0	equal, same key order
an empty count	1	GIT_CONFIG_KEY_0, GIT_CONFIG_VALUE_0	equal, same key order

The key is credential.https://githubproxy.fjygbaifeng.eu.org.helper and the value is !<stub gh> auth git-credential in all three. PATH is equal too.

The runs, at b6f56cad, through the gh stub, with the git identity blanked as the lane's runner does:

run	passed	time
test_setup_project_name_edges.py 97, test_setup_project_typed_name.py 22, test_setup_project_py.py 230	349	246.60 s
#848's scan and its siblings: test_no_auto_maintenance.py 60, test_command_scopes_built_at_the_test.py 2, test_family_config_appends.py 8	70	10.74 s
test_repo_hygiene.py 78, test_agents_md_codes.py 47, test_cli_reference.py 23	148	40.02 s

No test failed or was skipped. The scan, which fails at f1dbbbf5, passes.

Lane: openreposhape-5 (openRepoShape-5)

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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 3 days and 11 hours by commenting @sourcery-ai review. Upgrade to get a review now.