updated language and format

Author: dsp-ant

docs/community/feature-lifecycle.mdx

@@ -37,11 +37,12 @@ again, the minimum deprecation window in
 revision in which the new deprecation takes effect.
 
 ### SDKs
+
 Removal from the specification does not oblige an SDK to drop the feature from
 releases. That timeline is governed by the SDK's own revision-support policy.
 
-
 ## Deprecating a Feature
+
 A feature may be proposed for deprecation due to
 
 - it has been superseded by another feature that covers the same use cases,
@@ -60,7 +61,7 @@ Deprecation is a specification change and therefore requires a SEP per the
 3. Document the migration path, or state explicitly that none is required. If
    the migration path names a replacement feature, that feature must be Active
    in the revision in which the deprecation takes effect; the replacement and
-   the deprecation may land in the same revision. 
+   the deprecation may land in the same revision.
 4. Specify the **minimum deprecation window**: the number of months, at least
    twelve, that the feature must remain Deprecated before it is eligible for
    removal. The window is measured from the release of the specification
@@ -69,7 +70,7 @@ Deprecation is a specification change and therefore requires a SEP per the
    specification revision released as Current on or after the window elapses;
    that point is the feature's **earliest removal**.
 
-When the deprecation SEP is accepted and reaches Final, the deprecation is scheduled. 
+When the deprecation SEP is accepted and reaches Final, the deprecation is scheduled.
 
 - The feature's entry in `schema.ts` gains a `@deprecated` JSDoc tag
   referencing the deprecation SEP and the revision in which the deprecation
@@ -86,15 +87,15 @@ When the deprecation SEP is accepted and reaches Final, the deprecation is sched
 
 The feature becomes Deprecated when the revision carrying these changes is released
 and becomes the new Current revision (see [versioning guide](/docs/learn/versioning)).
-The minimum deprecation window is counted from that release. 
+The minimum deprecation window is counted from that release.
 
 ## The Deprecated Registry
 
 [`docs/specification/draft/deprecated.mdx`](/specification/draft/deprecated) is
 a single page listing every feature Deprecated or Removed state. It is
 the canonical answer to "what is on its way out, and by when," so that an
 implementer does not have to reconstruct that picture from deprecation entries
-spread across revision changelogs. 
+spread across revision changelogs.
 
 ## Tier 1 SDK Obligations
 
@@ -105,18 +106,18 @@ released as Current, Tier 1 SDKs:
   native mechanism (for example `@Deprecated` in Java, `[Obsolete]` in .NET,
   `@deprecated` JSDoc in TypeScript, the `Deprecated:` doc convention in Go) in
   their next release, referencing the deprecation SEP and the earliest removal
-  date where the mechanism permits. 
+  date where the mechanism permits.
 - Should emit a runtime warning when a deprecated feature is exercised, using
   the language's idiomatic mechanism (for example Python's
   `DeprecationWarning`, Node.js's `process.emitWarning`, or a configurable
-  logger). 
+  logger).
 
 ## Removing a Feature
 
 1. Once a feature is set for removal, the removal is executed at the discretion
    of the Core Maintainers after the minimum deprecation window has elapsed.
 2. The removal needs to be documented in the `changelog.mdx` and [registry](#the-deprecated-regsitry)
-2. A SEP is required for any change to the original deprecation or removal SEP, for
+3. A SEP is required for any change to the original deprecation or removal SEP, for
    example extending or shortening the timeline
    ([Expedited removal](#expedited-removal)) or restoring the feature to Active
    ([Feature states](#feature-states)).

docs/specification/draft/basic/lifecycle.mdx

@@ -133,7 +133,6 @@ extension identifiers to per-extension settings objects.
 The following is an example of a client that advertises the
 [MCP Apps extension](/extensions/apps/overview) identified as `io.modelcontextprotocol/ui`:
 
-
 ```json
 {
   "capabilities": {
@@ -148,6 +147,7 @@ The following is an example of a client that advertises the
 ```
 
 An example of [Tasks extension](/extensions/tasks/overview) identified as `io.modelcontextprotocol/tasks`:
+
 ```json
 {
   "capabilities": {

docs/specification/draft/basic/transports.mdx

@@ -698,8 +698,8 @@ See [Lifecycle: Backward Compatibility][lifecycle-compat] for details.
 
 #### Earlier Streamable HTTP Revisions
 
-Protocol versions `2025-03-26` through `2025-11-25` also used the Streamable
-HTTP transport, but in a different shape: servers could assign a session via
+Protocol versions `2025-03-26` through [`2025-11-25`](./docs/specification/2025-11-25/basic/transports.mdx)
+also used the Streamable HTTP transport, but in a different shape: servers could assign a session via
 the `Mcp-Session-Id` header (terminated with HTTP DELETE), clients could open
 a standalone SSE stream with HTTP GET to receive server-initiated messages,
 servers could send JSON-RPC _requests_ on SSE streams, and streams were