@@ -0,0 +1,17 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+The `no_sign_in_account_at_boot` boot report states the email-verification rule each audience posture enforces.
+
+Clause-②: no
+
+The report's recovery advice said an `open` or `email_domain` posture forces email verification on the invited login. Later in the same message it said an `open` deployment can turn verification off. The first sentence stopped being true when posture `open` began honouring a deployment's opt-out. The message now states the rule once, as the auth plugin enforces it, and applies it to the invited login and to a new self-registered address alike:
+
+- `email_domain` always forces email verification on.
+- `open` forces it on unless the deployment turns it off, with `emailAndPassword.requireEmailVerification: false` or `OS_AUTH_REQUIRE_EMAIL_VERIFICATION=false`. A `false` stored only through the settings console is refused.
+- `invite_only` follows the deployment's declaration and is off by default.
+
+The advice keeps its order: on a deployment with no mail transport, close the posture back to `invite_only`, with verification left at its default off, before the invited person registers.
+
+Text only: no admission decision, verification default or accepted value changes.
@@ -2292,10 +2292,12 @@ export class AuthManager {
             // written — INSTEAD of throwing USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL.
             //
             // We turn that shield on ourselves: a posture that permits
-            // self-registration FORCES `requireEmailVerification` on (see
-            // `createAuthInstance`), so `email_domain` and `open` sign-ups for an
-            // address that already exists answered 200 while `invite_only`
-            // answered 422 on the same population. Measured on a real ObjectQL
+            // self-registration forces `requireEmailVerification` on by default
+            // (see `createAuthInstance` — always under `email_domain`, and under
+            // `open` unless the deployment declared it off, #20389), so
+            // `email_domain` and `open` sign-ups for an address that already
+            // exists answered 200 while `invite_only` answered 422 on the same
+            // population. Measured on a real ObjectQL
             // engine with the posture held CONSTANT and only the verification flag
             // moved, so the divergence is the flag's, not the posture's: zero
             // inserts reach the engine, no `sys_account` appears, and the next
 
@@ -150,18 +150,31 @@ describe('#14353 — the dead-end shape reports, by name, with consequence AND r
   it('[#15588/F1] the no-mail-transport rider is SCOPED to the default posture', () => {
     // ⛔ This rider was WRONG in the first version of this line, stated for
     // EVERY posture. The carve-out is an ADMISSION verdict, not a verification
-    // bypass, so on `open`/`email_domain` the INVITED login is created and
+    // bypass, so wherever verification is on the INVITED login is created and
     // then refused EMAIL_NOT_VERIFIED — and creating it SILENCES this report
     // on the way past. That is the loud-dead-end-to-quiet-dead-end transition
     // remedy (b) warns about, delivered by the primary remedy. The exact
     // scoped phrasing is asserted so no future edit can re-generalise it.
     const msg = resolveNoSignInAccountReport(DEAD_END)!;
     expect(msg).toContain('ADMISSION verdict, not a verification bypass');
     expect(msg).toContain(
-      "under the default 'invite_only' posture no mail transport is needed either",
+      "under the default 'invite_only' posture it follows that same declaration and is OFF by default, " +
+        'so no mail transport is needed either',
     );
     // the rider must name the invited login as the thing verification hits …
-    expect(msg).toContain('forces email verification on the INVITED login too');
+    expect(msg).toContain('the INVITED login meets the same email-verification rule as any sign-up');
+    // … and state that rule as the resolver ships it: `email_domain` forced
+    // outright, `open` forced unless the DEPLOYMENT opts out, and the console
+    // unable to make that opt-out. Each clause is driven against the wiring in
+    // the `#20389` describe below.
+    expect(msg).toContain("Under 'email_domain' verification is always ON");
+    expect(msg).toContain("under 'open' it is ON unless the DEPLOYMENT has itself declared it off");
+    expect(msg).toContain('a false stored only through the settings console is refused there');
+    // [#20389] ⛔ The unconditional form this message carried before `open`
+    // honoured a deployment's opt-out — it contradicted remedy (b) in the same
+    // message. Either spelling coming back reds here.
+    expect(msg).not.toMatch(/an 'open' or 'email_domain' posture forces email verification/i);
+    expect(msg).not.toMatch(/every posture other than 'invite_only'[^.]*FORCES email verification/i);
     // … and give the operator the ORDER, which is the actionable half
     expect(msg).toContain("close the posture back to 'invite_only' BEFORE that person registers");
     // [#15588/N2] the lookup lowercases, so a mixed-case row is never found
@@ -246,14 +259,23 @@ const invitedSignUp = (posture: AudiencePosture, hasPendingInvitation: boolean)
     isBootstrap: false,
   });
 
-/** A manager carrying one audience declaration, for the wiring mirror. */
+/**
+ * A manager carrying one audience declaration, for the wiring mirror. The
+ * optional `emailAndPassword` block is the DEPLOYMENT's own declaration — the
+ * constructor config is the deployment's by definition (`assertAudienceConfig`
+ * runs there with `verificationDeclaredBy: 'deployment'`).
+ */
 const AUDIENCE_TEST_SECRET = 'test-secret-at-least-32-chars-long!!';
-const managerWith = (audience?: Record<string, unknown>) =>
+const managerWith = (
+  audience?: Record<string, unknown>,
+  emailAndPassword?: Record<string, unknown>,
+) =>
   new AuthManager({
     secret: AUDIENCE_TEST_SECRET,
     baseUrl: 'http://localhost:3000',
     dataEngine: engineOver({}).engine,
     ...(audience ? { audience } : {}),
+    ...(emailAndPassword ? { emailAndPassword } : {}),
   } as never);
 
 /** The declaration a widening posture needs to pass entry validation. */
@@ -328,12 +350,14 @@ describe('#15588 — the WARNING is true: ANY hand-written `sys_account` row sil
   });
 });
 
