hailer 0.1.0 → 0.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 9438bee546359ce97506f8c5111ffb1eed0d1fe187a4632385e11f61e37c574a
-  data.tar.gz: 1945fc1ab7fec8409cdea1a9de9e82347d204afbeb98226c864ea27d46713011
+  metadata.gz: 141f02c631f9a0c14ee84232561c516e40a33f9e0683ae31112c293a98011174
+  data.tar.gz: 3881311e389ab55c5b4d79c847f8c4f6da945666379bdfac998bdb534d7b3566
 SHA512:
-  metadata.gz: 91f53a1872615cca824ddaf029b073baa144f94dad7163b92fcb2c03ff1e687a24d8e65a4813516ff3a5339ef5d348103965c4719c68a18cae2c9a5aac4bfdca
-  data.tar.gz: 921b031e5486c6b6757e3ccb9d8673d0c3a6f7dd2c8aa4cb4be85b596f93572b167b8cc411ae01d8f33c0af9b72a6069b5af4f08d8257e2968092f7fef724a1d
+  metadata.gz: 1ed05d6d91f27d9054f19267d7a620cbb4bee68ab218dafc7f3a284e8403363414faff7c2cb83228f6987a326cc3c457d825eb0f5898634dfaefa60d1ee805fc
+  data.tar.gz: b485850221aac71b4634e06c55b12e0d605c9de789e9390f1227133b278921dd807f1bf575602829d93aa0e708df14b91149ad4679c9bbce01ccd0c95cc0e92a

data/CHANGELOG.md

@@ -1,6 +1,29 @@
 # Changelog
 
-## 0.1.0 (unreleased)
+## Working tree — durable delivery (unreleased)
+
+- Opt-in `:hailer_queued` Rails adapter with stable job keys and frozen intake retries.
+- PostgreSQL ownership receipts, immutable submission replay/conflict and explicit spool budgets.
+- Supervised fenced dispatch, journaled attempts, safe retries and held unknown outcomes.
+- Tagged SES feedback correlation, recipient facts, audited cancellation and resolution.
+- Deadline/body retention, independent lifecycle feed and intake/dispatcher readiness.
+- Native Rust future traits without `async-trait`; throttle-machines 0.3.1.
+- Current-source CommonShare queued smoke with loopback SES; no production cutover.
+- New Linux binary builds target Debian 13 Trixie (glibc 2.41), with locked GNU Ruby dependency variants.
+- Opt-in pre-send address verification (Emailable first; swappable via `Verifier` enum), `[email_verification]` in `hailer.toml`, cached verdicts in `hailer.address_verifications`. Fails open by default - a verifier outage or `unknown`/`risky` result never blocks a send unless explicitly configured into `reject_states`.
+- Domain/pattern blocklist (`hailer.domain_blocks`): exact domains or `*.`-suffix globs, always active. A small hand-curated disposable-provider list ships with the repo (source `curated`, only changes by upgrading); operators add their own via `hailer ban-domain`/`unban-domain` (source `operator`). Checked before suppression and verification - the cheapest, broadest filter runs first.
+- New `quarantined` message status, queued pipeline only: a non-ASCII recipient domain, or (opt-in `[domain_intel]`, RDAP-backed) a newly registered one, holds the whole message for operator review (`hailer release-quarantine`/`cancel-message`) instead of a hard reject. Excluded from the dispatch index like `held_unknown`; expires on the normal deadline like `queued`.
+
+## 0.2.0 (unreleased)
+
+- PostgreSQL-only live state, with atomic feedback and commit-safe cursors.
+- Resumable, read-only AWS suppression reconciliation scoped by account/region.
+- Pure behavior admission circuit, per-process throttle, and SES circuit breaker.
+- Single-attempt sends, explicit ambiguous outcomes, and typed rate-limit errors.
+- Private health/readiness sensors, supervised workers, and bounded graceful drain.
+- Explicit read-only migration of stopped 0.1 redb state into an empty database.
+
+## 0.1.0
 
 - Rails 8.1+/Ruby 4.0+ ActionMailer delivery with automatic defaults.
 - Typed provider-neutral feedback client and Rails callback consumer.

data/README.md

@@ -2,7 +2,7 @@
 
 Rails writes the email. Hailer deals with sending it.
 
-This repository ships two things at version **0.1.0**:
+This repository prepares two things at version **0.2.0** (not published yet):
 
 - **`hailer` gem** — an ActionMailer adapter, feedback client, and executable
   launcher. Platform gems bundle the Rust binary. No Ruby AWS SDK or native extension.
@@ -13,6 +13,12 @@ This repository ships two things at version **0.1.0**:
 ActionMailer → hailer gem → private Mothership route → hailer binary → SES
 ```
 
+The working tree also implements an **opt-in durable queued adapter**. See
+[durable delivery](docs/durable-delivery.md) for ownership, recovery, routing
+and operator controls. It is not included in the preserved 0.2 release
+candidates. Current-source macOS, ARM64 Linux and x86_64 Linux verification
+gates pass locally; this work has not been published or deployed.
+
 ## Rails
 
 Requires Ruby 4.0+ and Rails 8.1 or newer within Rails 8.x.
@@ -78,7 +84,7 @@ name = "hailer"
 command = "hailer"
 workers = 0
 threads = 2
-routes = [{ bind = "mail", pattern = "^/internal/mail/send$" }]
+routes = [{ bind = "mail", pattern = "^/internal/mail/(send|events|health|ready)$" }]
 ```
 
 Mothership exports `MS_PID`, `MS_SHIP`, and `MS_SOCKET_DIR`. Hailer binds its
@@ -90,6 +96,31 @@ Give the **service**, not the Rails adapter, AWS region and credentials through
 the standard AWS credential chain. Its identity needs `ses:SendEmail`, and the
 SES account/identities must be configured for sending.
 
+### PostgreSQL
+
+PostgreSQL is the **only live backend** in 0.2. Hailer owns a `hailer` schema,
+not Rails tables. Use a separate database/role where practical:
+
+```sh
+export HAILER_DATABASE_URL='postgres://hailer:password@db/hailer?sslmode=verify-full'
+hailer migrate
+```
+
+Supply the database CA through the normal PostgreSQL connection options.
+Use certificate verification in deployment; a private network is not TLS.
+Keep the URL in a secret manager, not TOML or a committed initializer.
+Startup also applies embedded, versioned migrations. The bootstrap identity
+needs database `CREATE` and ownership of its schema/tables. Runtime startup
+currently runs that same bootstrap/migrator, so provision the service role for
+it too; a separate DML-only runtime mode is not implemented.
+The runtime never needs Rails schema ownership. Back up the database with your
+normal PostgreSQL backup/restore tooling.
+
+Configuration defaults: pool size 5 (range 1–64), shutdown timeout 30 seconds
+(range 1–300). Every replica shares PostgreSQL; each has its own pool and optional
+rate budget. Set your supervisor/container stop grace longer than Hailer's
+shutdown timeout. PostgreSQL 18 is exercised locally and in CI.
+
 ## Bounces, complaints, and suppressions
 
 ```text
@@ -97,7 +128,7 @@ SES → SNS → dedicated SQS queue → Hailer → durable events + suppressions
 ```
 
 Hailer atomically commits each event, deduplication key, and suppression change
-to a local redb database **before** acknowledging SQS. Failed acknowledgements
+to PostgreSQL **before** acknowledging SQS. Failed acknowledgements
 can be retried without duplicating stored events. Invalid/untrusted messages
 are left for SQS's dead-letter policy.
 
@@ -113,14 +144,16 @@ are left for SQS's dead-letter policy.
 Copy [hailer.example.toml](hailer.example.toml), set the real queue/topic, and
 pass `--config /path/to/hailer.toml` or `HAILER_CONFIG`. Without `[feedback]`,
 the consumer is disabled, but previously stored suppressions are still enforced.
-`HAILER_STATE_PATH` overrides `state_path`; the default is `data/hailer.redb`.
-Use a persistent, private volume in production.
+`HAILER_DATABASE_URL` is required, even with feedback disabled.
+The old `state_path`, `--state-path`, and `HAILER_STATE_PATH` are not supported.
+Replicas may consume the same dedicated queue when they share the same Hailer
+database. Commits serialize cursor allocation so a reader cannot skip an earlier
+transaction that has not committed yet.
 
-**One Hailer process owns one state file and one dedicated queue.** Run the
-bay with `workers = 0`; this is not a distributed suppression database.
-Do not run competing consumers with separate state files. Back up the state
-file while Hailer is stopped; event history and deduplication currently have
-no automatic retention/pruning.
+Event history and deduplication have **no automatic retention/pruning**.
+Do not delete events casually: event IDs also carry the SQS deduplication
+contract, and Rails consumers may still need their cursors. Plan retention
+against consumer lag and redelivery windows before adding a pruning policy.
 
 Hailer also exposes a provider-neutral, nondestructive event feed:
 
