@opensaas/stack-core 0.40.0 → 0.41.0

package/.turbo/turbo-build.log

@@ -1,4 +1,4 @@
 
-> @opensaas/stack-core@0.40.0 build /home/runner/work/stack/stack/packages/core
+> @opensaas/stack-core@0.41.0 build /home/runner/work/stack/stack/packages/core
 > tsc
 

package/CHANGELOG.md

@@ -1,5 +1,44 @@
 # @opensaas/stack-core
 
+## 0.41.0
+
+### Minor Changes
+
+- [#1179](https://github.com/OpenSaasAU/stack/pull/1179) [`67dce2e`](https://github.com/OpenSaasAU/stack/commit/67dce2e9d96afdc5c69f0a2f1c8b395346d4e942) Thanks [@borisno2](https://github.com/borisno2)! - A list/field `resolveInput` / `validate` / `beforeOperation` / `afterOperation` hook's `context` is now a full secured context — `sudo()`, `withSession()`, `transaction()` and `serverAction` — bound to the write's OWN transaction client, exactly like the `txContext` a `context.transaction()` callback receives.
+
+  ```typescript
+  Order: list({
+    hooks: {
+      beforeOperation: async ({ context }) => {
+        // Elevated AND atomic with this write — rolls back together if it throws.
+        await context.sudo().db.auditLog.create({ data: { action: 'order-write' } })
+      },
+    },
+  })
+  ```
+
+  Previously this `context` had no `sudo()`/`withSession()`/`transaction()` at all, forcing a workaround (`getContext(session).sudo()`) that opened a SEPARATE connection from the write's transaction — its writes could survive a rollback, and it could deadlock on a single-connection adapter. `context.transaction()` called from inside one of these hooks now joins the write's transaction rather than opening a nested one. `beforeTransaction`/`afterTransaction` are unaffected — they keep the plain access-checked context bound to the base client, always. A field's `resolveOutput` keeps the same context type as before; which client it's bound to already depended on how the read arose (a plain read: the base client; a create/update's own Field Visibility pass: that write's transaction client), unchanged by this release.
+
+### Patch Changes
+
+- [#1108](https://github.com/OpenSaasAU/stack/pull/1108) [`2260539`](https://github.com/OpenSaasAU/stack/commit/2260539c5488dae0ee6e7f86ccd913e5c898ccdb) Thanks [@borisno2](https://github.com/borisno2)! - Fix: a relation quantifier (`some`/`every`/`none`/`is`/`isNot`) nested inside an `include` entry's own `where` is now scoped by the deeper related list's `query` access and field-read access too, reusing `buildAccessScopedWhere` ([#916](https://github.com/OpenSaasAU/stack/issues/916)) — closing a residual probing-oracle gap in [#1092](https://github.com/OpenSaasAU/stack/issues/1092)'s fix.
+
+- [#1102](https://github.com/OpenSaasAU/stack/pull/1102) [`aa34cca`](https://github.com/OpenSaasAU/stack/commit/aa34cca65877759b9625da1538c65c53ed54385a) Thanks [@borisno2](https://github.com/borisno2)! - Fix: a `where`/`orderBy` nested inside a caller's `include` entry now validates against the related list's config, closing a probing oracle over undeclared or read-denied fields one hop into a relation ([#1092](https://github.com/OpenSaasAU/stack/issues/1092)).
+
+- [#1041](https://github.com/OpenSaasAU/stack/pull/1041) [`182153c`](https://github.com/OpenSaasAU/stack/commit/182153cb976b14ef67673d0eeef7925d950bfa10) Thanks [@borisno2](https://github.com/borisno2)! - Upgrade Prisma packages to `^7.9.1`, keeping the CLI, client, and driver adapters on the same release. Scaffolded PostgreSQL projects now pin `@prisma/adapter-pg` to `^7.9.1`.
+
+- [#1101](https://github.com/OpenSaasAU/stack/pull/1101) [`682795f`](https://github.com/OpenSaasAU/stack/commit/682795f7c7f0d0194ffd08e993d452c368bcd847) Thanks [@borisno2](https://github.com/borisno2)! - Fix a query fragment read (`{ query: fragment }`) skipping the Access Filter's scoping walk, so a related list's `query` access, row filters, and the read-include depth cap were never enforced. Fragment reads may now return fewer related rows — those rows were never authorised.
+
+- [#1110](https://github.com/OpenSaasAU/stack/pull/1110) [`73d1b6a`](https://github.com/OpenSaasAU/stack/commit/73d1b6aba9a9b789a8111105d56257a1de66a883) Thanks [@borisno2](https://github.com/borisno2)! - A caller-supplied `_count` in `include` is now scoped by each named relation's own `query` access (a row filter is folded into the count, a fully denied relation counts `0`), closing a cardinality leak where counts previously reached the caller unscoped.
+
+- [#1091](https://github.com/OpenSaasAU/stack/pull/1091) [`f1e8792`](https://github.com/OpenSaasAU/stack/commit/f1e8792ce580d92a5874599dfb8a8ccde4d6c8b3) Thanks [@borisno2](https://github.com/borisno2)! - Fix a read naming a list-only ref's synthetic back-relation (`from_<List>_<field>`) in `include`: it now resolves to the declared relationship it stands for and is scoped by that list's `query` access, its field-level `read` gates, and its virtual fields — instead of being returned unscoped. An `include` key that resolves to neither a declared relationship, a synthetic back-relation, nor `_count` is now rejected rather than silently passed through. Responses will shrink for callers relying on either gap — the extra rows and fields they received were never authorised.
+
+- [#1120](https://github.com/OpenSaasAU/stack/pull/1120) [`9eb7c77`](https://github.com/OpenSaasAU/stack/commit/9eb7c7766d212e92b02d53a1ba3aaead4faf1496) Thanks [@borisno2](https://github.com/borisno2)! - Fix `_count` ignoring a relationship's field-level `read` access, letting the true count of a hidden relationship leak through both the admin list view and a caller-supplied `_count`.
+
+- [#1090](https://github.com/OpenSaasAU/stack/pull/1090) [`5b478de`](https://github.com/OpenSaasAU/stack/commit/5b478de64f3564d837d2f9f912972e49008be884) Thanks [@borisno2](https://github.com/borisno2)! - Fix nested update/delete (e.g. `post.update({ data: { author: { update: {...} } } })`) silently treating a Prisma filter returned by the target list's `update`/`delete` access as an unconditional allow. It is now re-checked against the target row in the database, matching top-level write behavior.
+
+- [#1115](https://github.com/OpenSaasAU/stack/pull/1115) [`d335122`](https://github.com/OpenSaasAU/stack/commit/d335122323b3402c0838aa50873fab0c085fbb01) Thanks [@borisno2](https://github.com/borisno2)! - Fix a denied to-many relation coming back `undefined` instead of `[]` on both the caller-`include:` and fragment `query` read paths.
+
 ## 0.40.0
 
 ### Minor Changes

package/CLAUDE.md

@@ -192,6 +192,58 @@ Key points:
   optimistically at write time, unchanged. See ADR-0028 and the hooks concept
   doc.
 
+#### Hook context is the same secured context as a transaction's (#1176)
+
+A list/field `resolveInput` / `validate` / `beforeOperation` / `afterOperation`
+hook's `context` argument is a full `StackContext` — `sudo()`, `withSession()`,
+`transaction()` and `serverAction` are all present, exactly like the `txContext`
+a `context.transaction()` callback receives — bound to the WRITE'S OWN
+transaction client, not the base one. This amends ADR-0012: the Write
+Pipeline's transaction rebind (`bindContextToTransaction`) goes through the
+same `getContext` factory `context.transaction()` already rebuilds through,
+instead of hand-assembling a bare `AccessContext` object literal.
+
+```typescript
+Order: list({
+  hooks: {
+    beforeOperation: async ({ context }) => {
+      // Elevated AND atomic with this write: rolls back together if the
+      // write (or a later hook in it) throws — unlike `getContext(session)
+      // .sudo()`, which would bind to a SEPARATE connection.
+      await context.sudo().db.auditLog.create({ data: { action: 'order-write' } })
+    },
+  },
+})
+```
+
+- `context.sudo()` / `context.withSession(s)` from one of these hooks stays
+  bound to the SAME transaction client the hook itself was given — carrying
+  the write's transaction owner (ADR-0028, so a write through them defers its
+  `afterTransaction` to that owner) and the hook's own resolve chain
+  (ADR-0023, so a write issued from inside a `resolveOutput` hook keeps that
+  hook's cycle-guard chain into its own Field Visibility pass).
+- `context.transaction(fn)` called from inside one of these hooks **joins**
+  the write's transaction (the existing "no interactive client → run
+  directly" fallback) — it never opens a nested one.
+- Plugin runtimes are **not** re-executed on this rebind (same rule as the
+  nested-write rebind ADR-0010 already established).
+- **Unaffected:** `beforeTransaction` / `afterTransaction` (list and field) keep
+  the plain `AccessContext`, bound to the BASE client, always — see ADR-0028
+  for why boundary hooks must not run through a client that may already be
+  closed by flush time.
+- **A field's `resolveOutput` keeps the plain `AccessContext` type**, but which
+  client it's bound to already depended — before this record and after it
+  alike — on how the read that triggered it arose: a plain top-level read
+  resolves against the base client; a `resolveOutput` that runs as part of a
+  create/update's OWN result (the write's Field Visibility pass, Phase 11)
+  resolves against THAT write's transaction client (ADR-0010) — so a
+  `context.db` read/write from inside such a hook is already atomic with the
+  write, same as `beforeOperation`/`afterOperation`. Not a consequence of this
+  record; stated here only so it isn't mistaken for one.
+
+See ADR-0066 and the hooks concept doc's "In-transaction vs
+transaction-boundary hooks" section.
+
 #### Substituting a session (`context.withSession`, #980)
 
 `context.withSession(session)` sits beside `sudo()` on the other axis:

package/dist/access/access-filter.d.ts

@@ -1,6 +1,15 @@
 import type { Session, AccessContext, PrismaFilter } from './types.js';
 import type { OpenSaasConfig, FieldConfig, ListConfig } from '../config/types.js';
-/** One to-one relation's recorded access filter, or an outright denial — see the module doc's "To-one relations" section. */
+import { type ResolveSyntheticRelation } from './query-validation.js';
+/**
+ * One relation's recorded access filter, or an outright denial — see the
+ * module doc's "To-one relations" section. `kind: 'scoped'` is to-one only
+ * (a to-many filter is attached as Prisma `where` instead, never recorded
+ * here); `kind: 'denied'` is recorded for BOTH arities (issue #1103) — a
+ * to-many relation has no `where`-based way to record "zero rows, and the
+ * key itself absent" either, so it shares the same post-query mechanism a
+ * denied to-one already used.
+ */
 export type ToOneAccessFilterEntry = {
     kind: 'scoped';
     relatedListName: string;
@@ -9,35 +18,75 @@ export type ToOneAccessFilterEntry = {
     kind: 'denied';
 };
 /**
- * Which to-one relations, at which nesting level of an `include`, need a
- * post-query existence check rather than a Prisma-side `where` — because
- * their related list's `query` access resolved to a filter (`kind: 'scoped'`)
- * or a denial (`kind: 'denied'`) and Prisma cannot express either as a nested
- * `where` on a to-one include. `resolveToOneAccessVisibility` consumes this
- * tree; `filterReadableFields` (`field-visibility.ts`) applies its result.
+ * Which relations, at which nesting level of an `include`, need a post-query
+ * fixup rather than a Prisma-side `where` — a to-one relation whose related
+ * list's `query` access resolved to a filter (`kind: 'scoped'`) or a denial
+ * (`kind: 'denied'`), Prisma cannot express either as a nested `where` on a
+ * to-one include; a to-many relation whose related list denies `query`
+ * access outright (`kind: 'denied'` only — a to-many filter is attached as
+ * `where` and never reaches this tree) is dropped from `include` entirely,
+ * so nothing marks its key present in the raw row either (issue #1103).
+ * `resolveToOneAccessVisibility` consumes this tree; `filterReadableFields`
+ * (`field-visibility.ts`) applies its result — forcing a denied key to `null`
+ * for a to-one relation, `[]` for a to-many one.
  */
 export type ToOneAccessFilterTree = {
-    /** To-one relation keys at THIS level needing a post-query check. */
+    /** Relation keys at THIS level needing a post-query fixup. */
     filters: Record<string, ToOneAccessFilterEntry>;
-    /** Per-key trees for relations present in the include for other reasons, whose own nested include may contain further to-one filters. */
+    /** Per-key trees for relations present in the include for other reasons, whose own nested include may contain further filters. */
     nested: Record<string, ToOneAccessFilterTree>;
 };
 export declare function emptyToOneAccessFilterTree(): ToOneAccessFilterTree;
+/**
+ * Whether a relationship field is to-one (at most one related row) rather
+ * than to-many. Exported so `field-visibility.ts` can pick the same `null`
+ * (to-one) vs `[]` (to-many) shape for a denied relation's forced value
+ * (issue #1103) that this module used to decide whether to record the
+ * denial in the first place — one source of truth for arity, not two.
+ */
+export declare function isToOneRelationship(fieldConfig: FieldConfig): boolean;
+/**
+ * Which `_count.select` keys, at which nesting level of an `include`, were
+ * denied outright by their related list's `query` access — omitted from the
+ * `_count.select` sent to Prisma (issue #1087), so the row Prisma returns
+ * either lacks the key entirely or lacks a `_count` object at all. Consumed
+ * post-query by `filterReadableFields` (`field-visibility.ts`), which injects
+ * `0` for each — a count is a session-relative value, and `0` is what "no
+ * visible rows" means for it, never an absent key (mirroring the to-one
+ * `null` injection this module already does for issue #974, though a denied
+ * count needs no existence check: `0` requires no query at all).
+ */
+export type CountAccessDenialTree = {
+    /** `_count.select` keys denied at THIS level. */
+    keys: Set<string>;
+    /** Per-relation trees for relations present in the include for other reasons, whose own nested include may contain a further `_count`. */
+    nested: Record<string, CountAccessDenialTree>;
+};
+export declare function emptyCountAccessDenialTree(): CountAccessDenialTree;
 /**
  * Build the access-scoped `include` for exactly the relations a read
  * requested, recursing only into branches `requestedInclude` itself names.
  *
  * For each key in `requestedInclude`:
- * - Not a config-declared relationship → access control does not govern it;
- *   passed through unchanged (e.g. a fragment/caller key that isn't a
- *   relationship at all).
+ * - A declared field that isn't a relationship (scalar, virtual, …) → access
+ *   control does not govern it; passed through unchanged (a virtual key is
+ *   stripped later by `stripVirtualFieldsFromInclude`, #628).
+ * - Not declared at all → resolved via `resolveSyntheticReverseRelation`
+ *   (the synthetic-back-relation case above); `_count` is scoped by
+ *   `buildAccessScopedCountSelect` (issue #1087 — each named relation's own
+ *   `query` access, exactly like any other relation this walk scopes; a
+ *   denied one is recorded for `filterReadableFields` to inject `0` for,
+ *   post-query, since Prisma cannot be asked for a guaranteed `0`); anything
+ *   else throws `UndeclaredIncludeKeyError` rather than reaching the
+ *   database unscoped.
  * - A declared relationship whose related list's `query` access denies it
  *   (`=== false`) → dropped entirely, no matter what the request asked for
  *   nested beneath it (#566): the caller chooses *which* relations, access
- *   control chooses *whether* and *with what filter*. For a to-one relation
- *   this denial is also recorded in `toOneAccessFilters` (`kind: 'denied'`),
- *   so `filterReadableFields` can still surface an explicit `null` for it
- *   (issue #974) rather than an absent key.
+ *   control chooses *whether* and *with what filter*. This denial is also
+ *   recorded in `toOneAccessFilters` (`kind: 'denied'`), for either arity, so
+ *   `filterReadableFields` can still surface an explicit `null` (to-one,
+ *   issue #974) or `[]` (to-many, issue #1103) for it rather than an absent
+ *   key.
  * - Otherwise, for a to-**many** relation → the access `where` is
  *   AND-combined with any caller-supplied nested `where` (never replaced —
  *   the other half of #566), and a caller-supplied `take` rides through
@@ -65,8 +114,15 @@ export declare function buildAccessScopedInclude(requestedInclude: Record<string
 }, config: OpenSaasConfig, listKey: string, depth?: number): Promise<{
     include: Record<string, unknown>;
     toOneAccessFilters: ToOneAccessFilterTree;
+    countDenials: CountAccessDenialTree;
 }>;
-/** One to-one relation's resolved post-query visibility — see `resolveToOneAccessVisibility`. */
+/**
+ * One relation's resolved post-query visibility — see
+ * `resolveToOneAccessVisibility`. `kind: 'visible'` (an existence check
+ * against a set of ids) only ever arises for a to-one relation, since only a
+ * to-one `kind: 'scoped'` filter entry produces one; `kind: 'denied'` passes
+ * straight through unresolved for either arity.
+ */
 export type ToOneVisibility = {
     kind: 'denied';
 } | {
@@ -146,11 +202,25 @@ export declare function resolveToOneAccessVisibility(items: readonly unknown[],
  * caller can observe that an inaccessible related row exists (an `every`
  * that "should" pass instead fails), but never that row's field values,
  * which is the property this ticket exists to close.
+ *
+ * A quantifier's value of literal `null` (`is: null`/`isNot: null`, a to-one
+ * relation's existence check) is passed through untouched rather than folded:
+ * it names no fields to read-check or scope, and AND-folding an access filter
+ * into it would silently invert the caller's own predicate (see the inline
+ * comment at that branch).
+ *
+ * `resolveSyntheticRelation` (#1092/#1108) extends this to a key that
+ * resolves to a synthetic back-relation (#1082) rather than a declared
+ * field, recursing against its SOURCE list. Only `buildAccessScopedInclude`
+ * passes it, for the include-nested `where` position; the top-level `where`
+ * this function was originally built for (`context/index.ts`) omits it, so
+ * a synthetic key there is unaffected — matching #1092's own scope, which
+ * deliberately left the top-level checks unchanged.
  */
 export declare function buildAccessScopedWhere(where: unknown, listConfig: ListConfig<any>, listName: string, config: OpenSaasConfig, args: {
     session: Session | null;
     context: AccessContext;
-}): Promise<unknown>;
+}, resolveSyntheticRelation?: ResolveSyntheticRelation): Promise<unknown>;
 /**
  * Remove keys that correspond to `virtual` fields from a Prisma `include`
  * object, recursing into nested relationship includes using the related

package/dist/access/access-filter.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"access-filter.d.ts","sourceRoot":"","sources":["../../src/access/access-filter.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,aAAa,EAAE,YAAY,EAAE,MAAM,YAAY,CAAA;AACtE,OAAO,KAAK,EAAE,cAAc,EAAE,WAAW,EAAE,UAAU,EAAE,MAAM,oBAAoB,CAAA;AAmHjF,6HAA6H;AAC7H,MAAM,MAAM,sBAAsB,GAChC;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,eAAe,EAAE,MAAM,CAAC;IAAC,WAAW,EAAE,YAAY,CAAA;CAAE,GAAG;IAAE,IAAI,EAAE,QAAQ,CAAA;CAAE,CAAA;AAE7F;;;;;;;GAOG;AACH,MAAM,MAAM,qBAAqB,GAAG;IAClC,qEAAqE;IACrE,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,sBAAsB,CAAC,CAAA;IAC/C,yIAAyI;IACzI,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,qBAAqB,CAAC,CAAA;CAC9C,CAAA;AAED,wBAAgB,0BAA0B,IAAI,qBAAqB,CAElE;AAWD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AACH,wBAAsB,wBAAwB,CAC5C,gBAAgB,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EACzC,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,IAAI,EAAE;IACJ,OAAO,EAAE,OAAO,GAAG,IAAI,CAAA;IACvB,OAAO,EAAE,aAAa,CAAA;CACvB,EACD,MAAM,EAAE,cAAc,EACtB,OAAO,EAAE,MAAM,EACf,KAAK,GAAE,MAAU,GAChB,OAAO,CAAC;IAAE,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IAAC,kBAAkB,EAAE,qBAAqB,CAAA;CAAE,CAAC,CAgF1F;AAED,iGAAiG;AACjG,MAAM,MAAM,eAAe,GAAG;IAAE,IAAI,EAAE,QAAQ,CAAA;CAAE,GAAG;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,GAAG,EAAE,WAAW,CAAC,MAAM,CAAC,CAAA;CAAE,CAAA;AAEhG,6GAA6G;AAC7G,MAAM,MAAM,yBAAyB,GAAG;IACtC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,eAAe,CAAC,CAAA;IACxC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,yBAAyB,CAAC,CAAA;CAClD,CAAA;AAED,wBAAgB,8BAA8B,IAAI,yBAAyB,CAE1E;AAED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAsB,4BAA4B,CAChD,KAAK,EAAE,SAAS,OAAO,EAAE,EACzB,IAAI,EAAE,qBAAqB,EAC3B,IAAI,EAAE;IACJ,OAAO,EAAE,OAAO,GAAG,IAAI,CAAA;IACvB,OAAO,EAAE,aAAa,CAAA;CACvB,GACA,OAAO,CAAC,yBAAyB,CAAC,CA+CpC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AACH,wBAAsB,sBAAsB,CAC1C,KAAK,EAAE,OAAO,EAEd,UAAU,EAAE,UAAU,CAAC,GAAG,CAAC,EAC3B,QAAQ,EAAE,MAAM,EAChB,MAAM,EAAE,cAAc,EACtB,IAAI,EAAE;IACJ,OAAO,EAAE,OAAO,GAAG,IAAI,CAAA;IACvB,OAAO,EAAE,aAAa,CAAA;CACvB,GACA,OAAO,CAAC,OAAO,CAAC,CA0FlB;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,6BAA6B,CAC3C,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,EAC5C,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,MAAM,EAAE,cAAc,GACrB,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,CA+BrC"}
+{"version":3,"file":"access-filter.d.ts","sourceRoot":"","sources":["../../src/access/access-filter.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,aAAa,EAAE,YAAY,EAAE,MAAM,YAAY,CAAA;AACtE,OAAO,KAAK,EAAE,cAAc,EAAE,WAAW,EAAE,UAAU,EAAE,MAAM,oBAAoB,CAAA;AAcjF,OAAO,EAOL,KAAK,wBAAwB,EAE9B,MAAM,uBAAuB,CAAA;AAkK9B;;;;;;;;GAQG;AACH,MAAM,MAAM,sBAAsB,GAChC;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,eAAe,EAAE,MAAM,CAAC;IAAC,WAAW,EAAE,YAAY,CAAA;CAAE,GAAG;IAAE,IAAI,EAAE,QAAQ,CAAA;CAAE,CAAA;AAE7F;;;;;;;;;;;;GAYG;AACH,MAAM,MAAM,qBAAqB,GAAG;IAClC,8DAA8D;IAC9D,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,sBAAsB,CAAC,CAAA;IAC/C,kIAAkI;IAClI,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,qBAAqB,CAAC,CAAA;CAC9C,CAAA;AAED,wBAAgB,0BAA0B,IAAI,qBAAqB,CAElE;AAMD;;;;;;GAMG;AACH,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,WAAW,GAAG,OAAO,CAErE;AAED;;;;;;;;;;GAUG;AACH,MAAM,MAAM,qBAAqB,GAAG;IAClC,iDAAiD;IACjD,IAAI,EAAE,GAAG,CAAC,MAAM,CAAC,CAAA;IACjB,0IAA0I;IAC1I,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,qBAAqB,CAAC,CAAA;CAC9C,CAAA;AAED,wBAAgB,0BAA0B,IAAI,qBAAqB,CAElE;AAiND;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4CG;AACH,wBAAsB,wBAAwB,CAC5C,gBAAgB,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EACzC,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,IAAI,EAAE;IACJ,OAAO,EAAE,OAAO,GAAG,IAAI,CAAA;IACvB,OAAO,EAAE,aAAa,CAAA;CACvB,EACD,MAAM,EAAE,cAAc,EACtB,OAAO,EAAE,MAAM,EACf,KAAK,GAAE,MAAU,GAChB,OAAO,CAAC;IACT,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;IAChC,kBAAkB,EAAE,qBAAqB,CAAA;IACzC,YAAY,EAAE,qBAAqB,CAAA;CACpC,CAAC,CAmLD;AAED;;;;;;GAMG;AACH,MAAM,MAAM,eAAe,GAAG;IAAE,IAAI,EAAE,QAAQ,CAAA;CAAE,GAAG;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,GAAG,EAAE,WAAW,CAAC,MAAM,CAAC,CAAA;CAAE,CAAA;AAEhG,6GAA6G;AAC7G,MAAM,MAAM,yBAAyB,GAAG;IACtC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,eAAe,CAAC,CAAA;IACxC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,yBAAyB,CAAC,CAAA;CAClD,CAAA;AAED,wBAAgB,8BAA8B,IAAI,yBAAyB,CAE1E;AAED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAsB,4BAA4B,CAChD,KAAK,EAAE,SAAS,OAAO,EAAE,EACzB,IAAI,EAAE,qBAAqB,EAC3B,IAAI,EAAE;IACJ,OAAO,EAAE,OAAO,GAAG,IAAI,CAAA;IACvB,OAAO,EAAE,aAAa,CAAA;CACvB,GACA,OAAO,CAAC,yBAAyB,CAAC,CA+CpC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AACH,wBAAsB,sBAAsB,CAC1C,KAAK,EAAE,OAAO,EAEd,UAAU,EAAE,UAAU,CAAC,GAAG,CAAC,EAC3B,QAAQ,EAAE,MAAM,EAChB,MAAM,EAAE,cAAc,EACtB,IAAI,EAAE;IACJ,OAAO,EAAE,OAAO,GAAG,IAAI,CAAA;IACvB,OAAO,EAAE,aAAa,CAAA;CACvB,EAKD,wBAAwB,CAAC,EAAE,wBAAwB,GAClD,OAAO,CAAC,OAAO,CAAC,CAiHlB;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,6BAA6B,CAC3C,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,EAC5C,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,MAAM,EAAE,cAAc,GACrB,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,CA+BrC"}