fix: frontmatter gate crashed on a tracked symlink with an unreachable target

[scott-wueschinski-GTMify]

Found by the gate's own first real CI run, against gtmify-config, where it died with a FileNotFoundError on skills/_gstack-command/SKILL.md.

The cause is a real repo defect, not a CI quirk

That path is a committed symlink whose target is the absolute /Users/scottwueschinski/claude/config/gtmify/skills/gstack/SKILL.md, and it points into skills/gstack/, which that repo gitignores. It resolves only on the machine that created it, and is dangling on the second machine and in CI.

An audit found roughly 145 tracked symlinks in gtmify-config, the large majority with absolute /Users/... targets. That is its own piece of work and is not addressed here.

Why skip rather than fail

Three behaviors were possible and only one is right:

Option	Verdict
Crash	Obviously wrong
Fail	Turns tier A permanently red over a pre-existing problem the gate was not built to solve. A permanently red gate gets ignored within a week
Count, name, exclude from the verdict	Chosen

The summary now states plainly how many files were not assessed and why. A gate that quietly skips work reads as full coverage, which is worse than one that admits a gap.

A dangling symlink still cannot mask a genuine violation elsewhere in the same run. There is a test for exactly that.

Tests

New tests/frontmatter_gate_test.sh, 8 cases, all passing, including the one that crashed:

ok  valid_skill_passes
ok  missing_frontmatter_fails
ok  missing_description_fails
ok  unclosed_frontmatter_fails
ok  dangling_symlink_is_skipped_not_fatal
ok  dangling_does_not_mask_real_failure
ok  nested_agent_docs_are_out_of_scope
ok  repo_with_no_skills_noops

The self-test now iterates tests/*_test.sh instead of naming one file, so a new suite is picked up without editing the workflow. shellcheck clean, junk suite still 35/0.

🤖 Generated with Claude Code