@powerhousedao/knowledge-note 1.0.3 → 1.0.5

package/README.md

@@ -1,179 +1,416 @@
-# Document Model Boilerplate
+# bai-knowledge-note
 
-This Document Model Boilerplate provides code generation for scaffolding editors and models. 
-It ensures compatibility with host applications like Connect and the Reactors for seamless document model and editor integration.
+A Powerhouse Vetra package for team-wide institutional memory — atomic knowledge notes with typed content, structured links, lifecycle states, and provenance tracking.
 
-## Standard Document Model Workflow with help of the boilerplate.
-This tutorial will guide you through the process of creating a new document model using the Document Model Editor in the Connect app. 
+## Architecture
 
-<details>
-<summary>Available NPM commands</summary>
+```
+bai-knowledge-note/
+├── document-models/     11 document models (data schemas + reducers)
+├── editors/             10 editors + 1 drive-app (UI layer)
+├── processors/          Graph indexer (data pipeline)
+├── subgraphs/           Knowledge graph (GraphQL query API)
+├── powerhouse.manifest.json
+└── powerhouse.config.json
+```
 
--   `generate`: Updates the generated code according to the JSON spec and GraphQL schema of your document model, made in Connect.
--   `lint`: Checks for errors with ESLint and TypeScript checking.
--   `format`: Formats the code using Prettier.
--   `build`: Builds the library project using Vite.
--   `storybook`: Starts Storybook in development mode.
--   `build-storybook`: Builds Storybook.
--   `test`: Runs Jest for testing.
+## Document Models
 
-</details>
+11 document types defining the knowledge vault's data layer:
 
-### 1. Defining Your Document Model GraphQL Schema
-Start by creating your own 'Powerhouse Project' (Document model + editor).
+| Model | Type | Role |
+|-------|------|------|
+| **KnowledgeNote** | `bai/knowledge-note` | Atomic knowledge claims with title, content, typed links, topics, provenance |
+| **Moc** | `bai/moc` | Maps of Content — topic navigation hubs organizing notes into clusters |
+| **Source** | `bai/source` | Raw ingested material (articles, transcripts, documentation) |
+| **ResearchClaim** | `bai/research-claim` | Ars Contexta methodology foundation (249 claims) |
+| **KnowledgeGraph** | `bai/knowledge-graph` | Materialized graph singleton |
+| **PipelineQueue** | `bai/pipeline-queue` | Processing task tracker singleton |
+| **HealthReport** | `bai/health-report` | Point-in-time vault diagnostics |
+| **VaultConfig** | `bai/vault-config` | Vault configuration singleton |
+| **Observation** | `bai/observation` | Operational learning signals |
+| **Tension** | `bai/tension` | Unresolved contradictions between claims |
+| **Derivation** | `bai/derivation` | Configuration audit trail |
 
-Step 1: Run the following command to set up your project inside this directory:
+Each model lives in `document-models/<name>/v1/` with `gen/` (auto-generated types, action creators) and `src/` (hand-written reducers).
 
-```bash
-npm create document-model-lib
-```
+## Editors
 
-Step 2: Use the Document Model Editor in the Connect app
+React components for viewing and editing each document type. All editors use the `useSelectedXDocument()` hook pattern from `@powerhousedao/reactor-browser` which returns `[document, dispatch]`.
 
-The following command gives you access to all the powerhouse CLI tools available, install it globally if you are a poweruser. 
+### Drive App: Knowledge Vault
 
-```bash
-npm install ph-cmd
-```
-Now you are able to launch Connect in Studio Mode (Locally):
+The main entry point (`editors/knowledge-vault/`). Registered as a drive-app in the manifest — this is what users see when they open the drive in Connect. Features:
 
