@dsalazardev/ai-hub-cli 0.0.0-stage → 0.2.0

package/skills/shared/elixir/references/otp-patterns.md

@@ -0,0 +1,96 @@
+# OTP patterns
+
+Depth offloaded from SKILL.md. Pick the lightest behaviour that fits.
+
+## Choosing an OTP behaviour
+
+| Need | Reach for | Notes |
+|---|---|---|
+| State behind a custom API, callbacks | `GenServer` | The workhorse; full control over messages |
+| Trivial state, get/update by function | `Agent` | A thin GenServer wrapper; no custom protocol |
+| One-off concurrent computation | `Task` | `Task.async/await`, or `Task.async_stream` for bounded fan-out |
+| Supervised fire-and-forget jobs | `Task.Supervisor` | Crashes isolated, no result needed |
+| Many dynamic, identical children | `DynamicSupervisor` + `Registry` | Start/stop children at runtime, look them up by key |
+| Explicit state machine with phases | `:gen_statem` (Erlang) | When transitions/events dominate; usable directly from Elixir |
+| Shared read-heavy data | `:ets` | Concurrent lock-free reads; one owner process holds the table |
+
+## DynamicSupervisor + Registry recipe
+
+Use this when you want one process per logical entity (per user, per connection, per token bucket) started on demand and addressable by a key.
+
+```elixir
+# In application.ex children, before the workers:
+#   {Registry, keys: :unique, name: MyApp.Registry},
+#   {DynamicSupervisor, name: MyApp.WorkerSup, strategy: :one_for_one}
+
+defmodule MyApp.Worker do
+  use GenServer
+
+  def start_link(id) do
+    GenServer.start_link(__MODULE__, id, name: via(id))
+  end
+
+  defp via(id), do: {:via, Registry, {MyApp.Registry, id}}
+
+  # Start (or return existing) a worker for `id`.
+  def ensure_started(id) do
+    case DynamicSupervisor.start_child(MyApp.WorkerSup, {__MODULE__, id}) do
+      {:ok, pid} -> {:ok, pid}
+      {:error, {:already_started, pid}} -> {:ok, pid}
+      other -> other
+    end
+  end
+
+  @impl true
+  def init(id), do: {:ok, %{id: id}}
+end
+```
+
+`{:via, Registry, {Registry, key}}` lets you address a process by `key` without ever touching its pid. The Registry entry is removed automatically when the process dies — no stale-pid bookkeeping.
+
+## Timeouts, backpressure, and mailbox growth
+
+- `GenServer.call/3` defaults to a **5000 ms** timeout. If the server is slow, the *caller* gets an `:timeout` exit. Raise the timeout only when the operation is legitimately long; otherwise the slowness is the bug.
+- A **growing mailbox** means messages arrive faster than `handle_*` drains them. Causes: an unbounded `cast` producer, an expensive `handle_info`, or a process doing too much. Fixes:
+  - Switch hot producers from `cast` to `call` so the caller blocks (natural backpressure).
+  - Move heavy work out of the GenServer (into a `Task` it supervises).
+  - Shard the work across many processes instead of one.
+  - For true streaming/backpressure, use `GenStage`/`Flow` (external deps).
+- `handle_continue/2` runs immediately after `init` (or after the returning callback) before the next message — use it for post-init warm-up so `start_link` returns fast.
+
+## Task and Task.Supervisor
+
+```elixir
+# Bounded concurrent fan-out — never spawns more than max_concurrency at once.
+ids
+|> Task.async_stream(&fetch/1, max_concurrency: 10, timeout: 30_000)
+|> Enum.map(fn {:ok, result} -> result end)
+
+# Supervised fire-and-forget (add {Task.Supervisor, name: MyApp.Tasks} to children):
+Task.Supervisor.start_child(MyApp.Tasks, fn -> do_async_thing() end)
+```
+
+Prefer `Task.async_stream` over manually spawning N tasks — it bounds concurrency and applies a per-item timeout.
+
+## Agent (when GenServer is overkill)
+
+```elixir
+{:ok, agent} = Agent.start_link(fn -> %{} end)
+Agent.update(agent, &Map.put(&1, :k, 1))
+Agent.get(agent, &Map.get(&1, :k))
+```
+
+Note: every `Agent.get`/`update` runs its function in the agent process — keep them tiny, or you recreate the god-process bottleneck.
+
+## ETS for shared read state
+
+```elixir
+:ets.new(:cache, [:named_table, :set, :public, read_concurrency: true])
+:ets.insert(:cache, {:key, value})
+case :ets.lookup(:cache, :key) do
+  [{:key, v}] -> {:ok, v}
+  [] -> :error
+end
+```
+
+ETS gives concurrent lock-free reads, so a read-heavy cache does not bottleneck on a single GenServer mailbox. Have one process own and create the table (so the table dies with it, or use `:heir` to transfer ownership on crash).

package/skills/shared/elixir/scripts/verify.sh

@@ -0,0 +1,76 @@
+#!/usr/bin/env bash
+# verify.sh — read-only checks for an Elixir/OTP target.
+#
+# Checks (only when the toolchain and artifacts are present):
+#   - `mix format --check-formatted` (style)
+#   - `mix compile --warnings-as-errors` (warning-free compile) at a mix project root
+#
+# Never blocks a toolchain-free or empty target: exits 0 with a skip note when
+# Elixir/mix is absent or there is nothing to check. No network, no writes.
+#
+# Usage: bash scripts/verify.sh [TARGET_DIR]   (default: current directory)
+
+set -euo pipefail
+
+TARGET="${1:-.}"
+
+if [ ! -d "$TARGET" ]; then
+  echo "verify: target '$TARGET' is not a directory — nothing to check. SKIP."
+  exit 0
+fi
+
+# Toolchain gate: no mix on PATH -> skip cleanly (do not fail CI without a toolchain).
+if ! command -v mix >/dev/null 2>&1; then
+  echo "verify: 'mix' not found on PATH — Elixir toolchain not installed. SKIP."
+  exit 0
+fi
+
+# Find a mix project root (a directory containing mix.exs), shallowest first.
+mix_root=""
+if [ -f "$TARGET/mix.exs" ]; then
+  mix_root="$TARGET"
+else
+  mix_root="$(find "$TARGET" -maxdepth 4 -name mix.exs -not -path '*/deps/*' -not -path '*/_build/*' 2>/dev/null \
+    | awk '{ print gsub(/\//,"/"), $0 }' | sort -n | head -n1 | cut -d' ' -f2- || true)"
+  [ -n "$mix_root" ] && mix_root="$(dirname "$mix_root")"
+fi
+
+# Count loose Elixir sources in the target (excludes deps/_build).
+ex_count="$(find "$TARGET" \( -name '*.ex' -o -name '*.exs' \) \
+  -not -path '*/deps/*' -not -path '*/_build/*' 2>/dev/null | wc -l | tr -d ' ')"
+
+if [ -z "$mix_root" ] && [ "$ex_count" = "0" ]; then
+  echo "verify: no mix.exs and no .ex/.exs files under '$TARGET' — nothing to check. SKIP."
+  exit 0
+fi
+
+status=0
+
+if [ -n "$mix_root" ]; then
+  echo "verify: mix project root -> $mix_root"
+
+  echo "verify: mix format --check-formatted"
+  if ! ( cd "$mix_root" && mix format --check-formatted ); then
+    echo "verify: FAIL — files are not formatted (run: mix format)"
+    status=1
+  fi
+
+  echo "verify: mix compile --warnings-as-errors"
+  if ! ( cd "$mix_root" && mix compile --warnings-as-errors ); then
+    echo "verify: FAIL — compile produced warnings or errors"
+    status=1
+  fi
+else
+  # Loose .ex/.exs without a mix project: format check only (compile needs a project).
+  echo "verify: no mix.exs found; checking formatting of $ex_count loose Elixir file(s)"
+  echo "verify: mix format --check-formatted"
+  if ! ( cd "$TARGET" && mix format --check-formatted ); then
+    echo "verify: FAIL — files are not formatted (run: mix format)"
+    status=1
+  fi
+fi
+
+if [ "$status" -eq 0 ]; then
+  echo "verify: OK"
+fi
+exit "$status"

package/skills/shared/email-deliverability/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: email-deliverability
+description: "Use when mail already sent lands in spam, is rejected, or fails the Gmail/Yahoo bulk-sender checks and the fix is authentication and reputation, not the sending code: SPF/DKIM/DMARC alignment, domain warmup, spam-complaint rate, one-click unsubscribe, BIMI. NOT putting mail on the wire through a provider API (that is `email-connector`)."
+tags: [email, deliverability, spf, dkim, dmarc, bimi, sender-reputation, bulk-sender]
+recommends: [email-connector, newsletter, cold-outreach, gdpr-privacy, data-policy]
+origin: ai-hub
+---
+
+# email-deliverability — make mail authenticate and land in the inbox
+
+This skill owns one layer: **why mail you already send gets filtered, deferred,
+or rejected, and the DNS + reputation work that fixes it.** It starts where the
+send technically succeeds but the message never reaches the inbox.
+
+The lever is almost never the sending code. It is three DNS records that must
+*align*, a complaint rate you must hold down, and a reputation you build slowly
+and lose fast. Treat this as ops on a domain, not a code change.
+
+## Not this skill
+
+- **Sending the mail at all** — provider SDK, `sendEmail()` seam, templates,
+  retries, batch caps, bounce/complaint webhooks → `../email-connector/SKILL.md`.
+  That skill feeds the suppression list; this one explains the reputation it
+  protects.
+- **Subject lines, open/click optimization, list growth** → `newsletter`.
+- **Outbound prospecting sequences, lead lists** → `cold-outreach` (deliverability
+  is a *constraint* on it, not the same job).
+- **Consent, lawful basis, retention of the address list** → `gdpr-privacy` and
+  `data-policy`. Unsubscribe *mechanics* live here; consent *law* does not.
+- **Handling the DKIM private key and provider API secrets** →
+  `../secure-coding/SKILL.md`.
+
+## The three records that must align
+
+SPF, DKIM, and DMARC are not three ways to do the same thing. DMARC is the
+policy; it *passes* only when SPF or DKIM both authenticate **and align** with
+the visible `From:` domain. Most "SPF is set but DMARC fails" tickets are an
+alignment miss, not a missing record.
+
+| Record | What it asserts | Common break |
+|---|---|---|
+| SPF (TXT) | This IP/host is allowed to send for the domain | Lists the provider but the `Return-Path` is a different domain → no alignment |
+| DKIM (TXT) | This message body+headers are signed by a key the domain published | Provider signs with `provider.net`, not your domain → no alignment; or a deprecated 1024-bit key (publish 2048-bit, rotate periodically) |
+| DMARC (TXT at `_dmarc`) | What to do when neither aligns, plus where to send reports | Policy left at `p=none` forever; never tightened |
+
+```dns
+; DMARC — start at none to collect reports, then tighten to quarantine/reject.
+_dmarc.acme.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@acme.com; fo=1"
+```
+
+Alignment rule, stated once: the domain in `From:` must match the domain SPF
+authenticated (the `Return-Path`/envelope domain) **or** the domain in the DKIM
+`d=` tag. Use a custom Return-Path and a domain-keyed DKIM selector through your
+provider so at least one aligns. Verifying SPF alone passing is the classic
+false comfort.
+
+## Gmail / Yahoo bulk-sender rules
+
+If you send **more than ~5,000 messages/day** to Gmail or Yahoo accounts, these
+are enforced, not advisory. Enforcement ramped from late 2025; failures now draw
+temporary and permanent rejections, not silent spam-foldering.
+
+1. **SPF + DKIM both set, and DMARC present** at minimum `p=none`. At least one
+   of SPF/DKIM must align with `From:`.
+2. **One-click unsubscribe** (`List-Unsubscribe` + `List-Unsubscribe-Post`) on
+   marketing/promotional mail, honored within **2 days**. Transactional mail
+   (password reset, receipt, shipping) is exempt.
+3. **Spam-complaint rate** kept low. The hard threshold where filtering kicks in
+   is **0.3%** (Postmaster Tools); Google's reliable-inbox target is **below
+   0.1%**. Treat 0.3% as the cliff, 0.1% as the speed limit.
+
+```text
+List-Unsubscribe: <https://acme.com/u/abc123>, <mailto:unsub@acme.com?subject=unsub>
+List-Unsubscribe-Post: List-Unsubscribe=One-Click
+```
+
+## BIMI — the verified logo, last
+
+BIMI shows your brand logo (and on Gmail a blue verified checkmark) next to the
+message. It is the **last** step, never a fix for placement: it requires you have
+*already* passed DMARC at enforcement, and it changes how a delivered message
+looks, not whether it gets delivered.
+
+Hard prerequisite: DMARC at `p=quarantine` or `p=reject` with `pct=100`. A record
+left at `p=none` does **not** qualify — that is why "add BIMI to escape the spam
+folder" is backwards; you cannot publish it until the auth work is done.
+
+Whether the logo (and checkmark) actually render depends on the certificate:
+
+| Approach | Cost / proof | Where it shows |
+|---|---|---|
+| Self-asserted (no certificate) | Free; logo only | Yahoo, Fastmail — **not** Gmail |
+| CMC (Common Mark Certificate) | Cheaper; ~12 months of public logo use, no registered trademark | Gmail + the rest, with checkmark |
+| VMC (Verified Mark Certificate) | ~$749–$1,500/yr; needs a registered (or government-modified) trademark | Gmail + the rest, with checkmark |
+
+Active mark-certificate issuers in 2026: DigiCert, GlobalSign, SSL.com (Sectigo
+resells; Entrust exited mark certificates in 2025). The logo file must be **SVG
+Tiny PS 1.2**, square, with no scripts or external references.
+
+```dns
+; BIMI — only valid once DMARC is at quarantine/reject with pct=100.
+; a= is the VMC/CMC PEM; omit it for a self-asserted (non-Gmail) logo.
+default._bimi.acme.com.  IN TXT  "v=BIMI1; l=https://acme.com/logo.svg; a=https://acme.com/vmc.pem"
+```
+
+Do BIMI only after weeks of clean, enforced DMARC. It amplifies a good
+reputation; it does not create one.
+
+## Warm a cold domain (decision flow)
+
+A brand-new domain has zero reputation; blasting volume on day one looks exactly
+like a spammer. Warm only if the domain genuinely has no history.
+
+- **New domain, no send history** → warm: start ~20-50/day to *engaged*
+  recipients, roughly double every few days over 4-6 weeks, watch Postmaster
+  reputation before each step up. Send your most-opened content first.
+- **Established domain, new provider/IP** → warm the *IP* path, not the domain;
+  migrate a slice of volume and ramp.
+- **Established domain, same IP, sudden spam folder** → do NOT warm; this is a
+  reputation or auth regression. Read the rejection code and Postmaster trend
+  first (see the error table).
+
+Skipping warmup to "just send the campaign" is the most common self-inflicted
+blacklisting. There is no fast path; reputation is earned by consistent,
+low-complaint sending.
+
+## Read the rejection, then act
+
+| Signal | Likely cause | Fix |
+|---|---|---|
+| `550 5.7.26` | Message unauthenticated — SPF and DKIM both failed/missing | Publish SPF + DKIM through the provider; confirm at least one aligns |
+| `dmarc=fail` in headers, SPF=pass | Alignment miss: `Return-Path` ≠ `From:` domain | Set a custom Return-Path on your domain, or align the DKIM `d=` |
+| `421`/`451` deferral, then later delivery | Receiver throttling an unwarmed/spiky sender | Slow the ramp; spread volume; warm the domain |
+| Postmaster "Bad" domain reputation | Sustained complaints / spam-trap hits | Cut volume, prune unengaged, fix consent, hold under 0.1% complaints |
+| Lands in Promotions (not Spam) | Not a failure — bulk/marketing classification | Leave it; do not chase the Primary tab by faking transactional headers |
+
+## Anti-patterns
+
+| Anti-pattern | Why it breaks | Do instead |
+|---|---|---|
+| "SPF passes, so we're authenticated" | DMARC needs *alignment*; SPF on a mismatched Return-Path still fails DMARC | Verify DMARC result in headers, not SPF alone; align Return-Path or DKIM |
+| Leaving DMARC at `p=none` forever | Publishes intent to enforce nothing; spoofers and filters both notice | Collect `rua` reports, then move to `quarantine` then `reject` |
+| `p=reject` on day one with no report review | Silently drops your own legitimate sub-streams (CRM, support tools) | Stage `none` → `quarantine` → `reject`, reading reports at each step |
+| Blasting full volume from a new domain | Looks like spam; gets throttled/blacklisted with no recovery for weeks | Warm: tiny start to engaged users, ramp over 4-6 weeks |
+| Buying/scraping a list to hit volume | Spam traps + complaints spike past 0.3% → domain reputation tanks | Send only to opted-in, engaged recipients; prune the unengaged |
+| Faking transactional headers to dodge Promotions | Violates bulk rules; risks rejection, not just foldering | Accept Promotions placement; earn Primary via engagement |
+| Routing the unsubscribe to a form that takes a week | Breaks the 2-day one-click honor rule; raises complaints | Honor `List-Unsubscribe-Post` one-click within 2 days, automatically |
+| Adding BIMI to fix spam-foldering | BIMI needs DMARC enforcement you do not have yet, and it changes logo display, not placement | Fix auth + reputation first; add BIMI last as a branding layer |

