[brettheap]

Goal

The value patterns the issue names refuse a value that ends in a line feed, by name, as #1126 (#1017) makes COMMIT_RE, SHA256_RE and COMMIT_40 do:

• DATE_RE and QUALIFIED_RE in validate-manifest.py and validate-family.py, MEMBER_RE in scripts/family.py, DATE_RE in scripts/shape_advisory.py and REPOSITORY_RE in update-shape.py;
• PROJECT_ID_RE, read with fullmatch where the two validators and family.py add read an id from a file.

A shape pin's source_repository: that is neither a path on this machine nor an owner/repo name is refused in the pin's name, not --upstream's. Values without a line feed keep their outcome, and no refusal code is added or renamed. Two inputs do move from one existing code to another (see "Behaviour changed", below).

What this PR does not cover, and the title does not claim:

• the naming-policy patterns that scripts/repo_shape.py reads from contracts/repository-naming.yaml, which validate-repository-naming.py still reads with .match;
• update-upstream-not-a-repo, which still says --upstream when a pin names a folder that exists and is not a repository.

Both are follow-ups, with the other findings of the independent review, under "Follow-ups (not in this PR)".

This does not need #1126 and does not touch its files or its test file.

What held on main

Measured on main 038dafba (Python 3.12.3, git 2.43.0) by a probe of each tool, before any change. Each value is written in the file as a YAML double-quoted "...\n", which the reader takes as the value and a line feed.

Read from	Value	On main
project.yaml (validate-manifest.py)	id: "atlas\n"	only FINDING manifest-topic: topic is 'xf-project-atlas', expected 'xf-project-atlas\n' derived from id 'atlas\n', exit 1
project.yaml	elected_on: "2026-09-02\n"	manifest ok, exit 0
project.yaml	a leg's repository: "testorg/Atlas-spec\n"	manifest ok, exit 0
family.yaml (validate-family.py)	id: "inkrouter\n"	family ok: InkRouter (inkrouter and a line break, exit 0
family.yaml	created_on: "2026-09-04\n"	family ok, exit 0
family.yaml	a member's repository: "InkRouter/IRRS\n"	FINDING member-repository-name: ... whose name is 'IRRS\n', exit 1
a member's project.yaml, read by family.py add	id: "irqs\n"	mounted and committed, exit 0, with the row id: "irqs\n"; the holder's gate then said family ok
contracts/shape-pin.yaml, update-shape.py check with no --upstream	source_repository: "opensoft/openRepoShape\n"	REFUSED unsafe-value: --upstream is 'opensoft/openRepoShape\n', exit 2
the same	source_repository: "opensoft/open Repo"	REFUSED update-upstream-unresolvable: --upstream 'opensoft/open Repo' is neither ..., exit 2
the same	source_repository: "-opensoft/openRepoShape"	REFUSED unsafe-value: --upstream is '-opensoft/openRepoShape', exit 2
an adoption plan (adopt-project.py check)	id: "northwind\n"	FINDING plan-manifest-invalid: id is 'northwind\n', which the project's own validate-manifest.py refuses: manifest-topic: ..., exit 1; execute refused it, exit 2, before any leg

In-process on the same main: repo_shape.PROJECT_ID_RE.match('atlas\n'), shape_advisory.DATE_RE.match('2026-09-02\n') and REPOSITORY_RE.match('a/b\n') each matched, and date.fromisoformat('2026-09-02\n') raised ValueError.

What changed

• DATE_RE and QUALIFIED_RE in templates/assembly-root/scripts/validate-manifest.py and templates/family-root/scripts/validate-family.py end in \Z. So do MEMBER_RE in scripts/family.py (the third spelling tests/test_family_member_name.py holds equal to the two QUALIFIED_RE), DATE_RE in scripts/shape_advisory.py and REPOSITORY_RE in update-shape.py.

• PROJECT_ID_RE keeps its $. Every id refusal prints its text (must match ^[a-z0-9][a-z0-9-]*$, pinned in six test files), the validators run against each project's own copy of repo_shape.py, and its definition sits inside repo_shape.py and bootstrap.py: COMMIT_RE, SHA256_RE and COMMIT_40 end in \Z, not $, so a pin's commit: or tree_sha256: that ends in a line break is refused as not 40 or 64 hex by every validator and adopt-project.py (#1017) #1126's hunk. The three callers that read an id from a file ask it with fullmatch instead: validate-manifest.py (manifest-id), validate-family.py (family-id) and family.py's reading of a member's project.yaml (member-bad-id, which add now says before anything is mounted).

• update-shape.py. open_upstream(spec, pin_path=None) takes the pin the value was read from, which prepare passes when no --upstream was given. Then update-upstream-unresolvable says <root>/contracts/shape-pin.yaml: `source_repository:` is '...', which is neither a path on this machine nor an `owner/repo` name, with a remedy to write the pin's field or pass --upstream, and checked_value names the same field. Code kept: update-upstream-unresolvable, the existing code for a value that is not an owner/repo name. A line feed now reaches it, since the pattern no longer takes one. Before, checked_value refused it as unsafe-value.

• One existing test line: tests/test_family_init_values.py finds validate-family's DATE_RE line by its text, which now ends \Z.

• One existing stand-in: the temporaries fixture in tests/test_update_shape_unreadable.py stands in for open_upstream with def opening(spec), which the new two-argument call refused with TypeError: ... takes 1 positional argument but 2 were given. It now takes pin_path=None and hands it on to the real open_upstream, so test_a_read_refused_in_prepare_closes_the_upstream[check|apply] asks what it asked before.

• The rows are in a new file of their own, tests/test_value_pattern_line_break.py.

• A second guard, in a second commit (5102b4294, a test only, no production file). The first guard holds the four pattern names this PR ends in \Z, and nothing held PROJECT_ID_RE, which keeps its $. test_every_reader_of_the_id_pattern_is_in_the_table reads every tracked .py outside tests/ with ast (it runs none) and holds each call of a method of PROJECT_ID_RE (PROJECT_ID_RE.x(...) or repo_shape.PROJECT_ID_RE.x(...)) to the table ID_READERS:

  • the three fullmatch readers of an id from a file (validate-manifest.py, validate-family.py, scripts/family.py);
  • the modules that still match it, each with its reason: argv --id in scaffold-project.py and scripts/family.py, where checked_value refuses a line feed after the pattern; argv --id in adopt-project.py, which the project's own validate-manifest.py refuses (adopt-manifest-invalid, below; ID_READERS still gives it the checked_value reason); and adopt-project.py's two plan-bad-id readers, of the plan's id: and of the id derived from legs.assembly, which a line feed never passes (below).

  A new reader of PROJECT_ID_RE, fullmatch included, fails it by file and method until it is listed in ID_READERS with its reason. The table is exact both ways, so a reader taken away fails it too.

Left as they are, and why:

• the argv readers of PROJECT_ID_RE (--id in scaffold-project.py, family.py init and adopt-project.py). The first two hold the id to checked_value after the pattern, which refuses a line feed as unsafe-value naming --id, and tests/test_derived_id_refusals.py pins that answer for them. adopt-project.py never calls checked_value on --id: plan with --id set to northwind and a line feed exits 2 with adopt-manifest-invalid, in the words of the project's own validate-manifest.py (manifest-id), and writes no plan (lane 5's re-check, issuecomment-6371408915, NIT 2; measured on plan only);
• adopt-project.py's reading of a plan's id:: check and execute hold it to the project's own validate-manifest.py, which refused it on main (above) and now names it in manifest-id's words. It is the same value, refused under the same code, plan-manifest-invalid, before any leg exists. The id derived from legs.assembly is read with .match too, and a line feed in legs.assembly is unsafe-value before that id is asked (the review measured both, on main and here alike). This keeps the open PRs on adopt-project.py (24 at 12:02Z) clear;
• PIN_ARG_RE, and NAME_RE/REF_RE/PATH_RE in setup-project.py, as the issue says;
• update-upstream-not-a-repo still says --upstream. A pin's value reaches it only when it names a path that exists, not through the pattern.

Behaviour changed, stated plainly, and what the issue's Verify means by "No refusal code changes": the issue's Verify line reads as no code added or renamed, and none is. Two inputs do move from one existing code to another, exit 2 both before and after:

• update-shape.py --upstream "opensoft/openRepoShape<LF>" was unsafe-value and is now update-upstream-unresolvable, still naming --upstream;
• a pin's source_repository: that ends in a line feed, with no --upstream, was unsafe-value naming --upstream and is now update-upstream-unresolvable naming the pin's field.

No test pinned either old answer: every gate below passed. family.py add --member is stripped before MEMBER_RE, so add answers as before.

Not changed, seen while measuring: with --upstream passed, update-shape.py does not read the pin's source_repository: through REPOSITORY_RE at all, and it keeps the value as the upstream's repository name. validate-family.py does not hold a member row's id: to PROJECT_ID_RE; it compares the row with the member's manifest. Neither is a $ question. Both are under "Follow-ups (not in this PR)".

Rows failing on main

All in tests/test_value_pattern_line_break.py, run against main's production code: the five production files swapped in place from origin/main (961640c68), then put back with their sha256 matching (dirty=5 in the run's START line is those five files). On the head 5102b4294 (30 rows) the result is 20 failed, 10 passed in 23.12s, git 2.43.0. The 10 that pass are baselines: the seven test_a_pattern_takes_its_value rows, the spelling-table guard and the two double-quoted-without-a-line-feed rows.

