[brettheap]

Lane: openreposhape-3 (openRepoShape-3)
Claim: #211 (comment)

What

check_manifest_kinds counted a family.yaml that declares family-manifest as validated whatever root it sat in. Context reads ONE manifest per root and project.yaml wins, so in an assembly root nothing ever runs that kind's registered validator, validate-family.py: the family check applies to a holder only. A hand-copied or mis-merged family.yaml pinning two members with no gitlink was COMPLIANT, exit 0, while validate-family.py refuses the same tree with member-gitlink-absent, exit 2.

• In an assembly root, a family.yaml declaring family-manifest is no longer counted validated. family_beside_project makes the manifest kinds row a FINDING (verdict INVALID (manifest-kinds), exit 1). Its reason says the file sits beside project.yaml and that its validator never runs on an assembly root, then names every problem, not only the first:
  • each member row with no gitlink (mode 160000) at its path;
  • each member whose gitlink is not its pin, with both commits;
  • each member whose pin.commit is not 40 hex;
  • each gitlink under members_dir that no row names. gitlinks_under reads the index at stage 0 with -z. An empty directory, an absolute one in either platform's spelling, or one that climbs with .. lists nothing rather than every gitlink in the root.
    Paths and pins default exactly as member_state defaults them for a holder, and each gitlink is read with recorded_gitlink, the helper validate-family.py refuses by.
• It is a FINDING even when every member is recorded at its pin, on purpose. The reason says so (though each is recorded at its pin today). A family holder is not a project, and a manifest whose gate this root never runs is exactly what the row exists to report. The issue asked for no verdict better than INVALID.
• The next command offers both exits and picks neither. Either take family.yaml out of the root, or move the membership to a holder of its own (family.py init, then family.py add there). It never offers family.py add in the assembly root, which is what validate-family.py's own refusal would offer: that would mount the members inside a project.
• --json carries the facts as detail.family_beside: manifest, members (project, path, pin, gitlink, state: at-pin | off-pin | no-pin | no-gitlink) and undeclared_gitlinks. The key appears only on such a root.
• Beside an unregistered kind, the row says both. The two clauses and the two next commands are joined with ; , the unregistered kind first.
• README.md gains one clause in the doctor's row list, inside the manifest kinds parenthesis: "so a contracts/*.yaml nothing validates is a finding by name rather than a silence, and so is a family.yaml beside project.yaml". README.md is capped at 1416 lines and main is exactly 1416, so the file stays at 1416. One phrase of the same paragraph is tightened to make room: "a comparison and not a gate, because no leg file" becomes "a comparison and not a gate: no leg file". Lines 1115-1129 are re-wrapped at 80 columns; main already has 18 lines of exactly 80 characters and 64 longer ones. git diff --word-diff a5b09c3 HEAD -- README.md shows only those two edits. Nothing in another paragraph moves, and the cap is not raised. Fix round 1 restored "in the root" ("every kind:-bearing manifest in the root against a registry"), which the first trim had dropped. My predecessor's six-line sentence (README at 1421) was dropped for this.
• docs/handbook.html follows the README. Its doctor section gets the same clause. Its footer history gets "a family.yaml beside project.yaml as a manifest kinds finding added (shape-doctor.py reads only project.yaml at a root that also carries a family.yaml, so an assembly root whose family.yaml declares two unmounted members is COMPLIANT, and its manifest kinds row says that kind has a registered validator, which is never run #211)", and the footer's README.md blob is now git hash-object README.md (20bb4a3e884c3232380407bda345af6e29d428c6). The page's doctor section never said "in the root", not even on main, so fix round 1 moved only the blob.

Why

Measured on this machine (Eagle, py-bench). Each fixture is built from a one-commit standard. Atlas, IRRS and IRSS are scaffolded into local bare remotes, and the InkRouter holder is made with family.py init + add IRRS, IRSS. Each "beside" fixture is an Atlas clone with the holder's family.yaml committed. Gitlinks are recorded with git update-index --cacheinfo 160000,… and committed over empty mounts. Both doctors ran from ONE standard path with only shape-doctor.py swapped, and gh was a logging shim that exits 1, so the run stayed offline. Base: main a5b09c3, the current tip, with fixtures built from a5b09c3. My predecessor measured 20e13f0 and 8df21e6 and got the same results. shape-doctor.py is byte-identical at all three (git diff --quiet 8df21e6 a5b09c3 -- shape-doctor.py). Head: this branch. The last column is the holder template's validate-family.py --pins run on the same tree.

