@poodle64/ui 2026.9.4 → 2026.9.6

package/README.md

@@ -1164,4 +1164,18 @@ non-zero and naming the field on any difference.
 
 1. Change a component; bump `version` in `package.json` (CalVer).
 2. `pnpm build`, which runs `svelte-package` then `publint` (package.json/exports sanity).
-3. Commit, tag `ui-v<version>`, push the tag; CI publishes to public npm.
+3. Commit, tag `ui-v<version>`, push the tag.
+4. `.github/workflows/publish.yaml` runs on that push and should publish via
+   npm OIDC trusted publishing: check it with
+   `gh run list --workflow=publish.yaml`. As of 2026.9.4 every run since
+   `ui-v2026.9.2` fails at the `npm publish` step with
+   `E404 Not Found - PUT .../@poodle64%2fui` (an OIDC/trusted-publisher
+   binding issue, since `Build and test package` passes first). Until that
+   is diagnosed and fixed, publish manually from `packages/ui/`:
+   ```bash
+   printf '//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}\n' > .npmrc
+   signet exec --identity huginn-claude --broker https://portcullis.godswood.au \
+     --credential npm-publish-token --env-var NODE_AUTH_TOKEN -- npm publish
+   rm -f .npmrc
+   ```
+   Confirm with `npm view @poodle64/ui version`.

package/dist/components/ui/app-identity/app-identity.svelte

@@ -30,7 +30,14 @@
 	 * instead (operator ruling, 07/09/2026, master-project#291's org-of-one
 	 * case). Wire it whenever the app has a members route, whether or not it
 	 * also renders a switcher.
+	 *
+	 * `links` is the escape valve for everything the fixed entries have no room
+	 * for — an Admin route, a support link — as a LIST, so every app's extra
+	 * destinations render as the same row. Without it an app puts its own
+	 * destination in AppShell's `actions` slot as an icon button (cadmus did,
+	 * twice), and two apps do it two ways in the same bar.
 	 */
+	import type { Component } from 'svelte';
 	import { toggleMode } from 'mode-watcher';
 	import * as DropdownMenu from '../dropdown-menu/index.js';
 	import * as Avatar from '../avatar/index.js';
@@ -43,7 +50,8 @@
 		onSignOut,
 		onAccountSettings,
 		onManageMembers,
-		onSwitchTheme
+		onSwitchTheme,
+		links = []
 	}: {
 		user: { username: string; display_name: string | null; email: string | null };
 		/** The active workspace's name. Omit while none is chosen yet — the block hides rather than rendering empty. */
@@ -70,6 +78,22 @@
 		onManageMembers?: () => void;
 		/** Override the theme action. Defaults to mode-watcher's toggleMode, matching AppShell. */
 		onSwitchTheme?: () => void;
+		/**
+		 * App destinations the fixed entries have no room for, rendered in their
+		 * own group.
+		 *
+		 * A list of items, never a snippet: a snippet lets each app invent its own
+		 * row shape, and two apps inventing two shapes in the same top bar is the
+		 * drift this package exists to end. Cadmus is the measured case — its
+		 * Admin entry had nowhere to go and became an icon button in AppShell's
+		 * `actions` slot, and a second one (a quiet support link) was about to
+		 * follow it there.
+		 *
+		 * No `href`: the callback shape matches every other action on this
+		 * component, and a consumer routes with its own `goto`. The icon is
+		 * optional — a label-only row stays aligned with any iconed row beside it.
+		 */
+		links?: { label: string; icon?: Component<{ class?: string }>; onSelect: () => void }[];
 	} = $props();
 
 	const shown = $derived(user.display_name ?? user.username);
@@ -110,6 +134,11 @@
 		user.display_name ? initialsOf(user.display_name) : handleInitials(user.username)
 	);
 
+	// Spacers only where the group actually has an icon to align to: a group of
+	// label-only rows sits flush with the fixed entries below it, exactly as it
+	// would if this prop had never existed.
+	const linksHaveIcons = $derived(links.some((l) => l.icon));
+
 	function switchTheme() {
 		if (onSwitchTheme) onSwitchTheme();
 		else toggleMode();
@@ -177,6 +206,26 @@
 				<DropdownMenu.Item onSelect={onManageMembers}>Members</DropdownMenu.Item>
 			{/if}
 		{/if}
+		{#if links.length}
+			<DropdownMenu.Separator />
+			<DropdownMenu.Group>
+				<!-- Keyed by position, not by label: nothing in the type makes a label
+				     unique, and two apps' configs colliding on one would be a
+				     duplicate-key crash rather than a duplicated row. This list is
+				     app configuration, not data that reorders. -->
+				{#each links as link, i (i)}
+					{@const Icon = link.icon}
+					<DropdownMenu.Item onSelect={link.onSelect}>
+						{#if Icon}
+							<Icon class="size-4" />
+						{:else if linksHaveIcons}
+							<span class="size-4 flex-none" aria-hidden="true"></span>
+						{/if}
+						{link.label}
+					</DropdownMenu.Item>
+				{/each}
+			</DropdownMenu.Group>
+		{/if}
 		<DropdownMenu.Separator />
 		<DropdownMenu.Item onSelect={switchTheme}>Switch theme</DropdownMenu.Item>
 		<DropdownMenu.Item onSelect={onAccountSettings}>Account settings</DropdownMenu.Item>

package/dist/components/ui/app-identity/app-identity.svelte.d.ts

@@ -1,3 +1,42 @@
+/**
+     * The signed-in user surface for AppShell's `identity` slot.
+     *
+     * Graduated from the shell lab (`packages/console/src/routes/lab/+page.svelte`,
+     * the `identity === 'avatar'` shape) — operator ruling 04/09/2026: avatar
+     * only at rest, no name, no chevron, and no prop reintroduces a variant.
+     * Opening it answers who is signed in, which workspace they act in, and the
+     * ways out — identity first, because a menu that opens on a list of actions
+     * makes you infer who you are from the avatar you just clicked.
+     *
+     * Prop names match the stamped template's auth store
+     * (`frontend/src/lib/auth.svelte.ts` — `User`, `Membership`) exactly, so a
+     * consumer wires this straight from `auth.user`, `auth.entitlements`,
+     * `auth.activeWorkspace` and `auth.activeRole` with no reshaping. A guessed
+     * shape needs rewriting the day it meets the real store, which is the whole
+     * reason this one didn't. `display_name` and `email` are both nullable
+     * there, and `activeWorkspace` is genuinely null until a caller with several
+     * memberships chooses one — this component is built against that, not a
+     * happy path.
+     *
+     * Sign-out and settings are the consuming app's concerns, never behaviour
+     * baked in here: `onSignOut` and `onAccountSettings` are callbacks. Theme
+     * follows AppShell's own `onToggleTheme` pattern — override it, or accept
+     * mode-watcher's `toggleMode` by default.
+     *
+     * `onManageMembers` exists for the caller a workspace switcher has nothing
+     * to show: `WorkspaceMenu` (the factory template) renders nothing in the
+     * bar for a single-member workspace, and this is where Members lands
+     * instead (operator ruling, 07/09/2026, master-project#291's org-of-one
+     * case). Wire it whenever the app has a members route, whether or not it
+     * also renders a switcher.
+     *
+     * `links` is the escape valve for everything the fixed entries have no room
+     * for — an Admin route, a support link — as a LIST, so every app's extra
+     * destinations render as the same row. Without it an app puts its own
+     * destination in AppShell's `actions` slot as an icon button (cadmus did,
+     * twice), and two apps do it two ways in the same bar.
+     */
+import type { Component } from 'svelte';
 type $$ComponentProps = {
     user: {
         username: string;
@@ -28,7 +67,29 @@ type $$ComponentProps = {
     onManageMembers?: () => void;
     /** Override the theme action. Defaults to mode-watcher's toggleMode, matching AppShell. */
     onSwitchTheme?: () => void;
+    /**
+     * App destinations the fixed entries have no room for, rendered in their
+     * own group.
+     *
+     * A list of items, never a snippet: a snippet lets each app invent its own
+     * row shape, and two apps inventing two shapes in the same top bar is the
+     * drift this package exists to end. Cadmus is the measured case — its
+     * Admin entry had nowhere to go and became an icon button in AppShell's
+     * `actions` slot, and a second one (a quiet support link) was about to
+     * follow it there.
+     *
+     * No `href`: the callback shape matches every other action on this
+     * component, and a consumer routes with its own `goto`. The icon is
+     * optional — a label-only row stays aligned with any iconed row beside it.
+     */
+    links?: {
+        label: string;
+        icon?: Component<{
+            class?: string;
+        }>;
+        onSelect: () => void;
+    }[];
 };
-declare const AppIdentity: import("svelte").Component<$$ComponentProps, {}, "">;
+declare const AppIdentity: Component<$$ComponentProps, {}, "">;
 type AppIdentity = ReturnType<typeof AppIdentity>;
 export default AppIdentity;

package/dist/components/ui/app-shell/app-shell.svelte

@@ -575,7 +575,19 @@
 				{@render brandLockup(true)}
 			</span>
 
-			{#if context}{@render context()}{/if}
+			<!-- `min-w-0` is what lets a leading `context` snippet (a workspace
+			     switcher, a breadcrumb) actually shrink under crowding — a flex
+			     item's automatic `min-width: auto` otherwise floors it at its own
+			     min-content size, so with search, actions and identity all also
+			     competing for the bar the FIRST thing to run out of room was
+			     whichever trailing control happened to sit last in source order
+			     (theme, identity) — pushed edge-to-edge past the header's own
+			     right edge and, with no horizontal scroll on the bar, permanently
+			     unreachable rather than merely cramped (design-system#111). The
+			     wordmark and the search button already carry their own shrink
+			     behaviour (hiding text, going icon-only); `context` is the one
+			     leading slot that never had to. -->
+			{#if context}<div class="min-w-0">{@render context()}</div>{/if}
 
 			{#if onSearch && searchPlacement === 'leading'}
 				{@render searchButton(

package/dist/styles.css

@@ -624,6 +624,15 @@
 	.ds-nav {
 		--ds-nav-ink: var(--ds-nav-chrome-ink, var(--foreground));
 		--ds-nav-ink-muted: var(--ds-nav-chrome-ink-muted, var(--muted-foreground));
+		/* Specified rather than left `visible` (the default): `overflow-y: auto`
+		   otherwise forces the computed value of an unspecified overflow-x to
+		   `auto` too (CSSOM's "if one axis is visible and the other is not, the
+		   visible one becomes auto" rule), so a row wider than the nav — a long
+		   label, a wide badge — got its own sideways scrollbar inside the drawer.
+		   The drawer scrolls vertically only; a row that doesn't fit truncates
+		   (`.ds-nav-item`'s label already carries `.truncate`) rather than
+		   growing a second scroll axis on top of the menu's own (design-system#111). */
+		overflow-x: hidden;
 	}
 
 	.ds-shell-rail,
@@ -847,6 +856,21 @@
 		padding-inline: 0;
 	}
 
+	/* A hard ceiling on the whole shell, in the one unit that names the actual
+	   drawn surface rather than a percentage of an ancestor. `.ds-shell` is
+	   already `flex` with `overflow-hidden` in the component markup, which
+	   clips an ordinary descendant that outgrows it — but a `position: fixed`
+	   descendant (the open drawer, below) is excused from an ancestor's
+	   `overflow: hidden` by definition, fixed positioning escapes every
+	   clipping ancestor that is not itself a containing block for fixed
+	   elements, and `.ds-shell` is not one. This is the backstop for that
+	   whole class of leak: whatever grows past the shell's own box, on
+	   whichever descendant, the SHELL still cannot be asked to draw wider than
+	   the viewport it is actually in (design-system#111). */
+	.ds-shell {
+		max-width: 100dvw;
+	}
+
 	/* The rail is ONE element in two states, not two elements (see the comment in
 	   app-shell.svelte): below md it is hidden until `data-drawer` turns it into
 	   an overlay; at md and up it is the permanent column and `data-drawer` means
@@ -871,16 +895,35 @@
 	   the last nav row at its bottom sit exactly where a notch or a home
 	   indicator gesture bar would cover them. The rail's own sticky state
 	   never needs this — it starts below the page's own top edge in normal
-	   flow, not against the physical screen edge. */
+	   flow, not against the physical screen edge.
+
+	   The width is a `min()` against the true viewport (`100dvw`, less the
+	   left inset a landscape notch carves out of it) rather than the old
+	   `max-width: 82vw` — `vw` is the LAYOUT viewport, which on a phone stays
+	   the largest size the page could ever occupy whether or not the browser
+	   chrome is actually showing, while `dvw` is the viewport the page is
+	   ACTUALLY drawn into right now. The two rarely disagree on width the way
+	   `vh`/`dvh` disagree on height, but disagreeing on principle was already
+	   enough to make this the one place on the drawer that named the wrong
+	   viewport (design-system#111): every other rule the drawer carries reads
+	   `dvh`/`env(safe-area-inset-*)`, so `82vw` was the one dimension still
+	   trusting a unit this component elsewhere treats as untrustworthy on a
+	   phone. `min()` over `--ds-shell-rail-width` keeps the drawer at its
+	   ordinary width on anything bigger than a narrow phone, and only the
+	   viewport term binds below that — so the drawer can never be asked to be
+	   wider than the screen it is drawn on, at any width, by construction
+	   rather than by testing every content shape that could have pushed it
+	   there. */
 	.ds-shell-rail[data-drawer='true'] {
 		display: flex;
 		position: fixed;
 		inset-block: 0;
 		left: 0;
 		z-index: 50;
-		max-width: 82vw;
+		width: min(var(--ds-shell-rail-width), 82dvw, 100dvw - env(safe-area-inset-left, 0px));
 		padding-top: env(safe-area-inset-top);
 		padding-bottom: env(safe-area-inset-bottom);
+		padding-left: env(safe-area-inset-left);
 		box-shadow:
 			0 10px 15px -3px oklch(0 0 0 / 0.1),
 			0 4px 6px -4px oklch(0 0 0 / 0.1);
@@ -896,9 +939,10 @@
 		.ds-shell-rail[data-drawer='true'] {
 			position: sticky;
 			z-index: auto;
-			max-width: none;
+			width: var(--ds-shell-rail-width);
 			padding-top: 0;
 			padding-bottom: 0;
+			padding-left: 0;
 			box-shadow: none;
 			animation: none;
 		}

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@poodle64/ui",
-	"version": "2026.9.4",
+	"version": "2026.9.6",
 	"description": "Household shared component layer: shadcn-svelte primitives (bits-ui) plus the composed page chrome every app builds its routes from, restyled by each app's @poodle64/design-tokens alias layer. One fix reaches every app.",
 	"type": "module",
 	"license": "MIT",

package/registry/component-map.json

@@ -1,7 +1,7 @@
 {
 	"meta": {
 		"package": "@poodle64/ui",
-		"version": "2026.9.4",
+		"version": "2026.9.6",
 		"generatedBy": "scripts/generate-registry.mjs",
 		"source": "scripts/situations.json + package source (DO NOT EDIT the outputs by hand)",
 		"componentCount": 56,

package/registry/component-map.md

@@ -1,7 +1,7 @@
 # @poodle64/ui — situation → component map
 
 <!-- GENERATED by scripts/generate-registry.mjs from scripts/situations.json + package source. DO NOT EDIT. -->
-Generated from `@poodle64/ui@2026.9.4`. 56 components, 15 situations.
+Generated from `@poodle64/ui@2026.9.6`. 56 components, 15 situations.
 
 **Read this before writing a `<div>`.** Find the SITUATION you are in below, then compose the component named for it — do not hand-build it from raw `Card` or utility classes. Import is `import { Name } from '<import path>'`. Props marked `?` are optional. This map is the retrieval step the [`frontend-design` skill] makes mandatory; the [CHI 2026 study] measured composing-from-a-registry at 95% design-system compliance against 71% for writing the CSS from a prose style guide.