[brettheap]

Lane: openreposhape-2 (openRepoShape-2)
Claim: #293 (comment)
Claim: #294 (comment)

The date guard no longer reorders refusals

5982bbe, on top of the merge below. The guard this PR added to _manifest_values (a2ec12e, "Merged main after #314 landed") returned before the function's checked_value("org", ...) and before _template_table read plan.project_id. check meets a bad organisation there and nowhere else, and a bad id there first (it reads the id again later, for the topic line it prints). So a bad elected_on: beside either one changed which problem each command named first (rv356m's P3):

hand-edited plan	main 580d7df	88c430c (as 10323a7)	5982bbe
elected_on: someday, org: "-evil"	check and execute: REFUSED unsafe-value	check: exit 1, only the date FINDING; execute: REFUSED unsafe-value	check and execute: REFUSED unsafe-value
elected_on: someday, id: "North Wind"	check and execute: REFUSED plan-bad-id	check: REFUSED plan-bad-id; execute: REFUSED election-date-malformed	check and execute: REFUSED plan-bad-id
elected_on: someday alone	FINDING plan-manifest-invalid	FINDING election-date-malformed	FINDING election-date-malformed

No leg is created in any of them. The fix refuses the organisation and reads the id before the guard, so the guard sits after them, and not "right after its _check_names refusal" as the #314 section below says. The guard still keeps a date-only plan to one finding in the plan key's words, with no plan-manifest-invalid beside it. The one cost left is the one "Composes with" names: the validator's other findings (for example visibility: secret) wait until the date is corrected. The docstrings of _manifest_values and _manifest_findings now say they return nothing for such a date (rv356m's nit 2).

test_a_bad_date_does_not_change_what_check_and_execute_refuse_first pins both plans, with reference: kept and removed: check exits 2 on the code execute refuses with, and no leg is created. On 88c430c's code all 4 fail; at 5982bbe all 4 pass. The coordinator's repro driver, run on 5982bbe, matches main 580d7df for both plans. tests/test_adopt_execute_refusals.py now has 91 tests, 54 of them this PR's. flake8 7.4.0 reports the same findings by message at 5982bbe as at main 580d7df.

Merged main after #445 landed

88c430c merges main 580d7df. Since dd8d0ea main gained #267, #403, #446, #445, #406 and #416. Only #445 (75052cb) touches adopt-project.py, and none of them touches this PR's two test files. The merge conflicted in one hunk, in _commit_the_split.

• The hunk: both kept. adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445 wraps _commit_the_split's body in a try that names each step (cloning the source for the split, mounting the legs, committing the split, pushing the split branch). A failure once both legs are pushed then flushes stdout and prints REFUSED <step>., what failed and one notice of what the run left. This PR reads follow_ups: there through _plan_follow_ups. The merge keeps adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445's try, steps and reports whole, and puts follow_ups = _plan_follow_ups(plan) in its committing the split step. Git had kept main's raw [str(f) for f in plan.get("follow_ups", [])] inside the try: a second read of the key, beside the one this PR makes.

• The two contracts do not overlap. This PR's findings are refused through _refuse_what_check_finds. That runs before adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445's _refuse_an_occupied_work_dir and _refuse_a_split_branch_left_behind, and before _create_leg_remotes. So plan-bad-follow-ups and election-date-malformed are refusals before any leg exists:

  • exit 2 and REFUSED <code>:;
  • the remediation "no leg repository was created and nothing was pushed", the words adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445 gives its own refusals before the legs;
  • no notice.

  adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445's report covers failures once a leg exists, and these values no longer reach that point. The merge leaves the guard in _manifest_values as it was; adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445 does not touch it.

• One comment. adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445's comment over _template_values in cmd_execute named "an elected_on that is not a date" as a refusal the table can raise. _refuse_what_check_finds now refuses such a date first (adopt-project.py: check never reads a plan's elected_on: when the plan has no reference:, so plan ok is followed by an execute that creates both leg repositories and only then refuses election-date-malformed, naming --elected-on, a flag neither command takes #294), so the comment says the date no longer reaches the table. adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445's own test of a table refusal stubs _template_values, and is unchanged.