-```bash
-npm run connect
+- **Notes tab** — Paginated grid of NoteCards with status badges, topics, and link counts
+- **Graph tab** — Cytoscape.js visualization with fcose layout, semantic clustering around MOC hubs, position persistence across sessions, and cross-cluster edge separation
+- **Sources tab** — Ingested source material with status tracking
+- **Pipeline tab** — Processing queue with phase tracking
+- **Health tab** — Vault diagnostics dashboard
+- **Config tab** — Vault configuration
+
+### Document Editors
+
+| Editor | Document Type | Purpose |
+|--------|--------------|---------|
+| `knowledge-note-editor` | `bai/knowledge-note` | Textarea editor with markdown preview, links section, topic management |
+| `moc-editor` | `bai/moc` | Core ideas, tensions, open questions, child MOC references |
+| `source-editor` | `bai/source` | Source ingestion with content preview and extraction stats |
+| `research-claim-editor` | `bai/research-claim` | Methodology claim viewer |
+| `health-report-editor` | `bai/health-report` | Health check results |
+| `pipeline-queue-editor` | `bai/pipeline-queue` | Task queue management |
+| `observation-editor` | `bai/observation` | Operational signals |
+| `tension-editor` | `bai/tension` | Contradiction tracking |
+| `vault-config-editor` | `bai/vault-config` | Configuration management |
+| `knowledge-graph-editor` | `bai/knowledge-graph` | Graph document viewer |
+
+## Processor: Graph Indexer
+
+The data pipeline that turns document operations into a queryable relational index (`processors/graph-indexer/`).
+
+### How it works
+
+**Registration:** `processors/factory.ts` → `graph-indexer/factory.ts` — called once per drive on startup. Creates a namespaced PGlite store (`GraphIndexerProcessor_<driveId>`) and registers a filter for `bai/knowledge-note` + `powerhouse/document-drive` operations.
+
+**Processing:** `onOperations()` is called whenever matching operations occur:
+
+1. **Deduplicates** — keeps only the last operation per document in a batch
+2. **Handles deletions** — `DELETE_NODE` on the drive removes the node + all edges from the index
+3. **Filters** — skips anything that isn't `bai/knowledge-note`
+4. **Reconciles** — for each changed document, reads `context.resultingState`:
+   - Upserts into `graph_nodes` (id, title, description, noteType, status)
+   - Deletes old edges for that source document
+   - Inserts new edges from the note's `links[]` array
+
+**Schema:**
+
+```
+graph_nodes: id, document_id, title, description, note_type, status, updated_at
+graph_edges: id, source_document_id, target_document_id, link_type, target_title, updated_at
 ```
 
-Open the 'Document Model' creator at the bottom of connect to define your document mode with it's GraphQL Schema Definition.
-This schema will define the structure and fields for your document model using GraphQL. 
-Follow one of our tutorials on Academy to get familiar with the process. 
+Indexes on `source_document_id`, `target_document_id`, and `status` for query performance.
 
-### 2. Defining Document Model Operations
-Using the Document Model Operations Editor, define the operations for your document model and their GraphQL counterparts. 
-These operations will handle state changes within your document model.
+**On disconnect:** No-op — preserves indexed data across restarts. The reactor does not replay historical operations, so wiping tables would leave the index permanently empty.
 
-**Best Practices:**
+## Subgraph: Knowledge Graph
 
-- Clearly define CRUD operations (Create, Read, Update, Delete).
-- Use GraphQL input types to specify the parameters for each operation.
-- Ensure that operations align with user intent to maintain a clean and understandable API.
+GraphQL query layer exposing the indexed data (`subgraphs/knowledge-graph/`). Registered at `/graphql/knowledgeGraph`.
 
-### 3. Generating Scaffolding Code
-Export your document model as a .zip file from Connect.
-Import the .zip file into your project directory created in Step 1.
-Run the following command to generate the scaffolding code:
+### Queries
 
-```bash
-npm run generate YourModelName.phdm.zip
+| Query | Description |
+|-------|-------------|
+| `knowledgeGraphNodes(driveId)` | All indexed nodes |
+| `knowledgeGraphEdges(driveId)` | All indexed edges |
+| `knowledgeGraphStats(driveId)` | Node count, edge count, orphan count |
+| `knowledgeGraphSearch(driveId, query, limit?)` | Text search on title + description |
+| `knowledgeGraphOrphans(driveId)` | Nodes with no incoming edges |
+| `knowledgeGraphConnections(driveId, documentId, depth?)` | BFS traversal from a node |
+| `knowledgeGraphBacklinks(driveId, documentId)` | Edges pointing TO a document |
+| `knowledgeGraphForwardLinks(driveId, documentId)` | Edges pointing FROM a document |
+| `knowledgeGraphTriangles(driveId, limit?)` | Pairs that share a target but aren't linked |
+| `knowledgeGraphBridges(driveId)` | Articulation points that connect clusters |
+| `knowledgeGraphDensity(driveId)` | Graph density metric |
+| `knowledgeGraphDebug(driveId)` | Raw DB rows for debugging |
+
+### Mutations
+
+| Mutation | Description |
+|----------|-------------|
+| `knowledgeGraphReindex(driveId)` | Backfill the index by reading all notes — use when the processor missed historical operations |
+
+## Deep Dive: Processor + Subgraph Architecture
+
+### The Problem They Solve
+
+Powerhouse documents are stored as **operation logs** (event sourcing). To read a note's title, you replay all its operations to reconstruct the current state. This works for individual documents, but becomes expensive when you need to:
+
+- Search across 500+ notes by keyword
+- Find all notes linking to a specific note
+- Calculate graph metrics (density, orphans, bridges)
+- Render a graph visualization of all notes and edges
+
+Without an index, every query would require loading and replaying every document in the drive. The processor + subgraph pattern solves this by maintaining a **materialized read model** — a relational projection of document state that's always up to date.
+
+### How the Processor Works (Write Path)
+
+The `GraphIndexerProcessor` sits between the Reactor and a PGlite relational database. It implements the `RelationalDbProcessor` base class from `@powerhousedao/shared/processors`.
+
+```
+┌─────────────────────────────────────────────────────┐
+│                      Reactor                        │
+│                                                     │
+│  Document A  ──op──▶ ┌───────────────────────────┐  │
+│  Document B  ──op──▶ │   GraphIndexerProcessor   │  │
+│  Document C  ──op──▶ │                           │  │
+│  Drive (delete)──op─▶│  filter:                  │  │
+│                      │   bai/knowledge-note      │  │
+│                      │   powerhouse/document-drive│  │
+│                      │                           │  │
+│                      │  onOperations(ops[]):      │  │
+│                      │   1. deduplicate           │  │
+│                      │   2. handle deletions      │  │
+│                      │   3. upsert graph_nodes    │  │
+│                      │   4. reconcile graph_edges │  │
+│                      └──────────┬────────────────┘  │
+│                                 │                    │
+│                      ┌──────────▼────────────────┐  │
+│                      │    PGlite (namespaced)    │  │
+│                      │                           │  │
+│                      │  graph_nodes              │  │
+│                      │    id, document_id, title  │  │
+│                      │    description, note_type  │  │
+│                      │    status, updated_at      │  │
+│                      │                           │  │
+│                      │  graph_edges              │  │
+│                      │    id, source_document_id  │  │
+│                      │    target_document_id      │  │
+│                      │    link_type, target_title │  │
+│                      └───────────────────────────┘  │
+└─────────────────────────────────────────────────────┘
 ```
 
