The module system

A module is a self-contained unit of functionality with a machine-readable manifest: module.json. The manifest declares everything the composition engine needs to combine modules safely: the database schema fragment, the server actions, the UI components, the API routes, the secrets, the compliance obligations, the MCP tools, and the audit events it emits.

The engine reads every module's manifest before generating code. It validates composition constraints (dependsOn / conflictsWith), enforces compliance gates (analytics requires compliance-eu), merges schema fragments into @alleex-cloud/canonical-schema, and wires the MCP spine to expose each module's tools. The app you get out is a coherent whole — not patched fragments.

This is the difference between Alleex Cloud and a prompt-to-code tool. Modules are contracts. The engine can reason about them. Free-form codegen cannot.

Every module that touches personal data carries a compliance block in its manifest. It declares what personal data the module collects, which file handles DSAR export, which file handles erasure, which subprocessors the module introduces, and the EU AI Act impact classification.

This is not a self-attestation field — the composition engine reads it. When a DSAR request arrives, the engine calls each installed module's dsarHandler in turn and assembles a complete export. When a user requests erasure, each module's deletionHandler is called. The compliance-eu module orchestrates the 30-day window and surfaces overdue requests in the dashboard.

The EU AI Act risk register is generated at compose time: every module with aiActImpact set to anything other than none contributes a row to the register. The register is readable via the MCP tool compliance_get_risk_register.

"compliance": {
  "personalDataCollected": [
    "cookie_consent_choices",
    "ip_hash",
    "user_agent_hash",
    "dsar_request_metadata"
  ],
  "dsarHandler": "compliance/dsar.ts",
  "deletionHandler": "compliance/delete.ts",
  "subprocessors": [],
  "aiActImpact": "none"
}

Each module declares its MCP tools in the mcp block of its manifest: name, description, required scopes, and whether the tool requires explicit human approval before execution. The hosted MCP spine wires every installed module's tools into a single endpoint your agents and CLI tools can call.

Destructive or sensitive tools (cancelling a subscription, revoking a session, initiating a DSAR export) carry humanApprovalRequired: true in the manifest. The spine enforces this — it is not a convention, it is a gate the module author cannot skip.

Read-only informational tools (who_am_i, compliance_get_model_card, compliance_get_risk_register) run without approval. The distinction is declared in the manifest and enforced at runtime.

Every module lists its audit event names in auditEvents. These names are the exact strings written to the hash-chained audit log when those operations happen (for example, auth.user.created, compliance.dsar.completed, compliance.consent.recorded).

Each audit row is hash-chained to the previous row via a server-side Postgres trigger. Chain heads are periodically witnessed in Sigstore Rekor — a public, append-only transparency log — so retroactive alteration is detectable by any third party. This is not opt-in: the audit table and trigger are part of @alleex-cloud/canonical-schema and present in every generated app.

For the full compliance picture — what the audit log covers, how to export it, and how Rekor witnessing works — see the compliance docs.

The following modules are in the registry as of this writing. The registry is the source of truth — if a module appears here, its module.json is live in the codebase.

Registry growth: New modules are added when their module.json, implementation, tests, and compliance tag are all complete. We do not list modules before they ship.

Modules can declare hard composition rules. The engine validates these before generating any code: