state packages come from github only

web/installation-requirements.html

@@ -43,7 +43,7 @@
             <p>At the first installable release (0.1), the network path is straightforward: wired Ethernet via DHCP, or wireless via <code>nmtui</code>, both handled from inside the installer. <a href="network-setup.html">See the network setup flow.</a></p>
 
             <h3>What "from the network" means</h3>
-            <p>The installer fetches source tarballs (straight from upstream, or via a mirror when <code>SOURCE_MIRROR</code> is set), pulls recipes from the <a href="kama-repos.html">recipe repository</a>, and builds. The heavy lifting is the compiler on your CPU — which is exactly the point of a source-only, from-scratch distribution.</p>
+            <p>The installer fetches source tarballs (straight from upstream, or via a mirror when <code>SOURCE_MIRROR</code> is set) and pulls package recipes from the GitHub-hosted <a href="kama-repos.html">recipe repository</a>. The heavy lifting is the compiler on your CPU — which is exactly the point of a source-only, from-scratch distribution.</p>
 
             <div class="callout">If you want fast and prebaked, a binary distro is right there. If you want <em>your</em> machine — built from source to your exact selection — Keru is the one.</div>
 

web/kama-repos.html

@@ -30,6 +30,14 @@
                 <tr><td><strong>KeruOS</strong></td><td>The OS: installer, profile, build pipeline, live init, website.</td><td>The orchestration.</td></tr>
             </table>
 
+            <h3>Where the repos live</h3>
+            <div class="code-block">github.com/AstralZX/kama            # the manager
+github.com/AstralZX/kama-packages  # the recipe repository
+github.com/AstralZX/KeruOS         # the OS itself</div>
+            <p>Today the repos are <strong>GitHub-only</strong> — that's the single canonical source for package recipes and code. Mirrors on Codeberg and on <code>git.spectoria.dev</code> are planned, but nothing is hosted there yet, and there are no other mirrors. Until that changes, GitHub is the source of truth.</p>
+
+            <div class="callout">No package recipes ship on the ISO, in the installer, or anywhere else. The recipe repository on GitHub is how you get packages — clone it or install Keru, which fetches it at build time.</div>
+
             <h3>Why separate</h3>
             <ul class="features">
                 <li><strong>Independent cadence.</strong> The manager changes rarely; recipes change constantly. Mixing them couples an ossified core to churn.</li>

web/mirror-cache.html

@@ -4,7 +4,7 @@
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Mirrors and cache — Keru OS</title>
-<meta name="description" content="How Keru and Kama download source: the project mirror, upstream fallback, and the download/source/stage cache layout.">
+<meta name="description" content="How Keru and Kama download source tarballs: an optional mirror you run, upstream as fallback, and the download/source/stage cache layout.">
 <link rel="stylesheet" href="assets/css/style.css">
 <link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
 </head>
@@ -21,7 +21,7 @@
 <section>
     <div class="wrap">
         <div class="prose">
-            <p>Every Keru build is a network operation. Two mechanisms keep that sane and reproducible: a mirror-first download policy, and a well-defined cache on disk.</p>
+            <p>Every Keru build is a network operation. Package recipes always come from the GitHub-hosted <a href="kama-repos.html">kama-packages</a> repo; this page is about the other half — the <em>source tarballs</em> each recipe downloads, and the cache they pass through.</p>
 
             <h3>Download order</h3>
             <ul class="features">

web/privacy.html

@@ -37,7 +37,7 @@
             </ul>
 
             <h3>About the download</h3>
-            <p>When 0.1 ships as an ISO, downloading it is a plain file fetch from the public mirror. Nothing is recorded beyond what your server logs necessarily keep.</p>
+            <p>When 0.1 ships as an ISO, downloading it is a plain file fetch from GitHub (a release asset). Nothing is recorded beyond what your server and service logs necessarily keep. If a mirror is ever added, this page will say so.</p>
 
             <div class="callout">If that changes, this page changes first — and it will be public. Keru won't decide that telemetry is "fine actually" in a changelog.</div>
         </div>

web/security.html

@@ -28,7 +28,7 @@
 
             <h3>Verified fetch</h3>
             <ul class="features">
-                <li><strong>Mirror then upstream.</strong> Downloads prefer the project mirror and fall back to upstream, never the other way.</li>
+                <li><strong>Mirror then upstream.</strong> Downloads try <code>SOURCE_MIRROR</code> when set and fall back to upstream. Unset — the default — they go straight to upstream.</li>
                 <li><strong>Integrity enforced.</strong> A fetched tarball that doesn't verify is refused, not untarred. Failed verification is a hard stop.</li>
                 <li><strong>Pinned sources.</strong> Recipes pin the exact <code>url</code> and version. Nothing is ever pulled "latest" implicitly.</li>
             </ul>
@@ -49,7 +49,7 @@ kama-packages/*.sh      # recipes as plain shell you can read top to bottom</div
             <h3>Licensing, because supply chain is security</h3>
             <p>All three repos are <span class="tag accent">AGPL-3.0</span>. Recipes tag their <code>license</code> explicitly. Nothing in the pipeline is proprietary-black-boxed.</p>
 
-            <div class="callout">Trust is transitive: you still trust the sources you install and the mirror that serves them. Keru's job is to make that trust chain visible and verifiable — not to pretend you can be protected from everything.</div>
+            <div class="callout">Trust is transitive: you still trust the sources you install and any mirror you point at. Keru's job is to make that trust chain visible and verifiable — not to pretend you can be protected from everything.</div>
 
             <h3>Reporting</h3>
             <p>Found a flaw in the installer, kama, or a recipe? File it with the stage and the failing artifact. See <a href="contact.html">contact</a> and <a href="troubleshooting.html">troubleshooting</a>.</p>

web/troubleshooting.html

@@ -33,7 +33,7 @@
 
             <h3>Network</h3>
             <ul class="features">
-                <li><strong>Installer says offline.</strong> It probes a few hosts (<code>1.1.1.1</code>, <code>github.com</code>, the project mirror) and loops: it will offer to run <code>nmtui</code>, then re-check. Let it.</li>
+                <li><strong>Installer says offline.</strong> It probes several hosts (<code>1.1.1.1</code>, <code>github.com</code>) and loops: it will offer to run <code>nmtui</code>, then re-check. Let it. GitHub reachability matters — package recipes are fetched from GitHub.</li>
                 <li><strong>DHCP won't bite.</strong> Use <code>nmtui</code> and set a static address. The installer doesn't care how the link comes up, only that it does.</li>
                 <li><strong>Slow fetch.</strong> When <code>SOURCE_MIRROR</code> is set it's tried first; upstream is the fallback. A broken mirror yields timeouts — fix or unset <code>SOURCE_MIRROR</code>.</li>
             </ul>