Summary

The setup script still has multiple raw ln -snf calls in the Pi install path, so the Windows fallback invariant is currently broken.

Repro

cd ~/gstack
bun test test/setup-windows-fallback.test.ts

Current failure

test/setup-windows-fallback.test.ts fails in the "zero raw ln calls outside the helper body and comments" assertion.

The offending raw symlink calls are in setup, mainly around:

• create_pi_runtime_root()
• link_pi_skill_dirs()

Examples flagged by the test:

• ln -snf "$pi_dir/gstack/SKILL.md" "$pi_gstack/SKILL.md"
• ln -snf "$gstack_dir/bin" "$pi_gstack/bin"
• ln -snf "$skill_dir" "$target"
• ln -snf "$pi_dir/gstack-office-hours" "$repo_office_hours_alias"
• ln -snf "$skills_dir/gstack-office-hours" "$office_hours_alias"

Why this matters

The script already defines _link_or_copy() specifically to avoid the Windows behavior where ln -snf can silently create stale file copies instead of real symlinks. The static invariant test is supposed to guarantee every symlink path routes through that helper.

Because these Pi-specific paths bypass the helper, Windows installs are at risk of the same stale-copy / refresh problems the helper was introduced to fix.

Expected fix

Route the Pi install path through _link_or_copy() as well, including:

• runtime root files/dirs created in create_pi_runtime_root()
• skill links in link_pi_skill_dirs()
• the office-hours alias links

After the fix, this should pass again:

bun test test/setup-windows-fallback.test.ts