@barefootjs/client 0.27.0 → 0.28.1

package/dist/runtime/map-array-lazy.d.ts

@@ -0,0 +1,164 @@
+/**
+ * BarefootJS - Lazy Row Graph List Rendering (slot unification §9, L2)
+ *
+ * `mapArrayLazy` renders a keyed reactive array WITHOUT any per-row reactive
+ * resources: no `createRoot`, no per-item signal, no per-row effect, no
+ * hydration-time query/claim/DOM-write per row. See
+ * `spec/slot-unification.md` §9 for the design and the measurement spike
+ * that motivated it (branch `claude/lazy-effect-spike`).
+ *
+ * A plain loop row has exactly two update paths, both already known without
+ * per-row reactivity (§9.1):
+ *
+ *  1. **Item-driven changes** — the keyed reconciler detects them itself
+ *     (`!Object.is(oldItem, newItem)` per key) and calls the row plan's
+ *     `applyItem` directly. The row's DOM refs are claimed lazily on that
+ *     row's FIRST item-driven write (a scan inside that one row, cached on
+ *     `entry.refs`); a row that never updates never pays.
+ *  2. **Outer-signal reads** — applied by ONE loop-level `createEffect`
+ *     (`applyOuter`) iterating all entries with per-entry dedup, created
+ *     only when the loop has such bindings.
+ *
+ * ## Row-plan contract (PINNED — L3's compiler emission targets exactly this)
+ *
+ * The compiler emits a {@link LazyRowPlan} per eligible loop
+ * (§9.4 eligibility: plain single-root keyed rows whose data source is
+ * hydration-consistent; everything else keeps the eager `mapArray`
+ * emission). Obligations, split by side:
+ *
+ * **Runtime (this module) guarantees:**
+ * - Hydration first run adopts SSR rows with ZERO per-row DOM mutations:
+ *   `entry.key` is READ from the SSR-rendered `data-key` attribute (never
+ *   written on adopted rows; `getKey(items[i], i)` is the fallback when the
+ *   attribute is absent), `entry.item = items[i]` positionally (sound by
+ *   the §9.3(2) compile-time eligibility gate), `refs`/`last` start `null`.
+ * - `plan.createRow` / `plan.applyItem` are invoked inside the reconciler
+ *   effect but wrapped in `untrack()`, so outer-signal reads during row
+ *   creation or item application never subscribe the reconciler — it re-runs
+ *   only when `accessor()`'s dependencies change. (`applyItem` is untracked
+ *   for the same reason `createRow` is: mixed item+outer bindings read outer
+ *   signals non-reactively there; the `applyOuter` effect owns the reactive
+ *   side.)
+ * - The runtime assigns `createRow`'s returned element to `entry.primaryEl`
+ *   and stamps `data-key` on CSR-created rows if `createRow` didn't (same
+ *   semantics as `mapArray`'s create path).
+ * - When `plan.applyOuter` exists, ONE loop-level effect is created (after
+ *   the reconciler effect, so its first run happens after adoption) whose
+ *   body calls `applyOuter(entryList, seed)` with `seed === true` exactly
+ *   once, on the very first run. `entryList` is a closure variable holding
+ *   the entries in current order, REBUILT (reassigned) by the reconciler
+ *   after every reconcile — chosen over a live/mutable view so a run of the
+ *   effect can never observe a half-reconciled list, and read
+ *   non-reactively so the effect re-runs ONLY on the outer signals
+ *   `applyOuter` itself reads, never because the list was reconciled.
+ * - **Re-subscribe seam**: the previous bullet's "reconciles never re-run
+ *   this effect" contract holds only when every outer read subscribes
+ *   independently of the entries. That is true for a plain signal/memo
+ *   getter and FALSE for a per-key subscription such as `createSelector`,
+ *   whose selector subscribes the caller only to the specific keys it was
+ *   called with — so a reconcile can leave the effect subscribed to keys
+ *   that no longer matter and NOT subscribed to keys that now do. Every
+ *   loop with an `applyOuter` therefore re-runs it after any reconcile that
+ *   created a row or changed an item (removals strand nothing). Applied
+ *   unconditionally rather than gated on a compiler judgement about which
+ *   reads are per-key: see the seam's comment inside `mapArrayLazy` for why
+ *   (a misclassification must be harmless, not silently wrong) and for the
+ *   three stranding sequences it prevents, each reproduced before it existed.
+ *
+ * **Plan (compiler-emitted) obligations:**
+ * - `createRow` MUST write ALL bindings — item-driven AND outer-involving —
+ *   with current values (it is CSR creation; it computes everything anyway)
+ *   and MUST seed `entry.refs`/`entry.last` from known clone paths (no
+ *   scan). Freshly-created rows are therefore consistent immediately; the
+ *   `applyOuter` effect's per-entry dedup (seeded via `entry.last`) keeps
+ *   them consistent on later outer-signal changes.
+ * - `applyOuter`'s FIRST run (`seed === true`) must READ current DOM state
+ *   (`getAttribute` / `nodeValue`) to initialize each entry's dedup value
+ *   and write only where the computed value differs — read-compare-write
+ *   seeding (§9.3(1)), sound even when outer state is client-only and
+ *   diverges from SSR. No trust-first-run regression (§6).
+ * - `applyItem` claims refs lazily (scan within `entry.primaryEl`) when
+ *   `entry.refs` is null, and writes through per-binding dedup held on
+ *   `entry.last` / `entry.refs`.
+ *
+ * ## Reconciliation
+ *
+ * The keyed diff, duplicate-key once-per-reconcile warning, clear-all fast
+ * path, and LIS minimal-move reorder mirror `mapArray`'s exactly — minus
+ * every per-row reactive resource. Removal is plain DOM detach: entries
+ * hold no reactive resources (CSR rows created by `plan.createRow` hold
+ * none either), so there is nothing to dispose.
+ *
+ * Single-root rows only (v1): the §9.4 eligibility gate guarantees the
+ * compiler never targets this entry point for multi-root (Fragment) rows,
+ * so there is no `startMarker`/`extras`/`bf-loop-i` bookkeeping here.
+ *
+ * Rows are NOT added to `hydratedScopes`: that mark exists for element
+ * scopes the hydration walker must skip, and lazy-eligible rows are plain
+ * markup (no nested component/host scopes — the eligibility gate excludes
+ * them), so the mark would only spend per-row memory this design exists to
+ * eliminate.
+ *
+ * Shared helpers: `findLoopMarkers` and `longestIncreasingSubsequenceIndices`
+ * are imported from `./map-array.ts` (now exported for internal reuse)
+ * rather than duplicated or extracted into a third module — they are pure,
+ * behavior-identical for both reconcilers, and importing keeps exactly one
+ * copy without churning `map-array.ts`'s structure. The loop-shaped logic
+ * around them (partition, diff, clear fast path) is intentionally
+ * re-written here rather than shared: it differs in what it carries per row
+ * (plain entries vs reactive scopes) and forcing one parameterized body
+ * would obscure both.
+ *
+ * `bfId` is forwarded to the reconciler effect only (same attribution point
+ * as `mapArray`); profile mode never emits lazy loops (§9.4), so the outer
+ * effect carries no id.
+ */
+/**
+ * One row of a lazy loop: plain data, no reactive resources.
+ * Built at adoption (hydration) or by the reconciler via `plan.createRow`.
+ */
+export interface LazyRowEntry<T> {
+    key: string;
+    primaryEl: HTMLElement;
+    item: T;
+    /** plan-owned: claimed DOM refs, null until the row's first item-driven write */
+    refs: unknown | null;
+    /** plan-owned: per-binding last-value dedup state */
+    last: unknown | null;
+}
+/**
+ * The compiler-emitted row plan for a lazy-eligible loop.
+ * See the module docstring for the pinned contract and each side's
+ * obligations.
+ */
+export interface LazyRowPlan<T> {
+    /** CSR create: clone/build a fully-written row element for item; record refs
+     *  and dedup state directly on the entry (no scan). Returns the element. */
+    createRow(entry: LazyRowEntry<T>, index: number): HTMLElement;
+    /** Item-driven (and mixed) bindings: called by the reconciler AFTER
+     *  entry.item has been updated to the new item; prevItem is the old value.
+     *  Claims refs lazily (scan within entry.primaryEl) when entry.refs is null.
+     *  Writes through per-binding dedup held on entry.last / entry.refs. */
+    applyItem(entry: LazyRowEntry<T>, prevItem: T): void;
+    /** Outer-involving bindings (present only when the loop has bindings that
+     *  read signals from outside the row). Runtime wraps this in ONE
+     *  createEffect for the whole loop. Reads its outer signals inside the
+     *  callback (so the effect subscribes), then applies those bindings to
+     *  every entry with per-entry dedup. `seed` is true on the effect's FIRST
+     *  run only: the binding must READ current DOM state (getAttribute /
+     *  nodeValue) to initialize its dedup value and write only where the
+     *  computed value differs (read-compare-write, spec §9.3(1)). */
+    applyOuter?(entries: ReadonlyArray<LazyRowEntry<T>>, seed: boolean): void;
+}
+/**
+ * Lazy-row-graph keyed list rendering (spec/slot-unification.md §9).
+ *
+ * @param accessor - Function returning the reactive array (signal/memo read)
+ * @param container - DOM container element
+ * @param getKey - Key extractor (null = use index). Receives plain item value.
+ * @param plan - Compiler-emitted row plan (see {@link LazyRowPlan})
+ * @param markerId - Scoped loop marker id (`<!--bf-loop:<id>-->`), see #1087
+ * @param bfId - Profiler attribution id for the reconciler effect
+ */
+export declare function mapArrayLazy<T>(accessor: () => T[], container: HTMLElement | null, getKey: ((item: T, index: number) => string) | null, plan: LazyRowPlan<T>, markerId?: string, bfId?: string): void;
+//# sourceMappingURL=map-array-lazy.d.ts.map

package/dist/runtime/map-array-lazy.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"map-array-lazy.d.ts","sourceRoot":"","sources":["../../src/runtime/map-array-lazy.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkHG;AAMH;;;GAGG;AACH,MAAM,WAAW,YAAY,CAAC,CAAC;IAC7B,GAAG,EAAE,MAAM,CAAA;IACX,SAAS,EAAE,WAAW,CAAA;IACtB,IAAI,EAAE,CAAC,CAAA;IACP,iFAAiF;IACjF,IAAI,EAAE,OAAO,GAAG,IAAI,CAAA;IACpB,qDAAqD;IACrD,IAAI,EAAE,OAAO,GAAG,IAAI,CAAA;CACrB;AAED;;;;GAIG;AACH,MAAM,WAAW,WAAW,CAAC,CAAC;IAC5B;gFAC4E;IAC5E,SAAS,CAAC,KAAK,EAAE,YAAY,CAAC,CAAC,CAAC,EAAE,KAAK,EAAE,MAAM,GAAG,WAAW,CAAA;IAC7D;;;4EAGwE;IACxE,SAAS,CAAC,KAAK,EAAE,YAAY,CAAC,CAAC,CAAC,EAAE,QAAQ,EAAE,CAAC,GAAG,IAAI,CAAA;IACpD;;;;;;;qEAOiE;IACjE,UAAU,CAAC,CAAC,OAAO,EAAE,aAAa,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,OAAO,GAAG,IAAI,CAAA;CAC1E;AAED;;;;;;;;;GASG;AACH,wBAAgB,YAAY,CAAC,CAAC,EAC5B,QAAQ,EAAE,MAAM,CAAC,EAAE,EACnB,SAAS,EAAE,WAAW,GAAG,IAAI,EAC7B,MAAM,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,EAAE,KAAK,EAAE,MAAM,KAAK,MAAM,CAAC,GAAG,IAAI,EACnD,IAAI,EAAE,WAAW,CAAC,CAAC,CAAC,EACpB,QAAQ,CAAC,EAAE,MAAM,EACjB,IAAI,CAAC,EAAE,MAAM,GACZ,IAAI,CAqSN"}

