The developer guide describes a pre-commit hook that runs two checks, and tells you both to use and not to use the pre-commit framework

`docs/developer-guide.md:421-422` describes `.githooks/pre-commit` as two checks:

```
$ git rev-parse --short=8 HEAD
61b3a878
$ sed -n '421,422p' docs/developer-guide.md
`.githooks/` already ships a `pre-commit` hook (`cargo fmt --all --check` +
`cargo nextest run --workspace --locked`) alongside the new `pre-push` one.
```

The hook runs five:

```
$ grep -nE '^(cargo|RUSTDOCFLAGS|scripts)' .githooks/pre-commit
16:scripts/check_no_secrets.sh --staged
19:cargo fmt --all --check
22:cargo clippy --workspace --all-features --all-targets --locked -- -D warnings
25:RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --workspace --locked
34:scripts/test_baseline.sh
```

A hundred and forty lines earlier the same document says two of those run only
in CI:

```
$ sed -n '279,280p' docs/developer-guide.md
Intentionally excluded from pre-commit (they run in CI instead):
`cargo clippy` (20–30 s), `cargo nextest run` (minutes), `vitest` (minutes).
```

And the guide disagrees with itself about the `pre-commit` framework. Line 68
tells you not to install it and calls `.pre-commit-config.yaml` dead; line 255
opens a section instructing you to run it:

```
$ 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.
$ sed -n '255,258p' docs/developer-guide.md
## Pre-commit Hooks

Pre-commit runs on every `git commit`. Run all hooks manually before
pushing:
$ sed -n '261p' docs/developer-guide.md
pre-commit run --all-files
```

## Why it matters

The hook's own header records the change that made the guide stale, and why the
change mattered:

```
$ sed -n '4,8p' .githooks/pre-commit
# These are the Rust checks the `rust` job in .github/workflows/ci.yml runs,
# copied verbatim so a green commit here means a green job there. The hook used
# to run only fmt + nextest, which let a broken intra-doc link (a doc comment
# pointing at a function the same commit deleted) pass locally and fail in CI.
# A local gate that is a subset of the remote one buys a false green, not speed.
```

So the guide describes the exact configuration that was removed for producing
false greens, and it describes it as current. A contributor who installs the
hook expecting `fmt` plus tests gets stopped by `clippy -D warnings` and
`RUSTDOCFLAGS="-D warnings" cargo doc`, neither of which the guide told them
about. A contributor who reads line 279 instead believes clippy will not run
until CI, which is the belief the header was written to kill.

The framework contradiction costs a different evening: somebody follows the
"## Pre-commit Hooks" section, installs the framework, writes into `.git/hooks`,
and ends up with no gate at all while believing they have one. Line 68 says so
in as many words.

## Scope

- Correct `docs/developer-guide.md:421-422` to the five steps the hook runs, in
the order it runs them. Take the list from `.githooks/pre-commit`, not from
this issue.
- Correct the exclusion list at `docs/developer-guide.md:279-280`. `vitest` is
the only one of the three that is still excluded; check that before writing it
down.
- Resolve the framework contradiction. Either the "## Pre-commit Hooks" section
at line 255 goes, or the warning at line 68 goes, and the file keeps the one
that matches what `.git/config` actually drives. Read `core.hooksPath` and the
`.githooks/` directory before choosing; do not pick the one that needs less
editing.
- If the section goes, say in one sentence what `.pre-commit-config.yaml` is
still doing in the tree, or the next reader files this issue again.

## Tests first

`docs/developer-guide.md` is already screened, and the existing screen does not
cover this, so read it before assuming either way:

```
$ grep -n 'developer-guide' scripts/check_evidence_claims.py
67: "docs/developer-guide.md",
```

That list is for **numeric** claims. Nothing checks hook prose against the hook.

The guard to add is a rule that every command the guide attributes to
`.githooks/pre-commit` appears in `.githooks/pre-commit`. Prove it bites the way
this repo expects: add a sixth step to the hook, or delete one, and show the
check going red and naming the step. A guard that passes with the hook and the
prose disagreeing is the defect being filed here, one level up.

## Difficulty

`easy`. The reading is the work: three passages, one hook file, and one decision
about which of two contradictory sections survives. No Rust, no VM, no daemon.

## Getting started

[CONTRIBUTING.md](https://github.com/lacs-project/sysknife/blob/main/CONTRIBUTING.md)
has the build and test commands. No CLA and no copyright waiver. The project is MIT.

Read docs/developer-guide.md alongside .githooks/pre-commit, then inspect .git/config and .githooks/ to resolve which hook setup the repository uses. Review scripts/check_evidence_claims.py and its existing screen before adding coverage. Done means the guide matches the hook’s five commands and exclusions, the framework guidance is consistent, and the new guard fails when hook prose and commands disagree.

Written by the indexing model from the issue text.