Item 2 asks to treat .git and anything under .git/ as protected. The check anchors on the start of the normalized string, so a nested .git directory (a submodule or vendored repository) passes. Live POST /requests/check on 2026-10-02 refused every one of these with protected_path: "src/.git", "a/.git/b.txt", "web/.git/config" (the last one twice, for the path and path/**).

The library returns valid:true for all three, so a body the library approves is refused at quote time.

Live /requests/check (2026-10-02) refuses paths on build-contract-project, adversarial-review, build-website, frontend-for-contract, create-image, integrate-project and research-report with unplannable_steps "step 1 () declares its own budget, so the step may not also name paths". Only the six writer skills (implement-contract, implement-one-contract, implement-and-test, implement-component, write-foundry-tests, refine-project) accept paths.

The library forbids paths on three skills only. It also never checks the single-step form {skill, paths} at the top level: {objective, skill:'gas-and-size-report', paths:['src']} is valid locally while live refuses it with unknown_skill "declares its own budget, so the step may not also name paths" (same for build-contract-project, adversarial-review, write-readme-and-docs, deploy-script and the other non-writer skills).

schemas/common-1.json was edited by hand to accept '.' and './' (pattern (?:^|/)\.\.(?:/|$)), but the generator that sources/schema-notes.md names as the update procedure ("Edit scripts/generate-schemas.mjs, regenerate with node scripts/generate-schemas.mjs") still rejects any single-dot segment with \.{1,2} and still says only foundry.toml and lib are protected.

Running the documented regeneration overwrites common-1.json with the old pattern, so paths '.' and './src' become invalid again and test/live-check.test.cjs fails. No other schema drifts; the diff is exactly this definition.

The regex requires the last segment to start with a non-dot and to have characters after the final dot, and only '/**' is recognised as a glob. Live (2026-10-02) counts a path once whenever its last segment contains a dot or the path contains '*'.

Measured with 7 extensionless directories plus one file (15) plus one candidate: live passed (candidate = 1) for '.', './', 'src/*', '', 'src//', 'foo.', 'src/x.', 'src/.hidden.ts' and 'src/dir.name/', while the library reports bad_path_count (candidate = 2, total 17) for every one of them. Both sides agree that 'src/', './src', 'README', 'Makefile', 'a.b/c' and 'src/.d/x' count twice.

The library therefore refuses valid budgets, including the '.' path that item 1 was meant to admit.

Beyond the three names in the task, live /requests/check (2026-10-02) refused with protected_path: '.github', '.github/', '.github/workflows/ci.yml', '.env', '.env.local', '.env.example', 'node_modules', 'node_modules/x/index.js' and 'src/node_modules/x.js'. It accepted 'src/.github', 'src/.env', '.envrc', '.gitignore', '.gitmodules', '.vscode', '.idea', '.npmrc', 'package-lock.json' and 'dist'.

The library returns valid:true for all of the refused set, and docs/refusals.md lists only .git, foundry.toml and lib as protected. Low because it is outside the four listed items, but it is observed server behaviour the catalog does not mention.

When a job has steps and each step names its own paths, live /requests/check (2026-10-02) does not apply protected_path or bad_path_count to the job-level paths (a step without paths 'takes its paths from the job', otherwise the job-level list is unused). The library checks the job-level list unconditionally, so it refuses bodies live accepts.

Low: the job-level list is dead configuration in that case, and refusing it is the stricter outcome.

The fixture's root_dot, git_root and root_nine_directories bodies have an objective and paths but no skill or steps. Live (replayed 2026-10-02) returns bad_path_count (node 'build') for that shape regardless of the paths: {objective:'Build a project.'} with no paths at all, paths ['src'], ['src/a.ts'] and 8 directories all get the same blocker.

So the test's live assertion for root_nine_directories passes for a reason unrelated to the 9-directory rule, git_root's live result says nothing about .git, and line 16 asserts the library accepts root_dot while the saved live response for the same body is a refusal (the test never reads it).

Adding a top-level skill isolates the rules: with skill:'implement-component', live accepts paths ['.'], refuses ['.git'] with protected_path, refuses 9 directories with bad_path_count and accepts 8, all matching the library.

Refusing foundry.toml and lib is the requester's stated design and not a defect, but the catalog row describes them as a known cause of the server's protected_path. On 2026-10-02 live /requests/check returned no blockers for step paths 'foundry.toml', 'lib', 'lib/', 'lib/**', 'lib/forge-std/src/Test.sol' and 'remappings.txt'.

Live also accepted './.git', './foundry.toml' and './lib/x.sol' (it does not strip the './' prefix before the protected check), which the library correctly refuses. Worth stating as library-only policy, dated, as items 2-4 are.

All four saved launch cases, including launch_standard, carry two bad_path_count blockers from the server's own impl and tests nodes, and the replay plus 14 further launch bodies (with and without paths, evm_project, univ4_hook and onchain:true) all did too. The test only looks for launch_token in the live blockers and asserts the library says valid, so live and library never agree on a launch body and the test cannot detect it.

The live launch_token is a blocker, while the library (per the task's optional item) emits a warning; the CHANGELOG line 'The warning does not invalidate an otherwise valid input' is accurate for the library but a reader may assume it describes the server.