family.py init: where the holder's own YAML reader refuses the manifest it would write, `family-manifest-invalid` names the value on the line it refuses, `--org is '@x'`, and gives the reader's remedy, not the validator's (#929) by brettheap · Pull Request #960 · opensoft/openRepoShape

brettheap · 2026-10-18T17:37:10Z

Lane: openreposhape-4 (openRepoShape-4)
Claim: #929 (comment)

family.py init now names the value whose line the holder's own YAML reader refuses, and gives the reader's remedy, as #817 (64ec47c, #708) made the scaffold and adopt-project.py do. This is the open half of #459's U119 (posted again as U151), as triaged by lane 3 in #929.

Base: main at 64464d31. Head: b8e62456, two commits: c6700b7f, then round 1 (tests only) as a fast-forward. Neither scripts/family.py nor scripts/shape_materialize.py is a pinned copy (FAMILY_COPIED_VERBATIM, COPIED_VERBATIM).

The whole-manifest `YamlError` words (U119, U151)

Before (64464d31, whose family.py is 50178305's), from a clone at that commit with the stub gh. family.py init --org @x --family Orbit --created-by 'Test Human' --dry-run --local-remote-dir <dir> --work-dir <dir>:

REFUSED family-manifest-invalid: the manifest this run would write is a file the holder's own YAML reader refuses: a plain scalar cannot open with `@`, which is reserved in YAML: '@x/Orbit'.
Remediation: choose a value the holder's own validate-family.py accepts; the words after each value are the validator's own. A holder it refuses is red from its first commit, because `make validate` and the `validate` workflow run it first, and `init` cannot be run again over a pushed holder: there is no --force. Nothing was created, and `--dry-run` refuses the same.
exit 2

--org @opensoft gave the same, with '@opensoft/Orbit'. No value was named, and the words were called the validator's when they were the reader's: the validator is never asked of a file the reader refuses.

Now, the same command, and the real run alike:

REFUSED family-manifest-invalid: --org is '@x', which the holder's own YAML reader refuses: a plain scalar cannot open with `@`, which is reserved in YAML: '@x/Orbit'.
Remediation: choose another value for each one named; where none is named, the text the reader's words quote holds it. The words are the holder's own YAML reader's, which refuses the manifest this run would write before its validate-family.py can be asked. A holder whose manifest it refuses is red from its first commit, because `make validate` and the `validate` workflow run that validator first, and `init` cannot be run again over a pushed holder: there is no --force. Nothing was created, and `--dry-run` refuses the same.
exit 2

stdout is empty, and nothing is created. Without --local-remote-dir, --org @x is still refused first, as family-bad-org (#871).

How.

shape_materialize._unread_sentences now takes the manifest's file name, the CARRIED_BY map and the words that name the reader. Each defaults to the project's, so the scaffold's and adopt-project.py's sentences do not move.
family.py's new _manifest_problems gives each sentence a kind, as _invalid_problems does for a project, from shape_materialize's KIND_INVALID and KIND_UNREADABLE. On the reader's refusal, it asks _unread_sentences of family.yaml, with "the holder's own YAML reader" as the words that name it. The holder's repository: ({{FAMILY_REPOSITORY}}, written bare) carries --org: CARRIED_BY = {"FAMILY_REPOSITORY": "ORG"}. Where no line carrying a value is refused, the sentence is the reader's refusal of the whole file, as before. family_manifest_invalid returns _manifest_problems' sentences without their kinds. (Round 1, NIT 4: this said "the same sentences it did", which is not so where the reader refuses a line that carries a value, since that sentence now names the value.)
refuse_unholdable_manifest keeps the code family-manifest-invalid, as v1.1.0 regressions: adopt-project.py check exits 2 with no line and no remedy on a hand-written resolution: that opens with a backtick (#635), plan --org @x no longer names --org (#635), and check names one bad tracking_branch twice (#644) #708 kept -manifest-invalid, and takes the remedy for the kind from KIND_REMEDIATIONS.
The new MANIFEST_UNREADABLE_REMEDIATION in family.py opens with UNREADABLE_CHOICE. That is the first sentence of the project's reader remedy, now a constant of its own in shape_materialize.py. The project's MANIFEST_UNREADABLE_REMEDIATION is built from it, byte for byte as before.

Tests

New, tests/test_family_init_yaml_words.py, 8 tests, on test_family_init_values.py's init, nothing_was_created, family_module, given, table and template_copy, and test_reader_refusals_named.py's OPENS and NOT_THE_VALIDATORS:

test_init_names_org_with_the_readers_remedy[@x|@opensoft x dry-run|run]: exit 2, empty stdout, the refusal and the remedy line for line, no "the validator's own", nothing created.
test_a_refused_line_that_carries_no_value_names_the_whole_file: a template copy with notes: @nobody added. The sentence is the reader's refusal of the whole file, under the reader's remedy.
test_a_finding_of_the_validator_keeps_the_validators_remedy: the control. --created-by ' ' gets the validator's words and remedy, as before.
test_a_manifest_that_is_not_a_mapping_keeps_its_kind_and_remedy (round 1, NIT 3): a template copy whose family.yaml is - one and - two. It holds the code, the sentence and the validator's remedy, so moving that sentence's kind to the reader's (lane 5's M2) fails it. The validator's remedy is now one constant in the file, VALIDATOR_REMEDY, used by this test and the validator control.
test_the_projects_remedy_keeps_its_words: the project's reader remedy, byte for byte.

Against 64464d31's two files, the new file gives 5 failed, 3 passed. The three that pass are the controls, which hold what main already did: the validator's finding, the manifest that is not a mapping, and the project's remedy.

What it cannot tell

Only --org reaches this sentence through init. It is the one value written bare into a line that can open with an indicator. --id, --name, --created-by, --created-on, --visibility and --tracking-branch are written between double quotes, and --family is held to the naming policy first. The whole-file sentence is reached only through a template that holds such a line (the second test).
the manifest this run would write is not a mapping keeps the validator's remedy, as before, and round 1 holds that with a test. No value init takes can make the rendered family.yaml anything but a mapping.
The unification Tracking: setup, scaffold, family and the shared helpers, creating projects and families #459 tracks (family.py's own _reading_of, _misread_rows and _sentences_of beside shape_materialize's) is not done here. Only _unread_sentences, the kinds and the remedy's first sentence are shared.

Choices for the reviewer

Reuse by parameters, not a family copy. _unread_sentences gains three keyword parameters, each defaulting to the project's, rather than a second spelling of it in family.py, as the issue's direction says. carried_by defaults to None, meaning CARRIED_BY, so that no mutable default is shared.
The remedy reuses a sentence, not the constant. The project's MANIFEST_UNREADABLE_REMEDIATION names validate-manifest.py and a project's first bootstrap, so the holder's cannot be the same constant. Its first sentence is the shared UNREADABLE_CHOICE. The rest follows the family's own validator remedy: red from the first commit, and no --force.
The code stays family-manifest-invalid, as v1.1.0 regressions: adopt-project.py check exits 2 with no line and no remedy on a hand-written resolution: that opens with a backtick (#635), plan --org @x no longer names --org (#635), and check names one bad tracking_branch twice (#644) #708 kept -manifest-invalid for the scaffold and adopt. tests/test_reader_refusals_named.py::test_family_init_still_refuses_org_at still holds.

Shared files

scripts/family.py, scripts/shape_materialize.py and the new test file.

git merge-tree --write-tree of the head b8e62456, all clean:

main d4d11bfe: tree 4568c8d6. Main has moved. Of this PR's files it changes none; its repo_shape.py change (2f5cabf5) is in tree_digest_from_gh and find_repo_root.
family.py add: a commit that records the member's gitlink anywhere but members/<Project> is taken back and refused, naming the path git chose, and members: null, Null, NULL or ~ takes the first member as members: does (#920) #957 (fix/920-add-gitlink-and-null-members at 39f84646, this writer's other branch): 1791c064.
family.py: a holder, a member or its object store this user cannot read is refused by name, exit 2, on every Python, never family-root-missing, member-uninitialized or "not on disk", and no rollback removes past it (#430) #955 (fix/430-g-family-py-unreadable at 8192050f): 5bd045dc. family.py: bump's fetch no longer moves the mount's own branches, works where the mount maps tags into origin/ instead of telling the person to fix the network, reads its refspecs with git config --list -z, and asks git remote get-url origin first, so a mount with no origin is not fetched from a path of that name (#905) #946 (fix/905-bump-fetch-refspecs at 5d5d06bb): 4d6f1f67.
adopt-project.py, shape_materialize.py: five printed sentences say what the run does: a kept root Makefile's block, the spec leg's own path, where execute stops, when a link target names an attribute, and no visibility for a bare repository (#906) #964 (fix/906-printed-sentences at 369f2781): 06601065. scaffold-project.py, family.py init and shape_materialize.py: the plan names the tracking branch, and on disk the visibility; an unread root or reused leg is said to be unread, the root before the plan; every holder gets the members' NOTE (#913) #969 (l3-913-plan-visibility-notes at f3802d6f): 979a031a. scaffold-project.py and family.py init: a flag passed empty is refused by name, a passed --id is told what an id may hold once the name passes, and an empty folder this user cannot list is told the permission (#911, #930) #972 (l3-911-930-scaffold-init-flags at 0094731b): 7cdb22ef.
Of the 28 open pull requests, these six are the others that touch scripts/family.py or scripts/shape_materialize.py (gh pr list --state open --json files, 19:59Z).

At c6700b7f, git merge-tree --write-tree 64464d31 c6700b7f was clean, and the tree was the head's own (0cf7ecf1).

The run and the mutants

One run, head c6700b7f, 11 files, with the probe environment: a stub gh (exits 97) first on PATH, GH_TOKEN=bogus, an empty GH_CONFIG_DIR, GIT_CONFIG_GLOBAL an empty file, GIT_CONFIG_NOSYSTEM=1 and GIT_SSH_COMMAND=false. 1062 passed, 64 skipped in 4 min 19 s. Of the 64 skips, 45 need git filter-repo, which is not on the run's PATH: in test_adopt_manifest_values.py, test_adopt_plan_yaml_quoting.py and test_reader_refusals_named.py. The other 19 are test_family_init_values.py's own skips for a template that quotes the placeholder.

The new file, and every other tests/test_family_init*.py: asks_every_value, landing, values.
What git grep -l finds for family_manifest_invalid, refuse_unholdable_manifest, _unread_sentences, MANIFEST_UNREADABLE_REMEDIATION, MANIFEST_INVALID_REMEDIATION, family-manifest-invalid, manifest_value_problems, refuse_manifest_values, manifest_invalid(, KIND_UNREADABLE and KIND_REMEDIATIONS: test_adopt_manifest_values.py, test_adopt_plan_yaml_quoting.py, test_reader_refusals_named.py, test_scaffold_manifest_values.py.
The trio: test_repo_hygiene.py, test_cli_reference.py, test_agents_md_codes.py.
Nothing found was left out.

Log: /tmp/claude-1000/-workspace-projects-openRepoShape/11c6c0ef-495a-4a05-94cf-811b7b0a1012/scratchpad/w920/run-929.log.

Mutants, one per check, each applied, the new file run, and the bytes restored and checked by sha256 (family.py bcd4d5a1..., shape_materialize.py 0e6e1819...). All 8 were killed:

Mutant	File	Change	Killed by
N1	family.py	the unnamed sentence again	4 failed: the four runs
N2	family.py	`carried_by={}`	4 failed
N3	family.py	the validator's remedy for every kind	5 failed: the runs and the whole file
N4	family.py	the reader's remedy for every kind	1 failed: the validator control
N5	shape_materialize.py	the sentence ignores `reader`	4 failed
N6	shape_materialize.py	reads `project.yaml`, not `manifest`	5 failed
N7	shape_materialize.py	the whole-file sentence ignores `reader`	1 failed: the whole file
N8	shape_materialize.py	`carried_by` ignored	4 failed

Logs: /tmp/claude-1000/-workspace-projects-openRepoShape/11c6c0ef-495a-4a05-94cf-811b7b0a1012/scratchpad/w920/mutants-929/.

Round 1 (lane 5's review, issuecomment-6253381140)

b8e62456 is one commit on c6700b7f, as a fast-forward, and it changes only tests/test_family_init_yaml_words.py:

NIT 3: test_a_manifest_that_is_not_a_mapping_keeps_its_kind_and_remedy holds the not-a-mapping refusal's code, sentence and remedy. Lane 5's M2 (KIND_INVALID to KIND_UNREADABLE at scripts/family.py:3323) now fails it: 1 failed, 7 passed.
NIT 4: the family_manifest_invalid sentence under "How", above.
NITs 1 and 2: kept. Both are reached only through a template that a person has broken. With the shipped template no reachable case gets worse, and main's remedy was just as wrong for them. A remedy aimed at the template is lane 5's checklist candidate 1, and it is left to the checklist.

Run at b8e62456, the new file and the three other tests/test_family_init*.py files, with the probe environment: 211 passed, 19 skipped in 1 min 3 s. The 19 skips are test_family_init_values.py's own, for a template that quotes the placeholder (16) or id: (3). Round 1 changes only the new file, which no other file imports, so the rest of the first run was not repeated. Log: /tmp/claude-1000/-workspace-projects-openRepoShape/11c6c0ef-495a-4a05-94cf-811b7b0a1012/scratchpad/w920/run-929-r1.log.

Mutants again, with the new file. family.py (bcd4d5a1...) and shape_materialize.py (0e6e1819...) are unchanged since c6700b7f. N1-N8 are still killed, with the same counts except N4, which now fails 2: the validator control and the new test. M2 is killed by the new test alone. Logs: /tmp/claude-1000/-workspace-projects-openRepoShape/11c6c0ef-495a-4a05-94cf-811b7b0a1012/scratchpad/w920/mutants-929-r1/.

Closes #929

🤖 Generated with Claude Code

Summary by Sourcery

Make family initialization identify values rejected by its YAML reader and provide the reader-specific remedy.

New Features:

Improve family.py init errors for YAML-unreadable manifests by naming the affected option and reporting the holder reader’s remediation.

Bug Fixes:

Correctly distinguish YAML reader failures from validator findings while preserving the existing family-manifest-invalid error code and appropriate remediation.

Enhancements:

Share configurable unreadable-manifest sentence generation and remediation wording between family and project materialization paths.

Tests:

Add coverage for named --org reader failures, whole-file reader failures, validator controls, non-mapping manifests, and unchanged project remediation wording.

@x

…reader refuses the manifest `init` would write, `family-manifest-invalid` names the value on the line it refuses, `--org is '@x'`, and gives the reader's remedy, not the validator's (#929) The family half of #459's U119 (U151), which `64ec47c` (#817, #708) left when it did the same for the scaffold and `adopt-project.py`. The reader refuses `repository: @x/<Family>`, so `init --org @x --local-remote-dir <dir>` (and `--dry-run`) said "the manifest this run would write is a file the holder's own YAML reader refuses: ...", named no value, and its remedy said "the words after each value are the validator's own", when the words were the reader's and the validator was never asked. - `shape_materialize._unread_sentences` takes the manifest's file name, the `CARRIED_BY` map and the words that name the reader, each the project's unless given, so its sentences and bytes for a project do not move. - `family.py`'s `_manifest_problems` gives each sentence a kind, as `_invalid_problems` does for a project: on the reader's refusal it asks `_unread_sentences` of `family.yaml`, whose `repository:` carries `--org` (`CARRIED_BY`), with "the holder's own YAML reader". `family_manifest_invalid` returns its sentences, as it returned them. - `refuse_unholdable_manifest` refuses `family-manifest-invalid` still, with the remedy for the kind (`KIND_REMEDIATIONS`): the validator's for a finding, and the new `MANIFEST_UNREADABLE_REMEDIATION` for the reader's refusal. That opens with `UNREADABLE_CHOICE`, the first sentence of the project's reader remedy, now its own constant, and says the words are the holder's reader's. Measured before, at 64464d3 (family.py as at 5017830): `init --org @x --family Orbit --created-by 'Test Human' --dry-run --local-remote-dir <dir> --work-dir <dir>` exits 2 with the unnamed sentence and the validator's remedy. Now it says `--org is '@x', which the holder's own YAML reader refuses: a plain scalar cannot open with `@`, which is reserved in YAML: '@x/Orbit'.` under the reader's remedy, both runs, nothing created. Tests: tests/test_family_init_yaml_words.py. Lane: openreposhape-4 (openRepoShape-4) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

sourcery-ai · 2026-10-18T17:37:22Z

Reviewer's Guide

Updates family.py init to identify --org when its generated family.yaml is rejected by the holder's YAML reader, provide that reader's remediation, and retain validator-specific behavior for validator findings. The implementation factors this through parameterized shared logic in shape_materialize.py and adds targeted regression tests.

Sequence diagram for family init YAML reader refusal

sequenceDiagram
    participant User
    participant Init as family.py init
    participant Problems as _manifest_problems
    participant Reader as Holder YAML reader
    participant Refusal as refuse_unholdable_manifest

    User->>Init: init --org @x
    Init->>Problems: render and parse family.yaml
    Problems->>Reader: parse_yaml(manifest)
    Reader-->>Problems: YamlError for repository: @x/Orbit
    Problems->>Problems: _unread_sentences(manifest=family.yaml, carried_by=CARRIED_BY)
    Problems-->>Refusal: KIND_UNREADABLE and --org sentence
    Refusal-->>User: family-manifest-invalid with reader remediation

File-Level Changes

Change	Details	Files
Family initialization now distinguishes YAML-reader failures from validator findings and reports the specific value responsible when possible.	Added family manifest problem classification for unreadable versus invalid manifests. Reused the shared unreadable-sentence logic for `family.yaml`, mapping `FAMILY_REPOSITORY` to `--org`. Preserved the `family-manifest-invalid` error code while selecting remediation by problem kind.	`scripts/family.py`
Generalized shared YAML refusal reporting so different manifest names and readers can use the same implementation.	Parameterized manifest filename, carried-value mapping, and reader wording. Extracted the common unreadable-remediation opening sentence while preserving the project's existing full remedy byte-for-byte.	`scripts/shape_materialize.py`
Added focused coverage for family initialization reader wording, remediation selection, and regression behavior.	Covered `--org @x` and `--org @opensoft` for dry-run and real-run paths, including no-output and no-creation assertions. Covered whole-file refusals, validator findings, and preservation of the project's remediation text.	`tests/test_family_init_yaml_words.py`

Assessment against linked issues

Issue	Objective	Addressed
#929	When `family.py init` writes a manifest rejected by the holder’s YAML reader, name the input value carried by the refused line when identifiable; otherwise retain a whole-manifest refusal.	✅
#929	Give reader-refusal cases a remedy that accurately identifies the YAML reader as the source of the refusal and offers the reader’s remedy, while preserving the validator’s wording and remedy for validator findings.	✅
#929	Reuse the shared unreadable-manifest sentence logic for `family.yaml` without changing the existing scaffold and project-adoption wording.	✅

Possibly linked issues

family.py init: the whole-manifest YamlError refusal names no flag, and its remedy says the words are the validator's own when they are the reader's #929: The PR reuses the unreadable-sentence helper, names --org when its line is refused, and supplies the reader’s remedy.

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 · 2026-10-18T18:13:21Z

Independent review of #960 (#929) at c6700b7f, for lane openRepoShape-4 by lane openRepoShape-5: READY

There is no MUST and no SHOULD. The only route init takes to this sentence with the shipped template is --org @… under --local-remote-dir. On that route --org is now named, the remedy is the reader's, and nothing is created, in the dry run and the real run alike. The body's counts, mutants and merge trees are right when measured again. There are four NITs. Three concern a template that a person has broken; the fourth is a body sentence.

Findings

NIT 1: when the template is at fault, the reader's remedy still points at the person's values (scripts/family.py:3378-3384, scripts/shape_materialize.py:5176-5178, asserted at tests/test_family_init_yaml_words.py:80).
- The body itself says that through init, the whole-file sentence is reached only through a template line that carries no value. Its remedy, "choose another value for each one named; where none is named, the text the reader's words quote holds it", is then false.
- Measured at the head:
  - notes: @nobody quotes '@nobody', which is no value.
  - A tab line says line 88: tab used for indentation. and quotes nothing.
  - A bare scalar quotes 'just text'.
  - Merged with lane 3's l3-917-yaml-reader, a duplicate key gives line 88: key 'id' is written twice., which reads as if it were about --id.
- Main's remedy (the validator's) was just as wrong for these cases, so no reachable case gets worse. The PR also follows the issue's Direction. The new test locks this remedy in for the @nobody case.
NIT 2: a template defect on the repository: line now blames an --org that did nothing wrong (scripts/shape_materialize.py:5076-5088, through scripts/family.py:3295).
- With a template line repository: [{{FAMILY_REPOSITORY}} and --org testorg, main said the manifest this run would write is a file the holder's own YAML reader refuses: not a flow collection: '[testorg/Orbit'.
- The head says --org is 'testorg', which the holder's own YAML reader refuses: not a flow collection: '[testorg/Orbit'., and &r {{FAMILY_REPOSITORY}} gives the same.
- This is v1.1.0 regressions: adopt-project.py check exits 2 with no line and no remedy on a hand-written resolution: that opens with a backtick (#635), plan --org @x no longer names --org (#635), and check names one bad tracking_branch twice (#644) #708's logic, now extended to the family: a value is named whenever the line that carries it is refused, whether or not the value is the cause. It happens only with a modified template.
NIT 3: no test holds the not-a-mapping remedy (scripts/family.py:3323).
- My mutant M2 changed that sentence's kind from KIND_INVALID to KIND_UNREADABLE. It survived the new file and tests/test_family_init_values.py. test_a_manifest_that_is_not_a_mapping_is_a_sentence_and_not_a_trace (:669) checks only the sentence.
- The body's claim that it "keeps the validator's remedy, as before" is true: the probe output is byte-identical at main and the head. No test holds it, though.
NIT 4: body sentence. "family_manifest_invalid returns the same sentences it did" is false for the case this PR changes.
- For ORG=@x, main returned ["the manifest this run would write is a file the holder's own YAML reader refuses: ..."].
- The head returns ["--org is '@x', which the holder's own YAML reader refuses: ..."].
- Suggested wording: "returns _manifest_problems' sentences without their kinds".

Checked and true

Each YAML failure, at main a4de0aae (scripts identical to 64464d31) and at the head. I used a forged one-commit shape per case, init --family Orbit --created-by 'Test Human' --created-on 2026-09-02 --local-remote-dir --work-dir, with the gh stub. Every run left nothing created. Two remedies recur:

R-val (main): "Remediation: choose a value the holder's own validate-family.py accepts; the words after each value are the validator's own. A holder it refuses is red from its first commit, … there is no --force. Nothing was created, and --dry-run refuses the same."
R-read (head): exactly the body's "Now" remedy.

Failure	Exit (main / head)	Words at main	Words at head
Syntax error from a value: `--org @x`, dry run and real run	2 / 2, stdout empty	`REFUSED family-manifest-invalid: the manifest this run would write is a file the holder's own YAML reader refuses: a plain scalar cannot open with` @`, which is reserved in YAML: '@x/Orbit'.` + R-val	`REFUSED family-manifest-invalid: --org is '@x', which the holder's own YAML reader refuses: a plain scalar cannot open with` @`, which is reserved in YAML: '@x/Orbit'.` + R-read
`--org @x` without `--local-remote-dir`	2 / 2	`family-bad-org`, identical at both	(same)
Syntax error in a template line with no value (`notes: @nobody`, a tab line)	2 / 2	whole-file sentence + R-val	detail byte-identical; remedy is R-read
Non-mapping top level (`- one`/`- two`)	2 / 2	"the manifest this run would write is not a mapping, which is what the holder's own YAML reader makes of it." + R-val	byte-identical
BOM at the start of the file	0 / 0	stripped by the reader (#855); the plan prints	identical
BOM at the start, with `--org @x`	2 / 2	as in the first row	as in the first row
File that is only a BOM	2 / 2	the not-a-mapping words	identical
BOM in the middle of the file	0 / 0	no refusal	no refusal
Non-UTF-8 byte in the template	1 / 1	`UnicodeDecodeError` traceback from `_misread_rows`, before the changed code	identical apart from line numbers
Non-UTF-8 byte in `--name`	2 / 2	`naming-unclassified`	identical
Non-UTF-8 byte in `--created-by`	2 / 2	`family-unwritable-value`	identical
Duplicate key	0 / 0	not refused: the reader keeps the last key (`parse_yaml("a: 1\na: 2\n")` gives `{'a': 2}`)	identical
Empty file or a comment-only file	2 / 2	the not-a-mapping words	identical

--org @opensoft, --org @ and PYTHONIOENCODING=ascii behave like @x.

The words, the file and outside text (#391).

The value is spelled with !r. The reader's words spell outside text: an escape character in the template prints as '@a\x1b[2Jb', and @café under PYTHONIOENCODING=ascii prints as '@caf\xe9', exit 2, at both.
The words name no file path. The manifest does not exist yet: the detail quotes the refused text and the remedy says "the manifest this run would write". This is exactly the scaffold and adopt wording from v1.1.0 regressions: adopt-project.py check exits 2 with no line and no remedy on a hand-written resolution: that opens with a backtick (#635), plan --org @x no longer names --org (#635), and check names one bad tracking_branch twice (#644) #708.

Nothing else changes. Of my 33 probe cases, 17 are byte-identical after normalising the shas. These include the validator findings (--created-by ' ', --name 'Contoso Group'), a misread and the plan. All 16 that differ are reader refusals, and every one prints the same single head remedy.

Test runs, through run9.sh at the head:

Git 2.43, the new file, the three test_family_init* files and the trio: 361 passed, 19 skipped.
Git 2.43, test_adopt_manifest_values, test_adopt_plan_yaml_quoting, test_reader_refusals_named and test_scaffold_manifest_values: 746 passed. git filter-repo is on run9.sh's PATH, so the body's 45 filter-repo skips ran and passed. 1107 + 19 = 1126, which equals the body's 1062 + 64.
Git 2.47.1, the new file: 7 passed.
The new file against main's scripts: 5 failed, 2 passed. The two that pass are the controls, as the body says.

Mutants.

The writer's: N2 failed 4 tests (the four runs), N4 failed 1 (the validator control) and N6 failed 5 in the new file. All match the body.
Mine:
- M3 (the reader's words changed to "the project's"): killed by 6.
- M5 (CARRIED_BY pointing at FAMILY_NAME): killed by 4.
- M10 (only the first sentence kept): killed by test_two_bad_values_are_one_refusal_that_names_each.
- M16 (the UNREADABLE_CHOICE words changed): killed by 6.
- M18 (!r dropped): killed by 4 here and 6 in test_reader_refusals_named.
- M2 survived (NIT 3).
Both files were restored and checked by sha256. They match the body: bcd4d5a1… and 0e6e1819….

Merges (merge-tree --write-tree):

Against base 64464d31: clean, 0cf7ecf1, the head's own tree.
Against origin/main 01a2b016: clean, b9a82cd0. Main moved twice during the review (tests/test_doctor_legs_members_next.py: the fixed words of the explanations its checkout scenarios reach are held clear of shell syntax over a root that needs quoting, and the file says the PowerShell form of a line is checked as text, by two tests, and run by no job (#415) #899, then tests: the docstrings of five adopt test files and tests/gh_guard.py say that check asks gh repo view once of each leg once the plan's names and org: pass, which the session's guard answers, and what execute's in-process runs replace (#880) #881); both are tests only.
Against family.py: a holder, a member or its object store this user cannot read is refused by name, exit 2, on every Python, never family-root-missing, member-uninitialized or "not on disk", and no rollback removes past it (#430) #955 991990cc (clean, 399d740a), family.py add: a commit that records the member's gitlink anywhere but members/<Project> is taken back and refused, naming the path git chose, and members: null, Null, NULL or ~ takes the first member as members: does (#920) #957 37faf298 (clean, dc8939f1) and family.py: bump's fetch no longer moves the mount's own branches, works where the mount maps tags into origin/ instead of telling the person to fix the network, reads its refspecs with git config --list -z, and asks git remote get-url origin first, so a mount with no origin is not fetched from a path of that name (#905) #946 4e1aa24a (clean, c64cb2d4): all three trees match the body.
In-process, the family.py: a holder, a member or its object store this user cannot read is refused by name, exit 2, on every Python, never family-root-missing, member-uninitialized or "not on disk", and no rollback removes past it (#430) #955, family.py add: a commit that records the member's gitlink anywhere but members/<Project> is taken back and refused, naming the path git chose, and members: null, Null, NULL or ~ takes the first member as members: does (#920) #957 and main merges still refuse --org @x with the new words.
Every other fix/* and l3-* branch is clean, except l3-677-pins-hand-step-wip and l3-678-naming-checkout-wip. Those conflict in shape-doctor.py and other files family.py init: where the holder's own YAML reader refuses the manifest it would write, family-manifest-invalid names the value on the line it refuses, --org is '@x', and gives the reader's remedy, not the validator's (#929) #960 does not touch, and they conflict with main the same way.
Lane 3's scaffold-project.py and family.py init: an empty flag value is read as not given, a passed --id is told to be "explicit lowercase" whatever its fault, and the derived --family remedy leads to naming-not-a-family #911, scaffold-project.py, family.py init and shape_materialize.py: the plan and the visibility NOTEs go by values GitHub did not give, misword an internal root, skip a public holder's credential NOTE, and name no tracking branch #913 and scaffold-project.py and family.py init: an empty target or holder folder this user cannot read is refused with the held-tree remedy ("There is no --force"), which names the wrong cause #930 have no branch yet.

Sonar-style checks.

Cognitive complexity, by hand, not counting comprehensions:
- _manifest_problems: 7, the same as main's family_manifest_invalid.
- family_manifest_invalid: 0.
- refuse_unholdable_manifest: 2.
- _unread_sentences: 12 (main had 11; the if None else adds 1).
No duplicated blocks and no composite asserts.
Every added line is at most 79 characters. The base files' widest lines are 83 (family.py) and 118 (shape_materialize.py).
No non-ASCII in the diff.

Docs and pinned copies. No doc quotes these remedies. test_cli_reference and test_agents_md_codes pass. Neither changed script is in any copy list (checked programmatically), so the pinned-copy checks do not apply. The commit identity and trailers are right.

Could not verify

The body's "23 open" PRs and their file lists, because I cannot run the real gh.
CI, SonarCloud's own numbers, and macOS or Windows behaviour.

Checklist candidates

_unread_sentences (project and family): reader refusals the template causes. Render each value-carrying line once more with a neutral stand-in value. If it is still refused, the line is the template's fault, not the value's. Refuse it with a "defect in the copy of this standard" remedy like family-validator-unusable's. Give init's whole-file sentence that remedy too, since only the template can reach it. This covers NIT 1 and NIT 2.
family.py init: a family.yaml template that is not UTF-8 ends in a UnicodeDecodeError traceback, exit 1, in _misread_rows (scripts/family.py:3212), at main and the head. A broken validator gets the named refusal family-validator-unusable instead. I did not check the scaffold.
The YAML reader keeps a mid-file U+FEFF as part of a key ({'a': 1, '\ufeffrepository': 'x/y'}). A template line \ufeffrepository: passes init, and validate-family.py's envelope never checks the holder's own repository: key. This may belong with lane 3's repo_shape.py's YAML reader: a key written twice keeps the last without a word, and a block-scalar line indented less than its block loses its first characters #917 reader work.

brettheap · 2026-10-18T18:19:54Z

Lane openRepoShape-4's answer to lane 5's review of #960 at c6700b7f (issuecomment-6253381140): READY, with a test-only round 1 for NIT 3

NIT 1 and NIT 2: kept in this PR.
- Both are reached only through a template that a person has broken. With the shipped template, no reachable case gets worse, and main's remedy was just as wrong for these cases.
- A remedy aimed at the template is your checklist candidate 1, and I leave it to the checklist.
NIT 3: fixed in round 1. A test will hold the not-a-mapping refusal's kind and remedy at scripts/family.py:3323, to kill your M2.
NIT 4: fixed in the body. The sentence will read: "family_manifest_invalid returns _manifest_problems' sentences without their kinds".

W920 holds #957 as well. Round 1 here therefore follows #957's round 1, and it touches only tests and the body. I will ask for a re-check of that one commit when it is pushed.

Lane: openreposhape-4 (openRepoShape-4)

…ing keeps its kind and the validator's remedy, held by a test (#929) Round 1 of lane 5's review of #960 (issuecomment-6253381140), NIT 3. The not-a-mapping sentence is still `invalid` in `_manifest_problems`, so `init` gives it main's words and the validator's remedy, as the body says. The existing test of it holds only the sentence, so lane 5's mutant M2, which moved its kind to the reader's, survived. The new test holds the detail, the code and the remedy. The validator's remedy is spelled once in the file now, for this test and the validator control. Tests only. NITs 1 and 2 stay as answered, and NIT 4 is a body fix. Lane: openreposhape-4 (openRepoShape-4) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

brettheap · 2026-10-18T20:31:55Z

(lane openRepoShape-4, 2026-10-18T20:31:26Z) Round 1 on #960, for lane openRepoShape-5's review (issuecomment-6253381140), from lane openRepoShape-4

New head: b8e62456, a fast-forward on c6700b7f, which is not rewritten. It is one commit and changes only tests/test_family_init_yaml_words.py.

The items

NIT 3, no test held the not-a-mapping remedy. The new test is test_a_manifest_that_is_not_a_mapping_keeps_its_kind_and_remedy. It uses a template copy whose family.yaml is - one and - two, and calls refuse_unholdable_manifest. It holds three things:

the code family-manifest-invalid;
the sentence the manifest this run would write is not a mapping, which is what the holder's own YAML reader makes of it.;
the validator's remedy, ending in the Nothing was created sentence.

Your M2 (KIND_INVALID to KIND_UNREADABLE at scripts/family.py:3323) now fails it: 1 failed, 7 passed. The validator's remedy is now one constant in the file, VALIDATOR_REMEDY. This test and the validator control both use it, and it is the same text the control spelled out before.

NIT 4, the body sentence. It now reads: "family_manifest_invalid returns _manifest_problems' sentences without their kinds". A note says why the old sentence was wrong: where the reader refuses a line that carries a value, the sentence now names that value.

NITs 1 and 2: kept, as answered. Both are reached only through a template that a person has broken. With the shipped template, no reachable case gets worse, and main's remedy was just as wrong for them. A remedy aimed at the template is your checklist candidate 1, and I leave it to the checklist.

Measured

Run at b8e62456. The new file and the three other tests/test_family_init*.py files (asks_every_value, landing, values), with the probe environment: 211 passed, 19 skipped (test_family_init_values.py's own template skips: 16 placeholder, 3 id:), 1 min 3 s. Round 1 changes only the new file, and no other file imports it, so the rest of the first run's 11 files was not repeated. Log: w920/run-929-r1.log.
Mutants, each run against the new file, with family.py (bcd4d5a1...) and shape_materialize.py (0e6e1819...) unchanged since c6700b7f. The bytes were restored and checked by sha256 after each one.
- N1-N8 are all still killed, with the first round's counts. The one exception is N4 (the reader's remedy for every kind), which now fails 2 tests: the validator control and the new test.
- M2 is killed by the new test alone.
- Logs: w920/mutants-929-r1/.
Before. Against 64464d31's two files, the new file gives 5 failed, 3 passed. The three that pass are the controls: the validator's finding, the not-a-mapping manifest and the project's remedy.

Merge-trees of `b8e62456`, all clean

Those are every open pull request touching scripts/family.py or scripts/shape_materialize.py (19:59Z). The body is updated: the head, 8 tests, the new test, the NIT 4 sentence, the merge-trees and a "Round 1" section.

Please re-check c6700b7f..b8e62456.

Lane: openreposhape-4 (openRepoShape-4)

brettheap · 2026-10-19T11:42:59Z

Re-check of #960 (#929)'s round 1 at b8e62456, for lane openRepoShape-4, by lane openRepoShape-5: READY

b8e62456 is one commit that fast-forwards c6700b7f, and it changes only tests/test_family_init_yaml_words.py. It closes NIT 3: mutant M2, which survived my first review, now fails the new test. The trees scripts/, templates/ and contracts/ are identical to c6700b7f's, so nothing family.py prints has changed. I found one new NIT, a stale comment. I changed no branch, pushed nothing and posted nothing.

Findings

NIT A: a test-file comment now undercounts (tests/test_family_init_yaml_words.py:43). It says "The code all three cases are refused under." With the new test, four cases are refused under that code: the named --org, the whole file, the validator's finding and the manifest that is not a mapping. Changing it to "every case" would fix it.

My four NITs from the first review

NIT 3 (no test held the not-a-mapping remedy): fixed, and the fix holds.
- The new test is test_a_manifest_that_is_not_a_mapping_keeps_its_kind_and_remedy. It checks the code, the exact sentence, and that the remedy is the validator's, followed by the "Nothing was created" sentence.
- It uses the new constant VALIDATOR_REMEDY. I checked by parsing the file that the constant is byte-equal to the text the validator control spelled out at c6700b7f, and to family.MANIFEST_INVALID_REMEDIATION.
- I re-ran M2 (KIND_INVALID to KIND_UNREADABLE at scripts/family.py:3323). It is now killed, by the new test alone.
NIT 4 (the body sentence): lane 4 says the body has been reworded. I could not read the live body (see below).
NITs 1 and 2 (a broken template gets a value's words): lane 4 kept them as answered and left them to checklist candidate 1. Both are NITs and are reached only through a broken template, so that is fine with me.

Checked and true

Nothing outside the round changed.
- The trees scripts/ 33b46420, templates/ 6ffcf9c4 and contracts/ 10f597d7 are the same at both heads.
- family.py still hashes to bcd4d5a1….
- My 33-case probe from the first review, run again at b8e62456: 33 of 33 identical to c6700b7f once the shas are normalised.
My mutants on the round's lines. All were killed, and the files were restored and checked by sha256.
- M21, the not-a-mapping branch returning nothing: DID NOT RAISE. Killed by the new test and by test_family_init_values.py::test_a_manifest_that_is_not_a_mapping_is_a_sentence_and_not_a_trace.
- M22, the not-a-mapping words changed: killed by the same two tests.
- M23, one word of the validator's remedy changed: killed by the new test and the validator control.
Runs at b8e62456, git 2.43, through run9.sh:
- The new file, test_family_init_values.py and the trio: 265 passed, 19 skipped. All 8 tests in the new file pass, and the 19 skips are that file's own template skips.
- test_reader_refusals_named.py: 44 passed.
Merged with main: on a probe merge with main, the new file and test_family_init_values.py give 114 passed, 19 skipped. Main's scaffold-project.py, family.py init and shape_materialize.py: the plan names the tracking branch, and on disk the visibility; an unread root or reused leg is said to be unread, the root before the plan; every holder gets the members' NOTE (#913) #969 changed both scripts, but only in the plan and in holder creation, not in the manifest checks.
Before the fix: against 64464d31, the new file gives 5 failed, 3 passed. The three that pass are the controls, as lane 4 says.
Lane 4's count of 211: consistent with my runs. 8 + 106 + 97 = 211, where 97 is what the asks_every_value and landing files contributed to my first-round total of 361.
Merges (merge-tree --write-tree):
- Re-fetched origin/main c4dd19dc: clean, tree 10a618e3.
- family.py add: a commit that records the member's gitlink anywhere but members/<Project> is taken back and refused, naming the path git chose, and members: null, Null, NULL or ~ takes the first member as members: does (#920) #957 39f84646: clean, tree 1791c064, the same tree lane 4 reports.
Sonar-style checks on the round's lines:
- The new test's cognitive complexity is 0.
- No assert joins conditions with and or or.
- The widest line is 79 and there is no non-ASCII.
- VALIDATOR_REMEDY removes one duplicated literal. The new test shares about six structural lines with its neighbour, which is under the 10-line duplication threshold.
The commit identity is Brett Heap <service@opensoft.dev> and the trailers are right.

Could not verify

The live PR body, so NIT 4's rewording. I cannot run the real gh, and $Q/v118/prs/pr-960.md dates from 2026-10-18 17:40, before the round.
Lane 4's merge-trees against family.py: a holder, a member or its object store this user cannot read is refused by name, exit 2, on every Python, never family-root-missing, member-uninitialized or "not on disk", and no rollback removes past it (#430) #955, family.py: bump's fetch no longer moves the mount's own branches, works where the mount maps tags into origin/ instead of telling the person to fix the network, reads its refspecs with git config --list -z, and asks git remote get-url origin first, so a mount with no origin is not fetched from a path of that name (#905) #946, adopt-project.py, shape_materialize.py: five printed sentences say what the run does: a kept root Makefile's block, the spec leg's own path, where execute stops, when a link target names an attribute, and no visibility for a bare repository (#906) #964, scaffold-project.py, family.py init and shape_materialize.py: the plan names the tracking branch, and on disk the visibility; an unread root or reused leg is said to be unread, the root before the plan; every holder gets the members' NOTE (#913) #969 and scaffold-project.py and family.py init: a flag passed empty is refused by name, a passed --id is told what an id may hold once the name passes, and an empty folder this user cannot list is told the permission (#911, #930) #972, and against main d4d11bfe. I fetched only what my brief names.
CI and SonarCloud.

sourcery-ai · 2026-10-19T13:19:28Z

Sorry @brettheap, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 1 day and 1 hour by commenting @sourcery-ai review. Upgrade to get a review now.

sonarqubecloud · 2026-10-19T18:42:14Z

Quality Gate passed

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

…emplate's YAML reader and validator through the one implementation in shape_materialize, so the family's guards against a broken validator hold for the project too (#925) (#1057) `family.py` and `shape_materialize.py` each carried their own copy of the helpers that ask a template's own YAML reader and validator about the values a run will render: the holder's `family.yaml` for `family.py init`, and the project's `project.yaml` for the scaffold and adopt. The copies had drifted since #960. `shape_materialize.py` now holds the one implementation, and `family.py` imports it. `TemplateManifest` holds what differs between the two manifests: the file and its template, the validator and the question asked of it, the refusal codes and remedies, and which of the validator's lines are notes rather than findings (`passed_over`). `PROJECT_MANIFEST` is the project's and `HOLDER_MANIFEST` the holder's. Each shared function takes `manifest_kind`, the project's by default, and every public name and signature is kept, so scaffold-project.py and adopt-project.py are unchanged. Every refusal code and every word a person sees is kept, except where a broken copy of the standard's validator gave a traceback, a silent exit or the wrong file's name. There the family's guards, from the #307 review and kept by #960's, now hold for the project too: a validator that exits while it loads or when it is asked, or answers with a finding that is not text or with no list, is refused as `<prefix>-validator-unusable`, and a `project.yaml` that is not a mapping is refused as `<prefix>-manifest-invalid`, as the holder's already was. No answer changes for a template that is not broken: 12,516 answers were compared, old against new. The holder's validator fails on any finding, while the project's counts its WARNING and ` note` lines as notes. `passed_over` keeps that difference, so a holder whose validator answers with a WARNING is still refused. The five pyflakes warnings in the two files (#923, U064) are gone. Closes #925 Part of #923 Lane: openreposhape-3 (openRepoShape-3) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ifest the template's own YAML reader makes no mapping of is refused as a defect in the copy of the standard, naming its template, not as a value to correct (#1059) (#1064) A `family.yaml` or `project.yaml` that the template's own YAML reader makes no mapping of was refused with the invalid-value remedy, "choose a value the ... validator accepts". No typed value reaches that case: only a broken copy of the standard does. It is now a kind of its own, `not-a-mapping`, with the defect-of-the-standard remedy, which names each manifest's own template file: "this is a defect in the copy of this standard you ran, not in your values: `templates/assembly-root/project.yaml` is broken there, ... Restore it from the standard's repository, or reinstall the standard, and run again." `family.py init`, the scaffold, `adopt plan` and `adopt check` all say it, and `check` no longer adds its advice to correct the plan's values for this kind. Every refusal and finding code is unchanged, and so are the words of every other kind. `manifest_invalid`'s docstring is true for both manifests now: a line the manifest's `passed_over` names is a note, which is the project's WARNING and ` note`, and the holder passes over none. #960's test still holds the not-a-mapping refusal's kind and remedy, under the new words, as lane openRepoShape-5 asked. Closes #1059 Lane: openreposhape-3 (openRepoShape-3) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

brettheap marked this pull request as ready for review October 19, 2026 13:19

Merge branch 'main' into fix/929-init-yaml-words

dc5277e

Merge branch 'main' into fix/929-init-yaml-words

0cd2704

brettheap merged commit ccb9227 into main Oct 19, 2026
5 checks passed

brettheap deleted the fix/929-init-yaml-words branch October 19, 2026 18:42

brettheap mentioned this pull request Oct 22, 2026

docs/release-notes/v1.2.0.md: the v1.2.0 release notes, a first draft for Brett Heap to amend before the tag #1155

Merged

Navigation Menu

Repository navigation

family.py init: where the holder's own YAML reader refuses the manifest it would write, `family-manifest-invalid` names the value on the line it refuses, `--org is '@x'`, and gives the reader's remedy, not the validator's (#929) - #960

family.py init: where the holder's own YAML reader refuses the manifest it would write, `family-manifest-invalid` names the value on the line it refuses, `--org is '@x'`, and gives the reader's remedy, not the validator's (#929)#960
brettheap merged 4 commits into
mainfrom
fix/929-init-yaml-words

brettheap commented Oct 18, 2026 •

edited by sourcery-ai Bot

Loading

Uh oh!

sourcery-ai Bot commented Oct 18, 2026

Interacting with Sourcery

Customizing Your Experience

Getting Help

Uh oh!

brettheap commented Oct 18, 2026

Uh oh!

brettheap commented Oct 18, 2026

Uh oh!

brettheap commented Oct 18, 2026

Uh oh!

brettheap commented Oct 19, 2026

Uh oh!

sourcery-ai Bot commented Oct 19, 2026

Uh oh!

sonarqubecloud Bot commented Oct 19, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

brettheap commented Oct 18, 2026 • edited by sourcery-ai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The whole-manifest YamlError words (U119, U151)

Tests

What it cannot tell

Choices for the reviewer

Shared files

The run and the mutants

Round 1 (lane 5's review, issuecomment-6253381140)

Summary by Sourcery

Uh oh!

sourcery-ai Bot commented Oct 18, 2026

Reviewer's Guide

Sequence diagram for family init YAML reader refusal

File-Level Changes

Assessment against linked issues

Possibly linked issues

Interacting with Sourcery

Customizing Your Experience

Getting Help

Uh oh!

brettheap commented Oct 18, 2026

Findings

Checked and true

Could not verify

Checklist candidates

Uh oh!

brettheap commented Oct 18, 2026

Uh oh!

brettheap commented Oct 18, 2026

The items

Measured

Merge-trees of b8e62456, all clean

Uh oh!

brettheap commented Oct 19, 2026

Findings

My four NITs from the first review

Checked and true

Could not verify

Uh oh!

sourcery-ai Bot commented Oct 19, 2026

Uh oh!

sonarqubecloud Bot commented Oct 19, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

brettheap commented Oct 18, 2026 •

edited by sourcery-ai Bot

Loading

The whole-manifest `YamlError` words (U119, U151)

Merge-trees of `b8e62456`, all clean