cloudflare-email 0.4.0 → 0.4.2

data/docs/tenant-mailboxes-plan.md

@@ -1,149 +0,0 @@
-# Tenant-aware mailbox layer — implementation proposal
-
-Status: original design record. The reusable mailbox module and tenant adapter
-are implemented on the feature branch; see [mailboxes](mailboxes.md) and
-[tenant setup](activerecord-tenanted.md) for the actual API. Rebulk application
-migration and live customer rollout remain separate work. Based on the gem's merged 0.2
-code and Rebulk/rebulk-system main at
-`17ffafccb69968dae022acdbb4620b84c65bedfb`.
-
-## Product goal
-
-Let a Rails application create, suspend and manage named mailboxes for its
-organizations, sites or users. Support organization subdomains such as
-`houston@venezia.rebulk.com`. Reuse the gem's transport, outbox and receipts;
-do not create another delivery ledger. SQLite remains the default integration
-target, including separate SQLite databases with `activerecord-tenanted`.
-
-## Rebulk already has the foundations
-
-- `Organization` is shared and carries `email_subdomain`.
-- `TenantRecord` uses `activerecord-tenanted` and requires a tenant context.
-- Sites have per-organization email local parts. `tracking@<org>.rebulk.com`
-  is an existing reserved organization-level destination.
-- `Customer` is a buyer within an organization, not the tenant root. A customer
-  mailbox can belong to that record without creating another tenant database.
-- ActiveStorage is tenant-specific. Mail must resolve its tenant before blob
-  access, persistence or job deserialization that needs tenant records.
-- `InboundEmail` records document-processing outcomes inside the tenant.
-  `CommunicationMessage` is a shared, encrypted cross-channel operational view.
-  Preserve these product roles instead of replacing them with duplicate models.
-- Existing ingest has its own Worker contract, sender authentication and
-  authorization, raw archive and document processing. It is not currently the
-  gem's ActionMailbox pipeline. Its policy cannot be discarded during migration.
-- `OrganizationEmailDomain` supports sign-in auto-join. Receiving-domain
-  ownership must be separate; creating a receiving domain must never grant users
-  membership or change login policy.
-
-## Database and routing boundary
-
-Keep a minimal shared receiving-domain directory: exact canonical domain,
-immutable tenant identity, tenant connection key, lifecycle state and provisioning
-evidence. Enforce domain ownership with a database uniqueness constraint. Never
-construct a SQLite path from an arbitrary recipient string or request parameter.
-
-Keep mailbox definitions, address aliases, message memberships, outbox records
-and tenant receipts in the tenant database. Support an application-selected
-ActiveRecord base class so every related gem model uses the intended connection.
-Merely wrapping today's hardcoded `ActiveRecord::Base` models in `with_tenant`
-does not establish that connection contract.
-
-The ingress sequence must be:
-
-1. Bound the body and verify the complete Worker signature and envelope.
-2. Resolve the exact signed recipient domain in the shared active directory.
-3. Enter the mapped tenant context, without creating a tenant implicitly.
-4. Resolve the registered active mailbox/alias inside that tenant.
-5. Persist raw mail and mailbox membership idempotently, then schedule processing.
-6. Restore tenant context even when processing raises.
-
-No MIME To/Cc, browser session fallback, sender domain or guessed organization
-slug may select the receiving tenant. Unknown/suspended domains and addresses
-must have explicit rejection or restricted quarantine outcomes, with no fallback
-to an arbitrary tenant/mailbox. Directory changes and mailbox suspension must
-also be checked when deferred work resumes; never silently reassign old mail.
-
-## Optional mailbox module
-
-Add explicit opt-in loading and a generator. The initial contract should cover:
-
-- Tenant/domain registration and verified provisioning state.
-- Mailbox creation, aliases, suspension and lookup by registered address.
-- Application ownership links for user/site/customer mailboxes, checked within
-  the resolved tenant; authenticated actor authorization stays in the host app.
-- Incoming message membership and deduplication without another copy of MIME.
-- Outgoing preparation through an active mailbox with an allowed From address,
-  linked to the existing outbox. A customer cannot select another tenant's
-  sender merely because both share the same Cloudflare account token.
-- An explicit tenant context adapter and connection-class configuration;
-  `activerecord-tenanted` is an optional integration, not a plain-Ruby dependency.
-
-Do not claim a finished inbox UI, IMAP/POP service, thread model, AI workflow,
-search engine or membership system. Rebulk supplies those product decisions.
-Document local-part case policy, reserved names and alias behavior before schema
-implementation; normalization must agree across directory, mailbox and send APIs.
-
-## Jobs, events and cross-database commits
-
-Jobs carry stable tenant and operation/mailbox identities. Establish tenant
-context before loading records. Never rely on a previous request's `Current`
-state, a naked numeric record ID or a Cloudflare account ID as a tenant key.
-Cloudflare account identity and application tenant identity are different.
-
-Queue events arrive without a Rails tenant context and may precede a saved send
-response. Use a shared durable receipt intake and a provider correlation
-directory populated by tenant outbox results. Retain unmatched events and retry
-when correlation becomes available; do not infer tenant ownership solely from
-the recipient's external domain. Ambiguous mappings remain unprojected.
-
-Delivery from shared intake to tenant projection is at least once. A tenant
-receipt deduplicates it. Mark shared processing complete only after tenant commit;
-crashes between commits cause safe replay. Writes to the shared directory,
-tenant SQLite and job queue are not one transaction. Recovery must cover each
-gap without allowing another send or prematurely acknowledging an event.
-
-## Customer subdomains and Cloudflare
-
-An organization may use a Rebulk-owned subdomain or, later, an explicitly verified
-customer-owned domain. Track receive readiness and send-domain verification
-separately. A Rails database record or wildcard DNS entry alone does not enable
-Cloudflare email routing or sending.
-
-Prefer explicit address rules for the first supported provisioner. Reconcile
-desired state with Cloudflare and retain failures for retry rather than marking
-a mailbox active before its route is ready. Multiple tenants may share a Worker
-and ingress secret within one application/environment; tenant routing stays in
-Rails. Separate Cloudflare accounts require account-aware credentials/jobs.
-
-The current catch-all task operates at zone scope. Do not alter the Rebulk apex
-catch-all or promise automatic subdomain catch-alls as part of mailbox creation.
-Verify provider support and limits for the exact subdomain topology before a
-live rollout. Custom domains need ownership verification and safe offboarding.
-
-## Implementation slices and acceptance checks
-
-1. **Tenant foundation:** configurable model connections, tenant-aware job
-   wrappers and migrations in the tenant migration path. Test two real SQLite
-   tenant databases with overlapping IDs, missing context, retries and cleanup.
-2. **Mailbox registry:** shared domain mapping plus tenant mailboxes/aliases,
-   lifecycle and ownership APIs. Test exact matching, uniqueness races,
-   suspension, reserved addresses and isolation for lookup and sending.
-3. **Tenant ingress:** authenticated envelope resolution before ActionMailbox
-   storage. Test Bcc routing, raw bytes, duplicate delivery, unknown destinations,
-   tenant-specific blob access and processing jobs after process restart.
-4. **Outbound/event integration:** reuse saved MIME/claims, enforce mailbox sender
-   identity, add durable shared-to-tenant event dispatch and repair scans. Test
-   event-before-response, duplicate receipts and crashes at each commit boundary.
-5. **Rebulk adoption:** map existing org/site addresses, preserve tracking and
-   sender-review policies, link existing communication/ingest records, and add
-   mailbox management through Rebulk's access resolver. Start behind a feature
-   flag on an isolated development address; keep current production routes intact.
-6. **Provisioning and live verification:** test domain/route setup with bounded
-   retries, then a real send/reply/attachment/event flow for two test tenants.
-   Verify the deployed revision and preserve a dated report before customer rollout.
-
-Required regressions include existing plain-Ruby, single-database SQLite and
-PostgreSQL behavior. Do not call the integration complete merely because a
-single-tenant send works. Existing Rebulk sender-authentication metadata must
-remain authenticated through the new Worker contract before its old ingress
-can be retired; the gem's v2 envelope alone does not supply that policy evidence.

