The contributing page still tells you to run the pre-commit framework, which leaves the clone with no gate

[vladimirrott]

docs/developer-guide.md stopped telling you to run the pre-commit framework
when #430 landed in #462. The contributing page in the same book still does.

$ git rev-parse --short=8 HEAD
fab9053f
$ sed -n '123,130p' docs/contributing/CONTRIBUTING.md
cargo nextest run --workspace --locked

# Frontend
npm test --prefix apps/sysknife-shell && npm exec --prefix apps/sysknife-shell -- tsc --noEmit

# All pre-commit hooks
pre-commit run --all-files

That page ships in the book:

$ grep -n 'contributing/CONTRIBUTING' docs/SUMMARY.md
47:- [Contributing](contributing/CONTRIBUTING.md)

Why it matters

docs/developer-guide.md:68 spells out what happens to somebody who follows
that instruction:

$ sed -n '68,70p' docs/developer-guide.md
> Do **not** use `pip install pre-commit && pre-commit install`. This repository
> drives its hooks through `core.hooksPath`, so anything written into
> `.git/hooks` is ignored by Git and you would end up with no gate at all.

A reader who lands on the contributing page, installs the framework and commits
believes a gate ran. Git looked in .githooks and never in .git/hooks, so
nothing ran. That is the evening #430 was filed to prevent, reached through the
other door.

The guard #462 added reads docs/developer-guide.md and nothing else, so this
copy is invisible to it:

$ grep -n 'check_pre_commit_commands' scripts/check_evidence_claims.py
810:def check_pre_commit_commands(root: Path, guide: str) -> list[str]:
840:        problems += check_pre_commit_commands(root, texts["docs/developer-guide.md"])

Scope

• Replace the pre-commit run --all-files block in
  docs/contributing/CONTRIBUTING.md with what the repository drives. Read
  .githooks/pre-commit and scripts/ci-local.sh --install-hooks before
  writing it down; do not copy a list out of this issue.
• Decide whether the contributing page should carry the five steps itself or
  point at docs/developer-guide.md#pre-commit-hooks. A second copy of the list
  is a second thing to drift, and check_pre_commit_commands screens one file
  today. Pointing at the guide costs nothing and keeps one source.
• If you do put commands in the contributing page, extend
  check_pre_commit_commands to screen both files rather than leaving the new
  copy unguarded.
• .pre-commit-config.yaml is still in the tree, and docs(hooks): align pre-commit guide with the active gate #462 calls it "an unused
  remnant of the earlier framework setup". Say in one sentence in the PR whether
  anything reads it, or file its removal separately.

Tests first

tests/release/public-claims.test.sh already mutates the hook and asserts the
checker names the changed step. If you extend the checker to a second file,
extend that fixture the same way and show it going red both by adding a step and
by removing one. A checker that screens a file nobody mutated in the test is the
defect one level up.

Difficulty

easy. One markdown block, one decision about where the list lives, and an
existing guard to reuse. No Rust, no daemon, no VM.

Getting started

CONTRIBUTING.md
has the build and test commands. No CLA and no copyright waiver. The project is MIT.

[vladimirrott]

Duplicate of #464, which I filed earlier today for the same lines of docs/contributing/CONTRIBUTING.md. #464 is the one to work on; it carries the same labels and quotes the same evidence.

Closing this one so nobody picks up both.