The download cards and the compatibility matrix derived each plugin's version
from the release tag, which cannot hold for a unified `vX.Y.Z` release: it
carries both JARs and their versions need not agree. v1.3.0 shipped Paper 1.3.0
alongside Velocity 1.2.0.

So the download page advertised Paper v1.2.2 and Velocity v1.1.0, two
generations stale, because it searched `paper/v` and `velocity/v` tags first and
fell back to a unified tag only when none existed. The matrix meanwhile put a
Velocity v1.3.0 on its axis that was never released, leaving no row for the
proxy build operators actually run.

Both now pick releases by the JARs attached to them and take the version from
the file name, the only place it is stated. Tag shape stops mattering: a
platform-specific tag and a unified one are alike just releases that happen to
carry a given JAR.

Releases rank by publication time rather than by API response order, which
follows tag creation instead: velocity/v1.1.0 precedes the later-published
paper/v1.2.2.

A version is listed once even when a later unified release re-attaches an
unchanged JAR, which release.yaml does whenever only the other platform was
bumped. Otherwise the matrix would carry one version twice, under two protocol
versions if the protocol had moved in between.

Tests run in CI from here on. They need an explicit path because Bun does not
discover tests inside dot-directories.

Co-Authored-By: Claude <noreply@anthropic.com>

The links were written before the English pages existed, so GitHub and Modrinth
sent an international audience to Japanese notes. Both now point at the English
pages; the Japanese ones remain reachable from the site's own locale switch.

Also stops the changelog template from being served. It lives under `src/`, so
VitePress published it as a page of empty headings at /assets/changelog-default,
where it was reachable and indexable. `srcExclude` keeps it a template.

The tag table on the changelog overview claimed `vX.Y.Z` was last used for
v1.0.0 and retired, which contradicts release.yaml and the release skill still
supporting it; it now says what the tag is for.

Co-Authored-By: Claude <noreply@anthropic.com>

The `@<server>` argument resolves against the server names registered in
`velocity.toml`, not the `features.velocityIntegration.serverName` of the
destination: PresenceTracker publishes `serverInfo.name` and
CrossServerDirectMessageRelay matches the target against the same, so the
previous text had it exactly backwards. Following it on a proxy where the two
names differ produces SERVER_NOT_FOUND every time, and points the reader at the
wrong file to fix. `serverName` still matters, for `{server}` and for
recognising local players, so what it does is stated instead.

Also corrects two claims made while widening these pages:

- `/lcv status` reports only this server's protocol version, not both sides'.
  The Velocity bug template leaned on it as its most important field, so a
  reporter would have pasted output that cannot answer the compatibility
  question. It now also says to run it after a player has joined, since the
  handshake waits for one - the same caveat the README install steps needed.
- Spies see pre-conversion text for direct messages only. Channel messages are
  converted before the handler runs, so spies get the same formatted string the
  members do.

Co-Authored-By: Claude <noreply@anthropic.com>

Every release emitted a skeleton of six empty headings that had to be filled in
by hand on the draft, and Modrinth linked to the GitHub release, so a reader
needed two hops to reach notes that might never have been written.

Both now link straight to the changelog page for the released version, built
from the tag, so the notes live in exactly one place. This makes the release
depend on that page being deployed, which the release skill now checks for.

Co-Authored-By: Claude <noreply@anthropic.com>

CONTRIBUTING pointed contributors at `./x start`, which now fails without a
platform argument, and credited LuckPerms with our coding conventions.

SECURITY.md still assumed a single Paper-shaped release: it scoped support to
one api-version and offered only email. It now states support per platform,
records that a protocol-version mismatch refusing to relay chat is intended
behaviour rather than a vulnerability, and points at GitHub private
vulnerability reporting, which is enabled on this repository.

Co-Authored-By: Claude <noreply@anthropic.com>

The single template asked for a Paper version unconditionally, so Folia and
Velocity operators had nowhere to describe the environment that actually
matters. Splitting it also lets each template carry its own Module label rather
than leaving that to triage.

The Velocity template requires the output of `/lcv status`, since compatibility
is decided by the protocol version rather than the plugin version, and asks for
the serverName of each backend, which is what cross-server DM routing matches
against.

Co-Authored-By: Claude <noreply@anthropic.com>

Paper 26.2 bundles Adventure 5.2.0, a major bump from the 4.26.1 shipped by 26.1.
Adventure 5 makes ClickEvent generic, so the raw type in
CommandContext.replyWithEvent no longer compiled. Auditing the rest of the
Adventure 5 removals found no other affected usage.

api-version is raised to 26.2, dropping 26.1 support: the two Adventure majors
are not binary compatible, so claiming 26.1 compatibility would be a lie.

Also fixes two problems found while verifying on a real server: the Velocity
healthcheck invoked mc-health, which does not exist in the mc-proxy image, so the
container had never once passed its check; and the debug environments pinned no
build at all, which meant the proxy came up as 4.1.0-SNAPSHOT while the plugin is
compiled against velocity-api 3.5.1. Server versions are now derived by x from
the Gradle coordinates so they cannot drift from what the plugin targets.

- Bump paperVersion to 1.2.0
- Update docker compose files to Paper/Folia 26.1.2
- Add v1.2.0 entry to CHANGELOG
- Drop "LunaticChat" prefix from release titles

Co-Authored-By: Claude <noreply@anthropic.com>

Add a dynamic compatibility matrix (GitHub Releases + ProtocolVersion.kt at
each tag) shown on the home page, download page, and a new reference doc.
Split protocol theory and rolling-update rules out of the Velocity feature
guide into the new compatibility reference, and simplify the download notice.

Also set explicit GitHub release titles in the Paper / Velocity workflows so
the awkward paper/v* tag prefix is not the user-facing label.

Co-Authored-By: Claude <noreply@anthropic.com>