Anchors every clock to a knowable date (deprecation SEP reaching Final
and revisions being "released as Current") so the twelve-month and
ninety-day floors can be computed without guessing a future publication
date. Points all decision steps at the governance Decision Process
section rather than SEP-932, which has no such section. Reframes
§Transition as an explicit grandfathering clause for the two
pre-existing deprecations, with their migration targets recorded so the
removal procedure has something to check.

Also: replacements must be Active in a Current revision (not just
draft), expedited shortening can be approved post-Final via the removal
SEP, the §Roles table now covers restoration and the SDK waiver, the
states table uses capital-C Current consistently, RFC 2026 swapped for
RFC 8996, and the Reference Implementation no longer promises schema.ts
tags for transport types that do not exist.

:house: Remote-Dev: homespace

…cycle-and-deprecation

# Conflicts:
#	docs/docs.json
#	docs/seps/index.mdx

:house: Remote-Dev: homespace

States explicitly that a feature is Deprecated from the moment its SEP
reaches Final rather than waiting for the next spec revision, and
explains why a feature may remain Deprecated indefinitely. Points the
roots/sampling motivation bullet at SEP-2577 instead of meeting notes,
notes Lead Maintainer veto in the Roles table, and switches three
British spellings to American.

:house: Remote-Dev: homespace

…tions

Address ecosystem-effects feedback: the lifecycle is only effective if
the deprecation signal reaches implementers. Pull the Tier 1 SDK
deprecation-marking bullet out of the spec-side artifact list into its
own section, upgrade SHOULD to MUST for the language-native deprecation
marker, and add a SHOULD for a runtime warning when a deprecated feature
is exercised (the testable signal for the conformance suite). Make
persistent non-compliance grounds for the SEP-1730 Tier Relegation
Process.

Strengthen the revision-support-window open question with the arithmetic
argument: a Tier 1 support window shorter than the twelve-month
deprecation floor lets an SDK consumer leapfrog the Deprecated state
entirely. Recommend the SEP-1730 amendment be pursued alongside this SEP.

Rename the "Runtime deprecation signal" open question to "Wire-level
deprecation signal" since the SDK-side runtime warning is now in the
policy body; the remaining gap is consumers without an official SDK.

:house: Remote-Dev: homespace

Address review feedback on the lifecycle mechanics:

- Measure the minimum deprecation window from the release of the revision
  that carries the deprecation rather than from the SEP-Final date, so
  every feature deprecated in the same revision shares one earliest
  removal. Resolves the internal inconsistency with the Tier 1 section,
  which was already release-anchored, and matches SEP-2577.
- Remove the second (removal) SEP. Removal is a Core Maintainer decision
  at release preparation with the migration/SDK confirmations recorded
  alongside the changelog entry. A SEP is now reserved for extending the
  window, restoring a feature, or expedited removal.
- Add docs/specification/draft/deprecated.mdx as a standing registry of
  Deprecated features and wire it into the deprecation artifacts.
- Transition: three-month grace for HTTP+SSE (already deprecated well
  over twelve months); includeContext values follow the SEP-2577
  Sampling deprecation rather than an independent clock.
- Reconcile Rationale, Roles, Transition, and Backward Compatibility
  with the above; point the SEP-2577 reference at the rendered page.

:house: Remote-Dev: homespace

…nsition

This is a Process SEP with no separate reference-implementation PR. Move
the schema/prose/changelog/registry edits into Transition as direct
draft/ changes when the SEP reaches Final, and reduce the Reference
Implementation section to a pointer.

:house: Remote-Dev: homespace

SEP-1730 already requires Tier-1 SDKs to implement new protocol features
within six months, and the replacement has been Active for at least the
twelve-month window before removal is eligible, so a separate
release-prep check that SDKs have shipped the migration is implied by
existing conformance. Replace the confirmation with a sentence noting
that, drop the waiver row from the Roles table, and rebase the
twelve-month rationale on removal being permissive rather than on the
removed check.

:house: Remote-Dev: homespace

… Removed

Relax the migration-target rule so the replacement and the deprecation
may land in the same revision (the twelve-month window from that
revision's release is the proving period; matches the
2025-03-26 Streamable HTTP precedent). State that Removed does not
oblige an SDK to drop the feature from releases supporting an earlier
revision, and that the SDK deprecation marker is intentionally
revision-agnostic.

:house: Remote-Dev: homespace

Regenerated docs/seps/index.mdx to resolve the conflict from new SEPs
landing on main.

:house: Remote-Dev: homespace