package/skills/shared/email-deliverability/evals/README.md

@@ -0,0 +1,21 @@
+# Evals — email-deliverability
+
+`cases.yaml` holds three blocks. `should_trigger` (7 prompts) are situations this
+skill must own — the SPF-passes-but-DMARC-fails alignment trap, domain warmup,
+the one-click-unsubscribe rule, the BIMI verified-logo request, and a Spanish
+phrasing of the spam-folder flagship. `should_not_trigger` (5 prompts) are
+near-misses that each route to a
+real sibling (`email-connector`, `newsletter`, `cold-outreach`, `gdpr-privacy`,
+`data-policy`) so the boundary is checked, not just recall — the sharpest being
+the send-path question that belongs to `email-connector`. `capability` (1
+scenario) is an 8k/day Gmail-sender remediation with a `must_include` rubric
+covering alignment diagnosis, SPF/DKIM fix, the bulk-sender threshold, one-click
+unsubscribe, complaint-rate targets, and staged DMARC tightening.
+
+There is no automated runner. To evaluate, paste each `should_trigger` /
+`should_not_trigger` prompt into an agent loaded with the catalog and confirm it
+selects (or declines) `email-deliverability` and routes to the named sibling.
+For `capability`, run the scenario and check the answer against every
+`must_include` line — then run `scripts/verify.sh <path-to-dns-or-config>` to
+mechanically confirm the DMARC policy and authentication invariants in any DNS
+zone / mail config the answer produces.