The first 19 are the first commit's rows (19 failed, 10 passed in 22.12s on its 29 rows at 038dafba). The independent review reproduced them from main's bytes of the same five files (19 failed, 10 passed in 26.78s, the same 19 ids). The 20th, test_every_reader_of_the_id_pattern_is_in_the_table, is the second commit's: it fails on main because the three readers of an id from a file are .match there, not .fullmatch.

• test_a_pattern_refuses_its_value_and_a_line_feed[manifest-DATE_RE]
• test_a_pattern_refuses_its_value_and_a_line_feed[manifest-QUALIFIED_RE]
• test_a_pattern_refuses_its_value_and_a_line_feed[family-DATE_RE]
• test_a_pattern_refuses_its_value_and_a_line_feed[family-QUALIFIED_RE]
• test_a_pattern_refuses_its_value_and_a_line_feed[family.py-MEMBER_RE]
• test_a_pattern_refuses_its_value_and_a_line_feed[shape_advisory-DATE_RE]
• test_a_pattern_refuses_its_value_and_a_line_feed[update-shape-REPOSITORY_RE]
• test_a_manifest_value_that_ends_in_a_line_break_is_a_finding[id]
• test_a_manifest_value_that_ends_in_a_line_break_is_a_finding[elected_on]
• test_a_manifest_value_that_ends_in_a_line_break_is_a_finding[leg-repository]
• test_adopt_check_names_a_plan_id_that_ends_in_a_line_break_as_an_id
• test_a_family_value_that_ends_in_a_line_break_is_a_finding[id]
• test_a_family_value_that_ends_in_a_line_break_is_a_finding[created_on]
• test_a_family_value_that_ends_in_a_line_break_is_a_finding[member-repository]
• test_add_refuses_a_member_whose_id_ends_in_a_line_break
• test_a_pins_source_that_is_no_owner_repo_is_named_as_the_pins[line-feed]
• test_a_pins_source_that_is_no_owner_repo_is_named_as_the_pins[space]
• test_a_pins_source_checked_value_refuses_is_named_as_the_pins
• test_an_upstream_passed_with_a_line_feed_is_named_as_passed
• test_every_reader_of_the_id_pattern_is_in_the_table

Mutants

13 of 13 killed. Each mutant was applied alone to one file of the branch's production bytes (the same bytes as the first commit and as the head, which adds a test only), the rows were run, and the file was put back with its sha256 checked (restored=yes for all 13). Each run is tests/test_value_pattern_line_break.py plus tests/test_family_member_name.py::test_every_spelling_of_the_member_name_rule_is_the_same_pattern, git 2.43.0.

Mutant	File	Killed by
M1 DATE_RE back to $	validate-manifest.py	2: test_a_pattern_refuses_its_value_and_a_line_feed[manifest-DATE_RE], test_a_manifest_value_that_ends_in_a_line_break_is_a_finding[elected_on]
M2 QUALIFIED_RE back to $	validate-manifest.py	3: ...[manifest-QUALIFIED_RE], ...[leg-repository], test_every_spelling_of_the_member_name_rule_is_the_same_pattern
M3 the id read with .match	validate-manifest.py	2: test_a_manifest_value_that_ends_in_a_line_break_is_a_finding[id], test_adopt_check_names_a_plan_id_that_ends_in_a_line_break_as_an_id
M4 DATE_RE back to $	validate-family.py	2: ...[family-DATE_RE], test_a_family_value_that_ends_in_a_line_break_is_a_finding[created_on]
M5 QUALIFIED_RE back to $	validate-family.py	3: ...[family-QUALIFIED_RE], ...[member-repository], test_every_spelling_of_the_member_name_rule_is_the_same_pattern
M6 the id read with .match	validate-family.py	1: test_a_family_value_that_ends_in_a_line_break_is_a_finding[id]
M7 MEMBER_RE back to $	scripts/family.py	2: ...[family.py-MEMBER_RE], test_every_spelling_of_the_member_name_rule_is_the_same_pattern
M8 a member's id read with .match	scripts/family.py	1: test_add_refuses_a_member_whose_id_ends_in_a_line_break
M9 DATE_RE back to $	scripts/shape_advisory.py	1: ...[shape_advisory-DATE_RE] (its pattern row alone: date.fromisoformat refuses the line feed after the pattern, so no tool row sees it)
M10 REPOSITORY_RE back to $	update-shape.py	3: ...[update-shape-REPOSITORY_RE], test_a_pins_source_that_is_no_owner_repo_is_named_as_the_pins[line-feed], test_an_upstream_passed_with_a_line_feed_is_named_as_passed
M11 prepare passes no pin	update-shape.py	3: test_a_pins_source_that_is_no_owner_repo_is_named_as_the_pins[line-feed] and [space], test_a_pins_source_checked_value_refuses_is_named_as_the_pins
M12 checked_value names --upstream again	update-shape.py	1: test_a_pins_source_checked_value_refuses_is_named_as_the_pins
M13 the pin's refusal sentence removed	update-shape.py	2: test_a_pins_source_that_is_no_owner_repo_is_named_as_the_pins[line-feed] and [space]

No mutant is added for the stand-in in tests/test_update_shape_unreadable.py: it is a test change.

The independent review re-ran M3, M8, M11 and M12, and one mutant of its own (X1: prepare names the pin even when --upstream is passed). All five were killed, and each file was put back with its sha256 checked. The other nine of the 13 are this writer's runs alone.

The second commit's guard: 6 of 6 probes caught. Each was applied alone to one tracked file at 5102b4294, test_every_reader_of_the_id_pattern_is_in_the_table was run, and the file was put back with its sha256 checked (restored=yes for all six). The first commit's guard, test_every_spelling_of_a_value_pattern_is_in_the_table, was run with each plant too: it passes every one of them, which is the gap the second guard closes.

