Document Rule 4 and the refresh procedure in the safety-kit README

[ptr727]

The write-safety kit README described only the three write footguns; the guard now also enforces Rule 4 (deny a git operation that would only land by bypassing an active branch rule). Updates:

• What It Installs describes Rule 4 (direct push to a PR-gated branch, force where history is protected, delete where deletion is blocked, and --admin/--no-verify; judged against live branch rules, fail-closed on the protected defaults).
• Scope and Limits adds a note that the branch-bypass rule fails closed (unlike the precision-over-recall write rules).
• A Refreshing After an Upstream Change section makes the re-run-the-installer update path explicit - the mechanism Roll out global ~/.claude/CLAUDE.md safety rules to all machines #365 tracks.

Docs only - no release.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the host write-safety kit documentation to reflect the expanded guard behavior (including the new Rule 4 branch-bypass protections) and to document how to refresh deployed copies on machines after upstream changes.

Changes:

• Document Rule 4 coverage in What It Installs, including branch-rule enforcement behavior and fail-closed defaults.
• Add a Refreshing After an Upstream Change section describing the “pull + re-run installer” update path.
• Clarify Scope and Limits to distinguish precision-over-recall for write-footgun rules vs fail-closed behavior for branch-bypass protection.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

host-setup/agent-safety/README.md:72

• This bullet says the rule adapts "with no hardcoded list", but it also describes a hardcoded fail-closed deny set (main/master/develop) when rules cannot be read. Clarify that the "no hardcoded list" claim applies to the live-rules evaluation, not the fail-closed fallback.

- **The branch-bypass rule fails closed.** Unlike the write-footgun rules, a push to `main`/`master`/`develop` is denied even when the branch rules cannot be read, because the harm there is a silent success under the maintainer's admin bypass. The rule reads each branch's live rules, so it adapts to every repo (a code-style `develop` denies, a config-style `develop` allows) with no hardcoded list, and hands the exact command to the maintainer to run when a bypass is genuinely intended.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

host-setup/agent-safety/README.md:3

• The intro describes this as guarding against a "git operation", but the examples include gh pr merge --admin, which is not a git operation. Also, --admin is an admin-override flag rather than a verification-skip flag. Rewording to "an operation" / "bypass flag" keeps the overview accurate and avoids conflating these concepts.

Per-machine, user-account-scoped guards against an agent making a mis-targeted GitHub **write** under the maintainer's identity, or a **git operation that bypasses a repository protection** - a push, force-push, or delete that an active branch rule forbids, or a verification-skipping flag like `--admin`/`--no-verify`. Deploy it as the **first thing on any new system** where Claude Code runs with the `gh` credentials logged in (WSL, Linux, macOS, Proxmox, Windows).

host-setup/agent-safety/README.md:9

• This bullet says the second class is a "git operation", but it includes gh pr merge --admin in the explicit-bypass list, which is a GitHub CLI operation rather than a git operation. Using "an operation" avoids the mismatch while keeping the rest of the paragraph intact.

- **`hooks/gh-write-guard.py`** - a PreToolUse hook that denies two classes of dangerous action. First, the GitHub **write** footguns behind the cross-repo comment incident: a state-changing `gh` call whose output is discarded, a GraphQL mutation passing a **literal** node id instead of a `$variable`, and a `gh` write whose explicit target is outside the checkout's `origin`. Second, a **git operation that bypasses a repository protection**. The branch-rule cases - a direct push to a branch that requires a pull request, a force-push where history is protected, a branch delete where deletion is blocked - are judged against the branch's **live** rules, so a code-style `develop` is denied while a config-style `develop` is allowed with no per-repo configuration, and the protected-default branches fail closed when the rules cannot be read. The explicit-bypass flags (`gh pr merge --admin`, `git commit`/`git push --no-verify`) are denied **unconditionally**: the flag is the bypass, so no branch query is needed. Reads and everything else pass through. It fires even in autonomous / bypass-permissions sessions, which is how the incident happened.