fix: make the plugin/skill validators work on Windows (6 failing tests -> 0)

[EazyHood]

On a clean Windows checkout, pnpm -r test fails with six failures — all of them valid files reported as invalid, for reasons unrelated to their contents.

✖ current Cursor plugin metadata is valid
    plugin/rules/call-e-safety.mdc must start with YAML frontmatter.
    plugin/rules/call-e-safety.mdc must contain alwaysApply: true.
✖ current Codex plugin metadata is valid
✖ reports a missing bundled skill
✖ reports missing skill UI metadata
✖ current Claude plugin metadata is valid          (+1 more)

The file it rejects does start with frontmatter. Three separate causes.

1. Frontmatter delimiters assumed LF

/^---\n([\s\S]*?)\n---\n?/u

Git on Windows checks out CRLF by default (core.autocrlf=true) and the repo ships no .gitattributes, so files arrive as ---\r\n and the delimiter never matches. The same pattern appears in five validators: claude-plugin, codex-plugin, cursor-plugin, openclaw-cli-skill, skills-sh-skill.

2. Field captures swallowed the carriage return

/^name:\s*([^\n]+)\s*$/mu     // captures "true\r", not "true"

so alwaysApply: true compared unequal to true.

3. Failure messages embedded native path separators

Messages are built from path.join(), so they read skills\calle on Windows while the tests — and CI log greps, and the docs — expect skills/calle:

assert.ok(failures.some((failure) => failure.includes("skills/calle")))

Fix

• accept \r?\n in the delimiters
• capture [^\r\n]+ for field values
• add displayPath(), which renders paths with forward slashes for display only — filesystem access still uses the native separator
• add .gitattributes (* text=auto eol=lf) so CRLF never enters a checkout in the first place

All three are no-ops on POSIX: \r? matches nothing against LF, and displayPath() is identity where path.sep is already /.

Tests

Four new regression cases feed CRLF content directly, so a revert is caught on any platform rather than only on Windows.

	before	after
Windows	6 failing	111 passing, 0 failing

Why this is worth landing now

The hackathon requires every participant to open a PR against this repo. Any entrant on Windows hits a red test suite on their first pnpm install && pnpm test, before writing a line of their own code.

---

Disclosure: written with AI assistance. Every failure above was reproduced on my own Windows 11 machine, and I take responsibility for the change.

[EazyHood]

Correcting my own numbers — I re-ran against a pristine clone rather than trusting my working copy, and the count in the description is wrong in a way that understates the problem.

What actually happens on a clean Windows checkout:

pnpm -r test
  packages/codex-plugin    3 failing
  packages/cursor-plugin   1 failing
  -> run aborts:  4 failing, 27 passing, 31 of 111 tests executed

It is 4 failures, not 6, because pnpm -r stops there — claude-plugin, openclaw-cli-skill, skills-sh-skill and cli never run at all. Fix those four and claude-plugin surfaces 2 more with the same root cause, which is where my original count of 6 came from. Six tests are affected in total; you only ever see four at a time.

The practical shape is worse than "some tests fail": a contributor on Windows gets an aborted suite with two thirds of it unexecuted, so the real state of their checkout is invisible to them.

After the patch: 111 passing, 0 failing, whole suite runs.

Everything else in the description stands — the three causes, the .gitattributes root cause, and the POSIX no-op guarantee are unchanged. Apologies for the sloppy figure; I had summed two runs taken at different points instead of measuring once from clean.

[EazyHood]

One follow-up worth naming, because without it this PR fixes the symptom and the cause stays put.

.github/workflows/ci.yml:11 is runs-on: ubuntu-latest — one job, no matrix. release.yml is the same. So nothing in this repo has ever executed on Windows, which is why all three causes here went unnoticed rather than being caught the day they were introduced.

That matters more than it would for an internal tool, because @call-e/cli is published:

@call-e/cli   0.3.7 on npm, 605 downloads in the last month
              "bin":     { "calle": "./bin/calle.js" }
              "engines": { "node": ">=22" }      <- no "os" field

With no os field npm installs it on Windows without warning, so the package offers Windows support that CI never checks.

Once this lands the suite is 111 passing on Windows, which means the matrix can go in as a required check straight away rather than as a known-broken one:

jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, windows-latest]
    runs-on: ${{ matrix.os }}

Happy to open that as a small separate PR the moment this one merges — I deliberately have not, because on today's main it would be red on arrival and that is noise in your queue rather than information you don't already have from this PR.

If Windows support is not actually intended, the clean alternative is to say so in metadata: "os": ["!win32"] in the CLI's package.json makes npm refuse the install with a clear message instead of letting it fail later and quietly. Either answer works; I mention it so the choice is explicit rather than implied by an absent CI job.

Disclosure: written with AI assistance; the CI, npm and download figures were checked directly and I take responsibility for them.

[Ray-56]

Reviewed for repository layout, path handling, supply-chain impact, and cross-platform behavior. The change is limited to repository validation tooling and checkout line-ending policy, does not alter published package contents or runtime behavior, and passes the full local check, test, and pack dry-run suite. Approved.