adopt-project.py and scaffold-project.py: a --pin naming an annotated tag's object id is written as the pin's commit:, under the pin file's "A COMMIT, NEVER A TAG" #651

Lane: openreposhape-1 (openRepoShape-1)

plan and the scaffold should refuse an annotated tag's own object id as a pin's commit, or peel it to the commit it names, as bump-leg.py has since #534/#561. A committed pin then keeps its own file's promise, "A COMMIT, NEVER A TAG". The riders in the same pin block ride with it.

From lane 1's triage of 2026-10-15, D1, approved by Brett Heap at 2026-10-16T11:21:17Z ("Approve all (Recommended)"). One pull request covers the lines below.

Parent: #457. Milestone: v1.1.0.

Lands after: nothing. No open PR edits adopt-project.py's pin block (lines 250-860 on 396c0ff).

Effort: M. Platform: all.

Lane openRepoShape-1 claims it at filing; see its CLAIMED comment.

Why this is P2. git rev-parse v1.2 prints an annotated tag's own id, so the mistake is plausible, and nothing asks about it. declared_pin_values, in scripts/shape_materialize.py and shared by both tools, reads the digest through ls-tree, which peels the tag. COMMIT_RE takes any 40 hex. The committed pin then breaks its own file's promise, and only bump-leg.py peels such an id (#534/#561).

The fix. Ask cat-file -t in the --pin-source clone, and peel the id or refuse it. On the gh path, ask the forge. #589's recheck in check asks the same of the recorded clone.

Lines

• L1-01 (P2): a pin's commit: can be an annotated tag's own object id. plan records it and execute writes it under revision_kind: commit, though the pin file says "A COMMIT, NEVER A TAG"; validate-pins.py passes it because ls-tree peels the tag. Where: declared_pin_values and COMMIT_RE (scripts/shape_materialize.py, scripts/repo_shape.py). On 396c0ff, read: no type check in declared_pin_values. Read again on 7ba64f0: unchanged. The line measured it on d158a21 and main f6eaab7; the scaffold's --pin was not run. (source)

Rides along (backlog; tick it here if the same change covers it)

• L1-04: git config --local in a non-repository directory inside a partial-clone repository reads the parent's config, so a non-clone there gets the partial-clone NOTE, not the unreadable finding (the safe side). Where: _a_partial_clone (adopt-project.py). Fix: ask whether the path is the clone's top level before reading its config. On 396c0ff, read: git config --local in the path. Read again on 7ba64f0: unchanged. (source)
• L1-05: optional nits on adopt-project.py: check recomputes each pin's digest at the plan's commit in the clone plan read it from, where that clone is still on the machine and is no partial clone, so a commit or a digest edited into the plan no longer checks ok and reaches the root as adoption verified over a red validate-pins.py (#449) #589 at 006caf4. _a_partial_clone writes the literal "config" beside the GIT_CONFIG constant. One comment says every sentence naming a relative clone says where it is read, which check's write contracts/<product>-pin.yaml line does not. No test covers "read from this directory". On 396c0ff, read: the literal "config" at :682. Read again on 7ba64f0: the literal is still there. (source)
• L1-06: a hand-edited pins: entry whose file is the shape's pin (product: Shape, already plan-pin-collides), with contracts/shape-pin.yaml kept, makes check print plan-root-holds-pin twice for one kept file. Where: _pin_files. Fix: dedupe by path. On 396c0ff, read: _pin_files dedupes by product. Read again on 7ba64f0: unchanged. The line measured it on 17dd55c. (source)
• L1-07: keeping both contracts/shape-pin.yaml and shape/contracts/shape-pin.yaml gives two findings for one cause (adopt-project.py check passes a plan that keeps the source's own shape/ in the root, and place() then writes the shape's collision copy onto it after both legs are pushed: a real shape/README.md is overwritten while execute prints "nothing was overwritten" and ends adopt-lost, and a shape/Makefile/ directory or a file named shape is a traceback #262's plan-root-blocks-shape-copy, which main gives alone, plus plan-root-holds-pin), because SHAPE_PIN is one of assembly_root_paths(). Fix: one finding for one cause. Not re-checked since the line measured it on 17dd55c. (source)
• L1-63: the docstring of test_a_path_kept_at_the_shapes_pin_is_found_and_refused_before_any_leg says "place finds it there", which is not true of the case-twin row on Linux. A nit, at 17dd55c. On 396c0ff, read: test file :123. (source)

Each line above is a line of #457's checklist comment (issuecomment-6200110061). Tick it there too when this closes.