SLS-LITE 0.1.0-rc.2.3

This narrow corrective release removes an implicit persistent-file backup policy and improves diagnostics for processes that fail after reaching readiness. Planned RC.3 features and architecture work remain out of scope.

Persistent-File Publication

• SLS-LITE no longer creates internal/persistent-file-backups/ or retains a previous.bak before publishing a changed declared persistent file.
• Publication remains atomic, so an interrupted write cannot expose a partial canonical file.
• Single-writer ownership and conflict detection are unchanged. If the canonical and instance copies changed independently, SLS-LITE still preserves the canonical value, stores the instance value under internal/persistent-file-conflicts/, and requires an operator decision.
• Backup and retention policy now belongs entirely to the operator.
• Existing internal/persistent-file-backups/ data from RC.2.2 or earlier is never deleted or modified during upgrade. Inspect, archive, or remove it manually while Velocity is stopped.

This change affects only automatic backups made during persistent-file write-back. Transaction backups used temporarily to make a persistent instance reset recoverable remain required and are cleaned up after commit or startup reconciliation.

Runtime Failure Diagnostics

• A process that exits after successful readiness is now described as exiting after readiness; it is no longer mislabeled as a failed start or as exiting before readiness.
• The report continues to record its exact exit code and runtime phase.
• Oversized retained output now contributes its first 100 and last 100 lines, separated by an omission marker. Large Paper watchdog dumps therefore retain both their watchdog header and final shutdown result.
• Existing report-count, redaction, confinement, per-line, and byte-size bounds remain unchanged.

Living Documentation

• Current manuals now describe the current supported behavior instead of carrying an accumulating RC-by-RC feature history.
• Exact version references remain only where they identify the current artifact or tested compatibility stack, or define release/security mechanics.
• Historical behavior, changes, and version-specific upgrade instructions remain available in release notes and in the documentation stored at each Git tag.
• Canonical manuals now form a shallow topic tree rooted at DOCS/README.md. Setup, blueprints, operations, networking, integrations, compatibility, extensions, and development each have a focused branch landing page instead of sharing one crowded file layer.
• Newcomer-facing pages now lead with short task-based paths. Host prerequisites, blueprint terminology, diagnostic retention mechanics, and contributor-only tooling remain available through focused references or expandable detail instead of interrupting the first working setup or recovery path.
• Forwarding setup now treats the secret generated by Velocity or the hosting panel as authoritative. Operators are directed to reuse the configured file and matching relative path; manual secret creation is only a fallback when the file is genuinely absent.
• GitHub community entry points now include root-level contributing, support, security, and conduct policies. Structured issue forms route ordinary bugs and feature requests separately from private security reports.
• Reviewable Wiki source now mirrors the task-first documentation model, generated-forwarding-secret guidance, split backend-integration paths, and community support routes while keeping DOCS/ canonical.
• Backend-messaging documentation now includes a complete NPC/menu quick start: Paper sender setup, exact source authorization, direct matchmaking, optional allowlisted command relay, player-context requirements, and troubleshooting. It also documents the separate security and setup model for generic third-party command forwarders without depending on a particular plugin. A concise hub now routes operators to separate built-in and third-party guides.

Upgrade From RC.2.2

1. Stop Velocity normally and confirm its managed child processes have exited.
2. Back up the complete plugins/sls-lite/ directory and installed plugin JAR as one matching restore set.
3. Replace only the plugin JAR with 0.1.0-rc.2.3; do not use a plugin hot-reloader. No configuration or blueprint migration is required.
4. Optionally inspect legacy internal/persistent-file-backups/. SLS-LITE will leave it untouched; remove it only if your own recovery policy no longer needs those files.
5. Start Velocity and review /sls system, blueprint readiness, and the detailed log. Verify persistent-file publication and one normal instance lifecycle before returning the host to service.

Operators upgrading from RC.2.1 or earlier must also apply the RC.2.2 blueprint player-cap migration from server.limits.max_players to annotations.sls-lite.max-players. Do not attempt an in-place downgrade after persistent state has been used; stop the proxy and restore the matching data directory and JAR backup instead.

Compatibility and Known Boundaries

• The SLS-LITE Java API and blueprint schema are unchanged from RC.2.2.
• Java 21 plugin bytecode remains supported on the tested Java 25 Velocity runtime. Host, storage, forwarding, protocol, and full-SLS compatibility boundaries are unchanged.
• SLS-LITE reports and recovers managed child-process failures, but cannot prevent Paper watchdog exits caused by host suspension or resource starvation.
• Cleanup of every unreachable directory after all possible failed or cancelled start phases remains assigned to RC.3 because it requires broader lifecycle and reconciliation work.

Use the current installation guide, migration guide, compatibility matrix, and troubleshooting guide. Report candidate issues with the SLS-LITE version, host capability summary, relevant detailed-log excerpt, and a minimal redacted configuration or blueprint.