hailer 0.3.1 → 0.5.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8cfb76f161f5c19fc25619cf4f8ee00260f72308817757f7dc97c60a6faf5a77
-  data.tar.gz: 5e02c982a4d7a0f74a3c55ddce1db73c6745a3e5b26e138505177b79bd9fd6f4
+  metadata.gz: 00f5d9ebd2dd587d6f2824487642a03c4d9bef5c6047d3f898975199b6c89745
+  data.tar.gz: 6580ca42145825de17fa3096eabf5b13d76f863e62a27a6ed86dfe56c4e0e6a7
 SHA512:
-  metadata.gz: 1ac351a5ef316733f4ad68a5a8a1d70518280acdf2168d56a2c429c11daf819ddaf139300fc84d13f30fc11e34a7600bf936db951325f43a5eafac47f1adab05
-  data.tar.gz: 6e523d30652e08ac572d0f3c45f3359e634f008f7e0bd52ee8fbde1f85a43553eff95351651c1553feb7ae53fe70bc9f96abecb732fac42a8c76262351293b15
+  metadata.gz: 3c50b744278952684d7b5984eab32a927885c591202be50fd734a44adca9661a2119573888fd954d91a5174294616aa8b40aa4207332864c4c9e26baa0968314
+  data.tar.gz: 73455d8ee3c97a0e948c6b9dab75a5f0ea2efdff910417c60f7996d84c197c4c2adc1ffd0ef51de21b3512c55aeab24c00772290f2c244f74e9280b9d191b406

data/README.md

@@ -2,7 +2,7 @@
 
 Rails writes the email. Hailer deals with sending it.
 
-This repository prepares two things at version **0.2.0** (not published yet):
+This repository is two things:
 
 - **`hailer` gem** — an ActionMailer adapter, feedback client, and executable
   launcher. Platform gems bundle the Rust binary. No Ruby AWS SDK or native extension.
@@ -13,11 +13,9 @@ This repository prepares two things at version **0.2.0** (not published yet):
 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.
+An **opt-in durable queued adapter** sits alongside the default synchronous
+send path. See [durable delivery](docs/durable-delivery.md) for ownership,
+recovery, routing and operator controls.
 
 ## Rails
 
@@ -25,7 +23,6 @@ Requires Ruby 4.0+ and Rails 8.1 or newer within Rails 8.x.
 Rails main (8.2 alpha) is also exercised in CommonShare. Older releases are not supported.
 
 ```ruby
-# Gemfile (use path: "/path/to/hailer" while developing)
 gem "hailer"
 ```
 
@@ -98,7 +95,7 @@ SES account/identities must be configured for sending.
 
 ### PostgreSQL
 
-PostgreSQL is the **only live backend** in 0.2. Hailer owns a `hailer` schema,
+PostgreSQL is the **only live backend**. Hailer owns a `hailer` schema,
 not Rails tables. Use a separate database/role where practical:
 
 ```sh
@@ -343,6 +340,21 @@ 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.
 
+### SES account diagnostics
+
+Operator-only, standalone (no Mothership, no docking - same tier as
+`migrate`/`sync-suppressions`), for checking the AWS side of mail delivery
+without ever sending anything:
+
+```sh
+hailer ses-account                                        # quota, reputation, enforcement status
+hailer ses-identities --identities commonshare.com,insights.commonshare.com
+```
+
+`ses-identities` checks each comma-separated identity independently - one
+unverified or nonexistent identity is reported inline (`error`/`code`) and
+never stops the others from reporting.
+
 ## Failure semantics
 
 An HTTP 200 means **SES accepted the message**, not that the recipient received
@@ -369,49 +381,14 @@ The SES SDK makes **one send attempt**. AWS throttling/transient failures return
 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.
-
-### 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. 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
-   suppressions. Let Hailer catch up and verify the event feed.
-4. Keep existing receivers/interceptors until routing, suppression import,
-   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 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.
-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.
+## Status
+
+The delivery contract, Hailer-side feedback processing, domain blocklist,
+impossible-address rejection, address verification, the queued/quarantine
+pipeline, and SES account diagnostics are all implemented and shipped.
+`[queued]`, `[domain_intel]`, `[suppression_sync]`, `[feedback]`, and
+`[email_verification]` ship disabled by default - absent config, not
+missing code.
 
 ## Development
 
@@ -420,8 +397,6 @@ bundle install
 bundle exec rake
 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.2.0.gem
-bundle exec rake native:package
 ```
 
 The Ruby suite exercises real local HTTP exchanges and a booted Rails app.
@@ -446,63 +421,8 @@ 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.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. 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.
+Bundler selects the matching native platform gem automatically; do not set
+`force_ruby_platform` in deployment if you want the bundled executable.

data/docs/durable-delivery.md

@@ -1,11 +1,8 @@
-# Durable delivery (in development)
+# Durable delivery
 
 The queued Ruby interface, PostgreSQL spool and supervised dispatcher are
-implemented. CommonShare source-client and installed macOS binary-gem smoke
-tests pass. ARM64 and x86_64 Linux release tests, binary packaging and clean slim
-Trixie runtime checks also pass in OrbStack (x86_64 under emulation).
-Do not enable queued delivery against the existing 0.2 release
-candidates or treat this working tree as a published durable-delivery release.
+implemented and shipped (0.3.0+). It is opt-in: absent `[queued]` config,
+Hailer stays on the synchronous send path and none of this runs.
 
 ## Opt-in Rails configuration
 

data/hailer.example.toml

@@ -17,8 +17,7 @@ interval_seconds = 3600
 # recipients_per_second = 10.0
 # burst = 50
 
-# In development: durable intake requires explicit logical payload budgets.
-# Requires the durable-dispatch build, not the existing 0.2 release candidates.
+# Durable intake requires explicit logical payload budgets.
 # [queued]
 # max_bytes = 268435456
 # max_messages = 10000

data/lib/hailer/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Hailer
-  VERSION = '0.3.1'
+  VERSION = '0.5.0'
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: hailer
 version: !ruby/object:Gem::Version
-  version: 0.3.1
+  version: 0.5.0
 platform: ruby
 authors:
 - Abdelkader Boudih