oikos/docs/MODULARIZATION_BACKLOG.md

Oikos Modularization Backlog

Status: low priority roadmap item.

Goal

Convert Oikos from module-shaped code into a proper modular platform where users and contributors can add, remove, and customize modules without editing core router/navigation/settings files in several places.

Desired outcome

• A single module manifest/registry owns route, navigation, icon, theme, stylesheet, settings visibility, permissions, and API capability metadata.
• New modules can be added by creating a module folder plus manifest entry, not by touching many core files.
• Existing modules can be disabled cleanly at UI and API/capability level.
• Language packs can be added by dropping in a locale file and registering display metadata in one place.
• Deployment-specific or family-specific customizations stay outside upstreamable core code.

Candidate implementation tasks

1. Introduce a module registry, for example public/modules/manifest.js or a JSON manifest loaded during boot.
2. Refactor router.js to build routes, navigation order, primary nav, theme accents, and disabled-module guards from the registry.
3. Move Kitchen tabs to module metadata so grouped/submodules are first-class.
4. Add a server-side module/capability registry for API exposure and OpenAPI grouping.
5. Add a locale registry so SUPPORTED_LOCALES, locale picker labels, and service-worker precache entries are generated from one source.
6. Define an extension/overlay mechanism for local deployments without patching core files.
7. Add contributor docs: “Create a module” and “Add a language pack”.
8. Add regression tests that verify module registration, hiding/disabling, navigation, and locale discovery.

Priority

Low. Do after the current Kitchen / Meal Planning work is stable and after Friborg-specific customizations are separated from upstreamable platform code.