@sciflow/editor-start 0.0.2 → 0.1.0

package/dist/lib/read-only.d.ts

@@ -0,0 +1,95 @@
+/**
+ * @module read-only
+ *
+ * A generic, toggleable read-only `Feature`: vetoes every doc-changing
+ * transaction while leaving selection/scroll transactions free to pass (so
+ * browsing — clicking around, selecting text to read it — still works),
+ * disables the DOM's own `contenteditable`/caret/IME behavior, and marks the
+ * editable surface with a styling hook so consumers can render a muted look.
+ *
+ * # Mechanism
+ *
+ * - `filterTransaction: (tr, state) => !tr.docChanged || isExternalSyncTransaction(tr) || key.getState(state) !== true`
+ *   — `EditorState.applyTransaction` checks this BEFORE running any plugin's
+ *   `state.apply`, so a vetoed transaction never reaches the doc, the
+ *   undo-history plugin, or anything else — the state comes back byte-for-
+ *   byte unchanged (`newState === oldState`). Selection-only and meta-only
+ *   transactions (`tr.docChanged === false` — e.g. a click, or another
+ *   feature's own `dispatchMeta` update) are explicitly let through, and so
+ *   is `Editor`'s own external-doc reconciliation transaction (see the
+ *   "Programmatic doc replacement" section below) — only an actual user/
+ *   command edit is vetoed.
+ * - `props.editable: (state) => key.getState(state) !== true` — the DOM-level
+ *   backstop: disables `contenteditable`, so the browser's own caret/IME
+ *   never engages in the first place. `filterTransaction` alone would still
+ *   technically block an edit, but a live caret sitting in "dead" text reads
+ *   as broken, not read-only.
+ * - `props.attributes: (state) => (key.getState(state) ? { 'data-readonly': 'true' } : {})`
+ *   — the styling hook. No baked-in colors here (only a `data-readonly`
+ *   attribute) — style the muted look with your own token-based CSS, e.g.
+ *   `.sf-editable-surface .ProseMirror[data-readonly] { opacity: var(--sf-opacity-muted); }`.
+ *
+ * # Programmatic doc replacement still works while read-only
+ *
+ * "Read-only" means "the user cannot edit this document" — not "this
+ * document can never change from any source." A host that reassigns
+ * `editor.doc` (e.g. a revision viewer paging through history) drives
+ * `Editor.updateFromSync()`, which reconciles the mounted view via its own
+ * transaction (`Editor`'s internal `syncViewWithState()`), tagged with
+ * `EXTERNAL_SYNC_TRANSACTION_META`. `filterTransaction` lets THAT transaction
+ * through even while read-only, so the view keeps rendering every
+ * subsequent doc the host assigns; only a transaction WITHOUT that meta
+ * (a real edit) is vetoed. See `@sciflow/editor-core`'s
+ * `EXTERNAL_SYNC_TRANSACTION_META`/`isExternalSyncTransaction` doc for the
+ * full contract — any custom read-only-style `filterTransaction` should
+ * follow the same check, or it will "freeze" the editor's own
+ * `updateFromSync()` calls after the first doc assignment, not just block
+ * user typing.
+ *
+ * # Toggling without re-initializing the editor
+ *
+ * The read-only flag lives in PLUGIN STATE (keyed, like `range-decorations.ts`,
+ * so it survives every transaction via a plain `state.apply`), not a value
+ * captured once at feature-construction time — `filterTransaction`/`editable`/
+ * `attributes` all read the CURRENT state on every check. This means the
+ * flag genuinely toggles live, no `configureFeatures()`/re-mount needed:
+ *
+ * ```typescript
+ * import { createReadOnlyFeature } from '@sciflow/editor-start/bundle';
+ *
+ * const { feature, key } = createReadOnlyFeature('my-read-only');
+ * await editor.configureFeatures([...otherFeatures, feature]);
+ *
+ * editor.plugins.dispatchMeta(key, true);   // now read-only
+ * editor.plugins.dispatchMeta(key, false);  // editable again, same editor instance
+ * ```
+ *
+ * # A caveat worth stating plainly, not silently
+ *
+ * `filterTransaction` guarantees the DOC never actually changes for a
+ * vetoed transaction, but a host's own `dispatchTransaction` handler that
+ * inspects the REJECTED transaction object directly (rather than comparing
+ * before/after state) can still be misled: `tr.docChanged` reflects what the
+ * transaction WOULD have done, not whether it was applied. A consumer
+ * wiring up its own change-tracking on a read-only editor should compare
+ * `newState !== oldState` (or `newState.doc.eq(oldState.doc)`) rather than
+ * trusting `tr.docChanged` alone. `@sciflow/editor-core`'s own
+ * `handleTransaction` does inspect `tr.docChanged` directly — this is a
+ * known, narrow gap for the (unusual) case of listening to `editor-change`
+ * on a read-only instance, not something this feature can close from a
+ * plugin alone. Not a concern for the ordinary "browse a read-view editor,
+ * nobody listens to its `editor-change`" case.
+ */
+import { PluginKey } from 'prosemirror-state';
+import { type Feature } from '@sciflow/editor-core';
+/**
+ * Build a fresh, independently-keyed read-only `Feature`. `initialReadOnly`
+ * sets the STARTING value (default `false` — editable, matching an ordinary
+ * editor's least-surprising default); flip it live afterward via
+ * `editor.plugins.dispatchMeta(key, true | false)`.
+ */
+export declare function createReadOnlyFeature(name: string, initialReadOnly?: boolean): {
+    feature: Feature;
+    key: PluginKey<boolean>;
+};
+//# sourceMappingURL=read-only.d.ts.map