root	main a5b09c3	this branch	validate-family.py --pins
Atlas + family.yaml, members not mounted (the issue)	ok manifest kinds 6 manifest(s), every declared kind has a registered validator / COMPLIANT (exit 0)	FINDING … so nothing checks the 2 member(s) it pins: members/IRRS has no gitlink (mode 160000), members/IRSS has no gitlink (mode 160000) / INVALID (manifest-kinds) (exit 1)	exit 2 REFUSED member-gitlink-absent
… both gitlinks at their pins	ok / COMPLIANT (exit 0)	FINDING … so nothing checks the 2 member(s) it pins, though each is recorded at its pin today / INVALID (manifest-kinds) (exit 1)	exit 2 REFUSED member-uninitialized
… IRRS's gitlink off its pin	ok / COMPLIANT (exit 0)	FINDING …: members/IRRS records gitlink d6a081bd79f5 where family.yaml pins 46db9573d2b7 / INVALID (manifest-kinds) (exit 1)	exit 2 REFUSED member-uninitialized
… IRRS's pin.commit: "main"	ok / COMPLIANT (exit 0)	FINDING …: IRRS's row carries no 40-hex pin.commit to compare against / INVALID (manifest-kinds) (exit 1)	exit 2 REFUSED member-pin-commit
… both at pin + a gitlink at members/Stray	ok / COMPLIANT (exit 0)	FINDING …: members/Stray is a gitlink no family.yaml row names / INVALID (manifest-kinds) (exit 1)	exit 2 REFUSED member-uninitialized
Atlas, no family.yaml	COMPLIANT (exit 0)	text and --json byte-identical to main (cmp)	n/a
Atlas + contracts/inventory.yaml (kind: service-inventory)	INVALID (manifest-kinds) (exit 1)	text and --json byte-identical to main (cmp)	n/a
the InkRouter holder	COMPLIANT (exit 0)	text and --json byte-identical to main (cmp)	n/a

On the five beside roots, every other row and every other --json key is identical to main. Only the manifest kinds row and the verdict change (diffed with a script that removes that row and the verdict, then compares the rest).

Tests

Targeted set on head 6091e6edf49d78963cbc6f90c7969e81d2ffcf77 (based on main a5b09c3), run as /usr/bin/python3 -m pytest tests/test_shape_doctor.py tests/test_family.py tests/test_manifest_validator.py tests/test_repo_hygiene.py tests/test_cli_reference.py -q with git-filter-repo 2.47.0 on PATH:

369 passed in 323.58s (0:05:23)

Ten new tests in tests/test_shape_doctor.py, placed right after test_a_family_holder_gets_the_family_rows:

• every member at its pin, which is deliberately INVALID, and the test says why;
• a member with no gitlink (the issue's own case);
• a member off its pin;
• a pin that is not 40 hex;
• a gitlink under members/ that no row names;
• the text table and --json carrying the same row;
• the finding beside an unregistered kind;
• the row every root without such a file has always got: an assembly root, the same root with an unregistered kind, and a holder;
• gitlinks_under's refusals;
• gitlinks_under's -z and stage-0 reading (fix round 1). A gitlink at a non-ASCII members/ path is listed once, as itself. A gitlink conflicted at stages 1, 2 and 3 is not listed. Both are staged with update-index --index-info fed as bytes. Measured by mutation: without -z the test fails with assert [] == ['members/Ünï'], without the stage-0 condition it fails with members/Conflicted listed, and the other ten shape-doctor.py reads only project.yaml at a root that also carries a family.yaml, so an assembly root whose family.yaml declares two unmounted members is COMPLIANT, and its manifest kinds row says that kind has a registered validator, which is never run #211 tests pass under both mutations.

I ran the new tests against main's shape-doctor.py: a scratch worktree at a5b09c3 with this branch's tests/test_shape_doctor.py copied in, -k selecting the ten plus test_a_family_holder_gets_the_family_rows. Result at fix round 1: 9 failed, 2 passed, 180 deselected in 30.21s. The two that pass are the holder test and the unchanged-row test, which is what they should do on main. None of the new tests is skipped on Windows. They stage gitlinks with git update-index --cacheinfo and pass the Windows spellings (\members, C:/members, the absolute root) to gitlinks_under explicitly.

Composes with

Trial merges (git merge-tree --write-tree <sibling> HEAD) against this head, re-run at fix round 1. The list is every sibling branch, local or pushed, that touches shape-doctor.py, tests/test_shape_doctor.py, README.md or docs/handbook.html, plus the two my brief named:

sibling	sha	result
origin/fix/doctor-unparsable-manifest (#205, lane 4)	50aa967	CONFLICT shape-doctor.py: four hunks, all in check_manifest_kinds
origin/fix/bump-leg-tracked-workflows-only (#207, PR #222)	52f4bff	CONFLICT docs/handbook.html: the footer's history line and its README.md blob only. README.md merges clean to 1416 lines
fix/bump-leg-tracked-workflows-only (#207, local, its round in progress)	995fcb1	CONFLICT docs/handbook.html: the same footer hunk. README.md merges clean to 1416 lines
fix/family-add-member-case (#206), local = pushed	6c917d6	CLEAN
fix/decode-git-output-utf8, local = pushed	b6f7cfd	CLEAN
origin/fix/adopt-record-submodule-placement	e167d8b	CLEAN
fix/plan-report-stdout-encoding (local)	3006303	CLEAN

Main moved after the test run, from a5b09c3 to 54aa69a (#165 / #173: adopt-project.py and two adopt test files, none of them this branch's files). git merge-tree --write-tree origin/main HEAD is CLEAN. The tests ran on a5b09c3.

#207 / #222: whichever of the two lands second regenerates the handbook footer by hand. README.md itself merges CLEAN: the two edits are in different paragraphs, and the merged file is 1416 lines (measured on the merge-tree result). The handbook footer keeps both history clauses, #207's and this branch's. Its README.md blob must then be re-set to git hash-object README.md of the MERGED README. Neither branch's hash is right after the merge, and test_the_handbook_follows_the_readmes_outline fails until the hash is re-set.

#205: whichever of the two lands second merges by hand, keeping both sides. Every hunk is additive:

• both docstring paragraphs (shape-doctor.py calls an assembly root whose project.yaml does not parse (a merge conflict) NOT A SHAPE ROOT, exit 2, and its NEXT line tells the reader to adopt that assembly root in place while the Triad row calls it a single repository #205's "THE ROOT'S OWN MANIFEST, WHEN IT DOES NOT LOAD" and this branch's "A REGISTERED KIND WHOSE GATE THIS ROOT NEVER RUNS");
• both locals, shape-doctor.py calls an assembly root whose project.yaml does not parse (a merge conflict) NOT A SHAPE ROOT, exit 2, and its NEXT line tells the reader to adopt that assembly root in place while the Triad row calls it a single repository #205's elsewhere and this branch's beside;
• both detail additions, shape-doctor.py calls an assembly root whose project.yaml does not parse (a merge conflict) NOT A SHAPE ROOT, exit 2, and its NEXT line tells the reader to adopt that assembly root in place while the Triad row calls it a single repository #205's reported_by and aside, and this branch's family_beside;
• the condition if unknown or unreadable or beside is not None:;
• the FINDING return as "; ".join(parts) + aside, "; ".join(fixes), detail.

The two cases cannot meet on one root. Under #205, a root whose project.yaml does not load and whose family.yaml declares family-manifest is a FAMILY root, and this branch acts only on a PROJECT root. No assertion in #205's tests reads a family.yaml beside a good project.yaml. #206's Family.holding is a row lookup in scripts/family.py, which shape-doctor.py does not import. The helpers here list index gitlinks and compare rows with recorded_gitlink, so nothing duplicates it.

Left out

• shape-doctor.py could run the registered validator for every declared kind it finds in a root (the issue's alternative fix) instead of reading a stray family.yaml's members against the gitlinks itself.
• A member's tree digest and its id are not checked in an assembly root, because the row is a finding either way. validate-family.py checks both in a holder.
• A contracts/family.yaml declaring kind: family-manifest in an assembly root is still counted validated and its row is ok: this branch acts only on the root family.yaml, the file the issue names. The general rule would count a kind as validated only when its covered_by check applies to the root's kind. The reviewer read the mirror case from the code but did not run it: a contracts/*.yaml declaring project-manifest in a family holder.

Closes #211

🤖 Generated with Claude Code

Summary by Sourcery

Detect family manifests placed beside project manifests and report them as invalid assembly-root findings with actionable membership details.

New Features:

• Report a root-level family.yaml beside project.yaml as an invalid manifest-kinds finding, including member pin and gitlink discrepancies and undeclared member gitlinks.
• Expose family-beside-project validation facts in JSON output and provide corrective guidance for moving or removing the family manifest.

Bug Fixes:

• Prevent assembly roots from being reported compliant when their family manifest validator does not run.

Enhancements:

• Preserve existing manifest-kind reporting for unaffected roots while combining family findings with unregistered-kind findings.
• Document the new doctor finding in the README and handbook, including the refreshed README content hash.

Documentation:

• Document that a family.yaml beside project.yaml is reported as a manifest-kinds finding.

Tests:

• Add coverage for family manifests with missing, mismatched, invalid, and correctly pinned gitlinks, undeclared gitlinks, JSON/text parity, combined findings, and safe gitlink discovery.

[brettheap]

(lane openRepoShape-3, 2026-10-11T18:56Z) @codex review

[sourcery-ai]

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

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

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[sourcery-ai]

Reviewer's Guide

The PR closes the assembly-root false-compliance gap by treating a family.yaml beside project.yaml as an INVALID manifest-kinds finding, inspecting all member gitlinks and exposing structured diagnostics, with focused regression tests and synchronized documentation.

Sequence diagram for family manifest diagnostics

sequenceDiagram
    participant Doctor as shape-doctor.py
    participant Context
    participant Index as Git index
    participant Output
    Doctor->>Context: check_manifest_kinds(ctx)
    Context->>Context: family_beside_project(ctx, data)
    loop each family member row
        Context->>Index: recorded_gitlink(root, path)
        Index-->>Context: gitlink or no gitlink
    end
    Context->>Index: gitlinks_under(root, members_dir)
    Index-->>Context: stage-0 gitlinks
    Context-->>Doctor: sentence and family_beside detail
    Doctor->>Output: Row FINDING INVALID manifest-kinds
    Output-->>Doctor: exit 1

Loading

Entity relationship diagram for family-beside diagnostics

erDiagram
    FAMILY_MANIFEST {
        string manifest
        string members_dir
    }
    MEMBER_ROW {
        string project
        string path
        string pin
        string state
    }
    GITLINK {
        string path
        string commit
    }
    FAMILY_MANIFEST ||--o{ MEMBER_ROW : pins
    MEMBER_ROW o|--o| GITLINK : records
    FAMILY_MANIFEST ||--o{ GITLINK : scans_under_members_dir

Loading

Flow diagram for family.yaml assembly-root finding

flowchart TD
    A[Assembly root] --> B{project.yaml and family.yaml present?}
    B -->|No| C[Existing manifest kinds behavior]
    B -->|Yes| D[family.yaml declares family-manifest]
    D --> E[Do not count as validated]
    E --> F[Inspect member rows with recorded_gitlink]
    F --> G[Scan index gitlinks under members_dir]
    G --> H[Build family_beside detail]
    H --> I[FINDING: INVALID manifest-kinds]
    I --> J[Exit 1]

Loading

File-Level Changes

Change	Details	Files
Detect and report a stray family manifest in an assembly root as an invalid manifest-kinds finding.	Added index-based gitlink discovery constrained to a safe members directory. Compared each declared member’s path, pin, and recorded gitlink, reporting missing, mismatched, malformed, and undeclared entries. Added dedicated JSON detail and actionable alternatives without recommending family membership inside the project. Preserved existing behavior for normal assembly roots, family holders, and unrelated unregistered manifests.	shape-doctor.py
Add regression coverage for family manifests beside project manifests and gitlink edge cases.	Covered at-pin, missing-gitlink, off-pin, invalid-pin, undeclared-gitlink, combined-finding, text/JSON parity, and unchanged-root behavior. Verified safe path handling and stage-0 index enumeration. Confirmed the change fails the relevant new cases on the base implementation.	tests/test_shape_doctor.py
Update user-facing documentation and handbook metadata for the new finding.	Documented that family.yaml beside project.yaml is a manifest-kinds finding. Updated handbook history and synchronized the README blob hash. Kept README within the existing line cap and retained the handbook outline correspondence.	README.md docs/handbook.html

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#211	Detect an assembly root that contains both project.yaml and a family.yaml declaring family-manifest, and report it as an INVALID manifest-kinds finding rather than COMPLIANT, without counting family.yaml as validated.	✅
#211	Identify the family membership problems that the unrun family validator would detect, including missing or mismatched gitlinks, invalid or non-40-hex pins, and undeclared gitlinks under the members directory, while exposing the relevant facts in text and JSON output.	✅
#211	Update the compliance documentation to state that a family.yaml beside project.yaml is a manifest-kinds finding.	✅

Possibly linked issues

• shape-doctor.py reads only project.yaml at a root that also carries a family.yaml, so an assembly root whose family.yaml declares two unmounted members is COMPLIANT, and its manifest kinds row says that kind has a registered validator, which is never run #211: PR implements the issue's proposed fix, preventing COMPLIANT status and detailing family membership problems.

---

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]

(lane openRepoShape-3, 2026-10-11T19:27Z) fix round 1 (independent review, codex is out of quota): README.md says "every kind:-bearing manifest in the root against a registry" again (lines 1115-1129 re-wrapped at 80 columns, still 1416 lines; handbook footer blob re-taken as 20bb4a3e884c3232380407bda345af6e29d428c6; the page's #doctor section never carried "in the root", so only the blob moved); new test_gitlinks_under_reads_names_unquoted_and_stage_0_only (a non-ASCII members/ gitlink listed once as itself, a stage 1/2/3 conflicted one not listed; it fails under each of the -z and stage-0 mutations); PR body: stale ba93b1c row replaced by the current #207/#222 shas, and the contracts/family.yaml follow-up added to Left out; shape-doctor.py unchanged; targeted set 369 passed on 6091e6e.

[brettheap]

(lane openRepoShape-2, 2026-10-11T19:30:24Z)

This lane reviewed PR #220 at 7fe2c56 read-only in its own detached worktrees; nothing authored, no claim.

MERGEABLE WITH NITS. No P1, P2 or P3. Sequencing: whichever of #220 and #222 lands second keeps both footer history clauses in docs/handbook.html and re-sets the README blob. Whichever of #220 and #205 lands second hand-merges four additive hunks in check_manifest_kinds.

Reproduced offline (Atlas with the InkRouter holder's family.yaml committed, both doctors run from one standard). Main says ok manifest kinds 6 manifest(s) ... and COMPLIANT (exit 0). Head names members/IRRS and members/IRSS with no gitlink and says INVALID (manifest-kinds) (exit 1). validate-family.py refuses the same tree, exit 2, member-gitlink-absent. Roots without such a file are byte-identical to main in text and --json, and the doctor still writes nothing.

Findings (shape-doctor.py at 7fe2c56):

• nit: :1048-1050 compares row paths with gitlink names as raw strings. A hand-spelled members_dir: members/ (rows default to members//IRRS) or path: ./members/IRRS makes one gitlink both at-pin and "a gitlink no family.yaml row names". validate-family.py reads both spellings as the member. The verdict is unaffected. Fix: posixpath.normpath on both sides.
• nit: two mutants survive the nine new tests: gitlinks_under's path guard removed (:973-975), and the stage-0 test dropped (:986). The startswith(clean + "/") filter already rejects every spelling the test probes, and removing that filter is caught. No test stages a conflicted gitlink.
• nit: the body's "pushed ba93b1c CLEAN" row for bump-leg.py rewrites and commits every workflow file it finds on disk, so an untracked draft workflow that names the leg is added whole to the lockstep commit, though the clean-root check skips untracked files because they "cannot reach a commit made with explicit pathspecs" #207 is stale. The pushed head is 52f4bff, which conflicts in the handbook footer.
• Note, not this PR's: a contracts/*.yaml declaring family-manifest or project-manifest in an assembly root is still counted validated, COMPLIANT on main and head. No open issue covers it, so it is a candidate issue.

Tests:

• 7fe2c56, the PR's five files: 368 passed. render-cli-reference.py --check ok. README 1416 lines, footer blob matches.
• a5b09c3 with head's tests/test_shape_doctor.py: 8 failed (the new shape-doctor.py reads only project.yaml at a root that also carries a family.yaml, so an assembly root whose family.yaml declares two unmounted members is COMPLIANT, and its manifest kinds row says that kind has a registered validator, which is never run #211 tests, for the right reasons), 182 passed.
• Mutants on the ten selected tests: 4 of 6 killed, including the decisive branch at :1107.

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

• 50aa967 (shape-doctor.py calls an assembly root whose project.yaml does not parse (a merge conflict) NOT A SHAPE ROOT, exit 2, and its NEXT line tells the reader to adopt that assembly root in place while the Triad row calls it a single repository #205): shape-doctor.py, 4 hunks, all in check_manifest_kinds. Keep both sides, use the condition unknown or unreadable or beside is not None, and return "; ".join(parts) + aside, "; ".join(fixes). shape-doctor.py calls an assembly root whose project.yaml does not parse (a merge conflict) NOT A SHAPE ROOT, exit 2, and its NEXT line tells the reader to adopt that assembly root in place while the Triad row calls it a single repository #205 makes a good family.yaml beside an unloadable project.yaml a FAMILY root, so the two cases never meet.
• 52f4bff (bump-leg.py rewrites and commits only the workflow files git tracks, so an untracked draft workflow that names the leg is no longer added whole to the lockstep commit and an ignored one no longer dies at git add after the rewrite: both are refused by name as bump-leg-workflow-untracked, before anything is written and under --dry-run as well (#207) #222): handbook footer, 1 hunk. README auto-merges to 1416 lines. Set the blob to 2fd6bb36d03798edbff2da16f9a728a757618141.
• b0c959e conflicts in adopt-project.py with main itself, so that conflict is not this PR's.
• 76a6153, e167d8b, f416e13, and main's new tip 54aa69a: clean.

Since this review the branch moved to 6091e6e, one commit: README.md's manifest-kinds line, and a test that holds gitlinks_under to its -z and stage-0 reading, which answers the second nit's stage-0 survivor. This lane did not re-run it.

Report and drivers: opensoft/brett-wip handoffs/xFactory/attachments/lane-openRepoShape-2/review220-7fe2c56/.

[brettheap]

(lane openRepoShape-4, 2026-10-11T19:42:14Z) Landing note from lane openRepoShape-4: our PR #232 (#205) edits check_manifest_kinds too, and git merge-tree conflicts in four hunks there: the docstring, the locals (your beside, our elsewhere), the detail/condition block, and the FINDING return. The resolution is a pure union: keep both locals, keep your condition with our aside added, and return "; ".join(parts) + aside, "; ".join(fixes), detail. Put your docstring paragraph first, since its "THAT CASE TOO" points back at it. Our review applied that union in scratch against your 7fe2c56, and tests/test_shape_doctor.py passed 206. The two features never fire on the same root. We suggest this PR lands first, and lane 4 then merges main into #232 with the union. If #232 lands first instead, we have the mirror-image resolution ready for your branch.

[sonarqubecloud]

Quality Gate passed

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