@cdmbase/wiki-browser 12.0.18-alpha.41 → 12.0.18-alpha.42

package/lib/templates/content/content-manifest.json

@@ -1,5 +1,17 @@
 {
   "files": [
+    {
+      "contentId": "botinstruction-tunnel-setup",
+      "slug": "tunnel-setup",
+      "filePath": "/content/docs/BotInstruction/TUNNEL-SETUP.md",
+      "relativePath": "BotInstruction/TUNNEL-SETUP.md",
+      "categoryId": "BotInstruction",
+      "title": "TUNNEL SETUP",
+      "description": "",
+      "author": "Documentation",
+      "updatedAt": "Recently",
+      "frontmatter": {}
+    },
     {
       "contentId": "botinstruction-zep_neo4j_knowledge_graph_guide",
       "slug": "zep_neo4j_knowledge_graph_guide",
@@ -33,6 +45,18 @@
         "Cache-Control": "no-cache"
       }
     },
+    {
+      "contentId": "llm-contextmemorydeveloperguide",
+      "slug": "contextmemorydeveloperguide",
+      "filePath": "/content/docs/LLM/ContextMemoryDeveloperGuide.md",
+      "relativePath": "LLM/ContextMemoryDeveloperGuide.md",
+      "categoryId": "LLM",
+      "title": "ContextMemoryDeveloperGuide",
+      "description": "",
+      "author": "Documentation",
+      "updatedAt": "Recently",
+      "frontmatter": {}
+    },
     {
       "contentId": "llm-logger.llm",
       "slug": "logger.llm",
@@ -3575,6 +3599,15 @@
       "description": "BotInstruction Documentation",
       "iconType": "Documentation",
       "articles": [
+        {
+          "id": "botinstruction-tunnel-setup",
+          "title": "TUNNEL SETUP",
+          "description": "",
+          "slug": "tunnel-setup",
+          "author": "Documentation",
+          "updatedAt": "Recently",
+          "categoryId": "BotInstruction"
+        },
         {
           "id": "botinstruction-zep_neo4j_knowledge_graph_guide",
           "title": "ZEP_NEO4J_KNOWLEDGE_GRAPH_GUIDE",
@@ -3627,6 +3660,15 @@
           "updatedAt": "Recently",
           "categoryId": "LLM"
         },
+        {
+          "id": "llm-contextmemorydeveloperguide",
+          "title": "ContextMemoryDeveloperGuide",
+          "description": "",
+          "slug": "contextmemorydeveloperguide",
+          "author": "Documentation",
+          "updatedAt": "Recently",
+          "categoryId": "LLM"
+        },
         {
           "id": "llm-db_migration_llm",
           "title": "Db_migration_llm",
@@ -5430,8 +5472,10 @@
     }
   },
   "contentPathMap": {
+    "botinstruction-tunnel-setup": "/content/docs/BotInstruction/TUNNEL-SETUP.md",
     "botinstruction-zep_neo4j_knowledge_graph_guide": "/content/docs/BotInstruction/ZEP_NEO4J_KNOWLEDGE_GRAPH_GUIDE.md",
     "generators-project-generate-fullproject": "/content/docs/Generators/Project/generate-fullproject.md",
+    "llm-contextmemorydeveloperguide": "/content/docs/LLM/ContextMemoryDeveloperGuide.md",
     "llm-logger.llm": "/content/docs/LLM/Logger.llm.md",
     "llm-templates_folder_and_codegen_guide": "/content/docs/LLM/TEMPLATES_FOLDER_AND_CODEGEN_GUIDE.md",
     "llm-backend-proxies-services-llm": "/content/docs/LLM/backend-proxies-services-llm.md",
@@ -6392,6 +6436,21 @@
         "name": "BotInstruction",
         "path": "BotInstruction",
         "children": [
+          {
+            "type": "file",
+            "name": "TUNNEL-SETUP",
+            "title": "TUNNEL SETUP",
+            "path": "BotInstruction/TUNNEL-SETUP.md",
+            "contentId": "botinstruction-tunnel-setup",
+            "slug": "tunnel-setup",
+            "categoryId": "BotInstruction",
+            "filePath": "/content/docs/BotInstruction/TUNNEL-SETUP.md",
+            "relativePath": "BotInstruction/TUNNEL-SETUP.md",
+            "description": "",
+            "author": "Documentation",
+            "updatedAt": "Recently",
+            "frontmatter": {}
+          },
           {
             "type": "file",
             "name": "ZEP_NEO4J_KNOWLEDGE_GRAPH_GUIDE",
@@ -8505,6 +8564,21 @@
             "updatedAt": "Recently",
             "frontmatter": {}
           },
+          {
+            "type": "file",
+            "name": "ContextMemoryDeveloperGuide",
+            "title": "ContextMemoryDeveloperGuide",
+            "path": "LLM/ContextMemoryDeveloperGuide.md",
+            "contentId": "llm-contextmemorydeveloperguide",
+            "slug": "contextmemorydeveloperguide",
+            "categoryId": "LLM",
+            "filePath": "/content/docs/LLM/ContextMemoryDeveloperGuide.md",
+            "relativePath": "LLM/ContextMemoryDeveloperGuide.md",
+            "description": "",
+            "author": "Documentation",
+            "updatedAt": "Recently",
+            "frontmatter": {}
+          },
           {
             "type": "file",
             "name": "db_migration_llm",
@@ -10418,6 +10492,12 @@
       "title": "BotInstruction",
       "path": null,
       "children": [
+        {
+          "title": "TUNNEL SETUP",
+          "path": "/help/BotInstruction/tunnel-setup",
+          "children": [],
+          "isFile": true
+        },
         {
           "title": "ZEP_NEO4J_KNOWLEDGE_GRAPH_GUIDE",
           "path": "/help/BotInstruction/zep_neo4j_knowledge_graph_guide",
@@ -11082,6 +11162,12 @@
           "children": [],
           "isFile": true
         },
+        {
+          "title": "ContextMemoryDeveloperGuide",
+          "path": "/help/LLM/contextmemorydeveloperguide",
+          "children": [],
+          "isFile": true
+        },
         {
           "title": "Db_migration_llm",
           "path": "/help/LLM/db_migration_llm",

package/lib/templates/content/docs/BotInstruction/TUNNEL-SETUP.md

@@ -0,0 +1,212 @@
+# Tunnel Setup Guide (Cloudflare Tunnel)
+
+Expose the local messenger-box dev environment to the internet using Cloudflare Tunnel (`cloudflared`).
+
+## Prerequisites
+
+```bash
+brew install cloudflared
+```
+
+## Step 1: Start the Frontend Tunnel
+
+```bash
+nohup cloudflared tunnel --url http://localhost:3030 >/tmp/cf-frontend.log 2>&1 &
+sleep 3
+grep -o 'https://[a-z\-]*.trycloudflare.com' /tmp/cf-frontend.log
+```
+
+This gives you a random URL like `https://abc-xyz.trycloudflare.com`. Copy it.
+
+> **Note:** You do NOT need a backend tunnel. The frontend proxies `/graphql` to the backend via Vite proxy.
+
+## Step 2: Update `config/development/dev.env`
+
+**Enable tunnel mode** by setting `ENABLE_TUNNEL=true`:
+
+```env
+# Enable tunnel mode - this configures HMR to work through the tunnel
+ENABLE_TUNNEL=true
+```
+
+Then replace the URLs with your tunnel URL. Keep `LOCAL_*` and `BACKEND_URL` as localhost:
+
+```env
+GRAPHQL_URL=https://<YOUR-TUNNEL-URL>/graphql
+BACKEND_URL=http://localhost:9010
+LOCAL_GRAPHQL_URL=http://localhost:9010/graphql
+LOCAL_BACKEND_URL=http://localhost:9010
+CLIENT_URL=https://<YOUR-TUNNEL-URL>
+APP_URL=https://<YOUR-TUNNEL-URL>
+```
+
+**Why this layout?**
+
+- `GRAPHQL_URL` points to the **frontend** tunnel (not backend) so the browser sends GraphQL requests to the same origin
+- The Vite proxy forwards `/graphql` to `localhost:9010` (the backend)
+- This keeps session cookies on the same domain — no cross-origin issues
+- `LOCAL_*` vars stay as localhost for server-side (SSR) requests that don't need the tunnel
+
+## Step 3: Vite Config Changes
+
+### File: `servers/frontend-server/vite.config.ts`
+
+**3a. Allow all hosts** (line ~46):
+
+```ts
+server: {
+    allowedHosts: true,
+```
+
+**3b. GraphQL proxy** — add inside `server`:
+
+```ts
+    proxy: {
+        '/graphql': {
+            target: 'http://localhost:9010',
+            changeOrigin: true,
+        },
+    },
+```
+
+This forwards browser GraphQL requests through the frontend to the backend. Without this, the browser would need to talk to a separate backend domain and cookies wouldn't be sent cross-origin.
+
+**3c. HMR config** — keep default (no changes needed):
+
+```ts
+    hmr: {
+        port: Number(config.buildConfig.__WEB_DEV_SERVER_PORT__) + 1,
+    },
+```
+
+HMR is handled via `server.js` (see Step 4).
+
+### File: `servers/frontend-server/server.js`
+
+**3d. HMR through the tunnel** — the Express server shares its HTTP server with Vite so HMR WebSocket runs on the same port (3030) and goes through the tunnel:
+
+```js
+// Create HTTP server first so Vite HMR can share the same port
+const http = await import('http');
+const app = express();
+const httpServer = http.createServer(app);
+
+const viteDevServer =
+    process.env.NODE_ENV === 'production'
+        ? undefined
+        : await import('vite').then((vite) => {
+              return vite.createServer({
+                  server: {
+                      middlewareMode: true,
+                      hmr: {
+                          server: httpServer, // Attach HMR WebSocket to Express HTTP server
+                          clientPort: 443, // Browser connects on 443 (tunnel uses HTTPS)
+                      },
+                  },
+              });
+          });
+
+// ... Express middleware setup ...
+
+// Use httpServer.listen instead of app.listen
+const port = config.buildConfig.__WEB_DEV_SERVER_PORT__ || 3030;
+httpServer.listen(port, () => console.log(`Express server listening at http://localhost:${port}`));
+```
+
+**Why `hmr.server`?** Vite docs: _"When `server.hmr.server` is defined, Vite will process HMR connection requests through the provided server."_ This means HMR WebSocket shares port 3030 with Express — no separate port 3031 needed, so it works through the single Cloudflare tunnel.
+
+**Why `clientPort: 443`?** The Cloudflare tunnel serves HTTPS on port 443. The browser's HMR client needs to connect on 443, not 3030.
+
+### Summary of all config changes
+
+| File             | Change                                          | Purpose                                       |
+| ---------------- | ----------------------------------------------- | --------------------------------------------- |
+| `dev.env`        | `ENABLE_TUNNEL=true`                            | Enable tunnel mode for HMR through tunnel     |
+| `vite.config.ts` | `allowedHosts: true`                            | Allow tunnel hostname                         |
+| `vite.config.ts` | `proxy: { '/graphql': ... }`                    | Same-origin GraphQL (fixes cookies)           |
+| `server.js`      | Conditional HMR config based on `ENABLE_TUNNEL` | HMR WebSocket shares port 3030 when tunneling |
+
+## Step 4: Update Auth0 Allowed URLs
+
+Go to [Auth0 Dashboard](https://manage.auth0.com) → Applications → your app → Settings:
+
+- **Allowed Callback URLs:** add `https://<YOUR-TUNNEL-URL>/callback/`
+- **Allowed Logout URLs:** add `https://<YOUR-TUNNEL-URL>`
+- **Allowed Web Origins:** add `https://<YOUR-TUNNEL-URL>`
+
+## Step 5: Restart Both Servers
+
+```bash
+# Session 1 - Backend
+lerna exec --scope="*backend-server" yarn watch
+
+# Session 2 - Frontend (clear vite cache first)
+rm -rf servers/frontend-server/node_modules/.vite
+lerna exec --scope="*frontend-server" yarn watch
+```
+
+## Step 6: Access & Login
+
+1. Open `https://<YOUR-TUNNEL-URL>` in your browser
+2. You'll be redirected to Auth0 login — log in from the tunnel URL
+3. Auth0 redirects back to `https://<YOUR-TUNNEL-URL>/callback/`
+4. Session cookie is set for the tunnel domain → everything works
+
+> **Important:** Always log in through the tunnel URL. Cookies set on `localhost` won't transfer to the tunnel domain.
+
+## HMR Behavior
+
+| Scenario                                     | HMR works? | Notes                                                                                                                        |
+| -------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| Edit files in `servers/frontend-server/`     | ✅ Yes     | Vite watches these directly                                                                                                  |
+| Edit files in `packages-modules/slack-ui/`   | ⚠️ Partial | Requires `yarn build` in slack-ui, then Vite detects lib/ change. Page may need full reload due to module graph invalidation |
+| Edit files in `packages/messenger-platform/` | ⚠️ Partial | Same — requires package rebuild                                                                                              |
+| Through tunnel                               | ✅ Yes     | HMR WebSocket goes through tunnel via shared HTTP server                                                                     |
+| On localhost                                 | ✅ Yes     | Works normally                                                                                                               |
+
+**Note:** Library packages (slack-ui, platform-client) are pre-built to `lib/`. Rebuilding them regenerates `lib/index.js` which invalidates Vite's module graph, causing a full page reload. This is a Vite limitation, not a tunnel issue.
+
+## Reverting to Local Development
+
+Simply set `ENABLE_TUNNEL=false` in `config/development/dev.env`:
+
+```env
+# Disable tunnel mode for local development
+ENABLE_TUNNEL=false
+```
+
+And restore the original env values:
+
+```env
+GRAPHQL_URL=http://localhost:9010/graphql
+BACKEND_URL=http://localhost:9010
+LOCAL_GRAPHQL_URL=http://localhost:9010/graphql
+LOCAL_BACKEND_URL=http://localhost:9010
+CLIENT_URL=http://localhost:3030
+APP_URL=http://localhost:3030
+```
+
+No code changes are needed — the server.js and vite.config.ts automatically use the appropriate HMR configuration based on the `ENABLE_TUNNEL` environment variable.
+
+## Troubleshooting
+
+| Issue                              | Fix                                                                                                                            |
+| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| "Blocked request" from Vite        | Ensure `allowedHosts: true` in vite.config.ts                                                                                  |
+| WebSocket errors in console        | Check `hmr.server` is set in server.js and `clientPort: 443`                                                                   |
+| "User not authenticated"           | Cookie cross-origin issue — make sure `GRAPHQL_URL` points to the frontend tunnel (same domain), not a separate backend tunnel |
+| Org list empty                     | Log in through the tunnel URL, not localhost                                                                                   |
+| `EADDRINUSE ::: 3030`              | Don't set `hmr.port` to 3030 in vite.config.ts — use `hmr.server` in server.js instead                                         |
+| `EADDRNOTAVAIL` on HMR             | Don't set `hmr.host` to the tunnel hostname — it tries to bind locally to a Cloudflare IP                                      |
+| Tunnel URL changed                 | Quick tunnels get random URLs on restart. Update dev.env and Auth0 each time                                                   |
+| "Failed to load url" after rebuild | Normal — rebuilding a library package invalidates Vite's module graph. Reload the page.                                        |
+
+## Optional: Stable URLs with ytunnel
+
+For persistent tunnel URLs using your own Cloudflare domain:
+
+```bash
+brew install yetidevworks/ytunnel
+```
+
+Requires a Cloudflare account, API token, and a domain managed by Cloudflare. See https://github.com/yetidevworks/ytunnel

package/lib/templates/content/docs/LLM/ContextMemoryDeveloperGuide.md

@@ -0,0 +1,313 @@
+# Zep Memory — Developer Guide for AI-Assisted Coding
+
+## Overview
+
+We use a shared **Zep memory server** (`https://zep.cdebase.dev`) as a team-wide knowledge base for GitHub Copilot (and any other LLM agent). When you solve a bug, document an architecture pattern, or figure out a non-obvious workflow, you should **store that context to Zep** so every developer (and their AI assistant) can retrieve it in future sessions.
+
+Zep automatically extracts **facts** from stored messages and makes them searchable via semantic search — so the AI can recall project-specific knowledge without you pasting large docs into every chat.
+
+---
+
+## 1. Setup — Zep MCP Server
+
+### 1.1 Install the MCP server (one-time)
+
+```bash
+# Create the MCP server directory
+mkdir -p ~/.vscode/mcp-servers/zep-mcp
+cd ~/.vscode/mcp-servers/zep-mcp
+
+# Create package.json
+cat > package.json << 'EOF'
+{
+  "name": "zep-mcp",
+  "version": "1.0.0",
+  "private": true,
+  "type": "module",
+  "description": "MCP server for self-hosted Zep memory/knowledge API",
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "^1.0.0"
+  }
+}
+EOF
+
+npm install
+```
+
+Then copy the `server.mjs` file from the team shared location (ask your lead for the latest version).
+
+### 1.2 Configure VS Code MCP
+
+Add the Zep server to your **VS Code User MCP settings**:
+
+**File:** `~/Library/Application Support/Code/User/mcp.json` (macOS)  
+**File:** `%APPDATA%\Code\User\mcp.json` (Windows)
+
+```jsonc
+{
+    "servers": {
+        "zep": {
+            "type": "stdio",
+            "command": "node",
+            "args": ["${userHome}/.vscode/mcp-servers/zep-mcp/server.mjs"],
+            "env": {
+                "ZEP_API_URL": "https://zep.cdebase.dev",
+                "ZEP_API_KEY": "emVwLXNlY3JldC1rZXktY2hhbmdlLW1lLWluLXByb2R1Y3Rpb24=",
+            },
+        },
+    },
+}
+```
+
+> **Note:** The API key is base64-encoded. The MCP server decodes it automatically.
+
+### 1.3 Verify it works
+
+In VS Code Copilot Chat (Agent mode), type:
+
+```
+Search Zep memory in session "cdebase-llm-guides" for "backend service creation"
+```
+
+If you get search results, you're set up correctly.
+
+---
+
+## 2. Session Structure
+
+We use a **single shared session** for team-wide knowledge:
+
+| Session ID           | Purpose                                                        |
+| -------------------- | -------------------------------------------------------------- |
+| `cdebase-llm-guides` | All project guides, patterns, architecture docs, bug fix notes |
+
+> **Important:** Everyone reads from and writes to the same session. Zep handles deduplication via semantic similarity.
+
+---
+
+## 3. Available MCP Tools
+
+Your AI assistant (Copilot) has these Zep tools available:
+
+| Tool                   | Description                             | When to Use                                  |
+| ---------------------- | --------------------------------------- | -------------------------------------------- |
+| `search_memory`        | Semantic search across stored knowledge | Finding existing patterns, architecture docs |
+| `get_session_memory`   | Get recent messages + extracted facts   | Quick context at start of a session          |
+| `get_session_messages` | Get raw messages (paginated)            | Browsing all stored guides                   |
+| `add_memory`           | Store new knowledge                     | **After completing meaningful work**         |
+| `list_sessions`        | List all available sessions             | Discovery                                    |
+
+---
+
+## 4. When to Store Context
+
+Store context to Zep **after** you complete any of these:
+
+### ✅ Always Store
+
+- **Bug fixes** — Root cause, what was wrong, what you changed, why
+- **Architecture decisions** — Component chains, data flow, state management patterns
+- **Non-obvious patterns** — Things that took you time to figure out
+- **Build/deploy workflows** — Commands, config file locations, gotchas
+- **GraphQL schema changes** — New fragments, field additions, codegen steps
+- **Data model documentation** — Types, relationships, optional vs required fields
+- **Integration patterns** — How modules connect (Apollo cache, XState, Remix router, etc.)
+
+### ❌ Don't Store
+
+- Trivial one-line fixes
+- Temporary debugging notes
+- Personal preferences / IDE settings
+- Sensitive credentials or secrets
+
+---
+
+## 5. How to Store Context
+
+### Method 1: Ask Copilot Directly (Recommended)
+
+At the end of your coding session, tell Copilot:
+
+```
+Store the following context to Zep memory session "cdebase-llm-guides":
+
+[Describe what you worked on, the key files, patterns, and decisions]
+```
+
+Or more specifically:
+
+```
+Save to Zep memory (session: cdebase-llm-guides) a guide about the
+marketplace extension installation flow. Include the component chain,
+key files, and the Apollo cache update pattern we use.
+```
+
+Copilot will use the `add_memory` MCP tool to store it.
+
+### Method 2: Structured Prompt (Best for Complex Topics)
+
+Ask Copilot to store in a structured format:
+
+```
+Store the following to Zep session "cdebase-llm-guides" as a project guide:
+
+TOPIC: [Module/Feature Name] - [Specific Aspect]
+PROJECT: [forms-stack | adminIde-stack]
+KEY FILES:
+- path/to/file1.ts — what it does
+- path/to/file2.ts — what it does
+PATTERN/FIX:
+[Describe the pattern, architecture, or fix in detail]
+GOTCHAS:
+[List any non-obvious things]
+```
+
+### Method 3: Batch Store at End of Session
+
+If you did significant work, tell Copilot:
+
+```
+Review all the changes we made in this session and store the important
+context to Zep memory session "cdebase-llm-guides". Include architecture
+patterns, bug fixes, and key file locations.
+```
+
+---
+
+## 6. Content Format Guidelines
+
+### Keep entries focused and factual
+
+**✅ Good:**
+
+```
+FORMS-STACK GUIDE: Apollo Cache Strategy.
+Apollo Client auto-normalizes by __typename + id. The updateFormBuilderExtensionSchema
+mutation returns the full FormBuilderExtension with id + metadataSchema, so Apollo
+automatically updates the normalized cache entry. No manual readQuery/writeQuery needed.
+SchemaBasedBuilderWrapper uses fetchPolicy: cache-only.
+File: packages/form-builder/browser/src/components/FormBuilderV3/utils/extensionUtils.ts
+```
+
+**❌ Bad:**
+
+```
+We tried a bunch of things and eventually figured out the cache was the problem.
+I think maybe the Apollo stuff auto-updates? Not sure.
+```
+
+### Include file paths
+
+Always include the **full relative path** from repo root so the AI can find files:
+
+```
+File: packages/form-builder/browser/src/graphql/fragments/formBuilderExtension.gql
+File: servers/backend-server/src/modules/form-builder-extension/form-builder-extension-repository.ts
+```
+
+### Use prefixes for discoverability
+
+Start entries with a consistent prefix so semantic search works well:
+
+```
+FORMS-STACK GUIDE: [Topic]
+ADMINIDE-STACK GUIDE: [Topic]
+DEPLOYMENT GUIDE: [Topic]
+BUG FIX: [Module] - [Issue]
+ARCHITECTURE: [System] - [Aspect]
+```
+
+### Keep entries focused
+
+For very long guides, Copilot will split them into multiple messages automatically (up to 30 messages per request). Each message can be up to ~100K characters, so practical limits are generous.
+
+---
+
+## 7. How to Retrieve Context
+
+### At the start of a session
+
+```
+Search Zep memory in session "cdebase-llm-guides" for "form builder component chain"
+```
+
+### When debugging
+
+```
+Search Zep for any known issues or patterns related to "Apollo cache fetchPolicy
+cache-only" in session "cdebase-llm-guides"
+```
+
+### For onboarding on a module
+
+```
+Get all Zep memory about "marketplace extension" from session "cdebase-llm-guides"
+```
+
+### Copilot will also search automatically
+
+When you set up Copilot Instructions (see Section 8), the AI will automatically search Zep before answering questions about the codebase.
+
+---
+
+## 8. Copilot Instructions (Optional but Recommended)
+
+Create a `.github/copilot-instructions.md` in your repo root to tell Copilot to automatically use Zep:
+
+```markdown
+## Project Context
+
+This is the [forms-stack | adminIde-stack] monorepo. Before answering questions
+about architecture, patterns, or module-specific code, search Zep memory in session
+"cdebase-llm-guides" for relevant context.
+
+When completing significant work (bug fixes, new patterns, architecture changes),
+offer to store the context to Zep memory session "cdebase-llm-guides" for the team.
+```
+
+---
+
+## 9. Currently Stored Knowledge
+
+As of now, the `cdebase-llm-guides` session contains **2,467+ messages** covering:
+
+- Backend service creation patterns (Moleculer, Proxy Services, auto-generation)
+- GraphQL schema design (module-prefixed naming, templates)
+- Frontend Remix upgrade guide
+- Container module patterns (Inversify DI)
+- Forms-stack architecture (component chain, tab switching, Apollo cache, GraphQL fragments)
+- Deployment & Jenkins pipeline patterns
+- And more...
+
+### Quick search examples
+
+```
+"backend proxy service auto generation"
+"forms-stack FormBuilderV3 tab switching"
+"GraphQL module-prefixed naming convention"
+"Moleculer event handler decorator"
+"Remix navigate vs replaceState"
+```
+
+---
+
+## 10. Troubleshooting
+
+| Issue                              | Fix                                                                                    |
+| ---------------------------------- | -------------------------------------------------------------------------------------- |
+| `Zep error: 401 Unauthorized`      | Check your `ZEP_API_KEY` in mcp.json                                                   |
+| MCP tools not showing              | Restart VS Code, check `mcp.json` syntax                                               |
+| Search returns no results          | Try broader search terms; facts are extracted asynchronously (wait ~30s after storing) |
+| `add_memory` fails with size error | Split very large guides into multiple messages (max 30 per request)                    |
+| Zep server unreachable             | Verify VPN/network access to `https://zep.cdebase.dev`                                 |
+
+---
+
+## Summary
+
+1. **Setup** the Zep MCP server in your VS Code
+2. **Search** Zep at the start of sessions for existing context
+3. **Store** new knowledge after completing meaningful work
+4. **Use prefixes** like `FORMS-STACK GUIDE:` or `ADMINIDE-STACK GUIDE:` for discoverability
+5. **Include file paths** so the AI can locate code
+6. **Keep entries factual** and focused

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@cdmbase/wiki-browser",
-    "version": "12.0.18-alpha.41",
+    "version": "12.0.18-alpha.42",
     "description": "Sample core for higher packages to depend on",
     "license": "ISC",
     "author": "CDMBase LLC",
@@ -65,7 +65,7 @@
             }
         ]
     },
-    "gitHead": "37ef81ba661208ac6b90ce2bb8afc2e056761b29",
+    "gitHead": "5581cd005f724fe9685fc016e73f02848d08a328",
     "typescript": {
         "definition": "lib/index.d.ts"
     }