@noego/app 0.0.7 → 0.0.10

package/.claude/settings.local.json

@@ -1,10 +1,17 @@
 {
   "permissions": {
     "allow": [
-      "Bash(cat:*)",
-      "Bash(curl:*)",
-      "Bash(noego dev)",
-      "WebSearch"
+      "Read(//Users/shavauhngabay/dev/noego/dinner/**)",
+      "Read(//Users/shavauhngabay/dev/ego/sqlstack/**)",
+      "Read(//Users/shavauhngabay/dev/ego/forge/**)",
+      "Read(//Users/shavauhngabay/dev/noblelaw/ui/**)",
+      "Read(//Users/shavauhngabay/dev/noblelaw/**)",
+      "mcp__chrome-devtools__take_screenshot",
+      "Bash(npm run build:ui:ssr:*)",
+      "mcp__chrome-devtools__navigate_page",
+      "Bash(node dist/hammer.js:*)",
+      "Bash(tee:*)",
+      "mcp__chrome-devtools__list_console_messages"
     ],
     "deny": [],
     "ask": []

package/DEVELOPING.md

@@ -0,0 +1,73 @@
+**Purpose**
+- Run and test dev watchers without blocking your terminal.
+- Verify backend/frontend restarts on file changes using short, backgrounded runs with logs and PIDs.
+
+**Prerequisites**
+- Node 20+.
+- This repo installed (run `npm install` once).
+
+**Local Watch Harness (Fast, Backgrounded)**
+- Start (runs ~10–15s, then exits on its own):
+  - `Timestamp=$(date +%s); LOG=watch-harness-$Timestamp.log; node scripts/watch-harness.mjs > $LOG 2>&1 & echo $! > watch-harness.pid`
+- Observe:
+  - `tail -f $LOG`
+  - Look for lines like:
+    - `🔄 change detected (change): server/stitch.yaml` (BACKEND)
+    - `🔄 change detected (change): hammer.config.yml` (SHARED)
+    - `🚀 [backend restart #X]` / `🚀 [frontend restart #X]`
+    - `✅ restart sequence complete`
+- Stop (if ever needed):
+  - `kill $(cat watch-harness.pid)`
+- What it does
+  - Seeds a temp tree under `.watch-harness/`.
+  - Watches directories (server/ui/middleware/openapi/repo) and classifies events using your globs.
+  - Spawns mock backend/frontend child processes, simulates backend/frontend/shared changes, restarts the right process(es), then shuts down.
+
+**Real App Dev (noblelaw) in Background**
+- Start dev for the noblelaw project in the background with logs:
+  - `NO_COLOR=1 node ./bin/app.js dev --root /Users/shavauhngabay/dev/noblelaw > noblelaw-dev.log 2>&1 & echo $! > noblelaw-dev.pid`
+- Observe:
+  - `tail -f noblelaw-dev.log`
+  - Expect on startup: backend on port 3002, frontend (Vite) on 3001, router on 3000.
+  - Make edits to trigger restarts:
+    - Backend restart: edit `server/services/*.ts`, `middleware/**/*.ts`, `server/openapi/**/*.yaml`, or `server/repo/**/*.sql`.
+    - Frontend restart: edit `ui/**/*.ts`, `ui/openapi/**/*.yaml`.
+    - Shared restart: edit `index.ts` or `hammer.config.yml`.
+    - Note: `.svelte` changes do not restart the server; Vite HMR handles them.
+  - Look for logs:
+    - `🔄 FILE CHANGE DETECTED: …`
+    - `Type: BACKEND | FRONTEND | SHARED`
+    - `🚀 [RESTART #…] Starting …`
+    - `✅ Restart complete`
+- Stop:
+  - `kill $(cat noblelaw-dev.pid)`
+- Free busy ports (if you see EADDRINUSE):
+  - `for p in 3000 3001 3002; do P=$(lsof -t -nP -iTCP:$p -sTCP:LISTEN 2>/dev/null); [ -n "$P" ] && kill -9 $P; done`
+
+**How The Watcher Works**
+- Chokidar now watches concrete directories/files so it always attaches:
+  - Directories: `server/`, `ui/`, `middleware/`, `server/openapi/`, `server/repo/`, `ui/openapi/`.
+  - Files: `index.ts`, `hammer.config.yml`, `server/stitch.yaml`, `ui/stitch.yaml`.
+- Classification still uses your original globs (picomatch):
+  - Backend: `server/**/*.ts`, `middleware/**/*.ts`, `server/stitch.yaml`, `server/openapi/**/*.yaml`, `server/repo/**/*.sql`.
+  - Frontend: `ui/**/*.ts`, `ui/stitch.yaml`, `ui/openapi/**/*.yaml`.
+  - Shared: `index.ts`, `hammer.config.yml` (plus any app-level watch entries).
+- This avoids the “ready but no watchers” problem when globs don’t match initial files.
+
+**Troubleshooting**
+- No restart logs after editing a file:
+  - Confirm the file lives under a watched directory and matches one of the classification globs above.
+  - `.svelte` isn’t supposed to restart—use Vite HMR in the browser.
+- Watcher error (EMFILE or similar):
+  - The CLI now fails fast on watcher errors with a clear log and exit.
+  - Ensure you’re not watching the entire repo root or `node_modules/`; keep to `server/`, `ui/`, `middleware/` and the specific YAML/SQL roots.
+- Ports in use (EADDRINUSE):
+  - Free 3000/3001/3002 using the snippet above and restart dev.
+- Clean up stray mock processes from the harness (if any):
+  - `pkill -f "\[backend\]"; pkill -f "\[frontend\]"`
+
+**Operational Tips**
+- Always background long-running scripts and write the PID to a file.
+- Tail logs for verification and kill by PID when done.
+- Keep a hard timeout in any custom test harness so it self-exits if something goes wrong.
+

package/docs/asset-serving-fix.md

@@ -0,0 +1,381 @@
+# Asset Serving Architecture Investigation
+
+**Status:** Under Investigation
+**Date:** 2025-01-11 (Updated)
+**Author:** Engineering Team
+**Context:** Deep dive after initial runtime.js fix revealed deeper Forge integration issue
+
+---
+
+## Investigation Summary
+
+After fixing the initial asset serving issue in `runtime.js` (mounting `.app` at root `/`), we discovered a **deeper architectural problem**: The browser is loading SSR components instead of client-bundled components, causing `effect_orphan` errors.
+
+---
+
+## What We Know FOR SURE (Confirmed via Code Review & Logs)
+
+### 1. Build Output Structure
+```
+dist/
+├── .app/
+│   ├── assets/              ← Client-bundled components (Vite output)
+│   │   ├── chunks/          ← Shared code chunks
+│   │   └── components/      ← Browser-ready .js files
+│   │       ├── layout/
+│   │       │   └── root.js  ← VITE-BUNDLED, imports from ../../chunks/
+│   │       └── views/
+│   │           └── home.js
+│   └── ssr/                 ← SSR components (server-side)
+│       ├── chunks/
+│       └── components/
+│           ├── layout/
+│           │   └── root.js  ← SSR VERSION, bare imports fail in browser
+│           └── views/
+│               └── home.js
+├── no_ego.js               ← Bootstrap config
+└── [compiled app files]
+```
+
+### 2. Generated Config Values (from `no_ego.js`)
+```javascript
+{
+  "component_dir": ".app/ssr/components",
+  "component_dir_ssr": ".app/ssr/components",
+  "component_dir_client": "/assets/components",
+  "component_base_path": "/assets",
+  "assets_build_dir": ".app/assets/components",
+  "component_suffix": "components"
+}
+```
+
+### 3. Express Static Mounts (4 total)
+
+**Mount 1** (`runtime.js` line 701-702):
+```javascript
+app.use('/client', express.static('/dist/.app/assets'))
+```
+
+**Mount 2** (`runtime.js` line 703-704):
+```javascript
+app.use('/chunks', express.static('/dist/.app/ssr/chunks'))
+```
+
+**Mount 3** (Forge `server.ts` via `client.js` assets):
+```javascript
+app.use('/', express.static('/dist/.app/assets'))
+app.use('/assets', express.static('/dist/.app/assets'))
+```
+
+**Mount 4** (Forge `server.ts` line 135-137):
+```javascript
+app.use('/.app/ssr/components', express.static('/dist/.app/ssr/components'))
+```
+
+### 4. Browser Behavior (Confirmed via Network Tab)
+```
+Browser requests: http://localhost:3050/.app/ssr/components/layout/root.js
+Server responds: 200 OK (serves SSR component file)
+Browser executes: SSR JavaScript with bare imports
+Result: Module not found errors + effect_orphan error
+```
+
+### 5. Forge's Component Directory Injection (Line 264)
+```typescript
+// express_server_adapter.ts:264
+const clientComponentDir = this.isProd ? this.componentDir : '/assets';
+
+// Line 281:
+window.__COMPONENT_DIR__ = ${JSON.stringify(clientComponentDir)}
+```
+
+**In production mode:**
+- `this.componentDir` = `".app/ssr/components"` (passed from hammer/client.js)
+- Therefore: `window.__COMPONENT_DIR__ = ".app/ssr/components"`
+- Browser constructs URLs: `/.app/ssr/components/layout/root.js`
+
+### 6. Forge's Single component_dir Design (Confirmed)
+**File:** `/Users/shavauhngabay/dev/forge/src/options/ServerOptions.ts`
+```typescript
+export interface ServerOptions {
+    component_dir?: string;  // SINGLE option for BOTH SSR and client
+    // NO component_dir_ssr
+    // NO component_dir_client
+}
+```
+
+**Usage in `server.ts` line 67:**
+```typescript
+const COMPONENT_DIR = !full_options.component_dir ? root : path.join(root, full_options.component_dir);
+```
+
+**Used for:**
+- SSR: `ProdComponentLoader(COMPONENT_DIR)` - loads components server-side
+- Client: Passed to `ExpressServerAdapter` → becomes `window.__COMPONENT_DIR__`
+- Static serving: `app.use(\`/\${component_dir}\`, express.static(COMPONENT_DIR))`
+
+---
+
+## The Core Problem
+
+### What's Happening
+1. **hammer/client.js** passes: `component_dir: '.app/ssr/components'`
+2. **Forge** uses this for EVERYTHING:
+   - SSR component loading ✅ (correct - Node.js can load SSR files)
+   - Client directory injection ❌ (wrong - browser gets SSR path)
+   - Static file serving ✅ (Mount 4 serves SSR files at `/.app/ssr/components`)
+3. **Browser** receives: `window.__COMPONENT_DIR__ = ".app/ssr/components"`
+4. **Browser** requests: `/.app/ssr/components/layout/root.js`
+5. **Express** serves SSR component (via Mount 4) ✅
+6. **Browser** executes SSR JavaScript:
+   - Contains bare imports: `import { onMount } from 'svelte'`
+   - Contains chunk imports: `await import("../../chunks/liveWebsocket-BL1FcyHq.js")`
+   - Resolves to: `.app/ssr/chunks/liveWebsocket-BL1FcyHq.js` ❌ (doesn't exist)
+7. **Result:** Module not found → `effect_orphan` error
+
+### Why SSR Components Fail in Browser
+SSR components are compiled for Node.js:
+- Use bare module imports (`'svelte'`, `'svelte/server'`)
+- Expect Node.js module resolution
+- Cannot run in browser environment
+
+Client components are Vite-bundled for browsers:
+- All imports are resolved and bundled
+- Chunks are properly linked
+- Can execute in browser
+
+---
+
+## What We're GUESSING / Hypothesizing
+
+### Hypothesis 1: We're Passing the Wrong Path
+**Theory:** We should pass `component_dir_client` to Forge instead of `component_dir_ssr`.
+
+**Problem:** If we pass `/assets/components`:
+- Browser would load client components ✅ (correct)
+- But SSR would try to load from `/dist/assets/components/` ❌
+- SSR files are actually at `/dist/.app/ssr/components/`
+- SSR would break
+
+**Conclusion:** Forge's single-path design doesn't support separate SSR/client directories.
+
+### Hypothesis 2: Build Output Should Match Forge's Expectations
+**Theory:** Maybe we should output components to a single directory that works for both SSR and client.
+
+**Problem:** SSR and client components are fundamentally different:
+- SSR: ES modules with bare imports (for Node.js)
+- Client: Vite-bundled with resolved imports (for browser)
+- They MUST be separate files
+
+**Conclusion:** We need two directories, not one.
+
+### Hypothesis 3: Forge Needs to Support Separate Paths
+**Theory:** Modify Forge to accept `component_dir_ssr` and `component_dir_client`.
+
+**Changes needed:**
+1. `ServerOptions.ts`: Add new optional fields
+2. `server.ts`: Calculate both paths
+3. `express_server_adapter.ts`: Use client path for `window.__COMPONENT_DIR__`
+4. `ProdComponentLoader`: Use SSR path for server-side loading
+
+**Status:** This seems like the correct solution, but requires Forge modifications.
+
+### Hypothesis 4: Pass Relative Path "components" to Forge
+**Theory:** The original hammer.config.yml specifies `componentDir: frontend/components`. Relative to `frontend/frontend.ts`, this is just `components`. Maybe we should pass just `"components"` to Forge?
+
+**Analysis:**
+- Forge would calculate: `COMPONENT_DIR = /dist/components`
+- Browser would request: `/components/layout/root.js`
+- But files don't exist at `/dist/components/` ❌
+- Files are at `/dist/.app/assets/components/` and `/dist/.app/ssr/components/`
+
+**Conclusion:** This doesn't match our current build structure.
+
+### Hypothesis 5: Change Build Structure
+**Theory:** Output components to `/dist/components/` (single location) instead of separate SSR/client dirs.
+
+**Problems:**
+- How would we differentiate SSR vs client builds?
+- Vite outputs to one location, SSR to another
+- Would require major build pipeline changes
+- Unclear if this is even possible with current tools
+
+**Status:** Needs more investigation into Vite's capabilities.
+
+---
+
+## Original Config Intent
+
+**From `hammer.config.yml`:**
+```yaml
+client:
+  main: frontend/frontend.ts          # UI root: /project/frontend/
+  componentDir: frontend/components   # Components: /project/frontend/components/
+```
+
+**Relative calculation:**
+- UI root: `frontend/`
+- Component dir: `frontend/components/`
+- Relative path: `components/` (just the subdirectory)
+
+**Bootstrap calculates:**
+- `component_dir_ssr`: `.app/ssr/components`
+- `component_dir_client`: `/assets/components`
+
+**The question:** Should Forge receive:
+- Option A: `.app/ssr/components` (full SSR path, current behavior)
+- Option B: `/assets/components` (full client path, breaks SSR)
+- Option C: `components` (relative path, no files at `/dist/components/`)
+- Option D: Both paths via new Forge API
+
+---
+
+## Potential Solutions
+
+### Solution 1: Modify Forge (Most Correct)
+**Pros:**
+- Clean separation of concerns
+- SSR and client use correct directories
+- No breaking changes to build pipeline
+
+**Cons:**
+- Requires Forge modifications
+- Need to update Forge across all projects
+
+**Files to change:**
+1. `forge/src/options/ServerOptions.ts` - Add `component_dir_ssr` and `component_dir_client`
+2. `forge/src/server/server.ts` - Calculate both paths
+3. `forge/src/routing/server_adapter/express_server_adapter.ts` - Use client path for injection
+4. `hammer/src/client.js` - Pass both paths
+
+### Solution 2: Change Hammer Build to Output Single Component Directory
+**Approach:** Build both SSR and client to same location, differentiate by filename suffix.
+
+**Example:**
+```
+dist/components/
+  ├── layout/
+  │   ├── root.ssr.js    # For server-side rendering
+  │   └── root.js        # For browser
+```
+
+**Pros:**
+- Works with Forge's current API
+- No Forge modifications needed
+
+**Cons:**
+- Major build pipeline changes
+- Unclear if Vite supports this pattern
+- May break component loader expectations
+- High risk of regressions
+
+### Solution 3: Pass Client Path to Forge, Handle SSR Separately
+**Approach:** Pass `/assets/components` to Forge, manually load SSR components elsewhere.
+
+**Problems:**
+- How would SSR loading work?
+- Would need to bypass Forge's component loader
+- Unclear if this is even possible
+- High complexity, fragile
+
+### Solution 4: Mount Client Components at SSR Path
+**Approach:** Add another Express mount that serves client components at `/.app/ssr/components`.
+
+**Example:**
+```javascript
+app.use('/.app/ssr/components', express.static('/dist/.app/assets/components'))
+```
+
+**Pros:**
+- No code changes to Forge
+- Quick fix
+
+**Cons:**
+- Conceptually wrong (SSR path serves client files)
+- Confusing for developers
+- SSR would still try to load from wrong location
+- Doesn't fix the root problem
+
+---
+
+## Open Questions
+
+1. **Can Vite output to a single component directory?**
+   - Can we build SSR and client to same location with different naming?
+   - Does this conflict with Vite's chunk optimization?
+
+2. **Does Forge's dev mode work correctly?**
+   - Dev mode uses Vite dev server
+   - Does it have the same SSR/client split issue?
+   - Line 264: `clientComponentDir = this.isProd ? this.componentDir : '/assets'`
+   - In dev: Always uses `/assets` - why does this work?
+
+3. **Is the `.app/` directory structure mandatory?**
+   - Could we output to `/dist/ssr/` and `/dist/assets/` instead?
+   - Would this simplify path calculations?
+
+4. **What did the original Forge design expect?**
+   - Was Forge designed for projects with separate SSR/client builds?
+   - Or was it designed for unified component directories?
+
+5. **Are there other projects using this stack successfully?**
+   - How do they structure their builds?
+   - Can we learn from existing patterns?
+
+---
+
+## Next Steps
+
+1. **Decide on solution approach:**
+   - Option 1: Modify Forge (cleanest, most correct)
+   - Option 2: Restructure build output (risky, high effort)
+   - Option 3: Quick mount hack (temporary workaround)
+
+2. **If Option 1 (Modify Forge):**
+   - Design the new API surface
+   - Write tests for dual-path support
+   - Implement changes in Forge
+   - Update hammer to use new API
+   - Test with markdown_view, liftlog, noblelaw
+
+3. **If Option 2 (Restructure Build):**
+   - Research Vite multi-output capabilities
+   - Design new directory structure
+   - Update build pipeline
+   - Test thoroughly across all projects
+
+4. **Validate the fix:**
+   - Run all 18 unit tests
+   - Test markdown_view in production mode
+   - Verify no `effect_orphan` errors
+   - Confirm browser loads correct (client) components
+   - Verify SSR still works
+
+---
+
+## Timeline Estimate
+
+- **Option 1 (Modify Forge):** 2-3 hours implementation + 1 hour testing
+- **Option 2 (Restructure Build):** 1-2 days research + 2-3 days implementation + 2 hours testing
+- **Option 3 (Quick Hack):** 30 minutes, but doesn't solve root cause
+
+---
+
+## Files Reference
+
+### Confirmed File Locations
+- `/Users/shavauhngabay/dev/hammer/src/client.js` - Passes component_dir to Forge
+- `/Users/shavauhngabay/dev/hammer/src/runtime/runtime.js` - Express static mounts
+- `/Users/shavauhngabay/dev/hammer/src/build/bootstrap.js` - Calculates component paths
+- `/Users/shavauhngabay/dev/forge/src/server/server.ts` - Forge server initialization
+- `/Users/shavauhngabay/dev/forge/src/options/ServerOptions.ts` - Forge options interface
+- `/Users/shavauhngabay/dev/forge/src/routing/server_adapter/express_server_adapter.ts` - Injects window.__COMPONENT_DIR__
+- `/Users/shavauhngabay/dev/forge/src/routing/component_loader/component_loader.ts` - ProdComponentLoader
+- `/Users/shavauhngabay/dev/markdown_view/hammer.config.yml` - Project configuration
+- `/Users/shavauhngabay/dev/markdown_view/dist/no_ego.js` - Generated runtime config
+
+---
+
+**END OF DOCUMENT**
+
+For questions or to proceed with implementation, contact the engineering team.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noego/app",
-  "version": "0.0.7",
+  "version": "0.0.10",
   "description": "Production build tool for Dinner/Forge apps.",
   "type": "module",
   "bin": {
@@ -30,6 +30,8 @@
   "author": "App Build CLI",
   "dependencies": {
     "deepmerge": "^4.3.1",
+    "glob-parent": "^6.0.2",
+    "http-proxy": "^1.18.1",
     "picomatch": "^2.3.1",
     "yaml": "^2.6.0"
   },
@@ -38,5 +40,7 @@
     "@noego/forge": "*",
     "express": "*"
   },
-  "devDependencies": {}
+  "devDependencies": {
+    "chokidar": "^4.0.3"
+  }
 }