The matrix marked every accepted pair with a plain tick, which reads as "everything works". It does not. ProtocolVersion bumps PATCH for sub-channels a peer can safely ignore, so Paper 1.3.0 (protocol 1.0.1) against Velocity 1.1.0 (1.0.0) completes the handshake and then silently drops cross-server direct messages — the very feature that PATCH was bumped for. An operator reading the tick had no way to learn that, and the pages around it repeated the claim. The handshake is settled by MAJOR and MINOR alone, so any difference left once a pair is accepted is a feature the newer end offers and the older will never answer. Those pairs now carry a warning that says which end lags. Naming the feature would take a protocol-version-to-feature table on the website, which would drift from the protocol it describes, so the warning stays general and leaves the reader one hop from the compatibility page. The handshake verdict keeps the three checks that mirror Velocity's gate, with the new one layered after them, so the mirror stays honest. isCompatible now holds for a degraded pair, which does connect. Cells are built once per pair in a computed instead of recomputing on each of the template's reads, which a third state would otherwise have multiplied. Co-Authored-By: Claude <noreply@anthropic.com>
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>
Release notes were written into the GitHub release body, which means they exist once, in English only, and are awkward to revise after publishing. Putting them on the site gives each release a Japanese and an English page that can be corrected later and linked from anywhere. The overview page states the versioning rules the version numbers alone do not convey: that dropping a supported platform is a MINOR bump, that the Paper and Velocity builds advance separately, and that the plugin version says nothing about compatibility. Co-Authored-By: Claude <noreply@anthropic.com>
Velocity moved to the 4.x generation while platform-velocity still compiled against 3.5.1, so the debug environment had to pin an older proxy than the one most users now run. The migration needed no source changes. Comparing every one of the 213 classes in the API jar with javap shows 4.0.0 is identical to 3.5.1 in its public signatures; the supported protocol range is unchanged too. The one real difference is the POM, which moves adventure-bom from 4.26.1 to 5.2.0. Support for 3.5.x is dropped even though the JAR would still load there, because keeping it meant Adventure 4.26.1 could be the runtime and engine had to stay inside the API surface both Adventure majors share -- a constraint no build step could check. Narrowing to 4.x makes every supported runtime ship Adventure 5.2.0, matching what engine already compiles against, so the constraint is gone rather than merely documented. Nothing enforces the requirement in code, matching how dropping 3.4.0 was handled in v1.1.0. Also drops two dead dependencies: kaml, declared but never imported, worth about 1 MB of shaded JAR, and the velocity-api annotationProcessor, which does nothing without Java sources or kapt.
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.
* docs: add developer design/architecture guide (EN/JA) The docs site covered features and reference but had no entry point for the codebase's design. Add a Developer Guide section describing the module structure (engine shared kernel, platform-paper, platform-velocity), the protocol-version compatibility model, and the Service Container / Feature Gating pattern, so contributors can understand the architecture without reading the source first. Co-Authored-By: Claude <noreply@anthropic.com> * docs: mirror cross-server DM docs into English (#231) PR #231 added the cross-server direct messaging feature but updated only the Japanese docs. Port the same additions to the English pages (configuration, direct-message, velocity, commands) so both locales stay in sync. Co-Authored-By: Claude <noreply@anthropic.com> * style: apply biome formatting to ja.ts sidebar config The developer-guide sidebar entries were not biome-formatted, failing the build_docs CI check (format:check). Apply the formatter. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
Swap the website default locale from Japanese to English. English now lives at the site root (/), and Japanese moves under /ja/. Update locale config, nav/sidebar links, internal doc links, and asset relative paths accordingly. Co-Authored-By: Claude <noreply@anthropic.com>