@buoy-gg/network 7.0.12 → 7.0.14

package/lib/typescript/network/components/NetworkListScreen.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"NetworkListScreen.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkListScreen.tsx"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAIH,OAAO,EAKL,KAAK,cAAc,EACpB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,KAAK,EAAE,YAAY,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AA4E5D,UAAU,sBAAsB;IAC9B,OAAO,EAAE,OAAO,CAAC;IACjB,MAAM,EAAE,OAAO,CAAC;IAChB,MAAM,EAAE,aAAa,CAAC;IACtB,eAAe,EAAE,SAAS,cAAc,EAAE,CAAC;IAC3C,KAAK,EAAE,OAAO,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,wEAAwE;IACxE,YAAY,EAAE,CAAC,KAAK,EAAE,YAAY,KAAK,IAAI,CAAC;IAC5C,cAAc,EAAE,MAAM,IAAI,CAAC;CAC5B;AAED,wBAAgB,iBAAiB,CAAC,EAChC,OAAO,EACP,MAAM,EACN,MAAM,EACN,eAAe,EACf,KAAK,EACL,UAAU,EACV,YAAY,EACZ,cAAc,GACf,EAAE,sBAAsB,sCAkHxB"}
+{"version":3,"file":"NetworkListScreen.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkListScreen.tsx"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAIH,OAAO,EAML,KAAK,cAAc,EACpB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,KAAK,EAAE,YAAY,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AA0J5D,UAAU,sBAAsB;IAC9B,OAAO,EAAE,OAAO,CAAC;IACjB,MAAM,EAAE,OAAO,CAAC;IAChB,MAAM,EAAE,aAAa,CAAC;IACtB,eAAe,EAAE,SAAS,cAAc,EAAE,CAAC;IAC3C,KAAK,EAAE,OAAO,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,wEAAwE;IACxE,YAAY,EAAE,CAAC,KAAK,EAAE,YAAY,KAAK,IAAI,CAAC;IAC5C,cAAc,EAAE,MAAM,IAAI,CAAC;CAC5B;AAED,wBAAgB,iBAAiB,CAAC,EAChC,OAAO,EACP,MAAM,EACN,MAAM,EACN,eAAe,EACf,KAAK,EACL,UAAU,EACV,YAAY,EACZ,cAAc,GACf,EAAE,sBAAsB,sCAuJxB"}

package/lib/typescript/network/components/NetworkModal.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"NetworkModal.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkModal.tsx"],"names":[],"mappings":"AAkDA,UAAU,iBAAiB;IACzB,OAAO,EAAE,OAAO,CAAC;IACjB,OAAO,EAAE,MAAM,IAAI,CAAC;IACpB,MAAM,CAAC,EAAE,MAAM,IAAI,CAAC;IACpB,UAAU,CAAC,EAAE,CAAC,UAAU,EAAE,GAAG,KAAK,IAAI,CAAC;IACvC,2BAA2B,CAAC,EAAE,OAAO,CAAC;IACtC;;;;;;;;OAQG;IACH,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB;;;;;OAKG;IACH,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,cAAc,CAAC,EAAE,CAAC,MAAM,EAAE,OAAO,KAAK,IAAI,CAAC;CAC5C;AAopBD;;;GAGG;AACH,wBAAgB,YAAY,CAAC,KAAK,EAAE,iBAAiB,+BAMpD;AAED,MAAM,WAAW,oBAAoB;IACnC,+EAA+E;IAC/E,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,cAAc,CAAC,EAAE,CAAC,MAAM,EAAE,OAAO,KAAK,IAAI,CAAC;CAC5C;AAED;;;;;;;;;GASG;AACH,wBAAgB,eAAe,CAAC,KAAK,GAAE,oBAAyB,+BAa/D"}
+{"version":3,"file":"NetworkModal.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkModal.tsx"],"names":[],"mappings":"AAqEA,UAAU,iBAAiB;IACzB,OAAO,EAAE,OAAO,CAAC;IACjB,OAAO,EAAE,MAAM,IAAI,CAAC;IACpB,MAAM,CAAC,EAAE,MAAM,IAAI,CAAC;IACpB,UAAU,CAAC,EAAE,CAAC,UAAU,EAAE,GAAG,KAAK,IAAI,CAAC;IACvC,2BAA2B,CAAC,EAAE,OAAO,CAAC;IACtC;;;;;;;;OAQG;IACH,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB;;;;;OAKG;IACH,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,cAAc,CAAC,EAAE,CAAC,MAAM,EAAE,OAAO,KAAK,IAAI,CAAC;CAC5C;AAg1BD;;;GAGG;AACH,wBAAgB,YAAY,CAAC,KAAK,EAAE,iBAAiB,+BAMpD;AAED,MAAM,WAAW,oBAAoB;IACnC,+EAA+E;IAC/E,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,cAAc,CAAC,EAAE,CAAC,MAAM,EAAE,OAAO,KAAK,IAAI,CAAC;CAC5C;AAED;;;;;;;;;GASG;AACH,wBAAgB,eAAe,CAAC,KAAK,GAAE,oBAAyB,+BAa/D"}

package/lib/typescript/network/components/NetworkNumberPrompt.d.ts

