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

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 (UMD/browserify bundle).
• A number of runtime steps are already split into editable modules under @be/be/be/:
  • @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
• The injection logic is here: @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/menu-manager.js

3) Hard limit: “menu entry exists” ≠ “skill is loadable”

• BE loads skills listed in @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.