@@ -157,12 +190,159 @@ updates in one application database transaction. Retried pages require
 idempotent handlers; no hidden poller, scheduling, or checkpoint database is
 started by the gem. Reading does not acknowledge or erase events.
 
-See [feedback setup and migration](docs/feedback.md) before removing a receiver.
+The SQS policy must allow only the intended SNS topic, using `aws:SourceArn`
+and account restrictions. Subscribe with `RawMessageDelivery=false`, restrict
+direct `sqs:SendMessage`, set a dead-letter queue, and monitor its depth.
+The SNS topic allowlist in TOML is defense in depth, not signature verification.
+Hailer needs `sqs:ReceiveMessage` and `sqs:DeleteMessage` on that queue, plus
+applicable KMS decrypt permissions if customer-managed encryption is used.
+
+### Import AWS suppressions
+
+```sh
+hailer sync-suppressions
+# If AWS expires a saved pagination token:
+hailer sync-suppressions --restart
+# Existing application export, JSON array:
+hailer import-suppressions --file suppressions.json
+```
+
+The service identity needs `ses:ListSuppressedDestinations`; STS
+`GetCallerIdentity` identifies the account (AWS does not require an explicit
+allow for that operation). The configured region is part of the source identity.
+These commands **read AWS only**; they never mutate the account suppression list.
+Missing AWS entries do not unsuppress local entries, and a bounce never
+downgrades a complaint. Imports do not fabricate delivery-history events.
+Account-level AWS data does not include every possible global SES suppression.
+
+Enable `[suppression_sync]` as in the example to reconcile on startup and hourly.
+The first complete sync gates send readiness. Later errors mark health degraded,
+retain committed pages, and retry safe reads with bounded backoff. A token is
+stored with its page in one transaction. Replicas coordinate a source-scoped
+advisory lock; they cannot advance the same checkpoint concurrently.
+An expired token deliberately requires the operator's `--restart`. Omitting
+the section disables scheduled sync, not existing suppression enforcement.
+
+### Control plane
+
+The behavior circuit evaluates **pure admission decisions**: input validity,
+service/storage readiness, suppression, and local rate admission. PostgreSQL,
+AWS calls, clocks, and token reservations remain owned by the async host.
+The SES circuit breaker counts transient/ambiguous failures, not bad addresses
+or permanent request rejections. An optional `[rate_limit]` budgets envelope
+recipients **per process**, not per account; it does not discover SES quotas.
+
+Private `GET /internal/mail/health` returns sanitized component states and
+counters. `GET /internal/mail/ready` returns 503 during initial sync or storage
+failure, otherwise 200. A provider circuit can be degraded while readiness
+remains true so protected half-open probes can recover it. No credentials,
+recipient addresses, message bodies, or pagination tokens appear in these sensors.
+They are operational signals, not a guarantee SES will accept a message.
+
+TERM/ctrl-c stops admission and SQS receives, then drains owned requests and
+the current feedback commit/ack within the configured deadline. Idle links
+close immediately. Deadline expiry aborts remaining tasks and exits nonzero;
+an interrupted send can have an unknown outcome.
 
 **Security:** the route currently has no application-level authentication.
 `/internal/` is a name, not an access control. Keep the bind private. The client
 does not follow redirects or use environment HTTP proxies.
 
