fix(kb): level pages no longer duplicate id="what-it-is"

kb.long always opens with "## What it is", so the wrapping section and its
own first heading both slugged to "what-it-is" — invalid HTML, and any
in-page anchor to it resolved to the section instead of the heading. The
wrapper no longer carries its own id; the heading's id (already in the
page's TOC via headingsOf) is the only one, so anchors now land where they
say they will.

kb-generator.test.js gains a no-duplicate-id assertion across every
generated page so this class of bug fails the suite next time.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Author: ghostintheshell-192

.development/scripts/generate-kb.js

@@ -676,7 +676,11 @@ function levelPage(def, ctx) {
   };
 
   // 1 — the level's own story, under its class in words and its short form.
-  out.push('  <section class="kb-section" id="what-it-is">');
+  // No id on the section itself: kb.long always opens with "## What it is",
+  // whose rendered heading already gets that id (headingId: slug below) —
+  // giving the wrapper the same id would duplicate it (invalid HTML) and make
+  // the anchor resolve to the section instead of the heading it names.
+  out.push('  <section class="kb-section">');
   out.push(`    <p class="kb-lede">${escapeHtml(shortOf(def))}</p>`);
   if (def.kb.long) out.push(indent(md(def.kb.long, `${where}: kb.long`), 4));
   out.push('  </section>');

kb/raid0.html

@@ -156,7 +156,7 @@ <h1 class="kb-title">RAID 0</h1>
       <a class="kb-nav-item" href="../index.html">Sandbox</a>
   </nav>
 
-  <section class="kb-section" id="what-it-is">
+  <section class="kb-section">
     <p class="kb-lede">Data dealt out in chunks across every disk and nothing else: no copy, no parity. Every disk works on every large request, so it is the fastest layout there is and uses all the space; and any one disk failing loses everything on all of them.</p>
     <h2 id="what-it-is">What it is</h2>
     <p>RAID 0 is the pair <em>striped + no redundancy</em>: the data is cut into chunks and dealt across the members in turn (<a href="striping.html">striping</a>), and that is all. The 1988 paper that named RAID defines five levels, from mirroring upward; a stripe with no redundancy is not one of them, and the name came later, for exactly the case the paper opens with: an array whose time to failure is one disk&#39;s divided by the number of disks (<a href="redundancy.html">redundancy</a>).</p>

kb/raid1.html

@@ -156,7 +156,7 @@ <h1 class="kb-title">RAID 1</h1>
       <a class="kb-nav-item" href="../index.html">Sandbox</a>
   </nav>
 
-  <section class="kb-section" id="what-it-is">
+  <section class="kb-section">
     <p class="kb-lede">Every disk holds a full copy of the data, written in step. A read is served by any one copy, a write goes to all of them, and the array survives as long as one copy is left. It keeps one disk&#39;s worth of space however many disks it has, and it is the simplest redundancy there is.</p>
     <h2 id="what-it-is">What it is</h2>
     <p>RAID 1 is the pair <em>linear + mirror</em>: nothing is cut into chunks, and every member holds the whole (<a href="mirroring.html">mirroring</a>). It is the first level of the 1988 paper, &quot;the most expensive option we consider since all disks are duplicated&quot;, and every other level is a cheaper answer to the same problem. There is no layout to choose and no chunk size, because there is nothing to place: <code>mdadm</code> does not accept a chunk size for it.</p>

kb/raid10.html

@@ -156,7 +156,7 @@ <h1 class="kb-title">RAID 10</h1>
       <a class="kb-nav-item" href="../index.html">Sandbox</a>
   </nav>
 
-  <section class="kb-section" id="what-it-is">
+  <section class="kb-section">
     <p class="kb-lede">Striping and mirroring in one flat array: every chunk is stored on two disks, and the chunks are dealt across all of them. It reads like a stripe, writes at a mirror&#39;s cost with no parity to compute, keeps half the space, and is guaranteed to survive one failure, more if the failures miss each other.</p>
     <h2 id="what-it-is">What it is</h2>
     <p>RAID 10 is the pair <em>striped + mirror</em>: the data is cut into chunks and dealt across the members (<a href="striping.html">striping</a>), and each chunk is stored twice, on two different disks (<a href="mirroring.html">mirroring</a>). In Linux <code>md</code> it is one level, not a nesting: &quot;every datablock is duplicated some number of times, and the resulting collection of datablocks are distributed over multiple drives&quot;. Where the second copy lands is the placement <a href="algorithm.html">algorithm</a>, <em>near</em>, <em>far</em> or <em>offset</em>; near, the default, puts the two copies side by side in the same stripe, which is the same arrangement a hardware controller reaches in a different way, by striping over mirror pairs. That nested form, RAID 1+0, has its own page; with the near layout the two put every block in the same place, and the difference is which engine built it and which other layouts it can offer. RAID 0+1, a mirror of two stripes, uses the same disks in a worse arrangement, and its page says why.</p>

