@nimtech/nimpress 2.3.1

package/.claude/rules/roadmap-entries.md

@@ -0,0 +1,154 @@
+# Authoring roadmap pages
+
+Rules for the `type: roadmap` page and the issue pages that fill its timeline.
+
+## Two file types
+
+1. One `type: roadmap` file per roadmap. Its filename is arbitrary. It defines the header markdown, hero text, and background of the roadmap page itself.
+
+2. Many sibling files of `type: milestone | epic | feature | bug`. Each is a real standalone page at its own URL. Collectively call these issue pages.
+
+The plugin discovers a roadmap by walking the content tree and finding any file whose frontmatter declares `type: roadmap`. Each such file produces one roadmap page in the sidebar. Multiple roadmap files in different folders produce independent roadmaps.
+
+## Layout in the file tree
+
+```
+docs/
+└── solutions/
+    └── bookable/
+        └── roadmap/
+            ├── overview.md             # type: roadmap, header markdown lives here
+            ├── public-booking-calendar.md   # type: epic
+            ├── notification-routing.md      # type: feature
+            └── api-error-mapping.md         # type: bug
+```
+
+By default the roadmap pulls issue pages from the same folder as the roadmap file. Override the scope with `data.issues` or `data.entries` (relative paths or array of paths) on the roadmap file to point at one or more subfolders.
+
+## Filenames are the ids
+
+Filename without `.md` is the issue id. References from `data.parent` on issues and `data.issue` on changelog entries are written as relative paths (with or without `.md`).
+
+There is no `data.id` field. Do not invent one.
+
+## Roadmap file frontmatter
+
+```yaml
+---
+title: Bookable roadmap
+type: roadmap
+description: What we are building, what we are shipping, and what is on the horizon.
+background: /img/roadmap-bg.svg
+data:
+  changelog: ../changelog
+---
+```
+
+1. `title` is the page title. The roadmap file's markdown body renders as the page header above the timeline.
+
+2. `data.changelog` is optional. A relative path to a changelog folder whose entries should plot markers on the spine and feed the rocket progress. Omit to auto-discover from any changelog that links into one of this roadmap's issues via `data.issue`. Explicit scope takes priority when set.
+
+3. `data.issues` or `data.entries` is optional. A relative path or array of paths. The roadmap pulls issue pages from these directories instead of the default sibling scope.
+
+## Issue file frontmatter
+
+```yaml
+---
+title: Public booking calendar surface
+type: epic
+description: A customer facing booking calendar that runs end to end on mobile and desktop web.
+data:
+  date: 2026-08-21
+  parent: organization-settings
+---
+```
+
+1. `title` is required.
+
+2. `type` must be one of `milestone | epic | feature | bug`. The renderer paints the card and the issue page chrome differently per kind.
+
+3. `description` is one short sentence. Plain text. Shown on the timeline card and on the hover aside.
+
+4. `data.date` is required. An RFC 3339 date or full timestamp. Drives the chronological position on the spine and the sidebar order (oldest at top).
+
+5. `data.parent` is optional. The filename (with or without `.md`) of another issue in the same roadmap. The renderer pairs the child next to its parent on the timeline. The sidebar nests the child under the parent.
+
+## Changelog linkage
+
+A changelog entry opts in to an issue with `data.issue: <relative path>` and reports its effect on the issue with `data.status`. The plugin resolves the path against the changelog file's directory.
+
+```yaml
+data:
+  version: 1.5.0
+  release_date: 2026-06-10
+  title: Calendar selection surface
+  description: Plain text sentence.
+  issue: ../roadmap/public-booking-calendar
+  status: 60
+```
+
+1. `data.issue` is a relative path to the issue file. The resolved file must exist as a roadmap issue, or the link is dropped.
+
+2. `data.status` is one of:
+
+2.1. A number `0..100`. The percent of the issue this release advanced. The highest number across all linked releases sets the rocket position.
+
+2.2. The literal word `completes` (also accepts `completed`, `complete`, `closes`, `fixes`, `resolves`). The issue flips to `shipped` and the rocket settles at this point. Use the verb that matches your commit and PR style.
+
+3. The release lands a marker on the roadmap spine at the changelog `release_date`. Clicking the marker navigates to the changelog entry's URL.
+
+## Card and timeline
+
+1. Cards alternate left and right of the spine by default. Issues with a `data.parent` sit next to their parent in chronological order.
+
+2. Each card carries the `KIND` label as a solid colored pill at the top-left and the target date at the top-right. Title below, description below that. The kind pill is indigo for epic, green for feature, red for bug.
+
+3. The card border color carries the issue status. Green for shipped, yellow for in progress, the default border for planned. Status is driven by the linked changelog `data.status`, so authors set status through the changelog, not on the issue file.
+
+4. Card backgrounds are organic SVG blobs deterministically generated from the filename, so each card looks unique but stays stable.
+
+5. The spine is a single smooth curve from the planet at the bottom to an arrow at the top. The arc length between two consecutive issues scales with the time between them, so a long gap draws a longer stretch of path. The traveled portion is solid, the untraveled portion is dashed and muted, matching the top arrow.
+
+6. Today renders as a short tick drawn as a normal to the path, carrying a date-only label placed on the side away from the nearest issue. An SVG rocket sits at the chronological position of today, or at the highest linked changelog progress, whichever is further.
+
+7. Every linked changelog entry drops a smaller dotted marker with the version and release date at its release-date position. Clicking the marker navigates to the changelog entry.
+
+8. Clicking a card navigates to the issue's own page (each issue is a real standalone page at its file URL).
+
+## Responsive
+
+1. At 800px viewport width and below, every issue moves into a single column on the right, ordered by date with the oldest at the bottom.
+
+2. The spine becomes a straight vertical line on the left. It starts at the globe at the bottom, curls to the left, and runs straight up to the top arrow. Each card connects to the line with a horizontal connector.
+
+3. The hover aside is off at this width. Tapping a card navigates to its page.
+
+## Hover aside
+
+1. Desktop (above 900px viewport): hovering or focusing a card opens a floating aside on the opposite side that mirrors the issue's markdown body and lists the shipping changelogs. Mobile (≤900px): no hover; tap navigates.
+
+## Sidebar
+
+1. The roadmap page is the parent node.
+
+2. Issue pages list as children sorted by `data.date` ascending (oldest first, newest last).
+
+3. Children with `data.parent` nest under the parent issue in the sidebar.
+
+4. Each issue page has its own URL and renders through the standard page chrome with a kind chip and date header.
+
+5. Each row carries an icon for its kind: a flag for milestone, a box for epic, a sparkle for feature, an alert for bug. The icons live in `issueKindIcon` in `src/plugin.ts` and are not authored per page.
+
+## Right TOC
+
+1. The roadmap page itself has no right TOC.
+
+2. Issue pages keep the right TOC like regular doc pages.
+
+## What not to include
+
+1. Internal status updates better suited to issue comments.
+
+2. Customer names or contracts. The roadmap page is customer facing.
+
+3. Pricing or dates that are not yet committed publicly.

package/.claude/rules/style.md

@@ -0,0 +1,61 @@
+# Styling and theming
+
+Rules for changing how Nimpress looks, both inside the framework and inside consumer overrides.
+
+## Token first
+
+Every visual choice goes through a CSS custom property. Token catalog lives in `src/styles/tokens.css`. Before touching a component's CSS, check whether a token already covers it.
+
+## When to add a token
+
+1. The value appears in more than one component.
+
+2. Consumers will want to override it without forking.
+
+3. It has light and dark variants.
+
+If none of those apply, keep the literal value in the component.
+
+## Class naming
+
+1. Every component root carries a stable `np-<scope>` class.
+
+2. Internal elements carry `np-<scope>-<part>` classes.
+
+3. The class set on rendered chrome is the public API. Renames go through a major version bump.
+
+## Overrides from consumers
+
+Consumers override Nimpress styles by:
+
+1. A site wide stylesheet named in the `css` config field. nimpress loads it after the framework styles, so setting CSS custom properties on `:root` and `html.dark` or targeting the public `np-` classes there wins the cascade.
+
+2. A per page stylesheet named the same as a markdown file. `guide/index.css` next to `guide/index.md` loads while the route is `/guide` or any path under it. A leaf page's stylesheet loads only on its own page. The author writes normal selectors and they apply only while inside that subtree.
+
+3. A css file that is not a page style, such as a story asset loaded with `?raw`, is named with a leading underscore, `template/_cv.css`. Lint treats underscore css as inert; any other css file must sit next to the markdown page it is named after.
+
+Consumers never need to fork the framework to change visuals.
+
+## Light and dark
+
+Every token has a light and a dark value. Adding a token means adding both. Tokens without a dark variant break the theme toggle.
+
+## Geometry tokens
+
+1. `--np-radius-sm`, `--np-radius-md`, `--np-radius-lg`, `--np-radius-pill` for rounded corners. Pick the smallest one that reads correctly.
+
+2. `--np-header-height`, `--np-sidebar-width`, `--np-toc-width`, `--np-content-max` for layout. Sticky positioning math depends on these. Do not bypass them with hardcoded pixels.
+
+## Spacing
+
+No spacing token system. Spacing is per component. Keep values to multiples of 4px for visual rhythm.
+
+## Don't
+
+1. Do not write component scoped styles in `tokens.css`. Tokens describe values, not components.
+
+2. Do not introduce a CSS preprocessor. Vanilla CSS only.
+
+3. Do not introduce a CSS in JS library. Svelte's scoped `<style>` is the carrier.
+
+4. Do not add `!important`. If you reach for it, the cascade is fighting your structure, fix the structure.

package/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 nimling
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -0,0 +1,137 @@
+<div align="center">
+  <img src="assets/logo.svg" alt="Nimpress" width="320" />
+
+  <span><i>Svelte 5 docs framework that supports it all.</i></span>
+</div>
+
+## Documentation
+
+The full documentation is at **[nimling.github.io/nimpress](https://nimling.github.io/nimpress/)**. It is built from the `docs/` folder of this repository with nimpress itself and redeploys on every release, so it is always the current reference. This file stays short and points there.
+
+| Topic | Guide |
+|-------|-------|
+| Getting started, config, first site | [Getting started](https://nimling.github.io/nimpress/getting-started) |
+| CLI reference: every command, flag, and exit code | [CLI](https://nimling.github.io/nimpress/cli) |
+| Page types: `doc`, `openapi`, `changelog`, `hero`, `roadmap`, `dbml`, `component` | [Page types](https://nimling.github.io/nimpress/page-types) |
+| Component workshop: systems, stories, harness, controls, import CLI | [Modules](https://nimling.github.io/nimpress/modules) |
+| Markdown support, callouts, actions, features | [Markdown](https://nimling.github.io/nimpress/markdown) |
+| Definition lists for compact term references | [Definition lists](https://nimling.github.io/nimpress/definition-lists) |
+| Mermaid diagrams | [Mermaid](https://nimling.github.io/nimpress/mermaid) |
+| DBML database diagrams | [DBML](https://nimling.github.io/nimpress/dbml) |
+| OpenAPI renderer | [OpenAPI](https://nimling.github.io/nimpress/openapi) |
+| Changelog renderer | [Changelog renderer](https://nimling.github.io/nimpress/changelog-renderer) |
+| Hero landing pages | [Hero](https://nimling.github.io/nimpress/hero) |
+| SEO and social cards | [SEO](https://nimling.github.io/nimpress/seo) |
+| Build pipeline, build outputs, shell and body split | [Build pipeline](https://nimling.github.io/nimpress/build-pipeline) |
+| Relative links between pages | [Relative links](https://nimling.github.io/nimpress/relative-links) |
+| Frontmatter reference | [Frontmatter](https://nimling.github.io/nimpress/frontmatter) |
+| Sidebar layout from the content tree | [Sidebar](https://nimling.github.io/nimpress/sidebar) |
+| Theming and overriding styles | [Theming](https://nimling.github.io/nimpress/theming) |
+| Auth and the gate guard flow | [Auth](https://nimling.github.io/nimpress/auth) |
+| Search index | [Search](https://nimling.github.io/nimpress/search) |
+| Publishing docs to a central site, the sync actions, and their secrets | [Pipeline](https://nimling.github.io/nimpress/actions) |
+| Every release | [Releases](https://nimling.github.io/nimpress/changelog/) |
+
+## Getting started
+
+```bash
+pnpm add @nimtech/nimpress
+```
+
+`@nimtech/nimpress` is public on npm. No `.npmrc`, no registry line, no token. It just works.
+
+## Set up a site
+
+A consumer needs one config file and the `nimpress` CLI. The CLI owns Vite, serves the app shell and entry as virtual modules, and reads `nimpress.config`. There is no Vite config to write and no app to mount by hand.
+
+```bash
+pnpm exec nimpress init
+```
+
+That writes a starter `nimpress.config.ts` and a content folder:
+
+```ts
+import { defineConfig } from '@nimtech/nimpress/plugin'
+
+export default defineConfig({
+  title: 'Docs',
+  logo: '/assets/logo.png',
+  github: 'https://github.com/nimling/your-repo',
+  contentDir: 'docs'
+})
+```
+
+Every field has a default, so a config can be as small as a title. Wire the CLI into `package.json`:
+
+```json
+{
+  "scripts": {
+    "dev": "nimpress dev",
+    "build": "nimpress build",
+    "lint": "nimpress lint"
+  }
+}
+```
+
+The rest of the config surface, every command, and the build outputs are covered in [Getting started](https://nimling.github.io/nimpress/getting-started) and the [CLI reference](https://nimling.github.io/nimpress/cli).
+
+## Authoring docs with Claude
+
+The package ships the authoring rules at `node_modules/@nimtech/nimpress/.claude/rules/`. They cover how to write each page type: docs, changelog entries, hero pages, roadmap pages, roadmap issues, and dbml pages, plus frontmatter, file layout, and styling.
+
+Claude does not auto load rules from inside `node_modules`, so `nimpress init` writes a `CLAUDE.md` and an `AGENTS.md` pointing at them. In a repo that adds nimpress by hand, add the pointer yourself:
+
+```md
+## Nimpress docs authoring
+
+When writing or editing markdown under the docs content directory, follow the Nimpress authoring rules in `node_modules/@nimtech/nimpress/.claude/rules/`. Read the rule that matches the page type before writing:
+
+- `docs-authoring.md`, `doc-pages.md`, `page-types.md`, `frontmatter.md`, `file-layout.md` for general pages
+- `changelog-entries.md` for changelog entries
+- `roadmap-entries.md` for roadmap pages and issue pages
+- `dbml-pages.md` for database diagram pages and inline dbml fences
+- `component-modules.md` for component pages, stories, and the workshop
+- `style.md` for theming and overrides
+```
+
+## Working on Nimpress itself
+
+| Command | Description |
+|---------|-------------|
+| `just install` | Install dependencies with pnpm |
+| `just build` | Build the library bundle into `dist/` |
+| `just check` | Run svelte-check and tsc |
+| `just test` | Run the actions go tests, the CLI vitest suite, and the type checks |
+| `just dev` | Serve this repo's `docs/` with a watching library rebuild |
+| `just site` | Build this repo's `docs/` into `dist/site` |
+| `just deploy` | Patch version bump, tag, and trigger the publish workflows |
+| `just deploy-minor` | Minor version bump and publish |
+| `just deploy-major` | Major version bump and publish |
+
+A version tag publishes the package to npm, deploys `docs/` to GitHub Pages, and moves the major tag on the actions.
+
+## Structure
+
+```
+nimpress/
+├── assets/                 Logo and brand artwork
+├── bin/nimpress.mjs        CLI entry
+├── docs/                   The documentation site, built and published on every release
+├── actions/                Cross repo docs sync GitHub Actions
+├── src/
+│   ├── index.ts            Public Svelte exports
+│   ├── plugin.ts           Vite plugin and defineConfig
+│   ├── cli.ts              CLI dispatch
+│   ├── cli/                One module per command: init, lint, site, guard, export, modules
+│   ├── config/             Config load, defaults, schema, Vite and html
+│   ├── framework/          App bootstrap, router, stores
+│   ├── layout/             Shell, header, sidebar, breadcrumbs, right TOC
+│   ├── markdown/           Page, ChangelogPage, HeroPage, DbmlPage, callouts, code blocks
+│   ├── api/                OpenAPI renderer
+│   ├── dbml/               DBML to diagram model conversion, run at build time
+│   ├── search/             MiniSearch wrapper and modal
+│   ├── auth/               Session login guard
+│   └── styles/             Tokens and preflight
+├── tailwind.preset.ts      Design tokens exported for consumers
+└── justfile                Task runner
+```

package/bin/nimpress.mjs

@@ -0,0 +1,7 @@
+#!/usr/bin/env node
+import { run } from '../dist/cli.es.js'
+
+run(process.argv.slice(2)).catch((err) => {
+  console.error(err)
+  process.exit(1)
+})