@jantstack/adonis-authz 2.0.0-alpha.1 → 2.4.0-alpha.1

package/build/src/drivers/openfga_facts.d.ts

@@ -0,0 +1,369 @@
+import type { CatalogProjectionRole, HolderTypeMap } from '../types.js';
+/**
+ * `holderTypes` tiene que ser INYECTIVO. Si dos morph names caen en el mismo
+ * tipo FGA, para el store son un solo holder: un grant a `users:U` autoriza a
+ * `integrations:U`, `listSubjects` devuelve el morph equivocado y un revoke
+ * borra al otro (invariante 4, L0.2). El generador del modelo lo "sabía"
+ * (deduplicaba con un Set) y publicaba sin quejarse: ahora lanza aquí, al
+ * construir el driver y al generar cualquiera de los dos modelos, antes de
+ * tocar nada.
+ */
+export declare function assertHolderTypes(holderTypes: HolderTypeMap): void;
+/**
+ * Longitud máxima de un nombre de relación en FGA. `MAX_SLUG_LENGTH` (42) es
+ * justo esto menos el prefijo derivado más largo (`permits_`), así que un
+ * slug legal siempre cabe: la comprobación de aquí es la red del generador,
+ * que también lo llaman herramientas con listas de permisos que no pasaron
+ * por `assertValidSlug` (una base sincronizada por otra versión, un driver
+ * de terceros).
+ */
+export declare const FGA_MAX_RELATION_NAME = 50;
+/**
+ * Longitud máxima del id de un objeto FGA. Con la gramática publicada nada
+ * se acerca (`role_binding:<tipo>|<uuid>|<roleUuid>` son 107 como mucho),
+ * pero el id se compone de partes que vienen de la BASE: un catálogo
+ * corrupto no puede fabricar un objeto que el store no pueda leer de vuelta.
+ */
+export declare const FGA_MAX_OBJECT_ID = 256;
+/**
+ * Techo del authorization model (default de
+ * `OPENFGA_MAX_AUTHORIZATION_MODEL_SIZE_IN_BYTES`). **El techo son BYTES; el
+ * número de permisos que caben NO es una propiedad del modelo** (3b-4 · C3):
+ * depende de cuántos holder types declaras, de cuánto miden sus NOMBRES en el
+ * modelo y de cuánto miden los slugs de tus permisos. Medido con
+ * `factsModelBytes` —que cuenta los mismos bytes que el servidor, contrastado
+ * contra un `:8101` real— y fijado por un caso (`3b-4 · C3`):
+ *
+ * | catálogo | permisos que caben |
+ * |---|---|
+ * | 1 holder type, slugs `p0`…`pN` | **800** |
+ * | 3 holder types (`user`/`admin`/`integration`), slugs `p0`…`pN` | **691** |
+ * | 1 holder type, slugs `docs:readN` | **576** |
+ * | 3 holder types, slugs `recursoN:accion` (REALISTAS) | **447** |
+ * | 3 holder types, slugs de 40 caracteres | **272** |
+ *
+ * O sea: el «≈691» que se publicó es la cifra de un catálogo cuyos permisos se
+ * llaman `p0`, `p1`, `p2`…; **con nombres de permiso normales el techo está en
+ * ~450**. Y los mismos tres holder types con nombres más cortos (`bot` en vez
+ * de `integration`) dan 721: no basta con decir «tres holder types».
+ *
+ * Se valida en `syncAuthzCatalog` ANTES de escribir el catálogo: un catálogo
+ * que no se puede publicar no se escribe a medias en un entorno y entero en
+ * otro. El gate por bytes es exacto y salta antes de escribir, así que
+ * equivocarse con la cifra derivada no concede nada: solo sorprende.
+ */
+export declare const FACTS_MODEL_MAX_BYTES = 262144;
+/**
+ * **Profundidad máxima de cadena que el modelo (c2) resuelve** (3b-2e · E5),
+ * MEDIDA contra OpenFGA v1.19 con el `--resolve-node-limit` por defecto (25).
+ * Con el grant en la RAÍZ y el `Check` a profundidad creciente, 25
+ * repeticiones por punto:
+ *
+ * | saltos `parent` | `can_<P>` |
+ * |---|---|
+ * | 21 | 25/25 resuelve |
+ * | **22** | **25/25 resuelve** ← la cota que se declara |
+ * | 23 | resuelve casi siempre y **falla entre un 4 % y un 26 %** de las veces según la carga — el borde NO es nítido |
+ * | 24 | 0/25: siempre falla |
+ *
+ * (Remedido en 3b-4 · C4 sobre 50 hojas a la misma profundidad: a 22, 200 de
+ * 200 resuelven en cuatro lotes; a 23, entre 6 y 13 errores por lote de 50, y
+ * 15 de 100 en checks sueltos; a 24, 100 de 100 fallan.)
+ *
+ * Las otras dos ramas del modelo llegan más lejos (`denied_<P>` hasta 25,
+ * `ancestor` hasta 26): manda la más baja, y es `can_<P>` porque es una resta
+ * (`difference`) sobre una unión con DOS TTU (`binding` y `parent`), o sea dos
+ * reescrituras más que las otras.
+ *
+ * **Lo importante del hallazgo no es el número, es que el borde es
+ * PROBABILÍSTICO**: a 23 saltos la misma pregunta responde casi siempre y
+ * falla de vez en cuando (el presupuesto de nodos se consume de forma no
+ * determinista al resolver la unión). Por eso se declara **22**, que es la
+ * profundidad que resuelve SIEMPRE, y no el primer valor que falló. Un caso
+ * de la suite apoyado en 23 habría sido flaky en el artefacto publicado —la
+ * misma lección que 3G · Y1—, y de hecho lo fue una vez antes de medirlo.
+ *
+ * **Y por eso la constante se clava con REPETICIONES, no con una tirada**
+ * (3b-4 · C4): el par de casos original —positivo en la cota, negativo en la
+ * cota + 2— sujetaba el intervalo [22, 23] y no el 22 (con la constante a 23
+ * la suite seguía verde 3 corridas de 3, tester Fase 3b · M12b). El caso que
+ * lo cierra hace **500 resoluciones por lado** (10 lotes de 50 con
+ * `authorizeMany`): en la cota tienen que resolver las 500, y un salto más
+ * tiene que fallar al menos una vez. Con la tasa de fallo más baja jamás
+ * medida (4 %) un verde falso es 0,96^500 ≈ 1e-9.
+ *
+ * Los «~23» que citaba el panel (riesgo S9) eran de un modelo MÁS SIMPLE y
+ * estaban sin medir sobre (c2).
+ *
+ * Pasado el techo el servidor responde 400 («resolution required too many
+ * rewrite rules») y el paquete lo propaga como 503, **nunca como un `false`**
+ * (invariante 5): es fail-closed, pero es un DoS al alcance de quien pueda
+ * crear sub-scopes anidados, y `database` no tiene ese techo — el mismo árbol
+ * es legal en un driver y una caída en el otro. Sube
+ * `OPENFGA_RESOLVE_NODE_LIMIT` en el servidor si tu árbol es más profundo.
+ */
+export declare const FACTS_MAX_RESOLVE_DEPTH = 22;
+/** Tope de checks por `batchCheck` en OpenFGA (el driver trocea en lotes de este tamaño). */
+export declare const FGA_MAX_BATCH_CHECK = 50;
+/** Fracción del techo a partir de la cual se avisa (cruce 9: "aviso al 80 %"). */
+export declare const FACTS_MODEL_WARN_RATIO = 0.8;
+/** El tipo FGA cuyo id es el uuid del rol del catálogo. */
+export declare const FACTS_ROLE_TYPE = "role";
+/** Prefijo de la familia que materializa el catálogo (`role:<uuid>#permits_<P>`). */
+export declare const FACTS_PERMITS_PREFIX = "permits_";
+/**
+ * **La relación de (c2r)**: «desde este scope se llega a la raíz `app`»
+ * (3b-2i). Es una relación PROPIA del modelo, como `parent` o `ancestor`, y
+ * la única que se escribe una vez por STORE en vez de por hecho: el marcador
+ * de raíz (`factsRootTuples`).
+ */
+export declare const FACTS_ROOTED_RELATION = "rooted";
+/** Las CUATRO familias de (c2) para un permiso: `<P>`, `can_<P>`, `denied_<P>`, `permits_<P>`. */
+export interface FactsRelations {
+    permission: string;
+    /** `<P>` en `role_binding` y en `scope`. */
+    base: string;
+    /** `can_<P>`: lo que responde `authorize`. */
+    can: string;
+    /** `denied_<P>`: el deny explícito, heredado hacia abajo. */
+    denied: string;
+    /** `permits_<P>`: la proyección del catálogo (qué permisos vincula un rol). */
+    permits: string;
+}
+/** Las cuatro relaciones que un permiso genera, sin validar nada. */
+export declare function factsRelationsOf(permission: string): FactsRelations;
+/**
+ * **S4, bloqueante del juez.** Con CUATRO familias, dos permisos distintos
+ * pueden generar el mismo nombre de relación: `can_x` sale del permiso
+ * `can_x` y también del permiso `x`. El generador de antes las colapsaba en
+ * silencio y el modelo publicado anulaba un deny (el auditor lo reprodujo de
+ * punta a punta con `allowed: true`). Se detecta con un `Map` nombre→origen
+ * y se LANZA: nunca se escribe un modelo ambiguo.
+ *
+ * Es un espacio de nombres plano a propósito (aunque las relaciones vivan en
+ * tipos distintos): las familias tienen prefijos disjuntos, así que dos
+ * permisos legales jamás chocan aquí, y lo que sí choca es exactamente lo que
+ * `RESERVED_SLUGS`/`RESERVED_SLUG_PREFIXES` prohíben en el núcleo.
+ */
+export declare function factsRelationMap(permissions: readonly string[]): FactsRelations[];
+/**
+ * El authorization model del modo `facts` en el JSON del API de FGA. El mismo
+ * `holderTypes` y el mismo conjunto de permisos deben usarse al construir el
+ * driver: si difieren, los checks no encuentran las tuplas y `permits_<P>` de
+ * un permiso que el modelo no declara es un 400 del servidor.
+ *
+ * `permissions` son los slugs del CATÁLOGO (`authz_permissions`), que sigue
+ * siendo propiedad local: esto es una proyección derivada y reconstruible, no
+ * una fuente de verdad (regla del catálogo reescrita, cruce 7 del panel).
+ */
+export declare function openFgaFactsModel(holderTypeMap: HolderTypeMap, permissions: readonly string[], relationsConfig?: FactsRelationsConfig): any;
+/**
+ * Los bytes que el servidor contará para este modelo. Incluye el id (un ULID
+ * de 26 caracteres) porque el servidor lo asigna ANTES de medir: sin él la
+ * cuenta se queda 28 bytes corta.
+ */
+export declare function factsModelBytes(model: any): number;
+/**
+ * ¿Este catálogo se puede PUBLICAR como modelo `facts`? Se responde ANTES de
+ * escribir nada (`syncAuthzCatalog`), no en runtime: un catálogo que rebasa
+ * el techo del servidor entra en la base y deja el store sin poder
+ * regenerarse, que es la avería silenciosa.
+ *
+ * Pasado el 80 % del techo se AVISA por el canal de log del driver: quien
+ * declara permisos a ese ritmo tiene que enterarse antes de chocar, no el día
+ * del deploy que no arranca.
+ */
+export declare function assertFactsModelPublishable(holderTypeMap: HolderTypeMap, permissions: readonly string[], warn?: (message: string) => void, relationsConfig?: FactsRelationsConfig): {
+    bytes: number;
+    permissions: number;
+};
+/** Cota de id de objeto (A4): lo que el store no podría leer de vuelta no se escribe. */
+export declare function assertFgaObjectId(kind: string, id: string): void;
+/** Una tupla de la proyección: `role:<uuid>#permits_<P>@<holder>:*`. */
+export interface FactsCatalogTuple {
+    user: string;
+    relation: string;
+    object: string;
+}
+/**
+ * Las tuplas que materializan los vínculos rol→permiso del catálogo. Una por
+ * (rol, permiso, holder): el comodín de USUARIO es lo que hace (c2) barato
+ * —quitar un permiso de un rol son `holders` deletes en un solo `Write`, no
+ * una escritura por scope—.
+ *
+ * NO es catálogo: es una proyección derivada, reconstruible desde `authz_*`,
+ * que ningún camino de lectura del driver consulta para responder qué
+ * permisos tiene un rol (cruce 7 del panel; A6).
+ */
+export declare function factsCatalogTuples(roles: readonly CatalogProjectionRole[], holderTypeMap: HolderTypeMap): FactsCatalogTuple[];
+/** Clave textual de una tupla de la proyección, para comparar conjuntos. */
+export declare function factsTupleId(tuple: FactsCatalogTuple): string;
+/** El tipo FGA cuyo id es la `scopeKey` del paquete (`app` o `<tipo>|<uuid>`). */
+export declare const FACTS_SCOPE_TYPE = "scope";
+/** La arista del árbol: `scope:<hijo>#parent@scope:<padre>` (una por nodo). */
+export declare const FACTS_PARENT_RELATION = "parent";
+/** Una tupla del modo `facts` (misma forma que la del SDK, sin depender de él). */
+export interface FactsTuple {
+    user: string;
+    relation: string;
+    object: string;
+}
+/**
+ * El objeto FGA de un scope. La `scopeKey` es la MISMA codificación que ya
+ * usan los ids de binding (`identity.ts`), así que el árbol y los hechos
+ * hablan del mismo nodo con la misma cadena; el scope tiene que venir ya
+ * CANÓNICO (invariante 17: `chain[0]`), o se abriría una segunda rama para
+ * el alias del uuid.
+ */
+export declare function factsScopeObject(key: string): string;
+/**
+ * La arista `hijo → padre` del árbol. Una sola tupla por nodo (c2): mover un
+ * subárbol es reescribir ESA tupla, no recorrer nada — por eso el `moved`
+ * del cruce 8 cabe en un `Write` atómico.
+ */
+export declare function factsParentTuple(childKey: string, parentKey: string): FactsTuple;
+/**
+ * **El marcador de raíz** (3b-2i): `scope:app#rooted@<holder>:*`, una tupla
+ * por holder type en TODO el store — cero por scope.
+ *
+ * Es lo que hace verdadera la premisa de `rooted`: solo la raíz la tiene
+ * directa. `attached`/`moved`/`detached` no escriben ni una tupla más por su
+ * culpa (la outbox y el relay no llevan entradas nuevas), y a cambio lo
+ * escribe quien toca el CATÁLOGO —`projectCatalog`, en cada
+ * `syncAuthzCatalog` con proyección, de forma idempotente— porque ése es el
+ * momento en el que un holderType nuevo del config aparece.
+ *
+ * ⚠️ **Modo de fallo que hay que conocer: sin marcador, todo el store
+ * DENIEGA** (medido: `can_<P>` es `false` en `app`, en la org y en la unit).
+ * Es fail-closed —no es una fuga— y ruidoso a la primera pregunta, pero es
+ * una caída total silenciosa desde el punto de vista del log. Por eso el
+ * marcador se repone en cada sync y `authz:reconcile` (3b-3) tiene que
+ * reportarlo como deriva cuando falte.
+ */
+export declare function factsRootTuples(holderTypeMap: HolderTypeMap): FactsTuple[];
+/** El tipo FGA de una asignación: `role_binding:<scopeKey>|<roleUuid>`. */
+export declare const FACTS_BINDING_TYPE = "role_binding";
+/** `scope:<key>#binding@role_binding:…` — qué asignaciones cuelgan del scope. */
+export declare const FACTS_BINDING_RELATION = "binding";
+/** `role_binding:…#role@role:<roleUuid>` — qué rol vincula la asignación. */
+export declare const FACTS_ROLE_RELATION = "role";
+/** `role_binding:…#assignee@<holder>` — quién está asignado (con la caducidad). */
+export declare const FACTS_ASSIGNEE_RELATION = "assignee";
+/**
+ * El objeto de una asignación. Mismo id que en el modo `resolver`
+ * (`<scopeKey>|<roleUuid>`, 3A · A1: uuid del catálogo, nunca el slug), y por
+ * eso el cambio de modelo no renombra un solo binding: lo que (c2) añade son
+ * las DOS aristas de abajo, no una identidad nueva.
+ */
+export declare function factsBindingObject(scopeKeyValue: string, roleUuid: string): string;
+/**
+ * Las dos aristas que hacen ALCANZABLE una asignación en (c2): el binding
+ * cuelga del scope (`scope#binding`) y apunta a su rol (`role_binding#role`).
+ * Sin ellas el `assignee` es un hecho huérfano que `can_<P>` no ve — es la
+ * diferencia entre el modo `resolver` (donde la cadena la expande el paquete
+ * y basta con el `assignee`) y el modo `facts`.
+ *
+ * Son ESTRUCTURA, no concesión: no llevan caducidad y no dicen quién está
+ * asignado. Por eso `revoke` no las borra (otro holder puede seguir usando el
+ * mismo binding) y re-escribirlas es idempotente.
+ */
+export declare function factsBindingTuples(scopeKeyValue: string, roleUuid: string): FactsTuple[];
+/**
+ * La arista `scope:<key>#binding@role_binding:<key>|<rol>` sola, que es la
+ * que hace ALCANZABLE la asignación desde el scope.
+ *
+ * **Qué significa** (3b-2g · R1, decisión del dueño del 2026-08-30 (2)): desde
+ * el barrido, «**el rol es visible aquí**» — no «esta asignación existe». El
+ * hecho de la asignación es el `assignee`, que el barrido no toca; esta arista
+ * la escribe y la borra el paquete cada vez que la REGLA DE VISIBILIDAD cambia
+ * de respuesta para ese `(rol, scope)`: el árbol se mueve y el owner deja de
+ * estar en la cadena (`scopes.moved`, 3b-2e · E1) o el catálogo cambia el
+ * NIVEL declarado del rol (`projectCatalogRole`, 3b-2g · R1). Es lo que en
+ * `database` se evalúa en cada pregunta con `declaredRoleAt`, y aquí hay que
+ * materializar porque el modelo (c2) no lleva ni el owner ni el nivel.
+ */
+export declare function factsScopeBindingTuple(scopeKeyValue: string, roleUuid: string): FactsTuple;
+/**
+ * El deny explícito de (c2): `scope:<key>#denied_<P>@<holder>`. Ya no existe
+ * el tipo `deny_binding` — el deny es una relación DEL SCOPE, que es lo que
+ * permite que `denied_<P>` se herede hacia abajo por `parent` dentro del
+ * propio modelo y que `can_<P>` sea la resta (invariante 2) en un solo Check.
+ */
+export declare function factsDenyTuple(scopeKeyValue: string, permission: string, user: string): FactsTuple;
+/** Prefijo de la familia del deny (`denied_<P>`), para leer denies por relación. */
+export declare const FACTS_DENIED_PREFIX = "denied_";
+/**
+ * El tipo `group` de las relaciones ReBAC: el portador de los usersets
+ * (`group:eng#member`) que hace que un `viewer` valga para todos los miembros
+ * de un grupo. Lo emite SIEMPRE el generador de relaciones (no lo declara el
+ * consumidor), y por eso es un tipo RESERVADO igual que los de `facts`.
+ */
+export declare const FACTS_GROUP_TYPE = "group";
+/** La relación de pertenencia del grupo: `group:<id>#member@<holder>` y `@group:<otro>#member`. */
+export declare const FACTS_GROUP_MEMBER_RELATION = "member";
+/**
+ * Los tipos reservados del modelo compartido (⚪4). La fuente única está en
+ * `src/identity.ts` (la gramática compartida), porque también la consume
+ * `defineRelationsConfig` en `src/relations/`, que la frontera de pureza
+ * mantiene disjunto de `drivers/`. Se re-exporta aquí para no romper el
+ * subpath `/openfga` (`src/openfga.ts` la publica desde este módulo).
+ */
+export { RESERVED_FACTS_TYPES } from '../identity.js';
+/** Una relación de un tipo de objeto de relaciones (`document#viewer`). */
+export interface RelationObjectRelation {
+    /** El nombre de la relación (`owner`, `editor`, `viewer`). */
+    name: string;
+    /**
+     * Otras relaciones del MISMO tipo que ésta INCLUYE (`viewer or editor`): un
+     * `relate(u, editor, doc)` concede también `viewer`. Un nivel, SIN `from` en
+     * v1 (la herencia cross-objeto `viewer from parent` metería un TTU entre
+     * tipos y habría que re-medir profundidad — diferido a 2.6+).
+     */
+    includes?: readonly string[];
+}
+/** Un tipo de objeto de relaciones (`document`, `folder`, `space`…). */
+export interface RelationObjectType {
+    /** El tipo FGA del objeto. */
+    type: string;
+    /** Sus relaciones, en orden de declaración. */
+    relations: readonly RelationObjectRelation[];
+}
+/**
+ * La config de relaciones que el generador FUSIONA en el modelo `facts`
+ * (Fase 4-1). Es la forma MÍNIMA que consume el generador; el puerto
+ * `RelationsDriver` y `defineRelationsConfig` completos son 4-2.
+ */
+export interface FactsRelationsConfig {
+    /** Los tipos de objeto declarados por el consumidor. */
+    objectTypes: readonly RelationObjectType[];
+}
+/**
+ * **⚪4 + F-04, a nivel de MODELO.** Antes de emitir un solo `type_definition`
+ * de relaciones, el generador comprueba que la config es FUSIONABLE en el
+ * modelo compartido:
+ *
+ * - ningún `objectType` duplica un tipo reservado de `facts`/`group` ni un
+ *   holder type (⚪4 · tipo), ni se repite;
+ * - ningún NOMBRE de relación (deduplicado entre tipos: `document#viewer` y
+ *   `folder#viewer` son la misma relación lógica y se permiten) empieza por
+ *   una familia derivada (`can_`/`denied_`/`permits_`) ni coincide con una
+ *   relación PROPIA del modelo (`parent`/`rooted`/`assignee`… — ⚪4 · familia)
+ *   ni con un permiso del catálogo (F-04);
+ * - los `includes` refieren relaciones del MISMO tipo (un nivel).
+ *
+ * Lanza 422 `E_AUTHZ_RELATION_CONFIG` del PAQUETE (no el 400 opaco del
+ * servidor), nombrando qué choca con qué.
+ */
+export declare function assertRelationsConfigPublishable(permissionRelations: readonly FactsRelations[], config: FactsRelationsConfig, holderTypes: readonly string[]): void;
+/**
+ * Los `type_definitions` de relaciones que el generador AÑADE al modelo
+ * `facts`: el tipo `group` (usersets) + un tipo por objeto declarado. El
+ * literal medido contra el `:8101` está en la §1 del plan de la Fase 4.
+ *
+ * `group.member` admite holders directos y `group#member` (grupos anidan un
+ * nivel); cada relación de objeto admite `[holders, group#member]` directos y,
+ * si declara `includes`, se une a las relaciones incluidas del mismo tipo
+ * (`viewer or editor`), sin una sola tupla extra.
+ */
+export declare function factsRelationTypeDefinitions(permissionRelations: readonly FactsRelations[], config: FactsRelationsConfig, holderTypes: readonly string[]): any[];
+//# sourceMappingURL=openfga_facts.d.ts.map