kb/raid5.html

@@ -156,7 +156,7 @@ <h1 class="kb-title">RAID 5</h1>
       <a class="kb-nav-item" href="../index.html">Sandbox</a>
   </nav>
 
-  <section class="kb-section" id="what-it-is">
+  <section class="kb-section">
     <p class="kb-lede">Data striped across every disk, with one parity block per stripe that moves from disk to disk. Any one disk can fail and everything on it is recomputed from the rest by XOR. It keeps all but one disk&#39;s worth of space, reads nearly as fast as a plain stripe, and pays for small writes with four disk operations each.</p>
     <h2 id="what-it-is">What it is</h2>
     <p>RAID 5 is the pair <em>striped + single parity</em>: the data is dealt out in chunks across all the members (<a href="striping.html">striping</a>), and in every stripe one chunk holds the XOR of the others (<a href="parity.html">parity</a>). It is the fifth level of the 1988 paper, and the one the paper builds up to: the fourth level had put all the parity on one disk, and &quot;the check disk is the bottleneck&quot;; the fifth &quot;distributes the data and check information across all the disks&quot;. Which disk holds the parity in which stripe is the placement <a href="algorithm.html">algorithm</a>, almost always left-symmetric.</p>

kb/raid6.html

@@ -156,7 +156,7 @@ <h1 class="kb-title">RAID 6</h1>
       <a class="kb-nav-item" href="../index.html">Sandbox</a>
   </nav>
 
-  <section class="kb-section" id="what-it-is">
+  <section class="kb-section">
     <p class="kb-lede">RAID 5 with a second parity block per stripe, computed a different way, so that any two disks can fail at once. It keeps all but two disks&#39; worth of space, survives a second failure during a rebuild, and pays for each small write with six disk operations.</p>
     <h2 id="what-it-is">What it is</h2>
     <p>RAID 6 is the pair <em>striped + double parity</em>: the data is dealt across the members (<a href="striping.html">striping</a>), and every stripe carries two check blocks, <em>P</em>, the XOR of the data as in RAID 5, and <em>Q</em>, a Reed-Solomon code over the same blocks (<a href="parity.html">parity</a>). Two blocks give two equations, and two equations recover two unknowns: &quot;RAID-6 supports losing any two drives&quot;, in the words of the paper behind the Linux implementation. Which disks hold <em>P</em> and <em>Q</em> in each stripe is the placement <a href="algorithm.html">algorithm</a>, the same four names as RAID 5.</p>

tests/kb-generator.test.js

@@ -5,7 +5,7 @@
  * the pages are compared against; it runs the generator as a subprocess, so the
  * vendored parser stays inside that process and this suite keeps no dependency.)
  *
- * Four properties, each one a way a generated page has gone wrong before:
+ * Five properties, each one a way a generated page has gone wrong before:
  *
  *   1. DETERMINISM. Two runs on the same input produce the same bytes. Without
  *      it every commit carries a diff nobody wrote, and the pre-commit hook
@@ -22,7 +22,10 @@
  *      phone gets). The JSON-LD block (data, not code) and the Cookiebot /
  *      Consent Mode / gtag.js analytics block — byte-identical on every page,
  *      index.html is its source of truth — are the only <script> tags a page
- *      may carry; nothing else runs.
+ *      may carry; nothing else runs;
+ *   5. NO DUPLICATE ID. Every id in a page is unique. The knowledge base's
+ *      in-page anchors and "On this page" column both link to `#id`s the
+ *      generator assigns, and a collision means the wrong element wins.
  */
 
 const fs = require('fs');
@@ -294,5 +297,18 @@ for (const [name, html] of pages) {
   });
 }
 
+// ---------------------------------------------------------------------------
+console.log('\n[7] no id is duplicated on a page');
+
+for (const [name, html] of pages) {
+  test(`${name}: every id is unique`, () => {
+    const ids = [...html.matchAll(/\sid="([^"]+)"/g)].map((m) => m[1]);
+    const seen = new Set();
+    const dupes = new Set();
+    for (const id of ids) (seen.has(id) ? dupes : seen).add(id);
+    assert(dupes.size === 0, `${name}: id "${[...dupes][0]}" is used more than once`);
+  });
+}
+
 fs.rmSync(tmp, { recursive: true, force: true });
 finish();