Plan Gating

Phase 1 rule

Plan gating stays app-level first.

That means:

• plans include apps
• apps resolve into runtime/admin surfaces
• built-in modules come with the app

This keeps plan composition legible.

Why not gate modules first

If modules become primary entitlement units too early:

• plans become noisy
• UI state becomes harder to explain
• registry rows turn into implementation fragments
• operators lose a clean mental model

That is exactly the complexity the refactor was meant to remove.

When module or extension gating is acceptable

Later gating is appropriate for:

• advanced admin capabilities
• optional extensions
• high-value add-ons
• marketplace-style attachments

Examples:

• shop included in plan
• shop advanced shipping extension gated separately
• giving included independently from shop
• a future subscriptions operator app included independently if it becomes a real business surface

Runtime/UI rule

Presentation hints never affect entitlement.

Canonical runtime UI state remains:

• workspace_state
• reason_code

Presentation hints only affect:

• sidebar visibility
• switcher visibility
• preferred entry route