[brettheap]

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

A project name typed at the project name prompt was used as typed. The same value as --project or as the positional goes through checked_value at parse time and is refused before step (1) prints. This is #729, lane 4's L4-21 from #459.

Review: rv729 reviewed 9f429f40 and gave APPROVE WITH NITS (two SHOULDs). The fix round below takes them. The head is b3c77cc2.

What was wrong

• Step (3) built the clone path from the typed name. Landing.clone_path joins it to --into with Path /, so .. leaves --into and an absolute name replaces it. Step (3) then asks the disk about that path, and since setup-project.py: step (3) passes an unwritable parent or a missing drive, and step (4) shows a chain the plan verifies as [declared-unverified] #608 refuse_a_parent_nobody_can_write_in makes and removes a probe folder in the nearest folder above it. It leaves nothing behind, but it was made outside --into.
• Step (4) did not catch it. The naming validator reads only the last part of what it is handed (../x passes as x), has no length bound, and reads a leading - as its own option.
• The refusals that did come were in the wrong words.
  • ../x, a/b and an absolute path ended at step (5) as scaffold-bad-id: --id ... is '../x', an id nobody passed.
  • --help made the validator print its help (it exited 0) at step (4), and the run ended at step (5) with the scaffold's usage, exit 2.
  • 256 characters ended at step (5) as unsafe-value: --project is ....
  • .. ended at step (4) as naming-unclassified, exit 1.
  • A control character was printed raw by [ok] project and [ok] legs.
• An empty line said there was no terminal. It reached usage(sys.stderr) and then "no --project given, and no terminal to ask on."

What changed

setup-project.py has one hunk: ask_for_the_project_name(), new, just before resolve_project_and_elector, and its call in place of the bare ask(...). The helper makes two edits to what a typed line does:

1. The typed name is checked. checked_value("project name", typed) runs right after the ask. It is the check take_positional makes, so the refusal is the tool's own wording with project name as its subject, exit 2, before anything reads or writes a path.
2. An empty typed line has its own refusal. "no project name was typed; nothing was created.", exit 2, no usage text. Ctrl-D at the prompt reads the same way, because ask returns an empty string for both. The can_ask() gate is unchanged and is still the refusal for no terminal.

Decisions and their evidence:

• a b and Bad_Name go to step (4), as now. NAME_RE is permissive on purpose and the policy rules on those. The new test types both and checks exit 1 with (4) naming policy printed.
• Nothing in step (3) changes, and the validator's basename rule stays as it is. The prompt check closes every row above, so scaffold-bad-id cannot be reached from a name step (4) accepts unless the person typed --id themselves.
• No document changes. --project's help says "Prompted for when omitted and a terminal is attached", which is still true. README and the handbook say nothing about the prompt. render-cli-reference.py --check passes: [ok] docs/cli.md is what the generator produces.
• No pinned file and no template changes. Only setup-project.py and one new test file.

Fix round

Review 9f429f40 raised two SHOULDs, and the nits below them. All are in b3c77cc2, one new commit.

• SHOULD-1, SonarCloud python:S3776. resolve_project_and_elector was at cognitive complexity 16 against 15. The prompt, the empty-line refusal and the check moved into ask_for_the_project_name(), with their comments. rv729's estimator (cogcx.py) puts resolve_project_and_elector back at 14 and the helper at 1. Behaviour is unchanged.
• SHOULD-2, the tests did not pin where the check sits. A check moved to just before check_names (rv729's M11), or to after resolve_family (M12), passed all 16 tests. Now:
  • assert_refused_at_the_prompt seeds a file at tmp_path/parent, where the folder above --into goes. A check made after step (3) has asked the disk would end in "is a file", so the test asserts project name is is on the screen and is a file is not.
  • It also asserts that [ok] project and [ok] legs are not printed, and that the seeded file is the only thing on the disk afterwards, unchanged.
  • M11 and M12 now each fail 12 tests (table below). Over the earlier test file they pass 16 of 16, run again here.
• The probe-write sentence now says what the tests show. setup-project.py: step (3) passes an unwritable parent or a missing drive, and step (4) shows a chain the plan verifies as [declared-unverified] #608's probe folder removes itself, so no test can see it. What the tests show is that a refused name stops before [ok] project prints and before any later step asks the disk: the seeded file is never reported, and nothing else appears.
• NIT-1: one hunk with two edits, as written above. NIT-2: the test docstring now says the validator exited 0 at step (4) and the run ended at step (5), exit 2. NIT-3: the empty line and Ctrl-D are also typed through the one-liner's shape (stdin a pipe) and through setup.sh, 6 tests in place of 2. NIT-5: (4) naming policy is one constant, NAMING_POLICY.

Tests

tests/test_setup_project_typed_name.py is new, 20 tests. It types each name at a pseudo-terminal through run_in_a_terminal, as tests/test_setup_project_py.py does for Sample, POSIX only (PTY_SKIP). It takes piped, run_entry, terminal_env, SETUP_PROJECT and SETUP_SH from tests/test_setup_project_py.py and adds no conftest helper. Each test is a one-call wrapper over one helper, with parametrize for the cases.

• 10 names refused at the prompt (../x, a/b, .., ., -x, --help, a name with a control character typed with ^V, 256 characters, three spaces, an absolute path under tmp_path). For each: exit 2; the refusal holds project name is <ascii(value)>, which is not a value; no is a file, [ok] project, [ok] legs, (4) naming policy, usage text or --id on the screen; only the seeded file is on the disk.
• Parity. Each of those 10 also runs the same value as --project with no terminal and holds the two refusals equal once REFUSED: --project is reads REFUSED: project name is.
• Two more ways in (../x): the one-liner's shape, stdin a pipe and the answer read from the controlling terminal; and setup.sh, the shim.
• Empty line and Ctrl-D, each through the file run directly, the piped shape and setup.sh (6 tests): the refusal is exactly REFUSED: no project name was typed; nothing was created., exit 2, with no "no terminal", no usage text and no is a file.
• Bad_Name and a b: exit 1, step (4) printed, no project name is refusal.

Runs on the head b3c77cc2, through the gh-stub runner:

run	result
tests/test_setup_project_typed_name.py	20 passed
tests/test_setup_project_py.py	230 passed
tests/test_setup_sh.py (89), the new file (20), tests/test_repo_hygiene.py (77), tests/test_cli_reference.py (22), run together	208 passed

Fails on the base

The new file over origin/main's setup-project.py (66b230ed, in a separate clone): 18 failed, 2 passed. The two that pass are Bad_Name and a b, which already exit 1 at step (4).

Reproduction, base against head

Each name typed at the prompt, with --local-remote-dir and the gh stub:

typed	on 66b230ed	on the head
../x	step (4) and (5) print; REFUSED scaffold-bad-id: --id (not given, so --project lowercased) is '../x', exit 2	REFUSED: project name is '../x', ..., exit 2, nothing after (3) project
a/b	the same scaffold-bad-id	project name is 'a/b', exit 2
--help	the validator's help and the scaffold's usage print, exit 2	project name is '--help', exit 2
256 x	REFUSED unsafe-value: --project is ... at step (5), exit 2	project name is 'xxx...', exit 2
absolute path	scaffold-bad-id with the lowercased path as the id, exit 2	project name is '/tmp/...', exit 2
a, BEL, b	[ok] project prints the raw BEL; step (4) refuses ab, exit 1	project name is 'a\x07b', exit 2
..	step (4) naming-unclassified, exit 1	project name is '..', exit 2
empty line	usage text, then "no --project given, and no terminal to ask on."	"no project name was typed; nothing was created.", no usage

Mutation probes

Each mutant is applied to the head's setup-project.py in a separate clone and run over the new file (20 tests). Mutants 1 to 3 are the writer's; 4 to 12 are rv729's (mutate9.py, re-aimed at the helper's lines because the check now sits in it).

mutant	failed	passed
M1 no check (return typed)	12	8
M2 no empty-line refusal (the empty line then fails checked_value as project name is '')	6	14
M3 subject --project in place of project name	12	8
M4 check just before the [ok] lines	0	20
M5 partial check (a leading - or a / only)	5	15
M6 empty line exits 1	6	14
M7 the path pattern in place of the name pattern	9	11
M8 check typed.strip(), keep typed	1	19
M9 empty line prints usage first	6	14
M10 check skips control characters	1	19
M11 check just before check_names	12	8
M12 check after resolve_family	12	8

M11 and M12 passed all 16 tests of 9f429f40, and fail now. M4 passes, and rv729's own order test passes it too: it does no path work before the refusal, and its only difference is that outside --local-remote-dir a gh api user call is made first, which these runs never make.

Merge checks

git merge-tree --write-tree of the head b3c77cc2, against:

• origin/main 2a33a569: clean.
• setup-project.py: family_folder_here reads the family's DISPLAY name, so the layout family.py init makes for a family created with --name is not detected as a family folder and the old display-name layout is #696 (fix/696-setup-family-folder), which edits setup-project.py at family_folder_here: clean. Lane 4's wip/696-fix1-swap-checkpoint: clean.
• tests: the holder fixtures copy the family fixture with shutil.copytree while git's background gc or maintenance can still be packing it, so a test errors at setup when a loose object vanishes mid-copy (#440's race, through a file copy) #645, tests/conftest.py: one helper builds the url.<base>.insteadOf rewrite that clone_just_pushed and read_through_git each build, and the plain-path git submodule update --init sites of #554's review use it (#440) #662 and tests: the non-UTF-8 name and branch tests: one skip helper for a filesystem that refuses probe\udcff, Windows guards on make_file and the --branch a\udcffb case, and the UTF-8 promise and the leg finding's role pinned #663, which edit tests/conftest.py: clean. This PR does not edit conftest and uses nothing of theirs.
• Every other head on origin that is not on main (all fix/*, l3-* and wip/* heads): clean, except four that conflict with origin/main itself, in files this PR does not touch: fix/688-family-init-values, l3-677-pins-hand-step-wip, release/v1.0 and docs/release-notes-v1.0.0. The conflict counts against the head and against origin/main are equal for each.

No other branch edits tests/test_setup_project_py.py or tests/test_setup_sh.py.

Left out

Not fixed here:

• refuse_value's one sentence does not say why ../x, a/b or .. is refused. It explains the leading -, then "the rest must be spellable as a name, a ref or a path". A name must start with a letter or digit and hold none of /, \. This is shared by --project, the positional and now the prompt, so a better sentence is a change to every refusal and its tests.
• A name of 101 to 254 characters passes the prompt. In local mode a 101-character name reaches the confirmation. The scaffold's plan refuses 255 (scaffold-name-too-long, because <Project>-spec is 260 bytes). I did not check what a real gh does with a name over GitHub's own repository-name cap.
• The validator's basename rule (../x passes as x) stays as it is, as the issue directs.
• A typed trailing space is treated unlike a leading one (rv729's candidate). Atlas passes the check and ends at step (4), exit 1, while Atlas is refused at once, exit 2. A prompt answer, unlike an argv value, is where stray spaces come from; stripping them would change the three-spaces test, so it is a design choice for v1.1.1.
• The refusal's sentence names the leading - as the reason for every refusal (rv729's candidate, adding to the first item above): odd for Atlas, Atlas/ and Café. It is shared with --project.
• A mistyped name ends the run with no re-ask (rv729's candidate; unchanged by this PR).
• At 255 characters the run ends at step (5) after printing the family wall three times (rv729, reproduced; adds to the 101-254 item above).

Review. rv729 re-verified the fix round: APPROVE at b3c77cc2. The extraction is byte-identical, M11 and M12 now fail, the three test files give 339 passed, and SonarCloud analysed b3c77cc2 with S3776 gone (quality gate OK, 0 code smells).

Closes #729

🤖 Generated with Claude Code

Summary by Sourcery

Validate and clearly report project names entered at the interactive prompt before creating or inspecting project paths.

Bug Fixes:

• Validate project names entered at the interactive prompt using the same checks as --project and positional arguments, preventing unsafe paths, options, control characters, and invalid values before filesystem work begins.
• Report empty prompt responses as an explicit missing project name instead of treating them as a missing terminal or displaying usage output.

Enhancements:

• Keep names accepted by the initial value check available for the existing naming-policy validation in step (4).

Tests:

• Add pseudo-terminal coverage for invalid prompted names, empty and EOF responses, alternate entry points, refusal ordering, filesystem safety, and parity with --project validation.

[brettheap]

(lane openRepoShape-5, 2026-10-16T23:42Z) @codex review

[sourcery-ai]

Reviewer's Guide

The PR closes the interactive project-name validation gap by applying command-line checks immediately after prompting, adding a specific empty-input refusal, and introducing comprehensive PTY tests that verify consistent errors, safe early termination, and preserved step-(4) policy behavior.

Sequence diagram for interactive project name validation

sequenceDiagram
    actor User
    participant SetupProject
    participant checked_value
    participant NamingPolicy
    participant Filesystem

    User->>SetupProject: ask("project name")
    alt empty input
        SetupProject->>SetupProject: die("no project name was typed#59; nothing was created.")
    else non-empty input
        SetupProject->>checked_value: checked_value("project name", typed)
        alt unsafe project name
            checked_value-->>SetupProject: refusal
            SetupProject->>SetupProject: die(...)
        else accepted by value check
            checked_value-->>SetupProject: project name
            SetupProject->>NamingPolicy: validate at step (4)
            NamingPolicy-->>SetupProject: policy result
            SetupProject->>Filesystem: build project path at step (3)
        end
    end

Loading

File-Level Changes

Change	Details	Files
Validate project names entered interactively with the same value checks used for command-line input, and distinguish an empty response from the absence of a terminal.	Run checked_value("project name", typed) immediately after the prompt, before any path construction or later workflow steps. Refuse empty input with a dedicated exit-2 message without printing usage; preserve the existing no-terminal refusal path. Leave policy-level names such as a b and Bad_Name for step (4), where the naming policy reports them.	setup-project.py
Add pseudo-terminal coverage for validation parity, refusal behavior, and input paths.	Cover traversal, slash, dot, option-like, control-character, overlong, whitespace, absolute, and empty inputs, asserting wording, exit status, lack of usage or side effects, and parity with --project. Verify accepted-by-value but policy-invalid names still reach step (4), plus stdin-pipe and setup.sh entry points. Reuse existing PTY helpers and mark the test module POSIX-only.	tests/test_setup_project_typed_name.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#729	Validate a project name typed at the prompt with the same check used for --project or the positional argument, before it can be used to build or inspect a path.	✅
#729	Give an empty prompt answer its own exit-2 refusal without a usage dump or a misleading no-terminal message.	✅
#729	Leave names accepted by the shared value check, such as Bad_Name and a b, for the step (4) naming policy to decide.	✅

Possibly linked issues

• Tracking: setup, scaffold, family and the shared helpers, creating projects and families #459: The PR checks prompted names with checked_value before path handling and gives empty answers a specific refusal, matching the issue.

---

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: Didn't find any major issues. Already looking forward to the next diff.

Reviewed commit: 9f429f40b6

ℹ️ 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]

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-16T23:44:12.497822Z	9f429f4	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.

[sonarqubecloud]

Quality Gate passed

Issues
0 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 1 day and 22 hours by commenting @sourcery-ai review. Upgrade to get a review now.