+ );
+}
+```
+
+---
+
+## Known Issues & Risks
+
+### 1. Guard logic duplication
+
+Section wrappers must replicate guard logic that currently lives in parent page components. Two sources of truth.
+
+**Examples:**
+
+- `DeleteSection` renders unconditionally — the guard `user.deleteSelfEnabled` lives only in `SecurityPage.tsx:25`. The section wrapper must add this guard.
+- `PasskeySection` visibility depends on `shouldAllowIdentificationCreation` from `useUserProfileContext()` — computed in `SecurityPage.tsx:23`, not in the section itself.
+- AccountPage computes `isEmailImmutable`, `isPhoneImmutable`, `isUsernameImmutable` from `useUserProfileContext().immutableAttributes` and passes derived props (`shouldAllowCreation`, `shouldAllowDeletion`) to child sections.
+
+**Risk:** If a guard changes in the page component (portal path), the section wrapper (composed path) drifts silently. No shared code, no compile-time check.
+
+**Mitigation options:**
+
+- Extract shared `useSectionConfig()` hooks that both the page component and the section wrapper call.
+- Move guards into the section components themselves (bigger refactor, changes portal path behavior).
+
+### 2. CardState scoping is inconsistent across sections
+
+Sections fall into three categories, each with different error display behavior:
+
+| Category | Sections | Error behavior |
+| ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| **Self-contained** (own `withCardStateProvider` + own `Card.Alert`) | `ConnectedAccountsSection`, `Web3Section`, `EnterpriseAccountsSection` | Errors display inside the section. Page-level `Card.Alert` never sees them. |
+| **Parent-dependent** (no provider, calls `useCardState()`) | `EmailsSection`, `PhoneSection`, `MfaSection` | Errors bubble to the nearest `CardStateProvider` — currently the page's. |
+| **No card state** | `UserProfileSection`, `UsernameSection`, `PasswordSection`, `PasskeySection`, `ActiveDevicesSection`, `DeleteSection` | No error interaction at the section level. |
+
+**The problem:** When `Page` provides chrome (children mode), it wraps everything in a `CardStateProvider` + renders `Card.Alert`. This works for parent-dependent sections (emails, phone, mfa) — their errors show in the page alert. But self-contained sections (connected accounts, web3) have their own provider, so errors display in duplicate locations OR only inside the section.
+
+**Worse:** If a parent-dependent section like `EmailsSection` is rendered WITHOUT a parent `CardStateProvider` (e.g., directly under `Provider` without a `Page`), `useCardState()` will throw.
+
+**Decision needed:** Should we require all sections to be self-contained? Or enforce that sections only render inside a `Page`?
+
+### 3. Org section components are private
+
+All four section components in `OrganizationGeneralPage.tsx` are unexported module-private `const`s:
+
+- `OrganizationProfileSection` (line 88)
+- `OrganizationDomainsSection` (line 137)
+- `OrganizationLeaveSection` (line 186)
+- `OrganizationDeleteSection` (line 232)
+
+We need to export them for the section registry. This changes the module's public API surface.
+
+### 4. Org leave/delete forms depend on navigation callback
+
+`ActionConfirmationPage.tsx:22` reads `useOrganizationProfileContext().navigateAfterLeaveOrganization` — a callback that navigates away after the user leaves or deletes an org. In the portal path, this navigates to a different route. In the composed path, there's no route to navigate to.
+
+**Decision needed:** What should happen after leaving/deleting an org in the composed path? Callback prop on `Provider`? No-op? The current `OrganizationProfileProvider` doesn't provide `navigateAfterLeaveOrganization`.
+
+### 5. `useUserProfileContext()` is expensive
+
+The hook (`contexts/components/UserProfile.ts`) calls `useSubscription()`, `useStatements()`, and computes `pages` (navbar routes) on every render. Every section wrapper that needs a simple boolean like `shouldAllowIdentificationCreation` triggers all of this.
+
+In the portal path this is fine — the page component calls it once. In the composed path with N independent section wrappers, it's called N times per render.
+
+**Mitigation:** Extract the guard-related values into a lighter hook (e.g., `useUserProfileGuards()`) that doesn't pull billing data or page routes.
+
+### 6. Billing sections only work inside billing Page
+
+Billing sections call `navigate('plans')`, `navigate('statement/${id}')`, etc. These are handled by `useBillingRouter` which only exists when `` is the parent.
+
+If someone puts `` under ``:
+
+- `PageContext` says "account", so the section registry lookup would fail (subscriptions isn't an account section) → renders null. This is the designed behavior (Rule 4).
+
+But if someone puts billing sections under `` without children (passthrough mode), the existing BillingPage with tabs renders — section composition is ignored. Need to document this clearly.
+
+### 7. StrictMode compatibility
+
+We already found that `useSafeState` (used by `useLoadingStatus`) breaks in React 18 StrictMode (the `isMountedRef` is never reset after remount). We fixed it, but other hooks may have similar patterns. Each section that uses form submission, loading states, or action menus could be affected. The portal path doesn't use StrictMode, so these bugs only surface in the composed path.
+
+**The composed playground uses ``.** Any host app might too. We should audit `useSafeState` consumers for similar issues.
+
+---
+
+## Verification
+
+1. **Default rendering**: `` renders identically to current ``
+2. **Section omission**: `` renders only the profile section
+3. **Custom content**: Non-Section children render inline between sections
+4. **Environment guards**: Sections hidden by dashboard config render nothing even when explicitly declared
+5. **Atomic pages**: Billing tabs, sub-navigation (plans, statements, payments) all work
+6. **Error handling**: Section errors surface via `useCardState()` (available when page provides CardStateProvider)
+7. **Existing tests**: `pnpm turbo test --filter=@clerk/ui` — all portal-path tests pass unchanged
+8. **Playground**: Update `playground/composed/` to exercise all patterns above
diff --git a/packages/ui/package.json b/packages/ui/package.json
index e6a695bb706..d97953e8ec4 100644
--- a/packages/ui/package.json
+++ b/packages/ui/package.json
@@ -50,6 +50,11 @@
"import": "./dist/themes/experimental.js",
"default": "./dist/themes/experimental.js"
},
+ "./experimental": {
+ "types": "./dist/experimental/index.d.ts",
+ "import": "./dist/experimental/index.js",
+ "default": "./dist/experimental/index.js"
+ },
"./themes/shadcn.css": "./dist/themes/shadcn.css",
"./register": {
"import": {
diff --git a/packages/ui/src/components/OrganizationProfile/OrganizationBillingPage.tsx b/packages/ui/src/components/OrganizationProfile/OrganizationBillingPage.tsx
index fe8018cd709..bbf10255b39 100644
--- a/packages/ui/src/components/OrganizationProfile/OrganizationBillingPage.tsx
+++ b/packages/ui/src/components/OrganizationProfile/OrganizationBillingPage.tsx
@@ -28,7 +28,7 @@ const OrganizationBillingPageInternal = withCardStateProvider(() => {