# 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.