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