GovOPlaN core is the platform runner and shared foundation. It owns the server entry point, database/session primitives, tenant and RBAC infrastructure, governance policy, audit/auth helpers, module discovery, migration registration, and the shared WebUI shell. Feature code is supplied by installed modules.

Repository ownership

Core owns:

govoplan_core.server.app:app, the FastAPI entry point used by uvicorn
GovoplanServerConfig, module discovery, registry validation, and route aggregation
SQLAlchemy base/session helpers and module migration registration
tenant/account/session/RBAC/governance/audit models and services
core API routes for auth, admin, platform metadata, audit, and system health
@govoplan/core-webui, including login, CSRF/API helpers, shell layout, generic UI components, IconRail, DataGrid, access boundaries, and module route/nav contracts

Feature modules own their backend routers, models, migrations, permissions, frontend packages, nav items, and route contributions. Core should not import feature pages directly; it imports module manifests and renders their route contributions.

Governance docs

Canonical policy documents live in docs/:

Modules may define module-specific permissions and policy behavior, but the platform-level permission model and governance hierarchy belong here.

Backend development

Create or activate the core virtual environment, then install core and sibling modules from this repository:

cd /mnt/DATA/git/govoplan-core
./.venv/bin/python -m pip install -r requirements-dev.txt

Run the platform server from core through the module-aware development runner. The default config reads ENABLED_MODULES and discovers installed module entry points. Local development defaults to access,campaigns,files,mail; set ENABLED_MODULES explicitly when testing a smaller module permutation.

cd /mnt/DATA/git/govoplan-core
./.venv/bin/python -m govoplan_core.devserver \
  --host 127.0.0.1 \
  --port 8000

For example, to test campaign without files or mail:

cd /mnt/DATA/git/govoplan-core
ENABLED_MODULES=access,campaigns ./.venv/bin/python -m govoplan_core.devserver \
  --host 127.0.0.1 \
  --port 8000

The runner loads the same GovoplanServerConfig as govoplan_core.server.app:app, builds the platform registry, and passes core plus enabled module source roots to uvicorn as reload directories. After reinstalling the editable package, the same command is also available as govoplan-devserver.

The default development SQLite database lives at runtime/multimailer-dev.db, alongside other local runtime state.

Local devserver runs do not require Redis. CELERY_ENABLED defaults to false, so campaign queue actions update database state without publishing Celery tasks. Use the synchronous send flow for local send tests, or set CELERY_ENABLED=true only when a Redis broker and worker are running.

If the configured local SQLite database is missing or empty, govoplan_core.devserver enables the development bootstrap before loading settings. This creates the schema and the default development login on startup. Explicitly setting DEV_BOOTSTRAP_ENABLED=false disables this convenience. Production deployments should use migrations and managed database provisioning instead.

To verify the effective runtime paths and missing-SQLite bootstrap without starting uvicorn, run the smoke mode:

cd /mnt/DATA/git/govoplan-core
./.venv/bin/python -m govoplan_core.devserver --smoke --no-reload

The smoke mode prints the effective config, runtime root, database URL, modules, reload state, and bootstrap decision, then creates the ASGI app and runs startup once.

requirements-dev.txt links local govoplan-files, govoplan-mail, and govoplan-campaign checkouts for development. requirements-release.txt installs those modules from tagged git refs for release builds. See RELEASE_DEPENDENCIES.md.

WebUI development

Install and run from the core WebUI host:

cd /mnt/DATA/git/govoplan-core/webui
PATH=/home/zemion/.nvm/versions/node/v22.22.3/bin:$PATH /home/zemion/.nvm/versions/node/v22.22.3/bin/npm install
PATH=/home/zemion/.nvm/versions/node/v22.22.3/bin:$PATH /home/zemion/.nvm/versions/node/v22.22.3/bin/npm run dev

The local host links sibling module WebUI packages through local file dependencies and Vite filesystem allowances. Release builds should use webui/package.release.json, which points WebUI module packages at tagged git refs. See RELEASE_DEPENDENCIES.md.

Module contract

Backend modules register through the govoplan.modules entry point and return a ModuleManifest. A manifest can contribute:

permissions and role templates
API routers
SQLAlchemy metadata and migration locations
nav metadata and frontend package metadata
resource ACL providers and tenant summary/delete-veto providers

WebUI modules export a PlatformWebModule with nav items and route contributions. Core renders those routes with settings and auth context. Frontend nav icons must be supplied as core-resolved iconName strings, not imported icon components. See MODULE_ARCHITECTURE.md for the full module-building contract.