CRM — module-ownership case study

CRM is a playground/case-study service for the module-ownership architecture — not a business product module. It proves that a microservice can own its own navigation, route prefixes and translations through service registration. It will eventually be split out into a standalone product.

What it does today

• Declares the crm root level (partOf: "crm" — the CRM module IS its own root level, unlike the system services).
• Owns the /crm route prefix: /crm/customers, plus an extra root-level membership under system (/system/crm/pipeline — "a foot in two shoes").
• Registers CRM_NAV (nav-declaration.ts) via service_registry.endpoints.nav.
• Translates its own module label (labelKey: "crm.module.name") in the crm.translations namespace.

The customer entity pages stay BE-served for now — route declarations reference entity customer rendered by the FE metadata pipeline. Entity API ownership migrates to this service in a later phase.

Boundaries

• No HTTP controllers and no NATS subscribers — the service registers metadata only (nav, translations, route census).
• DB ownership: owns its own db-meta/ (signed MANIFEST.json, keys.json, patches/ — e.g. 0002_seed_config.sql seeds http_port and sibling config entries).
• Root level crm is distinct from system: service_registry.part_of separates the two domains (see overview.mdx).

Configuration

• Port: 3007 (config_entries.http_port, seeded by 0002_seed_config.sql).
• Env policy: DATABASE_URL + DATABASE_SCHEMA only (see docs/ai/env-policy.md); everything else lives in config_entries.
• Dev: bun --hot src/index.ts from primebrick-us-v3/crm/.

Adapters

• ConfigRepositoryAdapter — config_entries governance.
• HealthCheckAdapter, CrmAuthConfigPort — SDK lifecycle ports.