fix(service-settings): audience help and the identity-auth checklist state the email-verification rule as shipped

[objectstack-fleet]

Part of #20413 — the settings console text (4 locales) and the identity-auth checklist. The plugin-auth boot-diagnostic location of the same stale statement follows in a second round on the card (seat append below).

Clause-②: no

What changed

The auth settings console and the identity-auth platform checklist both said every audience posture other than invite_only forces email verification on. Commit 65352b7d changed that rule. Each location now states the rule the code enforces.

The rule, re-derived from packages/plugins/plugin-auth/src at base 40b315b0:

• email_domain always forces verification on (resolveEmailVerificationRequirement, audience-posture.ts). An explicit false is refused at entry from any source (assertAudienceConfig).
• open forces it on unless the deployment declares an explicit false, in either of two ways:
  • emailAndPassword.requireEmailVerification: false in the stack config;
  • OS_AUTH_REQUIRE_EMAIL_VERIFICATION=false. bindAuthSettings in auth-plugin.ts treats an env-sourced value as the deployment's own declaration.
• Under open, a false stored through the settings console is refused. This is the verificationDeclaredBy: 'console' branch of assertAudienceConfig, and it plays out two ways:
  • Posture and false saved in one pass: the posture change is refused.
  • false saved while open already stands: the stored false is refused.
  • In both cases the standing config keeps ruling.
• invite_only uses whatever value is declared, and defaults to off.

The code agrees with the card's statement of the rule.

