beskar 0.0.2 → 0.2.0

data/docs/guides/notifications-and-recovery.md

@@ -0,0 +1,157 @@
+# Notifications and recovery delivery
+
+Beskar supplies opt-in plain-text email for confirmed account locks (Devise and
+Rails-native), Rails-native emergency password resets, and security-team reset
+alerts. Delivery uses the host's Active Job and Action Mailer configuration.
+These notices describe precautionary actions, not proof of account compromise.
+
+## Enable explicitly
+
+All three notification flags now default to **false**. Their former true defaults
+only logged intent; enabling them now requires real delivery configuration:
+
+```ruby
+# config/initializers/beskar.rb
+Beskar.configure do |config|
+  config.notifications = {
+    from: "security@your-domain.example",
+    recovery_url: "https://your-domain.example/account-recovery",
+    security_team_recipients: ["security-team@your-domain.example"]
+  }
+  config.risk_based_locking[:notify_user] = true
+  config.emergency_password_reset[:send_notification] = true
+  config.emergency_password_reset[:notify_security_team] = true
+end
+```
+
+Replace the example mailboxes and URL with your own. Notification flags do not
+enable risk locking or emergency resets; configure those policies separately.
+Enabling notifications is independent of optional audit logging and background
+analysis. No sender fallback or hardcoded production recipient is used.
+
+The sender and recipients must be plain, single mailbox addresses, without display
+names, comma-separated lists, or header-control characters. Up to 20 security-team
+recipients are supported, with one separate message/job per list entry. An enabled
+team flag requires a nonempty list. User messages require a configured recovery
+URL. Invalid settings stop startup/configure publication; delivery workers also
+validate the notification settings they use.
+
+The recovery URL must be an absolute HTTPS **entry page**, without userinfo,
+query parameters, or a fragment. It must not contain a password-reset/sign-in token
+in its path either; syntax validation cannot determine whether a path contains a
+secret. Beskar never constructs this URL from a request's Host header. For multiple
+authentication models, provide a host page that routes users to the appropriate
+recovery/support flow. URL ownership, availability, and recovery correctness are
+host responsibilities, not validated by a network request at boot.
+
+Configure `config.active_job.queue_adapter` for your host and run workers consuming
+`beskar_notifications` (including any host queue prefix). Beskar jobs inherit the
+engine's `ApplicationJob < ActiveJob::Base`, not a host-defined `ApplicationJob`;
+host-only subclass callbacks/settings do not automatically apply. The normal Rails
+application-wide queue settings do apply. Configure Action Mailer transport/sender
+authorization, with `perform_deliveries` and `raise_delivery_errors` enabled.
+Disabled/suppressed delivery is treated as a failure, not a successful notice.
+
+## Transaction and failure contract
+
+Notification scheduling follows a confirmed lock/reset and waits for every
+enclosing Active Record transaction to commit. Outer rollbacks and rolled-back
+savepoints cancel callbacks. With no open transaction, enqueueing happens
+immediately after the operation. Enqueue attempts never occur inside retryable
+security-state mutation blocks.
+
+Monitor mode and IP whitelist policy suppress the automatic security action and
+its notification. A failed lock or rolled-back reset produces no notice. A failed
+optional account-lock audit does not prevent notification of the actual lock.
+Password invalidation, session revocation, and the mandatory emergency-reset audit
+remain transactional; notification delivery is outside that transaction.
+
+The user-reset and security-team hooks are independent: one failing hook does not
+suppress the other. Initial enqueue exceptions/aborted enqueues are logged without
+changing admission or rolling back committed work. There is no durable pending
+row to retry an initial enqueue failure automatically.
+
+`Beskar::NotificationJob` retries delivery failures up to five total attempts with
+Active Job's polynomial backoff. Exhausted failures remain raised for the backend
+to retain/report. A failed retry enqueue also raises visibly. Configure backend
+failure monitoring and reconciliation; backend-level retries may add attempts.
+
+This is **not an outbox or exactly-once delivery system**. A process crash between
+commit and enqueue can lose a notice. SMTP acceptance followed by a timeout,
+backend retries, or host delivery-observer failures can duplicate email. Separate
+recipient jobs avoid retrying all team members for one member's delivery failure.
+Successful execution means the configured transport returned successfully, not
+that the recipient received or read the message. No delivery-status audit/table,
+bounce handling, or verified recipient confirmation is supplied.
+
+## Data and logging boundaries
+
+Jobs contain only `user_type`, `user_id`, `kind`, and an optional
+`recipient_index`. No email, password, reset token, model object, raw request
+metadata, or risk explanation is serialized into job arguments. IDs are still
+personal identifiers and require appropriate queue access/retention controls.
+
+Workers load the current account and email (`email_address` for native accounts,
+`email` for Devise), and current sender/recovery URL/team list. They recheck the
+notification flag. Deleted accounts and removed recipient indices are skipped.
+A reordered/replaced team list changes the recipient at a queued index; drain
+pending jobs before changing the list if a fixed recipient snapshot is required.
+User address changes similarly affect pending delivery. These jobs are historical
+notices, not checks that the user is still locked when mail is delivered.
+
+User bodies contain only fixed explanatory text and the configured recovery page.
+Team bodies contain the model name and account ID, not the user's email or raw
+security evidence. Review the authenticated dashboard for incident details.
+
+Job argument logging is disabled for the notification job. Preparation/delivery
+errors are replaced with static class-based errors, without their original causes,
+before the normal job retry/failure reporting. This mailer uses
+`deliver.beskar_notification` instrumentation with the mailer name, timing, and
+sanitized exception information instead of Action Mailer's encoded-message and
+recipient delivery payload. Subscribe to that event if your monitoring normally
+depends on `deliver.action_mailer`. Other host mailers are unchanged.
+
+Host queue-adapter logging, custom instrumentation/interceptors/observers, SMTP
+debugging, and external error-reporting systems have their own privacy boundaries.
+Beskar does not globally filter them, protect a transport's internal logs, or
+anonymize mail recipients. Review those settings before production rollout.
+
+## Recovery remains a host flow
+
+The notice links to your existing recovery page; it does not issue a bearer token,
+expose the random replacement password, authenticate the recipient, unlock an
+account, or establish trusted-device/IP evidence. The host must supply secure
+password-reset issuance, expiry, redemption, anti-enumeration/rate limiting,
+identity verification, and authorized manual unlock where required.
+
+For native accounts, emergency invalidation changes the password digest, revokes
+sessions, and invalidates Rails' previous password-reset tokens. A later successful
+password reset does **not** remove a Beskar manual lock. Follow the authorized
+unlock procedure in [Authentication](authentication.md). Devise owns its own
+Recoverable/Lockable recovery semantics; this repair adds Devise lock notices,
+not a second Devise password-reset or unlock implementation.
+
+The public native `send_emergency_reset_notification(reason)` and
+`notify_security_team_of_reset(reason, event)` hooks remain overridable. Their
+defaults now enqueue these emails. Overrides still run independently after commit,
+but own their delivery, retry, and privacy behavior; do not call `super` if that
+would duplicate your delivery. Enabling their flags still requires the validated
+notification settings above. The optional analysis job is a separate read-only
+extension point, not a recovery-delivery adapter.
+
+## Verification and rollout
+
+Local Ruby 4.0.6 tests exercise real outer commits/savepoint rollbacks, both
+authentication paths, user/team hook and queue failures, all five delivery
+attempts, invalid recipients, disabled delivery, and sanitized logging. Mail is
+sent only to Rails' **test** delivery backend. The native integration test follows
+the recovery notice through the dummy host's recovery form, reset-token email and
+redemption, confirms token invalidation, and requires manual unlock before login.
+
+Real SMTP delivery, production worker durability, email-client rendering, host
+support processes, and broader host recovery integrations have not been verified.
+The dummy Devise reset-email/token handoff now verifies its email-unlock policy,
+one-time token use, and that old sessions remain revoked. Configure and
+exercise those before enabling emergency resets in production. This batch adds
+no database migration and does not change the any-`Rails.cache` coordination
+contract. Remaining work is tracked in [Repair status](../audits/repair-status.md).

