@hutusi/amytis 1.7.0 → 1.9.0

package/content/notes/react-server-components.mdx

@@ -0,0 +1,49 @@
+---
+title: "React Server Components"
+date: "2026-02-10"
+tags: ["react", "nextjs", "architecture"]
+---
+
+React Server Components (RSC) represent the most significant architectural shift in React since hooks. The mental model: components that run only on the server, produce static output, and ship *zero* JavaScript to the client.
+
+## The Key Insight
+
+Before RSC, React components were always client-side primitives — even when rendered on the server via SSR, their JavaScript was re-hydrated in the browser. RSC breaks this assumption. A server component:
+
+- Can directly `await` database queries, file reads, or API calls
+- Never re-renders on the client (no hydration cost)
+- Can import server-only packages without any client bundle impact
+
+## Composition Model
+
+The power is in the *composition*: you can freely mix server and client components in the same tree. A server component can render a client component; a client component can receive server-rendered children as props.
+
+```tsx
+// Server component — runs only on server
+async function ArticlePage({ slug }: { slug: string }) {
+  const post = await getPostBySlug(slug); // direct DB/file access
+  return (
+    <article>
+      <h1>{post.title}</h1>
+      <LikeButton postId={post.id} /> {/* client component */}
+      <MarkdownContent content={post.body} /> {/* server component */}
+    </article>
+  );
+}
+```
+
+## The "use client" Boundary
+
+`"use client"` marks the boundary where server-rendered output hands off to client-side JavaScript. It doesn't mean "client-only" — server-rendered HTML still crosses the boundary; only interactivity (event handlers, state) requires the client bundle.
+
+Common pitfall: passing non-serializable values (like a `Map` or class instance) through the boundary. These can't be serialized to JSON and will cause a runtime error.
+
+## Relation to Hooks
+
+RSC doesn't replace React hooks — hooks remain the right tool for client-side state and effects. The shift is that *data fetching* moves to the server, while *interactivity* stays with hooks on the client.
+
+The practical result: far less `useEffect` for data loading, simpler components, better performance.
+
+## In Next.js App Router
+
+Next.js App Router makes RSC the default. Every component in `app/` is a server component unless it declares `"use client"`. This site's data layer (`src/lib/markdown.ts`) runs exclusively on the server — no API routes needed.

package/content/notes/tailwind-v4.mdx

@@ -0,0 +1,45 @@
+---
+title: "Tailwind CSS v4"
+date: "2026-02-12"
+tags: ["css", "tailwind", "frontend"]
+aliases: ["tailwind-css-v4"]
+---
+
+Tailwind CSS v4 is a complete rewrite of the framework, shifting from a JavaScript-based configuration model to a CSS-first approach. The migration story is smoother than expected, and the performance improvements are significant.
+
+## CSS-First Configuration
+
+The biggest change: configuration moves from `tailwind.config.js` into your CSS file using the `@theme` directive.
+
+```css
+@import "tailwindcss";
+
+@theme {
+  --color-accent: oklch(60% 0.2 250);
+  --font-serif: "Georgia", serif;
+  --spacing-18: 4.5rem;
+}
+```
+
+This means your design tokens live in CSS — where they belong. You can inspect them in DevTools, use them in arbitrary CSS, and they compose naturally with CSS custom properties.
+
+## The New Engine
+
+v4's engine is built in Rust (via Lightning CSS) and is dramatically faster. Cold starts drop from seconds to milliseconds. The dev server no longer needs to scan your content for class names — it intercepts class usage at the PostCSS level.
+
+## Breaking Changes
+
+- No more `tailwind.config.js` for most use cases (it still exists for plugins)
+- Default ring width changed from 3px to 1px
+- Standalone opacity utilities removed — use slash syntax instead (e.g., `bg-black/50`)
+- The `!important` modifier moves to the end of the class name (e.g., `shadow-md!` not `!shadow-md`)
+- `@apply` works differently for custom utilities
+- Dark mode config moves to CSS: `@custom-variant dark (&:where(.dark, .dark *))`
+
+## Integration with React Server Components
+
+Tailwind v4 pairs well with [[react-server-components|React Server Components]]. Static CSS generation means zero runtime overhead — the right tool for a server-rendered architecture. The class scanning approach would have conflicted with server components anyway (no runtime class generation).
+
+## This Site
+
+This garden uses Tailwind v4 with a custom theme defined entirely in `src/app/globals.css`. Theme colors use CSS custom properties so the light/dark toggle works without JavaScript class manipulation.

