//go:build dev || test

package auth

// Dev/test builds of the verification-code flow (POST /api/verify/generate):
// the [VERIFY] log line is the LOCAL DEV delivery channel — the stand-in for
// the not-yet-wired email/SMS transport (P6) — and a missing TWO_FACTOR_PEPPER
// still falls back to the legacy unsalted SHA-256 digest (via the shared
// crussell/internal/twofa provider, which logs its own one-time warning).
// Production builds (!dev && !test) never log the code — stdout-log delivery
// is a dev/test-only local feature — and fail closed — see verifycode_prod.go.

import "log"

// verificationCodeEnsureIssueAllowed always permits code issuance in dev/test
// builds: the loose-fake delivery (the [VERIFY] log line) is the documented
// stand-in until email/SMS lands. Production builds fail closed here — no
// TWO_FACTOR_PEPPER, no codes (see verifycode_prod.go).
func verificationCodeEnsureIssueAllowed() error { return nil }

// verificationCodeDeliver delivers a fresh verification code to the user.
// Dev/test: the [VERIFY] log line is the delivery channel — an operator relays
// the code to the user out-of-band until email/SMS lands (mirrors the [2FA]
// log relay, which the 2FA flow uses identically). MEDIUM-3b: the user id and
// the plaintext code go to SEPARATE log lines so a single record cannot trivially
// pair a code with its owner.
func verificationCodeDeliver(userID, purpose, code string) {
	log.Printf("[VERIFY] code delivery requested (user=%s, purpose=%s)", userID, purpose)
	log.Printf("[VERIFY] code: %s", code)
}