@riffdb/better-auth 0.2.0 → 0.2.1

package/DESIGN.md

@@ -7,7 +7,7 @@ generation, adapter method mapping, and Better Auth conformance tests. RiffDB
 owns database semantics, compiled operations, authorization, durability,
 idempotency, and the Rust-backed TypeScript transport.
 
-## Better Auth 1.6.29 method inventory
+## Better Auth 1.7.18 method inventory
 
 The adapter project must cover the current `createAdapterFactory` interface:
 
@@ -34,13 +34,22 @@ matching, independent order, and nullable order are declared in the compiled
 query. The result page and total therefore share one provider epoch; the
 adapter neither drains pages nor recounts client-side.
 
-`consumeOne` maps to one atomic delete-and-return compiled command. The same
-command executes immediately when Better Auth invokes `consumeOne` inside its
-verification cleanup callback, so two racers cannot both observe a token and
-the loser receives `null`. Any remaining identifier-scoped verification rows
-are removed afterward by the bounded compiled set command. Signup and OAuth
-transactions remain single-command atomic graphs; unknown callback shapes fail
-closed.
+`consumeOne` maps to one atomic delete-and-return compiled command. In a
+recognized Better Auth verification transaction, the adapter records a bounded
+candidate and its internal revision, then commits `ConsumeVerificationSnapshot`.
+The database validates that revision while deleting; a losing delete racer
+returns `null`, and a changed snapshot fails explicitly. Remaining identifier-
+scoped rows use the separate bounded cleanup command.
+
+Better Auth 1.7.18 wraps password reset in a larger transaction. For the
+supported existing-credential graph, `ResetCredentialPassword` consumes the
+recorded verification row and revision-guards the credential password write
+in one compiled command. A stale or missing account leaves the token and
+password unchanged. Basic password changes use the native
+`UpdateCredentialPassword` command with its current credential selector.
+Additional verification rows, credential-account creation,
+and session-revoking reset graphs are unsupported. Signup and OAuth creation
+also remain single-command graphs; unknown callback shapes fail closed.
 
 Mutable core records carry internal monotonically increasing revisions. The
 adapter reads that compiler-owned revision, sends it to an exact update
@@ -92,7 +101,7 @@ tests. This separation makes the profile customizable without turning schema
 generation into a generic database or weakening the application-facing safety
 boundary. The generation adapter rejects every runtime method.
 
-## Materialization
+## Planning materialization
 
 `materializeRiffDBBetterAuthProfile` turns a reviewed plan into the first two
 of those artifacts: one contract and one named query per accepted call shape,
@@ -133,7 +142,7 @@ needs one of them enforced changes the aggregate assignment by hand.
 representative plan, regenerated by `npm run profiles:materialize` and verified
 byte-for-byte by `npm run profiles:check`. It ships its own `riffdb.toml`, so
 the claim made about it is checkable directly: `riffdb application check` in
-that directory compiles the contract and all nineteen queries.
+that directory compiles the contract and all twenty queries.
 
 References:
 
@@ -143,7 +152,73 @@ References:
 - <https://github.com/yultyyev/better-auth-firestore>
 - <https://github.com/datar-platform/better-auth-dynamodb>
 
-## First-profile exclusions
+## Executable runtime profiles
+
+`materializeRiffDBBetterAuthRuntimeProfile` extends the reviewed core sources
+with a finite operation catalogue and emits `profile.ts`. After source review,
+`riffdb application lock --write` generates its named client and exact immutable
+identity. The adapter accepts that bound module, compares its schema plan with
+the resolved Better Auth schema, and instantiates the generated client. It never
+accepts a JSON schema as executable storage or a caller-supplied CRUD callback.
+
+The runtime generator currently accepts scalar custom user fields and the
+reviewed default organization and two-factor schemas. Baseline fields,
+references, requiredness, and secret classification cannot be overridden.
+Organization teams, dynamic access control, and mutation hooks are rejected.
+Additional plugins and call shapes need a reviewed compiler implementation.
+`nextCookies` is a reviewed integration plugin and adds no storage schema; its
+ID is excluded from storage plans while runtime validation checks its version.
+
+The sample applications live in `profiles/custom-fields/` and `profiles/runtime/`.
+They have separate locks and generated clients. Source freshness, compilation,
+package contents, and official real-service authentication conformance are
+checked for all advertised profiles. The custom-field profile runs the official
+additional-fields test against a contract already carrying that field.
+
+Runtime profiles place all entities under one tenant aggregate. This intentionally
+serializes same-tenant commands and lets member and invitation rows retain both
+user and organization references. Compiled reads hydrate related rows through
+bounded dependent batches in the same snapshot; the adapter only associates
+those returned identities. It enables native joins for these profiles and
+rejects unmatched joins before querying, rather than invoking factory fallback
+join queries.
+
+The current compiler refuses a command binding two entities carrying cascade
+policies, even when they are read parents. Therefore the organization profile
+omits user deletion and rejects `user.deleteUser.enabled`; organization deletion
+cascades both memberships and invitations atomically. This is a limitation of
+this layout and compiler surface, not permission to remove either reference.
+The core and custom-field profiles retain their compiled user cascade.
+
+Organization capacity is authoritative: member and invitation creation mutate
+the organization's internal counters with a guard below 100, and individual
+deletions release capacity atomically. The organization delete graph has at most
+201 rows. Membership creation plus session activation during invitation
+acceptance is another single compiled graph. Invitation status guards admit
+one racer; upstream Better Auth owns its higher-level acceptance and compensation
+flow around that graph.
+
+Native 2FA commands increment failure counters, set locks under a threshold
+guard, reset expired locks, and replace backup codes under an exact old-value
+guard. An internal millisecond field tracks the optional lock timestamp in the
+same commands, so the expiry comparison stays a native scalar predicate. Every
+secret result leaf has an explicit `reveals` declaration. No counter or backup-
+code path invokes Better Auth's generic mutation fallback.
+
+Profile changes require explicit data migration review. The shared tenant
+aggregate and plugin fields cannot reinterpret an installed core profile.
+Internal revisions, capacity counters, required fields, reference targets, and
+secret authority must be initialized and verified before adopting a new lock.
+No automatic migration or mixed-profile runtime is supplied.
+
+The broader planning materializer still supports schema exploration for teams.
+Better Auth 1.7's optional unique `teamMember.membershipKey` needs an explicit
+`requireUniqueValues` review: RiffDB cannot enforce a nullable unique field.
+The planning fixture requires a non-null key on every row and reports that
+stronger storage requirement. It cannot accept legacy null-key rows and is not
+an advertised runtime profile.
+
+## Default core profile exclusions
 
 - renamed models or fields;
 - additional user/session fields;
@@ -154,11 +229,14 @@ References:
 - Better Auth database hooks that imply additional database mutations; and
 - secondary storage implemented by RiffDB.
 
+These exclusions describe the default core profile; the executable profiles
+above provide reviewed extensions. Each addition needs an explicit bounded contract and semantic tests.
+
 ## Closed RiffDB blockers
 
 The loopback conformance run deploys the exact contract and role and connects
 through `riffdb-driverd`. The initial empty `FindUserByEmail` result carries the
-valid application head `0`; `@riffdb/client@0.2.0` preserves it
+valid application head `0`; `@riffdb/client@0.2.1` preserves it
 as `0n`. The adapter does not issue an unrelated warmup write, so the first
 application-visible mutation remains the compiled signup graph.
 
@@ -181,8 +259,6 @@ independent ordering, and explicit null placement. The generated TypeScript
 client also emits only reachable compact decoders, so it compiles under strict
 consumer `noUnusedLocals` settings without generated-source suppressions.
 
-These exclusions describe the first profile, not permanent product limits.
-Each addition needs an explicit bounded contract and semantic tests.
 
 ## Secrets and authority
 

package/README.md

@@ -2,13 +2,16 @@
 
 An external Better Auth database adapter for RiffDB.
 
-Status: v0.2.0. The core runtime profile is implemented and
-passes Better Auth's pinned authentication-flow suite plus a real RiffDB
-loopback suite. Profile planning is implemented for custom fields and plugins,
-and a reviewed plan now materializes into a RiffDB contract, named queries, and
-application source that compile. Binding a materialized profile to a running
-adapter instance is not implemented: the adapter still dispatches only to the
-core profile's generated client.
+Status: core and compiled runtime profiles are implemented for Better Auth
+`1.7.18`. The default core profile, a custom-field profile, and an organization
+plus 2FA profile run through Better Auth's official authentication-flow suite
+against a real TLS loopback RiffDB service. The custom-field profile also runs
+the official additional-fields test.
+
+`nextCookies()` is supported with each profile. Organizations and 2FA require
+an explicitly selected, deployed compiled profile. Teams and dynamic access
+control remain unsupported. The organization profile also rejects user deletion;
+its stored member and invitation references remain enforced.
 
 ## Architecture boundary
 
@@ -18,19 +21,20 @@ reviewed compiled profile. It does not expose generic CRUD, accept arbitrary
 transaction callbacks, perform client-side authorization filtering, or
 silently fall back for unknown models, fields, joins, predicates, or plugins.
 
-The shipped runtime profile is deliberately exact:
+The default core runtime profile is deliberately exact:
 
-- Better Auth `1.6.29`;
+- Better Auth `1.7.18`;
 - the four default core models and their default field names;
 - UUID identifiers for every model;
-- no runtime plugins or additional fields; and
+- the reviewed `nextCookies()` integration, with no storage plugins or additional fields; and
 - the bundled `RiffDBBetterAuthCore` contract and `BetterAuthServer` role.
 
 Unsupported configuration fails before any RiffDB request. A custom or plugin
 profile requires its own generated contract, named operations, client facade,
-and conformance tests; `npm run profiles:materialize` generates the first two
-from a reviewed plan. Adapter construction also verifies that the resolved
-`better-auth` installation is exactly `1.6.29`; package-manager overrides do
+and conformance tests. `materializeRiffDBBetterAuthRuntimeProfile` emits the
+reviewable runtime sources and binding; RiffDB compiles and locks their client.
+Adapter construction also verifies that the resolved
+`better-auth` installation is exactly `1.7.18`; package-manager overrides do
 not bypass that runtime check. Secret-bearing Better Auth debug logging is
 rejected rather than forwarded to the factory logger.
 
@@ -60,7 +64,80 @@ The caller owns the RiffDB driver connection and application-defined
 organization ID. Better Auth continues to own users, sessions, passwords,
 sign-in, OAuth, and reset flows. The package contains the exact RiffDB
 application source, lock, contract bundle, and generated artifacts required to
-deploy the core profile.
+deploy the core profile. Better Auth development dependencies stay exactly
+pinned. Supported versions are explicit; a scheduled registry check flags new
+stable releases for schema, call-shape, and conformance review.
+
+For Next.js Server Actions, import `nextCookies` from `better-auth/next-js`
+and add `nextCookies()` as the last plugin in the Better Auth configuration.
+It can accompany the default core profile or the compiled profiles below.
+Cookie propagation, RSC refresh suppression, and Server Action refresh behavior
+are covered by integration tests using the official plugin and mocked Next.js
+request helpers.
+
+## Organization and 2FA runtime profile
+
+Deploy `profiles/runtime/riffdb.application.json` and its exact lock before
+connecting the driver. Select its binding explicitly:
+
+```ts
+import profile from "@riffdb/better-auth/profiles/organization-security";
+import { organization, twoFactor } from "better-auth/plugins";
+
+const auth = betterAuth({
+  database: riffdbAdapter({ driver, organizationId: tenantId, profile }),
+  advanced: { database: { generateId: "uuid" } },
+  emailAndPassword: { enabled: true },
+  user: {
+    additionalFields: {
+      locale: { type: "string", required: false },
+      dateField: { type: "date", required: false },
+    },
+  },
+  plugins: [
+    organization({ membershipLimit: 100, invitationLimit: 100 }),
+    twoFactor(),
+  ],
+});
+```
+
+These are example profile fields; `dateField` also serves the upstream
+conformance test. Generate a separate reviewed profile to use a different field
+inventory. The standalone custom-field example is available at
+`@riffdb/better-auth/profiles/custom-fields` and deploys from
+`profiles/custom-fields/` without storage plugins.
+
+The adapter's `organizationId` is the application's RiffDB tenant partition.
+The organization plugin's `organizationId` identifies an auth organization
+inside that partition. They are separate identifiers.
+
+The organization profile supports organization creation/update/listing, active
+organization sessions, membership listing/counts/roles/removal, invitations and
+guarded status transitions, and atomic organization/dependent deletion.
+Membership creation and session activation during invitation acceptance share
+one compiled command. Native capacity guards admit at most 100 live memberships
+and 100 retained invitations per organization; deleting an individual record
+releases its capacity. Lists are bounded at 100, membership offsets at 4096,
+and user hydration sets at 32. Member pages support the compiled default role
+order, role ascending/descending, and creation-time ascending/descending.
+Other member filters and sorts are rejected.
+
+2FA supports TOTP enrollment/verification, OTP challenges, backup codes,
+challenge consumption, and account lockout. Failure increments, expired-lock
+reset, backup-code replacement, and invitation status transitions use native
+compiled commands. Tests cover TOTP enrollment, backup-code and invitation
+races, challenge replay, lockout counters, capacity contention, and reset rollback.
+
+Teams, dynamic access control, organization mutation hooks, renamed storage,
+plugin-model custom fields, user deletion in organization profiles, and
+`revokeSessionsOnPasswordReset` are rejected. Password changes that request
+`revokeOtherSessions` also require a separately compiled transaction graph.
+Organization limits must be integers from 1 through 100. Custom runtime fields
+currently support scalar strings, booleans, safe integers, and dates on `user`;
+custom indexes, uniqueness,
+and references require a separately implemented profile. Credential password
+reset supports an existing credential account and one verification row per
+identifier. Additional transaction graphs fail closed.
 
 ## Implemented core surface
 
@@ -128,7 +205,7 @@ With that generation-only config, run the Better Auth CLI version matching the
 pinned runtime:
 
 ```bash
-npx auth@1.6.29 generate --config ./auth.profile.ts --yes
+npx auth@1.7.18 generate --config ./auth.profile.ts --yes
 ```
 
 The output records resolved storage names, field types, required/unique/index
@@ -147,31 +224,84 @@ npm run profiles:write
 npm run profiles:check
 ```
 
+## Materializing an executable profile
+
+Pass the reviewed plan to `materializeRiffDBBetterAuthRuntimeProfile(plan)`.
+Write the returned `files` under a new application directory, review the
+contract, queries, and `profile.ts`, then run `riffdb application lock --write`
+in that directory. Compile `profile.ts` and the generated TypeScript client
+with your application and pass its default export as `riffdbAdapter({ profile,
+driver, organizationId })`. A JSON plan alone cannot be passed to the adapter.
+Runtime construction compares the resolved schema and reviewed plugins with
+the bound plan before requests. Binding also checks compiler-owned command and
+result schemas, so a stale client cannot silently omit a new optional field.
+The generated client and driver enforce the exact compiled application and
+operation identities.
+
+The planning fixture also reports its explicit non-null requirement for the
+optional unique team membership key; it cannot accept legacy null-key rows.
+
+The executable generator accepts the core schema plus the reviewed organization
+and 2FA schemas. The broader `materializeRiffDBBetterAuthProfile` remains a
+planning tool: its teams example reports unenforced references and is not an
+executable runtime profile.
+
+Regenerate the executable examples with `npm run profiles:runtime`, review
+the source diff, and write each application's lock explicitly. `npm run
+profiles:check` verifies source freshness, compiler locks, and generated clients.
+
+A different profile is a different compiled application identity. There is no
+automatic switch or reinterpretation of existing core data. For existing
+installations, plan and review an explicit data migration, including identifier
+mapping, required/default fields, references, secrets, and capacity counts.
+Deploy the matching contract, operations, role, and client together. Never point
+a new binding at an old lock. Runtime profile examples are intended for fresh
+installations until an application-specific migration has been reviewed.
+
 ## Local development
 
 ```bash
-npm install
+npm ci --ignore-scripts
 npm run check
 ```
 
-The lock is pinned to `@riffdb/client@0.2.0` and `@riffdb/cli@0.2.0`.
+The lock is pinned to `@riffdb/client@0.2.1` and `@riffdb/cli@0.2.1`.
 
 `npm run check` performs strict type checking, semantic and upstream tests,
 profile-artifact freshness, a production build, and a package dry run.
 
 ## Real loopback conformance
 
-Run the real service/driver flow with:
+Run the official suite against isolated TLS services and Rust driver hosts:
 
 ```bash
-riffdb dev --run
+npm run test:loopback
 ```
 
-The included runner exercises signup, sign-in, password reset and replay
-rejection, user/session/account/verification mutation paths, atomic OAuth
-creation, exact counts, bounded search/offset windows, nullable ordering,
-dependent cleanup, and read-after-commit fencing against the Rust service and
-driver host.
+This runs the core, custom-field, and organization/2FA profiles. It requires
+`riffdbd` and `riffdb-driverd` from the immutable RiffDB build in
+`.github/riffdb-revision` on PATH. `RIFFDB_CLI`, `RIFFDB_SERVER_BIN`, and
+`RIFFDB_DRIVERD` can select exact local binaries. The published RiffDB `0.2.1`
+release bundle includes the CLI and service, but omits the driver host. Build
+that host from a separate RiffDB checkout at the full revision recorded in
+`.github/riffdb-revision`:
+
+```bash
+# In that separate, pinned RiffDB checkout:
+RUSTC_WRAPPER= cargo build --locked --release -p riffdb-driver-host --bin riffdb-driverd
+
+# Back in this adapter checkout, with riffdbd on PATH:
+RIFFDB_DRIVERD=/path/to/riffdb/target/release/riffdb-driverd npm run test:loopback
+```
+
+Release CI verifies the bundle checksum and revision, then builds the driver
+from that same revision. Certificates, capabilities, sockets, and databases
+are disposable and removed at the end. The official
+harness's cleanup hook is scoped to that disposable service; it is never a
+public delete-all operation.
+
+The original `scripts/real-riffdb-runner.mjs` also remains available to an
+external harness supplying its ten exact driver-identity arguments.
 
 See [DESIGN.md](./DESIGN.md) for the method and safety inventory. The adapter
 follows Better Auth's
@@ -185,7 +315,9 @@ This adapter owns its RiffDB compatibility checks. Pull requests compile the
 application sources and verify existing locks and generated artifacts against
 the full commit in `.github/riffdb-revision`. Scheduled checks use RiffDB
 `main`; manual dispatch accepts a full commit or `main`. Failures are reported
-here and do not block RiffDB itself. Framework conformance remains separate.
+here and do not block RiffDB itself. The job also runs `npm run check` and
+`npm run test:loopback`, including the official Better Auth suite for every
+advertised runtime profile.
 
 To upgrade, update the pin, migrate sources as needed, review the result of
 `riffdb application lock --write`, and verify with `riffdb application check`.

package/dist/adapter.d.ts

@@ -2,6 +2,7 @@ import { type DriverApplicationTransport } from "@riffdb/client";
 import { type AdapterFactory, type DBAdapterDebugLogOption } from "better-auth/adapters";
 import type { BetterAuthOptions } from "better-auth";
 import { RiffDBBetterAuthCoreClient } from "./generated/client.js";
+import { type RiffDBCompiledProfile } from "./runtime-profile.js";
 export type RiffDBBetterAuthCallErrorCode = "invalid_configuration" | "unsupported_model" | "unsupported_call_shape" | "unsupported_transaction_shape" | "result_bound_exceeded" | "invalid_record_shape" | "declared_outcome";
 export declare class RiffDBBetterAuthCallError extends Error {
     readonly code: RiffDBBetterAuthCallErrorCode;
@@ -14,12 +15,17 @@ export interface RiffDBBetterAuthAdapterConfig {
     readonly organizationId: string;
     readonly commandAttemptBudget?: number;
     readonly debugLogs?: DBAdapterDebugLogOption;
+    readonly profile?: RiffDBCompiledProfile;
 }
+type CoreClient = Omit<RiffDBBetterAuthCoreClient, "causalSession" | "withReadAfterCommit"> & {
+    causalSession(): CoreClient;
+};
 interface InternalAdapterConfig {
-    readonly client: RiffDBBetterAuthCoreClient;
+    readonly client: CoreClient;
     readonly organizationId: string;
     readonly debugLogs?: DBAdapterDebugLogOption;
     readonly resetModelForTesting?: (model: string) => number | Promise<number>;
+    readonly profile?: RiffDBCompiledProfile;
 }
 export declare function assertSupportedBetterAuthInstallation(installedVersion?: string): void;
 export declare function buildRiffDBBetterAuthAdapter(config: InternalAdapterConfig): AdapterFactory<BetterAuthOptions>;

package/dist/adapter.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"adapter.d.ts","sourceRoot":"","sources":["../src/adapter.ts"],"names":[],"mappings":"AAIA,OAAO,EAEL,KAAK,0BAA0B,EAChC,MAAM,gBAAgB,CAAC;AACxB,OAAO,EAEL,KAAK,cAAc,EAInB,KAAK,uBAAuB,EAE7B,MAAM,sBAAsB,CAAC;AAC9B,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,aAAa,CAAC;AAErD,OAAO,EACL,0BAA0B,EAe3B,MAAM,uBAAuB,CAAC;AAkD/B,MAAM,MAAM,6BAA6B,GACrC,uBAAuB,GACvB,mBAAmB,GACnB,wBAAwB,GACxB,+BAA+B,GAC/B,uBAAuB,GACvB,sBAAsB,GACtB,kBAAkB,CAAC;AAEvB,qBAAa,yBAA0B,SAAQ,KAAK;aAEhC,IAAI,EAAE,6BAA6B;aACnC,SAAS,EAAE,MAAM;aACjB,OAAO,CAAC,EAAE,MAAM;IAHlC,YACkB,IAAI,EAAE,6BAA6B,EACnC,SAAS,EAAE,MAAM,EACjB,OAAO,CAAC,EAAE,MAAM,YAAA,EAQjC;CACF;AAED,MAAM,WAAW,6BAA6B;IAC5C,QAAQ,CAAC,MAAM,EAAE,0BAA0B,CAAC;IAC5C,QAAQ,CAAC,cAAc,EAAE,MAAM,CAAC;IAChC,QAAQ,CAAC,oBAAoB,CAAC,EAAE,MAAM,CAAC;IACvC,QAAQ,CAAC,SAAS,CAAC,EAAE,uBAAuB,CAAC;CAC9C;AAED,UAAU,qBAAqB;IAC7B,QAAQ,CAAC,MAAM,EAAE,0BAA0B,CAAC;IAC5C,QAAQ,CAAC,cAAc,EAAE,MAAM,CAAC;IAChC,QAAQ,CAAC,SAAS,CAAC,EAAE,uBAAuB,CAAC;IAC7C,QAAQ,CAAC,oBAAoB,CAAC,EAAE,CAAC,KAAK,EAAE,MAAM,KAAK,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC;CAC7E;AAuBD,wBAAgB,qCAAqC,CACnD,gBAAgB,SAAsC,GACrD,IAAI,CAIN;AAo0CD,wBAAgB,4BAA4B,CAC1C,MAAM,EAAE,qBAAqB,GAC5B,cAAc,CAAC,iBAAiB,CAAC,CAuCnC;AAED,wBAAgB,aAAa,CAC3B,MAAM,EAAE,6BAA6B,GACpC,cAAc,CAAC,iBAAiB,CAAC,CAWnC"}
+{"version":3,"file":"adapter.d.ts","sourceRoot":"","sources":["../src/adapter.ts"],"names":[],"mappings":"AAIA,OAAO,EAEL,KAAK,0BAA0B,EAChC,MAAM,gBAAgB,CAAC;AACxB,OAAO,EAEL,KAAK,cAAc,EAInB,KAAK,uBAAuB,EAE7B,MAAM,sBAAsB,CAAC;AAC9B,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,aAAa,CAAC;AAErD,OAAO,EACL,0BAA0B,EAe3B,MAAM,uBAAuB,CAAC;AAE/B,OAAO,EACL,KAAK,qBAAqB,EAAE,MAAM,sBAAsB,CAAC;AAkD3D,MAAM,MAAM,6BAA6B,GACrC,uBAAuB,GACvB,mBAAmB,GACnB,wBAAwB,GACxB,+BAA+B,GAC/B,uBAAuB,GACvB,sBAAsB,GACtB,kBAAkB,CAAC;AAEvB,qBAAa,yBAA0B,SAAQ,KAAK;aAEhC,IAAI,EAAE,6BAA6B;aACnC,SAAS,EAAE,MAAM;aACjB,OAAO,CAAC,EAAE,MAAM;IAHlC,YACkB,IAAI,EAAE,6BAA6B,EACnC,SAAS,EAAE,MAAM,EACjB,OAAO,CAAC,EAAE,MAAM,YAAA,EAQjC;CACF;AAED,MAAM,WAAW,6BAA6B;IAC5C,QAAQ,CAAC,MAAM,EAAE,0BAA0B,CAAC;IAC5C,QAAQ,CAAC,cAAc,EAAE,MAAM,CAAC;IAChC,QAAQ,CAAC,oBAAoB,CAAC,EAAE,MAAM,CAAC;IACvC,QAAQ,CAAC,SAAS,CAAC,EAAE,uBAAuB,CAAC;IAC7C,QAAQ,CAAC,OAAO,CAAC,EAAE,qBAAqB,CAAC;CAC1C;AAED,KAAK,UAAU,GAAG,IAAI,CAAC,0BAA0B,EAAE,eAAe,GAAG,qBAAqB,CAAC,GAAG;IAC5F,aAAa,IAAI,UAAU,CAAC;CAC7B,CAAC;AAEF,UAAU,qBAAqB;IAC7B,QAAQ,CAAC,MAAM,EAAE,UAAU,CAAC;IAC5B,QAAQ,CAAC,cAAc,EAAE,MAAM,CAAC;IAChC,QAAQ,CAAC,SAAS,CAAC,EAAE,uBAAuB,CAAC;IAC7C,QAAQ,CAAC,oBAAoB,CAAC,EAAE,CAAC,KAAK,EAAE,MAAM,KAAK,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC;IAC5E,QAAQ,CAAC,OAAO,CAAC,EAAE,qBAAqB,CAAC;CAC1C;AAuBD,wBAAgB,qCAAqC,CACnD,gBAAgB,SAAsC,GACrD,IAAI,CAIN;AAqnDD,wBAAgB,4BAA4B,CAC1C,MAAM,EAAE,qBAAqB,GAC5B,cAAc,CAAC,iBAAiB,CAAC,CA2CnC;AAED,wBAAgB,aAAa,CAC3B,MAAM,EAAE,6BAA6B,GACpC,cAAc,CAAC,iBAAiB,CAAC,CAanC"}