data/docs/upgrading-0.2.md

@@ -1,101 +0,0 @@
-# Upgrade from 0.1.0 to 0.2.0
-
-0.2.0 adds delivery events, optional managed mailboxes and opt-in tenant adapters,
-and changes defaults where 0.1.0 could resend mail or misconfigure routing.
-Database multi-tenancy remains off unless explicitly configured.
-
-## Application changes
-
-1. **Ruby:** the declared minimum is now 3.2, matching the oldest compatibility job. Prefer a maintained Ruby version. CI also covers Ruby 4.0 with Rails 8.1.
-   Base64 is now an explicit runtime dependency so isolated Ruby 3.4/4 applications can load the gem without Rails' transitive dependencies.
-2. **Initializer:** replace direct credential lookups with `Cloudflare::Email::Credentials.account_id` and `.api_token`. This fixes the documented environment fallback for existing apps; upgrading the gem does not rewrite an initializer.
-3. **Send retries:** 429 and pre-send connection failures retry by default. Ambiguous failures (read/write timeouts, resets, and 5xx) no longer resend automatically. Set `retry_ambiguous: true` only if duplicate sends are an acceptable tradeoff. Review ActiveJob retries separately.
-4. **Receiving environments:** the installer now configures development and production ingress. Existing applications should add `config.action_mailbox.ingress = :cloudflare` where needed. `--all-envs` also includes test; staging is explicit.
-5. **Dev tunnel:** `cloudflare:email:dev` refuses staging/production. Use separate routed addresses and Workers for development.
-6. **Test sends:** both `FROM=` and `TO=` are required. The unsupported account-domain autodetection endpoint was removed.
-7. **JSON/Rails:** the gem's development bundle pins JSON below 3 because current tested Rails releases call the pre-3.0 positional-options API. If an existing Rails application's bundle selects JSON 3 and fails in `ActiveSupport::JSON.decode`, constrain `gem "json", "< 3"` in that application's Gemfile until its Rails version supports JSON 3. The gem does not impose this Rails-specific constraint on plain Ruby consumers.
-
-## Worker and routing migration
-
-Copy/review the updated Worker files from this gem; the generator does not silently replace your deployed Worker.
-
-0.2.0 is a preproduction protocol break: only the bundled v2 Worker protocol is
-accepted. Missing or v1 signature versions receive HTTP 401 before persistence
-or routing. Its HMAC covers the SMTP envelope as well as unchanged MIME.
-Pause test ingress while updating Rails and the deployed Worker together; verify
-the matching ingress URL and shared secret before resuming delivery. There is no
-legacy routing mode or supported mixed-version rollout.
-
-The 0.3 custom-ingress additions preserve v2 as the default and add
-opt-in v3 for authenticated Worker metadata. That additive upgrade is separate
-from the v1-to-v2 break above: upgrade the Rails receiver before enabling v3 in
-your custom Worker. See [custom ingestion](custom-ingress.md).
-
-Rails stores authenticated metadata before enqueueing routing jobs.
-`Cloudflare::Email::Envelope.for(inbound_email)` returns a string-keyed `from`/`to`
-hash for accepted ingress. It returns `nil` for records from another ingress or
-older stored records without verified metadata; applications should refuse to
-route those using sender-supplied MIME headers. Route tenant mailboxes using the
-trusted SMTP recipient instead of MIME `To`/`Cc`.
-
-The [earlier upgrade rehearsal](verification/2026-09-10-install-upgrade.md) is a
-historical report and its temporary legacy-mode instructions no longer apply.
-Identical MIME for separate SMTP recipients is stored separately; retries for the
-same exact recipient remain duplicates. This includes Bcc deliveries without a
-visible recipient header. The envelope format supports ASCII dot-atom addresses
-up to 254 bytes, with a 64-byte local part, and an empty SMTP sender for bounces.
-
-- Node tooling uses a tracked package-lock, `npm ci`, Node 22.12+ (or supported newer), Wrangler 4.131+, and Vitest 5.
-- Include `scripts/wrangler.mjs`, `package-lock.json`, and the updated `wrangler.toml`.
-- Wrangler deploy/dev scripts require `--env development|staging|production`.
-- Both deployment paths now target `cloudflare-email-ingress-<environment>`. Existing unsuffixed Workers are not deleted. Set both secrets on the new Worker, deploy, verify, then deliberately update the corresponding route.
-- The forwarding Worker now times out after 15 seconds and refuses redirects. Ensure the Rails URL is the final HTTPS endpoint. Both deployment paths use compatibility date 2026-09-10.
-- For an installer `--worker-dir` other than the default, pass `SCRIPT=your-directory/src/index.js` to the Ruby deploy task.
-- The development tunnel forces a dedicated origin Host and permits only POSTs to the email ingress. Restart the Rails development server after upgrading; the tunnel task verifies the ingress guard before starting.
-
-## Security hardening
-
-- Upgrade host applications to patched Rails: tested floors are 7.2.3.2, 8.0.5.1, and 8.1.3.1, with SQLite 2.9.6 in the test stacks. Rails 7.1 is no longer supported. These are development/test constraints, not runtime dependency enforcement in your application.
-- Redeploy the bundled Worker after updating the gem. Rails and the Worker now default to a 25 MiB raw-email limit. Set `MAX_EMAIL_BYTES` to the same positive integer on both sides when overriding it. Configure upstream request limits and deadlines too.
-- API and ingress endpoints require HTTPS, with HTTP allowed only for literal loopback development hosts. Remove URL credentials, fragments, and query options from configured Ruby endpoints.
-- Delivery events require recipient, ISO8601 timestamp, a boolean `terminal`, valid identifiers, and object-shaped optional details. Invalid messages remain unacknowledged; monitor and quarantine poison messages through your queue operations.
-- Event receipt identity and original payload are read-only through normal ActiveRecord updates. Privileged database access remains trusted.
-- See [the security review](verification/2026-09-11-security.md) for evidence and limits.
-- Subdomain routes require separately onboarded routing DNS and DNS Read access for preflight. The provisioner no longer enables the parent apex to make a subdomain work.
-- Catch-all provisioning is explicitly zone-wide. A request for a subdomain that resolves to a parent zone fails rather than replacing the parent's catch-all.
-- Apex enablement uses the current routing DNS API. Permission/setup errors stop provisioning; they are no longer ignored.
-- Rule lookup now paginates and only updates matching single literal-address rules.
-
-Do not enable Cloudflare routing at the apex of a domain whose mail belongs to Workspace/Outlook. Follow Cloudflare's current subdomain onboarding flow.
-
-## Delivery state and thread correlation
-
-Responses and notifications expose `message_id` when present and `suppressed_recipients`. API success can include permanent bounces or suppression. Monitor recipient outcomes.
-
-Add a dedicated Queue, Email Sending event subscription, and HTTP pull consumer to use [delivery events](delivery-events.md). Existing applications are not subscribed or polled automatically. Provide an idempotent handler and configure retries/dead-letter handling.
-
-For durable sending, install the optional [outbox](outbox.md) migrations and use
-its saved-operation API. Ordinary `deliver_now`/`deliver_later` do not silently
-opt into durable claims. Existing receipt tables from the earlier preproduction
-adapter should normalize their stored `message_id` column before filtered replay;
-retain the raw payload. The reference inbox's migration imports its existing
-attempts, recipients and audits without clearing uncertainty. Outbox and tracking
-generators now refuse destructive rollback; plan forward fixes and backups.
-
-The old README's signed-reply identity and exactly-once claims were too strong. The unused signed-ID helper has been removed. A repeated Message-ID is not a send idempotency key. Live testing confirmed Cloudflare replaces custom IDs: store provider IDs and include parent IDs in outgoing reply headers. See [thread correlation](thread-correlation.md).
-
-## Verification before publishing/deploying
-
-Local automated coverage includes fresh Rails installation/migrations/mailbox execution, task orchestration, packaged installation, duplicate deliveries, mocked sending/routing/event APIs, Worker unit tests, dry-run builds, and actual local workerd-to-Rails forwarding. The runtime test caught and fixed unsupported `redirect: "error"`; the Worker now uses `manual` and rejects 3xx responses. The API tests exercise documented contracts; they do not prove a live account is configured. See the [verification report](verification/2026-09-10.md).
-
-In an account and mailboxes you control, verify these before production rollout:
-
-- Sending-domain DNS and outbound MIME/attachments/cc/bcc behavior.
-- Subdomain receiving routes and each environment's deployed Worker.
-- Ingress response handling and application mailbox jobs.
-- Queue subscription, event encoding, handler persistence, and acknowledgements.
-- Actual delivered provider Message-ID and reply threading.
-
-The automated suite needs no live account. Separate authorized isolated live runs
-are documented in the [live follow-up](verification/2026-09-10-followup.md).
-The gem has not been published by these verification tasks.

