Group B fixes

src/app/[locale]/dashboard/new/page.tsx

@@ -3,6 +3,9 @@ import { getTranslations } from "next-intl/server";
 import { redirect } from "next/navigation";
 import { OnboardingFlow } from "@/components/onboarding/onboarding-flow";
 import { BackLink } from "@/components/ui/back-link";
+import { listTenants } from "@/lib/k8s";
+import { listActiveTenantRequestsByOrgId } from "@/lib/db";
+import { personalAccountAtCapacity } from "@/lib/personal-org";
 
 /**
  * /dashboard/new — wizard for creating an additional instance for an
@@ -21,6 +24,10 @@ import { BackLink } from "@/components/ui/back-link";
  * may create new instances. The server-side POST handler enforces the
  * same; this redirect is purely UX so /user-role members don't land on
  * a wizard that will 403 on submit.
+ *
+ * Bug 5: personal accounts that already hold a tenant or have one
+ * in-flight are sent back to the dashboard with the same UX rationale.
+ * Matching API guard lives in `/api/onboarding`.
  */
 export default async function NewInstancePage() {
   const user = await getSessionUser();
@@ -28,6 +35,25 @@ export default async function NewInstancePage() {
   if (user.isPlatform) redirect("/dashboard");
   if (!canMutate(user)) redirect("/dashboard");
 
+  if (user.isPersonal) {
+    const [allTenants, activeRequests] = await Promise.all([
+      listTenants(),
+      listActiveTenantRequestsByOrgId(user.orgId),
+    ]);
+    const ownTenants = allTenants.filter(
+      (t) => t.metadata.labels?.["pieced.ch/zitadel-org-id"] === user.orgId
+    );
+    if (
+      personalAccountAtCapacity(
+        user.isPersonal,
+        ownTenants.length,
+        activeRequests.length
+      )
+    ) {
+      redirect("/dashboard");
+    }
+  }
+
   const t = await getTranslations("dashboard");
 
   return (
@@ -43,7 +69,11 @@ export default async function NewInstancePage() {
       </div>
 
       <div className="animate-in animate-in-delay-1">
-        <OnboardingFlow orgName={user.orgName} />
+        <OnboardingFlow
+          orgName={user.orgName}
+          userName={user.name}
+          userEmail={user.email}
+        />
       </div>
     </div>
   );

src/app/[locale]/dashboard/page.tsx

@@ -8,6 +8,7 @@ import {
   canSeeInflightRequests,
   isUserScoped,
 } from "@/lib/visibility";
+import { personalAccountAtCapacity } from "@/lib/personal-org";
 import { Card, CardHeader } from "@/components/ui/card";
 import { StatusBadge } from "@/components/ui/status-badge";
 import { OnboardingFlow } from "@/components/onboarding/onboarding-flow";
@@ -179,7 +180,17 @@ export default async function DashboardPage() {
   // the admin panel anyway) see the "Create new instance" link. A
   // `user`-role member sees the dashboard but not the create flow —
   // they need to ask an owner.
-  const canCreate = canMutate(user);
+  //
+  // Bug 5: personal accounts are 1-instance by design. Once a personal
+  // account has either an active tenant OR an in-flight request, the
+  // create button must disappear. The matching server-side guard is
+  // in `/api/onboarding` so direct POSTs are also rejected.
+  const personalAtCapacity = personalAccountAtCapacity(
+    user.isPersonal,
+    orgScopedTenants.length,
+    inflightRequests.length
+  );
+  const canCreate = canMutate(user) && !personalAtCapacity;
 
   // First-time / no-visibility branch.
   //
@@ -262,7 +273,11 @@ export default async function DashboardPage() {
         </div>
 
         <div className="animate-in animate-in-delay-1">
-          <OnboardingFlow orgName={user.orgName} />
+          <OnboardingFlow
+            orgName={user.orgName}
+            userName={user.name}
+            userEmail={user.email}
+          />
         </div>
       </div>
     );

src/app/[locale]/register/page.tsx

@@ -8,11 +8,13 @@ import { Card } from "@/components/ui/card";
 type FormState = "idle" | "submitting" | "success" | "error";
 
 /**
- * Slice 4: a "Register as individual" toggle distinguishes personal
- * accounts from company registrations. When the toggle is on:
+ * Slice 4 + Bug 9: a "Register as individual" toggle distinguishes
+ * personal accounts from company registrations. When the toggle is on:
  *   - the company name field is hidden (and not sent)
  *   - the server skips the duplicate-domain check
- *   - the ZITADEL org is named "{givenName} {familyName} (Personal)"
+ *   - the ZITADEL org is named `personal-{8hex}` (opaque, collision-free)
+ *   - the user's display name lives only on the user record; the GUI
+ *     shows it instead of the opaque org name everywhere
  */
 export default function RegisterPage() {
   const t = useTranslations("register");
@@ -40,8 +42,8 @@ export default function RegisterPage() {
 
     try {
       // Build the request body explicitly. For personals we omit
-      // companyName so the server knows to derive the org name from
-      // the user's full name. The Zod schema accepts the omission.
+      // companyName so the server generates an opaque ZITADEL org name
+      // (`personal-{8hex}`); the Zod schema accepts the omission.
       const body: Record<string, unknown> = {
         givenName: form.givenName,
         familyName: form.familyName,

src/app/[locale]/team/page.tsx

@@ -21,6 +21,12 @@ export default async function TeamPage() {
   const user = await getSessionUser();
   if (!user) redirect("/login");
   if (!canMutate(user)) redirect("/dashboard");
+  // Bug 8: personal accounts have no team to manage. The page is
+  // structurally meaningless and the invite form would create extra
+  // ZITADEL users in a single-user org. Redirect cleanly. The matching
+  // API guards in `/api/team` and `/api/team/invite` enforce the same
+  // rule on direct calls.
+  if (user.isPersonal) redirect("/dashboard");
 
   const t = await getTranslations("team");
   const tDashboard = await getTranslations("dashboard");

src/app/[locale]/tenants/[name]/page.tsx

@@ -40,6 +40,19 @@ export default async function TenantDetailPage({
   // the same page but with edit controls hidden / fields read-only.
   const canEdit = canMutate(user);
 
+  // Bug 7: assigned-users panel is meaningless for personal tenants
+  // (sole-owner by definition; the only "assignee" is the owner
+  // themselves). We hide the panel when EITHER the CR carries the
+  // `pieced.ch/personal=true` label (set at approve time for new
+  // personal tenants) OR the viewer is on a personal account (covers
+  // legacy tenants approved before the label was added; the customer
+  // sees their own personal tenant). Platform admins viewing a legacy
+  // unlabeled personal tenant are the only case where this falls
+  // through to "show panel" — operators can `kubectl label` to fix.
+  const isPersonalTenant =
+    tenant.metadata.labels?.["pieced.ch/personal"] === "true" ||
+    user.isPersonal;
+
   const enabledPackages = tenant.spec.packages || [];
   const workspaceFiles = tenant.spec.workspaceFiles || {};
   const enabledChannels = enabledPackages.filter((pkg) =>
@@ -132,13 +145,16 @@ export default async function TenantDetailPage({
 
       {/* Slice 7: Assigned users — visible to anyone who can see the
           tenant, editable only by owners/platform users. The component
-          fetches its own data so the page doesn't need to await. */}
-      <section className="mt-8 animate-in animate-in-delay-4">
-        <h2 className="text-xs font-semibold uppercase tracking-wider text-text-muted mb-3">
-          {t("assignedUsers")}
-        </h2>
-        <AssignedUsersPanel tenantName={name} canEdit={canEdit} />
-      </section>
+          fetches its own data so the page doesn't need to await.
+          Bug 7: hidden entirely for personal tenants. */}
+      {!isPersonalTenant && (
+        <section className="mt-8 animate-in animate-in-delay-4">
+          <h2 className="text-xs font-semibold uppercase tracking-wider text-text-muted mb-3">
+            {t("assignedUsers")}
+          </h2>
+          <AssignedUsersPanel tenantName={name} canEdit={canEdit} />
+        </section>
+      )}
     </div>
   );
 }