+## Impossible addresses
+
+Always on, no configuration: `toto@example.com` is syntactically a real
+address, but RFC 2606 reserves `example.com`/`.net`/`.org` and the
+`test`/`example`/`invalid`/`localhost` TLDs for documentation - no real
+mailbox ever lives there. Rejected at the same boundary as a malformed
+address (`SendRequest::validate`), before any guard in the chain runs, for
+both the synchronous and queued adapters. Not a policy choice like the
+domain blocklist below - there is nothing to configure or an operator could
+turn off.
+
+## Domain blocklist
+
+```text
+SendRequest -> impossible-address check -> domain blocklist (free, local) -> suppression (free, local) -> verification (paid, external) -> SES
+```
+
+Always active - an empty `hailer.domain_blocks` table is a no-op, there is
+no toggle. A pattern is an exact domain (`guerrillamail.com`) or a
+`*.`-prefixed suffix glob (`*.kp` matches that domain and any subdomain).
+A small hand-curated list of known disposable-mail providers ships with the
+repo (`source = 'curated'`, migration `05_domain_blocks.sql`); it only grows
+by upgrading Hailer, never fetched from a third party at runtime. Operators
+add their own:
+
+```sh
+hailer ban-domain --pattern "*.kp" --reason "sanctioned TLD"
+hailer unban-domain --pattern "*.kp"
+```
+
+`unban-domain` only removes an `operator`-sourced pattern - a curated one
+cannot be removed this way, by design.
+
+## Address verification
+
+```text
+SendRequest -> suppression check (cheap, local) -> address verification (paid, external) -> SES
+```
+
+Opt-in pre-send deliverability check, off by default. Enable with
+`[email_verification]` in `hailer.toml`:
+
+```toml
+[email_verification]
+provider = "emailable"
+reject_states = ["undeliverable"]  # risky/unknown fail open unless added here
+cache_ttl_seconds = 604800
+timeout_seconds = 5
+```
+
+Set `EMAILABLE_API_KEY` in the process environment, never in `hailer.toml` -
+the same rule as `HAILER_DATABASE_URL` and AWS credentials. Suppression
+filters first since it is a free local lookup; verification only runs for
+recipients that survive it, so a suppressed address never costs a paid
+lookup. Verdicts are cached in `hailer.address_verifications` (a week by
+default) - a retried send against the same address reuses the cached verdict
+instead of paying for another check.
+
+A verifier outage, timeout, or an `unknown`/`risky` result all fail open: this
+middleware is never a new reason a real send stops working unless a
+deployment explicitly adds those states to `reject_states`. Adding another
+provider (ZeroBounce, NeverBounce, ...) means a new `Verifier` enum variant in
+`src/verify.rs`; nothing else in the send path changes.
+
+### Bulk pre-screening (batch)
+
+A separate concern from the real-time guard above: pre-verify a whole list
+*before* ever trying to send to it, not a per-send check. Emailable's batch
+API is async (submit, then poll) and only returns per-address results inline
+for batches up to 1,000 - larger ones get a ZIP/CSV download link this client
+deliberately does not fetch or parse, to avoid a zip/csv dependency:
+
+```sh
+hailer verify-batch --file addresses.txt   # one address per line, max 1000
+hailer batch-status --id BATCH_ID          # poll; caches each verdict once complete
+```
+
+`batch-status` writes every returned verdict into `hailer.address_verifications`
+(the same cache the real-time guard reads), so a later send to an
+already-screened address reuses the cached verdict instead of paying for
+another single-address check. A batch over 1,000 addresses is reported with
+its `download_file` URL but is not cached - split into smaller batches
+instead.
+
+`verify-batch` never submits an address that does not need it: exact
+duplicate lines (by the same normalized key the cache itself is keyed by -
+`USER+alias@x` and `user@x` are the same address), and anything already in
+`hailer.address_verifications` with an unexpired verdict, are dropped before
+the batch is ever submitted - never spending a credit on them. Every
+exclusion is counted and reported (`invalid_lines`, `duplicate_lines`,
+`already_cached`), never silently dropped. `hailer emailable-account` checks
+the Emailable account's remaining credits directly; `submit_batch` itself
+also checks this before submitting and refuses (without ever reaching the
+server) if the account has none left or fewer than the batch needs.
+
 ## Failure semantics
 
 An HTTP 200 means **SES accepted the message**, not that the recipient received
@@ -172,28 +352,47 @@ it. A successful response must include a nonblank `message_id`.
 | --- | --- |
 | HTTP 400 / 422 | `Hailer::ValidationError` |
 | HTTP 502 | `Hailer::RejectedError` |
+| HTTP 429 | `Hailer::RateLimitedError` |
+| HTTP 503, `code: "outcome_unknown"` | `Hailer::AmbiguousDeliveryError` |
 | HTTP 503 | `Hailer::UnavailableError` |
 | Other non-200 status | `Hailer::DeliveryError` |
 | Invalid/oversized response, missing message ID | `Hailer::ProtocolError` |
 | Connection, TLS, or timeout failure | `Hailer::TransportError` |
 | Missing/invalid endpoint or timeout settings | `Hailer::ConfigurationError` |
 
