You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The generated auth-plus-account scaffold must consume the corrected companion candidate from better-auth-ui#22, not @btst/better-auth-ui@2.0.0-rc.3 on Better Auth 1.7.2.
The scaffold and manual-install path must select the exact Better Auth 1.6.16 cohort recorded by #244 and tested by #174 while leaving @btst/db@2.2.3 and the 2.2.3 adapters unchanged. It must configure transaction: true explicitly when generated plugin choices require atomic writes; it still must not generate or own the Better Auth backend or database schema.
The completed better-auth-ui#20 remains the source of the bridge, route, session, and override design. Better-auth-ui#22 changes the supported v3 dependency cohort and publishes the immutable corrected candidate.
This was generated by AI during triage.
Current status — 2026-08-31
Both implementation dependencies are satisfied: core #202 is complete, and better-auth-ui#20 shipped through PR #21. RC3 was deliberately published without restoring this optional scaffold.
This issue is now a stable-v3 integration gate, not an RC3 publication blocker. Its product boundary is unchanged:
optional auth-plus-account generation only;
one browser Better Auth client pointed at an existing endpoint;
no generated Better Auth backend, database, schema, providers, migrations, or secrets;
organization and other features remain explicit opt-ins;
resolved site routes, inferred overrides, and explicit framework-native session refresh; and
packed Next.js, React Router, and TanStack consumer builds.
Use the newest candidate artifacts available when implementing the fixtures. #170 closes only after this scaffold/docs path proves the exact public override contract, and #174 may reuse these fixtures for its npm/pnpm packed-install coverage. Historical references below to “packed RC3 artifacts” should be read as the current release-candidate artifacts.
Restore @btst/better-auth-ui as an officially maintained, optional companion in the BTST CLI catalog and documentation after better-stack-ai/better-auth-ui#20 has migrated the package to the final runtime produced by #202.
The generated integration must be deliberately small. Selecting Better Auth UI installs and registers the companion's auth and account client plugins, creates only the browser Better Auth client needed by those plugins, and points the application at an existing Better Auth endpoint. It must not generate, own, or configure a Better Auth backend, database adapter, schema, migrations, authentication providers, secrets, or environment-specific production infrastructure.
This restores the first-class integration removed during the RC2-to-RC3 cleanup without coupling @btst/stack core to Better Auth. Better Auth remains an application prerequisite and @btst/better-auth-ui remains a separately maintained companion repository.
Intended generated boundary
The exact syntax must follow the API that lands in #202, but the generated result must preserve this ownership:
The CLI may adapt names and framework helpers to the final #202 surface. It must not reintroduce duplicated API/site/query configuration, a hand-written provider override map, Better Auth-to-BTST identity factories, or Better Auth permission translation.
Required behavior
Better Auth UI appears as an optional CLI/catalog choice; it is not forced into applications that do not select it.
The default generated plugin set is auth plus account only.
Organization, API-key, passkey, multi-session, and other Better Auth extensions are opt-in because they require matching Better Auth server/client plugins.
The scaffold creates a minimal Better Auth browser client module and connects it to the auth override once.
The scaffold assumes an existing Better Auth API endpoint. It does not generate the server, database, schema, migrations, environment variables, providers, or secrets.
Better Auth UI manages its own session and native permissions. BTST authorization remains optional, provider-agnostic, and application-owned.
Framework-native session synchronization is explicit: Next.js refresh, React Router revalidation, or TanStack Router invalidation. The generated bridge performs no hidden BTST identity refetch.
Account avatar customization, when documented, appears only at account.avatar.
Documentation identifies the companion repository, its release line, Better Auth prerequisite, supported dependency cohort, and optional-adapter peer requirements.
Installation and release-gate fixtures
Add generated clean-install fixtures for all three supported frameworks:
Next.js;
React Router;
TanStack Router/Start, using the repository's supported generated target.
Each fixture must be generated from the maintained CLI/template path, install the packed current candidate artifacts rather than workspace links, and use the exact retained Better Auth 1.6.16 compatibility contract from #174. Exercise both npm and pnpm across the release gate; the division of the package-manager matrix between this issue and #174 may be shared, but the combined gate must cover every generated framework with a clean install and production build.
The fixtures need only prove integration, declarations, routing, bundling, and production builds. They do not need a live Better Auth database or real sign-in flow; post-publication real-project validation is tracked separately and does not block RC3.
better-stack-ai/better-auth-ui#20 remains the completed bridge/API baseline, and the scaffold consumes the corrected cohort candidate from better-stack-ai/better-auth-ui#22.
Better Auth UI is restored to the optional CLI/catalog selection and relevant registry/catalog artifacts are reproducible.
The default scaffold registers only auth and account.
The generated code creates only a Better Auth browser client and clearly marks the existing Better Auth endpoint seam.
No Better Auth server, database adapter, schema, migration, provider, secrets, or generic BTST auth adapter is generated or owned by core.
Organization and other Better Auth extensions are documented and generated only when explicitly selected/configured.
Real-project validation in Better Stack Web and Bio Mogging starts only after the coordinated RC3 packages are public and does not block this issue or RC3 publication.
Stable-v3 cohort correction — 2026-08-31
The generated auth-plus-account scaffold must consume the corrected companion candidate from better-auth-ui#22, not
@btst/better-auth-ui@2.0.0-rc.3on Better Auth 1.7.2.The scaffold and manual-install path must select the exact Better Auth 1.6.16 cohort recorded by #244 and tested by #174 while leaving
@btst/db@2.2.3and the2.2.3adapters unchanged. It must configuretransaction: trueexplicitly when generated plugin choices require atomic writes; it still must not generate or own the Better Auth backend or database schema.The completed better-auth-ui#20 remains the source of the bridge, route, session, and override design. Better-auth-ui#22 changes the supported v3 dependency cohort and publishes the immutable corrected candidate.
Current status — 2026-08-31
Both implementation dependencies are satisfied: core #202 is complete, and better-auth-ui#20 shipped through PR #21. RC3 was deliberately published without restoring this optional scaffold.
This issue is now a stable-v3 integration gate, not an RC3 publication blocker. Its product boundary is unchanged:
Use the newest candidate artifacts available when implementing the fixtures. #170 closes only after this scaffold/docs path proves the exact public override contract, and #174 may reuse these fixtures for its npm/pnpm packed-install coverage. Historical references below to “packed RC3 artifacts” should be read as the current release-candidate artifacts.
Parent
What to build
Restore
@btst/better-auth-uias an officially maintained, optional companion in the BTST CLI catalog and documentation afterbetter-stack-ai/better-auth-ui#20has migrated the package to the final runtime produced by #202.The generated integration must be deliberately small. Selecting Better Auth UI installs and registers the companion's auth and account client plugins, creates only the browser Better Auth client needed by those plugins, and points the application at an existing Better Auth endpoint. It must not generate, own, or configure a Better Auth backend, database adapter, schema, migrations, authentication providers, secrets, or environment-specific production infrastructure.
This restores the first-class integration removed during the RC2-to-RC3 cleanup without coupling
@btst/stackcore to Better Auth. Better Auth remains an application prerequisite and@btst/better-auth-uiremains a separately maintained companion repository.Intended generated boundary
The exact syntax must follow the API that lands in #202, but the generated result must preserve this ownership:
The CLI may adapt names and framework helpers to the final #202 surface. It must not reintroduce duplicated API/site/query configuration, a hand-written provider override map, Better Auth-to-BTST identity factories, or Better Auth permission translation.
Required behavior
account.avatar.Installation and release-gate fixtures
Add generated clean-install fixtures for all three supported frameworks:
Each fixture must be generated from the maintained CLI/template path, install the packed current candidate artifacts rather than workspace links, and use the exact retained Better Auth 1.6.16 compatibility contract from #174. Exercise both npm and pnpm across the release gate; the division of the package-manager matrix between this issue and #174 may be shared, but the combined gate must cover every generated framework with a clean install and production build.
The fixtures need only prove integration, declarations, routing, bundling, and production builds. They do not need a live Better Auth database or real sign-in flow; post-publication real-project validation is tracked separately and does not block RC3.
Acceptance criteria
better-stack-ai/better-auth-ui#20remains the completed bridge/API baseline, and the scaffold consumes the corrected cohort candidate frombetter-stack-ai/better-auth-ui#22.Out of scope
@btst/stackcore.Blocked by
better-stack-ai/better-auth-ui#20— completed migrated companion bridge and exact override contracts.better-stack-ai/better-auth-ui#22— corrected companion candidate aligned to the retained Better Auth 1.6.16 database cohort.Real-project validation in Better Stack Web and Bio Mogging starts only after the coordinated RC3 packages are public and does not block this issue or RC3 publication.