package/content/notes/zettelkasten-method.mdx

@@ -0,0 +1,33 @@
+---
+title: "Zettelkasten Method"
+date: "2026-02-01"
+tags: ["zettelkasten", "note-taking", "knowledge-management"]
+---
+
+The Zettelkasten ("slip-box") method is a personal knowledge management system developed by sociologist Niklas Luhmann. He produced over 90 books and hundreds of articles, crediting much of his productivity to this system.
+
+## Core Principles
+
+**Atomic notes** — each note captures exactly one idea. If you need to say two things, write two notes. This constraint forces clarity and creates more connection points.
+
+**Linking over filing** — instead of organizing notes into folders or categories, you link them to related ideas. The structure that emerges is a network, not a tree.
+
+**Your own words** — always paraphrase rather than copy. The act of rewriting forces understanding and makes the note genuinely yours.
+
+**Permanent notes** — unlike fleeting notes (quick captures) or literature notes (summaries of sources), permanent notes are written to last. They connect to existing knowledge and stand alone without context.
+
+## Why It Works
+
+A folder system forces you to predict how you'll want to retrieve something. Linking lets you discover connections you didn't anticipate. Luhmann described his Zettelkasten as a "conversation partner" — it would surprise him with unexpected connections between distant ideas.
+
+The compounding effect is real: the more notes you have, the more connections are possible, and the more generative each new note becomes.
+
+## Relation to Digital Gardens
+
+[[digital-garden-philosophy]] takes the Zettelkasten spirit and applies it to public publishing. Where Luhmann's slip-box was private, a digital garden invites readers into the thinking process — with all its incompleteness and revision.
+
+## In This Garden
+
+This site implements Zettelkasten-style notes with bi-directional links. Any `[[wikilink]]` you write creates a connection that shows up in the backlinks panel of the target note.
+
+See the [[digital-garden-philosophy]] note for how this fits the broader philosophy of this garden.

package/content/series/digital-garden/01-philosophy.mdx

@@ -1,7 +1,7 @@
 ---
 title: "The Philosophy of Digital Gardening"
 date: "2025-12-15"
-excerpt: "Moving away from chronological feeds to contextual networks."
+excerpt: "How ideas evolve from raw daily flows into articles, series, and books — the philosophy behind the Amytis knowledge ladder."
 category: "Philosophy"
 tags: ["pkm", "knowledge management", "learning"]
 authors: ["Amytis Team"]
@@ -9,22 +9,35 @@ authors: ["Amytis Team"]
 
 # The Philosophy of Digital Gardening
 
-Unlike a traditional blog, which is a reverse-chronological stream of finished "publications," a **digital garden** is a collection of evolving notes.
+Unlike a traditional blog — a reverse-chronological stream of finished "publications" — a **digital garden** is a collection of evolving ideas. Notes are never truly done. They grow, branch, and connect over time.
 
 ## Gardening vs. Architecting
 
-- **Architecting** is about planning everything upfront.
-- **Gardening** is about planting seeds and seeing what grows.
+- **Architecting** is about planning everything upfront. You design the structure, then fill it in.
+- **Gardening** is about planting seeds and tending to what grows. The structure emerges from the content.
 
-### Key Principles
+Most personal publishing starts as architecting: "I'll write a three-part series on X." Digital gardening inverts this — you write when you have something to say, and patterns emerge later.
 
-1. **Topography over Chronology:** Organize by topic and connection, not just by date.
-2. **Continuous Growth:** Notes are never "finished." They are tended to over time.
-3. **Imperfection:** It is okay to share "seedling" thoughts that aren't fully formed.
+## Key Principles
+
+**Topography over chronology.** Organize by topic and connection, not by date. The question isn't "when did I write this?" but "how does this connect to that?"
+
+**Continuous growth.** A note is never "published and done." It is a living document — refined, expanded, and linked as your thinking evolves.
+
+**Imperfection is allowed.** Share seedling thoughts that aren't fully formed. A rough idea made public is more valuable than a perfect idea kept private.
+
+## From Seeds to Trees: The Knowledge Ladder
+
+In Amytis, the digital garden philosophy maps directly to four content types:
+
+**Flow** — The seed. Raw, unfiltered daily notes. Capture thoughts as they arrive, without worrying about form or permanence.
+
+**Articles** — The sprout. A single idea, tended to until it's clear and shareable. One thought, fully articulated.
+
+**Series** — The plant. Related articles gathered into a curated collection, exploring a broader theme across multiple pieces.
+
+**Books** — The tree. Mature knowledge organized into structured volumes — the most permanent and distilled form an idea can take.
 
 > "A garden is never finished."
 
