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
This commit is contained in:
Kjell Tore Guttormsen 2026-08-21 11:30:14 +02:00
commit 342acda5bc
3 changed files with 36 additions and 1 deletions

View file

@ -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.**