fix(railguard): skip test hook when runner missing; add path-fence guidance rules

[ulises-c]

Fixes the two open Railguard issues.

#29 — Railguard Hooks Error (blocking pytest: command not found)

post-test-runner.sh auto-detects pytest for any project with a pyproject.toml/pytest.ini/setup.py, then fails with a blocking PostToolUse error when the runner isn't installed. Added a guard after test-command discovery:

command -v "${TEST_CMD%% *}" >/dev/null 2>&1 || exit 0

A missing runner binary now means "no runnable suite — skip" (consistent with the hook's existing no-suite behavior) instead of a blocking error. This covers all detected runners (pytest, cargo, go, npm, make) and .claude/test-cmd overrides, without requiring a global pytest install.

Closes #29

#26 — path-fence false positives on fenced paths in command text

Added rules/common/railguard.md (imported from CLAUDE.md, outside the railguard-managed block so it survives regeneration) codifying:

• Prefer Write/Edit tools over cat <<EOF > / echo > / printf > for authoring file content.
• Don't embed fenced path literals in Bash command text; reference them via files written with Write and passed by path (--body-file, --file).
• Switching from a fence-blocked Bash command to the Write tool is the intended remediation, not evasion.
• A block on an actual fenced-path access should not be retried in any form.

Since ~/.claude/CLAUDE.md and ~/.claude/rules/ are symlinked into this repo, the guidance is live immediately.

Closes #26

#26 follow-up — cd approval prompts (fence anchor drift)

Root-caused the constant cd prompts in monorepo/submodule work: the fence's "project directory" is the hook's cwd at each call, not a root captured at session start. Since the shell cwd persists across Bash calls, a cd into a nested dir re-anchors the fence there, and cd back to the repo root resolves "outside the project" → approval prompt. Reproduced live (the repo root itself failed the fence after a nested cd).

Workaround in railguard.yaml: added ~/github, ~/Github, ~/Bitbucket to fence.allowed_paths so cwd drift inside any repo under them stays fenced-in. Details in the #26 comment.

Out of scope / follow-ups

• Fence matching on actual access targets instead of substring-scanning command text is an upstream railguard binary change, not fixable in this repo.
• The proper fix for fence anchor drift is also upstream: capture the project root at SessionStart (launch cwd or git rev-parse --show-toplevel) and fence against that stable root instead of the per-call cwd.
• fix(hooks): post-test-runner.sh broken on macOS — date +%s%3N and missing timeout #33 (post-test-runner.sh macOS portability — date +%s%3N, missing timeout) touches the same script but is a separate fix, left out of this PR.

Security review run on the staged diff: no findings (the hook change adds a read-only, quoted command -v check; the rest is markdown).

🤖 Generated with Claude Code

[ulises-c]

Upstream follow-up filed and submitted for the fence anchor drift root-caused here:

• Issue: railyard-dev/railguard#4 — Path fence anchors to per-call cwd instead of a session project root — cd within a repo triggers approval prompts
• PR: railyard-dev/railguard#5 — fix(fence): anchor path fence to session project root, not per-call cwd

The upstream PR captures the project root once at SessionStart (nearest ancestor with .git, falling back to the launch cwd) and fences every subsequent call against that anchor instead of the per-call cwd. It also fixes a second symptom of the same root cause: per-call cwd was used to locate the session state file, so cd silently spawned fresh state files and reset suspicion tracking and session approvals.

Once that lands in a release, the fence.allowed_paths workaround in railguard.yaml (~/github, ~/Github, ~/Bitbucket) can be dropped.