docs: clarify standard ci cd model

DEPLOYMENT.md

@@ -7,6 +7,24 @@
 - GitHub Actions uploads the repository contents to the server over SSH
 - the server does not need GitHub access to deploy
 
+## Standard target model for later
+When this moves from an internal test setup to a more standard delivery model, the target should be:
+1. feature branch
+2. CI
+3. merge into `develop`
+4. staging deploy
+5. staging validation
+6. merge into `main`
+7. production deploy
+
+Recommended standards for that future state:
+- staging and production use separate hosts or clearly separated environments
+- staging and production use separate secrets
+- production deploys only from `main`
+- production runs with HTTPS and `DJANGO_DEBUG=0`
+- production deploys require environment protection or approval in GitHub
+- rollback is documented and tested
+
 This is intentional. For a private repository, server-side `git clone` adds unnecessary credential management.
 
 ## Branch strategy

backend/workflows/templates/workflows/developer_handbook.html

@@ -366,6 +366,16 @@ make backup-verify BACKUP_DIR=backups/backup_YYYYmmdd_HHMMSS</code></pre>
       </ul>
     </div>
 
+    <div class="box">
+      <h3>What is good enough today vs what is standard later</h3>
+      <ul>
+        <li><strong>Today:</strong> GitHub runs CI, then a LAN-connected Mac deploys to the private test server with the helper scripts.</li>
+        <li><strong>Standard later:</strong> GitHub runs CI, then an approved deploy job promotes tested code to staging and production automatically.</li>
+        <li><strong>Why they differ:</strong> the current test server is inside the LAN, so GitHub-hosted runners cannot reach it directly.</li>
+        <li><strong>When to upgrade:</strong> do it once staging or production lives on a public host, or once you add a self-hosted runner inside the LAN.</li>
+      </ul>
+    </div>
+
     <div class="box">
       <h3>Why deploy is manual right now</h3>
       <p>The test server is inside the local network and uses a private IP address <code>192.168.2.55</code>. GitHub-hosted runners on the public internet cannot reliably reach that target. Because of that, the correct deployment path today is:</p>
@@ -377,6 +387,34 @@ make backup-verify BACKUP_DIR=backups/backup_YYYYmmdd_HHMMSS</code></pre>
       <p>Automatic CD from GitHub becomes appropriate only after moving to a public server or using a self-hosted runner inside the LAN.</p>
     </div>
 
+    <div class="box">
+      <h3>Recommended standard CI/CD model</h3>
+      <ol>
+        <li>Keep one private repository.</li>
+        <li>Use short-lived feature branches from <code>develop</code>.</li>
+        <li>Require CI to pass before merge into <code>develop</code>.</li>
+        <li>Deploy <code>develop</code> to a staging environment.</li>
+        <li>Promote <code>develop</code> into <code>main</code> only after staging validation.</li>
+        <li>Deploy <code>main</code> to production behind HTTPS with <code>DEBUG=0</code>.</li>
+        <li>Protect production with GitHub environment approvals, production secrets, and rollback steps.</li>
+      </ol>
+      <p>If you want the most standard shape, the long-term target is:</p>
+      <pre><code>feature branch -> CI -> develop -> staging deploy -> validate -> main -> production deploy</code></pre>
+    </div>
+
+    <div class="box">
+      <h3>What to change when this becomes a standard deployment</h3>
+      <ol>
+        <li>Move staging and production onto hosts that GitHub or a self-hosted runner can reach reliably.</li>
+        <li>Keep separate env files and secrets for staging and production.</li>
+        <li>Run production with <code>DJANGO_DEBUG=0</code>, secure cookies, and HTTPS only.</li>
+        <li>Add GitHub environment protection rules for <code>development</code> and <code>production</code>.</li>
+        <li>Use the production deploy path only from <code>main</code>.</li>
+        <li>Add backup verification and health verification as standard post-deploy checks.</li>
+        <li>Later, consider image-based deploys if you want cleaner rollbacks than source-upload deploys.</li>
+      </ol>
+    </div>
+
     <div class="box">
       <h3>What to do for normal work</h3>
       <ol>
@@ -391,6 +429,15 @@ make backup-verify BACKUP_DIR=backups/backup_YYYYmmdd_HHMMSS</code></pre>
       </ol>
     </div>
 
+    <div class="box">
+      <h3>Decision guide</h3>
+      <ul>
+        <li><strong>Keep the current manual Mac deploy flow</strong> if the server stays private inside the LAN.</li>
+        <li><strong>Use a self-hosted GitHub runner</strong> if you want automated deploys but the server must stay private.</li>
+        <li><strong>Use GitHub-hosted deploy jobs</strong> once staging or production runs on a publicly reachable host or VPN-reachable target.</li>
+      </ul>
+    </div>
+
     <div class="box">
       <h3>One-command test deployment</h3>
       <p>From the Mac on the same network:</p>
@@ -448,6 +495,17 @@ make backup-verify BACKUP_DIR=backups/backup_YYYYmmdd_HHMMSS</code></pre>
       </ul>
     </div>
 
+    <div class="box">
+      <h3>Minimal standard checklist for later</h3>
+      <ul>
+        <li>Staging and production must not share secrets.</li>
+        <li>Production deploy must run from <code>main</code> only.</li>
+        <li>Production must have HTTPS, health checks, backups, and a documented rollback path.</li>
+        <li>Runtime config sync must stay explicit. Code deploys should not silently overwrite DB-backed config.</li>
+        <li>Every deploy path should end with a health check and a quick browser verification of critical flows.</li>
+      </ul>
+    </div>
+
     <div class="box">
       <h3>If the local deploy helper fails</h3>
       <ol>