@book.dev/ui 1.60.0 → 1.64.0

package/dist/lib/__tests__/useCanWrite.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/lib/hud.d.ts

@@ -9,11 +9,11 @@ export declare const SETTINGS_SECTIONS: readonly [{
     readonly tabs: readonly ["profile", "signup", "signin", "support"];
 }, {
     readonly id: "workspace";
-    readonly tabs: readonly ["connection", "integrations", "extensions", "ai", "admin"];
+    readonly tabs: readonly ["connection", "members", "integrations", "extensions", "ai", "admin"];
 }];
 export type SettingsSectionId = (typeof SETTINGS_SECTIONS)[number]['id'];
 /** Settings panels, flattened in display order (derived from the sections). */
-export declare const SETTINGS_TABS: ("appearance" | "ai" | "extensions" | "general" | "profile" | "customisation" | "connection" | "integrations" | "admin" | "signup" | "signin" | "support")[];
+export declare const SETTINGS_TABS: ("appearance" | "ai" | "extensions" | "general" | "profile" | "customisation" | "connection" | "members" | "integrations" | "admin" | "signup" | "signin" | "support")[];
 export type SettingsTab = (typeof SETTINGS_SECTIONS)[number]['tabs'][number];
 /** The first sub-screen — the default when nothing (valid) is persisted. */
 export declare const DEFAULT_SETTINGS_TAB: SettingsTab;

package/dist/lib/sidebarStyles.d.ts

@@ -8,3 +8,10 @@
 export declare const SIDEBAR_HOVER = "hover:bg-primary/10 hover:text-foreground dark:hover:bg-primary/20";
 /** The selected / active sidebar item — a stronger tint of the same colour. */
 export declare const SIDEBAR_ACTIVE = "bg-primary/15 text-foreground dark:bg-primary/25";
+/**
+ * Press feedback for sidebar control buttons (settings, menu toggle). Cancels
+ * the shared Button's shrink-on-press (`active:scale-[0.97]`) and deepens the
+ * highlight instead — a darker tint in light mode, a lighter one in dark mode.
+ * Applied via `cn` so it overrides the Button base through tailwind-merge.
+ */
+export declare const SIDEBAR_PRESS = "active:scale-100 active:bg-primary/20 dark:active:bg-primary/30";

package/dist/lib/useCanWrite.d.ts

@@ -0,0 +1,45 @@
+import type { InstanceInfo } from '@book.dev/sdk';
+/**
+ * Whether the current caller may WRITE this instance — the signal that decides
+ * if a page renders editable or whole-document read-only (OB-205; contract roles
+ * admin=full, viewer=locked).
+ *
+ * ## Sourcing (coarse, UI-only, documented)
+ * The brief's preferred shape is a per-page `authorize()` over the page's
+ * visibility + `listPageAcl` + `getInstanceInfo().youRole` + the principal. On
+ * this branch that can't be assembled UI-side and stay isolated from the server:
+ *
+ *  - `getInstanceInfo().youRole` does **not exist** yet (the brief assumed it);
+ *    adding it is a server change, out of scope for this UI-isolated slice.
+ *  - the roster role (`listMembers`) and per-page ACL (`listPageAcl`) are **not on
+ *    the `DataClient` interface** `useData()` returns (only `getInstanceInfo` is),
+ *    and `GET /api/members` is admin-gated anyway (a viewer 403s).
+ *  - `StoredPage` carries no `visibility`, and the post-`inherit` effective
+ *    visibility isn't resolvable client-side.
+ *
+ * So this falls back to the coarse signal the brief sanctions ("v1 hide-not-break,
+ * the server is the real enforcement — writes 403 regardless"), read from the one
+ * sharing method on the interface, {@link DataClient.getInstanceInfo}:
+ *
+ *  - the loopback owner (`verifiedVia==='local'`) and any signed-in (`jws`) user
+ *    are treated as writers — keeping owner / admin / writer editing unchanged;
+ *  - a guest (or other non-`jws`) is a writer only when the guest gate is open
+ *    (`guestAccess==='write'`) — so an anonymous reader on a `read`/`off` instance
+ *    renders read-only;
+ *  - everything else renders read-only.
+ *
+ * ### Known v1 gap (errs toward writable = hide-not-break)
+ * A signed-in **roster viewer** (a `jws` user with role `viewer`) is rendered
+ * editable here, not locked — we can't tell them from an admin without the role.
+ * Their writes are still rejected by the server (403), so it's "show chrome that
+ * no-ops", never data corruption. The seam below already reads `youRole` if a
+ * future server build adds it to `InstanceInfo` — at which point jws viewers lock
+ * correctly with **no UI change**. ACL-write grantees and per-page visibility are
+ * likewise out of this coarse v1 (they'd need the per-page `authorize()` inputs).
+ *
+ * Defaults to writable while loading / on error, so the common owner case never
+ * flashes locked and a transient failure never strands a writer.
+ */
+export declare function useCanWrite(): boolean;
+/** The coarse decision (see {@link useCanWrite}). Pure, so it's unit-testable. */
+export declare function canWriteFromInstance(info: InstanceInfo): boolean;