Probe	File	The new guard	The first guard
P1 a new PROJECT_ID_RE.match(value) reader appended	update-shape.py	failed: ('update-shape.py', 'match'): 1 is more than the table holds	passed
P2 a new repo_shape.PROJECT_ID_RE.search(value) reader appended	scripts/shape_advisory.py	failed	passed
P3 fullmatch back to match	templates/assembly-root/scripts/validate-manifest.py	failed	passed
P4 fullmatch back to match	templates/family-root/scripts/validate-family.py	failed	passed
P5 fullmatch back to match	scripts/family.py	failed	passed
P6 main's bytes of those three files together (the 20th row above)	the three	failed	not run

Runs

The second commit 5102b4294 (dirty=0), Python 3.12.3, with the same stub gh, bogus token and no global git config:

Run	Git	Result
tests/test_value_pattern_line_break.py	2.43.0	30 passed in 23.00s
tests/test_value_pattern_line_break.py	2.47.1	30 passed in 23.30s
tests/test_pinned_copy_text.py, tests/test_path_guard_hygiene.py, tests/test_repo_hygiene.py, tests/test_agents_md_codes.py, tests/test_cli_reference.py	2.43.0	306 passed in 61.54s

That commit changes only the test file (62 lines added, no assert that joins conditions with and or or, ASCII), so the first commit's runs below are not repeated: they hold the production files and every other test file, and those are unchanged. CI on 5102b4294, and an independent look at the second commit, were not done when this was written.

The independent review of the first commit (rv1166c, READY, read-only) reports these gates on 2593952c9, all passing: the stand-in gate's 6 files (298 passed), the new file on 2.47.1 (29 passed), the five hygiene files (306 passed), 15 more test files that name a changed function, pattern or code (1611 passed, 19 skipped) and tests/test_shape_doctor.py (445 passed, 3 skipped). It also read CI on that head at about 20:04Z: tests (the full suite on 3.14), tests-git-bash, package and SonarCloud all passed.

The first commit's gates ran on 2593952c (dirty=0), Python 3.12.3, with the real gh unreachable (a stub first on PATH, a bogus token) and no global git config:

Run	Git	Result
the files that held every failure and setup error of the shards below: tests/test_family.py, tests/test_update_shape_pr_base.py, tests/test_update_shape_unreadable.py, tests/test_update_shape_header_comments.py, tests/test_update_shape_messages.py and the new tests/test_value_pattern_line_break.py	2.43.0	298 passed in 343.60s
tests/test_value_pattern_line_break.py	2.47.1	29 passed in 21.31s
tests/test_pinned_copy_text.py, tests/test_path_guard_hygiene.py, tests/test_repo_hygiene.py, tests/test_agents_md_codes.py, tests/test_cli_reference.py	2.43.0	306 passed in 69.12s

The two shards, on the uncommitted tree holding the same production bytes as the first commit (the 7 files' sha256 checked before and after), git 2.43.0: the validators' test files, the REPOSITORY_RE/source_repository files and the update-shape.py, shape_advisory.py and family.py files, 125 in all.

• shard 1 (62 files): 4 failed, 5290 passed, 13 skipped in 56 min;
• shard 2 (63 files): 3 failed, 4 setup errors, 3761 passed, 29 skipped in 50 min.

Every failure and setup error is in the five existing files of the first row of the table above, which all pass on the first commit:

• 2 were real: test_a_read_refused_in_prepare_closes_the_upstream[check|apply], the opening(spec) stand-in under the two-argument call. The stand-in is fixed in the first commit.
• The other 5 failures and the 4 setup errors were update-conflict on scripts/validate-family.py ("not a verbatim copy ... at the pinned commit"). This is an artifact of an uncommitted tree: tests/test_family.py's upstream_clone commits the working tree into its clone, while family.py init pins the holder at the real HEAD, so an uncommitted templates/family-root/ file is never verbatim at its pin. On the first commit they pass.

Every other file of the two shards passed on these production bytes, so the shards were not re-run.

Merge-trees

git merge-tree --write-tree <other> 5102b4294 (git 2.43.0) at 2026-10-23T12:08Z, after re-fetching main (still 961640c6; read again at 12:10Z, just before the push) and re-listing the open PRs at 12:02Z (55 open). Main has moved from the 038dafba that this body measured to 961640c6 by one file, docs/release-notes/v1.2.0.md. Each open PR that touches one of this PR's 8 paths, at its current head, plus #1126:

Against	Head	Shares	Result
origin/main	961640c6		clean, tree 4613729516ff
#1098	dad7961a	scripts/family.py	clean, tree 4d1ff9517588
#1117	10dc011c	scripts/family.py	scripts/family.py merges clean; conflict in docs/handbook.html only, which this PR does not touch (see below)
#1124	8dfa32bd	validate-family.py	clean, tree cb2ec1073646
#1126	4c1f80cf	none (its scripts/repo_shape.py and tests)	clean, tree e82c8945ac37
#1133	a7bfee1b	update-shape.py	clean, tree a710870d1ffc
#1144	89486f69	scripts/shape_advisory.py	clean, tree 2d3e3e1ef43d
#1147	b75babee	validate-manifest.py	clean, tree a82ac3b47a3f
#1159	66e68f94	scripts/shape_advisory.py	clean, tree 4abeb7b38665
#1164	74096eb4	scripts/family.py	clean, tree ee285e1cb8cf
#1172	5aa0f116	validate-family.py	clean, tree aa32d41e6e2c
#1187	cc8a87ee	update-shape.py, tests/test_update_shape_unreadable.py	clean, tree 25711eb1cac4
#1201	eac177af	scripts/family.py	scripts/family.py merges clean; conflict in docs/handbook.html only (see below)

• family.py: the remove that both member-duplicate-id remedies name and the add that bump's member-unknown names carry --family-root <holder>, quoted for the host, so each runs as printed (#1005) #1117 and family.py: the add, bump and remove lines its remedies name begin with the interpreter and the script's path, quote the row's name, fill in the family's org, say the branch they run on, and member-already-present prints its remove (#1127) #1201 conflict in docs/handbook.html alone. family.py: the add, bump and remove lines its remedies name begin with the interpreter and the script's path, quote the row's name, fill in the family's org, say the branch they run on, and member-already-present prints its remove (#1127) #1201 is stacked on family.py: the remove that both member-duplicate-id remedies name and the add that bump's member-unknown names carry --family-root <holder>, quoted for the host, so each runs as printed (#1005) #1117 (their merge-base is family.py: the remove that both member-duplicate-id remedies name and the add that bump's member-unknown names carry --family-root <holder>, quoted for the host, so each runs as printed (#1005) #1117's head 10dc011c). Each of them against origin/main alone gives the same conflict in the same file, so it is theirs: family.py: the remove that both member-duplicate-id remedies name and the add that bump's member-unknown names carry --family-root <holder>, quoted for the host, so each runs as printed (#1005) #1117's, from its older base 6da757cb, which family.py: the add, bump and remove lines its remedies name begin with the interpreter and the script's path, quote the row's name, fill in the family's org, say the branch they run on, and member-already-present prints its remove (#1127) #1201 inherits.
• update-shape.py: apply puts every byte back under any OSError after its first write, says what it put back on stderr, and raises the error as it was, so a file gone between its stat and its read, a broken pipe or an EIO no longer leaves the tree half-written behind a traceback (#1173) #1187 and family.py: the add, bump and remove lines its remedies name begin with the interpreter and the script's path, quote the row's name, fill in the family's org, say the branch they run on, and member-already-present prints its remove (#1127) #1201 are new since the first merge-trees. update-shape.py: apply puts every byte back under any OSError after its first write, says what it put back on stderr, and raises the error as it was, so a file gone between its stat and its read, a broken pipe or an EIO no longer leaves the tree half-written behind a traceback (#1173) #1187 shares tests/test_update_shape_unreadable.py with this PR; its diff adds or removes no line that names open_upstream, def opening or REPOSITORY_RE, so it brings no one-argument stand-in for the two-argument call. That was read for all 55 open heads at 12:12Z; only this PR's own lines name them.
• No other open PR adds or removes a call of a method of PROJECT_ID_RE, which the second guard counts: the lines each of the 55 open heads adds or removes outside tests/, docs/ and *.md were read at 12:04Z. Only this PR's own name it, and family.py: the add, bump and remove lines its remedies name begin with the interpreter and the script's path, quote the row's name, fill in the family's org, say the branch they run on, and member-already-present prints its remove (#1127) #1201's one new MEMBER_RE.fullmatch is another pattern. So a sibling landing first does not move the guard's table.

Follow-ups (not in this PR)

Each is a candidate for its own issue. They come from the independent review (rv1166c, READY at 2593952c9, issuecomment-6352173084), which measured each of them on main and at the head unless the item says it did not. The review's finding numbers are in brackets.

• The naming-policy patterns [1]. scripts/repo_shape.py reads the families, the roles and the topic pattern of contracts/repository-naming.yaml with .match (family["_re"].match(name), family["_split_re"].match(name), role["_re"].match(name), and topic_pattern, which defaults to ^xf-project-[a-z0-9-]+$). validate-repository-naming.py --project project.yaml runs in the root template's Makefile and validate.yml. At the head, and on main, it exits 0 on a leg repository: "testorg/Atlas\n" and prints the line feed inside its table; -spec and -code the same. The project's gate as a whole still fails, because validate-manifest.py now refuses that manifest.

• update-upstream-not-a-repo with a pin [3]. With no --upstream, a pin whose source_repository: names a folder that exists and is no repository (the review measured contracts and scripts/repo_shape.py) is REFUSED update-upstream-not-a-repo: --upstream contracts exists but is not a git repository, exit 2, on main and here. pin_path is in scope at update-shape.py:686-687, so that refusal can name the pin as update-upstream-unresolvable now does.

• A pin's line feed when --upstream is passed [9]. update-shape.py check --upstream <clone> over a pin whose source_repository: ends in a line feed exits 0, nothing to do. The value is kept as upstream.repository, which reaches the README shape line's check, apply's commit subject and the pull request words (update-shape.py:2525, 3017 and 5121). The review measured check, not apply. It belongs with the previous item.

• A member row's id: [4]. On main, add of a member whose project.yaml reads id: "irqs\n" commits the row id: "irqs\n", and the holder's validate-family.py then says family ok. Under mutant M8 (this branch with main's .match in add) the same row is written, and the gate still says family ok. By code reading, not measured end to end: validate-family.py compares a row's id with the member manifest's by str equality (member-id-mismatch, validate-family.py:1608), and _check_member_ids_unique does the same, so neither asks PROJECT_ID_RE of a row. This PR makes add refuse such a member, so no new holder gets such a row.

• Values that no pattern reads [8]. The review's sweep found these manifest ok or family ok, exit 0, with a trailing line feed, at the head and on main alike:

  • in project.yaml: name, a spec or code leg's path, shape.repository and shape.digests.digest_algorithm;
  • in family.yaml: org, the family's own repository, tracking_branch, and the shape's and each member pin's digest_algorithm.

  No ^...$ pattern reads them, so they are not this PR's. A leg's path is checked only by _leg_path_findings, which asks no pattern, and the family's tracking_branch is refused in project.yaml (manifest-tracking-branch, U+000A) but not in family.yaml. shape.commit and tree_sha256 with a line feed are also manifest ok; that is repo_shape.py and bootstrap.py: COMMIT_RE, SHA256_RE and COMMIT_40 end in \Z, not $, so a pin's commit: or tree_sha256: that ends in a line break is refused as not 40 or 64 hex by every validator and adopt-project.py (#1017) #1126's.

The first commit's message, and what the review measured

The first commit's message says "the three readers of an id from a file ask it with fullmatch (manifest-id, family-id, member-bad-id)". That is true of those three, but it reads as if there were no others [2]. What the review measured instead:

• adopt-project.py still reads the id derived from legs.assembly (:6780) and the plan's id: (:6791), both plan-bad-id, with .match;
• neither lets a line feed through. A plan id: "northwind\n" is plan-manifest-invalid, now in manifest-id's words. A plan with no id: and legs.assembly: "NorthWind\n" is REFUSED unsafe-value: legs.assembly is 'NorthWind\n', exit 2, before the derived id is asked, on main and here alike.

So it is the wording alone that overstates. The second commit's ID_READERS lists both readers with that reason.

The title's pin clause is the narrower one (the pin's name only where the value is no path and no owner/repo name), and two inputs change from unsafe-value to update-upstream-unresolvable (see "Behaviour changed", above).

Closes #1139

Lane: openreposhape-5 (openRepoShape-5)

🤖 Generated with Claude Code

Summary by Sourcery

Reject trailing line feeds in validated identifiers and repository-related values, and attribute invalid shape-pin sources to the pin that supplied them.

Bug Fixes:

• Reject trailing line feeds in manifest, family, member, advisory-date, and repository values instead of accepting them as valid input.
• Report invalid shape-pin source_repository: values against the pin field rather than the absent --upstream option.
• Reject member project IDs ending in a line feed before mounting or recording the member.

Enhancements:

• Use complete-value matching for IDs read from project and family files while preserving the existing ID pattern and refusal codes.
• Add coverage and guards for all relevant value-pattern readers, including protection against untracked ID-pattern call sites.

Tests:

• Add regression tests covering trailing-line-feed handling across validators, family operations, adoption checks, and shape updates.
• Update affected test fixtures for the expanded upstream-opening interface and revised pattern text.

[sourcery-ai]

Reviewer's Guide

Data structures

Anchor the end-sensitive date and repository-name patterns at the actual end of values, and retain the public ID-pattern spelling while requiring whole-value matches for IDs read from files.

• scripts/family.py L310-313, L1133-1137
• scripts/shape_advisory.py L169-172
• templates/assembly-root/scripts/validate-manifest.py L116-121, L798-804
• templates/family-root/scripts/validate-family.py L193-198, L588-593
• update-shape.py L208-211

API

Extend upstream resolution to accept the source pin's path context, so invalid pin values and unsafe-value refusals identify the pin field while explicit --upstream errors retain their existing naming.

• update-shape.py L671-678, L692-700 (+2 small edits)

Uses of the API

Pass the pin path only when no --upstream argument was supplied, preserving the distinction between a pin-derived source and an explicitly supplied upstream.

• update-shape.py L2422-2423

Tests

Update the upstream-opening stand-in for the added optional pin-path argument.

• tests/test_update_shape_unreadable.py L228-229

Keep the family validator's source-text assertion aligned with its end-anchored date pattern.

• tests/test_family_init_values.py L592

Add regression coverage for line-feed-terminated values, pin-specific refusal messages, and the inventory of end-sensitive patterns and ID-pattern readers.

• tests/test_value_pattern_line_break.py L1-396

---

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.

[brettheap]

Independent review of #1166 (#1139) for lane openRepoShape-5

Reviewers: rv1166, then rv1166c (Opus 5.5), read-only, at head 2593952c9519c4b96de295657635fc711f75c695. That head equals refs/pull/1166/head by ls-remote at 20:04Z and again at 21:44Z. main is 961640c6 (#1155). From 038dafba, the base the body measured, to 961640c6, only docs/release-notes/v1.2.0.md changed.

Verdict: READY. There are no MUST or SHOULD findings.

• Every row the body says fails on main does fail there, for the reason the body gives.
• Every mutant I ran is killed.
• The sweep found no value that main accepts and the change now refuses, other than a value that ends in a line feed.
• Pinned copies stay compatible, every gate passes on the commit, and every merge-tree is clean.

There are 9 NITs or follow-ups, below. Findings 1-7 are the partial review's, now measured where they were not. Findings 8 and 9 are new.

What held (measured)

1. The patterns. At the head these end in \Z:

   • DATE_RE and QUALIFIED_RE in both validators (validate-manifest.py:120-121, validate-family.py:194-195);
   • MEMBER_RE (scripts/family.py:312-313);
   • DATE_RE in scripts/shape_advisory.py:166;
   • REPOSITORY_RE in update-shape.py:211.

   fullmatch is used at validate-manifest.py:803 (manifest-id), validate-family.py:589 (family-id) and scripts/family.py:1137 (member-bad-id). That is what the body says.

2. The rows fail on main. I swapped main's bytes of the 5 production files into the scratch worktree and ran tests/test_value_pattern_line_break.py (git 2.43.0, Python 3.12.3). The result was 19 failed, 10 passed in 26.78s. Afterwards I put the files back and checked their sha256 (restored=True).

   • The 19 failing ids are exactly the 19 the body lists (diff of the two sorted lists is empty).
   • The 10 that pass are the baselines the body names.
   • Each row fails for the answer the body's "What held on main" table gives. For example:
     • [id] fails on FINDING manifest-topic: ... expected 'xf-project-atlas\n' derived from id 'atlas\n';
     • [elected_on] and [leg-repository] fail on manifest ok, exit 0;
     • test_add_refuses_... fails on add, which mounted the member and committed 9f19175faf7a: .gitmodules, members/IRQS, family.yaml;
     • the pin rows fail on REFUSED unsafe-value: --upstream is 'opensoft/openRepoShape\n'.

3. Mutants. I chose 4 of the writer's 13 and added 1 of my own. Each was applied alone to one production file at the head, then run against the new file plus test_family_member_name.py::test_every_spelling_of_the_member_name_rule_is_the_same_pattern. Each file was restored with its sha256 checked (restored=yes for all). All 5 are killed:

   Mutant	File	Result	Killed by
   M3: the id read with .match	validate-manifest.py	2 failed, 28 passed	test_a_manifest_value_that_ends_in_a_line_break_is_a_finding[id], test_adopt_check_names_a_plan_id_that_ends_in_a_line_break_as_an_id
   M8: a member's id read with .match	scripts/family.py	1 failed, 30 passed	test_add_refuses_a_member_whose_id_ends_in_a_line_break
   M11: prepare passes no pin	update-shape.py	3 failed, 27 passed	test_a_pins_source_that_is_no_owner_repo_is_named_as_the_pins[line-feed] and [space], test_a_pins_source_checked_value_refuses_is_named_as_the_pins
   M12: checked_value names --upstream again	update-shape.py	1 failed, 29 passed	test_a_pins_source_checked_value_refuses_is_named_as_the_pins
   X1 (mine): prepare names the pin even when --upstream is passed	update-shape.py	1 failed, 29 passed	test_an_upstream_passed_with_a_line_feed_is_named_as_passed

   The killers of M3, M8, M11 and M12 are the ones the body's table names. I did not run the other 9 of the writer's 13 (M1, M2, M4-M7, M9, M10, M13): not measured by me.

4. The sweep: no value without a line feed changes its answer. I ran the same probe at the head and on main's production bytes (9 rows each, 9 passed both times). It rewrites, one at a time, every scalar line of a scaffolded project.yaml (32 lines), a family holder's family.yaml (35 lines) and an adoption plan (plan's own output, 62 lines) as a double-quoted value with a trailing \n. It also runs each file with CRLF line ends, and block scalars |, > and |-.

   • Of the 163 probe lines, 18 differ between main and the head. 16 of them are an answer that changed, and every one is a value that ends in a line feed:
     • project.yaml: id and id: | (manifest-topic became manifest-id), elected_on, elected_on: | and >, and the three legs' repository (manifest ok became a finding);
     • family.yaml: id, created_on and created_on: | (family ok became a finding), and two members' repository (member-repository-name became member-repository);
     • the plan's id (manifest-topic became manifest-id, both under plan-manifest-invalid);
     • add of a member whose id: ends in a line feed, and the rows it leaves (2 lines).
   • The other 2 differ only in a gitlink sha, because main's bytes build different fixture commits. They are the members' path, which is still member-gitlink-unnamed on both.
   • The 5 rows keyed by a sha or a temporary path (the member pins' commit and tree_sha256, the plan's local_path) give the same answer on both.
   • A CRLF project.yaml, family.yaml and plan each give exit 0 on both. load_yaml reads with universal newlines (repo_shape.py:1339). A \r was never taken by $ anyway, so no CR answer moves.
   • |- gives exit 0 on both. | and > keep the line feed by YAML's own rule, and are now refused by name. No tool writes a block scalar (repo_shape.py:950 says so), so only a hand edit reaches one.
   • By code reading (not measured end to end), the values a tool writes into these fields come from argv, which checked_value already refuses with a line feed, or from date.today(). None comes from a subprocess's output.

5. Gates on the commit (dirty=0, Python 3.12.3, a stub gh first on PATH, a bogus token, no global git config), all rc=0. They ran at 20:06-20:28Z, and the head has not moved since:

   Run	Git	Result
   the 6 files of the stand-in gate (test_family.py, the four test_update_shape_* files, the new file)	2.43.0	298 passed in 257.80s
   tests/test_value_pattern_line_break.py	2.47.1	29 passed in 23.69s
   test_pinned_copy_text.py, test_path_guard_hygiene.py, test_repo_hygiene.py, test_agents_md_codes.py, test_cli_reference.py	2.43.0	306 passed in 63.98s
   15 more test files that name a changed function, pattern or code (adopt, scaffold, manifest-validator, family-init, member-name, member-path, family.py-unreadable, local-remote-dir and others)	2.43.0	1611 passed, 19 skipped in 1033.50s
   tests/test_shape_doctor.py	2.43.0	445 passed, 3 skipped in 745.67s

   CI on this head also passed: tests (the full suite on 3.14), tests-git-bash, package and SonarCloud. rv1166 read that at about 20:04Z, and it was not read again. The new file has no assert that joins conditions with and or or, and it is ASCII.

6. Pinned-copy compatibility.

   • The import lines of both validators are identical at 038dafba and 2593952c.
   • scripts/repo_shape.py is untouched.
   • PROJECT_ID_RE is re.compile(r"^[a-z0-9][a-z0-9-]*$") in the repo_shape.py of v1.0.0, v1.1.0, v1.1.1 and main. So .fullmatch exists on every pinned copy.
   • I imported the head's validate-manifest.py and validate-family.py beside the repo_shape.py of v1.1.1, of 038dafba and of repo_shape.py and bootstrap.py: COMMIT_RE, SHA256_RE and COMMIT_40 end in \Z, not $, so a pin's commit: or tree_sha256: that ends in a line break is refused as not 40 or 64 hex by every validator and adopt-project.py (#1017) #1126's head 4c1f80cf. All 6 imported, and PROJECT_ID_RE.fullmatch('atlas\n') gave None.

7. The pin's refusal names the pin. It names root_of(args) / SHAPE_PIN, the same absolute spelling that read_pin and check_pin use. shape-doctor.py always passes upstream= (lines 3341 and 6226), so its rows are unchanged.

8. Merge-trees. git merge-tree --write-tree <other> 2593952c at 2026-10-22T21:50Z (git 2.43.0), against main and every open PR that touches one of this PR's 8 paths, at heads re-listed at 21:50Z (45 open). All are clean:

   Against	Head	Tree
   main	961640c6	aa1de7bc
   family.py: a failed remove's by-hand lines spell a leg mounted at a path that is not UTF-8 as a printf word of octal escapes ending in a slash, so git -C <member>/<leg> and submodule update -- <leg> typed in any POSIX shell name that leg (#1086) #1098	dad7961a	5c4f23f1
   validate-family.py: gitmodules-path-twice and the check for values git dies on read the .gitmodules git reads, the index's where the work tree's is gone, and every section's lines end git add -- .gitmodules, so a plain git commit after them takes the section out of HEAD (#1077) #1124	8dfa32bd	6ae5e02b
   repo_shape.py and bootstrap.py: COMMIT_RE, SHA256_RE and COMMIT_40 end in \Z, not $, so a pin's commit: or tree_sha256: that ends in a line break is refused as not 40 or 64 hex by every validator and adopt-project.py (#1017) #1126	4c1f80cf	eae12927
   update-shape.py: update-accept-local-missing-name asks a copy an earlier apply kept, read unchanged, as a module a written copy imports from and as an importer of a written one, so a plain apply that stops either on its import is refused (#1082) #1133	a7bfee1b	67858a0b
   shape-doctor.py and shape_advisory.py: a .git or an agent file linked into a folder this user cannot search is said once in what is here or agent files, <name>: cannot be read (<reason>), never absent; a .git offers no way in (#1110) #1144	89486f69	630ea103
   shape-doctor.py, validate-pins.py and validate-manifest.py: a root whose own .git this user cannot read is named .git: cannot be read (<reason>), so the doctor never reads it as DRIFTED, and both pinned validators refuse it, exit 2 (#1146) #1147	b75babee	6f690ce8
   shape_advisory.py and shape-doctor.py: a leg's AGENTS.md this user cannot read leaves whether it is a leg unknown, so the way in offers neither command and points at what is here, and the other way in and the Triad row are silent (#1110) #1159	66e68f94	f4d96aa8
   family.py and the family root's siblings.py: a holder's .gitmodules this user cannot read, as through a link into a folder it cannot search, is gitmodules-unreadable, never no section for remove's rollback or no url for make siblings (#1110) #1164	3162b523	1e8e43c8
   bootstrap.py, validate-family.py and siblings.py: a root or holder whose .git this user cannot read is refused git-repo-unreadable, exit 2, not a traceback or not-a-git-repo, and the doctor's members row names it once, never drift (#1148) #1172	5aa0f116	bd57903d

   • family.py: the remove that both member-duplicate-id remedies name and the add that bump's member-unknown names carry --family-root <holder>, quoted for the host, so each runs as printed (#1005) #1117 (10dc011c) conflicts in docs/handbook.html only. It has the same conflict against main alone.
   • At 20:12Z, no added line in the diffs of the then-41 open PRs, other than validate-manifest.py, validate-family.py, family.py and update-shape.py: an id:, a date or a repository: ending in a line feed is refused by name, and a pin's source_repository: that is no path or owner/repo name is named as the pin's (#1139) #1166's own, named open_upstream, PROJECT_ID_RE, DATE_RE, QUALIFIED_RE, MEMBER_RE, REPOSITORY_RE or source_repository.

Findings

1. NIT, now measured end to end: the Goal's "Every ^...$ pattern that reads a value from a file" claims too much.

   • The naming-policy patterns from contracts/repository-naming.yaml are still read with .match (scripts/repo_shape.py:2264, 2266, 2432, 2435, and topic_pattern).
   • validate-repository-naming.py --project project.yaml runs in the root template's Makefile:48 and validate.yml:310. At the head (and on main) it exits 0 on a leg repository: "testorg/Atlas\n", and prints the line feed inside its table (' Atlas', then project-leg/assembly on the next line). The same holds for -spec and -code.
   • The project's gate as a whole still fails, because validate-manifest.py now refuses that manifest.
   • Suggest: narrow the Goal to the patterns the issue names, or open a follow-up for the naming-policy patterns.

2. NIT, measured: the commit message says "the three readers of an id from a file ask it with fullmatch", but there are more.

   • adopt-project.py:6780 and :6791 (plan-bad-id) still read the plan's id: and the id derived from legs.assembly with .match.
   • Neither lets a line feed through:
     • the plan's id: "northwind\n" is plan-manifest-invalid, now in manifest-id's words, as the body says;
     • a plan with no id: and legs.assembly: "NorthWind\n" is REFUSED unsafe-value: legs.assembly is 'NorthWind\n', exit 2, before the derived id is asked, on main and at the head alike.
   • So this is wording only. Fix it in the squash message at landing.

3. NIT, measured: the title says "a shape pin's source_repository: is refused in the pin's name", but one refusal still blames the flag.

   • With no --upstream, and run from the root, source_repository: "contracts" gives REFUSED update-upstream-not-a-repo: --upstream contracts exists but is not a git repository, exit 2.
   • source_repository: "scripts/repo_shape.py" gives the same.
   • The answer is the same on main. pin_path is in scope at update-shape.py:686-687.
   • The body discloses it. Make it a one-line follow-up, or narrow the title.

4. FOLLOW-UP, measured: a holder that main's add already wrote stays family ok.

   • On main, add of a member whose project.yaml reads id: "irqs\n" commits a row id: "irqs\n", and the holder's gate then says family ok.
   • Under mutant M8 (the head with main's .match in add), the same row is written, and the head's validate-family.py still exits 0, family ok.
   • By code reading: the row's id is compared with the member manifest's id by string equality (validate-family.py:1608). _check_member_ids_unique does the same. Neither asks PROJECT_ID_RE of a member row.
   • The body names this as a follow-up candidate. The PR closes the add path, so no new holder gets such a row.

5. NIT: two inputs move from one existing code to another.

   • A pin's source_repository: ending in a line feed, and argv --upstream "owner/repo<LF>", both go from unsafe-value to update-upstream-unresolvable. Measured on main and at the head by the rows above.
   • The body says so for argv. The issue's Verify says "No refusal code changes". That reads as "no code added or renamed", and none is.
   • Nothing pins the old answer: every gate and CI are green.
   • Suggest: one line in the body tying this to the issue's Verify.

6. NIT: the body's Merge-trees section is stale.

   • main is 961640c6.
   • update-shape.py: update-accept-local-missing-name asks a copy an earlier apply kept, read unchanged, as a module a written copy imports from and as an importer of a written one, so a plain apply that stops either on its import is refused (#1082) #1133 is at a7bfee1b, shape_advisory.py and shape-doctor.py: a leg's AGENTS.md this user cannot read leaves whether it is a leg unknown, so the way in offers neither command and points at what is here, and the other way in and the Triad row are silent (#1110) #1159 at 66e68f94 and family.py and the family root's siblings.py: a holder's .gitmodules this user cannot read, as through a link into a folder it cannot search, is gitmodules-unreadable, never no section for remove's rollback or no url for make siblings (#1110) #1164 at 3162b523.
   • bootstrap.py, validate-family.py and siblings.py: a root or holder whose .git this user cannot read is refused git-repo-unreadable, exit 2, not a traceback or not-a-git-repo, and the doctor's members row names it once, never drift (#1148) #1172 (5aa0f116, validate-family.py) is new.
   • All are clean (table above).

7. NIT, optional: the new guard covers only four pattern names.

   • test_every_spelling_of_a_value_pattern_is_in_the_table holds DATE_RE, QUALIFIED_RE, MEMBER_RE and REPOSITORY_RE only.
   • Nothing holds a new PROJECT_ID_RE.match reader of a file. The two in adopt-project.py are live examples, harmless today (finding 2).

8. FOLLOW-UP, outside validate-manifest.py and validate-family.py: PROJECT_ID_RE, DATE_RE and QUALIFIED_RE end in $, so an id:, a date or a repository: that ends in a line break passes as well formed (#1126 follow-up) #1139: values that no pattern reads still take a trailing line feed. The sweep found these manifest ok / family ok, exit 0, at the head and on main alike:

   • in project.yaml: name, a spec or code leg's path (spec\n), shape.repository, shape.digests.digest_algorithm;
   • in family.yaml: org, the family's own repository, tracking_branch, and the shape's and each member pin's digest_algorithm.

   No ^...$ pattern reads them, so they are not this PR's.

   • A leg path: "spec\n" is checked only by _leg_path_findings, which asks no pattern.
   • The family's tracking_branch is refused in project.yaml (manifest-tracking-branch, U+000A) but not in family.yaml.

   shape.commit and tree_sha256 with a line feed are also manifest ok; that is repo_shape.py and bootstrap.py: COMMIT_RE, SHA256_RE and COMMIT_40 end in \Z, not $, so a pin's commit: or tree_sha256: that ends in a line break is refused as not 40 or 64 hex by every validator and adopt-project.py (#1017) #1126's.

9. NIT, for the record: with --upstream passed, a pin's source_repository: that ends in a line feed is not refused.

   • update-shape.py check --upstream <clone> over such a pin exits 0, nothing to do.
   • The value is kept as upstream.repository, which reaches the README shape line's check, apply's commit subject and the pull request words (update-shape.py:2525, 3017, 5121). I measured check only, not apply.
   • The body names this under "Not changed, seen while measuring". It belongs with finding 3's follow-up.

Logs

$Q/v124/rv1166/ on the lane-5 bench:

• logs/onmain-new.log, logs/probe-head.log, logs/probe-main.log and logs/mut-*.log;
• probe-head.txt, probe-main.txt and probe-M8.txt;
• merge-trees-c.log, gates.summary and gates2.summary;
• compat.txt.

Lane: openreposhape-5 (openRepoShape-5)

[brettheap]

Re-check of #1166 (#1139) NIT round for lane openRepoShape-5

READY at 5102b4294

Re-checker rc1166b, read-only: no commit, push or GitHub write. I checked only the delta since the review's head 2593952c9. That delta is the ID_READERS guard commit plus the replaced title and body.

There are no MUST and no SHOULD findings. The guard does what the body says, and it fails when it should. Every review item the body says it fixed is fixed, except where noted below. There are four NITs. NIT 2 is a false justification that the body, the test file and the commit message all repeat.

Findings

MUST: none.

SHOULD: none.

NIT 1: a new fullmatch reader also fails the guard, so "read with fullmatch" alone does not pass it.

• Where it is claimed:
  • tests/test_value_pattern_line_break.py:57-60 (module docstring);
  • :195-199 (the test's docstring: "it is read with fullmatch, or it is in ID_READERS ... or this fails");
  • the body: "A new match or search reader fails it by file and method, until it is read with fullmatch or listed with its reason".
• What I measured:
  • I appended def _rc_probe(value): return PROJECT_ID_RE.fullmatch(value) to update-shape.py.
  • The guard failed with Left contains 1 more item: {('update-shape.py', 'fullmatch'): 1}.
  • The table is exact in both directions. Making one adopt-project.py reader unreachable (if False: in place of the plan-id: test at :6791) failed it too: {('adopt-project.py', 'match'): 2} != {('adopt-project.py', 'match'): 3}.
• Why it is a NIT: the assert id_pattern_calls() == expected at :200 has no message, so the author sees only a dict diff.
• Fix: say "listed in ID_READERS" in the docstring and the body, or give the assert a message that names ID_READERS. A sibling that adds any new reader, fullmatch included, must add a row. The body's scan found none among the open PRs.

NIT 2: for adopt-project.py the "argv --id: checked_value refuses a line feed after it" reason is false. A line feed is still refused.

• Where it appears:
  • ID_READERS: the scaffold-project.py and scripts/family.py rows (:159, :161) and the adopt-project.py row (:162-167, "argv --id, as above");
  • the module docstring's "LEFT AS THEY ARE" bullet;
  • the body's "Left as they are" bullet and the new second-guard bullet;
  • the second commit's message ("the three match readers of argv (checked_value refuses a line feed after them)").
• What I measured: adopt-project.py plan --id=northwind<LF> (head 5102b4294, a local source, through conftest's write_plan) gave:

  REFUSED adopt-manifest-invalid: --id is 'northwind\n', which the project's own validate-manifest.py refuses: manifest-id: id is 'northwind\n'; it must match ^[a-z0-9][a-z0-9-]*$.
  

  It exited 2 and wrote no plan.
• Why the reason is wrong:
  • adopt-project.py never calls checked_value("--id", ...). _checked_flag_inputs checks --project, --tracking-branch, --pin-owner, the leg paths and --org.
  • tests/test_derived_id_refusals.py TOOLS pins that answer for scaffold and family only.
• So the claim holds for two of the three argv readers. For adopt-project.py the refusal comes from the project's own validator, adopt-manifest-invalid in manifest-id's words, and the id is refused all the same.
• Fix: correct the body now. Leave the checked_value clause out of the squash message, or say it of the scaffold and family.py init only. Rewording the adopt-project.py string in ID_READERS is optional, because it costs a new head. The issue itself says adopt's --id was "not measured end to end".

NIT 3: the body's "Merge-trees" section is a snapshot that main has since passed.

• The body says main is 961640c6. The local origin/main is now ef619c74a, which is ac5f28d2a plus tests/test_adopt_check_throwaway_repos.py: rows pin that refused_paths holds each case twin under its own name and blob, or names it, with core.ignorecase true or false, and that check names the twins git refuses and none it holds (#1033) #1158, a test file. ac5f28d2a itself carries family.py: a failed remove's by-hand lines spell a leg mounted at a path that is not UTF-8 as a printf word of octal escapes ending in a slash, so git -C <member>/<leg> and submodule update -- <leg> typed in any POSIX shell name that leg (#1086) #1098 (scripts/family.py, which the body lists as open), scaffold-project.py: a push ssh refused the host's key for names how to check that key against GitHub's fingerprints, not the ruleset hint, and the hint on GitHub says what its re-run can still wait at (#1108) #1130 (scaffold-project.py) and tests/test_bom_tool_io.py: the byte-order-mark rows hold each tool's own read and write and that only U+FEFF is cut, so a utf-8-sig read that drops the mark and a cut that also takes spaces no longer survive (#1176) #1188 (tests/test_bom_tool_io.py).
• git merge-tree --write-tree ef619c74a 5102b4294 returns rc=0, tree ccd5a26e032a.
• On that merged tree PROJECT_ID_RE is read exactly as ID_READERS lists it. That is adopt 3, scaffold 1, scripts/family.py fullmatch 1 and match 1, and one fullmatch each in the two validators. The git grep line counts for scaffold-project.py (2) and scripts/family.py (3) include one comment line each.
• No action is needed beyond the landing gate's update-branch run.

NIT 4: the guard reads spellings, not meaning (optional).

• _ID = PROJECT_ID_RE followed by _ID.match(value) in update-shape.py passes both guards (2 passed). By reading, from repo_shape import PROJECT_ID_RE as X does the same.
• A match in a string or a comment is correctly not counted: 2 passed.
• The body claims only PROJECT_ID_RE.x(...) and repo_shape.PROJECT_ID_RE.x(...), so nothing in it is false.

Review items the body says it fixed

The numbers are the review's, in issuecomment-6352173084.

• [1] Goal over-claims: fixed.
  • The Goal now names the patterns the issue names, and a "What this PR does not cover" list says what is left.
  • The issue's own Direction names PROJECT_ID_RE, DATE_RE, QUALIFIED_RE and REPOSITORY_RE, "wherever the validators define or copy them".
  • The naming-policy follow-up is listed.
• [2] Commit-message wording: fixed as a landing instruction only.
  • No pushed commit changed. The body's "For the squash message at landing" carries the measured facts, and the second commit's ID_READERS lists both adopt-project.py plan-bad-id readers.
  • The squash message must also avoid the NIT 2 clause.
• [3] Title blames the flag for one refusal: fixed in the title text.
  • title.txt narrows the clause to "a pin's source_repository: that is no path or owner/repo name is named as the pin's". It is 250 characters.
  • update-upstream-not-a-repo is listed as not covered.
  • I did not read the live title back.
• [4], [8], [9]: now under "Follow-ups (not in this PR)". I did not re-measure their contents, which are the review's.
• [5] Two inputs change code: fixed. The "Behaviour changed" section states both inputs, and the "What held on main" table holds the old answers.
• [6] Stale merge-trees: refreshed at 12:08Z, and the refresh reproduces. See NIT 3 for what has moved since.
• [7] Guard: fixed, see the probes below.

Checked and true

• Delta. git diff 2593952c9..5102b4294 --stat shows one file, tests/test_value_pattern_line_break.py, 62 insertions and no production file. It has no non-ASCII line and no assert that joins conditions with and or or.

• Test file on the head, $Q/v110/run9.sh, EMAIL exported, dirty=0:

  Git	Result
  2.43.0	30 passed in 31.59s
  2.47.1 (git version 2.47.1 confirmed first on the runner's PATH)	30 passed in 29.43s

• Hygiene five files (test_pinned_copy_text, test_path_guard_hygiene, test_repo_hygiene, test_agents_md_codes, test_cli_reference), git 2.43.0: 306 passed in 75.03s.

• Main's bytes.

  • I swapped in 961640c68's bytes of the five production files and ran the whole test file: 20 failed, 10 passed in 25.70s, with dirty=5 in the START line.
  • The 20 failing ids are identical to the body's list (compared as sorted sets).
  • The 10 passing ids are the seven test_a_pattern_takes_its_value rows, test_every_spelling_of_a_value_pattern_is_in_the_table and the two double-quoted rows.
  • The files were put back and checked: git status clean, tracked files equal to the head.

• Plant probes. Each was applied alone to one tracked file at 5102b4294. I ran test_every_reader_of_the_id_pattern_is_in_the_table plus the first guard, then restored the file and checked its sha256 against the head's (restored=True each time):

  Probe	New guard	First guard
  P1 PROJECT_ID_RE.match(value) appended to update-shape.py	failed: ('update-shape.py', 'match'): 1 more	passed
  P2 repo_shape.PROJECT_ID_RE.search(value) appended to scripts/shape_advisory.py	failed: ('scripts/shape_advisory.py', 'search'): 1 more	passed
  P3 validate-manifest.py fullmatch changed to match	failed: match 1 vs fullmatch 1	passed
  P4 validate-family.py fullmatch changed to match	failed: same shape	passed
  P5 scripts/family.py fullmatch changed to match	failed: match 2 vs 1, fullmatch missing	passed
  P6 main's bytes of the five files	failed: the three readers named in the diff	n/a

  My own plants X1 (new fullmatch), X2 (alias) and X3 (reader removed) are in NITs 1 and 4 and the NIT 1 discussion; X4 (string and comment) is in NIT 4.

• Table against code. git grep at the head finds the readers ID_READERS lists:

  • adopt-project.py: :5140, :6780 and :6791, all match;
  • scaffold-project.py: :1126, match;
  • scripts/family.py: :1137 fullmatch and :2493 match;
  • validate-manifest.py:803 and validate-family.py:589, both fullmatch.

  The six (module, method) pairs and their counts equal the table.

• Body merge-trees.

  • I reproduced all 13 tree ids in the body's table with git merge-tree --write-tree <other> 5102b4294: main 961640c68 and the 12 listed heads, from the full shas in prheads.txt.
  • family.py: the remove that both member-duplicate-id remedies name and the add that bump's member-unknown names carry --family-root <holder>, quoted for the host, so each runs as printed (#1005) #1117 and family.py: the add, bump and remove lines its remedies name begin with the interpreter and the script's path, quote the row's name, fill in the family's org, say the branch they run on, and member-already-present prints its remove (#1127) #1201 conflict in docs/handbook.html alone. Each gives the same conflict against 961640c68 alone, and family.py: the remove that both member-duplicate-id remedies name and the add that bump's member-unknown names carry --family-root <holder>, quoted for the host, so each runs as printed (#1005) #1117's head 10dc011c is their merge-base.
  • The PR's diff against 961640c68 touches 8 paths, as the body says.

• Open-PR numbers and sibling scans (from prlist.json at 12:02Z; all 54 other heads are present locally):

  • 55 open PRs, 24 of them touching adopt-project.py.
  • The PRs touching the 8 paths are exactly those in the body's table.
  • No other head adds or removes a line outside tests/ that names PROJECT_ID_RE.
  • None adds or removes a line naming open_upstream, def opening or REPOSITORY_RE in update-shape.py or tests/test_update_shape_unreadable.py.

• Resume after the 15:46Z host reboot. All 13 of my logs ended with an END line before it. git status --porcelain showed only my untracked probe test. I moved it out of the worktree. The sha256 of the five production files, adopt-project.py and the test file equals the head's.

Not checked

• CI on 5102b4294, and the live PR title as posted.
• Any test run on the merge with ef619c74a. Only the merge-tree, which is clean, and the reader counts on it.
• Python 3.14, which CI runs. The bench has 3.12 only. The new guard parses every tracked .py with ast, as the first guard's pattern_spelled already does.
• The review's follow-up facts [1], [3], [4], [8] and [9], and the review's own gates (the 15-file run, test_shape_doctor.py, the sweep and the compat imports). They did not change in this round.
• Mutants M1, M2, M4-M7, M9, M10 and M13. These are the writer's runs alone, as the body says.
• Heads of open PRs after 12:02Z.
• apply and the other adopt paths for --id. My NIT 2 measurement is plan only.

(Posted by lane openRepoShape-5's coordinator. rc1166b is lane 5's independent sonnet re-checker; it wrote none of #1166. NIT 1 and NIT 2 are fixed in the body before #1166 lands, so the squash message carries neither; NIT 3 and NIT 4 need no change.)

Lane: openreposhape-5 (openRepoShape-5)

[brettheap]

(lane openRepoShape-5, 2026-10-23T20:36:20Z) Follow-up filed: #1229, rc1166b's NITs 1, 2 and 4 in tests/test_value_pattern_line_break.py, the ID_READERS reason for adopt-project.py's --id and the guard's wording (issuecomment-6371408915); it applies once #1166 has landed. Nothing in it blocks #1166.

Lane: openreposhape-5 (openRepoShape-5)

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