data/docs/guides/risk-scoring.md

@@ -0,0 +1,116 @@
+# Authentication risk evidence
+
+Authentication now uses one `RiskAssessment` snapshot for the decision, login
+audit, and lock context. `metadata["risk_assessment"]` contains a version, assessment
+time, observation/enforcement mode, score, and named factors with points/evidence.
+Factor points, including negative cap adjustments, sum to the recorded score.
+`device_info` and `geolocation` carry the same facts used by that assessment.
+
+## Factors and limits
+
+| Factor | Points |
+| --- | ---: |
+| Successful / failed credentials | 1 / 10 |
+| Missing User-Agent | 20 |
+| Bot-like User-Agent claim | 30 |
+| User-Agent shorter than 20 or longer than 500 characters | 15 |
+| Test/debug/script marker in User-Agent | 10 |
+| More than three parentheses in User-Agent | 5 |
+| Chrome/Firefox major version below the legacy cutoff of 90 | 5 |
+| Mobile User-Agent, application-local hour 22:00–05:59 | 5 |
+| At least two recent account failures in ten minutes | 20 |
+| Private or unavailable geographic location | 10 |
+| Impossible-travel heuristic | 25 |
+| Changed known country | 10 |
+
+User-Agent factors are capped at 50, geographic factors at 30, and total risk at
+100. The version-90 cutoff is a retained heuristic, not a browser support policy.
+Password contents and length are no longer used as risk factors. User-Agent
+assessment/storage is bounded to 500 sanitized characters; the length factor uses
+the original length. User-Agent risk logging no longer includes the raw header.
+Other audit surfaces still need the privacy work tracked under F11.
+
+These are heuristic weights, not calibrated probabilities. A travel signal alone
+does not reach the default locking threshold of 75. IP geolocation can describe a
+VPN, proxy, mobile carrier, or shared egress; User-Agent values can be forged. None
+of these factors proves the identity, intent, or physical position of a person.
+
+## Timestamped geographic history
+
+The geographic assessment considers up to the latest 20 success records in four
+hours, explicitly ordered by `created_at` and ID. A history record must have
+`authentication.allowed == true` and must not report `locked_now == true`.
+Blocked outcomes, legacy successes without explicit admission evidence, future
+events, and malformed records are not travel baselines. Observation-mode records
+are excluded from enforcement assessments. Monitor assessments may inspect
+enforced history as well as observations.
+
+Every usable location is paired with its own event timestamp and ID. Travel uses
+the newest comparable coordinate observation, actual elapsed seconds, and a
+1,000 km/h heuristic. Evidence includes the previous event ID/time, elapsed
+seconds, distance, and speed threshold. Country change independently uses the
+newest known-country observation. JSON string/symbol keys and numeric coordinate
+strings are normalized; missing, non-finite, or out-of-range coordinates cannot
+produce travel evidence. Equal, future, or malformed times are ignored.
+
+History remains optional audit data, not an independent travel-enforcement store.
+Disabled/missing audits reduce available history. Concurrent authentications do
+not serialize geographic observations, and records outside the bounded window
+are not considered. The recent-failure factor similarly examines the latest 20
+failures within ten minutes, excluding observations in enforcement mode. These
+limits bound database work; they are not exhaustive forensic analysis.
+
+The integer `calculate_location_risk` compatibility method accepts timestamped
+observations (`location`, `occurred_at`, optional `event_id`), or one previous
+location with a positive elapsed duration. An untimestamped collection no longer
+shares one duration across all entries. Prefer `assess_location` for evidence.
+
+## Providers and configuration changes
+
+The default `:mock` provider produces synthetic data for development. Synthetic
+locations never establish country/travel evidence or add geographic risk. Private
+addresses still receive the explicitly labeled unavailable-location factor.
+Configure `:maxmind` with an actual city database for geographic observations.
+Unknown provider names and the unimplemented IP2Location provider are rejected
+by configuration validation and service construction. Valid MaxMind lookups may
+still return unknown data when enrichment is unavailable; this is not fabricated
+geographic evidence. See [Configuration](configuration.md).
+
+Cache keys include provider and MaxMind database identity (path, inode, size,
+modification time). New service instances/readers follow configuration or database
+generation changes. An in-flight service instance can finish using its snapshot.
+Old cache entries expire under their TTL; they are not reused across generations.
+Any Rails.cache backend remains supported, including NullStore and unavailable
+optional caches. Replacements that preserve every identity attribute require an
+explicit reader reset and cache invalidation, or a new database path.
+
+## Locks, observation, and trust
+
+The actual computed travel, country-change, and bot/suspicious flags drive lock
+reasons. Lock audits include the same risk factors and authentication attempt ID.
+When risk locking is enabled, login metadata includes `lock_decision` with the
+threshold, adapter availability, `would_lock`, and whether policy permits
+enforcement. `would_lock` describes eligibility, not successful persistence;
+`authentication.locked_now` records the actual result. Monitor mode/whitelists do
+not mutate accounts. Unknown/custom strategies are not advertised as available.
+
+There is **no automatic trust discount**. Repeated IP use, lock attempts, and
+manual/automatic unlocks do not prove a verified device or confirmed recovery.
+The former 30% scoring discount and complete geographic bypass have been removed.
+A future trust mechanism needs explicit host-verified identity/recovery evidence.
+
+## Upgrade and validation
+
+No new migration is required for this batch. Legacy login records without explicit
+admission evidence are not promoted into geographic history. Scores can rise when
+unsafe trust discounts disappear, and fall when mock geography or erroneous old-
+browser penalties disappear. Review recorded factors in monitor mode before
+enabling risk locking or opt-in emergency resets; do not assume old thresholds
+have been calibrated for the corrected inputs.
+
+Local coverage includes real Devise/native logins, persisted JSON history,
+chronological ordering, midnight boundaries, modern browsers, malformed locations,
+provider/cache isolation, monitor/whitelist policy, and matching lock evidence.
+Real MaxMind database accuracy, production false-positive rates, and verified
+recovery/notification delivery remain unverified or unfinished. See
+[Authentication](authentication.md) and [Repair status](../audits/repair-status.md).

data/docs/operations/monitor-only-mode.md

@@ -0,0 +1,85 @@
+# Monitor-only mode
+
+Monitor mode lets you observe WAF and rate-limit decisions without rejecting
+requests or automatically creating IP bans:
+
+```ruby
+Beskar.configure do |config|
+  config.monitor_only = true
+  config.waf[:enabled] = true
+  config.waf[:auto_block] = true
+end
+```
+
+The installer defaults to monitor mode in every environment. Turn it off explicitly
+only after reviewing traffic and tuning thresholds.
+
+## What is recorded
+
+WAF violations remain available as `Beskar::SecurityEvent` records when
+`config.waf[:create_security_events]` is enabled. Their metadata includes:
+
+- `monitor_only_mode`: whether the observation was made in monitor mode.
+- `would_be_blocked`: whether the threshold and auto-block policy would deny a
+  non-whitelisted IP.
+- `current_score`, `score_threshold`, and matched patterns.
+
+Matched patterns contain rule identifiers and static descriptions, not URLs,
+query strings, raw headers, or exception messages. Default exception scoring
+requires independent scanner-path/format evidence (with resolved IP-spoof signals
+handled separately). See [Audit data and WAF](../guides/audit-and-waf.md) before changing this
+policy or interpreting exports.
+
+Monitor WAF history, authentication counters, and rate-denial counters are stored
+separately from enforcement state. Switching to enforcement does not promote
+monitor observations into active counters or bans. Switching modes does not delete
+either history; unexpired enforcement state from an earlier enforcement period
+remains effective when enforcement resumes.
+
+Existing manually created or previously enforced bans remain in the database, but
+middleware does not enforce them while monitoring. Monitor mode does not prevent an
+administrator from explicitly creating or modifying a ban.
+
+## Review and enable enforcement
+
+Use the dashboard, or inspect recent observations in the console:
+
+```ruby
+Beskar::SecurityEvent.where(event_type: "waf_violation")
+  .where("created_at >= ?", 24.hours.ago)
+  .find_each do |event|
+    next unless event.metadata["monitor_only_mode"]
+    puts [event.ip_address, event.metadata["would_be_blocked"],
+      event.metadata["current_score"]].inspect
+  end
+```
+
+Review false positives, configure trusted proxies and whitelist entries, then set:
+
+```ruby
+Beskar.configure do |config|
+  config.monitor_only = false
+end
+```
+
+Use `config.waf[:score_threshold]` to tune cumulative WAF scores.
+`block_threshold` and nested `config.waf[:monitor_only]` are not supported options.
+
+## Important limitations during remediation
+
+Beskar's automatic account locks, current-attempt sign-outs, and emergency password
+resets now honor monitor mode and the IP whitelist. Rails-native applications must
+use the [admission and session-reader guards](../guides/authentication.md). Host application
+restrictions—such as Devise's own failed-attempt Lockable policy or Rails' own rate
+limiter—remain independent of Beskar monitor mode. Risk-enabled login audits now
+include `lock_decision.would_lock`, adapter availability, enforcement policy, and
+the scored evidence. Observed successes/failures do not supply enforced risk
+history. See [Risk scoring](../guides/risk-scoring.md). Production calibration and real
+notifications remain open; observation does not prove the signals are accurate.
+
+Older versions created bans during monitoring. Existing bans cannot reliably be
+classified as monitor-only after the fact. Review and explicitly remove any
+unwanted legacy bans before enabling enforcement; this release does not silently
+delete ban records.
+
+See [state storage and upgrade notes](state-storage.md) for database requirements.