data/docs/upgrading-0.3.md

@@ -1,55 +0,0 @@
-# Upgrade from 0.2 to 0.3
-
-Update your Gemfile to `gem "cloudflare-email", "~> 0.3.0"`, run
-`bundle update cloudflare-email`, and deploy Rails first. Updating the gem does
-not replace your deployed Worker, change DNS, or enable optional mailbox features.
-If you are upgrading from 0.1, complete the [0.2 upgrade](upgrading-0.2.md) too.
-
-## Receiving mail while Rails is down
-
-New installations can use the [Deploy to Cloudflare template](../templates/deploy-to-cloudflare/README.md)
-to provision the Worker resources through Cloudflare's setup form. Existing
-installations should preserve their resources and pending mail using the steps below.
-
-The bundled Worker now stores inbound mail in private R2 before accepting it,
-then delivers through a Queue with scheduled recovery. Before deploying it:
-
-1. Create an R2 bucket and Queue for each environment.
-2. Configure the `INBOUND_EMAIL_STORE` binding, `INBOUND_EMAIL_QUEUE` producer
-   and consumer, and once-per-minute cron from the bundled `wrangler.toml`.
-3. Preserve your ingress URL and shared secret. Deploy with Wrangler first;
-   the Rails deploy task does not provision infrastructure.
-4. Verify that mail queues during a Rails outage, drains after recovery, and
-   retries without duplicating application records. Monitor pending mail and age.
-
-Follow the [durable delivery guide](../templates/worker/docs/durable-inbound.md)
-for commands, retention requirements, capacity limits, and recovery behavior.
-Missing infrastructure fails visibly. To deliberately retain single-attempt
-delivery, explicitly select `INBOUND_DELIVERY_MODE=direct` before deploying.
-Direct mode cannot buffer outages. Keep existing bindings and cron so previously
-stored mail continues to drain. The old `DURABLE_INBOUND_ENABLED` flag is removed.
-
-Messages without a parseable Message-ID now receive a deterministic fallback
-across Rails hosts. Historical records created with the old hostname-dependent
-fallback may duplicate on replay; reconcile old archives before replaying them.
-Retain deduplication records for your recovery horizon and make app processing
-idempotent. Durable transport is not an exactly-once delivery guarantee.
-
-## Optional features
-
-- [Management engine](management-engine.md): mount a server-rendered mailbox UI
-  with host authentication, scopes, and permissions. It is not mounted automatically.
-- [Mailboxes](mailboxes.md): enable domain catch-all explicitly on an existing
-  active address. Follow the catch-all schema upgrade instructions; exact
-  registered addresses still take precedence, and sending remains exact-address only.
-- [Custom ingestion](custom-ingress.md): integrate verified envelopes and raw
-  persistence into an existing app. Deploy Rails before enabling v3 metadata
-  signatures in a custom Worker; ordinary v2 forwarding remains supported.
-- [Routing delivery confirmation](routing-deliveries.md): configure separate
-  analytics credentials and durable receipts if needed. API acceptance alone
-  is not proof of delivery, and ambiguous evidence must not trigger a resend.
-
-Database tenancy remains opt-in. Existing tenant-enabled applications can now
-preload their schemas without selecting a tenant; actual mailbox access still
-requires explicit tenant context. No new database tables are required merely to
-upgrade the gem or use the durable inbound Worker.