-This will create a new directory under /document-models containing:
+**Key design decisions:**
 
-JSON file with the document model specification.
-GraphQL file with state and operation schemas.
-A gen/ folder with autogenerated code.
-A src/ folder for your custom code implementation.
+1. **Filter-based subscription** — The processor declares interest in specific document types and scopes. The Reactor only sends matching operations, avoiding unnecessary work:
+   ```typescript
+   const filter: ProcessorFilter = {
+     branch: ["main"],
+     documentId: ["*"],
+     documentType: ["bai/knowledge-note", "powerhouse/document-drive"],
+     scope: ["global"],
+   };
+   ```
 
-### 4. Implementing Reducer Code and Unit Tests
-Navigate to the reducer directory:
+2. **State reconciliation, not event replay** — The processor doesn't interpret individual operations (SET_TITLE, ADD_LINK, etc.). Instead, it reads `context.resultingState` — the full document state after the operation — and upserts the entire node + edges. This means it doesn't need to know the document model's operation semantics.
+
+3. **Namespace isolation** — Each drive gets its own PGlite namespace (`GraphIndexerProcessor_<driveId>`), so multiple drives don't interfere with each other. The namespace is derived deterministically from the drive ID.
+
+4. **Idempotent migrations** — Tables and indexes are created with `ifNotExists`, so the processor can restart safely without schema conflicts.
+
+5. **No-op on disconnect** — The processor preserves its data across server restarts. Since the Reactor doesn't replay historical operations to processors, wiping on disconnect would leave the index empty until new edits arrive.
+
+### How the Subgraph Works (Read Path)
+
+The `KnowledgeGraphSubgraph` extends `BaseSubgraph` from `@powerhousedao/reactor-api` and exposes the indexed data via GraphQL at `/graphql/knowledgeGraph`.
 
