Add a `rust-crate` policy to the policy registry

[bkd-dotcom]

What this is

signetry-core ships a policy registry: a directory of YAML files, one per repository
shape, that says which paths an AI agent may touch for a given task and which it may not.
Six ship today (signetry_core/policies/):
python-library, node-service, monorepo-service, docs-only, dependency-bump,
ci-workflow-fix. A Rust crate is missing.

This is the highest-leverage thing you can contribute without touching the kernel: one new
file, no Python, and no test to write — tests/test_policy_registry.py is parametrized
over every file in that directory, so your policy is validated the moment it exists.

The deliverable

One file: signetry_core/policies/rust-crate.yaml. Copy
python-library.yaml
as your starting shape — the # @policy header comments are load-bearing metadata, not
decoration.

A starting point, not a spec to type in verbatim — argue with it, the reasoning is the
contribution:

# @policy id: rust-crate
# @policy title: Rust crate (src/tests layout, cargo test)
# @policy summary: A library crate. The agent may change crate source, tests and benches, and must keep
#   `cargo test` and clippy green. Anything that runs at compile time, pins the toolchain
#   or rewrites a test's own expected output stays off-limits.
# @policy stack: rust, cargo, clippy
# @policy author: your-github-handle
# @policy blocks: build.rs, .cargo/config.toml, tests/snapshots/api__list.snap, rust-toolchain.toml, .github/workflows/ci.yml
# @policy allows: src/lib.rs, src/parser/mod.rs, tests/integration.rs, Cargo.toml, README.md
version: 2
task_type: feature-work

allowed_paths:
  - "src/**"
  - "tests/**"
  - "benches/**"
  - "examples/**"
  - "Cargo.toml"
  - "README.md"
  - "CHANGELOG.md"

forbidden_paths:
  # build.rs is arbitrary Rust that runs at COMPILE time, on every developer machine
  # and every CI job that builds the crate — the Rust analogue of setup.py. It can
  # link native code, shell out, or emit cfg flags that change what compiles.
  - "build.rs"
  # .cargo/config.toml can repoint the registry, override the linker or inject
  # rustflags for every build in the tree, from a file nobody reads in review.
  - ".cargo/**"
  - "rust-toolchain.toml"
  - "rust-toolchain"
  # Inside tests/** which is otherwise allowed: a snapshot IS the assertion.
  # Letting the agent rewrite it turns 'make the test pass' into 'edit what the
  # test expects' — the failure mode reviewers never catch by reading the diff.
  - "tests/snapshots/**"
  - "**/*.snap"
  - ".github/**"
  - "**/.env*"
  - "**/*secret*"

max_files_changed: 12
required_checks:
  - "cargo clippy --all-targets -- -D warnings"
  - "cargo test --all-features"

policy_owner: your-team
policy_version: "1.0"

The part people get wrong

Your blocks list must include at least one path that sits inside your own
allowed_paths. Carving an exception out of a directory you otherwise own is the whole
skill. For a Rust crate that exception is:

tests/snapshots/** (and **/*.snap) — tests/** is allowed because the agent
should be writing tests, but a snapshot file is the expected output. An agent that can
edit it can always make a failing test pass.

The Rust trap worth a comment in the file

Cargo.lock: for a library it's advisory, for a binary it's the build. Pick a
side and comment it. And feature flags — a new [features] entry in Cargo.toml can
enable code paths that no reviewer of the diff looked at.

Acceptance criteria

• signetry_core/policies/rust-crate.yaml exists; filename matches @policy id.
• blocks and allows each list 3–4 realistic paths for this stack, and don't overlap.
• At least one blocks entry is inside allowed_paths.
• Every forbidden_paths entry that isn't self-evident carries a comment saying why,
  not just that it is. python-library forbids conftest.py at any depth and the comment
  explains it executes at collection time on every developer machine — that is the bar.
• pytest tests/test_policy_registry.py is green. The suite proves each claimed block is
  actually refused by the real evaluate_contract, so a policy that misleads adopters
  fails CI rather than shipping.
• If the policy permits something risky, it says so in a caution: — signetry init
  prints it at adoption time. A risky policy with no caution gets sent back; a risky
  policy that's honest is fine.

Getting started

The full numbered walkthrough, including what makes a policy worth merging, is in
docs/site/policy-registry.md → "Contributing a policy".

git clone https://github.com/Signetry/core && cd core
uv sync
uv run pytest tests/test_policy_registry.py -q
uv run signetry policies          # your entry should appear here once the file exists

Comment to claim it — one policy per contributor so nobody's work gets duplicated. Happy to
review a half-finished scope list; the reasoning matters more than the YAML.