data/docs/verification/2026-09-10-followup.md

@@ -1,49 +0,0 @@
-# Envelope, drafting, and delivery verification — 2026-09-10
-
-The [install/upgrade rehearsal](2026-09-10-install-upgrade.md) and the
-[inbox E2E report](https://github.com/cole-robertson/agentic-inbox-rails-full/blob/verification/remaining-e2e/docs/verification/2026-09-10-e2e.md)
-extend this pass with crash/restart and live queue dead-letter/replay evidence.
-
-This follow-up supersedes the missing-envelope, missing-ledger, and maintenance-failure findings in the initial reports. The app pins gem candidate `be879439353752d2127dd6413bf915f7321e3fa6`; its runtime matches the live-tested `cb9b87a` (the later commit fixes test-fixture reloading only).
-
-## Implemented
-
-- Worker v2 authenticates SMTP sender/recipient alongside unchanged MIME. Rails stores trusted metadata before routing jobs enqueue and deduplicates separately per recipient. The app routes strictly by trusted recipient; legacy visible-To fallback requires explicit configuration.
-- Drafting supplies actual incoming content and sent history, validates structured output, rejects placeholders, retains existing drafts on failures, and exposes retry/review UI. Re-triage preserves completed tasks and avoids duplicate titles.
-- Review flags combine model output with conservative application checks for approval/financial content, commitments, clarification, and unread attachments. Auto-send and agent SendDraft refuse flagged drafts; the owner can explicitly approve in the UI. These heuristics do not guarantee semantic correctness or protect against every possible tool chain.
-- Durable send claims and immutable attempt snapshots block repeated sends after ambiguous outcomes. Operator reconciliation is scoped, documented, and audited. Event receipts deduplicate before ACK, correlate by provider ID and recipient, and handle ordering/unmatched replay.
-- Compose, UI approval, agent tools, and auto-send share delivery handling. The UI shows state, uncertainty, review reasons, and generation failures. Draft editor state resets when the selected draft changes.
-- Updated Ruby/npm dependencies and resolved the earlier lint, formatting, scanner, and audit findings.
-
-## Live evidence
-
-Only dedicated addresses under `test.rebulk.com` and an isolated SQLite database/storage were used. Real LLM inference used the configured `gpt-4o-mini`.
-
-1. A structured send to To/Cc/Bcc produced three received records sharing the same visible To and Message-ID. Each authenticated SMTP recipient routed to its own mailbox and separate conversation, including the hidden Bcc mailbox.
-2. Four received messages were processed with real triage/drafting. Replies referred to the blue sample box; none contained the earlier scaffolding or placeholders.
-3. A purchase/next-day commitment scenario initially returned a sensible clarification but an incorrect model review flag. Added independent application rules and a regression. The rerun required review, included concrete reasons, and stayed unsent.
-4. An explicitly approved synthetic draft went through the real ActionMailer adapter. Its durable attempt became accepted and then delivered after its provider event was consumed. Cloudflare replaced the custom signed Message-ID; parent reply headers were preserved.
-5. The dedicated queue produced four delivered events (three direct-client recipients plus the app send). A deliberate exception after durable storage caused redelivery; the retry retained four unique receipts and ACKed all four. The app event matched its attempt/recipient; direct-client events remained stored unmatched.
-
-The first simultaneous ingress requests reached a cold, reload-enabled temporary test harness: two returned routing errors while one succeeded. After routes loaded, a new send produced all three successful copies. This was a harness startup limitation, not counted as a passing delivery. Use eager loading/disabled reloading and warm the receiver before concurrent live tests.
-
-The earlier live report separately covers raw MIME, binary attachment integrity, provider-ID reply round trips, and six initial delivered events.
-
-## Automated verification and limits
-
-Gem: 197 tests / 631 assertions; 19 Worker tests; 19 real local workerd-to-Rails checks. All 13 CI jobs passed at be87943, including 11 Ruby/Rails combinations:
-https://github.com/cole-robertson/cloudflare-email/actions/runs/34531698927
-
-The app suite passes **213 examples**, seed 42422. It covers authenticated ingress, strict mailbox selection, approval endpoints, review/auto-send guards, rejection and ambiguity, process/persistence failure, attempt snapshots, operator authorization, ordering, deduplication, event task wiring, and malformed LLM responses. Lint, TypeScript, Prettier, RuboCop, Brakeman and Ruby/npm audits pass (zero reported vulnerabilities/warnings).
-
-Browser acceptance was attempted using the shared T3 preview: status/open repeatedly timed out, including a fresh-tab attempt. No visual browser pass is claimed; authenticated request tests and frontend static checks passed.
-
-Only delivered lifecycle events were induced live. Bounce, suppression, complaint, and deferred/failure handling have automated coverage. Queue dead-letter exhaustion was not exercised; no exhaustive provider failure simulation or spam complaints were generated. The token lacks DNS Read, so complete route-provisioning preflight still needs an appropriately scoped credential. Exact test rules were created through Email Routing after the prior DNS verification. No exactly-once guarantee is possible across provider/database boundaries; separate compose submissions are distinct messages.
-
-## Cleanup and reproduction
-
-Deleted the four exact test routes, dedicated Worker, event subscription, and queue. Existing routing rules and catch-all exactly match the saved baseline. Stopped the local receiver/tunnel; no DNS changes, production migration, merge, or gem publication occurred.
-
-Private harness/evidence: `/tmp/cf-email-envelope-live-20260911` (the suffix is a unique run identifier; execution was September 10). No credentials or queue leases are in tracked evidence. Sanitized observations are in [2026-09-10-followup-results.json](2026-09-10-followup-results.json).
-
-Run `bundle exec rspec`, `bundle exec rubocop`, `bin/brakeman --no-pager`, `bin/bundler-audit`, `npm run lint`, `npm run check`, `npm run format`, and the checked-in Worker tests/build. See the app's delivery operations guide for event consumption and operator reconciliation. Deploy the new Rails gem and app migrations before the v2 Worker.

data/docs/verification/2026-09-10-install-upgrade.md

@@ -1,86 +0,0 @@
-# Install, upgrade, rollback, and staged protocol rehearsal
-
-Executed 2026-09-10 with Ruby 4.0.0, Rails 8.1.3.1, gem 0.2.0.
-Gem merge: `cb8d8932296f64b5531ee2e1b773e9937c6df884`.
-Inbox merge: `21bc3627ad70c586c45e7df297db4af4cd070066`.
-The inbox retains its release-candidate gem pin `be879439353752d2127dd6413bf915f7321e3fa6`.
-
-## Packaged install
-
-```sh
-bundle exec ruby script/verify_package.rb
-```
-
-Passed: isolated consumer installed the built `.gem` into a temporary bundle,
-loaded version 0.2.0, and did not load Rails. Rails integration fixtures loaded
-the extracted packaged files in separate processes:
-
-| Fixture | Tests | Assertions | Failures/errors/skips |
-| --- | ---: | ---: | --- |
-| Inbound | 18 | 95 | 0/0/0 |
-| Send only | 11 | 40 | 0/0/0 |
-| Fresh inbound | 19 | 100 | 0/0/0 |
-
-The fresh Rails harness invoked the actual install generator, installed and
-ran Active Storage/Action Mailbox migrations, generated mailbox files and Worker
-files, then received and routed a signed message. This verifies the packaged
-generator in a minimal fresh Rails application; it does not claim a RubyGems
-publication, Docker deployment, or a production installation.
-
-## Existing inbox migration and backup recovery
-
-From the gem checkout, using the inbox bundle:
-
-```sh
-INBOX_ROOT=/absolute/path/to/agentic-inbox-rails-full \
-BUNDLE_GEMFILE=/absolute/path/to/agentic-inbox-rails-full/Gemfile \
-bundle exec ruby script/verification/install_upgrade.rb
-```
-
-All **16 checks passed**. The script creates temporary SQLite databases and
-storage, uses inert test credentials, disables mail delivery, and blocks network
-access during routing. It removes those resources on exit and never migrates the
-configured inbox database.
-
-- Migrate a completely empty database to the pre-ledger migration
-  `20260418012251`; insert representative incoming, sent, and unapproved messages.
-- Upgrade to the current schema; preserve every original message field and
-  timestamp. Previously sent messages become `legacy_sent`, while unsent messages
-  become `pending`. No provider IDs or delivery attempts are fabricated.
-- Check review-field defaults on existing rows.
-- Insert an ambiguous send and durable attempt. Take a quiesced SQLite snapshot
-  with `VACUUM INTO`, roll back both new migrations, and reapply them.
-- Restore the snapshot into a different database; verify the original ambiguous
-  attempt and message state survive. Re-running migrations is idempotent, and an
-  actual `DraftDelivery.call` remains blocked without creating another attempt.
-
-**Schema rollback is destructive to delivery history.** The rehearsal confirmed
-that down/up migrations preserve old message content but drop attempts and reset
-an ambiguous draft to `pending`. A schema rollback after send attempts exist must
-not be treated as a safe retry/recovery procedure. Stop writers and retain the
-ledger; prefer a forward fix. If restoring a backup, coordinate ingress, jobs,
-and provider reconciliation first: the local quiesced backup test does not prove
-that restoring an earlier production snapshot is safe while external sends are
-in flight. Rolling back to old sending code can also bypass the new ledger guard.
-
-## Rails-before-Worker rollout
-
-The same script POSTs correctly signed v1/v2 payloads to the real Rails ingress
-and routes them through `AgentMailbox`. A closed, existing conversation avoids
-LLM requests and outbound mail.
-
-| Protocol and configuration | Observed result |
-| --- | --- |
-| v1, `ALLOW_LEGACY_EMAIL_ROUTING=true`, single To/no Cc | Accepted and routed into the existing conversation |
-| v1, transitional mode, Cc present | Ingress accepts; mailbox refuses ambiguous routing and records bounced |
-| v1, strict mode | Ingress accepts; mailbox refuses missing authenticated envelope and records bounced |
-| v2, strict mode | Accepted and routed into the existing conversation |
-
-Only the two permitted messages enter the conversation; no outbound mail is sent.
-For a staged rollout, deploy Rails with the explicitly temporary legacy flag,
-deploy the v2 Worker, verify authenticated-envelope delivery, then disable the
-flag. Legacy multi-recipient traffic is intentionally refused even during this
-transition; use a controlled ingress pause if this traffic must not be interrupted.
-The protocol replay tests exercise real HMAC verification, persistence, and
-mailbox execution, with synthetic local HTTP requests; they are not additional
-Cloudflare-deployed Worker tests.

data/docs/verification/2026-09-10-live.md

@@ -1,102 +0,0 @@
-# Live verification — 2026-09-10
-
-> Initial live pass. The [follow-up](2026-09-10-followup.md) resolves the
-> envelope-routing, missing-ledger, and maintenance findings below, improves
-> drafting/review behavior, and records new live evidence and remaining limits.
-
-The updated gem was exercised against the real Cloudflare account owning
-`rebulk.com`, using only isolated addresses under its existing enabled sending
-subdomain `test.rebulk.com`. The Rails consumer was `agentic-inbox-rails-full`,
-with a private temporary SQLite database/storage and a restricted loopback
-server exposed through a temporary tunnel. Existing production resources and
-the old `cole@test.rebulk.com` experiment were preserved.
-
-## Results
-
-| Check | Live evidence |
-|---|---|
-| Structured send | One message addressed To/Cc/Bcc: three queued recipients, three actual received copies, three delivered events |
-| MIME headers | Text and HTML received, Cc retained, Bcc absent from MIME headers; sending-domain DKIM, SPF and DMARC passed |
-| Raw MIME | One real send with a 260-byte binary attachment; received and application-stored SHA-256 matches `0d42a8b2489dc6e5632cec0b1f06b4f41b61742536d2c3c361edb990e3b945cd` |
-| Deployed Worker | Gem `WorkerDeployer` uploaded the shipped Worker and set both secrets; all six received copies reached real Rails HMAC ingress |
-| Reply round trip | Two explicitly approved synthetic draft sends through real `DraftDelivery`/ActionMailer; returned reply matched the original conversation using the stored provider ID |
-| Custom signed Message-ID | **Not preserved.** Raw send and ActionMailer sends were assigned Cloudflare IDs; received IDs matched provider responses |
-| Actual LLM | Four inbound messages ran real triage and drafting; categories, summaries, action items and drafts were persisted; auto-send stayed off |
-| Ingress retries | Exact signed replay returned 200 without a new record; invalid signature returned 401 without persistence |
-| Delivery events | Six unique `delivered` events persisted and acknowledged through the real HTTP pull API; subsequent poll returned zero |
-| Handler failure/redelivery | Deliberate exception after durable event insert prevented acknowledgement; next poll redelivered the same event, inserted zero duplicate rows, then acknowledged it |
-| Isolation/cleanup | Four temporary literal rules, one Worker, one event subscription, two queues and local server/tunnel removed; original eight rules and catch-all exactly matched the saved baseline |
-
-Four outbound API calls produced six recipient deliveries. No mail was sent to
-people or production ingestion addresses. No DNS records were changed, and the
-apex Google Workspace MX configuration was not touched.
-
-## Defects found and fixed
-
-1. **Queue JSON encoding.** Real Email Sending subscriptions return plain JSON
-   strings with `CF-Content-Type: json`. The consumer previously assumed Base64,
-   so the first live poll failed without acknowledging the message. Commit
-   `3fda75aa7cd5c54fc7753676e340d1deef4f0ce4` accepts plain JSON and keeps Base64
-   compatibility. A sanitized live-shaped fixture and regression checks were
-   added. The fixed consumer passed real redelivery/deduplication/acknowledgement.
-2. **App reply headers.** The demo stored provider IDs but its outgoing replies
-   omitted `In-Reply-To` and `References`. Its follow-up change sets both from
-   the latest inbound message, and the real round trip then correlated correctly.
-
-Follow-up automated results: **193 gem tests / 602 assertions pass**, plus all
-13 jobs in [gem CI](https://github.com/cole-robertson/cloudflare-email/actions/runs/34527748184).
-The updated inbox suite passes **144 examples** with eager loading (seed 38933).
-The inbox now pins the fixed gem commit above in
-[PR #26](https://github.com/cole-robertson/agentic-inbox-rails-full/pull/26).
-
-## Boundaries and remaining findings
-
-- **Inbound Cc/Bcc mailbox selection is not implemented by the demo.** All three
-  actual copies retain the same visible To header, while their SMTP recipient
-  differs. The Worker forwards raw MIME without a separately authenticated
-  envelope recipient; `AgentMailbox` selects the first visible To address.
-  Only the primary To copy was processed in this test. Correct multi-mailbox
-  Cc/Bcc routing requires an explicit envelope-aware design; do not infer it
-  from successful outbound Cc/Bcc delivery.
-- **LLM response quality is not guaranteed.** Real replies sometimes included
-  drafting instructions/placeholders; one asked for context that was already
-  available. This pass proves live inference and persistence, not acceptable
-  autonomous reply quality. Human draft review remains necessary.
-- Wrangler OAuth lacks DNS Read. The gem's subdomain provisioning preflight
-  correctly refused that credential before creating rules. Public DNS confirmed
-  the three Cloudflare MX records; the four isolated literal rules were then
-  created directly using the authorized Email Routing API. The complete
-  `provision_route` path still needs a suitably scoped token for live validation.
-- Only `delivered` lifecycle events were induced live. Bounce, suppression,
-  complaint, and deferred/failure cases remain automated
-  fixture coverage. Dead-letter exhaustion was not tested. No spam complaints or deliberately harmful traffic were
-  generated. A dead-letter queue was configured but its exhaustion path was not
-  exercised.
-- The gem's development-tunnel orchestration task was not used; this run used an
-  explicit temporary tunnel with a restricted receiver. Arbitrary external mail
-  providers/clients, SMTP submission, exhaustive browser UI behavior and every
-  agent/MCP tool remain outside this live pass.
-- The app's existing dependency-audit/style failures and missing durable
-  ambiguous-send ledger remain as documented in its earlier report. No release
-  publication, production migration or merge occurred.
-
-## Reproduction and evidence
-
-Use an isolated app database and dedicated exact receiving addresses. Snapshot
-existing rules/catch-all; deploy a uniquely named shipped Worker; set its HMAC
-secret/receiver URL; provision only the dedicated addresses. Create an HTTP-pull
-queue and a domain-scoped `email.sending` subscription before sending.
-
-Exercise `Client#send`, `Client#send_raw`, the app's `DraftDelivery`, and
-`EventConsumer#poll`. Persist event IDs under a unique index before acknowledging;
-deliberately raise once after commit to test idempotent redelivery. Compare actual
-received headers/attachment hashes and conversation IDs. Wait for delivered
-events, then remove only the resources created by the run and compare the saved
-baseline. Do not rerun live sends without confirming the active target scope.
-
-Sanitized machine-readable observations are in
-[2026-09-10-live-results.json](2026-09-10-live-results.json). Detailed runner
-scripts, synthetic MIME, local database and private logs remain in
-`/tmp/cf-email-live-20260910` on the verification host; they are not committed.
-No tokens, OAuth callback codes, HMAC secrets, queue leases or LLM keys are in
-the tracked artifacts.