-```bash
-cd document-models/"YourModelName"/src/reducers
+```
+┌──────────────────────────────────────────────────┐
+│              GraphQL Clients                     │
+│                                                  │
+│  Connect UI ─────────┐                           │
+│  AI Agent (MCP) ─────┤                           │
+│  Switchboard CLI ────┤  query / mutation         │
+│  Third-party app ────┤                           │
+│  curl / Postman ─────┘                           │
+│                      │                           │
+│           ┌──────────▼───────────────────┐       │
+│           │   /graphql/knowledgeGraph    │       │
+│           │                              │       │
+│           │   KnowledgeGraphSubgraph     │       │
+│           │     ├─ getDb(driveId)        │       │
+│           │     │    → namespaced Kysely │       │
+│           │     ├─ getQuery(driveId)     │       │
+│           │     │    → typed query API   │       │
+│           │     ├─ reindexDrive()        │       │
+│           │     │    → backfill from     │       │
+│           │     │      reactorClient     │       │
+│           │     └─ ensureGraphDoc()      │       │
+│           │          → auto-create       │       │
+│           │            bai/knowledge-    │       │
+│           │            graph doc         │       │
+│           └──────────┬───────────────────┘       │
+│                      │                           │
+│           ┌──────────▼───────────────────┐       │
+│           │  PGlite (same namespace as   │       │
+│           │  the processor writes to)    │       │
+│           └──────────────────────────────┘       │
+└──────────────────────────────────────────────────┘
 ```
 
-Implement the reducer functions for each document model operation. These functions will handle state transitions.
+**The subgraph reads from the same PGlite tables the processor writes to.** This is the key architectural link — the processor is the write path, the subgraph is the read path, and they share a namespace.
 
-Add utility functions in:
+The subgraph provides two levels of query abstraction:
 
-```bash
-document-models/"YourModelName"/src/utils.ts
+1. **`getDb(driveId)`** — Returns a typed `Kysely<DB>` instance scoped to the processor's namespace. This centralizes the `IRelationalDbLegacy → IRelationalDb → Kysely` cast in one place.
+
+2. **`getQuery(driveId)`** — Wraps `getDb` with the `createGraphQuery()` helper that provides high-level methods (`allNodes()`, `searchNodes()`, `connections()`, `triangles()`, `bridges()`, etc.). All queries use Kysely's type-safe query builder.
+
+### How Third-Party Plugins Can Use This
+
+Any application that can make GraphQL requests to the Reactor's endpoint can query the knowledge graph. The subgraph is accessible at `/graphql/knowledgeGraph` (local: `http://localhost:4001/graphql/knowledgeGraph`, remote: `https://your-switchboard.example.com/graphql/knowledgeGraph`).
+
+**Example: Search notes from any client**
+
+```graphql
+query SearchNotes($driveId: ID!, $query: String!) {
+  knowledgeGraphSearch(driveId: $driveId, query: $query, limit: 20) {
+    documentId
+    title
+    description
+    noteType
+    status
+  }
+}
 ```
 
-Write unit tests to ensure the correctness of your reducers:
+**Example: Get graph structure for visualization**
+
+```graphql
+query GraphData($driveId: ID!) {
+  knowledgeGraphNodes(driveId: $driveId) {
+    documentId
+    title
+    noteType
+    status
+  }
+  knowledgeGraphEdges(driveId: $driveId) {
+    sourceDocumentId
+    targetDocumentId
+    linkType
+    targetTitle
+  }
+  knowledgeGraphStats(driveId: $driveId) {
+    nodeCount
+    edgeCount
+    orphanCount
+  }
+}
+```
 
-Test files should be located in:
+**Example: Find synthesis opportunities (triangles)**
 
-```bash
-document-models/"YourModelName"/src/reducers/tests
+```graphql
+query FindTriangles($driveId: ID!) {
+  knowledgeGraphTriangles(driveId: $driveId, limit: 10) {
+    noteA { documentId title }
+    noteB { documentId title }
+    sharedTarget { documentId title }
+  }
+}
 ```
 
-Run the tests:
+**Example: Backfill the index after deployment**
 
-```bash
-npm test
+```graphql
+mutation Reindex($driveId: ID!) {
+  knowledgeGraphReindex(driveId: $driveId) {
+    indexedNodes
+    indexedEdges
+    errors
+  }
+}
 ```
 
-Test the editor functionality:
+**Using the Switchboard CLI:**
 
 ```bash
-npm run connect
+# Search
+switchboard query '{ knowledgeGraphSearch(driveId: "<UUID>", query: "reactor") { documentId title } }'
+
+# Stats
+switchboard query '{ knowledgeGraphStats(driveId: "<UUID>") { nodeCount edgeCount orphanCount } }'
+
+# Reindex
+switchboard query 'mutation { knowledgeGraphReindex(driveId: "<UUID>") { indexedNodes indexedEdges errors } }'
 ```
 
-### 5. Implementing Document Editors
-Generate the editor template for your document model:
+**Using MCP (for AI agents):**
+
+AI agents connected via MCP can't call the subgraph directly, but they can use `mcp__reactor-mcp__getDocument` to read individual documents. The Switchboard CLI provides the fastest path for agents to query the graph index — the `powerhouse-knowledge` plugin uses this pattern.
+
+### Why This Pattern Matters
+
+The processor + subgraph pattern is the recommended way to build **read-optimized projections** in Powerhouse:
+
+| Concern | Without processor | With processor |
+|---------|------------------|----------------|
+| Search 500 notes by keyword | Load all 500 documents, replay ops, scan content | Single SQL `LIKE` query on `graph_nodes.title` |
+| Find orphan notes | Load all docs, build adjacency list in memory | `SELECT * FROM graph_nodes WHERE document_id NOT IN (SELECT target_document_id FROM graph_edges)` |
+| Graph density | Load everything, count manually | Two `COUNT(*)` queries |
+| Incremental updates | Reload everything on each change | Upsert one row per changed document |
+
+The same pattern can be applied to any domain — an invoice tracker could project invoice totals into a summary table, a project manager could index task statuses, etc. The processor handles the write path (operation → relational row), and the subgraph handles the read path (GraphQL → SQL → response).
+
+## Data Flow
 
-```bash
-npm run generate -- --editor YourModelName --document-types powerhouse/YourModelName
 ```
+User edits a note in the editor
+  → dispatch(setTitle({...}))
+    → operation recorded on the document
+      → Reactor sends operation to GraphIndexerProcessor
+        → Processor upserts graph_nodes + graph_edges in PGlite
+          → Subgraph queries return updated data
+            → GraphView in the drive-app renders the graph
+```
+
+## Drive Structure
 
-The --editor flag specifies the name of your document model.
-The --document-types flag links the editor to your document model type.
-After generation:
+Documents are organized into folders within the drive:
 
-Open the editor template:
+| Folder | Document Types | Purpose |
+|--------|---------------|---------|
+| `/knowledge/notes/` | `bai/knowledge-note` | Atomic knowledge claims |
+| `/knowledge/` | `bai/moc` | Maps of Content |
+| `/sources/` | `bai/source` | Raw input material |
+| `/research/` | `bai/research-claim` | Methodology foundation |
+| `/ops/queue/` | `bai/pipeline-queue` | Pipeline singleton |
+| `/ops/health/` | `bai/health-report` | Health report singleton |
+| `/ops/sessions/` | `bai/observation` | Operational signals |
+| `/self/` | `bai/knowledge-graph`, `bai/vault-config` | Singletons |
+
+## Development
 
 ```bash
-editors/YourModelName/editor.tsx
+# Install dependencies
+bun install
+
+# Start Vetra Studio with live code generation
+ph vetra --watch
+
+# Type check
+bun tsc --noEmit
+
+# Lint
+bun eslint <file>
+
+# Format
+bun prettier --write <file>
+
+# Run tests
+bun test
 ```
 
-Customize the editor interface to suit your document model.
+### Subgraph Endpoint Configuration
+
+The Search tab and other editor features that query the Knowledge Graph subgraph need to reach the reactor's GraphQL endpoint. The endpoint is resolved automatically in most cases:
 
-### 6. Testing the Document Editor
-Run the Connect app to test your document editor:
+| Environment | How it works |
+|-------------|-------------|
+| **`ph vetra --watch`** (local dev) | Auto-detected: Vite runs on port 3000/3001, subgraph at `http://localhost:4001/graphql/knowledgeGraph` |
+| **Connect production** (same origin) | Auto-detected: relative path `/graphql/knowledgeGraph` |
+| **Deployed** (Connect and Switchboard on different domains) | Set `VITE_SUBGRAPH_URL` env var |
+
+For deployed environments where Connect runs on a different domain than the Switchboard (e.g., `connect.example.com` vs `switchboard-dev.powerhouse.xyz`), create a `.env` file:
 
 ```bash
-npm run connect
-```
-
-Verify that the editor functions as expected.
-Perform end-to-end testing to ensure smooth integration between the document model and its editor.
-
-### 7. Adding a Manifest File
-Create a manifest file to describe your document model and editor. This enables proper integration with the host application.
-
-**Example manifest.json:**
-
-```json
-{
-  "name": "your-model-name",
-  "description": "A brief description of your document model.",
-  "category": "your-category", // e.g., "Finance", "People Ops", "Legal"
-  "publisher": {
-    "name": "your-publisher-name",
-    "url": "your-publisher-url"
-  },
-  "documentModels": [
-    {
-      "id": "your-model-id",
-      "name": "your-model-name"
-    }
-  ],
-  "editors": [
-    {
-      "id": "your-editor-id",
-      "name": "your-editor-name",
-      "documentTypes": ["your-model-id"]
-    }
-  ]
-}
+# .env
+VITE_SUBGRAPH_URL=https://switchboard-dev.powerhouse.xyz/graphql/knowledgeGraph
 ```
 
-### Steps to finalize:
+This is only needed when the app and reactor are on different origins. Local development and same-origin deployments work without any configuration.
+
+## Graph View
+
+The knowledge graph visualization uses `cytoscape-fcose` (force-directed layout) with semantic clustering:
 
-Place the manifest file at your project root.
-Update your index.js to export your modules and include the new document model and editor.
+- **MOC hubs** act as cluster anchors with higher repulsion, pulling their CORE_IDEA-linked notes into visible topic neighborhoods
+- **Cross-cluster edges** have weak elasticity and long ideal lengths, preventing topic groups from collapsing together
+- **Position persistence** via localStorage — positions survive tab switches and page reloads. New nodes are placed by fcose while existing nodes stay pinned
+- **MOC group drag** — dragging a MOC diamond moves its entire cluster of connected notes
+- **Re-layout button** clears cached positions and recomputes a fresh layout
 
-### Final Thoughts
-You've now successfully created a Document Model and its corresponding Editor using the Connect app!
+## License
 
-Next Steps:
-- Expand functionality: Add more operations or complex logic to your document model.
-- Improve UX: Enhance the document editor for a smoother user experience.
-- Integrate with other systems: Use APIs or GraphQL to connect your document model with external services.
+AGPL-3.0-only

package/dist/editors/knowledge-vault/components/DriveExplorer.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"DriveExplorer.d.ts","sourceRoot":"","sources":["../../../../editors/knowledge-vault/components/DriveExplorer.tsx"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,gBAAgB,CAAC;AA+BlD,wBAAgB,aAAa,CAAC,EAAE,QAAQ,EAAE,EAAE,WAAW,2CA+UtD"}
+{"version":3,"file":"DriveExplorer.d.ts","sourceRoot":"","sources":["../../../../editors/knowledge-vault/components/DriveExplorer.tsx"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,gBAAgB,CAAC;AAiClD,wBAAgB,aAAa,CAAC,EAAE,QAAQ,EAAE,EAAE,WAAW,2CAiWtD"}

package/dist/editors/knowledge-vault/components/DriveExplorer.js

@@ -7,6 +7,7 @@ import { GraphView } from "./GraphView.js";
 import { NoteList } from "./NoteList.js";
 import { SourceList } from "./SourceList.js";
 import { HealthDashboard } from "./HealthDashboard.js";
+import { SearchView } from "./SearchView.js";
 import { GettingStartedButton } from "./GettingStarted.js";
 import { useKnowledgeNotes } from "../hooks/use-knowledge-notes.js";
 import { useKnowledgeGraph, buildSyncPayload, } from "../hooks/use-knowledge-graph.js";
@@ -15,7 +16,7 @@ import { useKnowledgeGraphDocumentById } from "@powerhousedao/knowledge-note/doc
 import { actions as graphActions } from "@powerhousedao/knowledge-note/document-models/knowledge-graph";
 import { ThemeToggle } from "../../shared/theme-context.js";
 export function DriveExplorer({ children }) {
-    const [viewMode, setViewMode] = useState("notes");
+    const [viewMode, setViewMode] = useState("search");
     const { notes } = useKnowledgeNotes();
     const { graphDoc, graphState, hasGraphDoc } = useKnowledgeGraph(notes);
     const fileNodes = useFileNodesInSelectedDrive();
@@ -106,6 +107,11 @@ export function DriveExplorer({ children }) {
         setViewMode(mode);
     }
     const TABS = [
+        {
+            key: "search",
+            label: "Search",
+            icon: (_jsxs("svg", { className: "h-4 w-4", viewBox: "0 0 24 24", fill: "none", stroke: "currentColor", strokeWidth: "2", children: [_jsx("circle", { cx: "11", cy: "11", r: "8" }), _jsx("path", { d: "m21 21-4.35-4.35" })] })),
+        },
         {
             key: "notes",
             label: "Notes",
@@ -155,7 +161,7 @@ export function DriveExplorer({ children }) {
                                                 }, children: tab.badge }))] }, tab.key))), showDocumentEditor && (_jsxs("span", { className: "flex items-center gap-1.5 rounded-md px-3 py-1.5 text-xs font-medium", style: {
                                             backgroundColor: "var(--bai-hover)",
                                             color: "var(--bai-accent)",
-                                        }, children: [_jsxs("svg", { className: "h-4 w-4", viewBox: "0 0 24 24", fill: "none", stroke: "currentColor", strokeWidth: "2", children: [_jsx("path", { d: "M11 4H4a2 2 0 00-2 2v14a2 2 0 002 2h14a2 2 0 002-2v-7" }), _jsx("path", { d: "M18.5 2.5a2.121 2.121 0 013 3L12 15l-4 1 1-4 9.5-9.5z" })] }), "Editing"] }))] }), _jsxs("div", { className: "flex items-center gap-3", children: [hasGraphDoc && graphState && (_jsxs("span", { className: "text-[10px]", style: { color: "var(--bai-text-faint)" }, children: [graphState.nodes.length, "n / ", graphState.edges.length, "e"] })), _jsx(ThemeToggle, {}), _jsx(GettingStartedButton, {}), _jsx(CreateMenu, {})] })] }), _jsx("div", { className: "flex-1 overflow-auto", children: showDocumentEditor ? (_jsx("div", { className: "h-full", children: children })) : viewMode === "graph" ? (_jsx(GraphView, { notes: notes, graphState: graphState, mocs: mocs, tensions: tensions })) : viewMode === "sources" ? (_jsx(SourceList, {})) : viewMode === "health" ? (_jsx(HealthDashboard, {})) : (_jsx(NoteList, { notes: notes })) })] })] }));
+                                        }, children: [_jsxs("svg", { className: "h-4 w-4", viewBox: "0 0 24 24", fill: "none", stroke: "currentColor", strokeWidth: "2", children: [_jsx("path", { d: "M11 4H4a2 2 0 00-2 2v14a2 2 0 002 2h14a2 2 0 002-2v-7" }), _jsx("path", { d: "M18.5 2.5a2.121 2.121 0 013 3L12 15l-4 1 1-4 9.5-9.5z" })] }), "Editing"] }))] }), _jsxs("div", { className: "flex items-center gap-3", children: [hasGraphDoc && graphState && (_jsxs("span", { className: "text-[10px]", style: { color: "var(--bai-text-faint)" }, children: [graphState.nodes.length, "n / ", graphState.edges.length, "e"] })), _jsx(ThemeToggle, {}), _jsx(GettingStartedButton, {}), _jsx(CreateMenu, {})] })] }), _jsx("div", { className: "flex-1 overflow-auto", children: showDocumentEditor ? (_jsx("div", { className: "h-full", children: children })) : viewMode === "graph" ? (_jsx(GraphView, { notes: notes, graphState: graphState, mocs: mocs, tensions: tensions })) : viewMode === "search" ? (_jsx(SearchView, {})) : viewMode === "sources" ? (_jsx(SourceList, {})) : viewMode === "health" ? (_jsx(HealthDashboard, {})) : (_jsx(NoteList, { notes: notes })) })] })] }));
 }
 const CREATE_ITEMS = [
     {

package/dist/editors/knowledge-vault/components/SearchView.d.ts

@@ -0,0 +1,2 @@
+export declare function SearchView(): import("react/jsx-runtime").JSX.Element;
+//# sourceMappingURL=SearchView.d.ts.map

package/dist/editors/knowledge-vault/components/SearchView.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"SearchView.d.ts","sourceRoot":"","sources":["../../../../editors/knowledge-vault/components/SearchView.tsx"],"names":[],"mappings":"AA+CA,wBAAgB,UAAU,4CAmGzB"}