@knowledgine/cli 0.2.0 → 0.3.0

package/fixtures/demo/notes/api-design-decisions.md

@@ -6,20 +6,23 @@ tags:
 author: demo-user
 project: backend-api
 ---
+
 # REST API Design Decisions
 
 ## Issue: Pagination Strategy
+
 Needed to decide between offset-based and cursor-based pagination
 for the search results endpoint.
 
 ### Decision: Cursor-based pagination
+
 Offset pagination breaks when items are inserted/deleted during browsing.
 
 ```typescript
 // Cursor-based pagination
 interface PaginatedResponse<T> {
   data: T[];
-  cursor: string | null;  // null means no more pages
+  cursor: string | null; // null means no more pages
   hasMore: boolean;
 }
 
@@ -31,7 +34,7 @@ app.get("/api/notes", (req, res) => {
     `SELECT * FROM notes
      WHERE ($1::text IS NULL OR id < $1)
      ORDER BY id DESC LIMIT $2`,
-    [decoded?.id, limit + 1]
+    [decoded?.id, limit + 1],
   );
 
   const hasMore = notes.length > limit;
@@ -46,6 +49,7 @@ app.get("/api/notes", (req, res) => {
 ```
 
 ## Issue: Error Response Format
+
 Standardized error responses across all endpoints.
 
 ### Solution: RFC 7807 Problem Details
@@ -73,6 +77,7 @@ app.use((err, req, res, _next) => {
 ```
 
 ## Learnings
+
 - Cursor-based pagination is more reliable for real-time data
 - Consistent error formats reduce client-side error handling complexity
 - Always version your API from the start (`/v1/`)

package/fixtures/demo/notes/auth-debugging.md

@@ -6,14 +6,17 @@ tags:
 author: demo-user
 project: backend-api
 ---
+
 # Authentication Debugging Session
 
 ## Problem
+
 JWT token validation was failing intermittently in production.
 Users reported being logged out randomly after 10-15 minutes,
 even though the token expiry was set to 1 hour.
 
 ### Error Log
+
 ```
 Error: TokenExpiredError: jwt expired
   at /app/middleware/auth.ts:42:11
@@ -21,11 +24,13 @@ Error: TokenExpiredError: jwt expired
 ```
 
 ## Investigation
+
 - Checked server clock sync — NTP was configured correctly
 - Compared token `iat` (issued at) timestamps with server time
 - Found a 45-minute clock skew between API server and auth service
 
 ## Solution
+
 The auth service was running in a container with a drifted system clock.
 
 ```typescript
@@ -36,17 +41,20 @@ const decoded = jwt.verify(token, SECRET, {
 ```
 
 Also fixed the root cause by enabling NTP sync in the Docker container:
+
 ```dockerfile
 RUN apt-get update && apt-get install -y ntpdate
 CMD ntpdate -s pool.ntp.org && node server.js
 ```
 
 ## Learnings
+
 - Always configure clock tolerance for distributed JWT validation
 - Container clocks can drift if the host NTP is not propagated
 - Add monitoring for clock skew between services
 - The `clockTolerance` option is safer than extending token expiry
 
 ## Time Spent
+
 Investigation: 2 hours
 Fix + deployment: 30 minutes

package/fixtures/demo/notes/ci-cd-pipeline.md

@@ -6,14 +6,18 @@ tags:
 author: demo-user
 project: infrastructure
 ---
+
 # CI/CD Pipeline Setup and Debugging
 
 ## Problem
+
 The CI pipeline was taking 25 minutes per push, blocking the
 development workflow. Flaky tests caused unnecessary re-runs.
 
 ## Investigation
+
 Analyzed GitHub Actions run logs:
+
 - Dependency install: 4 minutes (no caching)
 - Build: 3 minutes
 - Tests: 15 minutes (sequential, with 3 flaky tests)
@@ -59,6 +63,7 @@ jobs:
 ```
 
 ### Flaky Test Fix
+
 ```typescript
 // Before: timing-dependent test
 it("should debounce input", async () => {
@@ -78,11 +83,13 @@ it("should debounce input", () => {
 ```
 
 ## Results
+
 - Pipeline time: 25 min → 8 min (68% reduction)
 - Flaky test rate: 15% → 0%
 - Developer satisfaction significantly improved
 
 ## Learnings
+
 - Cache dependencies aggressively in CI
 - Run lint and tests in parallel jobs
 - Flaky tests erode trust — fix them immediately

package/fixtures/demo/notes/code-review-notes.md

@@ -6,15 +6,18 @@ tags:
 author: demo-user
 project: team-process
 ---
+
 # Code Review Guidelines and Common Issues
 
 ## Problem
+
 Code reviews were inconsistent. Some PRs got rubber-stamped while
 others received 50+ nitpick comments. Reviews took 2-3 days on average.
 
 ## Solution: Review Checklist
 
 ### What to Check
+
 1. **Correctness**: Does the code do what the PR description says?
 2. **Edge cases**: Null handling, empty arrays, boundary conditions
 3. **Security**: Input validation, SQL injection, XSS
@@ -24,6 +27,7 @@ others received 50+ nitpick comments. Reviews took 2-3 days on average.
 ### Common Issues Found in Reviews
 
 #### Error handling gaps
+
 ```typescript
 // Bad: swallows errors silently
 try {
@@ -42,6 +46,7 @@ try {
 ```
 
 #### Missing input validation
+
 ```typescript
 // Bad: trusts external input
 app.post("/api/users", (req, res) => {
@@ -59,12 +64,14 @@ app.post("/api/users", (req, res) => {
 ```
 
 ## Process Improvements
+
 - Max review turnaround: 4 hours for small PRs, 1 day for large
 - Use "Request changes" only for blocking issues
 - Prefix comments: `nit:`, `question:`, `suggestion:`, `blocking:`
 - Author should self-review before requesting review
 
 ## Learnings
+
 - Checklists reduce review inconsistency
 - Small PRs (< 300 lines) get better reviews and faster merges
 - Automate what you can (linting, formatting, type checking)

package/fixtures/demo/notes/database-optimization.md

@@ -6,13 +6,16 @@ tags:
 author: demo-user
 project: backend-api
 ---
+
 # SQL Query Optimization and Indexing
 
 ## Problem
+
 The notes search endpoint was timing out with 100k+ rows.
 Average query time was 4.2 seconds, causing user-visible latency.
 
 ### Slow Query
+
 ```sql
 SELECT n.*, COUNT(p.id) as pattern_count
 FROM notes n
@@ -25,7 +28,9 @@ LIMIT 20;
 ```
 
 ## Investigation
+
 Used `EXPLAIN ANALYZE` to identify bottlenecks:
+
 ```sql
 EXPLAIN ANALYZE SELECT ...;
 -- Seq Scan on notes  (cost=0.00..12847.00 rows=100234 width=412)
@@ -50,6 +55,7 @@ CREATE INDEX idx_patterns_note_id ON patterns (note_id);
 ```
 
 ### Rewritten Query
+
 ```sql
 SELECT n.*, COUNT(p.id) as pattern_count
 FROM notes n
@@ -62,10 +68,12 @@ LIMIT 20;
 ```
 
 ## Results
+
 - Query time: 4.2s → 18ms (233x improvement)
 - Index storage overhead: ~45MB (acceptable for 100k rows)
 
 ## Learnings
+
 - `LIKE '%term%'` cannot use indexes — always use full-text search
 - `EXPLAIN ANALYZE` is the first tool to reach for
 - Covering indexes avoid table lookups for frequently joined columns

package/fixtures/demo/notes/docker-troubleshooting.md

@@ -6,9 +6,11 @@ tags:
 author: demo-user
 project: microservices
 ---
+
 # Docker Container Networking Issues
 
 ## Problem
+
 Containers in docker-compose could not communicate with each other.
 The API service failed to connect to the database container.
 
@@ -17,11 +19,13 @@ Error: connect ECONNREFUSED 127.0.0.1:5432
 ```
 
 ## Investigation
+
 - Verified both containers were running: `docker ps` showed healthy status
 - Checked network: `docker network ls` showed custom bridge network
 - The API was using `localhost` instead of the service name
 
 ## Solution
+
 Docker containers have their own network namespace. Use the service
 name as the hostname, not `localhost`.
 
@@ -32,7 +36,7 @@ services:
     build: ./api
     environment:
       # Wrong: DB_HOST=localhost
-      DB_HOST: postgres  # Use service name
+      DB_HOST: postgres # Use service name
       DB_PORT: 5432
     depends_on:
       postgres:
@@ -48,6 +52,7 @@ services:
 ```
 
 ## Additional Fix: DNS Resolution Timing
+
 Even with correct hostnames, the API started before DNS was ready.
 
 ```typescript
@@ -68,6 +73,7 @@ async function connectWithRetry(maxRetries = 5): Promise<Pool> {
 ```
 
 ## Learnings
+
 - Never use `localhost` for inter-container communication
 - Use `depends_on` with health checks, not just service ordering
 - Add connection retry logic for resilience

package/fixtures/demo/notes/react-performance.md

@@ -6,13 +6,16 @@ tags:
 author: demo-user
 project: dashboard-app
 ---
+
 # React Performance Optimization
 
 ## Issue
+
 The dashboard page was taking 3+ seconds to render with 500 items.
 React DevTools Profiler showed excessive re-renders on every state change.
 
 ## Root Cause Analysis
+
 1. Parent component state changes triggered full list re-render
 2. Inline arrow functions in JSX created new references each render
 3. Large bundle size from importing entire icon library
@@ -21,14 +24,10 @@ React DevTools Profiler showed excessive re-renders on every state change.
 
 ```tsx
 // Before: re-renders on every parent state change
-const ListItem = ({ item, onClick }) => (
-  <div onClick={() => onClick(item.id)}>{item.name}</div>
-);
+const ListItem = ({ item, onClick }) => <div onClick={() => onClick(item.id)}>{item.name}</div>;
 
 // After: memoized with stable callback
-const ListItem = React.memo(({ item, onClick }) => (
-  <div onClick={onClick}>{item.name}</div>
-));
+const ListItem = React.memo(({ item, onClick }) => <div onClick={onClick}>{item.name}</div>);
 
 // Parent: stable callback reference
 const handleClick = useCallback((id: string) => {
@@ -55,11 +54,13 @@ function Dashboard() {
 ```
 
 ## Results
+
 - Initial render: 3.2s → 0.8s (75% improvement)
 - Re-render on selection: 450ms → 12ms
 - Bundle size: 1.2MB → 680KB
 
 ## Learnings
+
 - Profile before optimizing — measure actual bottlenecks
 - React.memo only helps when props are actually stable
 - Lazy loading is most effective for below-the-fold content

package/fixtures/demo/notes/typescript-migration.md

@@ -6,17 +6,21 @@ tags:
 author: demo-user
 project: legacy-app
 ---
+
 # JavaScript to TypeScript Migration
 
 ## Problem
+
 The legacy Express app (50+ files) had no type safety. Runtime errors
 were discovered only in production, and onboarding new developers
 took weeks due to lack of type documentation.
 
 ## Migration Strategy
+
 Adopted an incremental approach instead of a big-bang rewrite.
 
 ### Phase 1: Setup (Day 1)
+
 ```jsonc
 // tsconfig.json - permissive start
 {
@@ -25,13 +29,14 @@ Adopted an incremental approach instead of a big-bang rewrite.
     "checkJs": false,
     "strict": false,
     "outDir": "dist",
-    "rootDir": "src"
+    "rootDir": "src",
   },
-  "include": ["src/**/*"]
+  "include": ["src/**/*"],
 }
 ```
 
 ### Phase 2: Rename files (Week 1)
+
 ```bash
 # Renamed .js → .ts one directory at a time
 # Started with utility files that had no dependencies
@@ -39,6 +44,7 @@ find src/utils -name "*.js" -exec bash -c 'mv "$0" "${0%.js}.ts"' {} \;
 ```
 
 ### Phase 3: Add types gradually (Week 2-4)
+
 ```typescript
 // Before: implicit any everywhere
 function processUser(user) {
@@ -58,21 +64,24 @@ function processUser(user: User): { name: string; role: string } {
 ```
 
 ### Phase 4: Enable strict mode (Week 5)
+
 ```jsonc
 {
   "compilerOptions": {
     "strict": true,
-    "noUncheckedIndexedAccess": true
-  }
+    "noUncheckedIndexedAccess": true,
+  },
 }
 ```
 
 ## Results
+
 - Runtime type errors: 12/month → 0/month
 - Onboarding time: 3 weeks → 1 week
 - Refactoring confidence: significantly improved with IDE support
 
 ## Learnings
+
 - Incremental migration is key — never stop shipping features
 - Start with leaf files (utilities), move inward to core logic
 - `@ts-expect-error` is better than `any` for tracking tech debt

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@knowledgine/cli",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "type": "module",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",
@@ -14,11 +14,20 @@
     }
   },
   "dependencies": {
+    "@clack/prompts": "^1.1.0",
+    "@hono/node-server": "^1.19.11",
+    "boxen": "^8.0.1",
+    "chalk": "^5.6.2",
     "chokidar": "^5.0.0",
+    "cli-table3": "^0.6.5",
     "commander": "^14.0.3",
-    "@knowledgine/core": "0.2.0",
-    "@knowledgine/mcp-server": "0.2.0",
-    "@knowledgine/ingest": "0.2.0"
+    "hono": "^4.12.9",
+    "log-symbols": "^7.0.1",
+    "ora": "^9.3.0",
+    "smol-toml": "^1.6.0",
+    "@knowledgine/core": "0.3.0",
+    "@knowledgine/ingest": "0.3.0",
+    "@knowledgine/mcp-server": "0.3.0"
   },
   "files": [
     "dist",