Modern CMS · business application platform

Kumwe CMS

A modern content-management system and typed business application platform whose administrator, portal, REST, CLI, MCP, worker, and scheduler surfaces share the same application rules.

Active public platform · current source reviewed
Role
Principal architect, lead implementer and maintainer
Evidence
3 direct public links
  • PHP 8.5
  • Mezzio
  • Joomla Framework
  • Doctrine DBAL
  • Redis
  • TypeScript
  • Docker
  • MCP

Purpose and value

Why this system exists

Kumwe unifies governed publishing and business operations without splitting policy across channels. Managed content, typed business definitions, generated operational surfaces, extension delivery, approvals, audit, and durable automation all pass through shared application services.

Engineering role

Principal architect, lead implementer and maintainer

System structure

Architecture

  1. 01

    Content management and the typed business runtime share application services, so administrator, portal, REST, CLI, MCP, worker, and scheduler paths enforce the same rules.

  2. 02

    Business definitions declare typed entities, relationships, views, actions, safe formulas, policies, and approvals from which operational surfaces and contracts are generated.

  3. 03

    A signed extension pipeline installs plugins, components, templates, and languages into a compiled and verified runtime without rebuilding the application image.

  4. 04

    Doctrine DBAL provides one portable persistence boundary across MariaDB, MySQL, and PostgreSQL, while Redis supplies cache, locks, rate limits, and coordination.

  5. 05

    Database-backed queues, leases, bounded retries, recurring schedules, inbox/outbox delivery, and isolated portal sessions make automation and external integration explicit runtime capabilities.

Boundaries

Principal interfaces

Graphical administrator and isolated client portal
Versioned REST/OpenAPI, CLI, and MCP contracts
Installable extensions, templates, and demo profiles
Workers, scheduler, queues, reports, events, and integration SDK

Judgement

Engineering decisions

Apply one authorization, validation, workflow, and audit model across every delivery channel instead of maintaining divergent browser and API behavior.

Generate business surfaces from typed definitions while retaining extension-owned custom handlers for domain-specific behavior.

Install extensions through a signed, compiled, verified lifecycle rather than coupling extension delivery to application-image rebuilds.

Keep persistence portable and production automation durable through explicit database, Redis, queue, lease, retry, and recovery boundaries.

Confidence model

Delivery, validation, and maintenance

  • Architecture and dependency policy enforced by the merge gate
  • PHPStan at maximum level, PSR-12 checks, API documentation checks, and unit/integration suites
  • Compiled OpenAPI contract verification and browser regression coverage
  • The same services and migrations exercised across MariaDB, MySQL 8.4, and PostgreSQL 17
  • Normative Kumwe Interface Standard for administrator, portal, generated, extension, and template surfaces

Direct sources

Inspect the evidence

Current verified scope

The 13 August 2026 master snapshot contains 331 attributable commits across 2,054 unique paths and documents a working CMS and business runtime with governed content, typed definitions, generated administrator and portal surfaces, REST/OpenAPI, CLI, MCP, signed extensions, durable automation, and three supported SQL engines.

Interpretation boundary

The project is active and evolving; this brief follows current public documentation and does not invent adoption, deployment-scale, performance, or production-certification claims.

Source reviewed to 2026-08-13

Rapid navigation

Go to

↑↓ navigate Enter open