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

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

@@ -233,8 +233,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 +329,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 +468,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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-plugin-shop",
-  "version": "0.8.7",
+  "version": "0.9.0-beta.1",
   "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;