-In this garden, you will find a mix of:
-- **Seedlings:** Rough notes and initial thoughts.
-- **Saplings:** Growing ideas with some structure.
-- **Evergreens:** Well-developed concepts.
+Each stage is valid on its own. Not every flow becomes an article; not every article joins a series. The garden grows at its own pace.

package/docs/ARCHITECTURE.md

@@ -4,7 +4,7 @@ Amytis is a static site generator built with **Next.js 16 (App Router)**, design
 
 ## Core Stack
 
-- **Framework:** Next.js 16.1.1 (App Router) with React 19
+- **Framework:** Next.js 16.1.6 (App Router) with React 19
 - **Runtime:** Bun
 - **Styling:** Tailwind CSS v4 with CSS variables for theming
 - **Content:** Local `.md`/`.mdx` files parsed at build time
@@ -40,6 +40,11 @@ src/app/
     page.tsx                        # All books overview
     [slug]/page.tsx                 # Book landing page
     [slug]/[chapter]/page.tsx       # Individual book chapter
+  notes/
+    page.tsx                        # All notes list
+    [slug]/page.tsx                 # Individual note
+  graph/
+    page.tsx                        # Knowledge graph visualization
   flows/
     page.tsx                        # Flows stream/listing
     [year]/[month]/[day]/page.tsx   # Individual flow entry (optional if modal/stream used)
@@ -96,6 +101,9 @@ src/app/
 | `getAllBooks()` | `BookData[]` | All books metadata |
 | `getBookData(slug)` | `BookData \| null` | Single book metadata & TOC |
 | `getBookChapter(...)` | `BookChapterData` | Single chapter content |
+| `getAllNotes()` | `NoteData[]` | All notes, sorted by date |
+| `getNoteBySlug(slug)` | `NoteData \| null` | Single note content |
+| `getBacklinks(slug)` | `BacklinkSource[]` | Inbound links for a page |
 | `getFlowBySlug(slug)` | `FlowData \| null` | Single flow entry |
 | `getSeriesPosts(slug)` | `PostData[]` | Posts in a series |
 | `calculateReadingTime(content)` | `string` | Estimated reading time (multilingual) |

package/docs/CONTRIBUTING.md

@@ -55,6 +55,18 @@ Books are manually structured in `content/books/`.
 2. Add `index.mdx` with metadata and chapters configuration.
 3. Create the chapter files (`welcome.mdx`, `conclusion.mdx`) in the same folder.
 
+### Creating Notes (Digital Garden)
+
+Notes live in `content/notes/`.
+
+```bash
+# Create a new note using the dedicated script
+bun run new-note "Zettelkasten Method"
+
+# Or using the general new script
+bun run new "Zettelkasten Method" --note
+```
+
 ### Importing Content
 
 ```bash
@@ -63,6 +75,20 @@ bun run new-from-pdf doc.pdf --title "My Doc"
 
 # Image folder to post
 bun run new-from-images ./photos --title "Gallery"
+
+# Chat logs to flows
+bun run new-flow-from-chat
+```
+
+### Maintenance Tools
+
+```bash
+# Sync book chapters with files in the folder
+bun run sync-book
+
+# Bulk draft/publish a series
+bun run series-draft "my-series"
+bun run series-draft "my-series" --undraft
 ```
 
 ## Running Tests

package/docs/DIGITAL_GARDEN.md

