dsh-plugin-shop 0.8.7 → 0.9.0-beta.2

package/lib/types/client/present.d.ts

@@ -36,9 +36,9 @@ export declare function installPhaseKey(phase: 'downloading' | 'installing'): Sh
 /** Why the shop cannot restart dsh, as a locale key.
  *
  * A sibling of `activationNoticeKey` and exhaustive for the same reason: the
- * switch has no default, so a fourth reason added to `RestartBlockedReason` is
- * a type error here rather than a card that silently keeps the third one's
- * copy. That is the whole point of the type — the single boolean this replaced
+ * switch has no default, so a reason added to `RestartBlockedReason` is a type
+ * error here rather than a card that silently keeps a neighbour's copy. That
+ * is the whole point of the type — the single boolean this replaced
  * had ONE string for three causes, and it named systemd, so a Windows reader
  * was told to restart a service they do not run and to set an override that
  * could not have helped. */
@@ -146,10 +146,12 @@ export declare function refusesInstall(blockers: readonly {
     kind: BlockerKind;
 }[]): boolean;
 /**
- * The refused peers as the refusal's copy names them: each peer and the range
- * the package declared, in the order dsh reported them. A blank range — which
- * dsh refuses — is quoted, or the sentence would name the peer and nothing
- * it asked for.
+ * The refused requirements as the refusal's copy names them: each one and the
+ * range the package declared, in the order dsh reported them. A peer is named
+ * by its package. `engines.dsh` is a manifest path, not a name anyone asked
+ * for, so it reads as `dsh` and its range, the way the sentence says "it
+ * requires dsh >=0.3.0". A blank range — which dsh refuses — is quoted, or the
+ * sentence would name the requirement and nothing it asked for.
  */
 export declare function refusedPeersText(refused: Readonly<Record<string, string>>): string;
 /**
@@ -233,8 +235,9 @@ export interface InstallStatusShape {
 /** The install view state machine (§7.2). `phase` distinguishes the download
  * that runs ahead of the per-profile mutex from the install that holds it.
  * It rides the `running` kind rather than adding a kind of its own: every
- * `view.kind === 'running'` site — `useInstall.ts`'s poll collection among
- * them — must keep treating a downloading install as live. */
+ * `view.kind === 'running'` site — the flow registry's poll collection
+ * (flow-registry.ts) among them — must keep treating a downloading install
+ * as live. */
 export type InstallView = {
     kind: 'idle';
 } | {
@@ -328,12 +331,23 @@ export declare function restartMonitorVerdict(input: {
  * a host older than the field, the one that matters most.
  */
 export declare function answeredByAnotherProcess(previous: ShopVersionResult, next: ShopVersionResult): boolean;
+/**
+ * Whether an update of the shop has landed and waits for a restart: the
+ * profile holds a version other than the one running. A host older than the
+ * field sends none, and that reads as waiting: a client newer than its host
+ * exists only because the disk holds a newer shop than the process running
+ * (design §7.3, 2026-09-27 amendment). The tab's restart offer and the
+ * hand-over after a hot swap (design 2026-10-16-shop-sidebar-page §6) read
+ * it alike.
+ */
+export declare function updateAwaitsRestart(version: ShopVersionResult): boolean;
 /**
  * Whether dsh restarting under the page settles this receipt: a change that
- * landed and was waiting for exactly that. The tab clears these once the
- * answers come from another process, and nothing else — a reload is still
- * owed by a page nobody reloaded, a failure still happened, and a flow still
- * running settles by its own poll.
+ * landed and was waiting for exactly that. The page store clears these
+ * (page-store.ts, `noteRestarted`) once the answers come from another
+ * process, and nothing else — a reload is still owed by a page nobody
+ * reloaded, a failure still happened, and a flow still running settles by
+ * its own poll.
  */
 export declare function settledByRestart(view: InstallView): boolean;
 /** How long the check-update button reports "up to date" after a re-check
@@ -456,6 +470,14 @@ export declare function npmPageUrl(entry: CatalogEntry): string | null;
  * This mirrors the registry's identity verbatim; the two must not drift.
  */
 export declare function entryKey(entry: CatalogEntry): string;
+/**
+ * Whether the shelf lists `entry`: a name the catalog's `notAShop` clears,
+ * or one whose name and repository `isShopLike` leaves alone. One rule for
+ * the shelf and for the Plugins page's "View in Plugin shop" (design
+ * 2026-10-16-shop-sidebar-page §7), so that button never sends a reader to a
+ * shelf that hides the plugin.
+ */
+export declare function listedOnShelf(entry: CatalogEntry, cleared: ReadonlySet<string>): boolean;
 /**
  * One entry's star count from the sidecar, or undefined when it has none.
  *

package/lib/types/client/restart-monitor.d.ts

@@ -72,6 +72,17 @@ export type RestartRequestOutcome = {
 } | {
     kind: 'unreachable';
 };
+/**
+ * Whether a shop instance on this page has registered its restart path:
+ * every `apply` since 0.8.4 does so before anything can ask for a restart.
+ * Read before this instance's own `apply` registers one, a store here names
+ * a predecessor — a 0.8.x shop when no page store sits beside it
+ * (page-store.ts `readPredecessor`; design 2026-10-16-shop-sidebar-page §6).
+ * The store outlives a carrier's withdrawal: a predecessor's teardown
+ * withdraws its carrier and leaves the store, and the store is what names it.
+ * Only a read: unlike `monitorStore`, it never creates the store.
+ */
+export declare function hasRestartMonitorStore(): boolean;
 /** The page's restart, or null when it has committed none. The same object
  * until the state changes, as `useSyncExternalStore` requires. */
 export declare function readRestartMonitor(): RestartMonitorState | null;

package/lib/types/client/useFlows.d.ts

@@ -1,5 +1,6 @@
 /**
- * One keyed registry of install-shaped flows: start, poll to terminal, reset.
+ * React's view of a keyed registry of install-shaped flows (flow-registry.ts):
+ * start, poll to terminal, reset.
  *
  * Install and uninstall are the same machine. Both fold a
  * `ShopInstallStatusResult` through `reduceInstall` into an `InstallView`,
@@ -12,16 +13,22 @@
  * install refusal is a `rejected` view carrying the gate's code; an uninstall
  * refusal is a `failed` view carrying the host's published detail, because
  * `ShopUninstallResult`'s failure variant has no code to populate and those
- * codes belong to the install gate. That difference is the `begin` parameter,
- * and it is the whole of it.
+ * codes belong to the install gate. That difference is the registry's
+ * `begin`, and it is the whole of it.
  *
  * The two used to be hand-synced copies — 71 of 84 lines identical. The cost
  * was not theoretical: a single review round had to make the same edit twice
  * (the settle signature, and its call), and the `pending` set below was added
  * to one of them and not the other before this module existed.
+ *
+ * Since 2026-10-16 the registry is its own module, framework-free, and the
+ * polling belongs to it: a component's effect stopped the moment the shop left
+ * the screen (design 2026-10-16-shop-sidebar-page §5). This module only
+ * renders one, through `useRegistryFlows`.
  */
-import type { ShopInstallStatusResult } from '../host/index.ts';
-import { type InstallView } from './present.ts';
+import type { InstallArgs } from '../host/index.ts';
+import { type FlowRegistry } from './flow-registry.ts';
+import type { InstallView } from './present.ts';
 /** One identity's flow, as the tab hands it to a panel. */
 export interface KeyedFlow<TArgs> {
     view: InstallView;
@@ -39,16 +46,13 @@ export interface UseKeyedFlows<TArgs> {
      * moves. The accessor's identity still tracks `views`; the result's does
      * not, and the result is what a card should be given. */
     flowFor: (key: string) => KeyedFlow<TArgs>;
-    /** Return one identity to `idle` without building a flow for it. Stable
-     * across renders (unlike `flowFor`, whose identity tracks `views`), so one
-     * registry's settle callback can supersede the other's receipt for the same
-     * key without taking a dependency on that registry's output. */
-    resetFlow: (key: string) => void;
     /** Return every identity whose view `predicate` selects to `idle`, and
-     * nothing else. Stable across renders like `resetFlow`; a call selecting
+     * nothing else. Stable across renders, unlike `flowFor`; a call selecting
      * nothing leaves the registry — and so every flow and `pending` — exactly
-     * as it was. The tab clears the receipts dsh restarting under it settled
-     * with this (design §8, 2026-10-06 amendment). */
+     * as it was. The receipts dsh restarting under the page settled are
+     * cleared the same way at the store, through each registry's own
+     * `resetWhere` (page-store.ts `noteRestarted`; design §8, 2026-10-06
+     * amendment). */
     resetWhere: (predicate: (view: InstallView) => boolean) => void;
     /**
      * The identities whose flow is not `idle` — asked by the shelf, which has
@@ -65,16 +69,20 @@ export interface UseKeyedFlows<TArgs> {
      */
     pending: ReadonlySet<string>;
 }
-/**
- * @param begin the starting RPC and its answer, mapped to the first view.
- *   Never rejects: a transport throw is the caller's to fold into a view,
- *   because only the caller knows which localized line stands in for a detail
- *   too private to render.
- * @param onSettled called once per identity that reaches a terminal state,
- *   with WHICH terminal state. The outcome is load-bearing: a failed flow
- *   changed nothing on the server, so a caller acting on "settled" alone
- *   discards outcomes that are still true.
- */
-export declare function useKeyedFlows<TArgs>(begin: (args: TArgs) => Promise<InstallView>, installStatus: (args: {
-    installId: string;
-}) => Promise<ShopInstallStatusResult>, onSettled?: (key: string, outcome: 'done' | 'failed') => void): UseKeyedFlows<TArgs>;
+/** One entry's install flow, as the tab hands it to a panel: the page
+ * store's install registry (page-store.ts), begun through flow-registry.ts's
+ * `beginInstall`. */
+export type InstallFlow = KeyedFlow<InstallArgs>;
+/** One entry's uninstall flow, as the tab hands it to a panel: the page
+ * store's uninstall registry, begun through `beginUninstall`. */
+export type UninstallFlow = KeyedFlow<{
+    name: string;
+}>;
+/** The uninstall flows as the tab hands them to the shadowed rows. */
+export type UseUninstallFlows = UseKeyedFlows<{
+    name: string;
+}>;
+/** The keyed-flow face over any registry: one of the page store's, which
+ * outlives the component, or one of the store a tab builds for itself when
+ * none is handed over (ShopTab). */
+export declare function useRegistryFlows<TArgs>(registry: FlowRegistry<TArgs>): UseKeyedFlows<TArgs>;

package/lib/types/client/useUpdateSelf.d.ts

@@ -1,25 +1,28 @@
-/** Self-update driving hook for the shop itself: start, poll to terminal.
- * Shares the install view machine and poll loop; the start mapping is the
- * uninstall one — a business refusal (a non-semver version) lands in the
- * `failed` view with the host's detail, never in the install `rejected`
- * codes. */
-import type { ShopInstallStatusResult, ShopUpdateResult } from '../host/index.ts';
-import { type InstallView } from './present.ts';
+/** The shop's own update as the tab renders it: the face over the registry
+ * that holds it, a page store's `self` (page-store.ts). It shares the install
+ * view machine and the registry's polling; its start mapping is
+ * flow-registry.ts's `beginUpdate`, which shares the uninstall's refusal
+ * rule — a business refusal (a non-semver version) lands in the `failed`
+ * view with the host's detail, never in the install `rejected` codes. */
+import type { FlowRegistry } from './flow-registry.ts';
+import type { InstallView } from './present.ts';
 export interface UseUpdateSelfResult {
     view: InstallView;
     start: (args: {
         version: string;
     }) => Promise<void>;
     /** Return the view to `idle` when `predicate` selects it; stable across
-     * renders. The keyed registries' `resetWhere`, for the one self-update:
-     * dsh restarting under the page settles an update that was waiting for
-     * exactly that (design §8, 2026-10-06 amendment). */
+     * renders. The failed panel's Dismiss uses it, so the version row decides
+     * again; an update waiting for a restart is settled at the store instead,
+     * when dsh restarts under the page (page-store.ts `noteRestarted`; design
+     * §8, 2026-10-06 amendment). */
     resetWhere: (predicate: (view: InstallView) => boolean) => void;
 }
-/** Drive one self-update: the host's business union, the shared polling
- * loop, and terminal states. The `rejected` install state never occurs. */
-export declare function useUpdateSelf(updateStart: (args: {
+/** The one key the self-update registry holds: the shop has one update. */
+export declare const SELF_UPDATE_KEY = "self";
+/** The self-update face over a registry: the keyed-flow face
+ * (`useRegistryFlows`) at its one key, so the subscription and the flow's
+ * identity are that hook's and nothing here can drift from it. */
+export declare function useRegistrySelf(registry: FlowRegistry<{
     version: string;
-}) => Promise<ShopUpdateResult>, installStatus: (args: {
-    installId: string;
-}) => Promise<ShopInstallStatusResult>): UseUpdateSelfResult;
+}>): UseUpdateSelfResult;

package/lib/types/host/harness.d.ts

@@ -28,13 +28,19 @@
  */
 import { type ProfileTemplates } from './compatibility.ts';
 /** One package's harness peers as the running dsh judges them: app-boot's
- * `evaluatePluginCompatibility` result, the shape 0.1.7 returns. */
+ * `evaluatePluginCompatibility` result, in the shape 0.1.7 returns, whichever
+ * name the running dsh gives its list (`peerCheckOf`). */
 export interface PeerIssue {
     name: string;
     version: string;
     /** The dsh version the check judged against — app-boot's own. */
     runtimeVersion: string;
-    /** The refused peers, each with the range the package declared. */
+    /** What the package asked of dsh and the running one does not meet, each
+     * with the range the package declared. A key is a dsh peer's package name,
+     * or the literal `engines.dsh`. dsh names this list `requirements` from
+     * 0.2.1 and `peers` before it (design 2026-10-19-dsh-021-readiness, section
+     * 4); `refusedRequirements` reads either into this field, so every consumer
+     * keeps reading the one name. */
     peers: Record<string, string>;
     /** Whether the profile holds dsh's exact-version exemption for this
      * package on this dsh, in which case dsh accepts the install anyway. */
@@ -84,6 +90,24 @@ export interface RunningHarness {
      * not be read — no verdict either way. */
     peerCheck: PeerCheck | null;
 }
+/**
+ * The list a refusal names, read off one answer of dsh's compatibility check
+ * or of its plugin manager, under whichever name the dsh that gave the answer
+ * uses: `requirements` from 0.2.1, `peers` from 0.1.7 to 0.2.0. app-boot's
+ * `evaluatePluginCompatibility` and dsh-plugin-manager's `IncompatiblePlugin`
+ * were renamed together (design 2026-10-19-dsh-021-readiness, section 4, read
+ * off 0.2.1-rc.2's own types and code on 2026-10-19). A key is a dsh peer's
+ * package name or the literal `engines.dsh`; a value is the range the package
+ * declared.
+ *
+ * `requirements` is read first, and only when it holds an object: an answer
+ * whose `requirements` is anything else is not in the newer shape, so its
+ * `peers` is tried. Only the entries whose range is a string are kept, as
+ * `incompatibleList` always kept them, so one malformed range costs its own
+ * entry and not the rest of the list. An answer naming neither reads as an
+ * empty list, never as a throw.
+ */
+export declare function refusedRequirements(answer: Readonly<Record<string, unknown>>): Record<string, string>;
 /**
  * The harness this process runs, identified from `script` — the gateway's
  * `restartScript`, `process.argv[1]` in production — or nothing, never a

package/lib/types/host/index.d.ts

@@ -211,7 +211,7 @@ export type ShopRestartResult = RestartOutcome;
  * restart was impossible after it had become possible. Static here, dynamic
  * there; the split is the whole reason this is a separate predicate rather
  * than a cache of `restart()`'s answer. */
-export type RestartBlockedReason = 'desktop' | 'windows' | 'systemd' | 'port-zero';
+export type RestartBlockedReason = 'desktop' | 'from-default-profile' | 'windows' | 'systemd' | 'port-zero';
 /** `shop/version` result (§7.3): the RUNNING shop version (from the shipped
  * package.json, not the manifest's range), the npm latest when the check
  * could answer (`null` = no answer — advisory, never an error), and the
@@ -618,14 +618,32 @@ export declare class ShopGateway extends TypertRemoteService {
      *
      * The order is load-bearing for the copy a reader sees. The desktop
      * profile first: dsh itself refuses to launch it, so no platform,
-     * supervisor or port could make a restart possible there. Then Windows,
-     * because the platform check has no override and reporting the systemd one
-     * there sends a Windows user to set `allowRestart: true`, which this gate
-     * would still refuse.
+     * supervisor or port could make a restart possible there, and the remedy
+     * is the app. Then `from-default-profile` and Windows, both ahead of
+     * systemd, because neither has an override and reporting the systemd one
+     * there sends the reader to set `allowRestart: true`, which this gate would
+     * still refuse. And `from-default-profile` ahead of Windows, because every
+     * remedy after `desktop` is "restart dsh manually", which a reader launched
+     * with the flag would do with the flag, and on 0.2.1 that recreates the
+     * profile: its copy is the one that says "without that flag", and a
+     * Windows, systemd or `--port 0` reader needs it as much as any other.
      *
      * - `desktop`: dsh's CLI refuses `--profile desktop` ("managed exclusively
      *   by the Electron application"), so the relaunch would exit at once and
      *   leave nothing on the port; the app restarts it.
+     * - `from-default-profile`: from dsh 0.2.1, `--from-default-profile <name>`
+     *   replaces an existing custom profile with a fresh copy of the shipped
+     *   template on every launch, and the relaunch re-runs this argv verbatim,
+     *   so it would delete every plugin in the profile, this shop included.
+     *   Measured 2026-10-19 in throwaway homes: 0.2.1-rc.2 booted a relaunched
+     *   profile that had held the shop with no dependencies, while 0.2.0-rc.2
+     *   refused to boot an existing profile at all, so there the restarted dsh
+     *   failed to come back. Both spellings are the flag:
+     *   `--from-default-profile <name>` and `--from-default-profile=<name>`. It
+     *   is left in the argv rather than stripped: the restarted process would no
+     *   longer run the command the reader chose, and their next launch with the
+     *   flag recreates the profile anyway. No override (design
+     *   2026-10-19-dsh-021-readiness §3).
      * - `windows`: the handoff helper is a POSIX shell one-liner (restart.ts)
      *   and there is no `sh` on Windows. That spawn fails ASYNCHRONOUSLY, so
      *   committing would answer `ok: true`, exit this process, and leave nothing
@@ -633,7 +651,7 @@ export declare class ShopGateway extends TypertRemoteService {
      * - `systemd`: under a unit the two-phase handoff kills itself, because the
      *   main process exiting also kills the unit's cgroup and takes the detached
      *   helper with it; the service never comes back. Overridable, and the only
-     *   one of the three that is.
+     *   one that is.
      * - `port-zero`: the OS hands the NEW process a fresh port the browser
      *   cannot know, so a restart would strand the client on a dead origin. */
     private staticRestartBlock;
@@ -668,6 +686,15 @@ export declare class ShopGateway extends TypertRemoteService {
      * passing request reaches the executor.
      */
     install(args: InstallArgs): Promise<ShopInstallResult>;
+    /**
+     * One install of `name` through dsh's CLI, `dsh plugin --profile <p> add
+     * <spec>` (§7.2): the path every install takes when dsh offers no plugin
+     * manager, and the one that continues an update the manager refuses in
+     * place (design 2026-10-19-dsh-021-readiness §2). `alreadyImported` is
+     * whether this process may already hold the package's module, which rules
+     * out a hot mount. The caller tracks the record and records any pin, once.
+     */
+    private startCliInstall;
     /**
      * What would stop the profile from starting now that `name`'s files are on
      * disk, or null: an entry id another installed package already declares,
@@ -790,5 +817,11 @@ export declare class ShopGateway extends TypertRemoteService {
     updateStart(args: {
         version: string;
     }): Promise<ShopUpdateResult>;
+    /** The shop's own update through dsh's CLI: the path when dsh offers no
+     * plugin manager, and the one that continues a self-update the manager
+     * refuses in place (design 2026-10-19-dsh-021-readiness §2). It passes no
+     * `afterDone`, so it reports a restart: a host half cannot swap itself live
+     * (§8). The caller tracks the record. */
+    private startCliSelfUpdate;
 }
 export default ShopGateway;

package/lib/types/host/manager-runner.d.ts

@@ -49,3 +49,27 @@ export interface ManagerOperationOptions {
  * can throw, and a null-prototype object has no conversion to a string. */
 export declare const messageOf: (error: unknown) => string;
 export declare function startManagerOperation(options: ManagerOperationOptions): RunningInstall;
+/**
+ * `first`, continued by the record `next` starts when `first` ends refused,
+ * as one record under `first`'s id: design 2026-10-19-dsh-021-readiness,
+ * section 2. dsh-plugin-manager 0.2.1-rc.2 refuses an update in place as
+ * `already-installed`, and the gateway continues such an update through
+ * dsh's CLI. One record, so the client keeps polling the id it was given,
+ * and the restart gate and eviction, which read every tracked record, see
+ * the command that runs.
+ *
+ * While `first` runs, this is `first`. Whether it continues is decided once,
+ * when `first` ends: the first `status()` read or `first.finished` settling
+ * that sees `first` terminal asks `refused`, and that answer is kept. So a
+ * caller may set its flag while reading the answer that ends `first`, and a
+ * flag flipped after that changes neither `status()` nor `finished`, which
+ * answer from that one decision. Not refused, this stays `first`. Refused,
+ * `next` runs, exactly once, at that same read or finish, so no read between
+ * the refusal and the next command reports the refusal. From then on the
+ * record is `next`'s, its state, detail and activation, with `first`'s log,
+ * then `bridge`, then `next`'s log. That log joins two bounded logs and the
+ * bridge, so a continued record can carry about twice `MAX_LOG_LINES` and
+ * `MAX_LOG_BYTES`, where one record of `startManagerOperation` carries at most
+ * one line over them.
+ */
+export declare function continueAfter(first: RunningInstall, refused: () => boolean, next: () => RunningInstall, bridge: string): RunningInstall;

package/lib/types/host/plugin-manager.d.ts

@@ -24,6 +24,11 @@ export interface PluginManagerLike {
  * All or nothing: half a service would take an install and fail its
  * uninstall. */
 export declare function asPluginManager(service: unknown): PluginManagerLike | null;
+/** One entry of dsh's `incompatible` list. `peers` is what the package
+ * declared and the running dsh does not meet, read under whichever name that
+ * dsh gives it, `requirements` from 0.2.1 and `peers` before
+ * (`refusedRequirements`): a key is a dsh peer's package name or
+ * `engines.dsh`. */
 export interface ManagerIncompatible {
     name: string;
     version: string;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-plugin-shop",
-  "version": "0.8.7",
+  "version": "0.9.0-beta.2",
   "description": "The DeepSeek Harness plugin shop: browse, install, enable, and update dsh plugins from a git-auditable catalog.",
   "icon": "./assets/icon.png",
   "keywords": [

package/lib/types/client/ShopSection.d.ts

@@ -1,10 +0,0 @@
-/**
- * The shop's Settings section (design §5.1, amended 2026-10-15): its own
- * entry in the Settings nav, directly after Built-in plugins, where it used
- * to be a tab inside that section. The page carries the title and the one
- * intro line the built-in Models and Built-in plugins pages carry, above the
- * shop body, which is `ShopTab` unchanged.
- */
-import type { ReactNode } from 'react';
-import { type ShopTabProps } from './ShopTab.tsx';
-export declare function ShopSection(props: ShopTabProps): ReactNode;

package/lib/types/client/useInstall.d.ts

@@ -1,31 +0,0 @@
-/** Install driving hooks: the shared poll loop, and the tab's keyed registry. */
-import { type Dispatch, type SetStateAction } from 'react';
-import { type InstallView } from './present.ts';
-import { type KeyedFlow, type UseKeyedFlows } from './useFlows.ts';
-import type { InstallArgs, ShopInstallResult, ShopInstallStatusResult } from '../host/index.ts';
-/** The single-view poll loop: while the view is `running`, poll once per
- * second and fold each status through the reducer. A poll failure is
- * transient — the host retains the record, so the next tick finds it. The
- * rejection handler must be present: an unhandled rejection here would
- * escape the poll loop.
- *
- * Kept for the self-update (`useUpdateSelf`), which drives ONE flow with no
- * identity to key it by. Everything per-plugin goes through `useKeyedFlows`,
- * whose own loop polls every running identity from one interval. */
-export declare function usePollStatus(view: InstallView, setView: Dispatch<SetStateAction<InstallView>>, installStatus: (args: {
-    installId: string;
-}) => Promise<ShopInstallStatusResult>): void;
-/** One entry's install flow, as the tab hands it to a panel. */
-export type InstallFlow = KeyedFlow<InstallArgs>;
-export type UseInstallFlows = UseKeyedFlows<InstallArgs>;
-/**
- * Install flows owned by the tab and keyed by install identity. Keeping the
- * state above individual cards preserves a running operation when filtering
- * unmounts its card, and makes the shelf and Outdated panels agree.
- *
- * The registry itself is `useKeyedFlows`; this supplies the one thing that is
- * install-specific — what the starting RPC's answer means.
- */
-export declare function useInstallFlows(install: (args: InstallArgs) => Promise<ShopInstallResult>, installStatus: (args: {
-    installId: string;
-}) => Promise<ShopInstallStatusResult>, onSettled?: (key: string, outcome: 'done' | 'failed') => void): UseInstallFlows;

package/lib/types/client/useUninstall.d.ts

@@ -1,28 +0,0 @@
-/** Uninstall driving hook: the tab's keyed registry, one start mapping. */
-import type { ShopInstallStatusResult, ShopUninstallResult } from '../host/index.ts';
-import { type KeyedFlow, type UseKeyedFlows } from './useFlows.ts';
-/** One entry's uninstall flow, as the tab hands it to a panel. */
-export type UninstallFlow = KeyedFlow<{
-    name: string;
-}>;
-export type UseUninstallFlows = UseKeyedFlows<{
-    name: string;
-}>;
-/**
- * Uninstall flows owned by the tab and keyed by install identity. Lifting the
- * state above individual cards is what lets a completed uninstall's outcome
- * survive the installed-projection refresh that follows it — the row backing
- * the card disappears, but the flow keyed by identity does not.
- *
- * The registry itself is `useKeyedFlows`; this supplies the one thing that is
- * uninstall-specific — what the starting RPC's answer means. An uninstall
- * business failure (not in the catalog / not installed) lands in the `failed`
- * view with the host's published detail, never in the install `rejected`
- * codes: those belong to the install gate, and `ShopUninstallResult`'s
- * failure variant has no `code` field to populate.
- */
-export declare function useUninstallFlows(uninstall: (args: {
-    name: string;
-}) => Promise<ShopUninstallResult>, installStatus: (args: {
-    installId: string;
-}) => Promise<ShopInstallStatusResult>, onSettled?: (key: string, outcome: 'done' | 'failed') => void): UseUninstallFlows;