The release candidate is intentionally boring in the right places
Kodari is already usable as a browser-based Android Java and XML learning environment. The current v1.9.10 line is about making that experience dependable enough for a controlled beginner pilot and, later, Public Beta.
That changes the development question from “what else can Kodari do?” to “what happens when a browser reloads, a connection drops, two devices touch the same project, an account changes, or old cached code meets a new deployment?”
What is being proved
The deployed candidate has cleared 25 of 25 production zero-data-loss checks in the current evidence set. Hosting/origin parity, App Check visibility, account isolation, browser resilience, multi-device behavior, viewport coverage, pilot smoke, and save/recovery scenarios are also part of the release gate.
The point is not the number by itself. The useful part is turning common failure modes into repeatable checks so a release decision is based on evidence rather than on whether the happy path looked fine once.
Why it is still a release candidate
Public Beta is deliberately still a boundary, not a label being used early. Hard browser/process-crash timing, the real old-service-worker to new-service-worker transition, final physical sanity checks, and the controlled beginner pilot still need to clear.
The next milestone is not “more features.” It is a smaller uncertainty surface around saving, recovery, compatibility, and what students experience on real devices.