@@ -0,0 +1,33 @@
+/**
+ * Entering one number, without the keyboard eating the screen.
+ *
+ * The custom status / delay / times fields used to be inline inputs sitting
+ * mid-form. Focusing one raises the keyboard, which on a phone covers roughly
+ * the bottom half of the tool — including, depending on where you'd scrolled,
+ * the field you were typing into and the Save button you needed next.
+ *
+ * Pinning the panel to the TOP is the fix, and it's the same one
+ * `StorageValueEditModal` reached for: a centred panel gets shoved up or
+ * covered the moment the field focuses, and a bottom sheet is simply
+ * underneath it. At the top it stays put and stays readable.
+ *
+ * Deliberately not a reuse of that component — this asks for a number and
+ * nothing else. It has no type inference, no raw-JSON escape hatch and no
+ * shape-preservation rules, so borrowing 400 lines to avoid writing 100 would
+ * be the wrong trade.
+ */
+export interface NetworkNumberPromptProps {
+    title: string;
+    /** Shown under the field — the range or unit, never a sentence. */
+    hint?: string;
+    /** Current value, or empty when nothing custom is set yet. */
+    value?: number;
+    placeholder?: string;
+    min?: number;
+    max?: number;
+    /** `null` means "cleared" — the caller decides what that means. */
+    onSubmit: (value: number | null) => void;
+    onCancel: () => void;
+}
+export declare function NetworkNumberPrompt({ title, hint, value, placeholder, min, max, onSubmit, onCancel, }: NetworkNumberPromptProps): import("react").JSX.Element;
+//# sourceMappingURL=NetworkNumberPrompt.d.ts.map

package/lib/typescript/network/components/NetworkNumberPrompt.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"NetworkNumberPrompt.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkNumberPrompt.tsx"],"names":[],"mappings":"AAIA;;;;;;;;;;;;;;;;;GAiBG;AAEH,MAAM,WAAW,wBAAwB;IACvC,KAAK,EAAE,MAAM,CAAC;IACd,mEAAmE;IACnE,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,8DAA8D;IAC9D,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,mEAAmE;IACnE,QAAQ,EAAE,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI,KAAK,IAAI,CAAC;IACzC,QAAQ,EAAE,MAAM,IAAI,CAAC;CACtB;AAED,wBAAgB,mBAAmB,CAAC,EAClC,KAAK,EACL,IAAI,EACJ,KAAK,EACL,WAAsB,EACtB,GAAG,EACH,GAAG,EACH,QAAQ,EACR,QAAQ,GACT,EAAE,wBAAwB,+BAoE1B"}

package/lib/typescript/network/components/NetworkOverrideEditor.d.ts

@@ -0,0 +1,17 @@
+import type { OverrideRuleDraft } from "../overrides/overrideRulesStore";
+export interface NetworkOverrideEditorProps {
+    draft: OverrideRuleDraft;
+    onChange: (draft: OverrideRuleDraft) => void;
+    onSave: () => void;
+    onCancel: () => void;
+    saveLabel?: string;
+    /**
+     * Pad the footer clear of the home indicator.
+     *
+     * Only true in bottom-sheet mode — a floating window doesn't sit on it, and a
+     * desktop panel has no such thing. Same gating the detail stepper uses.
+     */
+    applySafeAreaInset?: boolean;
+}
+export declare function NetworkOverrideEditor({ draft, onChange, onSave, onCancel, saveLabel, applySafeAreaInset, }: NetworkOverrideEditorProps): import("react").JSX.Element;
+//# sourceMappingURL=NetworkOverrideEditor.d.ts.map

package/lib/typescript/network/components/NetworkOverrideEditor.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"NetworkOverrideEditor.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkOverrideEditor.tsx"],"names":[],"mappings":"AAmBA,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,iCAAiC,CAAC;AA+NzE,MAAM,WAAW,0BAA0B;IACzC,KAAK,EAAE,iBAAiB,CAAC;IACzB,QAAQ,EAAE,CAAC,KAAK,EAAE,iBAAiB,KAAK,IAAI,CAAC;IAC7C,MAAM,EAAE,MAAM,IAAI,CAAC;IACnB,QAAQ,EAAE,MAAM,IAAI,CAAC;IACrB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB;;;;;OAKG;IACH,kBAAkB,CAAC,EAAE,OAAO,CAAC;CAC9B;AAED,wBAAgB,qBAAqB,CAAC,EACpC,KAAK,EACL,QAAQ,EACR,MAAM,EACN,QAAQ,EACR,SAAkB,EAClB,kBAA0B,GAC3B,EAAE,0BAA0B,+BAmZ5B"}

package/lib/typescript/network/components/NetworkOverrideHeaderButton.d.ts

@@ -0,0 +1,27 @@
+import type { OverrideRuleDraft } from "../overrides/overrideRulesStore";
+/**
+ * The Override action, in the request-detail header.
+ *
+ * A labelled word rather than an icon: every other control here is a glyph
+ * (back, pin, bookmark) and glyphs are fine for things you already know. This
+ * one is the least familiar action in the tool, and "Override" spelled out is
+ * the entire explanation.
+ *
+ * A self-subscribing leaf, for the same two reasons `NetworkDetailPinActions`
+ * is one: the modal root stays free of subscriptions, and the selected id is
+ * subscribed here so stepping between requests doesn't rebuild the header
+ * around a new prop.
+ *
+ * It lights up while a rule covers the request you're looking at — the same
+ * warning tint the OVERRIDDEN strip and the toolbar flask use, because "you are
+ * not seeing the truth" is one idea and should look like one.
+ *
+ * Tapping it goes straight to the Overrides screen with the rule open: a new
+ * one prefilled from this request, or the existing one if something already
+ * covers it. One destination, so there's never a question of where the thing
+ * you just made went.
+ */
+export declare function NetworkOverrideHeaderButton({ onOpen, }: {
+    onOpen: (draft: OverrideRuleDraft, ruleId?: string) => void;
+}): import("react").JSX.Element;
+//# sourceMappingURL=NetworkOverrideHeaderButton.d.ts.map

package/lib/typescript/network/components/NetworkOverrideHeaderButton.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"NetworkOverrideHeaderButton.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkOverrideHeaderButton.tsx"],"names":[],"mappings":"AAMA,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,iCAAiC,CAAC;AAIzE;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAgB,2BAA2B,CAAC,EAC1C,MAAM,GACP,EAAE;IACD,MAAM,EAAE,CAAC,KAAK,EAAE,iBAAiB,EAAE,MAAM,CAAC,EAAE,MAAM,KAAK,IAAI,CAAC;CAC7D,+BA8CA"}

package/lib/typescript/network/components/NetworkOverridesButton.d.ts

@@ -0,0 +1,17 @@
+/**
+ * Header button for the Overrides screen, and the always-visible "overrides
+ * are active" indicator.
+ *
+ * A self-subscribing LEAF, like the other live header pieces: the rule list
+ * changes on its own schedule (every hit bumps a counter) and the modal shell
+ * has no business re-rendering for it.
+ *
+ * The active tint is not decoration. A rule left enabled from yesterday makes
+ * the app behave wrongly in a way that looks exactly like a real bug, so the
+ * tool has to keep saying so from the top level — Chrome shows the same
+ * warning in its Overrides pane for the same reason.
+ */
+export declare function NetworkOverridesButton({ onPress }: {
+    onPress: () => void;
+}): import("react").JSX.Element;
+//# sourceMappingURL=NetworkOverridesButton.d.ts.map

package/lib/typescript/network/components/NetworkOverridesButton.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"NetworkOverridesButton.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkOverridesButton.tsx"],"names":[],"mappings":"AAIA;;;;;;;;;;;;GAYG;AACH,wBAAgB,sBAAsB,CAAC,EAAE,OAAO,EAAE,EAAE;IAAE,OAAO,EAAE,MAAM,IAAI,CAAA;CAAE,+BA4B1E"}

package/lib/typescript/network/components/NetworkOverridesScreen.d.ts

@@ -0,0 +1,29 @@
+import { type OverrideRuleDraft } from "../overrides/overrideRulesStore";
+export interface NetworkOverridesScreenProps {
+    visible: boolean;
+    isPro: boolean;
+    onUpgradePress: () => void;
+    /**
+     * A rule prefilled elsewhere (the request detail's Override action). Adopted
+     * once, then handed back via `onPendingConsumed` so re-entering the screen
+     * doesn't reopen a stale editor.
+     */
+    pendingDraft?: (OverrideRuleDraft & {
+        id?: string;
+    }) | null;
+    onPendingConsumed?: () => void;
+    /** Bottom-sheet mode only — see the editor's footer. */
+    applySafeAreaInset?: boolean;
+}
+/**
+ * Stable-router gate.
+ *
+ * The screens in `NetworkModal` are rendered as permanent siblings, and the
+ * convention there is that a HIDDEN screen must not subscribe to anything.
+ * Splitting the body out is how this one honours that: `useOverrideRules`
+ * subscribes to a store that ticks while rules are firing, and a hidden screen
+ * re-rendering for that would be pure waste. (The header's overrides button is
+ * a deliberate exception — it's always visible and its whole job is to react.)
+ */
+export declare function NetworkOverridesScreen(props: NetworkOverridesScreenProps): import("react").JSX.Element | null;
+//# sourceMappingURL=NetworkOverridesScreen.d.ts.map

package/lib/typescript/network/components/NetworkOverridesScreen.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"NetworkOverridesScreen.d.ts","sourceRoot":"","sources":["../../../../src/network/components/NetworkOverridesScreen.tsx"],"names":[],"mappings":"AAWA,OAAO,EAEL,KAAK,iBAAiB,EACvB,MAAM,iCAAiC,CAAC;AAiJzC,MAAM,WAAW,2BAA2B;IAC1C,OAAO,EAAE,OAAO,CAAC;IACjB,KAAK,EAAE,OAAO,CAAC;IACf,cAAc,EAAE,MAAM,IAAI,CAAC;IAC3B;;;;OAIG;IACH,YAAY,CAAC,EAAE,CAAC,iBAAiB,GAAG;QAAE,EAAE,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC,GAAG,IAAI,CAAC;IAC5D,iBAAiB,CAAC,EAAE,MAAM,IAAI,CAAC;IAC/B,wDAAwD;IACxD,kBAAkB,CAAC,EAAE,OAAO,CAAC;CAC9B;AAED;;;;;;;;;GASG;AACH,wBAAgB,sBAAsB,CAAC,KAAK,EAAE,2BAA2B,sCAGxE"}

package/lib/typescript/network/components/response-editor/Explorer.d.ts

@@ -0,0 +1,17 @@
+import { type JsonValue } from "@buoy-gg/shared-ui/dataViewer";
+type Props = {
+    editable?: boolean;
+    label: string;
+    value: JsonValue;
+    defaultExpanded?: string[];
+    dataPath?: string[];
+    itemsDeletable?: boolean;
+    dataVersion?: number;
+};
+/**
+ * Recursive data explorer component used for both editable and read-only JSON trees inside the
+ * React Query dev tools.
+ */
+export default function Explorer({ editable, label, value, defaultExpanded, dataPath, itemsDeletable, dataVersion, }: Props): import("react").JSX.Element;
+export {};
+//# sourceMappingURL=Explorer.d.ts.map

package/lib/typescript/network/components/response-editor/Explorer.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"Explorer.d.ts","sourceRoot":"","sources":["../../../../../src/network/components/response-editor/Explorer.tsx"],"names":[],"mappings":"AAKA,OAAO,EAAkB,KAAK,SAAS,EAAE,MAAM,+BAA+B,CAAC;AA+O/E,KAAK,KAAK,GAAG;IACX,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,SAAS,CAAC;IACjB,eAAe,CAAC,EAAE,MAAM,EAAE,CAAC;IAC3B,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAC;IACpB,cAAc,CAAC,EAAE,OAAO,CAAC;IACzB,WAAW,CAAC,EAAE,MAAM,CAAC;CACtB,CAAC;AAEF;;;GAGG;AACH,MAAM,CAAC,OAAO,UAAU,QAAQ,CAAC,EAC/B,QAAQ,EACR,KAAK,EACL,KAAK,EACL,eAAe,EACf,QAAQ,EACR,cAAc,EACd,WAAe,GAChB,EAAE,KAAK,+BAwWP"}

package/lib/typescript/network/components/response-editor/deleteNestedDataByPath.d.ts

@@ -0,0 +1,9 @@
+/**
+ * Deletes nested data by path
+ *
+ * @param {unknown} oldData Data to be updated
+ * @param {Array<string>} deletePath Path to the data to be deleted
+ * @returns newData without the deleted items by path
+ */
+export declare const deleteNestedDataByPath: (oldData: unknown, deletePath: string[]) => unknown;
+//# sourceMappingURL=deleteNestedDataByPath.d.ts.map

package/lib/typescript/network/components/response-editor/deleteNestedDataByPath.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"deleteNestedDataByPath.d.ts","sourceRoot":"","sources":["../../../../../src/network/components/response-editor/deleteNestedDataByPath.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,eAAO,MAAM,sBAAsB,GACjC,SAAS,OAAO,EAChB,YAAY,MAAM,EAAE,KACnB,OAmDF,CAAC"}

package/lib/typescript/network/components/response-editor/editorContext.d.ts

@@ -0,0 +1,29 @@
+import type { JsonValue } from "@buoy-gg/shared-ui/dataViewer";
+/**
+ * What the ported Explorer needs in place of React Query's cache.
+ *
+ * In the original, every edit ends at
+ * `queryClient.setQueryData(activeQuery.queryKey, newData)` and `activeQuery`
+ * doubles as the "is this editable" gate — so the whole tree is wired to one
+ * specific store. Here that becomes two values in context: the ROOT document
+ * (every op rebuilds the whole thing from the root, so each row needs it) and a
+ * single `onChange`.
+ *
+ * Context rather than props because Explorer recurses per node and already
+ * threads `activeQuery` down every level; swapping one drilled prop for another
+ * would have meant the same plumbing at every call site, and a row deep in a
+ * response is exactly where you don't want a missed prop.
+ */
+export interface ResponseEditorContextValue {
+    /** The whole body. Ops are computed against this, not the node's own value. */
+    root: JsonValue;
+    /** Hand back the rebuilt document. */
+    onChange: (next: JsonValue) => void;
+}
+export declare const ResponseEditorContext: import("react").Context<ResponseEditorContextValue | null>;
+/**
+ * Null outside a provider, which is how the tree stays READ-ONLY by default —
+ * the same role `activeQuery === undefined` played in the original.
+ */
+export declare function useResponseEditor(): ResponseEditorContextValue | null;
+//# sourceMappingURL=editorContext.d.ts.map

package/lib/typescript/network/components/response-editor/editorContext.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"editorContext.d.ts","sourceRoot":"","sources":["../../../../../src/network/components/response-editor/editorContext.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,+BAA+B,CAAC;AAE/D;;;;;;;;;;;;;;GAcG;AACH,MAAM,WAAW,0BAA0B;IACzC,+EAA+E;IAC/E,IAAI,EAAE,SAAS,CAAC;IAChB,sCAAsC;IACtC,QAAQ,EAAE,CAAC,IAAI,EAAE,SAAS,KAAK,IAAI,CAAC;CACrC;AAED,eAAO,MAAM,qBAAqB,4DACsB,CAAC;AAEzD;;;GAGG;AACH,wBAAgB,iBAAiB,IAAI,0BAA0B,GAAG,IAAI,CAErE"}

package/lib/typescript/network/components/response-editor/updateNestedDataByPath.d.ts

@@ -0,0 +1,10 @@
+import type { JsonValue } from "@buoy-gg/shared-ui/dataViewer";
+/**
+ * updates nested data by path
+ *
+ * @param {JsonValue} oldData Data to be updated
+ * @param {Array<string>} updatePath Path to the data to be updated
+ * @param {JsonValue} value New value
+ */
+export declare const updateNestedDataByPath: (oldData: JsonValue, updatePath: string[], value: JsonValue) => JsonValue;
+//# sourceMappingURL=updateNestedDataByPath.d.ts.map

package/lib/typescript/network/components/response-editor/updateNestedDataByPath.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"updateNestedDataByPath.d.ts","sourceRoot":"","sources":["../../../../../src/network/components/response-editor/updateNestedDataByPath.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,+BAA+B,CAAC;AAE/D;;;;;;GAMG;AACH,eAAO,MAAM,sBAAsB,GACjC,SAAS,SAAS,EAClB,YAAY,MAAM,EAAE,EACpB,OAAO,SAAS,KACf,SAiEF,CAAC"}

package/lib/typescript/network/hooks/useNetworkSelection.d.ts

@@ -0,0 +1,26 @@
+/**
+ * Narrow subscriptions to the prev/next cursor (`networkSelectionStore`).
+ *
+ * One hook per consumer, each returning the SMALLEST value that consumer
+ * renders — that is the whole point of moving the cursor into a store. The
+ * modal root takes `useHasNetworkSelection()` (a boolean that flips twice a
+ * session), so a step no longer re-renders `JsModal`, the header and all five
+ * screens; the footer and the body take the parts that actually change.
+ */
+/**
+ * Is ANYTHING selected — i.e. is the detail screen up?
+ *
+ * `useSyncExternalStore` compares the selector's result, so the root only
+ * re-renders when this boolean flips, not on every step.
+ */
+export declare function useHasNetworkSelection(): boolean;
+/** Where the USER is. Moves synchronously on tap — footer, header pin actions. */
+export declare function useSelectedNetworkEventId(): string | null;
+/** What the BODY may render. Lags `selectedId` — see networkSelectionStore. */
+export declare function useNetworkBodyEventId(): string | null;
+/** Cursor position + list length, for the "REQUEST n OF m" counter. */
+export declare function useNetworkCursor(): {
+    index: number;
+    total: number;
+};
+//# sourceMappingURL=useNetworkSelection.d.ts.map

package/lib/typescript/network/hooks/useNetworkSelection.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"useNetworkSelection.d.ts","sourceRoot":"","sources":["../../../../src/network/hooks/useNetworkSelection.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAaH;;;;;GAKG;AACH,wBAAgB,sBAAsB,IAAI,OAAO,CAMhD;AAED,kFAAkF;AAClF,wBAAgB,yBAAyB,IAAI,MAAM,GAAG,IAAI,CAMzD;AAED,+EAA+E;AAC/E,wBAAgB,qBAAqB,IAAI,MAAM,GAAG,IAAI,CAMrD;AAED,uEAAuE;AACvE,wBAAgB,gBAAgB,IAAI;IAAE,KAAK,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAYnE"}

package/lib/typescript/network/hooks/useOverrideRules.d.ts

@@ -0,0 +1,29 @@
+import { type OverrideRuleDraft, type OverrideRulesState } from "../overrides/overrideRulesStore";
+import type { OverrideRule } from "../overrides/types";
+export interface UseOverrideRulesResult extends OverrideRulesState {
+    /** Rules that would actually fire — what the "active" banner counts. */
+    activeCount: number;
+    setEnabled: (enabled: boolean) => void;
+    /**
+     * Create or replace a rule. The ONLY write path the UI uses — see
+     * `overrideRulesStore.upsertRule`: the add/update primitives don't forward to
+     * the device, so calling them from the dashboard would silently do nothing.
+     */
+    upsertRule: (draft: OverrideRuleDraft & {
+        id?: string;
+    }) => OverrideRule | null;
+    setRuleEnabled: (id: string, enabled: boolean) => void;
+    removeRule: (id: string) => void;
+    clearRules: () => void;
+    /** Has this rule burned through its `times` budget? */
+    isRuleSpent: (rule: OverrideRule) => boolean;
+}
+/**
+ * Read + mutate the override rule list.
+ *
+ * `useSyncExternalStore` over the store's own subscribe/getState, which already
+ * hands out a stable state object per mutation (see `rebuild`) — so this can't
+ * tear and doesn't need a selector to stay cheap.
+ */
+export declare function useOverrideRules(): UseOverrideRulesResult;
+//# sourceMappingURL=useOverrideRules.d.ts.map

package/lib/typescript/network/hooks/useOverrideRules.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"useOverrideRules.d.ts","sourceRoot":"","sources":["../../../../src/network/hooks/useOverrideRules.ts"],"names":[],"mappings":"AACA,OAAO,EAEL,KAAK,iBAAiB,EACtB,KAAK,kBAAkB,EACxB,MAAM,iCAAiC,CAAC;AAEzC,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,oBAAoB,CAAC;AAEvD,MAAM,WAAW,sBAAuB,SAAQ,kBAAkB;IAChE,wEAAwE;IACxE,WAAW,EAAE,MAAM,CAAC;IACpB,UAAU,EAAE,CAAC,OAAO,EAAE,OAAO,KAAK,IAAI,CAAC;IACvC;;;;OAIG;IACH,UAAU,EAAE,CAAC,KAAK,EAAE,iBAAiB,GAAG;QAAE,EAAE,CAAC,EAAE,MAAM,CAAA;KAAE,KAAK,YAAY,GAAG,IAAI,CAAC;IAChF,cAAc,EAAE,CAAC,EAAE,EAAE,MAAM,EAAE,OAAO,EAAE,OAAO,KAAK,IAAI,CAAC;IACvD,UAAU,EAAE,CAAC,EAAE,EAAE,MAAM,KAAK,IAAI,CAAC;IACjC,UAAU,EAAE,MAAM,IAAI,CAAC;IACvB,uDAAuD;IACvD,WAAW,EAAE,CAAC,IAAI,EAAE,YAAY,KAAK,OAAO,CAAC;CAC9C;AAED;;;;;;GAMG;AACH,wBAAgB,gBAAgB,IAAI,sBAAsB,CAsCzD"}

package/lib/typescript/network/overrides/__tests__/applyToFetch.test.d.ts

