Skip to content

shape-doctor.py members row: its green note says make siblings places every member with no working clone, a directory make siblings refuses included, so one row says both that it places IRRS and that it leaves IRRS exactly as it is #669

Closed

Description

@brettheap

Goal: the members row says, member by member, what make siblings would do with the directory beside the holder, as the holder's scripts/siblings.py decides it. It never says make siblings places a member it will refuse.

Filed by lane openRepoShape-3 on Brett Heap's word of 2026-10-16T12:24:41Z ("give #460 to lane 3").

What happens:

Where it is (d4a7fab):

  • shape-doctor.py:
    • members_verdict, :7289-7521 (the stranger sentence at :7323-7329, the note at :7497-7518);
    • check_members, :7551-7578;
    • working_clone, :7128-7186;
    • member_state, :7189-7231;
    • is_this_member, :6913-6938.
  • The rules it must agree with, in templates/family-root/scripts/siblings.py: place at :529-600, verify_sibling at :460-502, project_id at :449, and parent_folder_warning's exact compare at :969.

The change:

  • Record what stands at ../<Project>. member_state takes the slot's state in place's order:

    1. the holder itself;
    2. a non-empty folder with no .git;
    3. absent or empty;
    4. a repository whose origin is not the member's;
    5. one at the right origin with another id;
    6. one at the right origin with no readable manifest;
    7. the working clone.

    The --json entry carries this state as a new key, so a caller need not parse prose.

  • Say per member what make siblings does.

    • The "places them" note names only the absent and empty slots, and keeps its folder condition.
    • Every other member gets one sentence in make siblings's own word (WRONG ORIGIN, NOT A CLONE, WRONG PROJECT, IS THE HOLDER, or "fetched as the member") saying what it does. This holds on the green and the red path alike, as the stranger sentence does today.
    • CLONE FAILED is not predicted.
  • Say "exactly". The folder condition reads "named exactly after its repository (case included)", in the note and in the stranger sentence.

  • Document what the doctor restates. The doctor restates place's slot order but not the folder rule, as working_clone restates verify_sibling's questions (shape-doctor.py: the members row calls a beside-the-holder repository the working clone on its project id alone, where the family's own verifier also requires the origin #146). Say so in the docstring.

  • Nothing else moves. without_working_clone keeps its meaning, and no verdict, exit code or NEXT changes.

Tests (tests/test_shape_doctor.py, the #146 and #605 sections, :3610-3725):

  • Invert test_the_stranger_note_says_from_which_folder_make_siblings_calls_it: the stranger is not in the "places them" note.
  • One row per slot state, each asserting the sentence, the --json key, ok and COMPLIANT.
  • An agreement test: for each state, the holder's own scripts/siblings.py --dry-run, run from its family folder, gives the doctor's word for that member.
  • PLACES_NOTE and STRANGER_NOTE gain "exactly".

From #460, #460 (comment) (L16, and the doctor's half of L21)

🤖 Generated with Claude Code

Activity

  1. added this to the v1.1.0 milestone on Oct 16, 2026
  2. brettheap commented on Oct 16, 2026

    @brettheap
    ContributorAuthor

    CLAIMED — lane openRepoShape-3, session b30e8b49-f249-4668-adb1-1dbfa93c09e1@Eagle, 2026-10-16T12:57:19Z, for #669

    Logged in lanes/log/openRepoShape-3.md at 7d3a5e7e7fd4d3ae5c9d3450344b92ed042488d5.

    The three reads (lane-collision-protocol Rule 1):

    1. existing `CLAIMED —` comments on opensoft/openRepoShape#669:
       none
    2. `gh pr list --repo opensoft/openRepoShape --state all --search "#669"`, kept where the row or its body names `#669`:
       none
    3. `git ls-remote --heads git@github.com:opensoft/openRepoShape` branches naming `669` as a whole token:
       none
    
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions