@poodle64/ui 2026.8.9 → 2026.8.11

package/README.md

@@ -147,7 +147,6 @@ That is the whole minimum. Everything below is optional.
 | `identity`                                        | The signed-in surface. Rendered once, at the end of the top bar.                                                        |
 | `context`, `actions`                              | Leading and trailing top-bar slots: a store/tenant switcher, app-level action buttons.                                  |
 | `banner`                                          | Full-width region under the bar: reconnect notices, trial warnings.                                                     |
-| `sidebar`                                         | A secondary, route-scoped column between the nav and the page body.                                                     |
 | `onSearch`, `searchLabel`, `searchShortcut`       | Provide `onSearch` to render the search affordance at all.                                                              |
 | `themeToggle`, `onToggleTheme`                    | Defaults to `mode-watcher`. Set `themeToggle={false}` when the app puts theming inside its own user menu.               |
 | `measure`                                         | How wide the page body may get, from a named scale. Defaults to `full` (no cap).                                        |
@@ -176,10 +175,15 @@ it did before the field existed.
 
 It exists because the alternative was two left-hand columns: an app whose
 sections have inner navigation had nowhere to put it in the rail, so it put
-modules in `nav` and the current section's pages in `sidebar`. The other way out
-(modules along the top bar, rail for the current module) was rejected on mobile:
-it leaves two navigation surfaces that both need collapsing and both want the
-same hamburger. One nested tree collapses to one drawer.
+modules in `nav` and the current section's pages in a `sidebar` slot. The other
+way out (modules along the top bar, rail for the current module) was rejected on
+mobile: it leaves two navigation surfaces that both need collapsing and both want
+the same hamburger. One nested tree collapses to one drawer.
+
+Since **2026.8.11 it is the only way in**: the `sidebar` slot is gone. What it
+produced was the shell shape differing per app, and in one app per MODULE — two
+of its sections rendered their pages beside the rail and the rest rendered them
+inside it. Operator ruling, 21/08/2026: no app supports an additional sidebar.
 
 The behaviour, and why:
 
@@ -213,9 +217,11 @@ deep, so a section whose own navigation is itself grouped under sub-headings, or
 whose rows disclose a third level, does not lift into the rail whole. The rail is
 not the place to fix that. At 15.5rem a third level leaves roughly 128px for the
 label, which is about fifteen characters. A section that deep keeps its deepest
-level on its own page, where there is width for it, and the `sidebar` snippet
-stays the right home for a column that is not `NavItem`-shaped at all: a document
-tree, a table of contents, a filter panel.
+level on its own page, where there is width for it. A column that is not
+`NavItem`-shaped at all — a document tree, a table of contents, a filter panel —
+belongs in the page too, as a sibling of the article it serves, and not in the
+shell: it is part of that page's own reading surface, it wants that page's
+breakpoints, and no other route should be paying rail width for it.
 
 `NavItem` / `NavGroup` are exported so an app types its own config against them.
 They carry **no notion of who may see an item**: two surveyed apps gate
@@ -260,8 +266,8 @@ palette:
 }
 ```
 
-`AppNav` used outside the chrome (the `sidebar` slot's own column) keeps the
-page's ink, so inverting the rail does not drag a secondary nav with it.
+`AppNav` used outside the chrome (a navigation list inside a page) keeps the
+page's ink, so inverting the rail does not drag it along.
 
 ### The content measure
 

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

@@ -3,19 +3,19 @@
 	 * The vertical navigation list.
 	 *
 	 * Rendered by AppShell in the rail/drawer (one element, two states — see
-	 * app-shell.svelte) and exported in its own right so an app with a SECOND,
-	 * route-scoped navigation column (a per-module sidebar) uses the same
-	 * affordance rather than hand-building a near-copy.
-	 * That was the concrete shape of the drift in the estate: one app's inner
-	 * sidebar had reimplemented the active indicator, the group separators and
-	 * the collapse behaviour independently of its own top bar.
+	 * app-shell.svelte), and exported in its own right for a navigation list that
+	 * belongs in a PAGE — so it is built from the same affordance rather than
+	 * hand-copied. That was the concrete shape of the drift in the estate: one
+	 * app's inner nav had reimplemented the active indicator, the group
+	 * separators and the collapse behaviour independently of its own top bar.
 	 *
-	 * An item carrying `children` discloses them in place, beneath itself. That
-	 * is the same drift arriving from the other direction: an app whose sections
-	 * have their own navigation had nowhere to put it inside the rail, so it put
-	 * its modules here and its per-section pages in AppShell's `sidebar` snippet,
-	 * and shipped two left-hand columns. See `types.ts` on `children` for why the
-	 * nested rail won over modules-on-the-top-bar, and why the depth cap is one.
+	 * It is no longer how an app gets a second navigation COLUMN, because there
+	 * is no longer such a thing: AppShell's `sidebar` slot was removed in
+	 * 2026.8.11 (operator ruling, 21/08/2026 — no app supports an additional
+	 * sidebar). An item carrying `children` discloses them in place, beneath
+	 * itself, and that is where a section's own pages go at every width. See
+	 * `types.ts` on `children` for why the nested rail won over
+	 * modules-on-the-top-bar, and why the depth cap is one.
 	 */
 	import ChevronRight from '@lucide/svelte/icons/chevron-right';
 	import {

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

@@ -56,10 +56,20 @@
 	 * remembered. `collapsible` is on for the same reason.
 	 *
 	 * Everything else the surveyed apps differed on turned out to be a slot, not
-	 * a variant: the brand, the identity surface, a context switcher, a banner, a
-	 * secondary column. Those are snippets, so this package imports no app store,
-	 * no app route and no app brand — the coupling that made the best shell in
-	 * the estate unliftable in the first place.
+	 * a variant: the brand, the identity surface, a context switcher, a banner.
+	 * Those are snippets, so this package imports no app store, no app route and
+	 * no app brand — the coupling that made the best shell in the estate
+	 * unliftable in the first place.
+	 *
+	 * There is NO second navigation column, and there is no slot to make one.
+	 * `sidebar` was such a slot until 2026.8.11, and what it produced was two
+	 * apps rendering a module's own pages beside the rail while the other seven
+	 * rendered them inside it — the shell shape differing per app, and in one app
+	 * per MODULE, which is the thing this component exists to stop. Operator
+	 * ruling, 21/08/2026, on seeing one app's two modules disagree: no app
+	 * supports an additional sidebar; a section's own pages roll out beneath it
+	 * in the rail. That is `NavItem.children` (see types.ts), which the rail
+	 * already discloses at every width and folds into the one drawer on a phone.
 	 *
 	 * The minimum useful call is two props:
 	 *
@@ -96,7 +106,6 @@
 		context,
 		actions,
 		identity,
-		sidebar,
 		onSearch,
 		searchLabel = 'Search…',
 		searchShortcut = '⌘K',
@@ -154,8 +163,6 @@
 		actions?: Snippet;
 		/** The signed-in user surface. Rendered once, at the end of the top bar. */
 		identity?: Snippet;
-		/** A secondary, route-scoped column between the nav and the page body. */
-		sidebar?: Snippet;
 		/** Provide to render the search affordance. Usually opens a CommandPalette. */
 		onSearch?: () => void;
 		searchLabel?: string;
@@ -590,11 +597,6 @@
 		{#if banner}{@render banner()}{/if}
 
 		<div class="flex min-h-0 min-w-0 flex-1">
-			{#if sidebar}
-				<div class="border-border hidden min-h-0 flex-none border-r md:flex">
-					{@render sidebar()}
-				</div>
-			{/if}
 			<!--
 				The scrolling content region, and the element a consumer's
 				"no horizontal overflow" test must measure.

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

@@ -55,10 +55,20 @@
      * remembered. `collapsible` is on for the same reason.
      *
      * Everything else the surveyed apps differed on turned out to be a slot, not
-     * a variant: the brand, the identity surface, a context switcher, a banner, a
-     * secondary column. Those are snippets, so this package imports no app store,
-     * no app route and no app brand — the coupling that made the best shell in
-     * the estate unliftable in the first place.
+     * a variant: the brand, the identity surface, a context switcher, a banner.
+     * Those are snippets, so this package imports no app store, no app route and
+     * no app brand — the coupling that made the best shell in the estate
+     * unliftable in the first place.
+     *
+     * There is NO second navigation column, and there is no slot to make one.
+     * `sidebar` was such a slot until 2026.8.11, and what it produced was two
+     * apps rendering a module's own pages beside the rail while the other seven
+     * rendered them inside it — the shell shape differing per app, and in one app
+     * per MODULE, which is the thing this component exists to stop. Operator
+     * ruling, 21/08/2026, on seeing one app's two modules disagree: no app
+     * supports an additional sidebar; a section's own pages roll out beneath it
+     * in the rail. That is `NavItem.children` (see types.ts), which the rail
+     * already discloses at every width and folds into the one drawer on a phone.
      *
      * The minimum useful call is two props:
      *
@@ -116,8 +126,6 @@ type $$ComponentProps = {
     actions?: Snippet;
     /** The signed-in user surface. Rendered once, at the end of the top bar. */
     identity?: Snippet;
-    /** A secondary, route-scoped column between the nav and the page body. */
-    sidebar?: Snippet;
     /** Provide to render the search affordance. Usually opens a CommandPalette. */
     onSearch?: () => void;
     searchLabel?: string;

package/dist/components/ui/app-shell/types.d.ts

@@ -57,10 +57,12 @@ export interface NavItem {
      *
      * Without this, an app whose sections have their own inner navigation has
      * nowhere to put it inside the rail. The observed workaround was modules in
-     * `nav` and the current module's pages in the `sidebar` snippet — two
+     * `nav` and the current module's pages in AppShell's `sidebar` snippet — two
      * left-hand columns on a desktop, and, the reason this shape won over moving
      * modules to a top bar, two surfaces on a phone that both want the same
-     * hamburger. One nested tree collapses to one drawer.
+     * hamburger. One nested tree collapses to one drawer. That slot is gone as
+     * of 2026.8.11 and this is the only way in, so a section's navigation is in
+     * the same place in every app and on every route.
      *
      * Named `children`, not `items`, for a mechanical reason as well as a
      * readable one: `isNavGroup` narrows on `'items' in entry`, so an item
@@ -105,11 +107,26 @@ export declare function toGroups(nav: NavSource | undefined): NavGroup[];
 export declare function navChildren(item: NavItem): readonly NavChildItem[];
 /**
  * Every item in source order, ignoring grouping — a parent immediately followed
- * by its own children. Used by the command palette.
+ * by its own children, each destination appearing ONCE. Used by the command
+ * palette.
  *
  * Children are included because they are destinations like any other, and the
  * palette is the fastest route to a page three levels into a section. An item
  * with no children flattens exactly as it always did.
+ *
+ * The de-duplication is not tidiness. A section that discloses its own pages
+ * names its landing page twice by nature — the parent row goes there, and the
+ * section's first child row is that same page under its own name ("Property",
+ * then "Dashboard"). Both rows are wanted in the rail, where they render in
+ * different `{#each}` blocks; flattened they collide, and every consumer keys
+ * this list by `href`, so Svelte throws `each_key_duplicate` and the throw
+ * takes the palette's whole content with it. Measured in a consumer: ⌘K opened
+ * an empty sheet on every module route until the app hand-filtered its own nav
+ * before passing it. An app should not have to know that.
+ *
+ * First occurrence wins, so the surviving entry is the parent's — the row
+ * carrying the section's own name, which is what someone typing into a palette
+ * is looking for.
  */
 export declare function toItems(nav: NavSource | undefined): NavItem[];
 /**

package/dist/components/ui/app-shell/types.js

@@ -35,19 +35,43 @@ export function navChildren(item) {
 }
 /**
  * Every item in source order, ignoring grouping — a parent immediately followed
- * by its own children. Used by the command palette.
+ * by its own children, each destination appearing ONCE. Used by the command
+ * palette.
  *
  * Children are included because they are destinations like any other, and the
  * palette is the fastest route to a page three levels into a section. An item
  * with no children flattens exactly as it always did.
+ *
+ * The de-duplication is not tidiness. A section that discloses its own pages
+ * names its landing page twice by nature — the parent row goes there, and the
+ * section's first child row is that same page under its own name ("Property",
+ * then "Dashboard"). Both rows are wanted in the rail, where they render in
+ * different `{#each}` blocks; flattened they collide, and every consumer keys
+ * this list by `href`, so Svelte throws `each_key_duplicate` and the throw
+ * takes the palette's whole content with it. Measured in a consumer: ⌘K opened
+ * an empty sheet on every module route until the app hand-filtered its own nav
+ * before passing it. An app should not have to know that.
+ *
+ * First occurrence wins, so the surviving entry is the parent's — the row
+ * carrying the section's own name, which is what someone typing into a palette
+ * is looking for.
  */
 export function toItems(nav) {
     if (!nav)
         return [];
-    return nav.flatMap((entry) => {
-        const items = isNavGroup(entry) ? entry.items : [entry];
-        return items.flatMap((item) => [item, ...navChildren(item)]);
-    });
+    const seen = new Set();
+    const items = [];
+    for (const entry of nav) {
+        for (const item of isNavGroup(entry) ? entry.items : [entry]) {
+            for (const candidate of [item, ...navChildren(item)]) {
+                if (seen.has(candidate.href))
+                    continue;
+                seen.add(candidate.href);
+                items.push(candidate);
+            }
+        }
+    }
+    return items;
 }
 /** Prefix-match `path` against `prefix`, without running past a path segment. */
 function matchesPrefix(path, prefix) {

package/dist/components/ui/page-header/page-header.svelte

@@ -95,6 +95,15 @@
 		{/if}
 	</div>
 	{#if actions}
-		<div class="flex flex-wrap items-center justify-end gap-2">{@render actions()}</div>
+		<!--
+			`min-w-0` is load-bearing, not tidying. This row is a flex ITEM of the
+			header, so it inherits `min-width: auto` — a floor at its own min-content
+			width, which its `flex-wrap` cannot get below because wrapping shrinks a
+			flex CONTAINER, never its item floor. Measured 2026-08-20 at 360px: an
+			actions row rendered 408px inside a 328px parent and pushed 64px of
+			sideways scroll into the shell content region, on every consumer using
+			PageHeader with actions.
+		-->
+		<div class="flex min-w-0 flex-wrap items-center justify-end gap-2">{@render actions()}</div>
 	{/if}
 </div>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@poodle64/ui",
-  "version": "2026.8.9",
+  "version": "2026.8.11",
   "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.8.9",
+		"version": "2026.8.11",
 		"generatedBy": "scripts/generate-registry.mjs",
 		"source": "scripts/situations.json + package source (DO NOT EDIT the outputs by hand)",
 		"componentCount": 49,

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.8.9`. 49 components, 12 situations.
+Generated from `@poodle64/ui@2026.8.11`. 49 components, 12 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.