package/dist/lib/read-only.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"read-only.d.ts","sourceRoot":"","sources":["../../src/lib/read-only.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiFG;AAEH,OAAO,EAAU,SAAS,EAAE,MAAM,mBAAmB,CAAC;AACtD,OAAO,EAA6B,KAAK,OAAO,EAAE,MAAM,sBAAsB,CAAC;AAE/E;;;;;GAKG;AACH,wBAAgB,qBAAqB,CACnC,IAAI,EAAE,MAAM,EACZ,eAAe,UAAQ,GACtB;IAAE,OAAO,EAAE,OAAO,CAAC;IAAC,GAAG,EAAE,SAAS,CAAC,OAAO,CAAC,CAAA;CAAE,CAiC/C"}

package/dist/lib/read-only.js

@@ -0,0 +1,123 @@
+/**
+ * @module read-only
+ *
+ * A generic, toggleable read-only `Feature`: vetoes every doc-changing
+ * transaction while leaving selection/scroll transactions free to pass (so
+ * browsing — clicking around, selecting text to read it — still works),
+ * disables the DOM's own `contenteditable`/caret/IME behavior, and marks the
+ * editable surface with a styling hook so consumers can render a muted look.
+ *
+ * # Mechanism
+ *
+ * - `filterTransaction: (tr, state) => !tr.docChanged || isExternalSyncTransaction(tr) || key.getState(state) !== true`
+ *   — `EditorState.applyTransaction` checks this BEFORE running any plugin's
+ *   `state.apply`, so a vetoed transaction never reaches the doc, the
+ *   undo-history plugin, or anything else — the state comes back byte-for-
+ *   byte unchanged (`newState === oldState`). Selection-only and meta-only
+ *   transactions (`tr.docChanged === false` — e.g. a click, or another
+ *   feature's own `dispatchMeta` update) are explicitly let through, and so
+ *   is `Editor`'s own external-doc reconciliation transaction (see the
+ *   "Programmatic doc replacement" section below) — only an actual user/
+ *   command edit is vetoed.
+ * - `props.editable: (state) => key.getState(state) !== true` — the DOM-level
+ *   backstop: disables `contenteditable`, so the browser's own caret/IME
+ *   never engages in the first place. `filterTransaction` alone would still
+ *   technically block an edit, but a live caret sitting in "dead" text reads
+ *   as broken, not read-only.
+ * - `props.attributes: (state) => (key.getState(state) ? { 'data-readonly': 'true' } : {})`
+ *   — the styling hook. No baked-in colors here (only a `data-readonly`
+ *   attribute) — style the muted look with your own token-based CSS, e.g.
+ *   `.sf-editable-surface .ProseMirror[data-readonly] { opacity: var(--sf-opacity-muted); }`.
+ *
+ * # Programmatic doc replacement still works while read-only
+ *
+ * "Read-only" means "the user cannot edit this document" — not "this
+ * document can never change from any source." A host that reassigns
+ * `editor.doc` (e.g. a revision viewer paging through history) drives
+ * `Editor.updateFromSync()`, which reconciles the mounted view via its own
+ * transaction (`Editor`'s internal `syncViewWithState()`), tagged with
+ * `EXTERNAL_SYNC_TRANSACTION_META`. `filterTransaction` lets THAT transaction
+ * through even while read-only, so the view keeps rendering every
+ * subsequent doc the host assigns; only a transaction WITHOUT that meta
+ * (a real edit) is vetoed. See `@sciflow/editor-core`'s
+ * `EXTERNAL_SYNC_TRANSACTION_META`/`isExternalSyncTransaction` doc for the
+ * full contract — any custom read-only-style `filterTransaction` should
+ * follow the same check, or it will "freeze" the editor's own
+ * `updateFromSync()` calls after the first doc assignment, not just block
+ * user typing.
+ *
+ * # Toggling without re-initializing the editor
+ *
+ * The read-only flag lives in PLUGIN STATE (keyed, like `range-decorations.ts`,
+ * so it survives every transaction via a plain `state.apply`), not a value
+ * captured once at feature-construction time — `filterTransaction`/`editable`/
+ * `attributes` all read the CURRENT state on every check. This means the
+ * flag genuinely toggles live, no `configureFeatures()`/re-mount needed:
+ *
+ * ```typescript
+ * import { createReadOnlyFeature } from '@sciflow/editor-start/bundle';
+ *
+ * const { feature, key } = createReadOnlyFeature('my-read-only');
+ * await editor.configureFeatures([...otherFeatures, feature]);
+ *
+ * editor.plugins.dispatchMeta(key, true);   // now read-only
+ * editor.plugins.dispatchMeta(key, false);  // editable again, same editor instance
+ * ```
+ *
+ * # A caveat worth stating plainly, not silently
+ *
+ * `filterTransaction` guarantees the DOC never actually changes for a
+ * vetoed transaction, but a host's own `dispatchTransaction` handler that
+ * inspects the REJECTED transaction object directly (rather than comparing
+ * before/after state) can still be misled: `tr.docChanged` reflects what the
+ * transaction WOULD have done, not whether it was applied. A consumer
+ * wiring up its own change-tracking on a read-only editor should compare
+ * `newState !== oldState` (or `newState.doc.eq(oldState.doc)`) rather than
+ * trusting `tr.docChanged` alone. `@sciflow/editor-core`'s own
+ * `handleTransaction` does inspect `tr.docChanged` directly — this is a
+ * known, narrow gap for the (unusual) case of listening to `editor-change`
+ * on a read-only instance, not something this feature can close from a
+ * plugin alone. Not a concern for the ordinary "browse a read-view editor,
+ * nobody listens to its `editor-change`" case.
+ */
+import { Plugin, PluginKey } from 'prosemirror-state';
+import { isExternalSyncTransaction } from '@sciflow/editor-core';
+/**
+ * Build a fresh, independently-keyed read-only `Feature`. `initialReadOnly`
+ * sets the STARTING value (default `false` — editable, matching an ordinary
+ * editor's least-surprising default); flip it live afterward via
+ * `editor.plugins.dispatchMeta(key, true | false)`.
+ */
+export function createReadOnlyFeature(name, initialReadOnly = false) {
+    const key = new PluginKey(name);
+    const plugin = new Plugin({
+        key,
+        state: {
+            init: () => initialReadOnly,
+            apply(tr, readOnly) {
+                const meta = tr.getMeta(key);
+                return typeof meta === 'boolean' ? meta : readOnly;
+            },
+        },
+        filterTransaction(tr, state) {
+            if (!tr.docChanged)
+                return true;
+            // The editor's OWN external-doc reconciliation (Editor.updateFromSync /
+            // .applyOps, via syncViewWithState) — not a user edit. Letting it
+            // through is what makes `editor.doc = nextSnapshot` keep rendering on a
+            // read-only instance after the first assignment; see the module doc.
+            if (isExternalSyncTransaction(tr))
+                return true;
+            return key.getState(state) !== true;
+        },
+        props: {
+            editable: (state) => key.getState(state) !== true,
+            attributes: (state) => (key.getState(state) ? { 'data-readonly': 'true' } : {}),
+        },
+    });
+    const feature = {
+        name,
+        addPlugins: () => [plugin],
+    };
+    return { feature, key };
+}

package/dist/testing/external-widget-simulator.d.ts

@@ -0,0 +1,217 @@
+/**
+ * @module external-widget-simulator
+ * @internal
+ *
+ * INTERNAL TESTING UTILITY — NOT STABLE PUBLIC API.
+ * This module is exported from the `@sciflow/editor-start` package solely to
+ * enable automated tests and the interactive demo page to verify light-DOM
+ * reachability.  Its API may change without a semver notice.  Do not depend on
+ * it in production code.
+ *
+ * A vanilla-JS simulator that models the three key behaviours of browser
+ * proofreading and AI writing extensions (e.g. Grammarly, the LanguageTool
+ * browser add-on, DeepL Write, etc.) when they interact with a page's
+ * editable surface.
+ *
+ * Design constraints
+ * ------------------
+ * - Zero runtime dependencies — only public web APIs.
+ * - Never traverses into any ShadowRoot.  Extensions operate exclusively on
+ *   the flat document tree; they have no access to shadow-DOM internals.
+ * - Suitable for both automated tests (jsdom / vitest) and manual in-browser
+ *   testing via the demo page.
+ *
+ * The three capabilities modelled
+ * --------------------------------
+ * 1. `discover(root?)` — walks the light DOM for editable targets exactly as a
+ *    real extension would: `querySelectorAll` on [contenteditable], textarea,
+ *    and text inputs, then filters to nodes whose root is the document (i.e.
+ *    not behind a shadow boundary).
+ *
+ * 2. `markRange(target, from, to, options?)` — draws underline-style overlay
+ *    markers over a character range inside a text node the way widgets render
+ *    grammar/spell highlights.  Uses Range + getClientRects() and places
+ *    absolutely-positioned <span> elements in an overlay layer that is a
+ *    sibling of the editable (never inside it).
+ *
+ * 3. DOM mutation operations that mimic extensions touching the editable
+ *    directly, bypassing the editor's own transaction mechanism:
+ *    - `injectMarker(target, from, to)` — wraps a text sub-range in a
+ *      `<span data-extn-marker="1">` (how widgets tag matches for hover
+ *      interactions without accepting/rejecting them yet).
+ *    - `applyCorrection(target, from, to, replacement)` — replaces a text
+ *      sub-range via raw Range manipulation (the "accept suggestion" action).
+ *
+ * Threat/usage model
+ * ------------------
+ * A ProseMirror contenteditable mounted inside a shadow root is INVISIBLE to
+ * extensions because they do not call `shadowRoot.querySelector`.  This
+ * simulator encodes that exact distinction: `discover()` returns only light-DOM
+ * editables whose `getRootNode() === document`.  The fact that a slotted
+ * element satisfies this condition while a shadow-buried element does not is
+ * the core regression guard for the light-DOM spike (Option B).
+ *
+ * jsdom limitation
+ * ----------------
+ * `getClientRects()` is not implemented in jsdom and always returns an empty
+ * DOMRectList.  `markRange()` therefore cannot be meaningfully tested in the
+ * standard vitest suite — it is exercised through the manual demo page instead.
+ * `discover()`, `injectMarker()`, and `applyCorrection()` are all jsdom-safe
+ * and form the automated test surface.
+ */
+/** An editable element found by the simulator's discovery walk. */
+export interface EditableTarget {
+    /** The discovered element. */
+    element: HTMLElement;
+    /**
+     * The root node of the element.  For a light-DOM element this will be the
+     * `Document`; for a shadow-buried element it would be a `ShadowRoot`.
+     * The simulator's `discover()` only returns elements where this is
+     * `document` — this field is exposed so tests can assert it explicitly.
+     */
+    rootNode: Node;
+    /** True when the element is inside the light DOM (`rootNode === document`). */
+    isLightDom: boolean;
+}
+/** Options for the `markRange` overlay operation. */
+export interface MarkRangeOptions {
+    /** CSS color for the underline.  Defaults to `'#ef4444'` (red). */
+    color?: string;
+    /**
+     * How many pixels below the text baseline the underline is offset.
+     * Defaults to `2`.
+     */
+    offsetY?: number;
+    /** CSS z-index for the overlay layer.  Defaults to `'9999'`. */
+    zIndex?: string;
+}
+/** A marker handle returned by `injectMarker`, used for cleanup. */
+export interface InjectedMarker {
+    /** The `<span data-extn-marker="1">` wrapper element. */
+    span: HTMLSpanElement;
+    /** Removes the injected span and restores the original text layout. */
+    remove(): void;
+}
+/** Result of `applyCorrection`. */
+export interface CorrectionResult {
+    /** The text that was replaced. */
+    replaced: string;
+    /** The replacement text that was inserted. */
+    inserted: string;
+}
+/**
+ * Walk the light DOM for editable targets, exactly as browser extensions do.
+ *
+ * Extensions use `document.querySelectorAll` (or equivalent TreeWalker
+ * traversals) to find `[contenteditable]`, `textarea`, and `input[type=text]`.
+ * Critically, they do NOT call `shadowRoot.querySelectorAll` or otherwise
+ * traverse into shadow trees — they only see what is in the flat document tree.
+ *
+ * This function replicates that: it queries from `root` (defaulting to
+ * `document`) and then filters the results to those whose `getRootNode()` is
+ * the passed `root`.  An editable that lives inside a shadow root will NOT
+ * satisfy this condition and will NOT be returned.
+ *
+ * @param root  The root to query from.  Defaults to `document`.
+ * @returns     An array of `EditableTarget` objects for each discovered field.
+ *
+ * @example
+ * // Asserts the editor's contenteditable is reachable from the document root:
+ * const targets = discover(document);
+ * const ce = targets.find(t => t.element.hasAttribute('contenteditable'));
+ * assert(ce?.isLightDom === true);
+ * assert(ce?.rootNode === document);
+ */
+export declare function discover(root?: Document | Element): EditableTarget[];
+/**
+ * Position overlay underline markers over a character range inside `target`.
+ *
+ * Mimics how extensions draw underlines: they create a DOM Range, call
+ * `getClientRects()` to obtain the line boxes, and then absolutely-position
+ * overlay `<span>` elements in a sibling container at those coordinates.
+ * Critically, the overlay is NOT inserted inside the contenteditable — it is
+ * a sibling to avoid invalidating the editable's DOM tree from the extension's
+ * perspective.
+ *
+ * NOTE: `getClientRects()` always returns an empty list in jsdom.  This
+ * function is a no-op in that environment and is intended for manual
+ * in-browser verification via the demo page.  The automated test suite
+ * tests `discover`, `injectMarker`, and `applyCorrection` instead.
+ *
+ * @param target   The editable element to overlay.
+ * @param from     Character offset (from the start of `target.textContent`) of
+ *                 the range start.
+ * @param to       Character offset of the range end.
+ * @param options  Visual options.
+ * @returns        The overlay container element, or `null` when `getClientRects`
+ *                 returned nothing (jsdom / hidden element).
+ */
+export declare function markRange(target: HTMLElement, from: number, to: number, options?: MarkRangeOptions): HTMLElement | null;
+/**
+ * Wrap a character sub-range of `target` in a `<span data-extn-marker="1">`.
+ *
+ * This is what extensions do to tag a match for subsequent accept/reject
+ * interactions — they insert a wrapper span *inside* the contenteditable via
+ * raw DOM Range manipulation without going through the editor's transaction
+ * system.
+ *
+ * From ProseMirror's perspective this is a foreign DOM mutation.  ProseMirror's
+ * DOMObserver will observe the mutation and attempt to reconcile its internal
+ * model.  The mutation-tolerance tests in the spec verify that this does not
+ * corrupt the document or cause PM to throw.
+ *
+ * @param target   The contenteditable element to mutate.
+ * @param from     Character offset of the range start (within `target.textContent`).
+ * @param to       Character offset of the range end.
+ * @returns        An `InjectedMarker` handle with a `remove()` method for cleanup.
+ *                 Returns `null` when the range cannot be resolved.
+ */
+export declare function injectMarker(target: HTMLElement, from: number, to: number): InjectedMarker | null;
+/**
+ * Replace a character sub-range of `target` with `replacement` via raw DOM.
+ *
+ * This is the "accept suggestion" operation: the extension overwrites a word
+ * by creating a Range, deleting its contents, and inserting a new text node.
+ * It does NOT fire a ProseMirror transaction.
+ *
+ * The test that calls this should follow up with a normal PM transaction (e.g.
+ * `view.dispatch(view.state.tr.insertText(...))`) to verify that ProseMirror
+ * reconciles the foreign mutation cleanly and does not produce corrupted or
+ * duplicated content.
+ *
+ * @param target       The contenteditable element.
+ * @param from         Character offset of the range to replace.
+ * @param to           Character offset of the range end.
+ * @param replacement  The text to insert in place of the matched range.
+ * @returns            A `CorrectionResult` describing what was swapped, or
+ *                     `null` when the range cannot be resolved.
+ */
+export declare function applyCorrection(target: HTMLElement, from: number, to: number, replacement: string): CorrectionResult | null;
+/** A character-offset range within an element's flat `textContent`. */
+export interface TextRange {
+    from: number;
+    to: number;
+}
+/**
+ * Find all occurrences of `searchString` within `target.textContent` and
+ * return their character-offset ranges.
+ *
+ * This is the bridge between "a word I want to underline" and the `{from, to}`
+ * pair that `markRange`, `injectMarker`, and `applyCorrection` consume.
+ * Extensions compute positions exactly this way: read the full `textContent`
+ * of the editable as one flat string, locate every match, then use those
+ * offsets to build DOM Ranges.
+ *
+ * @param target        The element whose `textContent` is searched.
+ * @param searchString  The literal string to find (case-sensitive).
+ * @returns             Array of `{from, to}` ranges, one per occurrence,
+ *                      in document order.  Empty array when there are no matches.
+ *
+ * @example
+ * const hits = findTextOccurrences(editable, 'SciFlow');
+ * for (const { from, to } of hits) {
+ *   markRange(editable, from, to, { color: '#f97316' });
+ * }
+ */
+export declare function findTextOccurrences(target: HTMLElement, searchString: string): TextRange[];
+//# sourceMappingURL=external-widget-simulator.d.ts.map

package/dist/testing/external-widget-simulator.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"external-widget-simulator.d.ts","sourceRoot":"","sources":["../../src/testing/external-widget-simulator.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4DG;AAMH,mEAAmE;AACnE,MAAM,WAAW,cAAc;IAC7B,8BAA8B;IAC9B,OAAO,EAAE,WAAW,CAAC;IACrB;;;;;OAKG;IACH,QAAQ,EAAE,IAAI,CAAC;IACf,+EAA+E;IAC/E,UAAU,EAAE,OAAO,CAAC;CACrB;AAED,qDAAqD;AACrD,MAAM,WAAW,gBAAgB;IAC/B,mEAAmE;IACnE,KAAK,CAAC,EAAE,MAAM,CAAC;IACf;;;OAGG;IACH,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,gEAAgE;IAChE,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,oEAAoE;AACpE,MAAM,WAAW,cAAc;IAC7B,yDAAyD;IACzD,IAAI,EAAE,eAAe,CAAC;IACtB,uEAAuE;IACvE,MAAM,IAAI,IAAI,CAAC;CAChB;AAED,mCAAmC;AACnC,MAAM,WAAW,gBAAgB;IAC/B,kCAAkC;IAClC,QAAQ,EAAE,MAAM,CAAC;IACjB,8CAA8C;IAC9C,QAAQ,EAAE,MAAM,CAAC;CAClB;AAMD;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAgB,QAAQ,CAAC,IAAI,GAAE,QAAQ,GAAG,OAAkB,GAAG,cAAc,EAAE,CAwC9E;AAMD;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAgB,SAAS,CACvB,MAAM,EAAE,WAAW,EACnB,IAAI,EAAE,MAAM,EACZ,EAAE,EAAE,MAAM,EACV,OAAO,GAAE,gBAAqB,GAC7B,WAAW,GAAG,IAAI,CA8CpB;AAMD;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,YAAY,CAC1B,MAAM,EAAE,WAAW,EACnB,IAAI,EAAE,MAAM,EACZ,EAAE,EAAE,MAAM,GACT,cAAc,GAAG,IAAI,CA0BvB;AAMD;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,eAAe,CAC7B,MAAM,EAAE,WAAW,EACnB,IAAI,EAAE,MAAM,EACZ,EAAE,EAAE,MAAM,EACV,WAAW,EAAE,MAAM,GAClB,gBAAgB,GAAG,IAAI,CASzB;AAMD,uEAAuE;AACvE,MAAM,WAAW,SAAS;IACxB,IAAI,EAAE,MAAM,CAAC;IACb,EAAE,EAAE,MAAM,CAAC;CACZ;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,wBAAgB,mBAAmB,CACjC,MAAM,EAAE,WAAW,EACnB,YAAY,EAAE,MAAM,GACnB,SAAS,EAAE,CAYb"}