Docs: verify the clean install path on Windows PowerShell

[bitjaru]

Why

StyleSeed's public install path is documented for every supported agent, but the release evidence does not yet include a contributor-readable Windows PowerShell walkthrough. A real Windows check will make setup failures easier to distinguish from agent or package defects.

Scope

• Use a disposable, non-sensitive Windows workspace with Node.js 22 and PowerShell.
• Install from the public path: npx skills add bitjaru/styleseed.
• Verify that the installed core exposes 23 StyleSeed skills and that the styleseed router can be discovered by one supported host (Codex, Claude Code, or Cursor).
• Confirm that the default/core install does not add ss-learn or a StyleSeed MCP server.
• Add a concise walkthrough at docs/WINDOWS-INSTALL.md and link it from the manual-install or troubleshooting section of README.md.

Acceptance criteria

• Commands are copy-pasteable PowerShell, not translated shell syntax.
• The document records Windows, Node, host, and StyleSeed versions used.
• Expected output is described without including usernames, tokens, or private paths.
• Any host-specific limitation is labeled instead of presented as a StyleSeed failure.
• git diff --check and node scripts/test-public-claims.mjs pass.

Evidence to attach to the PR

Include the redacted command output and the exact verification commands you ran. A screenshot is optional; text output is preferred.

New contributors are welcome to claim this issue by leaving a comment.

[mori-ikuri]

Hi, I'd like to work on this issue. I'll verify the Windows PowerShell installation steps and prepare a documentation PR.

[mori-ikuri]

Quick update: I completed the Windows PowerShell install verification in a disposable workspace with Node.js 22. npx skills add bitjaru/styleseed succeeded, installed the 23 core skills, and placed the styleseed router in Codex’s project-local skill path. I also have the documentation draft ready.
However, the required check
node scripts/test-public-claims.mjs
fails on Windows before it can evaluate the documentation claims:
Error: ENOENT ... 'D:\D:<REPO>\README.md'
The failure appears to come from the test script’s file URL/path conversion (resolve(new URL("../", import.meta.url).pathname)), rather than from the documentation change. A small source fix—possibly using fileURLToPath()—may be needed, but I don’t want to expand the docs-only scope without checking first.
Would you prefer that I include a minimal Windows path-handling fix in the Issue #13 PR, or keep that PR documentation-only and open a separate issue/PR for the test script?

[bitjaru]

Thanks for verifying this on Windows and for checking before expanding the scope.

Please include the minimal fileURLToPath() fix in the same PR as a separate commit. It directly blocks the required Windows verification for #13, so it remains in scope.

Please keep the source change limited to scripts/test-public-claims.mjs and include:

• docs/WINDOWS-INSTALL.md plus the README link
• redacted Windows command output and the exact Node/Codex/StyleSeed versions used
• node scripts/test-public-claims.mjs
• node scripts/validate-engine.mjs
• git diff --check

No separate issue is needed unless the fix grows beyond that file. Thanks for catching this and for preserving the issue boundary.

[mori-ikuri]

While completing the requested Windows validation, I found the same URL pathname conversion pattern in scripts/validate-engine.mjs:

const root = resolve(new URL("../", import.meta.url).pathname);

On Windows, this produces a duplicated drive path such as D:\D:..., so the requested node scripts/validate-engine.mjs check cannot complete.

The approved fileURLToPath() fix in scripts/test-public-claims.mjs now passes.

May I apply the same minimal fileURLToPath() correction to scripts/validate-engine.mjs as an additional scoped change in this PR?

[bitjaru]

Thanks for checking again. No additional change to scripts/validate-engine.mjs is needed in your PR.

I audited the same cross-platform path pattern across the repository and merged the fileURLToPath() correction for scripts/validate-engine.mjs and the other maintainer-owned scripts in 54ef77e. The follow-up catalog refresh is also on the current main branch.

Please update or rebase your branch onto the latest main, then keep the #13 PR limited to:

• docs/WINDOWS-INSTALL.md
• the README link
• the minimal scripts/test-public-claims.mjs fileURLToPath() fix
• redacted Windows output and exact versions in the PR description

If your branch already includes a scripts/validate-engine.mjs change, please drop that change during the rebase. Then rerun the requested checks against the latest main and open the PR when ready. Thanks for surfacing the repository-wide pattern.

[mori-ikuri]

Thanks for the clarification and the upstream fix.
I updated the Issue #13 branch to current main at ff8baeb and confirmed that 54ef77e and the catalog refresh are present.
The approved scripts/test-public-claims.mjs fix now passes, and git diff --check also passes. However, node scripts/validate-engine.mjs still cannot complete on Windows.
After accounting for the repository symlink checkout, I’m still seeing:

• validate-skill-contracts.mjs expects LF-specific ---\n frontmatter, while my default Git for Windows checkout uses CRLF (core.autocrlf=true);
• the revision/update probes also fail against the CRLF-converted checkout;
• the optional learning validation fails with EPERM in fsyncDirectory() on Windows.
  I haven’t changed scripts/validate-engine.mjs or any other upstream-owned file. The Issue Docs: verify the clean install path on Windows PowerShell #13 diff is still limited to README.md, docs/WINDOWS-INSTALL.md, and scripts/test-public-claims.mjs.
  Would you prefer an upstream validation fix, or is there a Windows checkout/configuration procedure you’d like me to use for this PR?

[bitjaru]

Thanks for the precise Windows report. Both failures are upstream compatibility issues, so your #13 diff should remain scoped as-is.

I fixed them on main in f064c75:

• .gitattributes now pins repository text files to LF even when core.autocrlf=true, preserving the exact-byte revision contract.
• the learning runtime keeps file fsync and atomic rename, but skips the unsupported parent-directory metadata fsync on Windows.
• the learning catalog and regression coverage were refreshed.

The full GitHub Actions run is green: https://github.com/bitjaru/styleseed/actions/runs/32799990064

Please rebase onto current main at f064c75 and rerun the Windows checks in a fresh disposable clone. You can confirm the checkout policy with:

git ls-files --eol scripts/validate-skill-contracts.mjs

The working-tree column should report w/lf. Then rerun:

node scripts/test-public-claims.mjs
node scripts/validate-engine.mjs
git diff --check

Please keep the PR limited to README.md, docs/WINDOWS-INSTALL.md, and the approved scripts/test-public-claims.mjs fix, and include the redacted Windows output plus exact versions in the PR description. If all three checks pass, please open the PR.