Community Core Operations

Konduo Community Core provides the shared operating layer for plugin-based resource registration, access control, audit records, alert workflows, metric linkage, dashboards, and diagnostics. Domain-specific behavior belongs to plugins; Core keeps registration, rendering, permissions, and lifecycle behavior consistent across those plugins.

Primary Responsibilities

1. Register and manage resource, metric source, and alert channel plugins.
2. Handle users, roles, resource permissions, and audit records through one common model.
3. Render resource dashboards, diagnostics, and alert-rule pages from host-rendered schemas.
4. Run plugin health checks, alert evaluation, and delivery sessions through shared workflows.
5. Connect resource-owned logical metrics to concrete metric source queries through mapping packs.

Operating Flow

• Review available resource plugins, metric sources, and alert channels in admin settings.
• Register resources with plugin-specific connection settings and metric linkage.
• Run connection tests and resource health checks after registration.
• Use dashboards and diagnostics together to review current state, historical risk, and metric coverage.
• Tune alert rules, routes, workflows, and delivery history per resource.

Initial Administrator Provisioning

Konduo does not create a known default administrator password in production. After schema migration and reference-data seeding, a new database without an active administrator reports setup_required from /readyz and admin-bootstrap-status. An operator must then create the initial administrator with the one-time command.

Local Development

Run the following from the repository root:

task db:postgres:up
task db:seed
printf '%s\n' "$INITIAL_ADMIN_PASSWORD" | task backend:admin:bootstrap
task run

The default username is admin. Set ADMIN_USERNAME when another name is required:

printf '%s\n' "$INITIAL_ADMIN_PASSWORD" | \
  ADMIN_USERNAME=operator task backend:admin:bootstrap

Inspect the current state with:

task backend:admin:bootstrap:status

task clean removes build, scan, and temporary artifacts only. It does not delete PostgreSQL data, an existing administrator, or the completed bootstrap state. Run task db:reset and repeat the full procedure only when a completely new local database is intended.

Use task db:seed:demo only when you explicitly need demo accounts with known passwords and sample data. It is not a production administrator provisioning path.

Docker Compose

Run the one-time command with the same backend image and environment. Supply the password through stdin or a mode-0600 file, never as a command-line argument.

printf '%s\n' "$INITIAL_ADMIN_PASSWORD" | \
  docker compose --env-file docker/compose.release.env \
  -f docker/compose.yml run --rm -T backend \
  admin-bootstrap --username admin --password-stdin

Kubernetes

Create a one-shot Job that uses the same image, database settings, and encryption key as the backend. Read the initial password from a Secret, stage it in a memory-backed emptyDir with mode 0600, and run:

admin-bootstrap --username admin --password-file /run/konduo-bootstrap/password

Job retries are safe. Once bootstrap is complete, another attempt succeeds without changing the existing password. Confirm the complete state, then delete the initial-password Secret and Job.

Login and Recovery Boundaries

• The first login must change the password immediately.
• The password must satisfy the current local authentication policy.
• Running bootstrap again in the complete state does not change the existing account or password.
• If no active administrator remains after bootstrap completed, the state becomes recovery_required. Do not use bootstrap to create a replacement; follow the approved password-reset or verified-backup recovery procedure.
• A successful password reset revokes existing login sessions and refresh tokens and requires another password change at the next login.

printf '%s\n' "$TEMPORARY_PASSWORD" | \
  task backend:reset-password RESET_USERNAME=admin

Boundaries

• Core owns shared lifecycle, permissions, audit, alert workflow, and UI hosting.
• Plugins own domain configuration schemas, diagnostic evidence, logical metrics, mapping packs, and management actions.
• Sensitive credentials are used only at the storage and execution boundary and must not be exposed in health or diagnostic payloads.
• Plugin-specific UI behavior should be exposed through schemas and contributions, not hard-coded into Core.

Related Documents

• docs/community-edition-boundary.md
• docs/plugin-extension-point-policy.md
• docs/frontend-plugin-ui-contract.md
• docs/plugin-diagnostics-contract.md
• docs/manual-source-contract.md
• backend/docs/administrator-bootstrap.md