Skip to content

shape-doctor.py flags a submodule kept in a leg under a root-ruled path (.cursor, .specify/vendored) as MISPLACED, though #166 requires a leg for it #176

Closed

Description

@brettheap

(lane openRepoShape-1, 2026-10-09T02:28:39Z)

What is wrong. shape-doctor.py's placement audit classifies each leg path by glob with contracts/path-classification.yaml. It cannot tell a gitlink from a directory. An assembly adopted the way #166 requires keeps a vendored submodule under a root-ruled path, such as .cursor or .specify/vendored, in a LEG, because the assembly root keeps no source submodule. The doctor then reports:

FINDING placement ... code/.cursor: root by rule root-assistant-instructions; code/.specify/: root by rule root-spec-kit

It exits 1 (MISPLACED) over a placement that adopt-project.py itself required. main's doctor reports the same row.

Found by the #166 round-2 writer (branch fix/adopt-split-submodule-plan, head 326fb25).

What would fix it. The doctor's placement walk reads each leg's tree modes, as adopt-project.py's new ask_about_submodules does for plan. A path covering a gitlink is a note, or asks the ambiguous-gitmodules question, never root by rule. A test covers a leg holding a submodule at .cursor and at .specify/vendored.

What must not break. Every other placement verdict, and the doctor's output on a project with no submodules.

Activity

  1. brettheap commented on Oct 9, 2026

    @brettheap
    ContributorAuthor

    CLAIMED — lane openRepoShape-2, session 3a133e77-1ea9-415a-a670-47833e18c505@Eagle, 2026-10-09T03:37:20Z, for #176

    Logged in lanes/log/openRepoShape-2.md at ee4636bf588d6279076965feb4d103b10df9cd3c.

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

    1. existing `CLAIMED —` comments on opensoft/openRepoShape#176:
       none
    2. `gh pr list --repo opensoft/openRepoShape --state all --search "#176"`, kept where the row or its body names `#176`:
       none
    3. `git ls-remote --heads git@github.com:opensoft/openRepoShape` branches naming `176` as a whole token:
       none
    
  2. added 2 commits that reference this issue on Oct 9, 2026
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

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions