Version 3.1 InDev

V3.1/build/opt/jibo/Jibo/Skills/MODULARITY_PLAN.md

@@ -0,0 +1,80 @@
+# Modularity ground-work (Skills FS)
+
+Target: make the main menu + skill launching as modular as possible while staying compatible with the existing precompiled BE bundle.
+
+## What you have today (important choke points)
+
+### 1) BE is a big precompiled bundle
+- The BE “brain” is shipped as [@be/be/index.js](@be/be/index.js) (UMD/browserify bundle).
+- A number of runtime steps are already split into editable modules under [@be/be/be/](@be/be/be/):
+  - [@be/be/be/postinit.js](@be/be/be/postinit.js) is especially valuable because it runs after init and is easy to patch.
+
+### 2) Menu is already semi-modular (via patch)
+- The menu injection is wired in here: [@be/be/be/postinit.js](@be/be/be/postinit.js)
+- The injection logic is here: [@be/be/menu/main-menu-patch.js](@be/be/menu/main-menu-patch.js)
+- There are two alternate menu implementations that aren’t currently the default path:
+  - [@be/be/menu/skills-scanner.js](@be/be/menu/skills-scanner.js)
+  - [@be/be/menu/menu-manager.js](@be/be/menu/menu-manager.js)
+
+### 3) Hard limit: “menu entry exists” ≠ “skill is loadable”
+- BE loads skills listed in [@be/be/package.json](@be/be/package.json) → `jibo.skills[]`.
+- So the current menu patch can *show* buttons for new skills, but launching them will fail unless BE can actually load them.
+
+## What “max modular menu” realistically means
+
+You can make the **menu definition** fully modular without touching the BE bundle. Making **skill loading** fully modular is harder because the bundle pre-bakes skill modules.
+
+## Step-by-step path (least risky first)
+
+### Phase A — Make menu config fully modular (low risk)
+1. **Single source of truth for scanning**
+   - Stop duplicating scanner logic between `main-menu-patch.js` and `skills-scanner.js`.
+   - Export a stable `scanSkills(rootDir, options)` function that returns the exact menu schema expected by the main-menu skill.
+
+2. **Make Skills root configurable**
+   - Replace hard-coded `/opt/jibo/Jibo/Skills` with:
+     - env var `JIBO_SKILLS_ROOT`, else
+     - fallback `/opt/jibo/Jibo/Skills`.
+
+3. **Allow multiple menu providers (plugin style)**
+   - Add an entries directory, e.g. `/opt/jibo/Jibo/Skills/@be/menu-entries.d/`.
+   - Providers can be:
+     - `.js` files that export `getEntries()`
+     - `.json` static entries
+   - Patch merges provider entries + scanned `menuEntry.json` entries.
+
+4. **Move icon/color policy into config**
+   - Keep defaults, but load overrides from a JSON config file (ex: `@be/be/menu/menu-config.json`).
+
+### Phase B — Add Python-friendly menu generation (low/medium risk)
+1. Implement a “generated menu file” contract:
+   - Python script writes a JSON file, e.g. `/tmp/jibo-menu.generated.json`.
+   - Menu patch reads it (if present) and merges into the menu.
+2. This lets you write menu logic in Python 2.7 without fighting JS runtime quirks.
+
+### Phase C — Make skill launching modular (hard)
+This is the real blocker for “true modularity”. Options:
+
+1. **Soft approach** (menu remains modular; launching only works for known skills)
+   - Accept that new entries are “shortcuts” to existing/registered skills.
+
+2. **Medium approach** (dynamic skill registry)
+   - Maintain a small registry mapping `skillId -> folder path` by scanning `/opt/jibo/Jibo/Skills`.
+   - On launch, route through a single “launcher” skill (registered in BE) that loads content/assets from disk.
+
+3. **Hard approach** (replace BE bundle / build chain)
+   - Rebuild BE so skills are not baked into the browserify bundle.
+   - This is the cleanest long-term solution but requires toolchain alignment and more invasive changes.
+
+## Logging groundwork (so you can debug all of the above)
+
+To make JS/Python logging painless on a BusyBox robot, the repo now includes a tiny UDP log daemon + init.d template:
+
+- tools/robot/logd/jibo_logd.py
+- tools/robot/init.d/jibo-skills-logd
+
+This gives you a single log file you can tail on robot (default `/tmp/jibo-skills.log`) and a trivial Node client under:
+
+- @be/be/be/robot-logger.js
+
+Next step is to switch noisy modules (menu patch, loaders) to send logs to the daemon.