Runtime Package Map

Rule

Runtime packages should follow business boundaries first and shared infrastructure second.

Top-level runtime domains

Keep these as separate top-level domains:

• runtime/apps
• runtime/giving
• runtime/content
• runtime/growth
• runtime/workspaces
• runtime/auth

Shop domain

The core commerce business workflow now lives under runtime/shop/*.

Current shop modules:

• catalog
• products
• checkout
• orders
• fulfillment
• shipping
• tax

These are one app boundary.

Shared infrastructure under or beside app domains

These are not top-level apps:

• payments
• payment links
• provider adapters
• files
• notifications
• jobs

Current shared monetization/runtime infrastructure includes:

• runtime/monetization/payments
• runtime/monetization/paymentlinks
• runtime/monetization/subscriptions
• runtime/monetization/provideraccounts

These should support app domains without redefining them.

Subscriptions

Split recurring concerns by meaning:

• tenant SaaS billing stays in platform control
• recurring commerce stays with shop
• broader membership or access workflows can become their own app domain later

A future subscriptions app is acceptable only as an operator-facing surface over recurring agreements and invoices.

Target shape

The runtime package map should stay:

• runtime/shop/* for commerce business workflow
• runtime/giving/* for donor workflow
• shared monetization infrastructure beneath app domains

There should be no remaining top-level runtime/commerce/* boundary.

Do not create top-level pseudo-app packages for:

• products
• categories
• orders
• payments
• tax
• shipping