@@ -0,0 +1,16 @@
+/**
+ * Unit tests for the fetch-side synthesis.
+ *
+ * This layer exists because of a finding that only showed up on a real device:
+ * Expo replaces `globalThis.fetch` with a NATIVE `expo/fetch` (see
+ * `expo/src/winter/runtime.native.ts`), so those requests never construct an
+ * XMLHttpRequest and an XHR-only override silently does nothing. Verified on
+ * Expo SDK 56 / RN 0.85.3.
+ *
+ * Same self-contained harness as the other tests — see the run command in
+ * `resolveOverride.test.ts`. Excluded from the publish build by
+ * `tsconfig.build.json`.
+ */
+declare function main(): Promise<void>;
+export { main as runApplyToFetchTests };
+//# sourceMappingURL=applyToFetch.test.d.ts.map

package/lib/typescript/network/overrides/__tests__/applyToFetch.test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"applyToFetch.test.d.ts","sourceRoot":"","sources":["../../../../../src/network/overrides/__tests__/applyToFetch.test.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AA2KH,iBAAe,IAAI,kBAsBlB;AAaD,OAAO,EAAE,IAAI,IAAI,oBAAoB,EAAE,CAAC"}

package/lib/typescript/network/overrides/__tests__/applyToXhr.test.d.ts

@@ -0,0 +1,19 @@
+/**
+ * Unit tests for the XHR response synthesis, against a faithful clone of React
+ * Native's XMLHttpRequest state machine.
+ *
+ * WHY A CLONE RATHER THAN A MOCK: the interesting behaviour is not "did we set
+ * some fields", it's whether RN's own `setReadyState` / `abort` branches then
+ * do the right thing — which terminal event fires, and what `abort()` does when
+ * `_sent` is or isn't claimed. A mock that just records calls would pass while
+ * the real thing hung the app's fetch promise. `FakeRNXhr` below is transcribed
+ * from `react-native/Libraries/Network/XMLHttpRequest.js` (verified identical on
+ * RN 0.81.4 and 0.85.3), so these assertions are about real semantics.
+ *
+ * Same self-contained harness as the other tests — see the run command in
+ * `resolveOverride.test.ts`. Excluded from the publish build by
+ * `tsconfig.build.json`.
+ */
+declare function main(): Promise<void>;
+export { main as runApplyToXhrTests };
+//# sourceMappingURL=applyToXhr.test.d.ts.map

package/lib/typescript/network/overrides/__tests__/applyToXhr.test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"applyToXhr.test.d.ts","sourceRoot":"","sources":["../../../../../src/network/overrides/__tests__/applyToXhr.test.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAqYH,iBAAe,IAAI,kBAuBlB;AAaD,OAAO,EAAE,IAAI,IAAI,kBAAkB,EAAE,CAAC"}

package/lib/typescript/network/overrides/__tests__/resolveOverride.test.d.ts

@@ -0,0 +1,22 @@
+/**
+ * Unit tests for the override matcher + resolver — the pure half of the
+ * feature, and the half worth testing without a device.
+ *
+ * The glob cases mirror Chrome DevTools' own `escapeRegex` behaviour
+ * (`NetworkPersistenceManager.ts:1051`), because these patterns are the same
+ * syntax a developer already uses in Chrome's "Override headers" `applyTo`
+ * field and must not quietly mean something different here.
+ *
+ * Same self-contained harness as the perf-monitor tests (no Jest wired up yet);
+ * renames to Jest globals later. There is no `tsx` in this repo, so run it with
+ * the esbuild that is already here, from the repo root:
+ *
+ *   node_modules/.bin/esbuild <this file> --bundle --platform=node \
+ *     --format=cjs --outfile=/tmp/t.cjs && node /tmp/t.cjs
+ *
+ * `__tests__` is excluded from the publish build via `tsconfig.build.json`,
+ * so this file ships nowhere — it's developer infrastructure.
+ */
+declare function main(): Promise<void>;
+export { main as runResolveOverrideTests };
+//# sourceMappingURL=resolveOverride.test.d.ts.map

package/lib/typescript/network/overrides/__tests__/resolveOverride.test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"resolveOverride.test.d.ts","sourceRoot":"","sources":["../../../../../src/network/overrides/__tests__/resolveOverride.test.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AA0XH,iBAAe,IAAI,kBAuBlB;AAeD,OAAO,EAAE,IAAI,IAAI,uBAAuB,EAAE,CAAC"}

package/lib/typescript/network/overrides/applyToFetch.d.ts