-The gem does not retry. A lost response can happen **after** SES accepted the
-message; retrying may duplicate it. There is no durable **outbound** queue or
-send-idempotency store yet; feedback deduplication does not deduplicate sends.
+The synchronous adapter does not retry. A lost response can happen **after** SES
+accepted the message; retrying may duplicate it. This route does not use the
+opt-in outbound spool or its submission-key deduplication.
 Rails jobs can also retry, so configure them deliberately.
-The current service maps all SES SDK send errors to HTTP 502; that status is
-not yet a reliable distinction between permanent and transient AWS failures.
+The SES SDK makes **one send attempt**. AWS throttling/transient failures return
+503, permanent service rejections 502, and disconnects/timeouts/missing message
+IDs carry the explicit unknown-outcome code. None of these responses authorizes
+an automatic retry of an ambiguous send.
 
 ## Status and migration
 
 The delivery contract and Hailer-side feedback processing are implemented. CommonShare's
 existing sender is the compatibility reference, not a runtime dependency.
-See [the contract](docs/delivery-contract.md).
+
+### Upgrade from 0.1 redb
+
+1. Stop all old Hailer processes cleanly. Keep the source file and a backup.
+2. Provision an **empty** Hailer PostgreSQL database and set its URL.
+3. Run `hailer migrate-redb --file /private/path/state.redb`.
+4. Check reported counts, event cursors, and suppression enforcement before
+   starting 0.2. Keep the source backup; do not restart old writers after cutover.
+
+Migration opens redb read-only, checks event/dedup mappings and suppression keys,
+and copies bounded batches in **one destination transaction**. It preserves
+event IDs, sequence values, suppression metadata, and next-cursor continuity.
+It rejects missing/corrupt sources and nonempty targets without wiping anything.
+An unclean redb file may require recovery with the old version against a backup
+before migration. There is no implicit fallback and no dual-write period.
 
 Before switching an existing app:
 
-1. Run Hailer on a private Mothership bind and verify real SES delivery.
+1. Provision PostgreSQL, run Hailer on a private Mothership bind, check readiness,
+   and verify real SES delivery using a deliberate test.
 2. Add the gem, set `HAILER_URL`, and remove the app's old delivery-method
    override so Hailer's default takes effect.
 3. Subscribe a dedicated SQS queue before exporting and importing existing
@@ -202,22 +401,26 @@ Before switching an existing app:
    and any provider-neutral app history consumer have been verified.
 5. Only then remove the old sender and AWS-specific feedback handling.
 
-CommonShare's local integration is tested with its real application, database,
-Mothership, packaged Hailer binary, and a loopback SES fixture. Its existing AWS
+CommonShare's local 0.2 integration is tested with its real application,
+test database, Mothership, the optimized binary from the macOS gem, its installed 0.1 Ruby
+client, and a loopback SES fixture. Its existing AWS
 receivers remain until the real subscription and suppression cutover is verified.
 No deployed AWS routing has been changed.
-Account diagnostics, validation/behavior plugins,
-distributed state, rate limiting, graceful draining, and reliable send-error
-classification are later work. No plugin API is promised yet.
+The current-source queued adapter and dispatcher also pass a CommonShare smoke
+using an isolated Bundler Gemfile, real Mothership and loopback SES. No app
+Gemfile or production configuration was changed. Its legacy history observer
+still needs queued-ownership semantics before opt-in deployment.
+Validation/behavior plugins and distributed account-wide quotas remain later
+work. No plugin API or provider exactly-once delivery is promised.
 
 ## Development
 
 ```sh
 bundle install
 bundle exec rake
-cargo test --locked
+HAILER_TEST_DATABASE_URL=postgres://test_user:password@127.0.0.1/hailer_test cargo test --locked
 cargo fmt --all -- --check
-gem build hailer.gemspec --output /tmp/hailer-0.1.0.gem
+gem build hailer.gemspec --output /tmp/hailer-0.2.0.gem
 bundle exec rake native:package
 ```
 
@@ -225,17 +428,81 @@ The Ruby suite exercises real local HTTP exchanges and a booted Rails app.
 The Rust suite checks the same JSON fixture and the docking exchange with a
 fake provider. Feedback tests cover redelivery, acknowledgement ordering,
 atomic rollback, restart persistence, imports, and suppression enforcement.
