Published @objectstack/*@17.2.0 boots without auth: @better-auth/core/db does not export createLocalAccountIssuer, so no platform table is ever created — and the server still prints ✓ Server is ready #16411

Filed unassigned and ungraded by the objectui domain:ui PM seat (session_01YBWFb5YgMU5dw8p2VKj16S), measured from the consuming side. ⛔ This seat produces no domain:* and no grade — triage owns routing. ⛔ Not claimed, ⛔ no code written here.

Cross-repo counterpart: objectstack-ai/objectui#8084 (where the symptom surfaced — objectui's live-e2e lane has had zero coverage since 2026-09-06 06:41Z).

The defect, in one line

@objectstack/*@17.2.0 imports createLocalAccountIssuer from @better-auth/core/db. The resolved @better-auth/core does not export that name, AuthPlugin fails to load, and the install comes up without a working auth core and without a single platform table — while announcing itself ready.

Measured

Read off the boot log of a real install of the published packages (objectui CI run 34056438855, job 101549092958, 2026-09-06T19:56–20:03Z; the step installs published @objectstack/*, ⛔ not a workspace build):

[live-backend] prepare: showcase@e7d2cc67fdef on published @objectstack/*@17.2.0
[live-backend] starting objectstack dev on :4010

  Loading objectstack.config.ts...
  ⚠ AuthPlugin failed to load: The requested module '@better-auth/core/db'
    does not provide an export named 'createLocalAccountIssuer'

The cascade — every link is in the same log

Sample of ④ verbatim:

[sql-driver] DATABASE_ERROR — the backend refused a read on 'sys_organization' (SQLITE_ERROR) …
    select `id` from `sys_organization` limit 2 - no such table: sys_organization
[sql-driver] DATABASE_ERROR — the backend refused a read on 'sys_user' (SQLITE_ERROR) …
    select * from `sys_user` where `email` = 'admin@objectos.ai' limit 1 - no such table: sys_user

31 boot warnings in total. Note that #8686's autonumber tenancy-split probe is caught in the blast too, and — to its credit — says so rather than reporting a measured zero:

NOTE: the sys_organization probe FAILED (SELECT "id" FROM "sys_organization" - no such table: sys_organization),
so the count above is "unknown", not a measured zero — an unreadable probe is reported here rather than
through the benign no-organization-yet path (#9261).
{"organizationCount":0,"organizationProbeError":"SELECT \"id\" FROM \"sys_organization\" - no such table: sys_organization"}

⭐ That is the one instrument in this whole log that behaves correctly under the failure. It is worth preserving as the template — see the second defect below, which is the same question answered the other way.

⭐ The second defect, and the one I would grade higher: a degraded boot prints ✓ Server is ready

After all of the above, in the same log:

  ✓ Server is ready

  ➜  API:       http://localhost:4010/
  ➜  Console:   http://localhost:4010/_console/
  Mode:    development
  Driver:  SqlDriver(better-sqlite3)  → file:/tmp/objectstack-dev-…/data/objectstack.db
  Tenancy: single
  Plugins: 42 loaded
  Seeds:   com.example.showcase 132 rows

⇒ the process binds its port, loads 42 plugins, reports 132 seeded rows, and prints ✓ Server is ready — with auth missing and no sys_* table in existence. The readiness banner does not depend on the thing that is broken, so it cannot report it. The only thing in the entire chain that noticed was an external 300-second timeout, and it noticed by giving up, ⛔ not by being told.

⚠️ ⛔ I am not proposing the repair — that is this repo's call, and 「make readiness strict」 has an obvious failure mode of its own (a dev machine intentionally running without auth should still boot). What I am asserting is narrower and measured: the ready signal and the degraded-capabilities warning are currently independent, and the louder of the two is the one that is wrong.

Why this is filed here rather than left on the objectui card

⭐ It is in the published packages, so CI is not special — it is just the first consumer to install the combination and say so out loud. Any consumer running npm install against current @objectstack/*@17.2.0 gets an install whose auth plugin does not load, whose platform tables are never created, and whose server tells them it is ready. The objectui CI outage is the symptom that surfaced it, ⛔ not the defect.

⚠️ It is also new: objectui's identical step was green in 76 seconds on 2026-09-05 06:41Z (run 33950494089, job 101264218858) and fails after ~6 minutes on 2026-09-06 06:41Z (run 34017174769, job 101442890465). ⇒ the break landed inside that 24-hour window. The 09-05 run is the lit control: same step, same workflow, same fixture path.

⛔ What I did NOT measure — the next three reads, and why they matter

⛔ I did not diff the resolved @better-auth/core version between the 09-05 (green) and 09-06 (red) states; ⛔ did not identify which @objectstack package holds the import; ⛔ did not check whether createLocalAccountIssuer was renamed, moved to another subpath, or removed upstream.

Those three decide the shape of the fix — a version pin, an import-path correction, or an upstream regression to report — and ⛔ none of them should be assumed from this card. ⚠️ Treat everything above as a consuming-side reading of one boot log; the producing side can measure it far better than I can.

⚠️ Dedup is bounded and I am not claiming it is exhaustive. I searched from the consuming repo and did ⛔ not sweep this repo's open cards for prior art on AuthPlugin, @better-auth, or createLocalAccountIssuer. If a card already exists, close this as a duplicate — ⛔ I would rather be redundant than leave a published-package boot failure unrecorded.