Module Extraction Path

Notty modules are separated in layers. Module contracts live in @notty/module-api, first-party module packages define the product package boundary, and @notty/modules keeps a static capability catalog so the server can resolve editions without installing every commercial package. Most HTTP routes still run in @notty/server; extracted runtime services use explicit host adapters so route contracts can remain stable while ownership moves out module by module.

Current Boundary

Layer	Package	Responsibility
Contract	@notty/module-api	Manifest type, registry checks, load order
Extracted modules	@notty/module-*	First-party manifests, feature ownership, route/scope gates and extracted services
Catalog aggregator	@notty/modules	Static capability catalog, compatibility exports, registry creation
Runtime host	@notty/server	License resolution, capability enforcement, route shell and host adapters
Admin client	@notty/admin	Capability-aware navigation and settings locks

Rules

• Core security, auth safety, schema integrity and patch paths stay in Core.
• Commercial modules own business capability, not shared infrastructure.
• Every gated route or service must map to a FeatureKey or ModuleKey.
• Admin navigation should hide unavailable commercial surfaces outside the Platform settings page, while server-side gates remain authoritative.
• Add-ons must be disabled by default unless included by edition, config override or license claim.

Extraction Workflow

1. Add feature, route and scope gates before moving implementation code.
2. Create a focused package such as @notty/module-workflow.
3. Move the module manifest into that package and export it as the package boundary.
4. Update @notty/modules catalog metadata and the matching edition package dependencies.
5. Move only that module's service implementation and tests when the manifest boundary is stable.
6. Keep stable exports and route contracts unchanged.
7. Update @notty/server to import module implementation through the stable package boundary.
8. Run package type-check, server tests and admin lock tests before extracting the next module.

Extraction Status

Module	Package	Status
core.cms	@notty/module-cms	Manifest package extracted; core CMS runtime remains host-owned
core.developer	@notty/module-developer	Manifest package extracted; plugin/admin-extension runtime remains host-owned
pro.production	@notty/module-production	Manifest package extracted; preview-token and backup services extracted behind server host adapters
business.workflow	@notty/module-workflow	Manifest package extracted; server workflow routes remain host-owned
business.operations	@notty/module-operations	Manifest package extracted; server operations routes remain host-owned
business.compliance	@notty/module-compliance	Manifest package extracted; server compliance routes remain host-owned
business.ai	@notty/module-ai	Manifest package extracted; server AI routes remain host-owned
business.plugin-trust	@notty/module-plugin-trust	Manifest package extracted; server plugin trust checks remain host-owned
enterprise.auth	@notty/module-enterprise-auth	Manifest package extracted; server SSO/SCIM routes remain host-owned
enterprise.scale	@notty/module-enterprise-scale	Manifest package extracted; server tenant/workspace routes remain host-owned
enterprise.deployment	@notty/module-enterprise-deployment	Manifest package extracted; deployment controls are package-owned in policy
commerce.bundle	@notty/module-commerce	Add-on manifest package extracted
portal.bundle	@notty/module-portal	Add-on manifest package extracted

Host Adapter Pattern

Extracted runtime services must not import @notty/server internals directly. The module package owns business behavior and receives host capabilities through a narrow adapter.

For @notty/module-production, preview tokens and backups use this boundary:

1. @notty/module-production exports createPreviewTokenService(adapter).
2. @notty/module-production exports createBackupService(adapter).
3. The adapters expose dialect, DDL, query and execute functions.
4. Domain-specific host capabilities stay explicit: backups receive import/export, audit, alert and cron-validation callbacks from @notty/server.
5. @notty/server/src/lib/preview-tokens.ts and @notty/server/src/lib/backup.ts bind the adapters to the existing server helpers.
6. Server routes keep importing ~/lib/preview-tokens and ~/lib/backup, so HTTP contracts remain unchanged.

The next runtime extraction target should be selected by commercial isolation value. Good candidates are SSO/SCIM (@notty/module-enterprise-auth), releases/assignments (@notty/module-workflow) or operational jobs/alerts (@notty/module-operations).

Runtime Extraction Queue

Candidate	Reason
enterprise.auth	SSO/SCIM is commercially distinct and already gated
business.workflow	Releases, assignments and editorial collaboration have a clear domain boundary
business.operations	Jobs, alerts, webhooks and delivery observability are already grouped
enterprise.scale	Tenant/workspace/quotas require strict runtime boundaries
Vertical add-ons	commerce.bundle and portal.bundle are already optional package boundaries

Done Criteria Per Module

• Manifest includes all module features and route/scope gates.
• Disabled module returns HTTP 402 in strict mode at route and service boundaries.
• Observe mode keeps compatibility and emits gate headers.
• Admin navigation/settings hide unavailable surfaces except for the Platform edition/module overview.
• Package exports are stable and documented.
• Tests cover enabled, locked, disabled and dependency-blocked states.