Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/prisma/schema.prisma, line 298:

<comment>OrganizationRule↔OrganizationTeam relation does not enforce same-organization links, allowing cross-tenant associations.</comment>

<file context>
@@ -219,35 +219,113 @@ model EmailAccount {
+  actions OrganizationRuleAction[]
+
+  // teams this rule applies to; empty means it applies to all members
+  teams OrganizationTeam[]
+
+  managedRules Rule[]
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/prisma/schema.prisma, line 249:

<comment>Member.team relation is missing same-organization enforcement, so cross-org team assignments are possible at the DB level.</comment>

<file context>
@@ -219,35 +219,113 @@ model EmailAccount {
+  organization           Organization      @relation(fields: [organizationId], references: [id], onDelete: Cascade)
+  emailAccount           EmailAccount      @relation(fields: [emailAccountId], references: [id], onDelete: Cascade)
+  teamId                 String?
+  team                   OrganizationTeam? @relation(fields: [teamId], references: [id], onDelete: SetNull)
 
   @@unique([organizationId, emailAccountId])
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/organizations/organization-rules.ts, line 262:

<comment>Duplicate-name conflicts are treated as a permanent skip instead of retrying and applying a deterministic fallback name, so targeted members can remain without a managed org rule indefinitely.

(Based on your team's feedback about org-rule duplicate-name handling with deterministic fallback.) .</comment>

<file context>
@@ -0,0 +1,302 @@
+    });
+    return { status: "created" };
+  } catch (error) {
+    if (isDuplicateError(error, "name")) {
+      return {
+        status: "skipped",
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx, line 168:

<comment>Organization-managed rules are still openable via row click into an editable RuleDialog, leaving an edit/delete path despite the new menu/toggle locks.</comment>

<file context>
@@ -164,6 +165,7 @@ export function Rules({
               <TableBody>
                 {rules.map((rule) => {
                   const isPlaceholder = rule.id.startsWith("placeholder-");
+                  const isOrganizationManaged = !!rule.organizationRuleId;
 
                   return (
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/prisma/migrations/20260609120000_add_organization_rules/migration.sql, line 93:

<comment>`Rule.organizationRuleId` FK lacks organization scoping, allowing cross-organization references.</comment>

<file context>
@@ -0,0 +1,100 @@
+ALTER TABLE "OrganizationRuleAction" ADD CONSTRAINT "OrganizationRuleAction_organizationRuleId_fkey" FOREIGN KEY ("organizationRuleId") REFERENCES "OrganizationRule"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "Rule" ADD CONSTRAINT "Rule_organizationRuleId_fkey" FOREIGN KEY ("organizationRuleId") REFERENCES "OrganizationRule"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/actions/organization.ts, line 384:

<comment>This introduces a non-atomic remove flow: the member is deleted before managed-rule cleanup, so cleanup failure throws after irreversible deletion. Wrap both operations in a transaction or make cleanup best-effort in a deferred/background path to avoid partial-success errors.</comment>

<file context>
@@ -358,6 +380,11 @@ export const removeMemberAction = actionClientUser
 
     await prisma.member.delete({ where: { id: memberId } });
+
+    await removeOrganizationRulesForMember({
+      emailAccountId: targetMember.emailAccountId,
+      organizationId: targetMember.organizationId,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/actions/organization-rule.validation.ts, line 118:

<comment>`teamId` accepts empty strings, which bypasses team existence checks and can trigger DB foreign-key errors instead of clean validation failures.</comment>

<file context>
@@ -0,0 +1,120 @@
+
+export const updateMemberTeamBody = z.object({
+  memberId: z.string().min(1, "Member ID is required"),
+  teamId: z.string().nullable(),
+});
+export type UpdateMemberTeamBody = z.infer<typeof updateMemberTeamBody>;
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/actions/organization-rule.ts, line 85:

<comment>Toggle updates parent and managed copies in separate non-transactional writes, which can leave inconsistent enabled state if the second write fails.</comment>

<file context>
@@ -0,0 +1,320 @@
+      await assertTeamsBelongToOrganization({ organizationId, teamIds });
+
+      try {
+        await prisma.organizationRule.update({
+          where: { id },
+          data: {
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/organizations/organization-rules.ts, line 185:

<comment>Member-level org-rule sync drops the apply result, so skipped/failed rule applications are silently ignored and the completion log can falsely imply successful sync.</comment>

<file context>
@@ -0,0 +1,302 @@
+  }
+
+  for (const organizationRule of applicableRules) {
+    await applyOrganizationRuleToAccount({
+      organizationRule,
+      emailAccountId,
</file context>