@@ -0,0 +1,72 @@
+# Digital Garden Features
+
+Amytis includes a suite of features designed for non-linear knowledge management, inspired by the "Digital Garden" philosophy. These features allow you to create an interconnected web of thoughts rather than just a linear stream of posts.
+
+## Core Concepts
+
+### 1. Notes (`/notes`)
+Notes are atomic units of knowledge. Unlike posts, which are often time-bound articles, notes are evergreen and concept-oriented.
+
+- **Location:** `content/notes/*.mdx`
+- **Frontmatter:**
+  ```yaml
+  ---
+  title: "Zettelkasten Method"
+  tags: ["pkm", "productivity"]
+  aliases: ["zettelkasten", "slip-box"] # Alternative names for wiki-linking
+  backlinks: true # Show backlinks at the bottom (default: true)
+  ---
+  ```
+
+### 2. Wiki-links
+You can link between any content (Posts, Notes, Flows) using double-bracket syntax: `[[Slug]]` or `[[Slug|Display Text]]`.
+
+- **Standard Link:** `[[zettelkasten-method]]` → links to `/notes/zettelkasten-method`
+- **Aliased Link:** `[[zettelkasten-method|The Slip Box]]` → links to same note but displays "The Slip Box"
+- **Cross-Type Linking:**
+  - If a slug matches a Note, it links to `/notes/[slug]`
+  - If it matches a Post, it links to `/posts/[slug]`
+  - If it matches a Flow, it links to `/flows/[slug]`
+
+### 3. Backlinks
+At the bottom of every Note, Amytis automatically generates a "Linked References" section. This lists every other page that links *to* the current note, along with a context snippet showing how it was referenced.
+
+### 4. Knowledge Graph
+The `/graph` route visualizes your entire digital garden as an interactive network graph.
+- **Nodes**: Represent Notes, Posts, and Flows.
+- **Edges**: Represent wiki-links connecting them.
+- **Interaction**: Click a node to navigate to that page.
+
+### 5. Flows (`/flows`)
+Flows are a stream-style collection of daily notes, micro-blogging, or imported chat logs. They are ideal for quick thoughts that don't necessarily warrant a full blog post.
+
+- **Location:** `content/flows/YYYY/MM/DD.mdx`
+- **Navigation:** Grouped by date in a timeline view.
+- **Importing:** Use `bun run new-flow-from-chat` to bring in external conversations.
+
+## How to Use
+
+1. **Create a Note**: Run `bun run new-note "My Concept"` (or `bun run new "My Concept" --note`).
+2. **Create a Flow**: Run `bun run new-flow`.
+3. **Link to it**: In a blog post, note, or flow, type `[[my-concept]]` or `[[2026-02-27]]`.
+4. **Explore**: Visit `/notes` or `/flows` to see your collection, or `/graph` to see the connections.
+
+## Configuration
+
+In `site.config.ts`, you can configure the graph visualization:
+
+```typescript
+export const siteConfig = {
+  // ...
+  features: {
+    graph: {
+      enabled: true,
+      name: { en: "Graph", zh: "知识图谱" },
+    },
+    notes: {
+      enabled: true,
+      name: { en: "Notes", zh: "笔记" },
+    }
+  }
+};
+```

package/imports/README.md

@@ -0,0 +1,45 @@
+# imports/
+
+Drop source files here before running import scripts.
+**All contents are gitignored** — files stay local and are never committed.
+
+## Subdirectories
+
+| Directory  | Command                        | What goes here                          |
+|------------|--------------------------------|-----------------------------------------|
+| `chats/`   | `bun run new-flow-from-chat`   | Group chat export files (`.txt`)        |
+| `pdfs/`    | `bun run new-from-pdf`         | PDF documents → posts with page images  |
+| `images/`  | `bun run new-from-images`      | Image folders → gallery posts           |
+
+## chats/ — auto-import workflow
+
+Drop `.txt` chat export files into `imports/chats/` and run:
+
+```bash
+bun run new-flow-from-chat            # import all new files
+bun run new-flow-from-chat --dry-run  # preview first
+bun run new-flow-from-chat --all      # re-import everything
+```
+
+Already-processed filenames are tracked in `imports/chats/.imported`.
+Running the command again will only pick up files added since the last run.
+
+### Expected file format
+
+```
+username YYYY-MM-DD HH:mm:ss
+message line 1
+message line 2
+
+username YYYY-MM-DD HH:mm:ss
+message line 1
+```
+
+### Options
+
+| Flag              | Effect                                              |
+|-------------------|-----------------------------------------------------|
+| `--author "Name"` | Only include messages from one participant          |
+| `--append`        | Append to an existing flow instead of skipping      |
+| `--dry-run`       | Preview without writing any files                   |
+| `--all`           | Re-import all files, ignoring previous import history |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hutusi/amytis",
-  "version": "1.7.0",
+  "version": "1.9.0",
   "description": "A high-performance digital garden and blog engine with Next.js 16 and Tailwind CSS v4",
   "repository": {
     "type": "git",
@@ -14,8 +14,9 @@
   "packageManager": "bun@1.3.4",
   "scripts": {
     "dev": "next dev",
-    "build": "bun scripts/copy-assets.ts && next build && next-image-export-optimizer && pagefind --site out",
-    "build:dev": "bun scripts/copy-assets.ts && next build && pagefind --site out --output-path public/pagefind",
+    "build": "bun scripts/copy-assets.ts && bun run build:graph && next build && next-image-export-optimizer && pagefind --site out",
+    "build:dev": "bun scripts/copy-assets.ts && bun run build:graph && next build && pagefind --site out --output-path public/pagefind",
+    "build:graph": "NODE_ENV=production bun scripts/generate-knowledge-graph.ts",
     "validate": "bun run lint && bun run test && bun run build:dev",
     "clean": "rm -rf .next out public/posts public/books public/flows",
     "new": "bun scripts/new-post.ts",
@@ -24,17 +25,22 @@
     "new-from-pdf": "bun scripts/new-from-pdf.ts",
     "new-from-images": "bun scripts/new-from-images.ts",
     "new-flow": "bun scripts/new-flow.ts",
+    "new-flow-from-chat": "bun scripts/new-flow-from-chat.ts",
+    "new-note": "bun scripts/new-note.ts",
+    "import-book": "bun scripts/import-book.ts",
+    "sync-book": "bun scripts/sync-book-chapters.ts",
     "series-draft": "bun scripts/series-draft.ts",
     "start": "next start",
     "lint": "eslint",
-    "test": "bun test",
-    "test:unit": "bun test src",
+    "test": "bun test src tests/unit tests/tooling && bun run test:int",
+    "test:unit": "bun test src tests/unit",
     "test:int": "bun test tests/integration",
     "test:e2e": "bun test tests/e2e"
   },
   "dependencies": {
     "@giscus/react": "^3.1.0",
     "@tailwindcss/typography": "^0.5.19",
+    "d3": "^7.9.0",
     "github-slugger": "^2.0.0",
     "gray-matter": "^4.0.3",
     "image-size": "^2.0.2",
@@ -58,6 +64,7 @@
   "devDependencies": {
     "@tailwindcss/postcss": "^4.1.18",
     "@types/bun": "^1.3.9",
+    "@types/d3": "^7.4.3",
     "@types/image-size": "^0.8.0",
     "@types/node": "^24.10.13",
     "@types/react": "^19.2.14",

package/scripts/generate-knowledge-graph.ts

@@ -0,0 +1,162 @@
+/**
+ * Generate public/knowledge-graph.json for the Knowledge Graph visualization.
+ *
+ * Nodes: all posts, all notes, and flows that appear as wikilink source/target.
+ * Edges: wikilink edges (from backlink index) + series membership edges.
+ *
+ * Run: NODE_ENV=production bun scripts/generate-knowledge-graph.ts
+ */
+
+import fs from 'fs';
+import path from 'path';
+import { getAllPosts, getAllNotes, getAllFlows, getSeriesData } from '../src/lib/markdown';
+
+interface GraphNode {
+  id: string;
+  title: string;
+  type: 'post' | 'note' | 'flow' | 'series';
+  url: string;
+  connections: number;
+}
+
+interface GraphEdge {
+  source: string;
+  target: string;
+  type: 'wikilink' | 'series';
+}
+
+function extractWikilinks(content: string): string[] {
+  const slugs: string[] = [];
+  const re = /\[\[([^\]|]+?)(?:\|[^\]]+?)?\]\]/g;
+  let match;
+  while ((match = re.exec(content)) !== null) {
+    slugs.push(match[1].trim());
+  }
+  return slugs;
+}
+
+async function main() {
+  console.log('Generating knowledge graph…');
+
+  const posts = getAllPosts();
+  const notes = getAllNotes();
+  const flows = getAllFlows();
+
+  // Build id→node map
+  const nodeMap = new Map<string, GraphNode>();
+  const edges: GraphEdge[] = [];
+
+  // Add all posts and notes
+  for (const post of posts) {
+    nodeMap.set(post.slug, { id: post.slug, title: post.title, type: 'post', url: `/posts/${post.slug}`, connections: 0 });
+  }
+  for (const note of notes) {
+    nodeMap.set(note.slug, { id: note.slug, title: note.title, type: 'note', url: `/notes/${note.slug}`, connections: 0 });
+  }
+
+  // Track which flows appear in wikilinks (to avoid including ALL flows)
+  const linkedFlowSlugs = new Set<string>();
+
+  // Scan all content for wikilinks
+  const allContent: Array<{ slug: string; title: string; type: 'post' | 'note' | 'flow'; content: string; url: string }> = [
+    ...posts.map(p => ({ slug: p.slug, title: p.title, type: 'post' as const, content: p.content, url: `/posts/${p.slug}` })),
+    ...notes.map(n => ({ slug: n.slug, title: n.title, type: 'note' as const, content: n.content, url: `/notes/${n.slug}` })),
+    ...flows.map(f => ({ slug: f.slug, title: f.title, type: 'flow' as const, content: f.content, url: `/flows/${f.slug}` })),
+  ];
+
+  // Build wikilink edges (deduplicate per source document)
+  for (const item of allContent) {
+    const targets = extractWikilinks(item.content);
+    const seenTargets = new Set<string>();
+    for (const target of targets) {
+      if (target === item.slug) continue; // skip self
+      if (seenTargets.has(target)) continue; // skip duplicate within this doc
+      seenTargets.add(target);
+      edges.push({ source: item.slug, target, type: 'wikilink' });
+
+      // Ensure source exists in nodeMap
+      if (!nodeMap.has(item.slug)) {
+        nodeMap.set(item.slug, { id: item.slug, title: item.title, type: item.type, url: item.url, connections: 0 });
+        if (item.type === 'flow') linkedFlowSlugs.add(item.slug);
+      }
+      // Track referenced flows
+      const targetFlow = flows.find(f => f.slug === target);
+      if (targetFlow) {
+        linkedFlowSlugs.add(target);
+        if (!nodeMap.has(target)) {
+          nodeMap.set(target, { id: target, title: targetFlow.title, type: 'flow', url: `/flows/${target}`, connections: 0 });
+        }
+      }
+    }
+  }
+
+  // Add series nodes + series membership edges
+  const seriesSlugsSet = new Set<string>();
+  for (const post of posts) {
+    if (post.series) seriesSlugsSet.add(post.series);
+  }
+
+  for (const seriesSlug of seriesSlugsSet) {
+    const seriesData = getSeriesData(seriesSlug);
+    const seriesId = `series:${seriesSlug}`;
+    nodeMap.set(seriesId, {
+      id: seriesId,
+      title: seriesData?.title || seriesSlug,
+      type: 'series',
+      url: `/series/${seriesSlug}`,
+      connections: 0,
+    });
+    // Add edges from series to each post
+    for (const post of posts) {
+      if (post.series === seriesSlug) {
+        edges.push({ source: seriesId, target: post.slug, type: 'series' });
+      }
+    }
+  }
+
+  // Compute connection counts
+  for (const edge of edges) {
+    const src = nodeMap.get(edge.source);
+    if (src) src.connections++;
+    const tgt = nodeMap.get(edge.target);
+    if (tgt) tgt.connections++;
+  }
+
+  // Filter out nodes with no edges (isolated) to keep graph clean
+  const connectedIds = new Set<string>();
+  for (const edge of edges) {
+    connectedIds.add(edge.source);
+    connectedIds.add(edge.target);
+  }
+
+  // Always include all notes and posts (they are the knowledge base)
+  const nodes = Array.from(nodeMap.values()).filter(n =>
+    n.type === 'note' || n.type === 'post' || n.type === 'series' || connectedIds.has(n.id)
+  );
+
+  // Filter edges to only include those with both source and target in nodes
+  const validIds = new Set(nodes.map(n => n.id));
+  const validEdges = edges.filter(e => validIds.has(e.source) && validIds.has(e.target));
+
+  // Recompute connection counts from validEdges only (pre-filter counts were inflated)
+  const connectionCounts = new Map<string, number>();
+  for (const edge of validEdges) {
+    connectionCounts.set(edge.source, (connectionCounts.get(edge.source) ?? 0) + 1);
+    connectionCounts.set(edge.target, (connectionCounts.get(edge.target) ?? 0) + 1);
+  }
+  for (const node of nodes) {
+    node.connections = connectionCounts.get(node.id) ?? 0;
+  }
+
+  const graphData = { nodes, edges: validEdges };
+
+  const outputPath = path.join(process.cwd(), 'public', 'knowledge-graph.json');
+  fs.writeFileSync(outputPath, JSON.stringify(graphData, null, 2));
+
+  console.log(`✓ Written ${nodes.length} nodes, ${validEdges.length} edges → ${outputPath}`);
+}
+
+main().catch(err => {
+  console.error('Error generating knowledge graph:', err);
+  process.exit(1);
+});