WIP: pending changes — docs, webhook, nav/footer (committed per Sami request, not yet reviewed)

src/app/docs/troubleshooting/page.tsx

@@ -0,0 +1,40 @@
+import Navbar from '@/components/Navbar';
+import Footer from '@/components/Footer';
+import DocsLayout from '@/components/docs/DocsLayout';
+
+export default function DocsTroubleshootingPage() {
+  return (
+    <div className="flex min-h-screen flex-col bg-surface-950 text-surface-50">
+      <Navbar />
+      <DocsLayout
+        title="Troubleshooting"
+        intro="Because DashCaddy sits across runtime, DNS, reverse proxy, certificates, and dashboard state, the fastest way to debug it is layer by layer instead of guessing."
+      >
+        <h2>Debug order</h2>
+        <ol>
+          <li>backend process or container</li>
+          <li>service port reachability</li>
+          <li>reverse proxy route</li>
+          <li>DNS</li>
+          <li>certificate trust</li>
+          <li>dashboard/API visibility</li>
+        </ol>
+
+        <h2>Common failures</h2>
+        <ul>
+          <li>service is down even though the dashboard is reachable</li>
+          <li>internal HTTPS shows warnings because DashCA trust is missing</li>
+          <li>DNS automation fails due to API token or zone issues</li>
+          <li>Caddy changes are not applying because Admin API is unavailable</li>
+          <li>Premium features do not unlock because license validation is failing</li>
+        </ul>
+
+        <h2>Mindset</h2>
+        <p>
+          Most DashCaddy problems are really one dependency layer failing while the others are healthy. Debugging that dependency chain is the right way to recover quickly.
+        </p>
+      </DocsLayout>
+      <Footer />
+    </div>
+  );
+}