Pin wrangler and supabase CLI as devDependencies

The last pipeline run failed on \`npx wrangler deploy\` with npm unable to
find wrangler@4.144.0 — a transient registry propagation gap right after
that version's release, not an actual config problem (it installs fine
moments later, confirmed locally). Both wrangler and the supabase CLI were
being fetched fresh via bare npx on every single pipeline run instead of
coming from the lockfile like every other dependency, which is exactly
what left CI exposed to whatever npm's registry happens to be doing at
that moment. Pinning them means npm ci resolves the exact locked version
every time, and npx picks up the local install instead of hitting the
registry at all.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017DUU6CnxECCDeqDNYJgr5x

.woodpecker.yml

@@ -5,8 +5,8 @@
 # Supabase project — never shares data with production). Production is
 # never touched automatically — promoting to it is a manual "Deploy" button
 # click on a main-branch pipeline run in the Woodpecker UI (Woodpecker's
-# deploy event), which is why deploy-production is gated on `event: deploy`
-# rather than `event: push`.
+# deployment event), which is why deploy-production is gated on
+# `event: deployment` rather than `event: push`.
 #
 # Debian-based node image (not Alpine) for every step: the Supabase CLI's
 # downloaded binary has had musl/Alpine compatibility issues in the past.
@@ -14,18 +14,29 @@
 # `npm ci` in the install step is enough for every later step to reuse.
 
 steps:
+  # Explicit event filter on these three (rather than the no-`when` default,
+  # which runs on every event Woodpecker knows about) because a deploy-time
+  # re-run of this pipeline is a `deployment` event, not `push` — install
+  # has to fire there too, or deploy-production's `npm run build` would run
+  # with no node_modules.
   - name: install
     image: node:22-bookworm
+    when:
+      - event: [push, deployment]
     commands:
       - npm ci
 
   - name: lint
     image: node:22-bookworm
+    when:
+      - event: [push, deployment]
     commands:
       - npm run lint
 
   - name: typecheck
     image: node:22-bookworm
+    when:
+      - event: [push, deployment]
     commands:
       - npx tsc -b
 
@@ -58,7 +69,7 @@ steps:
   - name: deploy-production
     image: node:22-bookworm
     when:
-      - event: deploy
+      - event: deployment
         branch: main
         evaluate: 'CI_PIPELINE_DEPLOY_TARGET == "production"'
     environment:

deployment-plan.md

@@ -121,7 +121,7 @@ revisited and simplified to auto-deploy staging instead.
 **Actual flow**: any push (any branch) runs lint + typecheck, then
 auto-deploys to a shared staging environment — no button needed. Production
 is never touched automatically; promoting to it is a manual **Deploy**
-button click (Woodpecker's built-in deploy event) on a `main`-branch
+button click (Woodpecker's built-in `deployment` event) on a `main`-branch
 pipeline run, typing `production` as the deploy target
 (`$CI_PIPELINE_DEPLOY_TARGET`). Requires **"Allow deployments"** enabled in
 the repo's Woodpecker project settings.

package.json

@@ -28,8 +28,10 @@
     "@types/uuid": "^10.0.0",
     "@vitejs/plugin-react": "^6.1.0",
     "oxlint": "^1.79.0",
+    "supabase": "^2.118.0",
     "tailwindcss": "^4.3.3",
     "typescript": "~6.0.2",
-    "vite": "^8.2.2"
+    "vite": "^8.2.2",
+    "wrangler": "^4.143.1"
   }
 }

site/index.html

@@ -24,8 +24,8 @@
           <a href="#library">Library</a>
         </div>
         <div class="nav-auth">
-          <a class="nav-login" href="https://app.diagrav.com/">Log in</a>
-          <a class="btn btn-primary btn-sm" href="https://app.diagrav.com/">Sign up</a>
+          <a class="nav-login app-link" href="https://app.diagrav.com/">Log in</a>
+          <a class="btn btn-primary btn-sm app-link" href="https://app.diagrav.com/">Sign up</a>
         </div>
       </div>
     </div>
@@ -158,7 +158,7 @@
       <div class="strip">
         <h2>Stop guessing which cable you need</h2>
         <p>Plan the wiring first. Buy the right cables once.</p>
-        <a class="btn btn-primary btn-lg strip-cta" href="https://app.diagrav.com/">Sign up</a>
+        <a class="btn btn-primary btn-lg strip-cta app-link" href="https://app.diagrav.com/">Sign up</a>
       </div>
     </div>
   </section>
@@ -170,5 +170,21 @@
     </div>
   </footer>
 
+  <script>
+    // site/ has no build step (served as-is, no per-environment templating),
+    // so the app links above are hardcoded to production in the markup —
+    // this is the one place that needs to differ on staging.diagrav.com,
+    // rewritten at load time rather than maintaining a second copy of this
+    // file. Defaults to production's app host for anything else (the real
+    // domain, a bare file preview, etc.) — the safe assumption everywhere
+    // that isn't specifically the staging hostname.
+    (function () {
+      var appHost = location.hostname === 'staging.diagrav.com' ? 'staging-app.diagrav.com' : 'app.diagrav.com';
+      document.querySelectorAll('.app-link').forEach(function (a) {
+        a.href = 'https://' + appHost + '/';
+      });
+    })();
+  </script>
+
 </body>
 </html>