package/build/src/drivers/openfga_facts.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"openfga_facts.d.ts","sourceRoot":"","sources":["../../../src/drivers/openfga_facts.ts"],"names":[],"mappings":"AASA,OAAO,KAAK,EAAE,qBAAqB,EAAE,aAAa,EAAE,MAAM,aAAa,CAAA;AA8DvE;;;;;;;;GAQG;AACH,wBAAgB,iBAAiB,CAAC,WAAW,EAAE,aAAa,GAAG,IAAI,CAwBlE;AAID;;;;;;;GAOG;AACH,eAAO,MAAM,qBAAqB,KAAK,CAAA;AAEvC;;;;;GAKG;AACH,eAAO,MAAM,iBAAiB,MAAM,CAAA;AAEpC;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,eAAO,MAAM,qBAAqB,SAAU,CAAA;AAE5C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,eAAO,MAAM,uBAAuB,KAAK,CAAA;AAEzC,6FAA6F;AAC7F,eAAO,MAAM,mBAAmB,KAAK,CAAA;AAErC,kFAAkF;AAClF,eAAO,MAAM,sBAAsB,MAAM,CAAA;AAEzC,2DAA2D;AAC3D,eAAO,MAAM,eAAe,SAAS,CAAA;AAErC,qFAAqF;AACrF,eAAO,MAAM,oBAAoB,aAAa,CAAA;AAE9C;;;;;GAKG;AACH,eAAO,MAAM,qBAAqB,WAAW,CAAA;AAoB7C,kGAAkG;AAClG,MAAM,WAAW,cAAc;IAC7B,UAAU,EAAE,MAAM,CAAA;IAClB,4CAA4C;IAC5C,IAAI,EAAE,MAAM,CAAA;IACZ,8CAA8C;IAC9C,GAAG,EAAE,MAAM,CAAA;IACX,6DAA6D;IAC7D,MAAM,EAAE,MAAM,CAAA;IACd,+EAA+E;IAC/E,OAAO,EAAE,MAAM,CAAA;CAChB;AAED,qEAAqE;AACrE,wBAAgB,gBAAgB,CAAC,UAAU,EAAE,MAAM,GAAG,cAAc,CASnE;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,gBAAgB,CAAC,WAAW,EAAE,SAAS,MAAM,EAAE,GAAG,cAAc,EAAE,CA6BjF;AAUD;;;;;;;;;GASG;AACH,wBAAgB,iBAAiB,CAC/B,aAAa,EAAE,aAAa,EAC5B,WAAW,EAAE,SAAS,MAAM,EAAE,EAC9B,eAAe,CAAC,EAAE,oBAAoB,GACrC,GAAG,CAyGL;AAqED;;;;GAIG;AACH,wBAAgB,eAAe,CAAC,KAAK,EAAE,GAAG,GAAG,MAAM,CA6BlD;AAED;;;;;;;;;GASG;AACH,wBAAgB,2BAA2B,CACzC,aAAa,EAAE,aAAa,EAC5B,WAAW,EAAE,SAAS,MAAM,EAAE,EAC9B,IAAI,CAAC,EAAE,CAAC,OAAO,EAAE,MAAM,KAAK,IAAI,EAChC,eAAe,CAAC,EAAE,oBAAoB,GACrC;IAAE,KAAK,EAAE,MAAM,CAAC;IAAC,WAAW,EAAE,MAAM,CAAA;CAAE,CAuBxC;AAED,yFAAyF;AACzF,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,EAAE,MAAM,GAAG,IAAI,CAOhE;AAID,wEAAwE;AACxE,MAAM,WAAW,iBAAiB;IAChC,IAAI,EAAE,MAAM,CAAA;IACZ,QAAQ,EAAE,MAAM,CAAA;IAChB,MAAM,EAAE,MAAM,CAAA;CACf;AAED;;;;;;;;;GASG;AACH,wBAAgB,kBAAkB,CAChC,KAAK,EAAE,SAAS,qBAAqB,EAAE,EACvC,aAAa,EAAE,aAAa,GAC3B,iBAAiB,EAAE,CAerB;AAED,4EAA4E;AAC5E,wBAAgB,YAAY,CAAC,KAAK,EAAE,iBAAiB,GAAG,MAAM,CAE7D;AAID,kFAAkF;AAClF,eAAO,MAAM,gBAAgB,UAAU,CAAA;AAEvC,+EAA+E;AAC/E,eAAO,MAAM,qBAAqB,WAAW,CAAA;AAE7C,mFAAmF;AACnF,MAAM,WAAW,UAAU;IACzB,IAAI,EAAE,MAAM,CAAA;IACZ,QAAQ,EAAE,MAAM,CAAA;IAChB,MAAM,EAAE,MAAM,CAAA;CACf;AAED;;;;;;GAMG;AACH,wBAAgB,gBAAgB,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CAIpD;AAED;;;;GAIG;AACH,wBAAgB,gBAAgB,CAAC,QAAQ,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,UAAU,CAMhF;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,eAAe,CAAC,aAAa,EAAE,aAAa,GAAG,UAAU,EAAE,CAO1E;AAID,2EAA2E;AAC3E,eAAO,MAAM,kBAAkB,iBAAiB,CAAA;AAEhD,iFAAiF;AACjF,eAAO,MAAM,sBAAsB,YAAY,CAAA;AAE/C,6EAA6E;AAC7E,eAAO,MAAM,mBAAmB,SAAS,CAAA;AAEzC,mFAAmF;AACnF,eAAO,MAAM,uBAAuB,aAAa,CAAA;AAEjD;;;;;GAKG;AACH,wBAAgB,kBAAkB,CAAC,aAAa,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,MAAM,CAIlF;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,kBAAkB,CAAC,aAAa,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,UAAU,EAAE,CAQxF;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,sBAAsB,CAAC,aAAa,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,UAAU,CAM1F;AAED;;;;;GAKG;AACH,wBAAgB,cAAc,CAAC,aAAa,EAAE,MAAM,EAAE,UAAU,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,GAAG,UAAU,CAMlG;AAED,oFAAoF;AACpF,eAAO,MAAM,mBAAmB,YAAY,CAAA;AAI5C;;;;;GAKG;AACH,eAAO,MAAM,gBAAgB,UAAU,CAAA;AAEvC,mGAAmG;AACnG,eAAO,MAAM,2BAA2B,WAAW,CAAA;AAEnD;;;;;;GAMG;AACH,OAAO,EAAE,oBAAoB,EAAE,MAAM,gBAAgB,CAAA;AAErD,2EAA2E;AAC3E,MAAM,WAAW,sBAAsB;IACrC,8DAA8D;IAC9D,IAAI,EAAE,MAAM,CAAA;IACZ;;;;;OAKG;IACH,QAAQ,CAAC,EAAE,SAAS,MAAM,EAAE,CAAA;CAC7B;AAED,wEAAwE;AACxE,MAAM,WAAW,kBAAkB;IACjC,8BAA8B;IAC9B,IAAI,EAAE,MAAM,CAAA;IACZ,+CAA+C;IAC/C,SAAS,EAAE,SAAS,sBAAsB,EAAE,CAAA;CAC7C;AAED;;;;GAIG;AACH,MAAM,WAAW,oBAAoB;IACnC,wDAAwD;IACxD,WAAW,EAAE,SAAS,kBAAkB,EAAE,CAAA;CAC3C;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,gCAAgC,CAC9C,mBAAmB,EAAE,SAAS,cAAc,EAAE,EAC9C,MAAM,EAAE,oBAAoB,EAC5B,WAAW,EAAE,SAAS,MAAM,EAAE,GAC7B,IAAI,CAmFN;AAED;;;;;;;;;GASG;AACH,wBAAgB,4BAA4B,CAC1C,mBAAmB,EAAE,SAAS,cAAc,EAAE,EAC9C,MAAM,EAAE,oBAAoB,EAC5B,WAAW,EAAE,SAAS,MAAM,EAAE,GAC7B,GAAG,EAAE,CA+BP"}