• Two assertions. In tests/test_adopt_execute_refusals.py, the two end-to-end runs through main (adopt-project.py: check and execute iterate a plan's follow_ups: without asking for a list, so a hand-edited plan with follow_ups: 5 (or true) ends check in a TypeError: ... is not iterable traceback, and execute in the same one after both leg repositories are created and pushed #293, adopt-project.py: check never reads a plan's elected_on: when the plan has no reference:, so plan ok is followed by an execute that creates both leg repositories and only then refuses election-date-malformed, naming --elected-on, a flag neither command takes #294) now also call assert_refused_before_any_leg. It checks that the refusal says no leg was created, and that adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445's notice (NOTHING has been rolled back) does not follow it. Each run's corrected plan then adopts from the same --work-dir, which adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445's adopt-work-dir-occupied lets through, because the refused run built nothing there.

At 88c430c, against main 580d7df, this PR changed adopt-project.py, tests/test_adopt_execute_refusals.py and tests/test_adopt_manifest_values.py (3 files, 624 insertions, 28 deletions). git merge-tree --write-tree 580d7df 88c430c is rc 0. flake8 7.4.0 reports the same findings by message at 580d7df and at 88c430c: 34 in adopt-project.py, 2 in tests/test_adopt_execute_refusals.py, 6 in tests/test_adopt_manifest_values.py.

Targeted runs, with git filter-repo 2.47.0 and Python 3.12.3, as two background runs at each head. Together they cover all 25 tests/test_adopt_*.py files and the six other files below:

run	at 88c430c (the merge)	at 5982bbe (the head)
A: test_adopt_execute_refusals.py, test_adopt_manifest_values.py, test_scaffold_manifest_values.py, test_reference_default.py, #445's new test_adopt_late_failure.py and test_adopt_filter_repo_failure.py, test_shape_doctor.py, test_scaffold_leg_path_collisions.py	782 passed, 3 skipped	786 passed, 3 skipped
B: the other 21 tests/test_adopt_*.py, test_cli_reference.py, test_repo_hygiene.py	1611 passed, 1 skipped	1611 passed, 1 skipped
scripts/render-cli-reference.py --check	[ok] docs/cli.md is what the generator produces	[ok], the same
the new test on 88c430c's code		4 failed

At 88c430c that is 2397 tests collected: 2393 passed, 4 skipped, 0 failed. At 5982bbe it is 2401: 2397 passed, 4 skipped, 0 failed. The 4 skips are the same at both heads: test_shape_doctor.py:6587 three times (the PowerShell line, printed only on a Windows host) and test_adopt_plan.py:393 (no SHAPE_MEDXEHR_CLONE clone of MedxEHR).

Against main 580d7df this PR now changes adopt-project.py, tests/test_adopt_execute_refusals.py and tests/test_adopt_manifest_values.py (3 files, 680 insertions, 32 deletions at 5982bbe). Main has since moved to d6df36b, adding #404 (shape-doctor.py, scripts/shape_advisory.py) and #346 (update-shape.py). Neither touches this PR's files. git merge-tree --write-tree d6df36b 5982bbe is rc 0, and that tree differs from d6df36b by the same three files and numbers.

git merge-tree --write-tree 5982bbe <head>, on the local refs with no fetch, is rc 0 with:

• adopt-project.py: plan --help says what --spec-path and --code-path are, the default and key each records, and the two refusals plan makes on them, so docs/cli.md no longer lists the two flags that choose where a leg is mounted as bare lines (#340) #401 da27e69, scaffold-project.py and family.py: --tracking-branch is asked of git check-ref-format --branch before anything exists, so ~, a..b, x.lock and a/ are refused under --dry-run and no longer die at the first git init -b after gh repo create has made the repositories (#283) #355 32e4861, scaffold-project.py: a leg path the project's own YAML reader would read back as another type (null, ~, true, False, 2026, 1.5) is refused before anything is created, under --dry-run alike, through the one definition adopt-project.py asks, so --spec-path 2026 no longer creates three repositories whose first bootstrap fails manifest-leg-path, and adopt-project.py execute no longer says adoption verified before that bootstrap fails (#225) #266 3410be7;
• update-shape.py read_pin refuses update-pin-row, and the pinned validate-pins.py and validate-family.py report shape-pin-row, when a shape pin's files: is not a list, so files: 5, true or 1.5 no longer ends check, apply, shape-doctor.py and the project's own validator in TypeError: ... is not iterable (#290) #343 e68a01d, validate-pins.py (assembly-root template): a workflow file under .github/workflows/ that is not UTF-8, or that this user cannot open, is ONE workflow-unreadable refusal naming every such file, exit 2, so the project's pins gate no longer ends in a UnicodeDecodeError traceback, exit 1, with no line naming the file (#359) #419 11dff7f, update-shape.py: a pinned copy, contracts/shape-pin.yaml or the manifest kept as a symlink, or under one, is refused as update-rewrite-symlink before anything is written, and check calls such a copy copy-is-link, so apply no longer writes the standard's bytes at the link's end and reports a commit that does not hold them (#286) #347 9423361;
• adopt-project.py: check names, and execute refuses before the work directory is made, a plan whose source: or legs: is not a mapping or whose allow_empty_legs: or paths: is not a list of what plan writes, and asks the same first of a pins: that is not a list, so a number or a boolean in any of the four no longer ends both in a traceback and allow_empty_legs: code is no longer read as four legs (#386) #435 3efcc7a, which is stacked on this PR.

It is rc 1 with #358 ce2ce75, in shape-doctor.py only. This PR does not touch that file, and main conflicts with #358 there too.

Merged main after #314 landed

#314 landed on main as 3ef059c, and a2ec12e merges it, as "Composes with" below planned. At 3ef059c, adopt-project.py and #314's four test files are exactly a5438a5's merged with 92e29d9, so the plan read from a5438a5 held unchanged.

• The two hunks in _entry_findings: both kept. The return is findings + split + unwritable_findings + value_findings + moved + field_findings, then the remediations in the same order, then notes. The docstring lists 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's validator findings, then adopt-project.py keeps a source submodule's relative url = ../x unchanged in the leg, where git resolves it against the leg's remote, so execute says adoption verified and the assembly's recursive clone fails unless the dependency happens to sit beside the leg #190's relative urls, and last this PR's plan values. Main's own paragraph below it said the adopt-project.py keeps a source submodule's relative url = ../x unchanged in the leg, where git resolves it against the leg's remote, so execute says adoption verified and the assembly's recursive clone fails unless the dependency happens to sit beside the leg #190 urls come "last"; it now says the plan values come after them.
• The guard: _manifest_values returns None when _elected_on_findings(plan) has a finding, right after its _check_names refusal, with the comment given below. In plan it does nothing, because _checked_plan_inputs asks election_date of --elected-on before _refuse_unholdable_values builds its plan.
• scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's 5 rows in tests/test_adopt_manifest_values.py are retargeted to election-date-malformed, and none is dropped. This PR's own tests ask 2026-W41-6 and 20261011 only with no reference: (in its check rows, and in execute through a stand-in). These rows keep reference: and ask through execute, from a tree with no git, and of _manifest_findings alone. A helper, said_of(new), gives each row's finding, REFUSED prefix and remediation; every other row expects what it did.
  • elected-on-iso-week in test_check_finds_a_value_the_validator_refuses, test_execute_refuses_it_before_any_leg_exists and test_check_finds_it_from_a_tree_with_no_git_as_in_a_checkout;
  • elected-on-basic-format in test_execute_refuses_a_text_value_the_reader_misreads_before_any_leg and test_a_text_value_the_reader_misreads_is_one_finding_on_this_rule_alone. In the second, _manifest_findings is now ([], []) and _plan_field_findings holds the one finding.

Against main 3ef059c, this PR now changes adopt-project.py, tests/test_adopt_execute_refusals.py and tests/test_adopt_manifest_values.py (3 files, 601 insertions, 24 deletions). flake8 7.4.0 reports the same findings by message in adopt-project.py (37) and tests/test_adopt_manifest_values.py (6) at 3ef059c and at a2ec12e.

Targeted runs at a2ec12e, with git filter-repo 2.47.0 and Python 3.12.3: 2304 tests collected, 2300 passed, 4 skipped, 0 failed.

run	result
test_adopt_execute_refusals.py 87, test_adopt_manifest_values.py 79, test_scaffold_manifest_values.py 106, test_reference_default.py 18	290 passed
the other 20 tests/test_adopt_*.py (1532 tests)	1531 passed, 1 skipped
test_shape_doctor.py 268, test_scaffold_leg_path_collisions.py 104	369 passed, 3 skipped
test_cli_reference.py 13, test_repo_hygiene.py 50, test_agents_md_codes.py 47 (new on main, #396)	110 passed
scripts/render-cli-reference.py --check	[ok] docs/cli.md is what the generator produces
the first four files on a2ec12e without the guard (scratch tree)	26 failed, 264 passed
this PR's test file on main 3ef059c's code	42 failed, 45 passed

Without the guard, these fail:

• the 22 rows of this PR and the 1 row of scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314 that "Composes with" names;
• 3 of the 5 retargeted rows: execute for elected-on-iso-week and elected-on-basic-format (REFUSED plan-manifest-invalid: 2 finding(s)), and the rule-alone row, where _manifest_findings still holds the validator's finding.

With no reference:, check exits 2 on REFUSED election-date-malformed: --elected-on '' is not a YYYY-MM-DD date. With reference: kept, the date is two findings.

On main 3ef059c, all 37 tests of main's own file pass, and 42 of the 50 new ones fail: v3's 40, plus the same-question rows 2026-W41-6 and 20261011. #314's election_date now refuses both, but check does not list them as findings; it stops at exit 2. #314 already refuses a bad date before any leg, but not as this PR's finding:

• with no reference:, check exits 2 on REFUSED election-date-malformed: --elected-on 'someday' ..., naming a flag the plan does not hold, and elected_on: false is refused as --elected-on 'False';
• with reference: kept, the date is the validator's plan-manifest-invalid.

follow_ups: 5 is still a TypeError traceback there.

Fix round (review of 5a5011d)

Review of 5a5011d said MERGEABLE WITH NITS. Three commits answer it, and this description is N3:

• F2, main moved (0aff5ae). git merge origin/main (a983e6a: adopt-project.py: a relative .gitmodules url the plan keeps in a leg is resolved from the source's remote and from the leg's, and where the two differ check finds it and execute refuses before any leg exists, so a recursive clone no longer fails after adoption verified (#190) #245 landed as 161c6c9, then adopt-project.py, AGENTS.md: execute verifies before it exits on a refused gh pr create, and step 7 keys its way out to the exit it prints, so an IS pushed exit 2 is finished by hand, not re-run into a second pair of legs (#304) #371) conflicted in adopt-project.py only, 2 hunks in _entry_findings:
  • the docstring takes main's text and ends with this PR's clause (... and last each plan value executereads late and_plan_field_findings asks about (#293, #294));
  • the return is main's three-tuple with field_findings last: findings + split + unwritable_findings + moved + field_findings, the remediations in the same order, and notes.
  • cmd_check and _refuse_what_check_finds already unpack three values on main, and this PR's tests call _refuse_what_check_finds(plan, source) with its defaults, so no test changed. Tested at 0aff5ae before anything else was added: the four files that cover the merge (test_adopt_execute_refusals.py, test_adopt_relative_submodule_url.py, test_adopt_submodules.py, test_adopt_gitmodules_values.py) 433 passed.
• F1, elected_on: "" was unpinned (f8e6de1, tests only). _elected_on_findings skips only elected_on is None, so "" reaches election_date and is refused, but no test said so: changing is None to not elected_on passed all 81 tests, and check then said plan ok while execute created both legs before it refused. The commit adds an empty-text row to BAD_DATES, which feeds both the check test and the execute test, and a check test for false, 0, [] and {}, which are not text, so BAD_DATES cannot hold them. At 0aff5ae they pass (6 passed: no code changed). With if not elected_on: in place of is None, all 6 fail.
• N1 and N2, wording (dbfad70).
  • N1: the docstring of _plan_field_findings said the findings come "in the order the plan file holds the two keys". The order is fixed, date then follow-ups, and it is the order plan writes the keys. It now says so, and so does the both-findings test's docstring.
  • N2: the finding called the date "the one form execute reads". That does not hold on Python 3.11 and later until scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314 lands (20261011 and 2026-W41-6 pass election_date, and execute writes them). It now says "the form execute writes into the project's project.yaml". The check test pins the new words and that the old ones are gone: against the reviewed adopt-project.py its six rows fail, and they pass at this head.
• N3, this description: main is now 92e29d9, adopt-project.py: a relative .gitmodules url the plan keeps in a leg is resolved from the source's remote and from the leg's, and where the two differ check finds it and execute refuses before any leg exists, so a recursive clone no longer fails after adoption verified (#190) #245 has landed (its row is gone), scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314 is at a5438a5, adopt-project.py: _elector keeps a user.name byte that is not UTF-8 for #255's question, _remote_repository reads such an origin URL as no org/repo, and plan asks adopt-no-org before checked_value, so a Latin-1 name is refused as adopt-unwritable-value naming --elected-by, and plan, check and execute go on past such an origin, where both ended in a UnicodeDecodeError traceback (#292) #353 is at 96ff0c7 and shape-doctor.py: a root's own contracts/shape-pin.yaml that does not read as a pin (a merge conflict, a non-UTF-8 byte, a commit: that is not 40 hex, a deleted file) is INVALID, exit 1, with the git command that puts back the last pin a tool wrote as its NEXT, instead of CANNOT ANSWER, exit 3, sending the reader to git fetch --all in the standard (#237) #267 at 8badae0. The composed return order with scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314 is read from a5438a5's own code (below).

Not in this PR: the review's two follow-ups (a branch name the plan holds that git refuses, and the other plan keys that end check in a traceback).

Merged main after #270 landed

#270 (fix/adopt-template-values-utf8) landed on main as the squash f795cf7, and this PR, stacked on it, is now based on main. Three merges brought it up to date. The first two changed no code and added no test:

• ead7716 merges adopt-project.py: a value execute writes into a file is asked whether a file can hold it, in plan, in check and in execute before any leg exists, so a byte that is not UTF-8 in --elected-by, --reference or a local --source directory no longer pushes both legs before write_lf raises (#255) #270's final head 3cee853 (it had merged main e43fa95). No conflict. It comes first because this branch carried an older copy of adopt-project.py: a value execute writes into a file is asked whether a file can hold it, in plan, in check and in execute before any leg exists, so a byte that is not UTF-8 in --elected-by, --reference or a local --source directory no longer pushes both legs before write_lf raises (#255) #270's commits, so a plain merge of main conflicts in adopt-project.py.
• 5a5011d merges origin/main (ab623dd). adopt-project.py was the only file that conflicted, and it takes this branch's version of the whole file. That is right because the squash's content of adopt-project.py and tests/test_adopt_template_values.py is 3cee853's (git diff 3cee853 f795cf7 over them is empty), which ead7716 had already brought in, and no other main commit since 3cee853 touches them or scripts/shape_materialize.py.
• 0aff5ae merges origin/main (a983e6a), which holds adopt-project.py: a relative .gitmodules url the plan keeps in a leg is resolved from the source's remote and from the leg's, and where the two differ check finds it and execute refuses before any leg exists, so a recursive clone no longer fails after adoption verified (#190) #245 (161c6c9) and adopt-project.py, AGENTS.md: execute verifies before it exits on a refused gh pr create, and step 7 keys its way out to the exit it prints, so an IS pushed exit 2 is finished by hand, not re-run into a second pair of legs (#304) #371. It does change code: adopt-project.py was the only file that conflicted, in 2 hunks of _entry_findings, resolved as the Fix round section says.

After the first two (at 5a5011d): git diff HEAD^1 HEAD over adopt-project.py and tests/test_adopt_template_values.py was empty, and git diff --stat origin/main HEAD listed only adopt-project.py and tests/test_adopt_execute_refusals.py.

At the head: git diff --stat a983e6a dbfad70 lists only adopt-project.py and tests/test_adopt_execute_refusals.py (2 files, 553 insertions, 12 deletions), and git merge-tree --write-tree dbfad70 92e29d9 (main today) is rc 0. git diff --stat 92e29d9 against that merge's tree lists the same two files with the same numbers.

What

check now asks about two plan values that execute used to read only after check had said plan ok. execute refuses what check finds through _refuse_what_check_finds, before _create_leg_remotes, so no leg is created. There is one commit per issue.

• adopt-project.py: check and execute iterate a plan's follow_ups: without asking for a list, so a hand-edited plan with follow_ups: 5 (or true) ends check in a TypeError: ... is not iterable traceback, and execute in the same one after both leg repositories are created and pushed #293, follow_ups: (2533515).
  • _plan_follow_ups is now the one read for the three readers: _plan_values, _print_what_will_happen and _commit_the_split. It returns the text items of a follow_ups: list, and nothing for any other value.
  • _follow_ups_findings reports plan-bad-follow-ups for a follow_ups: that is present and is not a list, and names what it holds: the number 5, the boolean true, the text 'abc', a mapping of 1 key(s). It reports one finding for each list item that is not text: item 2 of `follow_ups:` is the boolean true, not text.
  • An empty list and a bare key are still valid.
  • The remediation says how plan writes the list.
• adopt-project.py: check never reads a plan's elected_on: when the plan has no reference:, so plan ok is followed by an execute that creates both leg repositories and only then refuses election-date-malformed, naming --elected-on, a flag neither command takes #294, elected_on: (84f3806).
  • _elected_on_findings asks election_date whether or not the plan has a reference:. It asks about str of what the plan holds, which is the value _template_values takes.
  • A date election_date refuses is a FINDING election-date-malformed: the plan's `elected_on:` is the text 'someday', which is not a day written YYYY-MM-DD, the form `execute` writes into the project's `project.yaml`, and, the plan naming no `reference:`, chooses the reference by it.
  • Only an elected_on: that is absent or null is "no date", which execute fills with today's. An empty text, false, 0, [] and {} are dates election_date cannot read, and are findings like any other.
  • The remediation says to edit elected_on: in the plan file. Nothing check or execute prints names --elected-on any more, because neither command takes it.
  • Only that refusal is a finding about the date. Anything else election_date raises is raised as it is, so a date it never judged is not reported as malformed. An example is scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's manifest-validator-unusable, raised when the validator it consults is missing.
• Both findings come last in _entry_findings, through _plan_field_findings, with the date first, in the order plan writes the two keys (elected_on: before follow_ups:). The new code is one section above UNSAFE_PATH_REMEDIATION, placed away from _entry_findings, which adopt-project.py: a relative .gitmodules url the plan keeps in a leg is resolved from the source's remote and from the leg's, and where the two differ check finds it and execute refuses before any leg exists, so a recursive clone no longer fails after adoption verified (#190) #245 changed and scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314 also edits (see Composes with).

a hand-edited plan	check before	check now	execute before (main 92e29d9)	execute now
follow_ups: 5 / true / false / 1.5	exit 1, TypeError: ... is not iterable	exit 1, FINDING plan-bad-follow-ups	exit 1, the same TypeError, raised from _plan_values inside _refuse_what_check_finds, so before any leg (until #270 landed it was raised in _commit_the_split, after both legs were pushed)	exit 2, REFUSED plan-bad-follow-ups, no leg
follow_ups: abc / {a: 1}, an item - true / - null / - 5	exit 0, follow-up: a, b, c	exit 1, a finding	exit 0; the split message held - a, - b, - c / - True / - None	exit 2, no leg
follow_ups: [], a bare key, quoted items	exit 0	exit 0	exit 0	exit 0
no reference:, elected_on: someday / notadate / "2026-9-2" / "2026-02-30" / ""	exit 0, plan ok	exit 1, FINDING election-date-malformed	exit 2, REFUSED election-date-malformed: --elected-on 'someday' ..., both leg repositories created, empty	exit 2, the finding as refusal, no leg
reference: kept, elected_on: someday	exit 0	exit 1, the finding	exit 0, adoption verified, elected_on: someday in the manifest	exit 2, no leg
elected_on: "2026-09-02" / "2026-06-01" / null, with or without reference:	exit 0	exit 0	exit 0	exit 0; with no reference: the manifest records the reference the date chooses

Why

The plan is untrusted input (cmd_execute's own comment). check is the command that says whether a plan is sound. It printed a traceback for one of these values and plan ok for the other, and execute used them after it had made the legs.

The date question is election_date's, unchanged. It is the rule plan asks of --elected-on and _template_values asks of the plan's date. On Python 3.11 and later it reads 2026-W41-6 and 20261011, and the project's own validate-manifest.py refuses both. That is #261's to rule on, and lane 5's #314 holds election_date to the validator's DATE_RE.

So this PR asks the same function and copies no rule:

• plan, check and execute cannot disagree about one value. A stricter check alone would refuse a plan that plan had just written from --elected-on 2026-W41-6.
• Once scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314 lands, its rule is asked here with no edit.

Only the words are this PR's. election_date's refusal names --elected-on, which is right for plan and wrong for a plan file. tests/test_reference_default.py still holds election_date's own wording.

Tests

tests/test_adopt_execute_refusals.py has 50 new tests: 22 for #293 and 28 for #294. It goes from 37 to 87 tests. They sit beside test_execute_refuses_each_class_and_creates_no_leg and use its helpers (write_edited, run_check, no_leg_was_created, refused_by).

• adopt-project.py: check and execute iterate a plan's follow_ups: without asking for a list, so a hand-edited plan with follow_ups: 5 (or true) ends check in a TypeError: ... is not iterable traceback, and execute in the same one after both leg repositories are created and pushed #293:
  • check for nine edits: one FINDING, exit 1, no traceback, and no follow-up: line except for text items.
  • execute in-process for the same nine: the refusal, no leg, no split branch.
  • Three controls.
  • One end-to-end run through main with git filter-repo: exit 2, no leg directory, then adoption verified from the corrected plan.
• adopt-project.py: check never reads a plan's elected_on: when the plan has no reference:, so plan ok is followed by an execute that creates both leg repositories and only then refuses election-date-malformed, naming --elected-on, a flag neither command takes #294:
  • check and execute for six dates: five with no reference: (someday, notadate, "2026-9-2", "2026-02-30" and the empty text "") and one with it kept. The finding names elected_on: and the form execute writes, and no output names --elected-on.
  • check for elected_on: false, 0, [] and {}: only an absent or null elected_on: is "no date".
  • Four controls.
  • check's verdict equals election_date's on the running interpreter, for 2026-W41-6, 20261011, 2026-09-02 and someday.
  • A stricter election_date, stood in by monkeypatch, refuses 2026-W41-6 before any leg.
  • Any other refusal from election_date is raised as it is, and is not a date finding.
  • Both findings in one plan: one list, the code is the first finding's, and each remediation appears once.
  • One end-to-end run: exit 2 and no leg, then the corrected plan with no reference: adopts and records the reference its date chooses.

Against main's code (92e29d9, this PR's test file copied in): the file gives 40 failed and 47 passed. The 37 existing tests pass, and 40 of the 50 new ones fail, each for the issue's reason:

• TypeError: 'int' object is not iterable;
• check exit 0, plan ok, where a FINDING belongs;
• DID NOT RAISE Refusal, because execute carried on and wrote - a/True/someday;
• the leg directory exists, as for elected_on: "";
• the refusal names --elected-on;
• another refusal from election_date is not raised.

The 10 that pass there are the 7 controls and the 3 same-question rows, where election_date answers "a date" on that interpreter.

Targeted runs at the head dbfad70, with git filter-repo 2.47.0 on PATH and Python 3.12.3:

run	result
A1: test_adopt_execute_refusals.py, test_adopt_relative_submodule_url.py, test_adopt_submodules.py, test_adopt_gitmodules_values.py	439 passed
A2: the other 17 tests/test_adopt_*.py files	1155 passed, 1 skipped
B1: test_shape_doctor.py (the doctor feeds adopt plans) and test_scaffold_leg_path_collisions.py	359 passed, 3 skipped
B2: test_reference_default.py, test_stdout_encoding.py, test_load_yaml_refusals.py, test_git_output_decoding.py, test_free_plan_hint.py, test_windows_paths.py, test_cli_reference.py, test_repo_hygiene.py	258 passed, 1 skipped
scripts/render-cli-reference.py --check	[ok] docs/cli.md is what the generator produces (no --help text changed)
the four merge files at the merge head 0aff5ae, before the fix round	433 passed
test_adopt_execute_refusals.py at the #293 commit alone	59 passed (2533515's code)
test_adopt_execute_refusals.py on main's code, no merge	92e29d9: 40 failed, 47 passed

That is 2216 tests collected across the 31 files and 2211 passed, 5 skipped, 0 failed. Per file (collected at dbfad70):

• test_adopt_execute_refusals.py 87 (37 before); test_adopt_clone_template.py 31, test_adopt_e2e.py 19, test_adopt_entry_paths.py 64, test_adopt_finding_spelling.py 128, test_adopt_github_exits.py 11, test_adopt_gitmodules_values.py 187, test_adopt_history_gitlinks.py 45, test_adopt_ignored_shape_files.py 30, test_adopt_leg_path_collisions.py 95, test_adopt_leg_paths.py 349, test_adopt_literal_names.py 14, test_adopt_mount_ignored.py 26, test_adopt_plan.py 57, test_adopt_plan_escapes.py 59, test_adopt_relative_submodule_url.py 32, test_adopt_root_shape_paths.py 120, test_adopt_spec_only.py 14, test_adopt_submodules.py 133, test_adopt_template_values.py 78, test_adopt_verify.py 16;
• test_reference_default.py 18, test_stdout_encoding.py 48, test_load_yaml_refusals.py 11, test_git_output_decoding.py 67, test_free_plan_hint.py 14, test_windows_paths.py 38;
• test_shape_doctor.py 258, test_scaffold_leg_path_collisions.py 104, test_cli_reference.py 13, test_repo_hygiene.py 50.

Nothing ran on Windows or macOS before this PR's CI. The new tests write plans through the file's own helpers, pass no text to git on stdin, and use no symlink, so nothing here is specific to an OS. flake8 (7.4.0, default settings) reports nothing new in either file: adopt-project.py gives 37 findings and tests/test_adopt_execute_refusals.py gives 2, at main 92e29d9 and at dbfad70 alike, the same ones by message (line numbers aside).

Mutants, each applied to adopt-project.py in a throwaway tree at dbfad70 and run against all 87 tests of the file:

mutant	result
the per-item findings of _follow_ups_findings removed	6 failed
the date skipped when it is falsy, not only when it is absent or null (if not elected_on:)	6 failed (it survived at 5a5011d: 81 passed, which was F1)
_plan_follow_ups keeps items that are not text (str(item))	3 failed
the date asked only when the plan has no reference:	3 failed
any refusal of election_date taken as a date finding	1 failed
a mapping at follow_ups: accepted	2 failed
_commit_the_split reads follow_ups raw, as main did	survives, 87 passed. It is equivalent, defence in depth: _refuse_what_check_finds refuses every bad follow_ups: first, so the split commit never reads one

The implementer's own seven mutants were run at 84f3806, each in a throwaway worktree, and were not re-run. They change _follow_ups_findings and _plan_follow_ups (unchanged since), _elected_on_findings (changed since only in the wording of its finding, N2) and the join in _entry_findings (re-spelled by the merge 0aff5ae):

mutant	tests run (-k)	result
_follow_ups_findings returns [] for a value that is not a list	the 19 follow-ups refusal tests	13 failed
_plan_follow_ups iterates whatever is there	the 9 check follow-ups tests	6 failed (TypeError, or follow-up: a)
the date asked only when the plan has no reference:	the 11 elected_on refusal tests	2 failed (word-reference-kept)
a copy of the rule (date.fromisoformat) instead of election_date	the tighter-rule and same-question tests	1 failed
election_date's own words passed on	the 5 check date tests	5 failed (--elected-on named)
any refusal of election_date taken as a date finding	the other-refusal test	1 failed
the field findings not joined to _entry_findings	the 14 execute refusal tests	14 failed

Composes with

git merge-tree --write-tree dbfad70 <head> for the heads at the shas named, with main 92e29d9 (which holds #245, #270 and #371):

head	rc	conflicts	resolves
origin/main 92e29d9	0		Merged here up to a983e6a (0aff5ae). Against main this PR changes adopt-project.py and tests/test_adopt_execute_refusals.py only.
#353 fix/adopt-git-reads-not-utf8 96ff0c7 (lane-mate)	0
#267 8badae0, #266 3410be7, #343 9e6caeb, #346 818db36, #347 e965ab0, #352 797c96b, #355 a03abcf, #401 6124cb4, #403 e2c78ee, #404 f9d420a	0
#386 fix/adopt-plan-field-types d53602b (stacked on this PR, built at 5a5011d)	0
#358 fix/doctor-manifest-kinds-unreadable-pin 2745890	1	shape-doctor.py, 4 hunks	The same 4 hunks as main 92e29d9 has against #358 (git merge-tree --write-tree 92e29d9 2745890). This PR does not touch that file.
#314 fix/scaffold-manifest-values a5438a5 (lane 5, #258/#261)	1	adopt-project.py, 2 hunks: _entry_findings' docstring and its return	The same 2 hunks as at 0aff5ae. Keep both, plus one guard (below). Landed as 3ef059c, and merged in a2ec12e (see "Merged main after #314 landed").

git merge-tree --write-tree 92e29d9 a5438a5 is rc 0, so #314 merges main cleanly and the conflict is only between #314 and this PR.

With #314: the two hunks. At a5438a5 _entry_findings returns findings + split + unwritable_findings + value_findings + moved, ... with the remediations in the same order and notes. With this PR it becomes:

    value_findings, value_remediation = _manifest_findings(plan)
    field_findings, field_remediation = _plan_field_findings(plan)
    return (findings + split + unwritable_findings + value_findings + moved
            + field_findings,
            unsafe_remediation + split_remediation + unwritable_remediation
            + value_remediation + moved_remediation + field_remediation, notes)

and the docstring lists the checks in that order: what the project's own validate-manifest.py would refuse (#261), then each relative url of a kept submodule (#190), and last each plan value execute reads late (#293, #294).

With #314: the guard, and why it is needed. Keeping both sides is not enough. I tested this on throwaway merges, never committed:

• With no reference:, scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's _manifest_values builds the table through _template_table and default_reference. That raises election_date's own refusal, so check exits 2 with REFUSED election-date-malformed: --elected-on 'someday' ... before this PR's finding is listed. That is scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's NIT-2, and adopt-project.py: check never reads a plan's elected_on: when the plan has no reference:, so plan ok is followed by an execute that creates both leg repositories and only then refuses election-date-malformed, naming --elected-on, a flag neither command takes #294's wording again.
• With reference: kept, the date is reported twice: scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's plan-manifest-invalid: elected_on is 'someday' ... and this PR's election-date-malformed.

The fix is one guard in _manifest_values, after its _check_names refusal, which also returns None. The anchor is unchanged at a5438a5:1770-1773:

    if _elected_on_findings(plan):
        # Reported in the plan key's own words (#294), and the reference the
        # manifest records is chosen BY that date when the plan names none:
        # there is no manifest to ask about until it is one.
        return None

With it, every row is one finding in this PR's words, exit 1, and execute refuses before any leg. That covers someday, notadate, "2026-9-2", "2026-02-30", "", "2026-W41-6" and "20261011", and reference: kept. 2026-W41-6 and 20261011 are refused because #314's election_date refuses them. The controls still adopt.

The cost: a plan whose date is unreadable gets the validator's other findings (for example visibility: secret) only once the date is corrected. That is how #314 already treats a plan whose names _check_names refuses.

Run at dbfad70 on throwaway merges with a5438a5, resolved as above, on tests/test_adopt_execute_refusals.py, tests/test_adopt_manifest_values.py, tests/test_scaffold_manifest_values.py and tests/test_reference_default.py (290 tests):

• With the guard: 285 passed, 5 failed. This PR's file passes in full. The 5 failures are scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's own rows for an elected_on: that is now judged once, by this PR's rule, ahead of the validator's question:
  • elected-on-iso-week in test_check_finds_a_value_the_validator_refuses, test_execute_refuses_it_before_any_leg_exists and test_check_finds_it_from_a_tree_with_no_git_as_in_a_checkout;
  • elected-on-basic-format in test_execute_refuses_a_text_value_the_reader_misreads_before_any_leg and test_a_text_value_the_reader_misreads_is_one_finding_on_this_rule_alone.
• Without the guard: 267 passed, 23 failed. 22 are this PR's tests: the twelve check and execute date rows, the four check rows for false, 0, [] and {}, the three same-question rows, the tighter-rule test, the both-findings test and the date end-to-end run. The 23rd is scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's elected-on-basic-format one-finding row.
• The 5 failing rows expect plan-manifest-invalid or REFUSED plan-manifest-, and get one finding election-date-malformed that names the same value. scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's own --elected-on rows already expect that code. The second lander retargets those rows to election-date-malformed, or drops them as covered by this PR's tests. That keeps one finding per value, which scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314's misreads_elsewhere already does for misreads.

Whoever lands second adds the guard. If #314 lands first, this PR merges main, resolves as above and adds the guard. If this PR lands first, #314 does. #314 landed first, and a2ec12e adds the guard.

Left out

• election_date's own form, 2026-W41-6 and 20261011 on Python 3.11+: 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, PR scaffold-project.py and adopt-project.py ask the project's YAML reader and validate-manifest.py about the manifest's values before anything exists, so --id null, --tracking-branch true and a blank --elected-by are refused (#258, #261) #314, now landed as 3ef059c. This PR asks through the same function, so check now finds both, with no edit here.
• The same unguarded iteration on other plan keys, outside the functions adopt-project.py: check and execute iterate a plan's follow_ups: without asking for a list, so a hand-edited plan with follow_ups: 5 (or true) ends check in a TypeError: ... is not iterable traceback, and execute in the same one after both leg repositories are created and pushed #293 names, is not touched here and should be its own issue. Checked at 5a5011d, and the lines are unchanged at this head:
  • pins: 5 ends check in TypeError: 'int' object is not iterable from Plan.__init__ (self.pins = [str(p) for p in (data.get("pins") or []) if p]).
  • allow_empty_legs: 5 ends the same way from Plan.allowed_empty_legs.
  • paths: is read the same way in Plan.__init__ (read from the code, not run).
• The late default_reference call in _template_values is unchanged. It cannot be reached with a date election_date refuses, because _refuse_what_check_finds refuses that plan first, asking the same function about the same value.

Closes #293
Closes #294

🤖 Generated with Claude Code

Summary by Sourcery

Validate late-read plan fields before adoption begins so malformed follow-ups and election dates produce clear findings and safe refusals without creating legs.

Bug Fixes:

• Validate malformed follow_ups: and elected_on: plan values during check and refuse them during execute before any leg repositories are created.
• Preserve the existing refusal precedence for invalid organisations and project IDs when malformed dates are also present.
• Prevent malformed follow-up values from causing tracebacks or being interpreted as character-by-character or non-text entries.

Enhancements:

• Centralize follow-up handling across plan summaries, value checks, and split commit messages.
• Use the shared election-date validation rule for plan-file dates while reporting findings in terms of elected_on: rather than the unrelated command-line flag.
• Ensure malformed plan-field findings and remediations are reported consistently and in plan key order.

Tests:

• Add comprehensive coverage for malformed and valid follow-ups and election dates, including falsy values, references, refusal precedence, combined findings, and end-to-end no-leg guarantees.

[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 10 hours and 52 minutes by commenting @sourcery-ai review. Upgrade to get a review now.

[sourcery-ai]

Reviewer's Guide

The PR moves validation of late-read plan fields into the shared preflight/refusal path: malformed follow_ups: and unreadable elected_on: values now produce targeted check findings and cause execute to stop before creating legs, while all readers share safe parsing and the existing date rule remains authoritative.

Sequence diagram for execute refusing malformed plan values

sequenceDiagram
    participant Plan as Plan file
    participant Execute as execute
    participant Findings as _entry_findings
    participant Fields as _plan_field_findings
    participant Date as election_date
    participant Refuse as _refuse_what_check_finds
    participant Legs as _create_leg_remotes

    Execute->>Plan: read plan
    Execute->>Findings: validate plan
    Findings->>Fields: _plan_field_findings(plan)
    Fields->>Date: election_date(str(elected_on))
    Date-->>Fields: date or election-date-malformed
    Fields-->>Findings: follow-up and date findings
    Findings-->>Execute: findings
    Execute->>Refuse: _refuse_what_check_finds(findings)
    alt finding exists
        Refuse-->>Execute: Refusal
        Execute-->>Plan: stop before leg creation
    else no findings
        Execute->>Legs: _create_leg_remotes
        Legs-->>Execute: legs created
    end

Loading

State diagram for execute plan acceptance

stateDiagram-v2
    [*] --> PlanLoaded
    PlanLoaded --> PreflightValidation
    PreflightValidation --> Refused : malformed follow_ups or elected_on
    Refused --> [*] : no leg created
    PreflightValidation --> PlanAccepted : no findings
    PlanAccepted --> LegsCreated
    LegsCreated --> [*]

Loading

Flow diagram for plan validation before leg creation

flowchart TD
    Plan["Hand-edited plan"] --> Check["check"]
    Check --> Findings["_entry_findings"]
    Findings --> Fields["_plan_field_findings"]
    Fields --> FollowUps["_follow_ups_findings"]
    Fields --> ElectedOn["_elected_on_findings"]
    FollowUps --> Verdict{"findings?"}
    ElectedOn --> Verdict
    Verdict -->|"no"| PlanOK["plan ok"]
    Verdict -->|"yes"| CheckFinding["FINDING with remediation"]
    PlanOK --> Execute["execute"]
    CheckFinding --> Execute
    Execute --> Refuse["_refuse_what_check_finds"]
    Refuse -->|"finding exists"| Refused["REFUSED; no leg created"]
    Refuse -->|"no finding"| Create["_create_leg_remotes"]

Loading

File-Level Changes

Change	Details	Files
Validate follow_ups: consistently before execution and centralize its safe reading.	Added findings for non-list values and non-text list items with value-specific diagnostics and remediation. Added a shared reader that only returns text list items for planning output, plan-value reporting, and split-commit messages. Integrated the new finding and remediation into the shared check/execute refusal pipeline.	adopt-project.py tests/test_adopt_execute_refusals.py
Validate plan-file elected_on: values using the existing election_date rule before any leg creation.	Added a plan-specific malformed-date finding that preserves the shared rule while translating flag-oriented wording to elected_on: wording. Applied the check to plans both with and without reference:, while propagating unrelated election_date refusals unchanged. Added date findings and remediation to the shared finding order and execute refusal path.	adopt-project.py tests/test_adopt_execute_refusals.py
Expand refusal coverage to prove invalid plans fail safely and valid controls remain compatible.	Added unit and end-to-end tests covering malformed follow-ups, malformed dates, combined findings, interpreter-dependent date behavior, stricter rule changes, and unrelated validator failures. Asserted no traceback, no leg repositories or source branches on refusal, correct finding codes/remediation, and successful execution after correction. Kept valid empty/list follow-ups and readable dates passing.	tests/test_adopt_execute_refusals.py

Possibly linked issues

• adopt-project.py: check never reads a plan's elected_on: when the plan has no reference:, so plan ok is followed by an execute that creates both leg repositories and only then refuses election-date-malformed, naming --elected-on, a flag neither command takes #294: PR fixes malformed elected_on detection, wording, and pre-side-effect refusal described by the issue.
• adopt-project.py: check and execute iterate a plan's follow_ups: without asking for a list, so a hand-edited plan with follow_ups: 5 (or true) ends check in a TypeError: ... is not iterable traceback, and execute in the same one after both leg repositories are created and pushed #293: PR adds follow_ups validation, safe iteration, findings, and pre-leg execute refusal exactly 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.

[brettheap]

@codex review

[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-12T17:22:34.828208Z	dbfad70	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Already looking forward to the next diff.

Reviewed commit: 84f380677f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[brettheap]

(lane openRepoShape-2, 2026-10-12T19:39Z)

This lane reviewed its own main-merge resolution on this PR at 10323a7 (a2ec12e's merge of #314, then main dd8d0ea), read-only in its own detached worktrees, with nothing authored.

MERGEABLE. Land once the three-OS CI is green. Every item below is follow-up.

1. P3: the guard at adopt-project.py:1919-1923 defers more than the body says. It also skips _manifest_values' own refusals of org: (unsafe-value, 1924) and id: (plan-bad-id, via _template_table at 4889). For a plan with elected_on: someday and org: "-evil", check gives only the date finding while execute refuses the org. With id: "North Wind", check refuses the id while execute refuses the date. On main they agreed. No leg is created either way.
2. nit: the docstrings of _manifest_values (1893-1895) and _manifest_findings (1937) do not say that a bad date also gives None.
3. nit: the misreads_elsewhere example elected_on: "20261011" (1942) no longer reaches the validator.
4. nit: the retargeted elected-on-iso-week check row (test_adopt_manifest_values.py:135, 271) asserts that the finding is present, not that it is the only one.

The _entry_findings hunks keep both sides, in the right order (3639-3645). The 5 retargeted #314 rows are right.

Tests at 10323a7, covering every tests/test_adopt_*.py plus the scaffold-manifest-values, reference-default, doctor, collisions, cli-reference and hygiene files: 2360 passed, 4 skipped, 0 failed. render-cli-reference.py --check is ok.

git merge-tree --write-tree a2ec12e dd8d0ea is rc 0 and equals 10323a7's tree. Of the 44 probe runs, none made a leg and none printed a traceback.

The report is handoffs/xFactory/attachments/lane-openRepoShape-2/review356-5a5011d/review-merge-10323a7.md in opensoft/brett-wip.

[brettheap]

(lane openRepoShape-2, 2026-10-12T22:16Z)

This lane re-verified its own PR at 5982bbe (the main merge 88c430c and the guard-order fix), read-only in its own detached worktrees, nothing authored.

MERGEABLE WITH NITS. #435 merges clean onto 5982bbe but conflicts with main 8782333 in adopt-project.py, so it needs its own main merge after this lands.

• The merge keeps adopt-project.py: every failure once a leg repository exists flushes stdout, then prints REFUSED <step>., what failed and one notice of what the run left, so a failed git filter-repo no longer exits 2 with an empty stderr (#171, #188, #177) #445's try, steps and late notice whole. The one PR line inside it, _plan_follow_ups(plan) (adopt-project.py:5139), cannot raise. The date and follow-ups refusals say no leg was created and print no notice.
• With elected_on: someday beside a bad org: or id:, check and execute now both name unsafe-value or plan-bad-id, as main 580d7df does. A bad date still never reaches _template_table.
• 70 probe plans at the head and at main: no traceback and no leg in any refusal. At main, "2026-13-01" or full-width digits with reference: kept still adopt; here both are refused before any leg.
• nit, follow-up: adopt-project.py:1914-1915 says a bad date never changes which problem either command names first. That holds for org: and id: only; visibility: secret waits behind the date, the stated cost.
• Pre-existing on main: with a bad leg path, check names a bad id: or org: first, execute the leg path.

Tests, 0 failed: 2448 passed, 4 skipped (MedxEHR, Windows) on 5982bbe + main d6df36b + #401; 2649 passed, 4 skipped with main 36538fd; 359 passed with main 8782333.

merge-tree with d6df36b, 36538fd, 8782333, da27e69 and 3efcc7a: rc 0.

Report: handoffs/xFactory/attachments/lane-openRepoShape-2/review356-5982bbe/final-report.md in opensoft/brett-wip.

[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