Landing points (strings re-located on this tree by key and by each locale's wording)

File	Keys	Hits by key / by wording
service-settings/src/manifests/auth.manifest.ts	audience group description; audience_posture description	2 / 2
service-settings/src/translations/en.ts	groups.audience.description; keys.audience_posture.help	2 / 2
service-settings/src/translations/zh-CN.ts	same keys	2 / 2
service-settings/src/translations/es-ES.ts	same keys	2 / 2
service-settings/src/translations/ja-JP.ts	same keys	2 / 2
docs/qa/platform-checklist/areas/identity-auth.json	two items, below

The card calls the posture string help. In the manifest it is actually the specifier's description; only the bundles call it help.

A repo-wide search for each locale's wording found these files and nothing else that repeats the old rule, with one exception listed under Acceptance notes. Three other hits already state the new rule:

• the spec describe;
• the generated reference page;
• content/docs/deployment/self-hosting.mdx.

No *.generated.ts bundle holds these strings.

"No env knob" was measured, and it is false

The checklist said the audience is config-only, with no env knob. In fact, the settings service derives an OS_AUTH_* override for every auth manifest key (envKeyOf, settings-service.types.ts). So the three audience keys have these overrides:

• OS_AUTH_AUDIENCE_POSTURE
• OS_AUTH_AUDIENCE_ALLOWED_EMAIL_DOMAINS
• OS_AUTH_AUDIENCE_SELF_REGISTRATION_PERMISSION_SET

Probe. A one-off probe, not committed, ran the real SettingsService with the shipped authSettingsManifest, set the env as shown, and called getNamespace('auth'):

control, no env:      audience_posture = "invite_only"  source=default locked=false
open + set + off:     audience_posture = "open"         source=env locked=true
                      audience_self_registration_permission_set = "member_default" source=env locked=true
                      require_email_verification = false source=env locked=true
email_domain + list:  audience_posture = "email_domain" source=env locked=true
                      audience_allowed_email_domains = "acme.com" source=env locked=true
off-vocabulary value: audience_posture = "invite_only"  source=default (override logged as IGNORED)

The plugin-auth half is already pinned. In audience-posture-setting.test.ts, the case "open with the OS_AUTH_REQUIRE_EMAIL_VERIFICATION env override OFF is honoured" drives bindAuthSettings with env-sourced audience keys and asserts posture open.

Composition. settings is in the always-on capability slate for every serve preset except minimal.

Not measured: a live stock boot with those variables set. The checklist text says this.

Checklist: two items, beyond the two quoted sentences

The card quotes two knownGaps sentences. The same file states the same old rule in seven more fields across two items. These are fixed here as a bounded in-place fix, which all four conditions allow:

1. It is the same defect class.
2. The edit is mechanical, and the rule above fixes its form.
3. The file is on this claim's declared surface.
4. It is the same gate, check:platform-checklist.

Left alone, those fields would contradict the rewritten gaps.

• identity-auth.self-signup-gate, revision 1 to 2:
  • knownGaps[0] now names both doors: stack config, and the settings namespace through the console or env. It says the env door is measured in halves, not yet end to end.
  • knownGaps[1] (the BOUNDARY note).
  • variants[2].
  • source[2].
• identity-auth.email-verification-loop, revision 1 to 2:
  • fixtures.requires[0].
  • acceptance[5].
  • negative[2]. As written, it would have scored an open boot with the deployment opt-out as a FAIL. That boot correctly advertises false.
  • source[0] and source[1].

Each item gets a new history entry with ref #20413. The earlier entries keep their text. I searched the file for nine old-rule phrases, such as config-only, no env knob and permitting-posture boot advertising. On base 40b315b0 they occur 11 times; at head they occur 0 times outside the two new history entries.

Verification

Every run below is at head a22b90fc.

Build. pnpm --filter '@objectstack/service-settings^...' build finished with VERDICT command-exit 0, then the package itself was built.

Tests. pnpm --filter @objectstack/service-settings exec vitest run --maxWorkers=2: Test Files 33 passed (33), Tests 584 passed (584). This includes:

• settings-translation-coverage.test.ts, which checks that zh-CN, ja-JP and es-ES cover settings.auth;
• auth.manifest.test.ts.

Typecheck. pnpm --filter @objectstack/service-settings run typecheck (tsc --noEmit) exits 0.

Derived gates. node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands derived 57 commands, and all 57 were run. Reconciled with --ran and exit codes: 57 derived, 56 run, 1 NOT-MEASURED.

• NOT MEASURED: pnpm check:dual-build-cjs-loads. It exited 3 (PREREQUISITE NOT MET) because it needs every package's dist/. Declared narrowing: I applied the gate's two properties to the one package the diff touches.
  • node --check dist/index.cjs exits 0.
  • require('./dist/index.cjs') loads (46 exports, new text present).
  • The diff only changes string literals.
• check-plugin-teardown-shape.mjs --self-test first exited 3, because its pinned fixture commit was outside the shallow clone. After I fetched that one commit at depth 1, it passed 48 cases.
• pnpm check:platform-checklist: OK, 15 areas, 266 items.
• pnpm check:nul-bytes: OK.

Roster gates. The derivation said the rosters of three gates live under packages/, so their silence is not evidence either way. I ran them anyway, and all three exit 0: check:authz-resolver, check:error-code-casing, check:filter-alias-parity.

Translation gates. No gate script reads these translation files. A search of scripts/ and .github/ for service-settings/src/translations and settingsBuiltinTranslations finds 0 hits. As a control, the same search surface does find service-automation. The only gate on these files is the package's coverage test above.

Acceptance notes

• Stale boot report text. packages/plugins/plugin-auth/src/boot-sign-in-reachability.ts line 478 still says an open or email_domain posture "forces email verification on the INVITED login too". Line 492 of the same message already names the open opt-out. plugin-auth source is outside this claim, so this goes to the PM as a finding. The phrase is pinned in boot-sign-in-reachability.test.ts.
• Stale comment. A comment in auth-manager.ts, near line 2295, still says a self-registration posture forces verification on. It is a comment only.

Changeset

.changeset/20413-verification-posture-statements.md: @objectstack/service-settings patch, because the strings ship in that package. The docs/qa file is not published.

Seat append (domain:services seat #6021, session_017B6YKCGu8CTY2KBWgwaHAs)

• The first line changed from a closing keyword to Part of #20413. The dev's report 5867903998 found one more location of the same stale statement, outside this PR's claim surface: the no_sign_in_account_at_boot remedy prose in packages/plugins/plugin-auth/src/boot-sign-in-reachability.ts, pinned by its test. By the family rule it joins Stale "every non-invite_only posture forces email verification" statements after #20389: settings console text (4 locales) and the identity-auth platform checklist #20413 as a second round instead of a new card, so this PR no longer closes the card.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 1 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• 2 name(s) were too generic to anchor anything (single lowercase words)
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 50e273fd7e933433182d6d89e3968d1af4be7b94 → packageMentionDocs.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: a22b90fc02b893cc742d03284bd132380dd83ff9
Local-runs: none

Inputs read: card #20413 (body + all 4 comments: unlock 5866972701, claim 5867222316, os-dev-report 5867903998, seat ACCEPT 5867962277), PR #20421 (body, 7-file list, net diff vs main at 50e273fd), the head's check-runs (three readings, last at 2026-09-28T10:22:47Z), and the enforcing code on origin/main (packages/plugins/plugin-auth/src/audience-posture.ts, auth-plugin.ts bindAuthSettings, auth-manager.ts applyConfigPatch, audience-posture-setting.test.ts; packages/services/service-settings/src/settings-service.ts and settings-service.types.ts envKeyOf; packages/spec/src/system/auth-config.zod.ts). The review ref refs/review/pr-20421 resolves to the head sha exactly. Nothing was built, run or re-run.

① Derived judgments

The diff is 7 files, +40/−23, string literals and JSON prose only. Every accept-set and public-surface implication, each judged:

1. auth.manifest.ts — audience group description and the audience_posture specifier description (the manifest carries the posture string as description; the bundles carry it as help — the card's help naming was wrong, the dev's correction is RIGHT, verified at head lines 92 and 106). Keys, options table, defaults, type, namespace: 'auth' all unchanged, so the accept set of the settings console and of every OS_AUTH_* override derived from these keys does not move. Right: text-only, no accept-set change.
2. The four locale bundles (en, zh-CN, es-ES, ja-JP), keys groups.audience.description and keys.audience_posture.help — same two keys in each, no key added or dropped, so the coverage invariant (settings-translation-coverage.test.ts) is undisturbed; en strings are byte-identical to the manifest's. The zh-CN, es-ES and ja-JP wordings each state the three clauses below faithfully (I read all three). Right.
3. Accuracy of the rule as now stated, measured against origin/main:
   • "email_domain always forces email verification on" — resolveEmailVerificationRequirement returns true for email_domain; assertAudienceConfig refuses an explicit false under email_domain regardless of declarant (pinned by "email_domain with the env override OFF is still refused"). Right.
   • "open forces it on unless the deployment turns it off (OS_AUTH_REQUIRE_EMAIL_VERIFICATION=false, or emailAndPassword.requireEmailVerification: false in the stack config)" — declared !== false for open; the constructor passes verificationDeclaredBy: 'deployment' (auth-manager.ts:1392); bindAuthSettings maps sources.require_email_verification === 'env' to 'deployment' (auth-plugin.ts:1706-1707); pinned by "open with the OS_AUTH_REQUIRE_EMAIL_VERIFICATION env override OFF is honoured". Right.
   • "a false saved in this console is refused under open" / "a value saved in this console cannot" — the 'console' branch of assertAudienceConfig; applyConfigPatch carries requireEmailVerificationFrom: 'console' for any non-env explicit source and re-judges the merged result whenever audience or emailAndPassword is in the patch (auth-manager.ts:4208-4222). Both orderings end refused with the standing config ruling. Right.
   • "Both email_domain and open require the self-registration permission set below" — audiencePermitsSelfRegistration branch of assertAudienceConfig. Right.
4. docs/qa/platform-checklist/areas/identity-auth.json — unpublished; two items (self-signup-gate, email-verification-loop) revision 1 to 2, each with a new history entry whose revision equals the item's (the validator's rule at scripts/check-platform-checklist.mjs:2741-2751); symbol anchors in source unchanged, only their parentheticals. Nine fields restated. The "audience is config-only, no env knob" claim the card marked unverified by the PM is now measured false by me as well: envKeyOf('auth','audience_posture') yields OS_AUTH_AUDIENCE_POSTURE for every manifest key; the settings service resolves an env value as source: 'env', locked: true (settings-service.ts:1229-1233) and rejects an off-options value as IGNORED (:1128); bindAuthSettings reads audience_posture etc. by explicitness, and audience-posture-setting.test.ts:257 drives env-sourced audience keys through it. The checklist says the live stock boot with those variables is not measured — honest. My grep of the head file finds 0 old-rule phrases outside the two new history entries; base held them in 11 places. Right.
5. No other public surface moves. Repo-wide grep on origin/main for the five old strings hits only the 5 touched source files (no *.generated.ts, no reference page copy); the spec posture describe, content/docs/references/system/auth-config.mdx and content/docs/deployment/self-hosting.mdx:580 already state the shipped rule. No packages/spec, no plugin-auth source, no content/docs/releases/, no governed surface (docs/qa/** is not on the Prime Directive feat: Comprehensive CRM example demonstrating all ObjectStack protocol features #14 register). Right.

② Semver level

The declaration is Clause-②: no.

.changeset/20413-verification-posture-statements.md: "@objectstack/service-settings": patch, Clause-②: no on its own line, no arm. Right. The package publishes (publishConfig present, no private), and the diff changes strings that ship in its bundle, so skip-changeset would be wrong; nothing in the accept set widens or narrows and no export, key, option or default moves, so minor is not owed and no is the correct declaration. The changeset body carries no migration (none is owed), no ADR-0087 marker (not breaking), no model identifier, and its (#20413) title suffix follows the repo's existing changeset convention. docs/qa carries no changeset — right, it is not published. Check Changeset on the head: success.

③ Boundary flags

• open_questions: empty — recorded; none to answer.
• Deviation: checklist scope beyond the two quoted knownGaps sentences (7 more fields, 2 items). Judged right: same file on the declared claim surface, same defect (the pre-feat(plugin-auth): the open audience posture honours a deployment's email-verification opt-out (#20389) #20406 rule), a mechanical restatement fixed in form by the shipped rule, same gate (check:platform-checklist); leaving them would have left the file self-contradicting. The seat's ACCEPT (5867962277 item 3) amended the claim surface accordingly. Verified by diff and by grep of base vs head.
• Deviation: card said help, manifest carries description. Verified at head; card wording corrected, no action owed.
• Deviation: check:dual-build-cjs-loads NOT-MEASURED with declared narrowing. Acceptable: the diff is string literals; Build Core on the head is success and stands as the build verdict.
• Deviation: one pinned fixture commit fetched at depth 1 for a checker self-test. Additive object-store fetch, no ref moved; no concern.
• Deviation: commit trailers use the AGENTS.md model-free pair. Verified on all three branch commits (d3eb775e, 380efb09, a22b90fc): Claude-Session + Co-authored-by: Claude, no model identifier anywhere in commits, changeset, PR title or body. Right per AGENTS.md.
• Out-of-scope (b): boot-sign-in-reachability.ts remedy prose. Verified on origin/main lines 478-479 ("forces email verification on the INVITED login too") against 492-493 of the same message ("unless an 'open' deployment has itself declared it off") — the message contradicts itself, is shipped runtime text, and is outside this claim's surface. The seat merged it into Stale "every non-invite_only posture forces email verification" statements after #20389: settings console text (4 locales) and the identity-auth platform checklist #20413 as round 2 (5867962277 item 6). Escalated correctly; no action on this PR.
• Out-of-scope: auth-manager.ts comment near line 2295. Verified stale ("a posture that permits self-registration FORCES requireEmailVerification on"); comment only; rides round 2. Right.
• PR closes nothing. First line Part of #20413 (seat's edit), no closing keyword elsewhere; Part-of PR must not also close its card and The card this PR closes must claim this branch both success. Round 2 is owed before the card closes.
• Observation, not a defect in this diff (plugin-auth behaviour landed by feat(plugin-auth): the open audience posture honours a deployment's email-verification opt-out (#20389) #20406, outside this claim): when posture open already stands and the console then stores require_email_verification: false, the refusal is thrown from the MAIN settings patch and lands in the outer catch at warn ("Auth: failed to apply auth settings: …"), dropping the pass's sibling auth settings — the test file's own comment names this shape. The new text's word "refused" is accurate either way; the seat may fold the log-level/sibling-drop question into round 2 or leave it.
• Check-runs on a22b90fc at 2026-09-28T10:22:47Z: 34 distinct checks — 28 success, 5 skipped, 0 failure; Lint & Repo Gates (a required context) was still in_progress at my last reading. All six other required contexts (TypeScript Type Check, Test Core and its 6 shards, Dogfood Regression Gate and its 3 shards, Build Core, Temporal Conformance (live PG + MySQL), Governed Surface Queue Guard) are success. This is an honest reading of the gate, not a verdict on it: readiness waits for that one context to conclude green.

Implemented-by: claude/issue-20413-verification-posture-statements
Reviewed-by: session_017B6YKCGu8CTY2KBWgwaHAs

VERDICT: PASS

_{Rendered by an isolated contract-review subagent and adopted by the domain:services seat (#6021, session_017B6YKCGu8CTY2KBWgwaHAs) at 2026-09-28T10:24Z after a transcript check: 70 harness model stamps, all at CONTRACT_REVIEW_TIER, zero fallbacks; 39 Bash calls, zero write calls. Seat note on the last observation: that refusal-drops-siblings shape is exactly #20412's scope (in flight, auth-plugin.ts), not round 2's.}

---

Generated by Claude Code