data/docs/operations/security-hardening.md

@@ -0,0 +1,167 @@
+# Audit findings 2–6: hardening and deployment contract
+
+This batch extends the previous repairs. It does not claim that arbitrary host
+authentication code is automatically secured, or that production capacity has
+been validated. Use the coverage checklist below as a deployment gate.
+
+## Authentication and revocation coverage
+
+| Entry point | Beskar enforcement | Host requirement / boundary |
+| --- | --- | --- |
+| Devise database password, including HTTP Basic | IP/account admission before password verification; risk/lock decision before session establishment | Include SecurityTrackable on every protected model; preserve the standard strategy/serialization pipeline |
+| Standard custom Warden strategies | IP admission before `_run!`; account admission when identity becomes known; failed strategy outcomes audited | Scope must resolve to a protected model. An opaque token's target cannot be counted before its verifier identifies it |
+| OAuth/manual Warden sign-in | `set_user` guarded, even with `run_callbacks: false` | External provider verification happens before Beskar sees the identity. Use the generic gateway if pre-verification admission is needed |
+| Devise cookie and remember-me resumption | Durable generation in both credential salts; locks rotate generations; fetch checks locks | New salt format invalidates old cookies once. Custom serializers/remember verifiers require review |
+| Rails-native session creation and resumption | Transactional session guard; locks delete sessions; resumption validates the persisted session and lock | Adopt both controller and resumption hooks in docs/guides/authentication.md; arbitrary host `Current`/cookie readers are not discoverable automatically |
+| Custom API/token issuance | Framework-neutral admission gateway and issued generation | Host verifies/cryptographically binds identity and generation and honors the result before issuing anything |
+| API token use | Shared base-controller guard checks account and signed generation per request | Include `Controllers::SessionSecurity` after host identity resolution; implement both readers below |
+| Action Cable | Base-channel guard checks subscribe, inbound actions, and normal outbound channel transmissions | Prepend `Channels::SessionSecurity`; connection implements the same readers. Direct connection writes/custom dispatchers bypass this adapter |
+
+Risk-based locking remains opt-in and requires a supported lock strategy. A
+confirmed lock always rejects the attempt; legacy `immediate_signout: false` no
+longer provides an exception. Ordinary Devise `locked_at` writes rotate the
+account generation in the user transaction. Explicit `user.revoke_beskar_sessions!`
+rotates it without needing a lock; native accounts also destroy database sessions.
+Unlock never restores old generations. Persistent generation rows must not be
+purged; they deliberately have no TTL. Bulk SQL updates bypass model callbacks.
+
+All users, sessions and security state must share the writer connection pool.
+Generation/native-lock reads bypass the query cache, not just Rails.cache. A
+database failure denies access; it does not use an old allow decision. In-flight
+work cannot be retroactively canceled; idle sockets close on their next guarded
+action or transmission, not via a background disconnect broadcast.
+
+### Framework-neutral credential issuance
+
+```ruby
+attempt = Beskar::Services::Authentication.authenticate(
+  request, model: User, scope: :api,
+  credentials: {email_address: params[:email_address]} # Identity only; never passwords/tokens
+) do
+  User.authenticate_by(params.permit(:email_address, :password))
+end
+# On denial, return attempt.response; on Unavailable, return the standard 503.
+# Only when attempt.allowed? is true may the host issue a credential containing:
+#   subject: attempt.user.id, beskar_generation: attempt.session_token
+# Sign/store these values using the host's existing authenticated token mechanism.
+```
+
+`scope` is a stable host-selected name, never a client-selected partition. The
+gateway does not create tokens, sessions, endpoints, or verify OAuth assertions.
+Credential verifiers must return the authenticated persisted model or nil.
+If the subject is unknown before verification, use an empty identity hash; IP
+admission still precedes the verifier and account admission follows it.
+
+For protected API controllers:
+
+```ruby
+class Api::BaseController < ActionController::API
+  before_action :verify_host_token! # Existing host verifier; never trust unverified claims
+  include Beskar::Controllers::SessionSecurity
+
+  private
+
+  def beskar_authenticated_user = @verified_user
+  def beskar_authenticated_generation = @verified_claims["beskar_generation"]
+end
+```
+
+For Action Cable, prepend `Beskar::Channels::SessionSecurity` to the shared
+`ApplicationCable::Channel` base. The connection must expose public
+`beskar_authenticated_user` and `beskar_authenticated_generation` methods from a
+verified credential, plus its normal `request`. Missing readers, missing/old
+generations, locks and unavailable state fail closed. **Never fill a missing token
+generation with `user.beskar_session_token` on resumption**: doing so would give
+an old credential a new generation and bypass revocation. Native DB-session
+connections can use the persisted-session guard instead, through a host adapter.
+
+Inventory every login, impersonation, recovery auto-login, API base, native
+session reader and Cable base before enabling enforcement. Verify each with a
+lock/revoke/unlock replay test. Beskar cannot guarantee coverage for omitted
+hooks, unprotected model classes, direct `connection.transmit`, or host overrides
+that intentionally bypass the supported pipeline.
+
+## Administrative history and permissions
+
+Security events survive account deletion unchanged and now reject ordinary
+instance rewrites/deletes. Administrative history is also append-only at the
+model layer; raw SQL/bulk APIs and privileged Ruby code remain outside this
+guarantee. No historical rows were rewritten or backfilled.
+
+Dashboard authentication grants no capabilities by itself. Configure
+`authorize_admin(request, permission)` in controller context to return exactly
+true for separately assigned `:read`, `:manage_bans`, `:export`, or `:read_audit`
+grants. Missing callbacks/grants deny access. Do not infer permissions from the
+request; consult the host's trusted role/permission store.
+
+Exports require a trusted `audit_actor`, a reason, and a committed journal record
+before sending a body. The record includes resource, format, filtered query,
+result count/ID bounds and truncation. A log of preparation does not prove client
+receipt. Every cursor page needs a reason. See docs/guides/audit-lifecycle.md for ban history
+and atomic all-or-nothing mutations.
+
+Configuration is sealed after startup. For exceptional process-local runtime
+changes, configure a separate `authorize_configuration(actor)` callback at boot,
+then call `Beskar.configure(actor:, reason:, request_id:) { |candidate| ... }`.
+It serializes local publication, validates a copy and requires a filtered
+before/after journal before publishing. Open database transactions are rejected.
+The record includes changed top-level settings; callbacks are represented as
+`[CALLBACK]`, never serialized code. Per-entry filtering/bounds still apply.
+
+This is not distributed configuration: restart all workers from reviewed
+initializers for normal deployments. A crash between journal commit/publication
+can leave an intent record without publication. Source-controlled boot edits,
+environment changes, and trusted callback code changes require host deployment
+auditing; they cannot safely require a migrated database during initial boot.
+
+## Advertised features
+
+The nonexistent versioned API routes remain removed. No built-in automatic
+pattern analyzer is advertised: enabling it requires a real host Active Job and
+startup validates that dependency. Notifications have opt-in Action Mailer jobs,
+bounded retries, and explicit sender/recipient/recovery-page configuration.
+Recovery itself uses host/Devise token and unlock workflows, not a Beskar token
+issuer. Production delivery, an outbox, replay/idempotence policy and support
+identity verification remain host/operational work; see docs/guides/notifications-and-recovery.md.
+
+## Availability and validation gate
+
+The global login budget now defaults off, removing its shared lock hot spot and
+distributed-attacker kill switch. `global_attempts[:enabled] = true` explicitly
+restores both. IP/account admission and backoff remain enabled. Authentication
+quotas no longer deny unrelated traffic or auto-ban shared egress by default;
+`ip_attempts[:block_requests] = true` restores that opt-in policy.
+
+Shared-NAT users can still share a login quota, and attackers can target one
+account's quota. Tune thresholds with observed traffic. There is no unconditional
+DoS resistance: password hashing, audit growth, writer availability, pool/lock
+timeouts, WAF storage and ingress bandwidth remain finite resources. Required
+pre-request state failures return a no-store 503/Retry-After response; arbitrary
+host database exceptions retain their host handling.
+
+The SQLite suite includes independently leased connections, lost-update/admission
+races, rollback/retry, null/unavailable caches, distributed-budget isolation, NAT
+page access and dependency failures. PostgreSQL 17/MySQL 8.4 CI jobs run the full
+suite using `BESKAR_TEST_DATABASE_URL`; **not yet executed here**. Docker daemon
+access was denied, including outside the sandbox. Installed pg/mysql2 adapters
+alone are not evidence of tested servers. No production throughput claim is made.
+
+Before production, run those jobs and host load/soak tests across multiple app
+workers: successful/failed/distributed logins, concentrated account/NAT traffic,
+WAF bursts, exports, concurrent locks/session creation, database loss/recovery,
+pool exhaustion and bounded-retry exhaustion. Measure p50/p95/p99 latency, error
+rate, password CPU, query/lock waits, pool utilization and table growth. Set host
+ingress limits, database statement/lock timeouts and operational alerts from the
+measured capacity. Never use a production database URL with Rails test tasks.
+
+## Rollout
+
+1. Install/apply all engine migrations, including `ExpandAdministrativeActionTargets`.
+2. Configure separate dashboard permissions and actor resolution; update exports
+   to send a reason. Runtime settings now require the audited path.
+3. Deploy the host authentication adapters and signed generation claims; reject
+   or reissue legacy tokens without them. Plan the one-time Devise sign-out.
+4. Drain old workers and restart from the same reviewed configuration. Mixed
+   versions can otherwise issue stale credentials or mutate/delete old audit rows.
+5. Keep the adapter/load gate open until actually run. Only the local test
+   database was migrated; no production database, remote CI or mail service was changed.