Found in the adversarial review of #120.
Skill has no working way to build $SNAP/claw: CLAW is not under MECHS_ROOT, and its shallow checkout makes the shared-clone recipe fail at the pin
Where: .claude/skills/update-xmech-page/SKILL.md:114
Step 1 says to fetch "$MECHS_ROOT/<Mech>" for each Mech plus culturebotai-claw. Steps 4 and 8 then pass --claw-root "$SNAP/claw" # CLAW cloned at its pin, but no step says where CLAW lives or how that clone is made. On this machine CLAW is not under MECHS_ROOT. It is at /Users/marcin/Documents/VIMSS/ontology/KG-Hub/KG-Microbe/culturebotai-claw, and that checkout is shallow. If you apply step 2's recipe (git clone -q --shared --no-checkout then checkout -q --detach "$sha") to it, git quietly ignores --shared (no alternates file is written) and copies only the local branches. The pin 2637172 is reachable only from origin/main, so the detached checkout fails.
Failure scenario. An agent following the skill runs git -C "$MECHS_ROOT/culturebotai-claw" fetch -q origin and it fails. It finds the real CLAW checkout and reuses the step 2 recipe for CLAW, as the comment on line 114 implies. The checkout dies with fatal: unable to read tree (2637172…). Steps 4 (refresh_manifest.py --claw-root "$SNAP/claw") and 8 (the --check gate) then cannot run as written.
Evidence. ls /Users/marcin/Documents/VIMSS/ontology/Mechs/ lists the ten Mechs and no culturebotai-claw. git -C …/Mechs/culturebotai-claw fetch gives fatal: cannot change to '…/Mechs/culturebotai-claw'. git -C …/KG-Microbe/culturebotai-claw rev-parse --is-shallow-repository gives true, and HEAD is da47953 while origin/main is 2637172. Scratch test: git clone -q --shared --no-checkout <claw> $R/snap/claw && git -C $R/snap/claw checkout -q --detach 2637172e… gives fatal: unable to read tree (2637172e…). The clone has a .git/shallow file, no objects/info/alternates, and count-objects -v shows in-pack: 326264, so it is a full copy, not shared. The same recipe works for CellStructureMech, which is not shallow and whose pin is also only in origin/main: HEAD=42cc23b, clean, 542 records, all tracked. This workaround made it work: git -C $SNAP/claw fetch -q <claw> refs/remotes/origin/main, then checkout. After that, refresh_manifest.py --claw-root $SNAP/claw --check prints Fleet snapshot matches CLAW: 10 members.
Verifier (confirmed, medium). The skill never says where CLAW lives or how $SNAP/claw is built. Step 1's git -C "$MECHS_ROOT/culturebotai-claw" fetch fails because CLAW is not under MECHS_ROOT. It is only at /Users/marcin/Documents/VIMSS/ontology/KG-Hub/KG-Microbe/culturebotai-claw, and that checkout is shallow. Reusing step 2's --shared clone recipe on it fails at the pin 2637172 with fatal: unable to read tree, because the pin is reachable only from origin/main. Steps 4 and 8 therefore cannot be followed as written.
Two routes work, and the skill should spell out one of them:
- cloning the public repo from GitHub at the pin, as CI does;
- the reviewer's fetch of refs/remotes/origin/main followed by the checkout.
The improvisation that fails silently is pointing --claw-root at the shared checkout. Its HEAD is 18 commits behind the pin, and no test ties manifest.json's revision to the CLAW pin in site_audit, so the page would cite a stale commit unnoticed.
This is medium severity: a gap in how reproducible the procedure is. The data in this PR is not affected.
Suggested fix. Add a CLAW sub-step to step 2 that names its source path (a CLAW_ROOT variable, since it is outside MECHS_ROOT). Make it work for a shallow source, e.g. git clone --no-checkout "$CLAW_ROOT" "$SNAP/claw" && git -C "$SNAP/claw" fetch -q "$CLAW_ROOT" refs/remotes/origin/main && git -C "$SNAP/claw" checkout -q --detach "$claw_sha", or clone from GitHub. Change step 1 so it does not fetch at $MECHS_ROOT/culturebotai-claw. Also have the free checks assert that $SNAP/claw HEAD equals the CLAW pin.
Found in the adversarial review of #120.
Skill has no working way to build $SNAP/claw: CLAW is not under MECHS_ROOT, and its shallow checkout makes the shared-clone recipe fail at the pin
Where:
.claude/skills/update-xmech-page/SKILL.md:114Step 1 says to fetch
"$MECHS_ROOT/<Mech>"for each Mech plus culturebotai-claw. Steps 4 and 8 then pass--claw-root "$SNAP/claw" # CLAW cloned at its pin, but no step says where CLAW lives or how that clone is made. On this machine CLAW is not under MECHS_ROOT. It is at /Users/marcin/Documents/VIMSS/ontology/KG-Hub/KG-Microbe/culturebotai-claw, and that checkout is shallow. If you apply step 2's recipe (git clone -q --shared --no-checkoutthencheckout -q --detach "$sha") to it, git quietly ignores --shared (no alternates file is written) and copies only the local branches. The pin 2637172 is reachable only from origin/main, so the detached checkout fails.Failure scenario. An agent following the skill runs
git -C "$MECHS_ROOT/culturebotai-claw" fetch -q originand it fails. It finds the real CLAW checkout and reuses the step 2 recipe for CLAW, as the comment on line 114 implies. The checkout dies withfatal: unable to read tree (2637172…). Steps 4 (refresh_manifest.py --claw-root "$SNAP/claw") and 8 (the --check gate) then cannot run as written.Evidence.
ls /Users/marcin/Documents/VIMSS/ontology/Mechs/lists the ten Mechs and no culturebotai-claw.git -C …/Mechs/culturebotai-claw fetchgivesfatal: cannot change to '…/Mechs/culturebotai-claw'.git -C …/KG-Microbe/culturebotai-claw rev-parse --is-shallow-repositorygivestrue, and HEAD is da47953 while origin/main is 2637172. Scratch test:git clone -q --shared --no-checkout <claw> $R/snap/claw && git -C $R/snap/claw checkout -q --detach 2637172e…givesfatal: unable to read tree (2637172e…). The clone has a.git/shallowfile, noobjects/info/alternates, andcount-objects -vshows in-pack: 326264, so it is a full copy, not shared. The same recipe works for CellStructureMech, which is not shallow and whose pin is also only in origin/main: HEAD=42cc23b, clean, 542 records, all tracked. This workaround made it work:git -C $SNAP/claw fetch -q <claw> refs/remotes/origin/main, then checkout. After that,refresh_manifest.py --claw-root $SNAP/claw --checkprintsFleet snapshot matches CLAW: 10 members.Verifier (confirmed, medium). The skill never says where CLAW lives or how $SNAP/claw is built. Step 1's
git -C "$MECHS_ROOT/culturebotai-claw" fetchfails because CLAW is not under MECHS_ROOT. It is only at /Users/marcin/Documents/VIMSS/ontology/KG-Hub/KG-Microbe/culturebotai-claw, and that checkout is shallow. Reusing step 2's--sharedclone recipe on it fails at the pin 2637172 withfatal: unable to read tree, because the pin is reachable only from origin/main. Steps 4 and 8 therefore cannot be followed as written.Two routes work, and the skill should spell out one of them:
The improvisation that fails silently is pointing --claw-root at the shared checkout. Its HEAD is 18 commits behind the pin, and no test ties manifest.json's revision to the CLAW pin in site_audit, so the page would cite a stale commit unnoticed.
This is medium severity: a gap in how reproducible the procedure is. The data in this PR is not affected.
Suggested fix. Add a CLAW sub-step to step 2 that names its source path (a CLAW_ROOT variable, since it is outside MECHS_ROOT). Make it work for a shallow source, e.g.
git clone --no-checkout "$CLAW_ROOT" "$SNAP/claw" && git -C "$SNAP/claw" fetch -q "$CLAW_ROOT" refs/remotes/origin/main && git -C "$SNAP/claw" checkout -q --detach "$claw_sha", or clone from GitHub. Change step 1 so it does not fetch at$MECHS_ROOT/culturebotai-claw. Also have the free checks assert that$SNAP/clawHEAD equals the CLAW pin.