package/dist/runtime/map-array.d.ts

@@ -17,6 +17,41 @@
  * extras...) triple — moves, mounts, and unmounts as a single unit.
  * Single-root loops continue to flow through the legacy path verbatim.
  */
+/**
+ * Find loop boundary comment markers in a container.
+ *
+ * When `markerId` is given, matches the scoped form `<!--bf-loop:<id>-->` /
+ * `<!--bf-/loop:<id>-->` so sibling `.map()` calls under the same parent
+ * each see only their own range (#1087).
+ *
+ * When omitted (e.g. hand-written tests that drop in unscoped markers),
+ * falls back to the first start / first end found, matching either the
+ * scoped or legacy unscoped form.
+ *
+ * Exported for `./map-array-lazy.ts` (internal reuse only — not re-exported
+ * from the runtime index).
+ */
+export declare function findLoopMarkers(container: HTMLElement, markerId?: string): {
+    start: Comment | null;
+    end: Comment | null;
+};
+/**
+ * Longest increasing subsequence, returned as ascending indices into `arr`.
+ * O(n log n) patience sorting with predecessor backtracking.
+ *
+ * Used by `mapArray`'s reorder step: `arr` holds, for each already-attached
+ * scope encountered while walking the live DOM in its current order, the
+ * scope's index in the *desired* order. The LIS of that array is the
+ * largest set of scopes whose relative order already matches the desired
+ * order — those scopes can stay exactly where they are; every other scope
+ * (plus any brand-new one) needs to move. This is the same strategy
+ * keyed-diff reconcilers in the udomdiff/Solid family use to turn an
+ * arbitrary reorder into a minimal set of DOM moves.
+ *
+ * Exported for `./map-array-lazy.ts` (internal reuse only — not re-exported
+ * from the runtime index).
+ */
+export declare function longestIncreasingSubsequenceIndices(arr: number[]): number[];
 /**
  * Per-item scoped list rendering.
  *

package/dist/runtime/map-array.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"map-array.d.ts","sourceRoot":"","sources":["../../src/runtime/map-array.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAgPH;;;;;;;;;;GAUG;AACH,wBAAgB,QAAQ,CAAC,CAAC,EACxB,QAAQ,EAAE,MAAM,CAAC,EAAE,EACnB,SAAS,EAAE,WAAW,GAAG,IAAI,EAC7B,MAAM,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,EAAE,KAAK,EAAE,MAAM,KAAK,MAAM,CAAC,GAAG,IAAI,EACnD,UAAU,EAAE,CAAC,IAAI,EAAE,MAAM,CAAC,EAAE,KAAK,EAAE,MAAM,EAAE,QAAQ,CAAC,EAAE,WAAW,KAAK,WAAW,EACjF,QAAQ,CAAC,EAAE,MAAM,EACjB,IAAI,CAAC,EAAE,MAAM,GACZ,IAAI,CAoQN;AAqHD;;;;;;;GAOG;AACH,wBAAgB,gBAAgB,CAAC,CAAC,EAChC,QAAQ,EAAE,MAAM,CAAC,EAAE,EACnB,SAAS,EAAE,WAAW,GAAG,IAAI,EAC7B,MAAM,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,EAAE,KAAK,EAAE,MAAM,KAAK,MAAM,CAAC,GAAG,IAAI,EACnD,UAAU,EAAE,CAAC,IAAI,EAAE,MAAM,CAAC,EAAE,KAAK,EAAE,MAAM,EAAE,QAAQ,CAAC,EAAE,OAAO,KAAK,gBAAgB,GAAG,OAAO,EAC5F,QAAQ,CAAC,EAAE,MAAM,EACjB,IAAI,CAAC,EAAE,MAAM,GACZ,IAAI,CA+FN"}
+{"version":3,"file":"map-array.d.ts","sourceRoot":"","sources":["../../src/runtime/map-array.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAqCH;;;;;;;;;;;;;GAaG;AACH,wBAAgB,eAAe,CAC7B,SAAS,EAAE,WAAW,EACtB,QAAQ,CAAC,EAAE,MAAM,GAChB;IAAE,KAAK,EAAE,OAAO,GAAG,IAAI,CAAC;IAAC,GAAG,EAAE,OAAO,GAAG,IAAI,CAAA;CAAE,CA+BhD;AA8DD;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,mCAAmC,CAAC,GAAG,EAAE,MAAM,EAAE,GAAG,MAAM,EAAE,CA2B3E;AAkFD;;;;;;;;;;GAUG;AACH,wBAAgB,QAAQ,CAAC,CAAC,EACxB,QAAQ,EAAE,MAAM,CAAC,EAAE,EACnB,SAAS,EAAE,WAAW,GAAG,IAAI,EAC7B,MAAM,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,EAAE,KAAK,EAAE,MAAM,KAAK,MAAM,CAAC,GAAG,IAAI,EACnD,UAAU,EAAE,CAAC,IAAI,EAAE,MAAM,CAAC,EAAE,KAAK,EAAE,MAAM,EAAE,QAAQ,CAAC,EAAE,WAAW,KAAK,WAAW,EACjF,QAAQ,CAAC,EAAE,MAAM,EACjB,IAAI,CAAC,EAAE,MAAM,GACZ,IAAI,CA6RN;AAqHD;;;;;;;GAOG;AACH,wBAAgB,gBAAgB,CAAC,CAAC,EAChC,QAAQ,EAAE,MAAM,CAAC,EAAE,EACnB,SAAS,EAAE,WAAW,GAAG,IAAI,EAC7B,MAAM,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,EAAE,KAAK,EAAE,MAAM,KAAK,MAAM,CAAC,GAAG,IAAI,EACnD,UAAU,EAAE,CAAC,IAAI,EAAE,MAAM,CAAC,EAAE,KAAK,EAAE,MAAM,EAAE,QAAQ,CAAC,EAAE,OAAO,KAAK,gBAAgB,GAAG,OAAO,EAC5F,QAAQ,CAAC,EAAE,MAAM,EACjB,IAAI,CAAC,EAAE,MAAM,GACZ,IAAI,CA+FN"}

package/dist/runtime/qsa-item.d.ts

@@ -25,6 +25,13 @@
  *      is `null` and step 2 yields nothing. Reading `__bfExtras` lets
  *      lookups reach the still-pending extras before `mapArray` inserts
  *      them into the DOM.
+ *
+ * Step 3's reliance on the primary being detached during setup is why
+ * `createItemScope` un-parks a row that turns out to carry extras: the
+ * connect-before-init mount point applies to `createComponent` row roots,
+ * which are single-root by construction and so never reach this module. An
+ * attached primary would make step 2's sibling walk run past the item's own
+ * roots into a neighbouring item's elements before step 3 is ever consulted.
  */
 /**
  * Find an element matching `selector` within an item's range. Searches

package/dist/runtime/qsa-item.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"qsa-item.d.ts","sourceRoot":"","sources":["../../src/runtime/qsa-item.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AAsCH;;;;GAIG;AACH,wBAAgB,OAAO,CAAC,SAAS,EAAE,OAAO,GAAG,IAAI,EAAE,QAAQ,EAAE,MAAM,GAAG,OAAO,GAAG,IAAI,CAQnF;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,eAAe,CAC7B,SAAS,EAAE,OAAO,EAClB,IAAI,EAAE,MAAM,EACZ,MAAM,EAAE,MAAM,GAAG,IAAI,EACrB,KAAK,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC9B,GAAG,CAAC,EAAE,MAAM,GAAG,MAAM,EACrB,WAAW,CAAC,EAAE,OAAO,GAAG,IAAI,GAC3B,WAAW,GAAG,IAAI,CAwBpB"}
+{"version":3,"file":"qsa-item.d.ts","sourceRoot":"","sources":["../../src/runtime/qsa-item.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AAsCH;;;;GAIG;AACH,wBAAgB,OAAO,CAAC,SAAS,EAAE,OAAO,GAAG,IAAI,EAAE,QAAQ,EAAE,MAAM,GAAG,OAAO,GAAG,IAAI,CAQnF;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,eAAe,CAC7B,SAAS,EAAE,OAAO,EAClB,IAAI,EAAE,MAAM,EACZ,MAAM,EAAE,MAAM,GAAG,IAAI,EACrB,KAAK,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC9B,GAAG,CAAC,EAAE,MAAM,GAAG,MAAM,EACrB,WAAW,CAAC,EAAE,OAAO,GAAG,IAAI,GAC3B,WAAW,GAAG,IAAI,CAuBpB"}

package/dist/runtime/registry.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"registry.d.ts","sourceRoot":"","sources":["../../src/runtime/registry.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAOH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,YAAY,CAAA;AAaxC;;;;;;GAMG;AACH,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,GAAG,IAAI,CAclE;AAED;;;;;;GAMG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS,CAEjE;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,SAAS,CACvB,IAAI,EAAE,MAAM,EACZ,UAAU,EAAE,OAAO,GAAG,IAAI,EAC1B,KAAK,GAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAM,GAClC,IAAI,CAoCN;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,WAAW,CACzB,MAAM,EAAE,OAAO,EACf,IAAI,EAAE,MAAM,EACZ,MAAM,EAAE,MAAM,GAAG,IAAI,EACrB,KAAK,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC9B,GAAG,CAAC,EAAE,MAAM,GAAG,MAAM,EACrB,WAAW,CAAC,EAAE,OAAO,GAAG,IAAI,GAC3B,WAAW,GAAG,IAAI,CA8BpB"}
+{"version":3,"file":"registry.d.ts","sourceRoot":"","sources":["../../src/runtime/registry.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAOH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,YAAY,CAAA;AAaxC;;;;;;GAMG;AACH,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,GAAG,IAAI,CAclE;AAED;;;;;;GAMG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS,CAEjE;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,SAAS,CACvB,IAAI,EAAE,MAAM,EACZ,UAAU,EAAE,OAAO,GAAG,IAAI,EAC1B,KAAK,GAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAM,GAClC,IAAI,CAoCN;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,WAAW,CACzB,MAAM,EAAE,OAAO,EACf,IAAI,EAAE,MAAM,EACZ,MAAM,EAAE,MAAM,GAAG,IAAI,EACrB,KAAK,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC9B,GAAG,CAAC,EAAE,MAAM,GAAG,MAAM,EACrB,WAAW,CAAC,EAAE,OAAO,GAAG,IAAI,GAC3B,WAAW,GAAG,IAAI,CAgCpB"}