@@ -0,0 +1,50 @@
+/**
+ * Perform an override outcome against `fetch`.
+ *
+ * WHY THIS EXISTS — and why "XHR is the single choke point" is WRONG:
+ *
+ * In bare React Native, `Libraries/Network/fetch.js` is `require('whatwg-fetch')`,
+ * so `fetch` really is a polyfill over XMLHttpRequest and hooking XHR alone
+ * would cover everything. But **Expo replaces it**: `expo/src/winter/runtime.native.ts`
+ * installs `expo/fetch` — a NATIVE fetch over `ExpoFetchModule` — as
+ * `globalThis.fetch` unless `EXPO_PUBLIC_USE_RN_FETCH=1`. Those requests never
+ * construct an XMLHttpRequest, so an XHR-only override silently does nothing on
+ * the majority of real apps.
+ *
+ * Verified the hard way on Expo SDK 56 / RN 0.85.3: rule matched, engine
+ * healthy, interceptor installed, and the request still came back a real 200.
+ *
+ * So overrides hook BOTH layers. `axios` still needs the XHR path (it uses
+ * XMLHttpRequest on every platform), and this covers `fetch` on both flavours.
+ */
+import type { OverrideOutcome } from "./types";
+export declare const sleep: (ms: number) => Promise<void>;
+/**
+ * Can we build a `Response` in this runtime?
+ *
+ * React Native installs the whatwg-fetch `Response` global via `setUpXHR`, and
+ * Expo deliberately keeps it (it only swaps `fetch`). Feature-detected anyway:
+ * without it, the honest thing is to let the request run for real.
+ */
+export declare function canSynthesizeResponse(): boolean;
+/**
+ * Build the fake `Response` an overridden `fetch` resolves with.
+ *
+ * Note the status range: whatwg-fetch's `Response` constructor THROWS
+ * `RangeError` outside [200, 599], which would crash the caller instead of
+ * overriding it. `resolveOverride` clamps before we ever get here.
+ */
+export declare function synthesizeResponse(url: string, outcome: Extract<OverrideOutcome, {
+    kind: "respond";
+}>): Response;
+/**
+ * The error a failed `fetch` rejects with.
+ *
+ * These are the exact messages whatwg-fetch produces for a dead connection and
+ * a timeout, so app code that string-matches on them (plenty does) behaves the
+ * same way it would against a real failure.
+ */
+export declare function synthesizeFetchError(outcome: Extract<OverrideOutcome, {
+    kind: "fail";
+}>): Error;
+//# sourceMappingURL=applyToFetch.d.ts.map

package/lib/typescript/network/overrides/applyToFetch.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"applyToFetch.d.ts","sourceRoot":"","sources":["../../../../src/network/overrides/applyToFetch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,SAAS,CAAC;AAE/C,eAAO,MAAM,KAAK,GAAI,IAAI,MAAM,KAAG,OAAO,CAAC,IAAI,CAGxB,CAAC;AAExB;;;;;;GAMG;AACH,wBAAgB,qBAAqB,IAAI,OAAO,CAE/C;AAED;;;;;;GAMG;AACH,wBAAgB,kBAAkB,CAChC,GAAG,EAAE,MAAM,EACX,OAAO,EAAE,OAAO,CAAC,eAAe,EAAE;IAAE,IAAI,EAAE,SAAS,CAAA;CAAE,CAAC,GACrD,QAAQ,CAeV;AAED;;;;;;GAMG;AACH,wBAAgB,oBAAoB,CAClC,OAAO,EAAE,OAAO,CAAC,eAAe,EAAE;IAAE,IAAI,EAAE,MAAM,CAAA;CAAE,CAAC,GAClD,KAAK,CAMP"}

package/lib/typescript/network/overrides/applyToXhr.d.ts

@@ -0,0 +1,43 @@
+/**
+ * Perform an override outcome against a React Native XMLHttpRequest.
+ *
+ * WHY THIS IS POSSIBLE AT ALL: React Native's XMLHttpRequest
+ * (`react-native/Libraries/Network/XMLHttpRequest.js`) is pure JavaScript.
+ * `readyState`, `status`, `responseHeaders` and `responseURL` are plain
+ * writable fields, and `setResponseHeaders()` / `setReadyState()` are real
+ * methods — `setReadyState(DONE)` dispatches the correct terminal event off
+ * internal flags (`_aborted` → abort, `_hasError` + `_timedOut` → timeout,
+ * `_hasError` → error, otherwise load; always loadend). So a response can be
+ * synthesized end to end without touching native code.
+ *
+ * WHY XHR IS THE ONLY PLACE WE HOOK: `react-native/Libraries/Network/fetch.js`
+ * is `require('whatwg-fetch')` — RN's `fetch` IS the polyfill over
+ * XMLHttpRequest. Overriding here therefore covers `fetch`, `axios` and raw
+ * XHR through one code path, and the fake response flows back up through the
+ * polyfill so the tool records it without any extra plumbing.
+ *
+ * Verified field-for-field on React Native 0.81.4 and 0.85.3.
+ *
+ * Four non-obvious behaviours are handled below; each one is a real bug if you
+ * skip it, and each is commented at the line that fixes it.
+ */
+import type { OverrideOutcome } from "./types";
+/**
+ * Can this XMLHttpRequest be driven by hand?
+ *
+ * The whole technique rests on RN internals, so it is feature-detected rather
+ * than assumed: on a browser XMLHttpRequest (react-native-web) these methods
+ * don't exist and `status` is a read-only getter. There, overrides no-op and
+ * the request goes out for real — degraded, but never broken.
+ */
+export declare function canSynthesize(xhr: XMLHttpRequest): boolean;
+/**
+ * Apply an outcome to a request that has NOT been sent yet.
+ *
+ * Returns `false` when this environment can't be driven by hand, in which case
+ * the caller must send the request normally.
+ *
+ * @param passThrough Sends the real request. Only used by `kind: "delay"`.
+ */
+export declare function runOverride(xhr: XMLHttpRequest, url: string, outcome: OverrideOutcome, passThrough: () => void): boolean;
+//# sourceMappingURL=applyToXhr.d.ts.map

package/lib/typescript/network/overrides/applyToXhr.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"applyToXhr.d.ts","sourceRoot":"","sources":["../../../../src/network/overrides/applyToXhr.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,SAAS,CAAC;AAkC/C;;;;;;;GAOG;AACH,wBAAgB,aAAa,CAAC,GAAG,EAAE,cAAc,GAAG,OAAO,CAM1D;AA+ED;;;;;;;GAOG;AACH,wBAAgB,WAAW,CACzB,GAAG,EAAE,cAAc,EACnB,GAAG,EAAE,MAAM,EACX,OAAO,EAAE,eAAe,EACxB,WAAW,EAAE,MAAM,IAAI,GACtB,OAAO,CAiET"}

