@3sln/trove 0.0.8 → 0.0.9

package/packages/web/src/bl/services.js

@@ -1,154 +1,42 @@
-// Reactive data services the workbench renders from. These hold *data* state
-// (the current collection's items, search results, in-flight transfers) as
-// opposed to the shell's UI state (WorkbenchService). ngin Actions mutate them;
-// the UI `watch`es them. Each is a plain cell wrapper so the render layer stays
-// declarative.
+// What is left of the data services, plus the derivations that were methods on them.
+//
+// The explorer, search and API-key services were state bags — a `state`, a `cell`, and a
+// `set` that wrote both — and are slices now (bl/state.js). TransfersService stays,
+// because it holds things a state snapshot cannot: AbortControllers, per-file retry
+// thunks closing over the File itself, and a projection into the activity list.
+//
+// The functions below were METHODS on those bags. They are derivations, so they belong to
+// whoever is asking rather than to whatever happens to hold the data.
 
 import { cell } from '../runtime.js';
 
-export class ExplorerService {
-  constructor(settings) {
-    this.settings = settings;
-    this.state = {
-      items: [], loading: false, error: null,
-      selection: [], sort: settings.get('explorer.sort'), order: settings.get('explorer.sortOrder'),
-      // No collection until one is chosen or created. `gate` is 'create' | 'choose' | null
-      // — when set, it is the ONLY thing the workbench shows, because every request needs
-      // a collection and there is nothing sensible to render without one.
-      collectionId: null, collections: [], canCreateCollection: false, gate: null,
-      // `stats` is the whole collection; `items` is the page on screen. Keeping both
-      // is what lets the UI say "500 of 3,006" instead of quietly claiming 500.
-      stats: null, usage: null, nextCursor: null, loadingMore: false, trash: null,
-    };
-    this.cell = cell(this.state);
-  }
-  observe() {
-    return this.cell;
-  }
-  set(patch) {
-    this.state = { ...this.state, ...patch };
-    this.cell.setValue(this.state);
-  }
-  /**
-   * @param {string[]} ids
-   * @param {{additive?: boolean, nodes?: object[]}} [opts] `nodes` is the caller's own
-   *   copy of what it selected — pass it whenever you have it (see selectedNodes).
-   */
-  select(ids, { additive = false, nodes = null } = {}) {
-    const next = additive ? Array.from(new Set([...this.state.selection, ...ids])) : ids;
-    // Selecting what is already selected must not emit. The launcher syncs the
-    // highlighted row into here on every mouseenter, and a state push per mouse move
-    // would re-render the list under the pointer.
-    const same = next.length === this.state.selection.length
-      && next.every((id, i) => id === this.state.selection[i]);
-    if (same) return;
-    this.set({ selection: next, selectionNodes: nodes && !additive ? nodes : null });
-  }
-  /**
-   * The nodes the selection refers to.
-   *
-   * Resolving ids against `items` only finds rows on the LOADED PAGE of the CURRENT
-   * collection — and the launcher's rows come from search (which the server scopes to
-   * every readable collection) and from recents (which survive a collection switch).
-   * So every row reached by searching resolved to nothing, and rename / move-to-trash /
-   * copy-link returned silently while `explorer.hasSelection` said there was a
-   * selection. Preferring the nodes the selecting caller already held fixes the whole
-   * class; the `items` lookup stays for callers that only have ids.
-   */
-  selectedNodes() {
-    const held = this.state.selectionNodes;
-    if (held?.length) return held.filter((n) => this.state.selection.includes(n.id));
-    return this.state.items.filter((i) => this.state.selection.includes(i.id));
-  }
-}
 
 /**
- * API keys, for the admin screen that manages them.
+ * The nodes the selection refers to — a pure function of explorer state.
  *
- * Its own service rather than a corner of ExplorerService because it is a different
- * lifetime: keys are read when someone opens Settings and never again, so they should not
- * be part of the state every render of the file list walks over.
+ * It was a method, which meant every caller reached for the service to ask a question about
+ * data it could already see. As a function it can be used two ways without either being a
+ * back door: the explorer QUERY folds it into the view, so the UI is handed the answer; and
+ * an effect that needs it right now computes it from the state it already holds.
  *
- * `minted` holds the one secret a mint returns. It lives here, in memory, and is dropped
- * the moment the admin dismisses it — the server cannot show it again, so the UI is the
- * only place it ever exists, and it should not persist anywhere that outlives the tab.
+ * Resolving ids against `items` only finds rows on the LOADED PAGE of the CURRENT
+ * collection — and the launcher's rows come from search (which the server scopes to every
+ * readable collection) and from recents (which survive a collection switch). So every row
+ * reached by searching resolved to nothing, and rename / move-to-trash / copy-link returned
+ * silently while `explorer.hasSelection` said there was a selection. Preferring the nodes
+ * the selecting caller already held fixes the whole class; the `items` lookup stays for
+ * callers that only have ids.
  */