-describe('#15588 — the WARNING is true: widening the posture FORCES email verification on', () => {
-  it('`email_domain` and `open` both wire requireEmailVerification ON', () => {
-    // The manager forces it from `audiencePermitsSelfRegistration(posture)` and
-    // `getPublicConfig()` mirrors the wired flag, so this is the same fact the
-    // message reports: a login registered under a widened posture cannot sign
-    // in until a mail transport delivers the link.
+describe('#15588 — the WARNING is true: widening the posture forces email verification on BY DEFAULT', () => {
+  it('with nothing declared, `email_domain` and `open` both wire requireEmailVerification ON', () => {
+    // The wiring and `getPublicConfig()` both read
+    // `resolveEmailVerificationRequirement`, so this is the same fact the
+    // message reports: a login registered under a widened posture that has not
+    // opted out cannot sign in until a mail transport delivers the link. The
+    // `open` opt-out, and `email_domain` having none, are pinned in the
+    // `#20389` describe below.
     for (const posture of ['email_domain', 'open'] as const) {
       expect(
         managerWith(wideningAudience(posture)).getPublicConfig().emailPassword
@@ -349,10 +373,11 @@ describe('#15588 — the WARNING is true: widening the posture FORCES email veri
     expect(managerWith().getPublicConfig().emailPassword.requireEmailVerification).toBe(false);
   });
 
-  it("every posture other than 'invite_only' is one that widens — the message's exact claim", () => {
-    // The message says "every posture other than 'invite_only'". A fourth
-    // posture that did NOT permit self-registration would make that sentence
-    // wrong, and this is where that is caught.
+  it('with nothing declared, exactly the postures that widen wire it ON — read off the vocabulary', () => {
+    // The message states the verification rule posture by posture. A fourth
+    // posture that did NOT permit self-registration yet forced verification
+    // (or the reverse) would leave that rule incomplete, and this is where
+    // that is caught.
     for (const posture of AUDIENCE_POSTURES) {
       expect(
         managerWith(
@@ -369,7 +394,7 @@ describe('#15588/F1 — the carve-out ADMITS, it does not EXEMPT: the rider\u201
   // mechanisms together — the carve-out and the verification wiring — because
   // the false claim was precisely that the first cancels the second.
 
-  it('a widened posture admits the INVITED creation AND still forces verification on it', () => {
+  it('with nothing declared, a widened posture admits the INVITED creation AND still forces verification on it', () => {
     for (const posture of AUDIENCE_POSTURES.filter(audiencePermitsSelfRegistration)) {
       // admitted by the carve-out …
       expect(invitedSignUp(posture, true), `posture ${posture}`).toMatchObject({ admit: true });
@@ -382,7 +407,7 @@ describe('#15588/F1 — the carve-out ADMITS, it does not EXEMPT: the rider\u201
     }
   });
 
-  it('ONLY the default posture is mail-transport-free — the half the message still promises', () => {
+  it('the default posture, verification undeclared, is mail-transport-free — the half the rider promises', () => {
     expect(invitedSignUp('invite_only', true)).toMatchObject({ admit: true });
     expect(managerWith().getPublicConfig().emailPassword.requireEmailVerification).toBe(false);
   });
@@ -399,6 +424,60 @@ describe('#15588/F1 — the carve-out ADMITS, it does not EXEMPT: the rider\u201
   });
 });
 
+describe('#20389 — the rule the message states, driven against the wiring posture by posture', () => {
+  // The message now says: "Under 'email_domain' verification is always ON;
+  // under 'open' it is ON unless the DEPLOYMENT has itself declared it off
+  // (… a false stored only through the settings console is refused there);
+  // under the default 'invite_only' posture it follows that same declaration
+  // and is OFF by default". Each clause below drives the manager that wires
+  // it, so the day the rule moves, the sentence goes red with it.
+  const DEPLOYMENT_OPT_OUT = { requireEmailVerification: false };
+
+  it("`open` + the DEPLOYMENT's explicit false: the invited creation is admitted AND wired with verification OFF", () => {
+    expect(invitedSignUp('open', true)).toMatchObject({ admit: true });
+    expect(
+      managerWith(wideningAudience('open'), DEPLOYMENT_OPT_OUT).getPublicConfig().emailPassword
+        .requireEmailVerification,
+    ).toBe(false);
+  });
+
+  it('`open` + the same false stored only through the console: refused, and verification stays ON', () => {
+    const fromConsole = managerWith(wideningAudience('open'));
+    expect(() =>
+      fromConsole.applyConfigPatch({ emailAndPassword: DEPLOYMENT_OPT_OUT } as never, {
+        requireEmailVerificationFrom: 'console',
+      }),
+    ).toThrow(/posture 'open' FORCES email verification on unless the DEPLOYMENT turns it off/);
+    expect(fromConsole.getPublicConfig().emailPassword.requireEmailVerification).toBe(true);
+    // CONTROL — the identical patch declared by the deployment is honoured, so
+    // the refusal above is the declarant's, not the value's.
+    const fromDeployment = managerWith(wideningAudience('open'));
+    fromDeployment.applyConfigPatch({ emailAndPassword: DEPLOYMENT_OPT_OUT } as never, {
+      requireEmailVerificationFrom: 'deployment',
+    });
+    expect(fromDeployment.getPublicConfig().emailPassword.requireEmailVerification).toBe(false);
+  });
+
+  it('`email_domain` has no opt-out: the deployment’s explicit false refuses the boot', () => {
+    expect(() => managerWith(wideningAudience('email_domain'), DEPLOYMENT_OPT_OUT)).toThrow(
+      /posture 'email_domain' opens self-registration, which FORCES email verification on/,
+    );
+    // CONTROL — the same declaration without the false boots, verification ON.
+    expect(
+      managerWith(wideningAudience('email_domain')).getPublicConfig().emailPassword
+        .requireEmailVerification,
+    ).toBe(true);
+  });
+
+  it('`invite_only` follows the declaration: OFF by default, ON when the deployment declares it', () => {
+    expect(managerWith().getPublicConfig().emailPassword.requireEmailVerification).toBe(false);
+    expect(
+      managerWith({ posture: 'invite_only' }, { requireEmailVerification: true }).getPublicConfig()
+        .emailPassword.requireEmailVerification,
+    ).toBe(true);
+  });
+});
+
 describe('#15588 — remedy (b) cannot recover an EXISTING person, and the posture is not the lever', () => {
   it('under `open` the gate ADMITS the address outright — so the posture is not what stops them', () => {
     // The message says widening "cannot recover an EXISTING person at all …
 
@@ -44,14 +44,20 @@
  *    (`audience-posture.ts`, "The invitation carve-out") is admitted under
  *    every posture in `AUDIENCE_POSTURES`. No door needs widening. ⚠️ But the
  *    carve-out is an ADMISSION verdict and NOT a verification bypass, so the
- *    third bullet below applies to the INVITED login too: only under the
- *    default `invite_only` posture is the recovery mail-transport-free, and on
- *    `open`/`email_domain` the invited login is created and then refused
- *    `EMAIL_NOT_VERIFIED` — which also SILENCES this report, the very
- *    transition the second bullet warns about, delivered by the primary
- *    remedy. The message therefore scopes the no-mail-transport rider and
- *    tells the operator to close the posture first; ⛔ never re-state that
- *    rider for EVERY posture. Pinned across the whole posture vocabulary, with
+ *    INVITED login meets the same email-verification rule as any sign-up
+ *    (`resolveEmailVerificationRequirement`, the one resolver the wiring and
+ *    `getPublicConfig()` both read): always on under `email_domain`; on under
+ *    `open` unless the DEPLOYMENT declared it off (#20389 — a `false` stored
+ *    only through the settings console is refused there); and the declared
+ *    value, off by default, under `invite_only`. Wherever it is on, the
+ *    invited login is created and then refused `EMAIL_NOT_VERIFIED` — which
+ *    also SILENCES this report, the very transition the second bullet warns
+ *    about, delivered by the primary remedy. The message therefore states that
+ *    rule once, scopes the no-mail-transport rider to the default
+ *    `invite_only` posture, and tells the operator to close the posture first;
+ *    ⛔ never re-state that rider for EVERY posture, and ⛔ never state the
+ *    forcing for every non-`invite_only` posture either — `open` honours a
+ *    deployment's opt-out. Pinned across the whole posture vocabulary, with
  *    the un-invited `invite_only` refusal as its control, and the scope itself
  *    pinned beside it.
  *  - **A hand-written credential row blinds this very check.**
@@ -474,12 +480,18 @@ export function resolveNoSignInAccountReport(
     'lowercases the address it searches for, so a mixed-case row is never found), then have that ' +
     'person register through the ordinary sign-up endpoint. The invitation carve-out admits that ' +
     'ONE creation under EVERY audience posture, so no door needs widening — but it is an ADMISSION ' +
-    "verdict, not a verification bypass: under the default 'invite_only' posture no mail transport " +
-    "is needed either, whereas an 'open' or 'email_domain' posture forces email verification on the " +
-    "INVITED login too (see (b)), so close the posture back to 'invite_only' BEFORE that person " +
-    "registers. On the 'single' tenancy posture that account holder is then promoted to platform " +
-    'admin. Afterwards, re-run the provisioning job that seeded these people so it seeds their ' +
-    'logins too. TWO THINGS THAT LOOK LIKE REMEDIES AND ARE NOT: (a) HAND-WRITING A CREDENTIAL ' +
+    'verdict, not a verification bypass: the INVITED login meets the same email-verification rule as ' +
+    "any sign-up. Under 'email_domain' verification is always ON; under 'open' it is ON unless the " +
+    'DEPLOYMENT has itself declared it off (emailAndPassword.requireEmailVerification: false, or ' +
+    'OS_AUTH_REQUIRE_EMAIL_VERIFICATION=false — a false stored only through the settings console is ' +
+    "refused there); under the default 'invite_only' posture it follows that same declaration and is " +
+    'OFF by default, so no mail transport is needed either. Wherever it is ON, the invited login is ' +
+    'refused EMAIL_NOT_VERIFIED at its first sign-in until a mail transport delivers the link, so on a ' +
+    "deployment without one, close the posture back to 'invite_only' BEFORE that person registers " +
+    "and leave verification at its default OFF. On the 'single' tenancy posture that account holder " +
+    'is then promoted to platform admin. Afterwards, re-run the provisioning job that seeded these ' +
+    'people so it seeds their logins too. TWO THINGS THAT LOOK LIKE REMEDIES AND ARE NOT: (a) ' +
+    'HAND-WRITING A CREDENTIAL ' +
     `ROW — a '${SystemObjectName.ACCOUNT}' row's 'password' column must carry a secret in the ` +
     "platform's own hash format, so a plaintext password authenticates nothing — a 401 or a 500 " +
     'depending on the row shape, never a session — and ' +
@@ -488,11 +500,10 @@ export function resolveNoSignInAccountReport(
     'OPENING THE AUDIENCE POSTURE — which cannot recover an EXISTING person at all: ' +
     'self-registration is a user-CREATION path, so it cannot hand a login to somebody whose ' +
     `'${SystemObjectName.USER}' row already exists, and NO posture changes that. Widening only ever ` +
-    "admits a NEW address — and then every posture other than 'invite_only' ('open', " +
-    "'email_domain') FORCES email verification ON unless an 'open' deployment has itself declared it " +
-    'off, so that login is refused EMAIL_NOT_VERIFIED at ' +
-    'its first sign-in until a mail transport delivers the link, and a locked-out self-hosted ' +
-    'install usually has none. Nothing here happens by itself.'
+    'admits a NEW address — and that login meets the same verification rule stated above, so wherever ' +
+    'it is ON that login is refused EMAIL_NOT_VERIFIED at its first sign-in until a mail transport ' +
+    'delivers the link, and a locked-out self-hosted install usually has none. Nothing here happens ' +
+    'by itself.'
   );
 }
 
 
@@ -27,8 +27,10 @@
  *  - So no insert is attempted and nothing is swallowed. Case ① asserts that
  *    directly by counting engine `insert` calls across the request.
  *  - And the POSTURE is not the cause: it is only what turns the shield on. A
- *    self-registration-permitting posture FORCES `requireEmailVerification`
- *    (`createAuthInstance`). Case ⓪ holds the posture CONSTANT at the
+ *    self-registration-permitting posture forces `requireEmailVerification`
+ *    on by default (`createAuthInstance` — always under `email_domain`, and
+ *    under `open` unless the deployment declared it off, #20389). Case ⓪
+ *    holds the posture CONSTANT at the
  *    `invite_only` default and moves only that flag — 422 becomes the
  *    synthetic 200 — which is what makes "before the uniqueness refusal" a
  *    measurement rather than a reading of vendor source.