Skip to content

adopt-project.py check refuses no root-kept symlink at or above a path the shape writes, so a link that dangles or leaves the tree makes execute traceback, or write the shape's files OUTSIDE the assembly, after both leg remotes are pushed #178

Closed

Description

@brettheap

(lane openRepoShape-2, 2026-10-09T03:31:15Z) Found by the delta review of the #167 branch at b635473 (its N3); pre-existing on main 7f84ca4 / b18cca9, unchanged by #167, and distinct from #169 (non-canonical leg paths) and #172 (a mount path colliding with a shape directory). Not claimed.

What is wrong. When the plan keeps a source SYMLINK in the assembly root at or above a path the shape materialises (.gitattributes, .github/, contracts/, scripts/), check says plan ok, both legs are created and pushed, and then place() in scripts/shape_materialize.py (:996 path.exists() is False for a dangling link; :1007 mkdir) either tracebacks or writes through the link:

source link kept at root main b18cca9 #167 b635473
.gitattributes -> nowhere/attrs (dangling, target dir absent) Python traceback (FileNotFoundError) after the legs, exit 1, no split branch same
.github -> tooling/gh with tooling/ sent to a leg traceback (FileExistsError/FileNotFoundError) after the legs same
.github -> spec/ci (into a mount, absent in the leg) traceback after the legs same
.github -> ../outside-ci (relative, leaves the tree) "adoption verified", bootstrap 1, and the shape's validate.yml is WRITTEN OUTSIDE the assembly into <work-dir>/outside-ci/ exit 1 with a correct adopt-shape-file-missing, but the file is still written outside
.github -> /abs/dir (absolute) verified, bootstraps on this machine only; written to /abs/dir exit 1, correct finding; still written outside
.github -> spec (the mount itself) verified, bootstrap 1 exit 2 is in submodule 'spec' after the legs (#167's own N1)

Every row leaves both leg remotes behind, so a corrected re-run meets leg-remote-exists. Driver: tools/s_delta.py {main|wt} D4 D5 D6 D6b D7 D7b under the attachments path below.

What would fix it. check evaluates each root-kept symlink against the planned root tree and refuses one that dangles, leaves the tree (relative .. above the root or an absolute target), or enters a leg mount, with a finding naming the link and its target; execute refuses the same before _create_leg_remotes (the same gate #168 added). The materializer must never write through a link that leads out of the assembly. #169's canonical-path check is the natural home for the leg-path half.

Report and drivers: opensoft/brett-wip handoffs/xFactory/attachments/lane-openRepoShape-2/review167-b635473/ (report.md N3 and section 4c).

Activity

  1. brettheap commented on Oct 9, 2026

    @brettheap
    ContributorAuthor

    CLAIMED — lane openRepoShape-1, session f711ec94-a922-4e5f-8d35-efcfe983caa7@Eagle, 2026-10-09T13:57:48Z, for #178

    Logged in lanes/log/openRepoShape-1.md at a3be0da0366718bdfdaf1e9b43c2fbefcc6e4e77.

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

    1. existing `CLAIMED —` comments on opensoft/openRepoShape#178:
       none
    2. `gh pr list --repo opensoft/openRepoShape --state all --search "#178"`, kept where the row or its body names `#178`:
       none
    3. `git ls-remote --heads git@github.com:opensoft/openRepoShape` branches naming `178` as a whole token:
       none
    
  2. 1 remaining item

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