+`src/lib/email-verify-script.ts`. No workflow step calls the waterfall, so it is a SERVICE switch held by workflow-service (`GET /internal/scripts/switches/service?outcome=email_found&callerService=apollo`, read at most once a minute; unreadable = last state, never read = our code). After the 30-day reuse (a held FINAL verdict asks nothing; a held step-1 catch_all/unknown is handed to the decision as `held`), the decision runs either HERE (`stepOne` + `secondOpinion` on its own `email-verification` run, child of the caller's run: Monitoring's service path) or, switched and with a caller run + user, as the stored script (`POST /internal/scripts/run`, `recordedBy: "apollo"`, parent = the caller's run). The script reaches us only through two DOORS that serve a verification IN FLIGHT here (`x-caller-run-id` + address, `registerInFlight`): `POST /internal/email-verifier-calls {verifier, email}` (our exact verifier call: hold, run under the SCRIPT's run, bronze row naming the CALLER's run (`VerificationContext.callRunParentId` moves only the run parent), email_checked, Apify-out timer, BounceBan resume/poll) and `GET /internal/email-verifier-calls/apify`. A refusal a door meets (billing, key, BounceBan pending, every verifier failed) is kept on the in-flight entry and re-thrown to the caller as the SAME `EmailVerificationError` (routes answer as before). EVERY decision, both paths, is recorded with its calls in the script's words (`email_verification_decisions`, migration 0048, fail-soft), served `GET /internal/email-verification-decisions/recorded?after=<seq>` (service key, 60 s settle) to workflow-service's case recorder. Guards: `email-verify-script.test.ts`, decision-run assertions in `email-verification*.test.ts` / `apify-credit-alert.test.ts`.
0 commit comments