package/skills/shared/email-deliverability/evals/cases.yaml

@@ -0,0 +1,45 @@
+skill: email-deliverability
+
+should_trigger:
+  - prompt: "Our transactional emails started going to spam in Gmail right after their big update. SPF is set. What's wrong?"
+    why: "Flagship symptom: inbox placement regression tied to the Gmail bulk-sender enforcement, with the SPF-passes-but-still-spam alignment trap."
+  - prompt: "DMARC keeps failing in the headers even though SPF passes — how do I make them agree?"
+    why: "Non-obvious core: DMARC fails on alignment, not on a missing SPF record. The fix is Return-Path / DKIM d= alignment, the skill's central distinction."
+  - prompt: "We just bought a fresh domain for outreach. How do I warm it up so we don't get blacklisted on the first send?"
+    why: "Warmup is a named decision flow here. Distinguishes new-domain (warm) from same-IP-regression (don't warm)."
+  - prompt: "Do we legally need one-click unsubscribe to keep sending marketing mail to gmail addresses, and how fast must we honor it?"
+    why: "Bulk-sender requirement: List-Unsubscribe-Post one-click honored within 2 days; transactional exempt. Specific rule the skill owns."
+  - prompt: "Los correos nos caen en spam y el SPF está bien configurado, ¿qué revisamos?"
+    why: "Spanish phrasing of the flagship alignment problem — must fire across language, routes to DMARC alignment + reputation checks."
+  - prompt: "Postmaster Tools shows our domain reputation dropped to Bad and we're getting 421 deferrals. What's the recovery path?"
+    why: "Reputation + deferral diagnosis. Non-obvious that 421 is throttling and the fix is volume/complaint reduction, not resending harder."
+  - prompt: "How do I get our company logo and that blue checkmark to show up next to our emails in Gmail?"
+    why: "BIMI/VMC is in scope. Non-obvious that the logo depends on DMARC already being at enforcement and on a VMC/CMC certificate, not on a copy or sending change."
+
+should_not_trigger:
+  - prompt: "Wire up Resend in our Node app with a sendEmail() seam and idempotent retries for password-reset mail."
+    route_to: "email-connector"
+    why: "Putting mail on the wire through a provider SDK — the send path, not the reputation behind it. email-connector owns the transport and suppression list."
+  - prompt: "Write me three subject-line variants and an A/B plan to lift open rates on our weekly digest."
+    route_to: "newsletter"
+    why: "Copy and engagement optimization, not authentication or reputation DNS. newsletter owns subject/open/click."
+  - prompt: "Build a 6-step cold outreach sequence with personalized first lines for this lead list."
+    route_to: "cold-outreach"
+    why: "Prospecting sequence design. Deliverability constrains it but the deliverable here is the sequence, which is cold-outreach."
+  - prompt: "Do we have lawful basis under GDPR to email this list, and how long can we retain the addresses?"
+    route_to: "gdpr-privacy"
+    why: "Consent and retention law, not unsubscribe mechanics or DNS. The legal basis behind the list is gdpr-privacy."
+  - prompt: "Define our company-wide policy for how long we keep customer contact data and who can access it."
+    route_to: "data-policy"
+    why: "Data governance / retention policy as the deliverable, not inbox placement. data-policy, not deliverability."
+
+capability:
+  - scenario: "A SaaS sends ~8,000 marketing emails/day to mostly Gmail recipients. They report messages now bounce with 550 5.7.26 or land in spam; SPF passes but headers show dmarc=fail. Diagnose and give a concrete remediation plan."
+    must_include:
+      - "Identify the root cause as a DMARC alignment failure (SPF passing on a Return-Path that does not match the From: domain), not a missing record"
+      - "Prescribe aligning at least one of SPF (custom Return-Path on the sending domain) or DKIM (domain-keyed d= selector via the provider)"
+      - "Note the 5,000/day Gmail-Yahoo bulk-sender threshold applies: SPF + DKIM + DMARC at minimum p=none, with at least one aligned"
+      - "Require one-click unsubscribe (List-Unsubscribe + List-Unsubscribe-Post) honored within 2 days on the marketing mail"
+      - "Set a spam-complaint target below 0.1% with 0.3% as the enforcement cliff, watched in Postmaster Tools"
+      - "Stage DMARC policy none -> quarantine -> reject while reading rua reports, rather than jumping straight to reject"
+      - "Treat BIMI as out of scope for this fix: it requires DMARC already at enforcement and does not change placement, so do not propose it as the spam remedy"

