From a2643f36b09a4e3e30a8daee9a4b71b11ed4b132 Mon Sep 17 00:00:00 2001
From: Guilhem Lemouel <guilhemlemouel@gmail.com>
Date: Tue, 13 Oct 2026 07:00:31 -0700
Subject: [PATCH] fix: hold the fork page for operators until the rulesets load

On a direct load the rulesets arrive after the first render, so an operator
allowed by AllowOperatorForking briefly saw the Unauthorized alert.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---
 .../(root)/(logged)/user/(user)/fork_workspace/+page.svelte   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/frontend/src/routes/(root)/(logged)/user/(user)/fork_workspace/+page.svelte b/frontend/src/routes/(root)/(logged)/user/(user)/fork_workspace/+page.svelte
index 8006259eb2..e98bedd212 100644
--- a/frontend/src/routes/(root)/(logged)/user/(user)/fork_workspace/+page.svelte
+++ b/frontend/src/routes/(root)/(logged)/user/(user)/fork_workspace/+page.svelte
@@ -15,7 +15,9 @@
 <!-- The form is reachable by URL whatever the pickers show. Only operators are refused here: the
      server refuses their fork unless a ruleset carries `AllowOperatorForking`, and a developer
      blocked by `DisableWorkspaceForking` gets the server's ruleset message instead. -->
-{#if $userStore?.operator && !canCreateFork($userStore)}
+{#if $userStore?.operator && !protectionRulesState.rulesets}
+	<!-- Until the rulesets arrive, `AllowOperatorForking` reads as off. -->
+{:else if $userStore?.operator && !canCreateFork($userStore)}
 	<div class="p-4 mt-12">
 		<Alert type="error" title="Unauthorized">Page not available for operators</Alert>
 	</div>