docs: define customer release branch policy

CONTRIBUTING.md

@@ -14,9 +14,26 @@ If you change architecture, deployment flow, or operational behavior, update the
 - `develop`: active integration branch
 - `main`: stable branch for production promotion
 - short-lived feature branches: branch from `develop`, merge back into `develop`
+- customer release branches: branch from `main` for a frozen customer line when a customer must not receive future feature work automatically
 
 Do not use `main` as the default development branch.
 
+### Customer release policy
+For customer-specific deliveries such as TUBCO, use a dedicated release branch from the current stable line.
+
+Recommended pattern:
+- `release/tubco-v1`: customer maintenance branch
+- `tubco-baseline-2026-03`: baseline tag taken from the same stable point
+
+Rule:
+- new product features continue on `develop`
+- customer release branches only receive approved:
+  - bug fixes
+  - security updates
+  - UI improvements
+
+Do not let a customer deployment track `develop` directly.
+
 ## Current Delivery Model
 - GitHub Actions is used for CI
 - the current test server is local/LAN-only

backend/workflows/templates/workflows/developer_handbook.html

@@ -79,6 +79,7 @@
         <li><code>develop</code> is the active integration branch.</li>
         <li><code>main</code> is the stable branch intended for production promotion.</li>
         <li>Feature work should start from <code>develop</code> and merge back into <code>develop</code>.</li>
+        <li>Customer release branches should start from <code>main</code> when a customer must not receive future feature work automatically.</li>
       </ul>
     </div>
     <div class="box">
@@ -93,6 +94,24 @@
         <li>promote <code>develop</code> into <code>main</code> when stable</li>
       </ol>
     </div>
+    <div class="box">
+      <h3>Customer release branches</h3>
+      <p>Use a dedicated release branch when a customer should receive the current stable product line but not future features by default.</p>
+      <ul>
+        <li>Example branch: <code>release/tubco-v1</code></li>
+        <li>Example baseline tag: <code>tubco-baseline-2026-03</code></li>
+        <li>Base the branch on the current <code>main</code>.</li>
+        <li>Continue product work on <code>develop</code>.</li>
+        <li>Only backport approved:
+          <ul>
+            <li>bug fixes</li>
+            <li>security updates</li>
+            <li>UI improvements</li>
+          </ul>
+        </li>
+      </ul>
+      <p>This keeps the customer line stable while the main product keeps evolving.</p>
+    </div>
 
     <h2 id="local">4) Local Development Workflow</h2>
     <h3>Start</h3>

backend/workflows/tests/test_app_registry_permissions.py

@@ -1,5 +1,6 @@
 from django.contrib.auth import get_user_model
 from django.test import TestCase
+from django.urls import reverse
 
 from workflows.app_registry import build_portal_app_sections, ensure_portal_app_configs
 from workflows.models import PortalAppConfig
@@ -48,3 +49,17 @@ class AppRegistryPermissionTests(TestCase):
         self.assertNotIn('requests_dashboard', self._visible_keys(self.staff))
         self.assertIn('requests_dashboard', self._visible_keys(self.it_staff))
 
+    def test_super_admin_cannot_open_platform_owner_app_registry_page(self):
+        self.client.force_login(self.super_admin)
+
+        response = self.client.get(reverse('portal_app_registry_page'))
+
+        self.assertEqual(response.status_code, 302)
+        self.assertEqual(response.url, reverse('home'))
+
+    def test_platform_owner_can_open_app_registry_page(self):
+        self.client.force_login(self.platform_owner)
+
+        response = self.client.get(reverse('portal_app_registry_page'))
+
+        self.assertEqual(response.status_code, 200)