package/lib/typescript/network/overrides/engine.d.ts

@@ -0,0 +1,47 @@
+/**
+ * The seam between the interceptor and the rule store.
+ *
+ * It exists to keep the import graph acyclic: `networkListener` needs rules,
+ * and the rule store needs the listener (to keep the swizzle installed while a
+ * rule is active). Rather than have them import each other, the store REGISTERS
+ * itself here and the listener asks here. Both sides import only this leaf.
+ *
+ * It's also the single place the production gate lives — see `overrideForRequest`.
+ */
+import type { OverrideOutcome, OverrideRule } from "./types";
+export interface OverrideHooks {
+    getRules: () => readonly OverrideRule[];
+    /** The rule APPLIED to a request. */
+    recordHit: (ruleId: string) => void;
+    /**
+     * The rule MATCHED a request, whether or not it applied.
+     *
+     * `alternate` needs this: a rule that only counted the requests it overrode
+     * would never advance past its off phase, so it would skip forever.
+     */
+    recordMatch: (ruleId: string) => void;
+}
+export declare function setOverrideHooks(next: OverrideHooks | null): void;
+/**
+ * Diagnostics for the sync adapter's `debugOverrides` action.
+ *
+ * Reads the engine's own view of the world — crucially `hooks`, which is
+ * MODULE state here: if the interceptor and the rule store ever ended up with
+ * separate copies of this file, this is the only place that shows it.
+ */
+export declare function inspectEngine(url: string, method: string): {
+    hooksInstalled: boolean;
+    devFlag: string | boolean;
+    ruleCount: number;
+    matches: boolean;
+};
+/**
+ * Resolve an override for one outgoing request, recording the hit.
+ *
+ * NEVER ACTIVE IN A PRODUCTION BUILD. A shipped app that synthesizes 500s or
+ * silently swallows requests is a catastrophe of a different order than a
+ * broken dev tool, so the gate is here — at the single entry point — rather
+ * than trusted to every call site.
+ */
+export declare function overrideForRequest(url: string, method: string): OverrideOutcome | null;
+//# sourceMappingURL=engine.d.ts.map

package/lib/typescript/network/overrides/engine.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"engine.d.ts","sourceRoot":"","sources":["../../../../src/network/overrides/engine.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAOH,OAAO,KAAK,EAAE,eAAe,EAAE,YAAY,EAAE,MAAM,SAAS,CAAC;AAE7D,MAAM,WAAW,aAAa;IAC5B,QAAQ,EAAE,MAAM,SAAS,YAAY,EAAE,CAAC;IACxC,qCAAqC;IACrC,SAAS,EAAE,CAAC,MAAM,EAAE,MAAM,KAAK,IAAI,CAAC;IACpC;;;;;OAKG;IACH,WAAW,EAAE,CAAC,MAAM,EAAE,MAAM,KAAK,IAAI,CAAC;CACvC;AAID,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,aAAa,GAAG,IAAI,GAAG,IAAI,CAEjE;AAED;;;;;;GAMG;AACH,wBAAgB,aAAa,CAAC,GAAG,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM;;;;;EAWxD;AAED;;;;;;;GAOG;AACH,wBAAgB,kBAAkB,CAChC,GAAG,EAAE,MAAM,EACX,MAAM,EAAE,MAAM,GACb,eAAe,GAAG,IAAI,CAqBxB"}

package/lib/typescript/network/overrides/matchRule.d.ts

@@ -0,0 +1,22 @@
+/**
+ * Glob matching for override rules — a faithful port of Chrome DevTools'.
+ *
+ * Ported from `NetworkPersistenceManager.ts:1051` + `StringUtilities.ts:9` in
+ * the devtools-frontend source. Ported rather than reinvented on purpose: `*`
+ * globs are the syntax developers already have in their fingers from Chrome's
+ * "Override headers" `applyTo` field, and a pattern that behaves differently
+ * here than it does in the browser would be a quiet trap.
+ */
+import type { OverrideRule } from "./types";
+/**
+ * Escape a glob into regex source: neutralize regex metacharacters, then
+ * promote `*` to `.*`.
+ *
+ * `split`/`join` rather than `replaceAll` — same result, no reliance on how
+ * complete a given Hermes build's ES2021 surface is.
+ */
+export declare function escapeRegex(pattern: string): string;
+export declare function compilePattern(pattern: string): RegExp;
+/** Does this rule apply to this request? Ignores `enabled` — callers check it. */
+export declare function ruleMatches(rule: OverrideRule, url: string, method: string): boolean;
+//# sourceMappingURL=matchRule.d.ts.map

package/lib/typescript/network/overrides/matchRule.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"matchRule.d.ts","sourceRoot":"","sources":["../../../../src/network/overrides/matchRule.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,SAAS,CAAC;AAU5C;;;;;;GAMG;AACH,wBAAgB,WAAW,CAAC,OAAO,EAAE,MAAM,GAAG,MAAM,CAUnD;AAWD,wBAAgB,cAAc,CAAC,OAAO,EAAE,MAAM,GAAG,MAAM,CAatD;AAED,kFAAkF;AAClF,wBAAgB,WAAW,CACzB,IAAI,EAAE,YAAY,EAClB,GAAG,EAAE,MAAM,EACX,MAAM,EAAE,MAAM,GACb,OAAO,CAWT"}