Add a `java-maven` 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 Java/Maven service 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/java-maven.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: java-maven
# @policy title: Java service (Maven, JUnit, src/main + src/test)
# @policy summary: A Maven-built Java service. The agent may change main and test sources, resources and
#   the POM, and must keep `mvn -q verify` green. Build extensions, repository settings,
#   production profiles and Flyway migrations stay off-limits.
# @policy stack: java, maven, junit, spring-boot, flyway
# @policy author: your-github-handle
# @policy blocks: src/main/resources/db/migration/V7__add_index.sql, src/main/resources/application-prod.yml, .mvn/extensions.xml, settings.xml, .github/workflows/release.yml
# @policy allows: src/main/java/com/acme/CheckoutService.java, src/test/java/com/acme/CheckoutServiceTest.java, src/main/resources/application.yml, pom.xml, README.md
version: 2
task_type: feature-work

allowed_paths:
  - "src/main/java/**"
  - "src/test/java/**"
  - "src/main/resources/**"
  - "src/test/resources/**"
  - "pom.xml"
  - "README.md"
  - "CHANGELOG.md"

forbidden_paths:
  # .mvn/extensions.xml and .mvn/maven.config alter EVERY mvn invocation in the tree,
  # including the one that runs your required checks. A build that can rewrite how it
  # is built cannot be used as evidence about itself.
  - ".mvn/**"
  - "settings.xml"
  - "**/settings.xml"
  # Inside src/main/resources/** which is otherwise allowed. A Flyway migration is
  # applied exactly once against a real database; there is no dry run in the diff.
  - "**/db/migration/**"
  - "**/db/changelog/**"
  # Production profiles configure the running system, not the code under test — a
  # datasource URL or a disabled security filter here never shows up in a unit test.
  - "**/application-prod*"
  - "**/application-production*"
  - ".github/**"
  - "Dockerfile*"
  - "**/.env*"
  - "**/*secret*"
  - "**/keystore*"

max_files_changed: 15
required_checks:
  - "mvn -q -B verify"

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 Java/Maven service that exception is:

**/db/migration/** and **/application-prod* — both live under
src/main/resources/**, which you want allowed so the agent can add a message bundle or a
test fixture. Neither of those two is reviewable from the diff alone.

The Maven trap worth a comment in the file

A <dependency> added to pom.xml is code execution at build time (annotation
processors, plugin goals bound to validate), and transitive version bumps via
<dependencyManagement> apply to modules outside the diff. If you allow pom.xml — you
probably should — say in the comment that the required check is what constrains it.

Acceptance criteria

• signetry_core/policies/java-maven.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.