Release readiness

This checklist records the evidence used to move the supported baseline into a release candidate and the remaining work before publishing 0.1.0 as stable. Marketplace approval is an important distribution milestone, but it does not replace compatibility, security, upgrade, or production-readiness evidence.

The first target is a release candidate for 0.1.0. New roadmap features do not block that release unless they are advertised as supported. Items described as modeled or future work may remain deferred.

Already in place

• Approved listing in the Convex Components marketplace.
• Public npm prerelease under the next tag with a guard against publishing a prerelease to latest.
• CI runs formatting, tests, typechecking, production builds, and package creation on pull requests and pushes to main.
• Maintainer manual validation covers the web client and real mobile devices against a Convex development-cloud deployment, including the supported messaging, attachment, presence, and reconnect flows.
• Public component functions declare argument and return validators.
• Host-authentication and component-membership boundaries are documented.
• Runnable Next.js and Expo examples cover the supported user flows.
• README, changelog, contribution guide, license, code of conduct, issue templates, and private vulnerability-reporting policy are present.

Required before a release candidate

• Freeze the supported contract. The maintained supported-contract page, API snapshot, validators, and tests define the public exports, errors, schema boundary, limits, pagination, and reply-deletion semantics.
• Complete the authorization and invariant test matrix. Cover read_write, read_only, none, inactive membership, cross-scope access, direct/group creation constraints, revision conflicts, deletion, attachments, reactions, and presence for every public operation.
• Add adversarial and concurrency tests. Cover concurrent conversation creation, sequence allocation, send retries, idempotency payload conflicts including reply targets, monotonic read watermarks, reaction replacement, and pagination while new messages arrive.
• Test input and resource limits. Bound and test external identifiers, titles, message text and captions, attachment metadata, pagination, and the documented 100-member cap.
• Install the packed artifact in a clean consumer fixture. CI creates and installs the tarball without workspace source aliases, typechecks component registration and an authenticated host wrapper, imports the optional test registrar, and checks package exports. Convex development-cloud code generation and runtime behavior are covered by maintainer validation.
• Test the claimed compatibility range. The packed-consumer suite passes on Node 20 and 22 against Convex 1.43.0 and the current npm latest release in the committed CI matrix.
• Define schema upgrade and rollback practice. UPGRADING.md identifies behaviorally breaking changes, staged index and optional-field migrations, deployment order, rehearsal evidence, and rollback boundaries. The 0.0.1 placeholder has no component data to migrate into 0.1.0.
• Run a focused security review. Review non-disclosure behavior, cross-scope isolation, host identity derivation, attachment authorization, presence tokens, error leakage, abuse limits, and dependency exposure. Findings and accepted host boundaries are recorded in SECURITY_REVIEW.md and resolved findings have regression tests.
• Bound the supported operating envelope. All public transaction-shaping inputs, page sizes, attachment metadata, and membership fan-out have documented hard limits. Formal production-tier performance claims are not required for the 0.1 baseline.

Required to publish 0.1.0 to latest

• Cut at least one release candidate and give adopters a documented feedback window with no unresolved critical or high-severity defects.
• Verify the live documentation and examples against the exact release candidate tarball, including a clean install from the documented commands.
• Move every user-visible change into a dated changelog section and write migration notes for every breaking API, data-model, or behavior change.
• Run the full CI suite from a clean checkout, verify the tarball contents and package exports, then create the version commit and Git tag.
• Publish the non-prerelease version to npm, move the latest tag only after verification, and smoke-test installation from the public registry.
• Replace alpha wording and badges across the repository, package README, website, documentation, security policy, and issue templates.

Recommended follow-ups

• Accept the completed real-device and web development-cloud validation as the 0.1 end-to-end evidence; repeat it for behaviorally breaking changes.
• Add a coverage report and fail CI when critical component modules or authorization branches regress below the agreed threshold.
• Add API declaration and package-export snapshots so accidental public contract changes are reviewed explicitly.
• Add documentation link checking and automated dependency updates.
• Add a guarded repeatable release workflow with dry-run verification and npm provenance.
• Define supported-version and security-fix windows once real adopters rely on the package.

Explicitly not blockers

The roadmap's group administration lifecycle, notification events, delivery receipts, notification preferences, search, mentions, pins, retention, polls, and other future messaging features are not required for the 0.1 stable release. They must remain accurately described as unavailable until their authorization, tests, documentation, and upgrade semantics are complete.