dogsbay 0.2.0-beta.11 → 0.2.0-beta.13

package/dist/commands/site-dev.js

@@ -3,13 +3,18 @@
  * run `dogsbay site build`, watch content for changes, and hand
  * control over to the Astro CLI inside the site directory.
  *
- *   dev      → astro dev      (live HMR for already-built pages)
- *   preview  → astro build && astro preview
+ *   dev      → astro dev               (live HMR for already-built pages)
+ *   preview  → <pm> run build → astro preview
  *
  * The site dir is found by locating `dogsbay.config.{yml,yaml,json}`
- * at or above cwd (or via --config). `npm run build` (the user's
- * existing script) is *not* what runs here — we shell out to `astro`
- * directly so this works whether the user uses pnpm / npm / yarn.
+ * at or above cwd (or via --config).
+ *
+ * site dev shells `npx astro dev` directly — fast, no script
+ * indirection. site preview needs the production build to match
+ * what's actually deployed, which means running the scaffolded
+ * package.json `build` script (chains `astro build && pagefind
+ * --site dist` so Cmd+K search works in the previewed dist/). The
+ * package manager is auto-detected (pnpm if on PATH, otherwise npm).
  *
  * `site dev` also installs a content watcher that re-runs
  * `dogsbay site build` whenever a markdown / yaml / json file under
@@ -37,6 +42,18 @@ const defaultRunner = (siteRoot, args) => new Promise((resolve) => {
         resolve(1);
     });
 });
+const defaultBuildRunner = (siteRoot) => new Promise((resolve) => {
+    const pm = pickPackageManager();
+    const child = spawn(pm, ["run", "build"], {
+        cwd: siteRoot,
+        stdio: "inherit",
+    });
+    child.on("exit", (code) => resolve(code ?? 0));
+    child.on("error", (err) => {
+        console.error(pc.red(`Error: failed to spawn ${pm} run build: ${err.message}`));
+        resolve(1);
+    });
+});
 /**
  * Pick the first available package manager from a preference list.
  * Defaults to pnpm (matches the dogsbay tooling chain); falls back
@@ -80,11 +97,13 @@ export async function siteDev(cwd, options, runner = defaultRunner) {
         throw err;
     }
 }
-export async function sitePreview(cwd, options, runner = defaultRunner) {
+export async function sitePreview(cwd, options, runner = defaultRunner, buildRunner = defaultBuildRunner) {
     const { outputDir } = await prepareForAstro(cwd, options);
-    // Two-step: produce dist/ then serve it. Each spawn is independent
-    // so we can still surface its exit code cleanly.
-    const buildCode = await runner(outputDir, ["build"]);
+    // Two-step: produce dist/ via the scaffolded `build` script
+    // (astro build + pagefind), then serve it via astro preview. The
+    // build script is the source of truth — `astro build` alone would
+    // skip pagefind and Cmd+K search in the previewed dist/ would 404.
+    const buildCode = await buildRunner(outputDir);
     if (buildCode !== 0)
         process.exit(buildCode);
     const previewCode = await runner(outputDir, ["preview"]);

package/dist/registry.js

@@ -388,6 +388,14 @@ export const registry = {
         primitives: [],
         description: "Clickable card with link",
     },
+    icon: {
+        name: "icon",
+        files: ["Icon.astro", "index.ts"],
+        dependencies: ["@dogsbay/icons"],
+        registryDependencies: [],
+        primitives: [],
+        description: "Build-time-resolved icon (Lucide default; mdi:, simple-icons:, etc. via Iconify)",
+    },
     sidebar: {
         name: "sidebar",
         files: ["Sidebar.astro", "SidebarContent.astro", "SidebarGroup.astro", "SidebarGroupContent.astro", "SidebarGroupLabel.astro", "SidebarHeader.astro", "SidebarInset.astro", "SidebarMenu.astro", "SidebarMenuButton.astro", "SidebarMenuItem.astro", "SidebarNavTree.astro", "SidebarProvider.astro", "SidebarRail.astro", "SidebarSeparator.astro", "SidebarTrigger.astro", "sidebar.ts", "index.ts"],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dogsbay",
-  "version": "0.2.0-beta.11",
+  "version": "0.2.0-beta.13",
   "description": "CLI for Dogsbay — scaffold, build, and serve documentation sites with markdown / MkDocs / Obsidian / OpenAPI sources",
   "type": "module",
   "bin": {
@@ -32,14 +32,14 @@
     "picocolors": "^1.1.0",
     "prompts": "^2.4.2",
     "yaml": "^2.8.3",
-    "@dogsbay/format-obsidian": "0.2.0-beta.11",
-    "@dogsbay/format-astro": "0.2.0-beta.11",
-    "@dogsbay/format-mkdocs": "0.2.0-beta.11",
-    "@dogsbay/format-mdx": "0.2.0-beta.11",
-    "@dogsbay/format-openapi": "0.2.0-beta.11",
-    "@dogsbay/format-dogsbay-md": "0.2.0-beta.11",
-    "@dogsbay/types": "0.2.0-beta.11",
-    "@dogsbay/format-starlight": "0.2.0-beta.11"
+    "@dogsbay/format-mkdocs": "0.2.0-beta.13",
+    "@dogsbay/format-astro": "0.2.0-beta.13",
+    "@dogsbay/format-mdx": "0.2.0-beta.13",
+    "@dogsbay/format-starlight": "0.2.0-beta.13",
+    "@dogsbay/format-obsidian": "0.2.0-beta.13",
+    "@dogsbay/format-dogsbay-md": "0.2.0-beta.13",
+    "@dogsbay/format-openapi": "0.2.0-beta.13",
+    "@dogsbay/types": "0.2.0-beta.13"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",

package/skills/platform/markdown-directives/SKILL.md

@@ -177,6 +177,54 @@ icon: rocket
 
 Both forms are accepted by the parser.
 
+## Link card (`:::link-card`)
+
+A focused variant of `:::card` for "go here next" navigation
+affordances. Renders a chevron arrow on the right and a
+distinctive hover state — visually clearer that it's a link
+rather than a content tile.
+
+```markdown
+:::link-card{title="Configuration guide" href="/config/"}
+Site name, theme, base path, and per-source settings live in
+dogsbay.config.yml.
+:::
+```
+
+YAML body form when prop count or content grows:
+
+```markdown
+:::link-card
+---
+title: Configuration guide
+description: |
+  Site name, theme, base path, and per-source settings live in
+  dogsbay.config.yml.
+href: /config/
+---
+:::
+```
+
+Props: `title` (required), `href` (required), `description`
+(optional — also accepted as the body paragraph for ergonomic
+authoring). No `icon` slot — link-cards intentionally lean on
+the chevron alone for the link affordance. When you need an
+icon, use `:::card`.
+
+### When to pick which card directive
+
+- **`:::cards`** (plural) — list of related links, displayed as
+  a responsive grid. Best for "browse next" clusters at the
+  end of a page or on a landing page. Items are bulleted-link
+  shorthand.
+- **`:::card`** (singular) — one rich card with full prop
+  surface (`icon`, `variant`, custom classes, arbitrary body).
+  Use when you want a tile with deliberate visual weight.
+- **`:::link-card`** — one card scoped to a single navigation
+  link, with chevron arrow. Use for callouts that lead the
+  reader somewhere specific ("Continue with Configuration
+  guide →").
+
 ## Grid
 
 Generic responsive grid container with `cols` and `gap` attrs: