ReallyMe Release Readiness

Shared release-readiness guardrails for ReallyMe repositories.

This package contains a small, dependency-free Node.js core used by ReallyMe release scripts. Sister repositories can vendor the core byte-for-byte for offline local use. Remote CI should execute the current shared repository runner so policy fixes do not remain trapped in stale local copies.

What It Checks

• Git-tracked release inputs and repository-contained paths.
• GitHub Actions pinned to full commit SHAs, with Node jobs pinned to Node 24.
• Cargo workspace metadata, package surfaces, dependency sources, and publish policy.
• SPDX headers for tracked source files.
• Protobuf schema contracts, generated output freshness, and adapter boundary checks.
• Generated protobuf hardening checks for redacted Debug output, strict ProtoJSON, zeroizing temporary byte owners, recursive unknown-field wiping, and final-owner zeroization.
• Command matrices for repository-specific release suites.

The current vendored-core contract marker is:

assertContains(
  "scripts/release-readiness/core.mjs",
  "RELEASE_READINESS_CORE_CONTRACT_VERSION = 6",
);

Usage

Run this repository's checks with:

npm run check

The GitHub Actions workflow runs the same command on Node 24.

Consumer repositories usually vendor the core into their local release scripts:

cp core.mjs ../crypto/scripts/release-readiness/core.mjs
cp core.mjs ../cose/scripts/release-readiness/core.mjs

Remote CI must pin this repository by a reviewed full commit SHA. Never use a mutable branch or tag in a credential-bearing workflow:

npm exec --yes --package=github:reallyme/release-readiness#FULL_COMMIT_SHA -- \
  reallyme-release-readiness

Arguments after reallyme-release-readiness are passed to the consumer's scripts/check_release_readiness.mjs. The runner requires the tracked vendored core to be byte-for-byte identical to its immutable upstream core before it runs the consumer checker.

For a new Rust/protobuf repository, start from templates/check_release_readiness.mjs and the companion templates/README.md. The template fails closed until every REPLACE_* marker has been replaced.

Generated protobuf freshness checks should snapshot generated outputs, run buf lint, buf generate, the repository hardening script such as harden-generated-example-proto.mjs, and cargo fmt, then compare the updated generated tree plus every tracked or non-ignored file outside the declared generated directories. Hardening scripts must also support --check-idempotent; repository checkers run that mode against checked-in output so a second pass cannot accumulate comments, derives, debug implementations, or drop implementations.

Protobuf Notes

Protobuf identifiers are ReallyMe wire identifiers, not provider registry values. assertProtoContract requires neither sparse nor sequential numbering; it rejects invalid field-number ranges, duplicate identifiers, and reuse of reserved names or numbers.

When a shared field name is sensitive only in one generated message, declare it as { message: "MessageName", field: "field_name" } so hardening assertions are scoped to that message.

The executable adapter boundary is intentionally narrow: the proto crate owns messages only, exposes no protobuf service, accepts binary protobuf and generated ProtoJSON requests, and returns the same binary status/payload result envelope from both paths.

License

Licensed under the Apache License, Version 2.0. See LICENSE.

Copyright and Trademarks

Copyright © 2026 by ReallyMe LLC.

ReallyMe® is a registered trademark of ReallyMe LLC.