package/skills/shared/email-deliverability/scripts/verify.sh

@@ -0,0 +1,98 @@
+#!/usr/bin/env bash
+#
+# verify.sh — DNS / mail-config deliverability linter. NO network, NO DNS
+# lookups. Scans a target dir or file for the authentication anti-patterns this
+# skill bans and exits non-zero on a hard finding.
+#
+# Read-only. Never writes, edits, or sends anything.
+#
+# Checks (text-only; this does not resolve DNS):
+#   1. A DMARC record left at "p=none" — a WARN, not a fail: fine for the report
+#      phase, but a reminder it must be tightened to quarantine/reject.
+#   2. A DMARC record at "p=reject" with NO rua= reporting address — a FAIL:
+#      enforcing with no visibility silently drops legitimate sub-streams.
+#   3. A "v=spf1" record ending in "+all" — a FAIL: passes any sender, defeats SPF.
+#
+# Usage:
+#   scripts/verify.sh [PATH ...]    PATH = a zone/config file or dir; default "."
+#
+# Exit 0 = no hard finding (clean/empty target passes). 1 = a hard finding.
+# Exit 2 = usage/environment problem.
+
+set -euo pipefail
+
+# Never let this script flag itself. grep -rn emits "<path>:<line>:..."; strip
+# any hit whose path component basenames to this script (relative or absolute).
+SELF_BASE="$(basename "${BASH_SOURCE[0]}")"
+drop_self() {
+  awk -v self="$SELF_BASE" -F: '{
+    p = $1
+    n = split(p, parts, "/")
+    if (parts[n] != self) print
+  }'
+}
+
+if [ "$#" -eq 0 ]; then
+  set -- "."
+fi
+
+declare -a TARGETS=()
+for t in "$@"; do
+  if [ -e "$t" ]; then
+    TARGETS+=("$t")
+  else
+    echo "verify.sh: no such path: $t" >&2
+  fi
+done
+
+if [ "${#TARGETS[@]}" -eq 0 ]; then
+  echo "verify.sh: nothing to scan"
+  exit 0
+fi
+
+INCLUDE=(--include='*.txt' --include='*.zone' --include='*.dns'
+  --include='*.conf' --include='*.cf' --include='*.yaml' --include='*.yml'
+  --include='*.tf' --include='*.json' --include='*.env')
+EXCLUDE=(--exclude-dir=.git --exclude-dir=node_modules --exclude=verify.sh)
+
+fail=0
+emit() {
+  echo "FAIL  $1"
+  while IFS= read -r line; do
+    [ -n "$line" ] && echo "        $line"
+  done <<< "$2"
+  fail=1
+}
+
+# --- check 1: DMARC p=none (WARN) -----------------------------------------
+none="$( { grep -rnI "${EXCLUDE[@]}" "${INCLUDE[@]}" \
+  -E 'v=DMARC1[^"]*p=none' "${TARGETS[@]}" 2>/dev/null || true; } | drop_self)"
+if [ -n "${none//[$'\n']/}" ]; then
+  echo "WARN  DMARC at p=none (report phase only — tighten to quarantine/reject):"
+  while IFS= read -r l; do [ -n "$l" ] && echo "        $l"; done <<< "$none"
+fi
+
+# --- check 2: DMARC p=reject with no rua= reporting (FAIL) -----------------
+reject_hits=""
+while IFS= read -r l; do
+  [ -z "$l" ] && continue
+  if ! printf '%s' "$l" | grep -q 'rua='; then
+    reject_hits+="${l}"$'\n'
+  fi
+done < <( { grep -rnI "${EXCLUDE[@]}" "${INCLUDE[@]}" \
+  -E 'v=DMARC1[^"]*p=reject' "${TARGETS[@]}" 2>/dev/null || true; } | drop_self)
+if [ -n "${reject_hits//[$'\n']/}" ]; then
+  emit "DMARC p=reject with no rua= report address (enforcing blind drops legit mail)" "$reject_hits"
+fi
+
+# --- check 3: SPF +all (FAIL) ---------------------------------------------
+spf="$( { grep -rnI "${EXCLUDE[@]}" "${INCLUDE[@]}" \
+  -E 'v=spf1[^"]*\+all' "${TARGETS[@]}" 2>/dev/null || true; } | drop_self)"
+if [ -n "${spf//[$'\n']/}" ]; then
+  emit "SPF ends in +all (passes any sender — use -all or ~all)" "$spf"
+fi
+
+if [ "$fail" -eq 0 ]; then
+  echo "OK    no hard deliverability anti-pattern found"
+fi
+exit "$fail"