docs(llm-security): state the deprecation notice period this repo practices

D4-C, order 20260821T091412Z-1428311869-from-.claude. Measured by .claude
against the org 21.08: this repo has the org's most mature deprecation
PRACTICE and no stated policy. An adopter cannot read a CHANGELOG row and know
it applies next time -- what D4 measures is what can be EXPECTED, not what
happened last time.

Form copied from open/portfolio-optimiser SECURITY.md "Deprecation Notice
Period"; the numbers are this repo's own. Both floors are kept because the
release count alone is toothless here: measured from the README release table,
7.5.0 and 7.6.0 shipped a day apart (2026-05-05 -> 2026-05-06), so "at least
one minor release" without a day floor would permit a next-day removal. 30 days
is comfortably holdable -- the one precedent ran 112 days (v7.3.0 released
2026-05-01 per commit 4637139; v8.0.0 still unreleased at 2026-08-21).

The precedent is worded as staged, not shipped: git describe reports
v7.8.3-43-ge97c232 and the removal sits under CHANGELOG [Unreleased], so
claiming v8.0.0 "removed" them would have been a claim about an untagged
release. Only the four env-vars are cited; CHANGELOG dates riskScoreV1's
@deprecated to v7.0.0 while README says v7.3.0, and that disagreement should
not be load-bearing in a policy.

No promise the project cannot hold: it is stated as a notice period and not an
SLA, with no backporting, and the one exception for security-critical removal
is named explicitly. README's Project scope now points at the section so an
adopter arriving from the deprecation bullet lands on the rule.

Docs only; the Iron Law does not fire. doc-consistency gate 45/45 pass, exit 0.
Full suite unchanged vs HEAD: 2253 tests / 2247 pass / fail 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y7TAHJfxBoCm9YwhMWm6y5

CHANGELOG.md

@@ -16,6 +16,15 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
   llms.txt is a convention, not a ratified standard, so a format change stays
   cheap.
 
+- **A stated deprecation notice period** in `SECURITY.md`. The practice already
+  existed — the four `LLM_SECURITY_*` env-vars were announced in v7.3.0 and are
+  removed in v8.0.0, five minor releases later — but nothing said it was the
+  rule, so an adopter could read the changelog and still not know what to expect
+  next time. The promise: announcement in the changelog, at least one minor
+  release **and** no fewer than 30 days before removal, removals only in a major,
+  one stated exception for security-critical removal, and an explicit note that
+  this is a notice period and not an SLA.
+
 ### Removed — BREAKING
 
 - **The four `LLM_SECURITY_*` configuration env-vars deprecated in v7.3.0.**

README.md

@@ -475,7 +475,7 @@ into commercial-grade territory. Going forward, work focuses on:
 - **Bug fixes** and security patches
 - **Compatibility** with new Claude Code releases
 - **Knowledge-base refresh** (OWASP updates, new published research, new attack patterns)
-- **Deprecation cleanup** — v8.0.0 removed the four `LLM_SECURITY_*` mode env vars and `riskScoreV1`, both deprecated in v7.3.0 (see [Migration](#migrating-to-v800))
+- **Deprecation cleanup** — v8.0.0 removed the four `LLM_SECURITY_*` mode env vars and `riskScoreV1`, both deprecated in v7.3.0 (see [Migration](#migrating-to-v800)). The notice period this follows is stated in [`SECURITY.md`](SECURITY.md#deprecation-notice-period)
 - **Opportunistic small additions** that fit the existing deterministic architecture
 
 ## Non-goals

SECURITY.md

@@ -17,6 +17,32 @@ The project is in **stabilization mode** as of 2026-05-01. New features are
 out of scope (see "Project scope" in [`README.md`](README.md)). Security and
 correctness fixes continue.
 
+## Deprecation notice period
+
+When a supported surface is removed — an env-var, an exported helper, a policy
+key, a command, or a documented output field:
+
+- The deprecation is announced in [`CHANGELOG.md`](CHANGELOG.md) under the
+  release that introduces it, and where the code can warn, it warns on use.
+- **At least one minor release — and no fewer than 30 days — passes between that
+  announcement and the removal.** Both floors are required: minor releases here
+  have shipped as little as a day apart, so the release count alone would not
+  give anyone time to read the changelog.
+- **Removals themselves land in a major release**, never in a minor or a patch.
+- **The one stated exception is a security-critical removal.** If leaving a
+  surface in place is itself the risk, it goes in the next release and the
+  changelog says plainly why the notice period was not used. This has not
+  happened so far.
+
+Precedent: the four `LLM_SECURITY_*` configuration env-vars were announced as
+deprecated in v7.3.0 (2026-05-01) and warned on every use. Their removal is
+staged for v8.0.0 — five minor releases (7.4.0 through 7.8.0) and more than
+three months later — with a migration table in [`README.md`](README.md).
+
+This is a notice period, not an SLA. It says when a break will be *announced*,
+not when a release will happen. There is no backporting, and a fork that needs
+stronger guarantees should set its own (see [`CONTRIBUTING.md`](CONTRIBUTING.md)).
+
 ## Reporting a vulnerability
 
 If you discover a security vulnerability in this plugin, please report it