change check cannot fail for anything CI gates on: clippy is missing from the verification command set

[0xLeif]

specsync change check is the local gate that decides a change is verified. It runs the project's configured verification commands. Those commands do not include clippy, but CI does:

.specsync/sdd.json  ->  cargo test change::, cargo test, two Python validators
ci.yml:288          ->  cargo clippy -- -D warnings

So a change can be locally ✓ verified, pass change audit --strict, get an independent review, and still be BLOCKED in CI.

This is not hypothetical — it happened today

PR #705 went green locally, was pushed, and CI reported the test job as failed. Every test passed — 2376 and 406. The failure was a later step in that job: manual implementation of Option::map. Two costs, and the second is worse:

1. A wasted CI round trip and a force of attention onto the wrong thing.
2. The job name said "test" while the failure was clippy. Reading the job name rather than the failing step sends you to look for a broken test that does not exist.

Why it matters more than convenience

The lifecycle's claim is that verified means something. A local gate that cannot fail for a condition the remote gate blocks on makes verified weaker than it reads — the same class of problem as #698 (a requirement describing a gate the code does not have) and #694 (a check that cannot fail).

It also silently shifts the work: the author believes verification covered the change, and CI becomes the first place the truth appears.

What it needs

Add cargo clippy -- -D warnings to the verification commands so change check fails where CI would.

Two things to get right, neither optional:

• Match CI exactly. CI runs bare cargo clippy, NOT --all-targets. The --all-targets form currently has 21 pre-existing failures in src/validator.rs test code, so adding that form would make every change unverifiable. This distinction has already cost time once.
• Keep it in the same lane as the other commands — no network, no shell, bounded — which clippy satisfies.

Worth checking at the same time whether any other CI gate is absent from the local set. fmt --check appears to be in the same position.

Found during the independent review of #705, which noted: "This is exactly the hole that produced commit 2bd9795; the local gate still cannot catch it."

[0xLeif]

A second blind spot at the same site: the clippy that does run skips every test

Measured on clean main at a98fc3d1 while investigating something else.

The configured gate is identical in both places that define it — fledge.toml:8 and .github/workflows/ci.yml:288:

cargo clippy -- -D warnings

No --all-targets. That flag is what pulls in #[cfg(test)] code and the integration harness, so the ~2,395 unit tests and 407 integration tests in this repository have never been linted at all — not by CI, and not by change check either, which is this issue's subject.

Running the same denial level with --all-targets on an unmodified main:

exit 101 — 21 lints
  20  bin "specsync" test
   1  test "integration"

By lint:

count	lint
10	field_reassign_with_default — field assignment outside the initializer for a Default::default() value
4	contains instead of iter().any()
2	items_after_test_module
1	unused_mut
1	needless_return
1	clone replaceable with std::slice::from_ref
1	collapsible_if
1	equality check against false replaceable by negation

None is dangerous on its own. That is the point — they are the lints nobody chose to allow, accumulated because nothing ever asked. items_after_test_module is the one worth a second look: it means production items are declared after a #[cfg(test)] mod, which is exactly the arrangement that makes a symbol's visibility to tests non-obvious.

Why this belongs on #708 rather than its own issue

Same remedy site. Whoever adds clippy to change check's verification command set will write the invocation once, and if they copy the existing one they will reproduce the blind spot in the new gate — arriving at "change check now runs what CI runs" while both still skip every test in the repository. The fix for this issue should specify --all-targets, and clearing the 21 existing lints is a prerequisite rather than a follow-up, because a gate that fails on arrival gets disabled.

Related, and not a coincidence

This is the same shape as the Windows compile break found today in the release lane: a test referencing #[cfg(unix)] symbols without its own gate compiled cleanly on every machine anyone used, because Windows is built only in the RC qualification job. A check that never runs over a body of code cannot report anything about it, and reads as approval. That is this release's recurring defect — a category empty for want of input, read as a verdict (#672, #684, #720, #728) — appearing here in the lint configuration.

Verified with the full log; happy to attach it if useful.