-Neither suite sends real mail or requires AWS credentials.
+Rust tests require an isolated PostgreSQL server and a test role with `CREATEDB`;
+each test creates and drops its own database. Never point this variable at a
+customer or Rails production database. Neither suite sends real mail or requires
+AWS credentials.
+
+For the opt-in CommonShare compatibility smoke, create a disposable Hailer
+database, then run from that application's checkout:
+
+```sh
+RAILS_ENV=test HAILER_SMOKE_BINARY=/path/to/hailer/target/debug/hailer \
+  HAILER_DATABASE_URL=postgres://test_user:password@127.0.0.1/hailer_smoke \
+  bundle exec rails runner /path/to/hailer/test/commonshare_smoke.rb
+```
+
+It refuses a non-test app database, points the AWS SDK at a loopback fixture,
+and rolls back application-history changes. It does not change the app's
+dependency lockfile or send external mail.
 
 `native:package` builds a locked release and writes
-`pkg/hailer-0.1.0-<platform>.gem`. Each platform gem contains exactly its host
+`pkg/hailer-0.2.0-<platform>.gem`. Each platform gem contains exactly its host
 binary and a version/platform/SHA-256 manifest. The launcher verifies that
 manifest before `exec`, preserving arguments, exit status, and signal handling.
 `HAILER_BINARY` is an explicit, version-checked source-build override; there is
 no download or PATH fallback.
 
-Build on each supported release host before publishing its artifact. Only
-`arm64-darwin` has been built and exercised in this checkout. Linux GNU builds
-must use your intended minimum-glibc build environment; a native build on a
-newer distro is not automatically portable to older distributions. Nothing in
-the packaging task publishes a gem.
+Build on each supported release host before publishing its artifact. Nothing
+in the packaging task publishes a gem.
+
+## Linux releases and RubyGems
+
+The **Linux binary gems** GitHub Actions workflow builds `x86_64-linux-gnu`
+and `aarch64-linux-gnu` natively against Debian 13 Trixie (glibc 2.41).
+New Trixie-built artifacts target glibc 2.41 or newer, not Bookworm or
+Alpine/musl. The preserved older 0.2 candidates retain their original baseline.
+Local OrbStack verification uses `test/linux/Dockerfile` for each architecture
+and a separate `ruby:4.0-slim-trixie` runtime.
+Use a copied checkout in separate per-architecture Docker work volumes; do not
+reuse the macOS `target/` or Ruby bundle. Run the locked Ruby tests, release Rust
+tests and `native:package` with an isolated PostgreSQL fixture, then install each
+gem in its slim runtime and exercise the launcher, migrations and import CLI.
+When transferring a macOS snapshot, use `COPYFILE_DISABLE=1 tar --no-xattrs`
+so AppleDouble `._*` metadata cannot appear as spurious SQL migrations.
+
+```sh
+gh workflow run linux-gems.yml --repo seuros/hailer -f tag=v0.2.0
+```
+
+The workflow checks out the requested release tag, runs the Ruby and Rust
+suites against an isolated PostgreSQL 18 service, and installs each binary gem
+in a separate slim Debian container. Pushes/PRs also verify the branch without
+creating a release or publishing anything; only explicit workflow dispatch
+can attach assets to an existing release.
+It verifies the installed platform, bundled-binary manifest, executable version,
+and PostgreSQL suppression import before attaching either Linux gem to the
+existing release. Existing gem assets are never overwritten; `SHA256SUMS` is
+updated to cover all release gems.
+
+Publishing a GitHub release does **not** publish to RubyGems. Like Shuttlebay,
+release assets can be fetched and published with Rake:
+
+```sh
+bundle exec rake gems:fetch
+bundle exec rake gems:push_all
+# Or select an explicit release:
+bundle exec rake 'gems:push_all[v0.2.0]'
+```
+
+`gems:push_all` fetches fresh assets, checks every archive's SHA-256,
+name/version/platform, and publishes only that verified set. It skips
+already-published platforms only when RubyGems reports the identical archive
+hash, so an interrupted publication can be resumed without replacing artifacts.
+`gems:push` is an alias. No release task rebuilds or silently republishes gems.
+
+RubyGems may require MFA or a suitably scoped API key. Keep credentials out of
+the repository. Publishing makes the packaged Ruby code and binaries public,
+even when the GitHub repository is private. Once published, Bundler selects
+the matching native gem; do not set `force_ruby_platform` in deployment if
+you want the bundled executable.