epic(platform-evolution): prepare AWCMS-Mini for scalable SaaS, business, and ERP-derived applications #738

Context

AWCMS-Mini has completed the generic base backlog and the platform-hardening epic #679. The current repository already provides a Bun + Astro 7 + PostgreSQL modular monolith, tenant-aware RBAC/ABAC/RLS, audit, idempotency, sync/outbox patterns, workflow approval, reporting, module management, connection pooling/backpressure, observability, resilience verification, and production preflight.

The next readiness gap is not rebuilding those foundations. It is proving and extending AWCMS-Mini as a reusable technical application kernel for many independently maintained derived repositories, horizontal deployment, high-volume data, enterprise processes, optional SaaS control-plane extensions, and ERP extension contracts.

This epic adapts the validated recommendations in Validasi Arsitektur, Skalabilitas, Performa, dan Ekspansi AWCMS-Mini v1.0 dated 13 July 2026 after checking the current main branch and open backlog.

Relationship to completed work

This is a follow-up to, not a reopening or duplicate of:

• epic(platform-hardening): reconcile architecture, security, delivery, docs, and operations #679 platform hardening;
• fix(modules): eliminate core module dependency cycles and add DAG validation #680 registry DAG validation;
• refactor(architecture): replace blog-content/news-portal circular imports with capability ports #681 capability ports and source-boundary protection;
• docs(governance): define core, system, official optional module, and derived-app admission policy #696 module admission/lifecycle governance;
• feat(observability): add metrics, SLOs, job health, and provider telemetry #698 metrics/SLO/provider telemetry;
• test(resilience): add failure-injection and disaster-recovery verification #699 resilience and disaster-recovery verification;
• docs(api): publish generated API and event reference documentation #700 generated API/event reference documentation.

Child issues must reuse those implemented mechanisms and scope only the remaining deltas.

Objective

Make AWCMS-Mini a reusable platform kernel that:

1. can be composed safely by multiple derived repositories without editing base registry files;
2. verifies base/derived compatibility before build and release;
3. has an operational transactional domain-event runtime;
4. proves horizontal database capacity and performance regression budgets;
5. governs retention, partitioning, archival, legal hold, and safe purge for high-volume data;
6. supports reusable business scope, enterprise workflow, party/profile, organization, reference data, document, data-exchange, reporting-projection, and integration primitives;
7. defines ERP extension contracts without adding ERP functional domains to the base repository.

Architecture placement

AWCMS-Mini
├── Core
│   ├── tenant_admin
│   ├── profile_identity
│   ├── identity_access
│   ├── logging
│   └── module_management
├── System Foundation
│   ├── workflow
│   ├── sync_storage
│   ├── reporting
│   ├── domain_event_runtime
│   ├── data_lifecycle
│   ├── integration_hub
│   └── extension_assembly
├── Official Optional Business Foundation
│   ├── organization_structure
│   ├── reference_data
│   ├── managed_files/document infrastructure
│   ├── case_management
│   └── data_exchange
└── Extensions outside the base
    ├── SaaS control plane
    ├── ERP functional modules
    └── application-specific derived repositories

The exact admission category of every new top-level module remains subject to docs/awcms-mini/21_module_admission_governance.md and an ADR/admission decision before implementation.

Non-negotiable guardrails

• Preserve the modular monolith as the default deployable; no premature microservices.
• Preserve the trusted static registry; no runtime plugin upload/install, marketplace, eval, or arbitrary code execution.
• Derived applications must not directly edit the base module registry after build-time assembly is available.
• Tenant remains the security boundary. Legal entity and organization unit are business scopes, not substitutes for tenant isolation.
• Tenant-scoped tables use tenant_id, ENABLE + FORCE RLS, tenant-first indexes, default-deny ABAC, and least-privilege DB roles.
• External provider calls remain optional, timeout-bounded, and outside database transactions.
• Offline/LAN-first profiles must continue to work with online/provider capabilities disabled.
• No direct shared-table writes across module ownership boundaries; use capability ports, APIs, or versioned events.
• Posted transactions remain immutable; corrections use reversal/compensation.
• No Platform Masjid, Jualanku.info, POS, marketplace, finance ledger, inventory valuation, payroll, tax, or other vertical business logic in the base.

Planned implementation waves

Wave 1 — prerequisites for many derived repositories

• Architecture boundaries and extraction criteria.
• Deterministic build-time module assembly.
• Derived compatibility manifest/test kit.
• Transactional domain-event runtime.
• Deployment-aware database/work-class capacity.
• Representative load/soak/query-plan regression suite.
• High-volume data lifecycle foundation.

Wave 2 — enterprise security and process

• Business-scope assignments and segregation-of-duties hooks.
• Enterprise workflow minimum.
• Canonical party/profile completion.
• Optional organization structure.

Wave 3 — reusable business infrastructure

• Effective-dated reference data.
• Generic document infrastructure and numbering.
• Staged data exchange.
• Reporting read models/projections.
• Integration hub.

Wave 4 — expansion contracts

• ERP extension readiness contracts.
• SaaS control-plane work only after Wave 1 contracts and compatibility gates are stable.

Evidence-gated work not created yet

The following must not be implemented merely because they are fashionable:

• tenant-safe distributed cache;
• service extraction/microservices;
• sharding or tenant placement/migration automation.

Create separate issues only after benchmarks or operational evidence prove the need, with an ADR, data-ownership plan, cutover, rollback, and no-dual-write strategy.

Epic completion criteria

• Derived repositories can compose application modules without editing src/modules/index.ts in the base.
• Base/derived semantic and capability compatibility is verified automatically.
• Transactional domain events have provider-neutral dispatch, idempotent consumers, retries, replay, ordering rules, and dead-letter handling.
• Horizontal connection/work-class budgets are validated against approved PostgreSQL/PgBouncer capacity.
• Load, soak, burst, large-data/RLS, and query-plan regression evidence is reproducible across releases.
• High-volume table lifecycle policies support retention, partitioning, archive checksum, legal hold, dry-run, safe batching, resume, and metrics.
• Reusable business-scope, workflow, party, organization, reference-data, document, exchange, reporting, and integration contracts are implemented or explicitly deferred through admission review.
• ERP contracts are documented and tested through an external example extension without adding accounting/inventory/payroll tables to the base.
• OpenAPI/AsyncAPI, migrations, tests, ADRs, ERD/data dictionary, deployment/security/backup/runbooks, repository inventory, and changesets remain synchronized.
• bun run check, relevant PostgreSQL integration tests, E2E tests, performance suites, security readiness, and a non-production preflight pass.

Standards and controls

Implementation should map practical controls to UU PDP, UU ITE, PP 71/2019, ISO/IEC 27001/27002/27005/27017/27018/27034/27701, ISO/IEC 20000-1, ISO 22301, ISO/IEC 15408 as an assurance reference, OWASP ASVS/API Security Top 10, NIST CSF, and CIS Controls without claiming certification.