@nimbus-sh/fabric 0.1.0

package/dist/process-fabric.js

@@ -0,0 +1,388 @@
+/**
+ * process-fabric.ts — the resident-process scheduler, and the process half of
+ * the substrate it runs on.
+ *
+ * Every long-lived process Nimbus runs — node servers, python/ruby socket
+ * servers, an agent TUI and its headless server — runs as a **DO Facet**:
+ * a named child actor whose class comes from a dynamic worker, opened by
+ * `openResidentFacet` in `workerd-facet-host.ts`.
+ *
+ *   ctx.facets.get(`proc-${pid}`, () => ({
+ *     class: env.LOADER.get(workerKey, buildConfig)
+ *              .getDurableObjectClass('NimbusProcess'),
+ *   }))
+ *
+ * There is ONE process implementation. What varies is WHOSE `ctx` and `env`
+ * that call runs against — the user's own session DO, or a sibling DO acting
+ * as a host — and that choice is a single deployment-wide config value read in
+ * `process-host.ts`. Nothing here, and nothing above here, branches on
+ * which program is running: no spawn site picks its own substrate, and no
+ * program name, mode or payload size reaches the selection.
+ *
+ * What each substrate costs, all of it measured on the production
+ * compatibility shape (see `process-host.ts` for the operator-facing
+ * version of this table):
+ *
+ *   facet  — spawn 8-16 ms warm. Memory independent: its OWN ~208 MiB
+ *            envelope, identical whether the coordinator holds 0 or 128 MiB,
+ *            with 1,664 MiB live across 8 facets + parent. CPU SHARED with
+ *            its siblings, because facets are separate isolates inside one
+ *            actor thread: awaiting I/O yields that thread completely (a
+ *            sibling's RPC latency while a facet parks on a socket, on stdin
+ *            or on an outbound call is indistinguishable from idle) but
+ *            sustained CPU stalls every sibling for its full duration —
+ *            a python HTTP server at 32-way saturation held siblings under
+ *            1.06 s (p50 231 ms), an attached full-screen TUI held them at the
+ *            77 ms idle baseline, and a deliberate 9,956 ms CPU burn stalled
+ *            them for 9,966 ms.
+ *   peer   — spawn 242-359 ms, because every spawn pays a DO create plus a
+ *            SQLite open. Memory AND CPU both independent: the process runs
+ *            in a different workerd process, verified per placement rather
+ *            than assumed (see `_place` in `process-host.ts`).
+ *
+ * Both give the process its own SQLite. Neither changes what the process is:
+ * the runner, the boot spec, the class name, the writer handshake and the
+ * lifecycle contract are the same code either way.
+ *
+ * The facet's SUPERVISOR binding is minted for the COORDINATOR's doId, so
+ * every syscall — VFS read/write, stdout/stderr frames, stdin pump,
+ * registerPort, loopback HTTP — lands on the user's session DO wherever the
+ * process runs. Because that binding is minted by an actor rather than by a
+ * stateless entrypoint, it lives as long as the process does; nothing has to
+ * hold a call open to keep it alive.
+ *
+ * Boot specs
+ * ──────────
+ * A resident process boots from one of two specs, and in both cases the module
+ * map is assembled LAZILY inside the loader's cache-miss callback — so the
+ * artifact sources are materialized only when the facet actually starts, and
+ * only for as long as the load takes:
+ *
+ *   staged — an embedder-defined stage spec; the registered
+ *            {@link StagedBootAssembler} fetches the artifact sources
+ *            (Nimbus's staged artifacts come from ASSETS).
+ *   code   — a generated module map (node / python / ruby runners). Fixed-size
+ *            module text rides inline; anything sized by the user's disk is
+ *            named BY VFS PATH and read through the injected disk reader. A
+ *            ruby server's `ruby+stdlib.wasm` alone is 34.3 MiB and a node
+ *            facet's disk snapshot reached 44 MB for pi.
+ *
+ * By-path is what lets a boot spec reach EITHER substrate. Inline, pi's node
+ * snapshot serialized to 44,252,709 bytes and died at workerd's 32 MiB RPC
+ * ceiling the moment it had to cross to a peer; named by path it sends zero
+ * bytes, and the host reads them off the coordinator's own disk through the
+ * `ResidentDiskReader` it was given.
+ */
+import { z } from 'zod/v4';
+/**
+ * The class every generated resident runner exports. One name for every
+ * runtime: the fabric names it unconditionally, so nothing about which program
+ * is running reaches this module.
+ */
+export const RESIDENT_PROCESS_CLASS = 'NimbusProcess';
+/**
+ * A generated module map. Only bounded, fixed-size module text rides inline;
+ * anything whose size is a function of the user's disk is named by VFS path
+ * and read when the facet loads, so the bytes are transient rather than
+ * resident in the coordinator's heap.
+ */
+export const ResidentCodeSpecSchema = z.object({
+    compatibilityDate: z.string().min(1),
+    compatibilityFlags: z.array(z.string()),
+    mainModule: z.string().min(1),
+    /**
+     * Inline modules: fixed-size generated source, plus small wasm sidecars that
+     * come from the worker's own ASSETS rather than the user's disk.
+     */
+    modules: z.record(z.string(), z.union([z.string(), z.object({ wasm: z.instanceof(ArrayBuffer) })])),
+    /**
+     * Module name → absolute VFS path of a wasm image to materialize at load.
+     * This is how the big user-installed runtimes travel: ruby's
+     * interpreter+stdlib image alone is 34.3 MiB.
+     */
+    vfsWasmModules: z.record(z.string(), z.string()).optional(),
+    /**
+     * Module name → absolute VFS path of a GENERATED module source, read as
+     * UTF-8 at load. The same by-path posture as `vfsWasmModules`, for module
+     * text whose size is a function of the user's disk.
+     *
+     * A node facet carries a snapshot of that disk, and it is the largest thing
+     * Nimbus generates: pi's is 3096 cells and inline it serialized to
+     * 44,252,709 bytes. That text cannot be rebuilt from the user's files at
+     * load time either — two thirds of the cells are esbuild ESM→CJS output, and
+     * the manifest and metadata members are walks of the tree rather than files
+     * in it. So the generator materializes its output in the content-addressed
+     * image store below and the spec names it.
+     */
+    vfsTextModules: z.record(z.string(), z.string()).optional(),
+});
+/**
+ * The boot-spec union, with the staged arm's payload validated by the
+ * embedder's own stage schema. The fabric defines the SHAPE of the union —
+ * `staged` boots assemble through the registered {@link StagedBootAssembler},
+ * `code` boots through {@link residentLoaderConfig} — but what a stage IS
+ * belongs to whoever registered the assembler, so the schema is composed
+ * rather than fixed. The embedder parses with this at its RPC trust boundary;
+ * the assembler re-validates at use either way.
+ */
+export function residentBootSpecSchema(stageSchema) {
+    return z.discriminatedUnion('kind', [
+        z.object({ kind: z.literal('staged'), stage: stageSchema }),
+        z.object({ kind: z.literal('code'), code: ResidentCodeSpecSchema }),
+    ]);
+}
+let _stagedBootAssembler = null;
+/** Registered once at composition time, first-write-wins. */
+export function setStagedBootAssembler(assembler) {
+    if (_stagedBootAssembler)
+        return;
+    _stagedBootAssembler = assembler;
+}
+export function requireStagedBootAssembler() {
+    if (!_stagedBootAssembler) {
+        throw new Error('fabric: no staged-boot assembler registered; a \'staged\' boot spec '
+            + 'cannot be assembled without one (setStagedBootAssembler)');
+    }
+    return _stagedBootAssembler;
+}
+// ── Boot-image store ────────────────────────────────────────────────────────
+/**
+ * Where a generated module source is materialized so a boot spec can name it.
+ *
+ * Outside any user working tree on purpose. The passes that build a node
+ * facet's snapshot enumerate the process's cwd, so an image written under one
+ * would be swept into the next snapshot — and that snapshot is what produced
+ * the image, so each spawn would grow the thing it just wrote.
+ *
+ * Kernel-owned and world-readable: the generator writes as CRED_KERNEL, and
+ * every process reads through a supervisor binding that enforces its own
+ * credential. Mode 0644 is what makes the read succeed for any process by
+ * construction rather than by a privilege carve-out in the permission layer,
+ * and leaves the bytes beyond reach of the user whose program they encode.
+ */
+export const FACET_IMAGE_DIR = 'var/lib/nimbus/facet-images';
+/**
+ * An image is named by the SHA-256 of its own bytes, so its name IS its
+ * integrity check and a stale image is not something to invalidate but
+ * something that cannot be addressed: different generated text is a different
+ * path.
+ *
+ * What that actually dedups, measured on a deployed worker rather than
+ * assumed: a RESTART resolves to the image already there, because the fabric
+ * replays one unchanged boot spec. Two separate spawns of the same tool do
+ * NOT, whenever the generated text carries anything per-process: an
+ * attached-TTY spawn bakes `NIMBUS_CP_CHILD_PID` into `__NIMBUS_ARGS`, so `pi`
+ * twice wrote two images (2c3a90ad… then c5b74f1a…). A spawn with no attached
+ * TTY has no pid in its args and does dedup. Lifting argv/env/pid out of the
+ * generated text into `startArgs` would make every image per-PROGRAM and
+ * shareable across spawns and sessions; the sweep bounds the store either way.
+ */
+export async function facetImageDigest(source) {
+    const digest = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(source));
+    return Array.from(new Uint8Array(digest), (b) => b.toString(16).padStart(2, '0')).join('');
+}
+export function facetImagePath(digest) {
+    return `/${FACET_IMAGE_DIR}/${digest}.js`;
+}
+/**
+ * The digest an image path claims, for the reader's verify-on-read. Content
+ * addressing only holds if the bytes are checked against the name they were
+ * fetched under; without that a truncated or overwritten image boots as
+ * silently-wrong code, which in a facet surfaces as an unattributable
+ * "Cannot find module" a long way from the corruption.
+ */
+export function facetImagePathDigest(path) {
+    const match = /(?:^|\/)([0-9a-f]{64})\.js$/.exec(path);
+    return match ? match[1] : null;
+}
+/**
+ * Complete a resident-process module map: read every member the spec named by
+ * path, verifying each generated image against the digest its own path claims.
+ * Runs inside the loader's cache-miss callback, so the bytes exist only for
+ * the duration of the load.
+ */
+export async function residentLoaderConfig(spec, disk) {
+    const resolved = {};
+    for (const [moduleName, path] of Object.entries(spec.vfsWasmModules ?? {})) {
+        const bytes = await disk.readFile(path);
+        resolved[moduleName] = {
+            wasm: bytes.buffer.slice(bytes.byteOffset, bytes.byteOffset + bytes.byteLength),
+        };
+    }
+    for (const [moduleName, path] of Object.entries(spec.vfsTextModules ?? {})) {
+        resolved[moduleName] = await readFacetImage(disk, path);
+    }
+    return {
+        compatibilityDate: spec.compatibilityDate,
+        compatibilityFlags: spec.compatibilityFlags,
+        mainModule: spec.mainModule,
+        modules: { ...spec.modules, ...resolved },
+    };
+}
+/**
+ * Read one content-addressed facet image and verify it against the digest its
+ * path claims. Content addressing is only a guarantee if the bytes are checked
+ * against the name they arrived under: an image that was truncated, or
+ * replaced by something the generator never wrote, would otherwise be loaded
+ * as the program and fail somewhere inside it with no way back to the cause.
+ */
+async function readFacetImage(disk, path) {
+    const expected = facetImagePathDigest(path);
+    if (!expected) {
+        throw new Error(`Nimbus: '${path}' is not a content-addressed facet image path`);
+    }
+    const source = new TextDecoder().decode(await disk.readFile(path));
+    const actual = await facetImageDigest(source);
+    if (actual !== expected) {
+        throw new Error(`Nimbus: facet image '${path}' does not match its digest (read ${actual}); `
+            + 'the image store is corrupt and the process cannot boot from it');
+    }
+    return source;
+}
+// ── Handle ──────────────────────────────────────────────────────────────────
+/**
+ * Resource handle for one resident process — the whole surface the kernel
+ * above this module sees: `booted()` for the boot payload, `done` for death,
+ * `kill()` for teardown, `routeTarget` for inbound HTTP. Substrate-free: the
+ * kernel cannot tell from it where the process is running, and never asks.
+ *
+ * `done` settles when the process ends: for a `lifetime` runner that is its
+ * held-open startProcess settling (resolve on exit, reject on host death);
+ * for a `boot` runner it is the kill that releases the host.
+ *
+ * The handle is disposable so FacetManager's existing per-pid resource
+ * tracking tears a process down exactly the way it releases any other
+ * per-process resource.
+ */
+export class ResidentProcessHandle {
+    done;
+    /**
+     * Inbound-HTTP target for PortRegistry: the running facet's own stub. A
+     * facet is a child actor, so its stub stays usable in request contexts long
+     * after the one that created it — which is the whole reason a resident
+     * process can serve a port at all.
+     */
+    routeTarget;
+    #booted;
+    #kill;
+    #killed = false;
+    #describe;
+    constructor(init) {
+        this.done = init.done;
+        this.#booted = init.booted;
+        this.routeTarget = init.routeTarget;
+        this.#kill = init.kill;
+        this.#describe = init.describe;
+        // Symbol.dispose may be absent from older lib targets; wire defensively
+        // so disposeRpcResource() (which probes for it) finds the disposer.
+        const disposeSym = Symbol.dispose;
+        if (disposeSym) {
+            Object.defineProperty(this, disposeSym, { value: () => this.kill() });
+        }
+    }
+    /**
+     * The runner's startProcess payload. The runner is started as part of the
+     * spawn, so this is a handle on that one boot — awaiting it twice is safe
+     * and never re-starts anything. For a `lifetime` runner it settles at exit.
+     */
+    booted() {
+        return this.#booted();
+    }
+    get killed() {
+        return this.#killed;
+    }
+    /** Human-readable placement, for the NIMBUS_DEBUG process-log line. */
+    describePlacement() {
+        return this.#describe();
+    }
+    /** Idempotent: abort the facet and release its isolate. */
+    kill() {
+        if (this.#killed)
+            return;
+        this.#killed = true;
+        try {
+            this.#kill();
+        }
+        catch { /* best-effort teardown */ }
+    }
+}
+/** A promise that settles only when the process is killed. */
+function heldUntilKilled() {
+    let release = () => { };
+    const promise = new Promise((resolve) => { release = resolve; });
+    return { promise, release };
+}
+export class ProcessFabric {
+    host;
+    constructor(host) {
+        this.host = host;
+    }
+    /**
+     * Boot a resident process on this deployment's substrate and return its
+     * handle. Resolves once the process is up and its runner has been started;
+     * rejects on boot failure.
+     *
+     * There is no decision in here. The substrate was chosen once, for the
+     * deployment, and the only thing this method knows about it is the
+     * `ProcessHost` interface.
+     */
+    async startResidentProcess(spawn) {
+        // The facet-local append sequence starts at one when its module evaluates.
+        // Bind that sequence to this concrete incarnation, then retire it only
+        // after the host is released; a later incarnation must use a fresh one.
+        const writerId = crypto.randomUUID();
+        spawn.onWriterActivated(writerId);
+        let hosted;
+        try {
+            hosted = await this.host.open({
+                pid: spawn.pid,
+                workerKey: spawn.workerKey,
+                boot: spawn.boot,
+                writerId,
+                startArgs: spawn.startArgs,
+            });
+        }
+        catch (error) {
+            spawn.onWriterRetired(writerId);
+            throw error;
+        }
+        const held = heldUntilKilled();
+        // Runs at most once, however it is reached — the lifecycle ending, a kill,
+        // or both. Retiring the writer twice would revoke an identity a later
+        // incarnation had already been granted.
+        let releasing = null;
+        const release = () => {
+            if (!releasing) {
+                releasing = (async () => {
+                    try {
+                        await hosted.release();
+                    }
+                    finally {
+                        spawn.onWriterRetired(writerId);
+                    }
+                })();
+                releasing.catch(() => { });
+            }
+            return releasing;
+        };
+        // `lifetime`: the runner's startProcess IS the process, so its settlement
+        // is the lifecycle — a host that dies under it rejects `started`.
+        // `boot`: the runner returns once it is up and the process stays resident
+        // on its host, so residency ends at a kill — or at the host dying, which
+        // is the same thing happening to the process without anyone asking for it.
+        const done = (spawn.startContract === 'lifetime'
+            ? hosted.started.then(() => undefined)
+            : hosted.started.then(() => Promise.race([held.promise, hosted.lost]))).finally(() => release());
+        done.catch(() => { });
+        return new ResidentProcessHandle({
+            done,
+            booted: () => hosted.started,
+            routeTarget: {
+                handleHttpRequest: (request) => hosted.handleHttpRequest(request),
+                handleWebSocketRequest: (request) => hosted.handleWebSocketRequest(request),
+            },
+            kill: () => { held.release(); void release(); },
+            describe: () => hosted.describe(),
+        });
+    }
+}

package/dist/process-host.d.ts

@@ -0,0 +1,132 @@
+/**
+ * process-host.ts — the two substrates a resident process can run on, and the
+ * one value that picks between them.
+ *
+ * `process-fabric.ts` owns what a resident process IS. This module
+ * owns only where it lives, behind `ProcessHost`:
+ *
+ *   facet — the process is a named child actor of the user's own session DO.
+ *   peer  — the process is a named child actor of a SIBLING session DO, and
+ *           the coordinator reaches it over one held-open RPC.
+ *
+ * Both call the same `openResidentFacet`. The peer leg is not a second process
+ * implementation; it is the same call made on a different actor, which is why
+ * the runner, the boot spec, the class name, the writer handshake, the start
+ * contract and the lifecycle are shared code rather than parallel paths.
+ *
+ * Choosing between them
+ * ─────────────────────
+ * One value for the whole deployment, resolved by the embedder's config seam
+ * (Nimbus reads `NIMBUS_PROCESS_HOST` in the worker's own selector) and
+ * handed to `createProcessHost`. No spawn site chooses; no program name, mode
+ * or payload size reaches the choice. If a decision about a particular
+ * process ever appears here, the heavy/light classifier has grown back and
+ * should be deleted again.
+ *
+ *   |          | spawn      | memory      | CPU        | SQLite |
+ *   |----------|------------|-------------|------------|--------|
+ *   | facet    | 8-16 ms    | independent | SHARED     | own    |
+ *   | peer     | 242-359 ms | independent | independent| own    |
+ *
+ * Facet CPU is shared because facets are separate isolates inside ONE actor
+ * thread: awaiting I/O yields it completely (measured 0 ms of sibling impact),
+ * but a non-yielding loop stalls every sibling for its full duration
+ * (measured 6,852 ms). A peer pays ~20x the spawn cost to buy that back.
+ *
+ * What the peer leg has to do differently, and why none of it reaches the
+ * process
+ * ────────────────────────────────────────────────────────────────────────
+ *   payloads — a whole structured-clone RPC value is capped at 32 MiB, and
+ *              pi's node snapshot alone serializes to 44,252,709 bytes. Boot
+ *              specs name their large members BY PATH, so what crosses is a
+ *              path and the host reads the bytes off the coordinator's disk in
+ *              4 MiB ranges through the supervisor. Nothing large is ever an
+ *              RPC argument, so nothing has to be streamed or replayed.
+ *   requests — workerd refuses to transfer an object owned by a
+ *              dynamically-loaded worker across a sibling-DO hop, so a request
+ *              travels to the peer as PARTS and the response comes back as
+ *              parts, both with plain `ReadableStream` bodies that RPC carries
+ *              with flow control. A live SSE body still streams; nothing is
+ *              buffered.
+ *   liveness — the host leg is held open for the process's whole life, which
+ *              is also what keeps the hosting DO resident. A peer therefore
+ *              never outlives its coordinator: the coordinator dying cancels
+ *              the inbound call and the facet dies with it. Nothing in this
+ *              fabric arms an alarm, on either substrate.
+ *
+ * WebSockets are the one thing on that list the RPC path cannot carry at all.
+ * A 101 Response owns a live socket, and RPC's Request/Response transport
+ * reconstructs a value rather than handing the socket over, so an upgrade
+ * stays on FETCH semantics for every hop: a facet is fetched directly, and a
+ * peer is fetched as a service binding which then fetches its hosted facet.
+ * Two headers carry what the RPC arguments would have — see
+ * {@link HOSTED_WEBSOCKET_KEY_HEADER} — and a per-process capability makes
+ * that pair unforgeable by anything that did not open the process.
+ */
+import { type ProcessHost, type ResidentDiskReader } from './process-fabric.js';
+/** The substrates this deployment can be configured for. */
+export type ProcessHostMode = 'facet' | 'peer';
+/**
+ * The substrate for this deployment, resolved once. The mode arrives already
+ * decided — the embedder owns the config var that picks it, and refuses an
+ * unrecognized value there rather than defaulting, because a typo that
+ * silently kept the old substrate would make an operator's comparison a lie.
+ * `disk` is the coordinator's own filesystem reader; the peer host does not
+ * take it, because a peer reads the same disk through the supervisor instead.
+ */
+export declare function createProcessHost(mode: ProcessHostMode, ctx: DurableObjectState, env: unknown, disk: () => ResidentDiskReader): ProcessHost;
+export declare function isolateToken(): string;
+/** Options the coordinator hands a hosting peer. */
+export interface HostProcessOpts {
+    coordinatorDoId: string;
+    pid: number;
+    writerId: string;
+    workerKey: string;
+    /** Unforgeable capability for the fetch-semantic WebSocket hop. */
+    webSocketCapability: string;
+    startArgs?: unknown;
+}
+/**
+ * Inbound HTTP for a peer-hosted process travels as PARTS, not as a
+ * Request/Response pair: workerd refuses to transfer an object owned by a
+ * dynamically-loaded worker across a sibling-DO hop. Bodies are plain
+ * ReadableStreams, which RPC carries with flow control, so nothing is buffered
+ * and a live SSE body still streams.
+ */
+export interface HostedHttpRequest {
+    method: string;
+    url: string;
+    headers: [string, string][];
+    body: ReadableStream | null;
+}
+export interface HostedHttpResponse {
+    status: number;
+    statusText: string;
+    headers: [string, string][];
+    body: ReadableStream | null;
+}
+/**
+ * Which hosted process a fetched upgrade is for. An upgrade cannot travel as
+ * RPC arguments, so the two values `_rpcRouteHostedHttp` would have taken ride
+ * as headers on the peer fetch instead.
+ *
+ * The key alone is guessable from a pid, so it is not enough on its own; the
+ * capability is minted per `open()` and known only to the coordinator that
+ * opened the process and the peer that hosts it. The receiving session strips
+ * both before the request reaches the process.
+ */
+export declare const HOSTED_WEBSOCKET_KEY_HEADER = "x-nimbus-hosted-websocket";
+export declare const HOSTED_WEBSOCKET_CAPABILITY_HEADER = "x-nimbus-hosted-websocket-capability";
+/**
+ * Headers as pairs, with every `Set-Cookie` kept separate.
+ *
+ * Iterating a `Headers` combines same-named fields into one comma-joined
+ * value, and for `Set-Cookie` that is not reversible — `append` cannot split
+ * `a=1; Path=/, b=2; Path=/` back into two cookies, and a browser reading the
+ * merged form sets one malformed cookie instead of two. Every other field
+ * combines by comma legally, so only this one needs the separate accessor.
+ * A user's server setting two cookies must not depend on which substrate its
+ * process happened to run on.
+ */
+export declare function headerPairs(headers: Headers): [string, string][];
+//# sourceMappingURL=process-host.d.ts.map

package/dist/process-host.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"process-host.d.ts","sourceRoot":"","sources":["../src/process-host.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AAKH,OAAO,EAGL,KAAK,WAAW,EAIhB,KAAK,kBAAkB,EAExB,MAAM,qBAAqB,CAAC;AAU7B,4DAA4D;AAC5D,MAAM,MAAM,eAAe,GAAG,OAAO,GAAG,MAAM,CAAC;AAE/C;;;;;;;GAOG;AACH,wBAAgB,iBAAiB,CAC/B,IAAI,EAAE,eAAe,EACrB,GAAG,EAAE,kBAAkB,EACvB,GAAG,EAAE,OAAO,EACZ,IAAI,EAAE,MAAM,kBAAkB,GAC7B,WAAW,CAIb;AAgFD,wBAAgB,YAAY,IAAI,MAAM,CAGrC;AAED,oDAAoD;AACpD,MAAM,WAAW,eAAe;IAC9B,eAAe,EAAE,MAAM,CAAC;IACxB,GAAG,EAAE,MAAM,CAAC;IACZ,QAAQ,EAAE,MAAM,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;IAClB,mEAAmE;IACnE,mBAAmB,EAAE,MAAM,CAAC;IAC5B,SAAS,CAAC,EAAE,OAAO,CAAC;CACrB;AAED;;;;;;GAMG;AACH,MAAM,WAAW,iBAAiB;IAChC,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,EAAE,MAAM,CAAC;IACZ,OAAO,EAAE,CAAC,MAAM,EAAE,MAAM,CAAC,EAAE,CAAC;IAC5B,IAAI,EAAE,cAAc,GAAG,IAAI,CAAC;CAC7B;AAED,MAAM,WAAW,kBAAkB;IACjC,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,OAAO,EAAE,CAAC,MAAM,EAAE,MAAM,CAAC,EAAE,CAAC;IAC5B,IAAI,EAAE,cAAc,GAAG,IAAI,CAAC;CAC7B;AA2BD;;;;;;;;;GASG;AACH,eAAO,MAAM,2BAA2B,8BAA8B,CAAC;AACvE,eAAO,MAAM,kCAAkC,yCAAyC,CAAC;AA0RzF;;;;;;;;;;GAUG;AACH,wBAAgB,WAAW,CAAC,OAAO,EAAE,OAAO,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,EAAE,CAWhE"}