-export class ApiKeysService {
-  constructor() {
-    this.state = {
-      keys: [], loading: false, loaded: false, error: null, minted: null, busy: null,
-      // The mint form. Held here rather than in the DOM so the section stays a pure
-      // function of state — and so a half-filled form survives a re-render caused by
-      // something else on the settings screen.
-      draft: null,
-    };
-    this.cell = cell(this.state);
-  }
-
-  /** Open the mint form, empty. */
-  startDraft() {
-    this.set({ draft: { name: '', expiresInDays: '', caps: {} }, error: null });
-  }
-  cancelDraft() {
-    this.set({ draft: null });
-  }
-  patchDraft(patch) {
-    if (!this.state.draft) return;
-    this.set({ draft: { ...this.state.draft, ...patch } });
-  }
-
-  /**
-   * Toggle one capability on one collection in the draft.
-   *
-   * `admin` is not treated specially here — it is offered as itself and the server
-   * expands it. Pre-ticking read/write/delete when admin is chosen would suggest they
-   * are separable afterwards, and they are not.
-   */
-  toggleCap(collectionId, capability) {
-    if (!this.state.draft) return;
-    const caps = { ...this.state.draft.caps };
-    const held = new Set(caps[collectionId] || []);
-    if (held.has(capability)) held.delete(capability);
-    else held.add(capability);
-    if (held.size) caps[collectionId] = [...held];
-    else delete caps[collectionId];
-    this.patchDraft({ caps });
-  }
-
-  /** The draft as the API wants it, or null when it would grant nothing. */
-  draftScopes() {
-    const caps = this.state.draft?.caps || {};
-    const scopes = Object.entries(caps)
-      .filter(([, list]) => list.length)
-      .map(([collectionId, capabilities]) => ({ collectionId, capabilities }));
-    return scopes.length ? scopes : null;
-  }
-  observe() {
-    return this.cell;
-  }
-  set(patch) {
-    this.state = { ...this.state, ...patch };
-    this.cell.setValue(this.state);
-  }
-  /** Forget the freshly minted secret. Called on dismiss, and after a copy. */
-  clearMinted() {
-    if (this.state.minted) this.set({ minted: null });
-  }
+export function selectedNodesOf(state) {
+  // Tolerant of a partial state: a view is computed on every emission, including the first
+  // one, and a projection that throws takes the whole query down rather than the field.
+  const selection = state?.selection || [];
+  const held = state?.selectionNodes;
+  if (held?.length) return held.filter((n) => selection.includes(n.id));
+  return (state?.items || []).filter((i) => selection.includes(i.id));
 }
 
-export class SearchClientService {
-  constructor() {
-    this.state = { query: '', mode: 'hybrid', results: [], loading: false, error: null, ran: false, paletteFiles: [], paletteQuery: '', paletteLoading: false, paletteError: null };
-    this.cell = cell(this.state);
-  }
-  observe() {
-    return this.cell;
-  }
-  set(patch) {
-    this.state = { ...this.state, ...patch };
-    this.cell.setValue(this.state);
-  }
-}
+
 
 /**
  * Uploads in flight.
@@ -278,3 +166,51 @@ export class TransfersService {
     this.#emit();
   }
 }
+
+
+/**
+ * The API-key draft as the API wants it, or null when it would grant nothing.
+ *
+ * A pure function rather than a method, for the same reason as `selectedNodesOf`: it is a
+ * derivation, so it belongs to the view that shows it and to the action that submits it,
+ * not to the resource that happens to hold the draft.
+ */
+export function draftScopesOf(state) {
+  const caps = state?.draft?.caps || {};
+  const scopes = Object.entries(caps)
+    .filter(([, list]) => list.length)
+    .map(([collectionId, capabilities]) => ({ collectionId, capabilities }));
+  return scopes.length ? scopes : null;
+}
+
+
+/**
+ * The collection switcher's menu, derived from what the explorer knows.
+ *
+ * A pure function for the same reason as `selectedNodesOf`: it answers a question about
+ * state, so it belongs to the view that shows it. It used to be a closure hung on `app` by
+ * `registerCommands` — reachable only through that one field, and impossible to see from
+ * the component that rendered it.
+ *
+ * Items carry `actions`, like every other menu item; see ui/activate.js.
+ *
+ * @param {object} state explorer state
+ * @param {(id?: string) => object} switchTo builds the action for picking a collection
+ * @param {() => object} create builds the action for making a new one
+ */
+export function collectionMenuOf(state, switchTo, create) {
+  // No fallback: this only decides which row gets a tick, and with nothing open the answer
+  // is that none of them do. `|| 'default'` ticked a collection the user had not chosen,
+  // and on a drive with one actually called "default", the wrong one.
+  const current = state?.collectionId;
+  const items = (state?.collections || []).map((c) => ({
+    label: c.name || c.id,
+    icon: c.id === current ? 'check' : 'files',
+    actions: [switchTo(c.id)],
+  }));
+  if (state?.canCreateCollection) {
+    if (items.length) items.push({ sep: true });
+    items.push({ label: 'New collection…', icon: 'plus', actions: [create()] });
+  }
+  return items;
+}

package/packages/web/src/bl/social.js

@@ -8,7 +8,9 @@
 import { cell } from '../runtime.js';
 
 export class SocialService {
-  constructor(platform) {
+  constructor(platform, offline = null) {
+    // How a comment or tag written while disconnected reaches the server later.
+    this.offline = offline;
     this.platform = platform;
     this.api = platform.api;
     this.state = {

package/packages/web/src/bl/state.js

@@ -0,0 +1,144 @@
+// The drive's own state, as named slices.
+//
+// These were classes: an `ExplorerService`, a `SearchClientService`, an `ApiKeysService`,
+// each holding a `state` field, a `cell`, and a `set` that wrote both. Nothing else. A
+// service should cover something complex and offer it through a narrow door — these
+// covered an object.
+//
+// Two things came of that shape and both are gone with it.
+//
+// TWO DOORS. Actions read `.state` and queries read `.cell`, and the two are only equal by
+// habit: most services wrote `this.state = {...}; this.cell.setValue(this.state)`, but not
+// all did, and `settings` still has a cell holding `effective()` and no `state` field at
+// all. A slice has one value and one way to read it.
+//
+// LOGIC IN THE HOLDER. `toggleCap` computed a capability set inside the service while an
+// action stood in front of it forwarding two arguments — and dropped one of them, which is
+// how a minted key came to be rejected by the server. Arithmetic over state belongs to the
+// action that decides to change it; the slice only holds.
+//
+// Each slice is still its OWN provider, so `static deps = ['explorer']` keeps meaning what
+// it says. A single `appState` covering everything would put the whole drive back behind
+// one lease, which is what naming the resources individually was for.
+
+import { cell } from '../runtime.js';
+
+/**
+ * One named piece of the drive's state.
+ *
+ * `set` merges, because every caller was already merging and doing it here removes the
+ * chance of a caller replacing a slice by forgetting to spread it. `replace` exists for
+ * the cases that genuinely mean "all of it" — a fresh panel stack, an emptied list.
+ *
+ * @param {object} initial
+ */
+export function slice(initial = {}) {
+  const held = cell(initial);
+  return {
+    /** The cell, for a query to watch. */
+    observe: () => held,
+    /** The value, for an action about to decide something from it. */
+    get: () => held.getValue(),
+    /** Merge a patch in. A new object every time — a cell compares with Object.is. */
+    set: (patch) => held.setValue({ ...held.getValue(), ...patch }),
+    /** Replace it outright, for when a patch would be a lie. */
+    replace: (next) => held.setValue(next),
+  };
+}
+
+/** Items, selection, the open collection, and the gate. */
+export const explorerState = (settings) => slice({
+  items: [], loading: false, error: null,
+  selection: [], sort: settings.get('explorer.sort'), order: settings.get('explorer.sortOrder'),
+  // No collection until one is chosen or created. `gate` is 'create' | 'choose' | null —
+  // when set, it is the ONLY thing the workbench shows, because every request needs a
+  // collection and there is nothing sensible to render without one.
+  collectionId: null, collections: [], canCreateCollection: false, gate: null,
+  // `stats` is the whole collection; `items` is the page on screen. Keeping both is what
+  // lets the UI say "500 of 3,006" instead of quietly claiming 500.
+  stats: null, usage: null, nextCursor: null, loadingMore: false, trash: null,
+});
+
+/** Query text, results, and the palette's separate file list. */
+export const searchState = () => slice({
+  query: '', mode: 'hybrid', results: [], loading: false, error: null, ran: false,
+  paletteFiles: [], paletteQuery: '', paletteLoading: false, paletteError: null,
+});
+
+/**
+ * The admin API-key list.
+ *
+ * `minted` holds the one secret a mint returns. It lives here, in memory, and is dropped
+ * the moment the admin dismisses it — the server cannot show it again, so the UI is the
+ * only place it ever exists and it must not outlive the tab.
+ *
+ * `draft` is the mint form. Held in state rather than in the DOM so the section stays a
+ * pure function of state, and so a half-filled form survives a re-render caused by
+ * something else on the settings screen.
+ */
+export const apiKeysState = () => slice({
+  keys: [], loading: false, loaded: false, error: null, minted: null, busy: null, draft: null,
+});
+
+/**
+ * What the UI is in the middle of doing — a keybinding mid-capture, text typed into a
+ * dialog that has not been submitted, the boxes ticked in a plugin review.
+ *
+ * None of it is drive state; all of it decides what is on screen, which is what makes it
+ * engine state. Keyed by component, so `set` here replaces one key rather than merging a
+ * patch — see SetViewStateAction.
+ */
+export const viewState = () => slice({});
+
+/**
+ * The shell's transient overlays: the command palette, a modal dialog, the right-click
+ * menu, and the plugin popup panel.
+ *
+ * Four things that are independent of the panel stack and of each other, which is why they
+ * were split out of the workbench in the first place. What they are NOT is complex enough
+ * to need a service — the class was four setters and a `wrapIndex`, with an action standing
+ * in front of each one. The wrapping now lives in the action that moves a cursor, which is
+ * where it was needed: MovePaletteAction lost the count argument once already, precisely
+ * because deciding and writing were on opposite sides of a forwarding layer.
+ */
+export const overlayState = () => slice({
+  palette: null, // { mode: 'commands'|'files', query, index } when open
+  dialog: null,
+  contextMenu: null,
+  pluginPanel: null,
+});
+
+/**
+ * The shell itself: which activity is showing, and the launcher's own cursor.
+ *
+ * The panel stack is NOT here — that is NavigationService, which stays a service because it
+ * mirrors the stack into browser history and persists recents, neither of which a state bag
+ * can do.
+ */
+export const workbenchState = () => slice({
+  activity: 'home', // home (stack) | plugins | settings
+  sidebarVisible: true,
+  launch: { query: '', index: 0 },
+  searchModal: false, // the double-shift modal search overlay
+  // Phone chrome: which bottom sheet is up, if any ('status' | 'more'). A phone has no room
+  // for a permanent status bar or a left rail, so both fold into a sheet pulled up on demand.
+  sheet: null,
+  infoPanel: false,
+});
+
+/** Wrap a list cursor by `delta` within `[0, count)` — the palette and the launcher share it. */
+export function wrapIndex(index, delta, count) {
+  return (index + delta + count) % count;
+}
+
+/**
+ * What the open collection's key is doing.
+ *
+ * Rotation is long-running and lives on the server, so this is a local view of it kept in
+ * step by polling while the settings screen is open — see `RotationQuery`. It is state
+ * rather than a fetch-per-render because two things read it (the progress line and whether
+ * Start is offered) and they must not disagree.
+ */
+export const rotationState = () => slice({
+  collectionId: null, rotation: null, estimate: null, loading: false, error: null, busy: false,
+});

package/packages/web/src/bl/status.js

@@ -0,0 +1,96 @@
+// What the drive is doing and how full it is — one answer, for every surface that says so.
+//
+// This lived in the status bar and was imported from there by the phone chrome, which is
+// how it was already admitting to being shared: two shells rendering the same facts in
+// different shapes. It is a derivation over four resources, so it belongs here, and it is
+// reached as the `statusFacts` query rather than recomputed per render.
+//
+// The reason it has to be derived ONCE rather than twice is on the record: the phone bar
+// rendered `collectionId` raw and showed an opaque `col_…` where the desktop bar showed the
+// collection's name — the same fact, said two ways, because each surface worked it out.
+
+/**
+ * The facts every shell reports.
+ *
+ * @param {{ex: object, tr: object, act: object, off: object}} slices
+ */
+export function statusFactsOf({ ex = {}, tr = {}, act = {}, off = {} } = {}) {
+  const items = ex.items || [];
+  const tasks = act.tasks || [];
+  return {
+    // `null` with nothing open — `collectionLabelOf` renders that as "no collection". The
+    // old fallback made the bar name a collection that may not exist, on a drive where the
+    // user had not yet chosen one.
+    collectionId: ex.collectionId ?? null,
+    // What to CALL it, so the phone shell and the desktop bar cannot end up saying
+    // different things.
+    collectionLabel: collectionLabelOf(ex),
+    // The COLLECTION's totals when the server could give them, not the page's. Summing what
+    // happens to be loaded reports a 3,000-file drive as 500 files — a wrong number, not a
+    // rounded one. Falls back to the page only when the server didn't say.
+    totalItems: ex.stats?.items ?? items.length,
+    // Whether that total is the COLLECTION's or just the page we happen to hold. With more
+    // pages waiting, the page length is a floor, not a total, and must read as one.
+    totalKnown: ex.stats?.items != null,
+    totalBytes: ex.stats?.bytes ?? items.reduce((n, i) => n + (i.size || 0), 0),
+    shown: items.length,
+    partial: !!ex.nextCursor,
+    usage: ex.usage ?? null,
+    usageLevel: usageLevelOf(ex.usage),
+    uploading: (tr.items || []).filter((t) => t.status === 'active'),
+    running: tasks.filter((t) => t.status === 'running'),
+    issues: act.issues || [],
+    off: { online: true, pins: [], queued: 0, syncing: false, ...off },
+  };
+}
+
+/** The open collection's name, or the plainest true thing when there isn't one. */
+export function collectionLabelOf(ex) {
+  if (!ex?.collectionId) return 'no collection';
+  const match = (ex.collections || []).find((c) => c.id === ex.collectionId);
+  return match?.name || ex.collectionId;
+}
+
+/**
+ * How worried to be about space, or '' when there is nothing to say.
+ *
+ * A filesystem or NAS can answer exactly, and that is where it matters: a disk fills up and
+ * every upload starts failing with no warning that anything was coming. An object store has
+ * no equivalent number, so this answers '' and the meter is not drawn at all rather than
+ * being drawn meaninglessly.
+ *
+ * The thresholds are a judgement about when someone still has time to act, which is why
+ * they are here and not in whichever bar happens to be on screen.
+ */
+export function usageLevelOf(usage) {
+  if (!usage?.total) return '';
+  const free = usage.available / usage.total;
+  return free < 0.05 ? 'critical' : free < 0.1 ? 'low' : '';
+}
+
+/**
+ * The one thing worth saying about the drive right now, most urgent first.
+ *
+ * The phone has room for a single glyph, so something has to decide what outranks what:
+ * being offline beats a standing problem, a standing problem beats work in progress, and
+ * anything beats running low on space. That ordering is a claim about which condition a
+ * person most needs to know, which makes it a decision rather than a rendering.
+ *
+ * Answers a KIND, not an icon. Which glyph draws a kind is the shell's business.
+ */
+export function driveConditionOf(facts) {
+  const f = facts || {};
+  if (!f.off?.online) return { kind: 'offline', label: 'Offline' };
+  if (f.issues?.length) {
+    return {
+      kind: 'issues',
+      label: `${f.issues.length} need${f.issues.length === 1 ? 's' : ''} attention`,
+      count: f.issues.length,
+    };
+  }
+  if (f.running?.length || f.uploading?.length || f.off?.syncing) {
+    return { kind: 'working', label: 'Working…', count: (f.running?.length || 0) + (f.uploading?.length || 0) };
+  }
+  if (f.usageLevel) return { kind: 'lowSpace', label: 'Low on space' };
+  return { kind: 'idle', label: 'Status' };
+}

package/packages/web/src/bl/trust.js

@@ -0,0 +1,109 @@
+// What a plugin package's signature actually means.
+//
+// This is a security classification, not a label. It decided the same four states in two
+// different components — the installed-plugin list and the install-review dialog — with two
+// different sets of words, and the distinction that matters most was the one that drifted:
+//
+//   `invalid` is NOT `unverified`. Unverified means nobody signed it, which is the ordinary
+//   case for a plugin you got from a friend. Invalid means it WAS signed and the signature
+//   does not verify — the bytes are not the bytes that were signed. That is the one state
+//   implying someone altered the package, and the list once rendered it in the same amber as
+//   the benign case, because the two `if` ladders were maintained separately and one of them
+//   was missing a branch.
+//
+// So the classification lives here, once, and the components choose their own wording from
+// `status`. What is a security judgement is in the business layer; how many characters fit
+// in a badge is not.
+
+/**
+ * Whether a package may be installed at all, and on what terms.
+ *
+ * Three answers, because the states differ in kind rather than in degree:
+ *
+ *   - `invalid` is REFUSED. It means the package was signed and the signature does not
+ *     verify — the bytes are not the bytes that were signed. No development workflow
+ *     produces that; it means the package was altered in transit or at rest. There is
+ *     nothing for a user to weigh, so they are not asked.
+ *
+ *   - `unverified` is installable but only DELIBERATELY. Nobody signed it, which is the
+ *     ordinary state of a plugin you are writing: you cannot sign a package you are still
+ *     changing. So it stays possible, behind an acknowledgement that says what is being
+ *     given up — no publisher, no proof the code is what its author shipped.
+ *
+ *   - `signed` carries a real signature whose domain does not vouch for the key. That is a
+ *     claim to a namespace rather than a proof of one, so it is said prominently and left
+ *     to the user; refusing it would block a valid publisher whose assetlinks are merely
+ *     misconfigured.
+ *
+ * This is also what closes namespace squatting. A package claiming another publisher's
+ * domain is unverified by construction — the real domain does not publish its key — so it
+ * cannot be installed without the user being told exactly that.
+ */
+export function installPolicyFor(trust) {
+  const t = describeTrust(trust);
+  if (t.status === 'invalid') {
+    return {
+      status: t.status,
+      allowed: false,
+      requiresAcknowledgement: false,
+      headline: 'This package has been altered',
+      detail: `${t.explanation}. It was signed, and the signature does not match its contents — so it is not what its author published. Trove will not install it.`,
+    };
+  }
+  if (t.status === 'unverified') {
+    return {
+      status: t.status,
+      allowed: true,
+      requiresAcknowledgement: true,
+      headline: 'Unsigned — for development only',
+      detail: 'Nobody has signed this package, so there is no way to tell who wrote it or whether it has been altered since. Install it only if you built it yourself or you trust wherever you got it from.',
+    };
+  }
+  if (t.status === 'signed') {
+    return {
+      status: t.status,
+      allowed: true,
+      requiresAcknowledgement: false,
+      headline: 'Signed, but the domain does not vouch for the key',
+      detail: `${t.explanation}. The signature is real; what is unproven is that ${t.domain || 'the publisher'} authorised it.`,
+    };
+  }
+  return { status: t.status, allowed: true, requiresAcknowledgement: false, headline: null, detail: null };
+}
+
+/**
+ * @param {{status?: string, domain?: string, reason?: string}|null} trust
+ * @returns {{status: string, tone: string, icon: string, domain: string|null, explanation: string, severity: number}}
+ */
+export function describeTrust(trust) {
+  const t = trust || {};
+  switch (t.status) {
+    case 'verified':
+      return {
+        status: 'verified', tone: 'verified', icon: 'check', domain: t.domain || null,
+        explanation: t.domain
+          ? `Signed by a key published at ${t.domain}`
+          : 'Signed by a key the publishing domain vouches for',
+        severity: 0,
+      };
+    case 'signed':
+      return {
+        status: 'signed', tone: 'signed', icon: 'info', domain: t.domain || null,
+        explanation: t.reason || 'Signed, but the domain does not vouch for the key',
+        severity: 1,
+      };
+    case 'invalid':
+      return {
+        status: 'invalid', tone: 'invalid', icon: 'warn', domain: t.domain || null,
+        // Said plainly. This is the only state that means tampering rather than absence.
+        explanation: t.reason || 'The signature did not verify — this package may have been altered',
+        severity: 3,
+      };
+    default:
+      return {
+        status: 'unverified', tone: 'unverified', icon: 'warn', domain: t.domain || null,
+        explanation: t.reason || 'This plugin is not signed',
+        severity: 2,
+      };
+  }
+}

package/packages/web/src/bl/viewState.js

@@ -0,0 +1,60 @@
+// View state: what the UI is in the middle of doing.
+//
+// Which keybinding is mid-capture, what has been typed into a dialog that has not been
+// submitted, which capabilities are ticked in a plugin review. None of it is drive state —
+// it is thrown away when the dialog closes — but all of it decides what is on screen, and
+// anything that decides what is on screen is engine state. A component reads it through a
+// query and writes it through an action, the same as everything else.
+//
+// The history is worth keeping because it went wrong twice in the same direction. It began
+// as module-level `let`s mutated in place, with a `rerender()` hook threaded through
+// fourteen modules so the leaf that changed one could poke the root into redrawing — data
+// down, invalidation back up out of band. Moving it into a cell fixed the invalidation and
+// left a second version of the same mistake: components still READ it by calling the module
+// during their own render, and two of them WROTE to it there as well, to lazily initialise a
+// default. A render that writes state is a render with a side effect.
+//
+// So this is a resource now, and the lazy-initialise trick is gone: where a component used
+// to write a default on first render, it now computes one and writes nothing until the user
+// does something. `ref` is what makes that possible — it records which dialog instance the
+// value belongs to, so a stale entry is simply ignored rather than needing to be cleared.
+//
+// The holder itself is a slice in bl/state.js; what stays here is how to read one.
+
+/**
+ * The slice for `key`, or `fallback` when it belongs to a different dialog instance.
+ *
+ * Two components keep a draft that must reset when the dialog is reopened. They used to do
+ * that by writing the default during the render that noticed the mismatch. Deriving it
+ * instead means the render stays a pure function of the state it was given, and the first
+ * write happens when the user actually changes something.
+ *
+ * @param {object} slice the view-state slice from the query
+ * @param {string} key
+ * @param {object} ref the dialog instance the value must belong to
+ * @param {any} fallback
+ */
+export function draftFor(slice, key, ref, fallback) {
+  const held = slice?.[key];
+  return held && held.ref === ref ? held : { ref, ...fallback };
+}
+
+/** Where a prompt dialog's typed value lives while it is being typed. */
+export const PROMPT = 'promptValue';
+
+/**
+ * What has been typed into the open prompt, or its initial value.
+ *
+ * The prompt kept this in a `let` closed over by the render and mutated by the input
+ * handler, and handed it back through an `onSubmit` callback — which meant a FUNCTION was
+ * living in the dialog spec, and the dialog spec is engine state. Keeping the value here
+ * instead lets a prompt carry actions like everything else, and each action reads what was
+ * typed rather than being handed it.
+ *
+ * `ref` ties it to the dialog instance, so reopening starts from the new initial value
+ * rather than whatever the last prompt left behind.
+ */
+export function promptValueOf(slice, dialog) {
+  const held = slice?.[PROMPT];
+  return held && held.ref === dialog ? held.value : (dialog?.value ?? '');
+}