blog

 ---
 import Base from '../../../layouts/Base.astro';
 import { getCollection, render } from 'astro:content';
 import type { GetStaticPaths } from 'astro';
 import { postUrl } from '../../../lib/order';
 import { proseShape, excerpt, longDate } from '../../../lib/prose';
 import { docLang, hasHangul, langOf } from '../../../lib/hangul';
 import { assertRendered } from '../../../lib/rendered';
 
 export const getStaticPaths: GetStaticPaths = async () => {
   const posts = (await getCollection('writing')).filter((p) => !p.data.draft);
   return posts.map((p) => ({
     // params must be the decoded form — Korean slugs are passed through verbatim.
     params: { year: p.data.date.slice(0, 4), slug: p.id },
     props: { post: p },
   }));
 };
 
 const { post } = Astro.props;
 assertRendered(post);
 const { Content, headings } = await render(post);
 
 const md = post.body ?? '';
 const { shape, rhythm } = proseShape(md);
 
 /**
  * The byline, and it is a site-level constant rather than a per-post field on purpose.
  *
  * The reference prints one on every article — `by <strong>Nicholas Carlini</strong>`
  * followed by the date, checked on three of its posts across 2024, 2025 and 2026 — so a
  * byline belongs here. A byline names a person, so this is the person: the same string
  * Base.astro holds as SITE_OWNER and prints in the copyright line at the foot of every
  * page, and in the header slot on / and the 404 page. NOT 'sqzer' — that is the domain
  * (sqzer.com), which Base.astro spends its own comment distinguishing from the
  * owner's name, and which only ever appears in <title> and the feed title. Printing it
  * here would have the byline say one name and the copyright line of the same page
  * another.
  *
  * Duplicated rather than imported because SITE_OWNER is a module-scoped const in
  * Base.astro's frontmatter, and nothing outside a component can import its frontmatter.
  * Keep the two in sync: src/layouts/Base.astro, `const SITE_OWNER`.
  *
  * Site-level rather than per-post because the writing schema has no `author` field. A
  * per-post byline — a guest post, a co-author — would need that field on the collection,
  * which is a schema change.
  */
 const AUTHOR = 'Hyukjin An';
 
 const year = post.data.date.slice(0, 4);
 
 // The body's language, measured on prose only; see docLang in src/lib/hangul.ts.
 const lang = docLang(md);
 
 /*
  * Which font to preload is a different question from which language to declare, and the
  * two answers differ on real posts. `lang` is a ratio over prose with code fences removed,
  * so We_need_to_talk is correctly an English document at 0.28 — and it still paints 753
  * Hangul syllables, because both English essays carry a KR half. Preloading by `lang`
  * would leave those in fallback behind a third-wave request. One Hangul character anywhere
  * in the rendered body is enough to need the whole 118KB face, so the test is presence,
  * not proportion, and it runs on the raw source including fences: 20 of the corpus's 55
  * fenced blocks (52 code plates and 3 diagrams) contain Hangul, in comments, placeholders
  * and diagram labels.
  */
 const ko = hasHangul(md, post.data.title, post.data.deck);
 
 /**
  * deck is empty on all 30 posts, so the description falls back to excerpt(): the opening
  * paragraph as plain text, cut to 160 characters.
  */
 const description = post.data.deck ?? excerpt(md);
 
 /**
  * Contents are the default, not a reward for being technical.
  *
  * The premise is that every post gets headings. 14 of the 30 have none today and 2 have
  * one; that is a gap in the prose, not a property of those documents, and the gate is
  * written for the corpus they are becoming rather than the one they are. So it asks a
  * single structural question — is there a heading structure here a reader could navigate
  * — and nothing at all about genre.
  *
  * Three levels deep, counted from the document's own top heading rather than from <h1>.
  * An absolute `depth <= 3` looks equivalent and is not, because satteri-prose demotes
  * every heading by one in any document that contains an h1 (and no h6) — so "depth 3" is
  * the author's ### in 안전하고 and the author's ## in tso, and an absolute filter silently
  * means a different thing on either side of that. Counted in the built DOM:
  *
  *                            absolute <= 3      relative to top
  *     tso                        5                  11     six ### subsections kept
  *     journalctl                 2                   6     four ### sections kept
  *     sysmon                    11                  18
  *
  * On the absolute count journalctl — a command reference, the single most jumped-around
  * document in the corpus — would show two entries. Every post with more than one heading
  * starts at h2 after demotion, so today the two readings differ only in where they stop;
  * the relative form is what keeps them in agreement if a document ever opens at h3 or the
  * demotion rule moves.
  *
  * The distribution over the 30 posts, entries per document:
  *
  *     28 19 19 18 11 10 6 6 6 4 3 2 2 2 | 1 1 | 0 x14
  *      ^ the 14 that get contents today ^  ^ nothing to navigate ^
  *
  *     >= 2 -> 14    >= 4 -> 10    >= 6 -> 9
  *     >= 3 -> 11    >= 5 ->  9    >= 7 -> 6
  *
  * 2, and it is ONE gate for both presentations. What decided it:
  *   - 1 is not a list. A single entry offers no choice — it is a link to a point in the
  *     middle of the page, filed under a heading that says "Contents" — and the rail would
  *     spend at least 240px of gutter and a full-height rule stating it. Two is the
  *     smallest list a reader can navigate WITH. It is the only threshold that follows
  *     from the premise rather than from this corpus's accidents, which is what makes it
  *     safe to leave in place while the 16 documents below the line are being written into.
  *   - not 6, the threshold the gap in this distribution suggests. That gap is exactly the
  *     artefact the premise dissolves: every document near it is one editing pass away
  *     from moving across it. 6 would also select nine documents while the page box
  *     reserves room for a rail on all thirty (see the rail block).
  *   - no `shape === 'technical'` test. A genre test keeps a long list of decorative
  *     headings out of an essay, and at two entries there is no long list to keep out. An
  *     essay with sections is a document with sections: this admits AIOdyssey and
  *     We_need_to_talk, both essay-shaped, both two real sections.
  *   - one gate, not two. A rail-only gate wider than the inline one would leave those
  *     posts with no contents at all below the width where the rail parks.
  *
  * What the 16 below the line get: nothing painted — no rail, no inline list, no rule.
  * What does not change for them is the page box, which reserves the rail's gutter on
  * every article whether or not a rail is painted in it; see `main:has(.post-shell)` in
  * the rail block below for why that is the steady state rather than a concession.
  */
 /*
  * One heading in `headings` was not written by the author. GFM footnotes close the document
  * with <section class="footnotes"><h2 class="sr-only" id="footnote-label">Footnotes</h2>,
  * and Sätteri's heading-id plugin collects it like any other — measured, depth 2, slug
  * "footnote-label". It is drawn nowhere (.sr-only in base.css), so leaving it in puts an
  * entry in the rail that jumps to an invisible target, and at a two-entry gate a post with
  * one real heading and one footnote would get a whole rail for that. It also joins the
  * Math.min below, so a footnoted document whose headings all start at h3 would take its
  * base from the footnote label instead and mis-level every entry under it.
  * No post uses footnotes today; two have exactly one heading, which is the case this
  * protects. Filtered by slug rather than by text because the text is translatable.
  */
 const authored = headings.filter((h) => h.slug !== 'footnote-label');
 const tocBase = authored.length ? Math.min(...authored.map((h) => h.depth)) : 2;
 const toc = authored.filter((h) => h.depth <= tocBase + 2);
 const showToc = toc.length >= 2;
 
 /**
  * Indent by position in this document's own hierarchy, not by absolute depth — the same
  * reason the filter above is relative. 0, 1 or 2 by construction.
  */
 const tocLevel = (depth: number) => depth - tocBase;
 
 const ld = {
   '@context': 'https://schema.org',
   '@type': 'BlogPosting',
   headline: post.data.title,
   datePublished: post.data.date,
   inLanguage: lang,
   /* Omitted rather than emitted empty. `description` is '' when the deck is blank AND
      excerpt() finds no paragraph to fall back on — a post copied from the template whose
      body has not been written yet. Both other sinks already drop it in that case:
      Base.astro guards <meta name="description"> behind a truth test, and @astrojs/rss
      omits the element. Emitted empty, this key would be the one place a blank field
      still put an empty value into the page, asserting that the post has an empty
      description. */
   ...(description ? { description } : {}),
   mainEntityOfPage: new URL(postUrl(post), Astro.site).href,
 };
 ---
 <Base
   title={`${post.data.title} :: debuman`}
   description={description}
   section="writing"
   ko={ko}
 >
   {/* Outside .post-shell, and that placement is load-bearing rather than tidy. The shell
       carries `container-type: inline-size`, which implies layout containment, which makes
       it a containing block for position:fixed descendants. Put the rail inside it and
       `right: var(--toc-x)`, a percentage expression, resolves against the 1024px shell
       instead of the viewport, `top` measures from the shell, and the whole thing scrolls
       away with the article. Here in <main>, which sets no containment, it is fixed to the
       viewport as intended.
       In reading order it precedes the article, which is where a contents list belongs. */}
   {showToc && (
     <nav class="toc-rail" aria-labelledby="toc-rail-title">
       <p class="toc-rail__title" id="toc-rail-title">Contents</p>
       <ol class="toc-rail__list">
         {toc.map((h) => (
           <li class="toc-rail__item" data-level={tocLevel(h.depth)}>
             {/* data-target, not the href, is what the scroll-spy resolves: the headings of
                 a Korean post have Hangul slugs, and `a.hash` comes back percent-encoded in
                 some engines, so reading the slug straight out of the attribute skips a
                 decode step that has to be right for every one of them. */}
             {/* lang per entry, and it is this rail's price for living outside .post.
                 The article declares its language on <article class="post">, and the
                 inline <details class="toc"> sits inside it, so the collapsed list inherits
                 that language and marks only the entries in the other script. The rail
                 cannot inherit it: it is hoisted out to <main> so that .post-shell's
                 `container-type` does not become its containing block, and out there the
                 nearest [lang] is <html lang="en">. Without a lang of their own, 15 of
                 sysmon's 18 entries, all 10 of bind9's and 8 of tso's 11 are Hangul
                 announced as English — the same strings the inline list announces
                 correctly. Per entry rather than one lang on the <nav>, because out here
                 `en` really is the document: how-to-win's list is 25 English headings to 3
                 Korean, and langOf() drops an agreeing value so a reader is not switched
                 for them. Same call the Writing index makes on the same kind of string. */}
             <a class="toc-rail__link" href={`#${h.slug}`} data-target={h.slug} lang={langOf(h.text, 'en')}>{h.text}</a>
           </li>
         ))}
       </ol>
     </nav>
   )}
   <div class="post-shell">
   <article class="post" data-shape={shape} data-rhythm={rhythm} lang={lang}>
     <header class="post__head">
       <p class="post__kicker">
         <a href="/writing/">Writing</a>
         <span class="post__sep" aria-hidden="true">·</span>
         <a href={`/writing/#${year}`}>{year}</a>
       </p>
       <h1 class="post__title" lang={langOf(post.data.title, lang)}>{post.data.title}</h1>
       {post.data.deck && <p class="post__deck">{post.data.deck}</p>}
       {/* No reading-time estimate: the reference's header is a title, a byline and a
           date, and it prints no estimate of how long the reading will take. The byline
           takes the slot under the title. lang="en" because the word "by" and the
           Latin-script name are the same on every post, most of which declare lang="ko" on
           <article> — the same reason the contents rail labels its entries one by one. */}
       {/* The gap between name and date is padding, so without the hidden comma the text
           itself would read "Hyukjin AnJune 27, 2026" to a screen reader, to Reader View
           (which takes this paragraph as the byline) and in anything copied from it. */}
       <p class="post__byline" lang="en">by <span class="post__author">{AUTHOR}</span><span class="sr-only">, </span><time class="post__date" datetime={post.data.date}>{longDate(post.data.date)}</time></p>
     </header>
 
     {showToc && (
       <details class="toc">
         <summary class="toc__summary">Contents</summary>
         <ol class="toc__list">
           {toc.map((h) => (
             <li class="toc__item" data-level={tocLevel(h.depth)}><a href={`#${h.slug}`} lang={langOf(h.text, lang)}>{h.text}</a></li>
           ))}
         </ol>
       </details>
     )}
 
     <div class="prose"><Content /></div>
   </article>
   </div>
   {/* JSON.stringify does not escape `<`, so a deck or a title containing `</script>` closes
       this element early and the rest of the object is parsed as HTML. The title is the
       author's and the deck is a field they fill in freely, so this is a string they can
       type, not a string only the build produces. `<` is escaped as its `\u003c` form, which
       is the same character to a JSON parser and inert to an HTML one. */}
   <script type="application/ld+json" set:html={JSON.stringify(ld).replace(/</g, '\\u003c')} />
 
 <script>
   /*
    * Current-section marking for the contents rail.
    *
    * Enhancement only. Without it every entry in the rail is still a working anchor, and
    * Astro renders this script into all 30 article pages, so the first test is the guard
    * that makes it a no-op on the 16 that have no rail today.
    *
    * No scroll handler, and no geometry measured to decide which entry is current — an
    * IntersectionObserver, with a root shaped so that `isIntersecting` is already the
    * answer. (Two reads further down: the rail's own scrollport, only when the section
    * changes, and scrollY, only while the end of the document is on screen, to tell a page
    * the reader has scrolled from one that fits on screen whole.)
    *
    * The reading line is 15% of the way down the viewport, and a heading counts as current
    * once it has crossed it. Expressing that as "is the heading inside a band at the top of
    * the viewport" does not work, and the failure is not theoretical: a band is a single
    * boolean, so above-the-band and below-the-band are the same state, and an instant jump
    * over the band — Home, a restored scroll position, window.scrollTo — changes nothing
    * and fires no callback. So with a band, scrollTo(0, 0) from the foot of how-to-win
    * would leave the rail marking "Conclusion" at the top of the page.
    *
    * So the root is not a band but a half-plane: 100,000px of margin above the viewport and
    * -85% below, giving a box that runs from far above the document to the reading line.
    * A heading intersects it exactly while it is above that line, "above" and "below" are
    * now different states, and every crossing in either direction fires — instant jumps
    * included. The tallest document is under 17,000px at 1440px, the narrowest window that
    * shows the rail, so 100,000px is roughly six times it and nothing can drift out of the
    * top of the root.
    *
    * 15% is 135px on a laptop, against the 16px (--sp-40) of scroll-margin the headings
    * carry — so following a rail entry always lands its own heading above the line and
    * marks the entry that was clicked. Where an h2 is followed immediately by its first
    * h3, both clear the line at once and the h3 wins; that is the rule working, not an
    * off-by-one, since the h2 has no text of its own at that point.
    *
    * The current section is then the LAST heading that has crossed, in document order.
    * None crossed means the reader is above the first heading — in the lede, or back at the
    * top of the document — and the answer there is the first entry, not nothing: a reader
    * who scrolls to the foot of how-to-win and presses Home sees entry one marked. The
    * marks on the way down may also have scrolled the rail down its own list, which would
    * open it mid-entry with CONTENTS off the top, so whenever the answer is entry one the
    * rail is returned to its own scrollTop 0 and the title and the first entry are whole.
    *
    * One correction to that rule, at the far end. A heading can only reach the line if the
    * document is tall enough to push it there, so a final section shorter than 85% of the
    * viewport can never be marked at all: on how-to-win, scrolled to the very bottom,
    * "Conclusion" sits in full view well below the line, and the last-crossed rule alone
    * would leave the rail pointing at the section before it. A second observer watches an
    * empty marker appended to the end of <body>, against the plain viewport. It is on
    * screen only when the page is scrolled as far as it goes, which is the one position a
    * short final section can never be marked from, so there the last entry is the answer.
    * Watching the end of the document rather than anything above it keeps this from firing
    * while the last heading can still be scrolled up to the line.
    */
   const rail = document.querySelector('.toc-rail');
   if (rail) {
     const links = new Map();
     const targets = [];
     for (const a of rail.querySelectorAll('.toc-rail__link')) {
       const el = document.getElementById(a.dataset.target);
       if (!el) continue;
       links.set(el.id, a);
       targets.push(el);   // rail order, which is heading order, which is document order
     }
 
     if (targets.length) {
       const passed = new Set();
       let atEnd = false;
       let marked = null;
 
       const apply = () => {
         // Entry one is the floor, not null: above the first heading the reader is in the
         // lede of section one, and that is what the rail should say.
         let next = targets[0].id;
         for (const el of targets) if (passed.has(el.id)) next = el.id;
         // Only once the reader has moved: an article short enough to fit on screen whole
         // shows its end marker on load, before anything has been read. A short one that
         // scrolls a little can reach its end with no heading past the line, and the last
         // entry is still the answer there, so scrollY counts as well as `passed`.
         if (atEnd && (passed.size || scrollY > 0)) next = targets[targets.length - 1].id;
 
         /* The one place the rail's own scroll position is set outright rather than nudged.
            scrollIntoView({ block: 'nearest' }) is a no-op once the entry is already in
            view, so coming back up to entry one from the foot of the article would leave
            the list wherever the last nudge had put it: on how-to-win at 1440x900, with its
            head scrolled out of view. At the top of the document the rail belongs at the
            top of itself.
            Written on every callback that lands here rather than only on a change: it is
            one property write, the callbacks are section crossings and not frames, and it
            also recovers a rail the reader had scrolled by hand. */
         const atStart = next === targets[0].id;
         if (atStart) rail.scrollTop = 0;
 
         if (next === marked) return;
 
         if (marked) links.get(marked).removeAttribute('aria-current');
         marked = next;
 
         const link = links.get(marked);
         link.setAttribute('aria-current', 'location');
         /* Keep the mark inside the rail's own scrollport — one of the 14 lists is taller
            than it at 1440x900, and the count only rises as posts gain headings. Read only
            when the section changes, which is a handful of times over an article rather
            than once a frame. Skipped at the start, where `rail.scrollTop = 0` has already
            put the whole head of the list on screen. */
         if (!atStart && rail.scrollHeight > rail.clientHeight) link.scrollIntoView({ block: 'nearest' });
       };
 
       const reading = new IntersectionObserver(
         (entries) => {
           for (const entry of entries) {
             if (entry.isIntersecting) passed.add(entry.target.id);
             else passed.delete(entry.target.id);
           }
           apply();
         },
         { rootMargin: '100000px 0px -85% 0px' },
       );
       for (const el of targets) reading.observe(el);
 
       // One pixel tall, pulled up over the pixel it adds, so it moves nothing and occupies
       // the document's last pixel. Zero height does not work: when the document's height
       // has a fraction that rounds the scroll range down, a zero-area marker sits just past
       // the viewport at full scroll and is not detected, so a short final section is never
       // marked.
       const end = document.createElement('div');
       end.setAttribute('aria-hidden', 'true');
       end.style.height = '1px';
       end.style.marginBlockStart = '-1px';
       document.body.append(end);
       new IntersectionObserver((entries) => {
         atEnd = entries[entries.length - 1].isIntersecting;
         apply();
       }).observe(end);
     }
   }
 </script>
 
 <script>
   /*
    * Copy control for code blocks.
    *
    * Enhancement, and built here rather than emitted by the `sqzer:code-block` transformer
    * on purpose: a button that cannot copy is worse than no button, so the control exists
    * only where the script that gives it a job has run. What the transformer must not do is
    * grow a second child — Astro reads `root.children[0]` and drops the rest — and what it
    * does emit is the contract this reads: figure.code[data-language] > pre > code.
    *
    * The row the button lands in is NOT made here. base.css reserves it on every plate, so
    * nothing reflows when this runs and the band is the same with a figcaption (where the
    * label and the button share one row) and without (7 of the corpus's 52 plates, the ones
    * whose fence names no language or `plaintext`, get no figcaption at all).
    *
    * What gets copied is `code.textContent`. Shiki's per-token <span>s contribute their text
    * and nothing else, the break between two rows is a real newline text node, and the
    * language label lives in a <figcaption> outside the <pre> — so the string is the
    * fence's source back, exactly, with no markup and no label in it. There is no trailing
    * newline, which is the fence's own shape and also the safer paste: a shell runs the
    * last line when it arrives with one, and does not when it does not.
    *
    * Insertion is `prepend`, not `append`, so the tab order matches the reading order: the
    * button at the top right of the plate, then the <pre>, which carries Shiki's own
    * tabindex="0" as a scroll region.
    */
   const plates = document.querySelectorAll('.prose figure.code');
   if (plates.length) {
     /*
      * One polite live region for the page, created up front. A region that is inserted
      * and filled in the same task is missed by most screen readers, so it has to be in
      * the tree before there is anything to say.
      *
      * role="status" is aria-live="polite" plus aria-atomic="true" without spelling either
      * out. Assigning the same string twice is commonly swallowed as "no change", and
      * copying the same block twice is a normal thing to do, so the region is emptied and
      * refilled on the next frame instead.
      */
     const status = document.createElement('p');
     status.className = 'sr-only';
     status.setAttribute('role', 'status');
     document.body.append(status);
 
     // Emptied again two seconds later: the region sits after the footer, and a message
     // left in it would be read out of context by anyone reading on to the end of the page.
     let frame = 0;
     let clear = 0;
     const announce = (message) => {
       cancelAnimationFrame(frame);
       clearTimeout(clear);
       status.textContent = '';
       frame = requestAnimationFrame(() => {
         status.textContent = message;
         clear = setTimeout(() => { status.textContent = ''; }, 2000);
       });
     };
 
     /*
      * Three glyphs in one <svg>; CSS paints whichever data-state names. 16px box, 1.5px
      * stroke, mitred joins and square caps — the page's own vocabulary is a 4px rule and a
      * 1px hairline, so the icon is drawn in straight lines with no corner radius anywhere.
      */
     const GLYPHS = `<svg viewBox="0 0 16 16" width="16" height="16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="square" stroke-linejoin="miter" aria-hidden="true" focusable="false"><g data-glyph="copy"><path d="M5.5 5.5V1.5h9v9h-4"/><rect x="1.5" y="5.5" width="9" height="9"/></g><g data-glyph="done"><path d="M3.5 8.5l3 3 6-7"/></g><g data-glyph="fail"><path d="M4.5 4.5l7 7m0-7l-7 7"/></g></svg>`;
 
     /*
      * navigator.clipboard needs a secure context. localhost and the deployed HTTPS site
      * both are one, so the first branch is the one that runs in practice — but it can
      * still reject (a permissions policy on an embedding page, a document that is not
      * focused, a user denying the permission prompt some engines still show), and the
      * whole point of a copy button is that the reader can tell whether it worked.
      *
      * So the fallback is also the failure affordance, in one gesture: select the block.
      * execCommand('copy') is deprecated but implemented everywhere, and what it asks for is
      * a user gesture rather than a permission — a click is one. If even that refuses, the
      * selection stays up and the reader finishes the job with the keyboard, which is what
      * the live region then tells them to do. Measured, with the async API forced to reject:
      * a real click still copies through this path; a script-dispatched .click() does not,
      * which is the gesture requirement doing its job.
      */
     const copy = async (code) => {
       const text = code.textContent ?? '';
       if (navigator.clipboard?.writeText) {
         try {
           await navigator.clipboard.writeText(text);
           return 'done';
         } catch { /* fall through to the selection path */ }
       }
       const selection = window.getSelection();
       if (!selection) return 'fail';
       const range = document.createRange();
       range.selectNodeContents(code);
       selection.removeAllRanges();
       selection.addRange(range);
       try {
         if (document.execCommand('copy')) {
           selection.removeAllRanges();
           return 'done';
         }
       } catch { /* leave the selection standing — it is the fallback */ }
       return 'fail';
     };
 
     for (const plate of plates) {
       const code = plate.querySelector('pre > code');
       if (!code) continue;
 
       const lang = plate.dataset.language;
       /* The control shows no text, so the name is the whole of it. It names the action and
          the thing, never the outcome: a button whose accessible name changes to "Copied"
          is a button that lies about what it does next. The outcome goes to the region. */
       const name = lang && lang !== 'plaintext' ? `Copy ${lang} code` : 'Copy code';
 
       const button = document.createElement('button');
       button.type = 'button';
       button.className = 'code__copy';
       button.dataset.state = 'idle';
       button.setAttribute('aria-label', name);
       button.title = name;          // the same string as a tooltip, for a pointer user
       button.innerHTML = GLYPHS;
 
       let revert = 0;
       button.addEventListener('click', async () => {
         const state = await copy(code);
         button.dataset.state = state;
         announce(state === 'done'
           ? 'Copied'
           : 'Copy failed. The code is selected — copy it with the keyboard.');
         clearTimeout(revert);
         revert = setTimeout(() => { button.dataset.state = 'idle'; }, 2000);
       });
 
       plate.prepend(button);
     }
   }
 </script>
 </Base>
 
 {/* is:global, not scoped. Astro rewrites a scoped `.prose p` to `.prose p[data-astro-cid-…]`,
     and the elements <Content /> emits carry no cid, so every body rule would silently miss.
     Only this page ships this sheet. Every selector matches the article's wrapper,
     .post-shell, or something inside it, except the contents rail, the hairline beside it
     (`main:has(.toc-rail)::before`) and the two rules that move the page box out of its
     way — `:root` and `main:has(.post-shell)`. Those two are the widening the rail asked
     for; they apply to every article rather than only the ones carrying a rail, and outside
     1440–1584px they give <main> the same margins base.css alone does (from 1440px up it is
     also position: relative, which moves nothing). Nothing here touches the
     site header: it is the same bar in the same place on every route, and base.css owns
     it. All of this is explained in the rail block below. */}
 <style is:global>
   /* ══ Geometry ════════════════════════════════════════════════════════════
      One left edge, with one bounded exception that is named here rather than left to be
      discovered. The text column is the same 928px the index uses, hung off the same 72px
      rail, so an article title starts exactly where the index entry title it was clicked
      from started — measured 0.00px apart at 320 / 768 / 1024 / 1584 / 1700 / 1920, on
      every article.
 
      The exception is a width band, 1440 to 1584px, and it is the same for all 30
      articles. There the rail's 240px floor does not fit in a centred gutter, so
      `main:has(.post-shell)` pushes the page box right far enough to make it fit and the
      two edges part: measured 72px at 1440, 48 at 1488, 24 at 1536, 0 from 1584 up and 0
      below 1440, where the rail is parked and the inline list is the contents. Those are
      layout-viewport widths, so a classic 15px scrollbar shifts the whole band 15px out
      and the true worst case is 79.5px, at a 1440px window. It is a deliberate trade — the
      alternative to the shift is to withhold the rail entirely across that 144px band —
      and the cost is bounded by arithmetic rather than by a literal: --page-left is a
      max() against the centred position, so the moment the gutter can seat the rail on its
      own the shift is exactly zero and never negative. The gutter is reserved whether or
      not a rail is painted in it, so moving from a post with contents to one without does
      not step the left edge. See the rail block below for
      the geometry, the --w-content note in tokens.css and the --content-w note in
      src/pages/writing/index.astro for the other two ends of the same edge.
 
      Inside that band the site header does not follow the page box. Restating base.css's
      header padding against --page-left would make the bar slide right and go asymmetric
      on article pages and nowhere else, so the bar stays where it is on every route, and
      across the band the wordmark stays on the centred edge while the page box leaves it.
      Measured, page box minus wordmark, at a real window with a classic scrollbar: 79.5px
      at 1440, 49.5 at 1500, 7.5 at 1584, 0.00 at 1700 / 1920 / 2560 and 0.00 at 1262 and
      below. It is the same shift already quoted above, read against the bar instead of
      against the index. The rail block below has the argument; base.css has the contract.
 
      `scrollbar-gutter: stable` on the root does not change any number in this block — a
      classic scrollbar still takes its 15px out of the layout viewport, which is why the
      worst case is at 1440 and why the shift is not yet 0 at a 1584px window. What it
      changes is that pages too short to scroll lose the same 15px, so the header's own
      centring is computed from one width across the site instead of two.
 
      Nothing breaks out of the edge on the page's own side: the rail lives outside .post
      and the measure is never widened to reach it. */
   .post {
     --rail-w: 4.5rem;                 /* 72px, the index date rail */
     --rail-gap: 1.5rem;               /* 24px */
     --fs-kicker: clamp(0.63rem, 0.36vw + 0.54rem, 0.88rem);   /* 10.08→14.08 */
 
     /* Korean leading. Measured from the shipped fonts: a Pretendard syllable advances
        0.8643em, times KoBody's 94.29% size-adjust = 0.8149em, so the 928px column holds
        71.2 syllables at 16px (Lora averages about 110 Latin characters on a wrapped line
        there, measured on the two English essays). Hangul also fills a 0.840em ink band on
        every character, where Lora's lowercase mostly occupies its 0.500em x-height and
        only the occasional ascender or descender reaches the 1.031em extreme - so at 1.6
        the Korean line loses about a third of its interline white. 1.75 returns nearly half
        of it. 1.90 would equalise it, at the price of the --sp-para gap between paragraphs
        no longer reading as a gap. */
     --lh-ko: 1.75;
 
     display: grid;
     grid-template-columns: var(--rail-w) minmax(0, 1fr);
     column-gap: var(--rail-gap);
     max-width: calc(var(--rail-w) + var(--rail-gap) + var(--w-content));  /* 1024px */
     margin-inline: auto;
   }
   .post > * { grid-column: 2; }
 
   /* The query container is this wrapper, not `.post` itself. An element cannot be
      styled by a container query it establishes, so with `container-type` on `.post`
      the rail-collapse block below would reach every descendant but never `.post`: the
      children would move to column 1 while the columns stayed `72px minmax(0, 1fr)`, and
      the whole article would render 72px wide on any viewport under ~623px. */
   .post-shell { container: post / inline-size; }
 
   /* ══ Header ══════════════════════════════════════════════════════════════
      Every Gazette header style is built around a picture: .article-header is a grid
      whose image slot is 316–500px tall (`height: clamp(19.75rem, 28.35vw + 13.11rem,
      31.25rem)`) and the text is the narrow column beside it. Remove the image and
      nothing holds the grid open, so the header has to be rebuilt, not emptied.
 
      Three things stand in for the picture, and none of them is filler:
        1. the 4px x 3rem rule, laid down as the page's first ink. The Gazette hangs it
           off .article-header__meta::before; this site's index already hangs it above
           the year kicker, and matching the index matters more than matching the
           Gazette's internal placement — it is the mark you just clicked away from.
        2. air above it and --sp-64 below the byline. An opening gap wider than the
           body's 48px block rhythm is what actually says "the header ended".
        3. the title at --fs-h1, not --fs-h1-large. Measured over the real 30 titles: at
           --fs-h1 every one sets on a single line from 1024 up and the worst at 375 is
           three lines, on one title; --fs-h1-large pushes four more titles onto a second
           line at 375 and still sets one on three.
 
      How much air. The number that matters is not this padding but the distance from the
      bar's bottom rule to the 4px mark, and this padding is only the second half of it:
      `main` already opens with --sp-64 above anything an article draws. At --sp-80 the two
      stack to about 138px at 1700 and 133 at 1500, under a bar about 60px tall — two
      large steps of nothing before the first ink, which is what reads as a hole rather
      than as an opening.
 
      Measured on the reference at 1700, from the bottom of the bar above it to the top of
      its own article header: 0px on three of its five story styles (split-screen,
      fullscreen, full-width-text-below — the header simply begins against the bar) and 94
      to 158px on the two classic ones, which hang an eyebrow block in the gap. Its heading
      lands 89.5 / 118.2 / 137.7 / 201.7px below the bar across those styles. So the
      reference's own answer spans from flush to roughly what --sp-80 would give, and the
      low end of it is where a header with no picture belongs.
 
      --sp-32 puts the total at a measured 94.8px at 1700 and 93.8 at 1500 — the
      reference's classic figure, a 43.3px lift from --sp-80, and still about twice the
      48px block rhythm inside the body, so point 2 above survives intact. It is not
      collapsed to nothing: 94px of quiet above a 4px rule is an opening, 0px would make
      the rule read as part of the bar. Measured across the range, header rule to the top
      of the kicker's mark: 64.0 at 320, 74.7 at 768, 81.6 at 1024, 88.1 at 1262, 92.9 at
      1440, 93.8 at 1500, 94.2 at 1584, 94.8 at 1700, 95.9 at 1920, 96.0 at 2560. The 320
      end is both clamps at their floor, which is right where the bar has folded onto two
      rows and the date rail has collapsed — the wrapped header wants less air above it,
      not the same. */
   .post__head {
     display: grid;
     grid-template-columns: subgrid;
     grid-column: 1 / -1;
     padding-block: var(--sp-32) var(--sp-64);
   }
   .post__head > * { grid-column: 2; }
 
   .post__kicker {
     margin: 0;
     font-family: var(--font-body);
     font-size: var(--fs-kicker);
     font-weight: 700;
     line-height: var(--lh-medium);
     letter-spacing: 0.105rem;         /* 1.68px, as measured on .article-header__category */
     text-transform: uppercase;
     font-variant-numeric: tabular-nums;
     color: var(--ppc-text);
   }
   /* The signature motif, a 4px rule in --ppc-ui. This page draws it here, on each
      thematic break, above the footnotes, beside a code plate's language label, under table
      headers, and as the contents rail's current-entry mark. */
   .post__kicker::before {
     content: "";
     display: block;
     width: 3rem;
     border-block-start: 4px solid var(--ppc-ui);
     margin-block-end: var(--sp-40);
   }
   /* No rule under these two, at rest or on hover: hover and focus are the colour step
      below. `padding-block-end` therefore paints nothing, and on an inline box it changes
      no line box and no layout: A/B'd with it removed, .post__kicker, .post__title, .prose
      and the document height are identical at 1700 and at 375, and the only number that
      moves is this link's own border box, 19.97 -> 18.00 at 1700. What that box still
      carries is the focus ring and the hit area, which reach 0.14em further down. */
   .post__kicker a { color: inherit; text-decoration: none; padding-block-end: 0.14em; }
   /* Hover is a colour step, not a rule. The reference draws its animated underline in one
      place only - the header nav - and every link in the body of a page, its writing index,
      its code list and even its year rail, simply lifts from rgb(160,32,32) to
      rgb(192,48,48) with no decoration at all. Measured over CDP on all three. */
   .post__kicker a:focus-visible { color: var(--crimson); }
   @media (hover: hover) {
     .post__kicker a:hover { color: var(--crimson); }
   }
 
   /* Forced colours override `color` at rest and on hover alike, so the colour step above
      paints nothing there. An underline is what that mode can still draw, so it is the
      hover and focus mark here, 0.3em down to clear this line's tracked capitals. */
   @media (forced-colors: active) {
     .post__kicker a:focus-visible { text-decoration: underline; text-underline-offset: 0.3em; }
   }
   @media (forced-colors: active) and (hover: hover) {
     .post__kicker a:hover { text-decoration: underline; text-underline-offset: 0.3em; }
   }
   .post__sep { margin-inline: 0.35em; color: var(--page-hairline); }
 
   /* The date sits in the byline, whole, not out in the rail. `09.08` in the 72px date
      column with the year three lines above it in the kicker would split one date across
      two places and print neither of them whole. The reference puts the whole thing on the
      byline: `by <b>name</b>` then a 2em gap then the date in a muted grey, and that is the
      shape reproduced here. The format is not the reference's — it writes 2025-01-05
      where this writes "September 8, 2026" — so longDate() supplies the text and
      `datetime` keeps the ISO form for machines. longDate is pinned to UTC; reading these
      dates in a local time zone can shift them by a day.
 
      No tabular-nums: there is no column of dates here to line up. */
   .post__date {
     padding-inline-start: 2em;     /* the reference's own gap between name and date */
     white-space: nowrap;
   }
 
   /* Stays in the measure column, on the entry title's edge. This heading is the entry you
      clicked, and it lands where that entry title was on the Writing index — measured
      0.00px apart at 320 / 768 / 1024 / 1700 / 1920, and apart only inside the rail's
      1440–1584 band. Moving it alone would also part it from its own kicker, byline and
      first paragraph, which are all in this column; moving the whole header out would give
      the article two left edges, one for the header and one for the body under it.
 
      The cost, stated rather than hidden: this <h1> does not share the header's left edge.
      Measured, wordmark to title: 96px at 1700, and 175.5px at a 1440px window, where the
      page box is pushed right for the rail and the bar stays put. */
   .post__title {
     grid-row: 2;
     margin-block: var(--sp-24) 0;     /* .article-header h1 { margin: spacing-24 0 } */
     font-size: var(--fs-h1);
     word-break: keep-all;
     text-wrap: balance;
   }
 
   /* Empty on all 30 posts today. The synthesised excerpt is deliberately NOT printed
      here: it is the article's own first sentence, and showing it directly above that
      same sentence is a duplication the reader sees at once. It goes to the metadata only:
      <meta name="description">, the JSON-LD and the feed. */
   .post__deck {
     margin-block-start: var(--sp-24);
     font-family: var(--font-display);
     font-size: var(--fs-h4);
     line-height: var(--lh-close);
     color: var(--page-fg);
     word-break: keep-all;
     text-wrap: pretty;
   }
 
   /* No tabular-nums: the only digits here are the date's, set in running text with no
      column to line up. The name carries the weight and the page's own ink, the way the
      reference sets its byline (`by` plain, the name at 600 in its own colour); 700 rather
      than 600 because that is this site's one strong weight and Lora ships it. `by` stays
      at --page-meta, so the two read as label and value. */
   .post__byline {
     margin-block-start: var(--sp-24);
     font-size: var(--fs-small);
     line-height: var(--lh-base);
     letter-spacing: 0.02em;
     color: var(--page-meta);
   }
   .post__author { font-weight: 700; color: var(--page-fg); }
 
   /* ══ Contents ════════════════════════════════════════════════════════════
      14 of the 30 posts carry one today and the design assumes all 30 eventually will (see
      the note beside showToc). It has two presentations and exactly one of them is on at
      any viewport width: the fixed rail in the left gutter from 1440px up, this collapsed
      inline list below that. The switch is a single media query further down, which turns one
      on and the other off in the same block, so "both" and "neither" are not reachable
      states — and the hairline beside the rail is generated in that same block, so it
      cannot outlive the thing it marks either.
 
      This is the narrow form: collapsed, so it costs one line of the column it sits in. */
   .toc {
     margin-block-end: var(--sp-64);
     border-block: 1px solid var(--page-hairline);
     padding-block: var(--sp-30);
   }
   .toc__summary {
     cursor: pointer;
     font-family: var(--font-body);
     font-size: var(--fs-kicker);
     font-weight: 700;
     letter-spacing: 0.105rem;
     text-transform: uppercase;
     color: var(--ppc-text);
   }
   .toc__list { margin: var(--sp-40) 0 var(--sp-30); padding: 0; list-style: none; }
   /* keep-all, for the same reason the rail below declares it: 12 of the 14 posts that
      carry contents are Korean, and a Korean line breaks between word units, never inside
      one. keep-all behaves as `normal` for the Latin headings of the other two, so one
      declaration still covers both.
      This list sits beside .prose rather than inside it, so it inherits nothing from the
      .prose rule further down and would default to `word-break: normal`. Without this
      line the longest heading (73 characters, on the cognitive-dissonance post) breaks
      inside a Korean word at phone and tablet widths, and two more on the same post do at
      375. Wrapping itself is rare - at layout widths of 320, 375, 430 and 768 with no
      classic scrollbar, 6, 3, 2 and 1 of the 136 entries wrap, and none from 1024 up - so
      the defect is rare only because the wrapping is.
 
      break-word is the escape valve and never has to fire: at 320, where the box is
      narrowest, the widest segment keep-all refuses to break is 72.1px of Hangul, or
      92.5px counting the one Latin filename among the headings, against a 256px text box.
      Measured with it: 0 in-word breaks and 0 overflow at 320 / 375 / 768 / 1024 / 1439. */
   .toc__item {
     margin-block-start: 0.4rem;
     font-size: var(--fs-medium);
     line-height: var(--lh-base);
     word-break: keep-all;
     overflow-wrap: break-word;
   }
   /* One step per level, off this document's own top level - see tocLevel(). A rule keyed
      on `data-depth="3"` would only be equivalent while the filter stopped at depth 3; the
      list reaches one level deeper, where h3 and h4 would share an indent. That would
      flatten tso's six ### subsections onto their ## parents, and sysmon's seven and
      journalctl's four with them. */
   .toc__item[data-level="1"] { padding-inline-start: var(--sp-40); }
   .toc__item[data-level="2"] { padding-inline-start: calc(2 * var(--sp-40)); }
   /* No underline at rest or on hover. The link is set in the page's ink, and hover and
      focus are the colour step to --crimson, the same gesture as the kicker's. The 0.07em
      of `padding-block-end` paints nothing; on an inline box it moves no line box, and
      what it still extends is the link's own border box, which the focus ring and the hit
      area follow. */
   .toc__item a { font-weight: 400; text-decoration: none; color: var(--page-fg);
     padding-block-end: 0.07em; }
   .toc__item a:focus-visible { color: var(--crimson); }
   @media (hover: hover) {
     .toc__item a:hover { color: var(--crimson); }
   }
 
   /* Forced colours override `color` at rest and on hover alike, so the colour step above
      paints nothing there. An underline is what that mode can still draw, so it is the
      hover and focus mark here. */
   @media (forced-colors: active) {
     .toc__item a:focus-visible { text-decoration: underline; }
   }
   @media (forced-colors: active) and (hover: hover) {
     .toc__item a:hover { text-decoration: underline; }
   }
 
   /* ── the rail ────────────────────────────────────────────────────────────
      The reference site floats a fixed #leftnav at `left: calc(50% - 31em)` and slides it
      to `left: -10em` under 80em. Same behaviour, positioned off this grid's own tokens
      rather than a hand-fitted em value.
 
      The geometry is declared once, on :root, and three rules read it: the rail's own
      inline-size, the rail's --toc-x inside the switch, and the page box's start margin.
      The hairline that runs beside the rail reads only --toc-gap from it and otherwise
      follows the page box through <main>. Nothing below restates any of it, which is the whole reason these
      cannot drift apart.
 
      `100%`, never `100vw`. Every consumer of these properties resolves a percentage
      against the initial containing block — the fixed rail directly, <main> through the
      body's content box, which is the same width — and the ICB excludes a classic
      scrollbar. `100vw` includes it unless the root carries `scrollbar-gutter: stable` and
      the engine then drops the gutter from vw: base.css sets the property, but engines
      differ on the second half, so the geometry does not hang on it. Without it, a real 15px scrollbar
      at 1440 comes straight out of --toc-edge in a `100vw` formula and leaves the rail 1px
      from the viewport edge. Written in `100%` the edge is 16.00px with the scrollbar and
      16.00px without.
 
      Where it sits. --page-left is the x of the page box's left edge and it is the larger
      of two demands: the centred position every other page uses, and whatever the rail
      needs in order to stand --toc-edge clear of the viewport. From 1584 up the centred
      position wins and the max() is inert; from 1440 to 1583 the rail wins and the page
      box is pushed right, which is the shift. The rail is laid into the gutter inline-end
      first, --toc-gap clear of the date rail's left edge, so it stays pinned to the page
      box rather than to the viewport: widen --w-content and the rail slides outward with
      the text instead of drifting over it.
 
      Its width is a floor, not a leftover. A centred gutter has only 168px to spare at the
      switch, too narrow to read; 240px is guaranteed wherever the rail is painted (see
      .toc-rail__link for what decided the number), and the gutter grows it to 320px where
      the gutter is wide enough to pay for the growth out of empty space.
 
      The clearance it must never lose is geometric rather than hoped for, and on both
      sides. Its inline-end edge is --toc-gap from the page box by construction, since
      `right` is written off --page-left and nothing else; its inline-start edge is exactly
      --toc-edge from the viewport whenever the rail is what set --page-left, and further in
      when the centred position did. The rail cannot reach the 72px date rail, let alone the
      measure, at any viewport. */
   :root {
     --toc-gap: 1.5rem;        /* 24px, = .post's --rail-gap: one column gutter */
     --toc-edge: var(--sp-40); /* 16px of air at the viewport edge */
     --toc-w-min: 15rem;       /* 240px, the floor  — reached at 1440, held to 1584 */
     --toc-w-max: 20rem;       /* 320px, the cap    — reached at 1744 */
 
     /* Three terms, and they are written in the order they bind: the cap past which more
        width buys no reading, the floor the reading needs raised over what a centred gutter
        happens to leave over, and the room that actually exists. The third is the one that
        keeps the guarantee geometric rather than hopeful, and it is not theoretical - the
        floor is in rem, so a reader on Chrome's 24px root asks for a 360px rail out of a
        gutter that cannot seat one. Measured at 12 / 14 / 16 / 20 / 24px roots against
        320 / 768 / 1024 / 1440 / 1584 / 1700 / 1920, it binds in exactly one of those
        cells, 24px at 1440: at a 16px root it is 352.5px against a 240px ask at 1440 and
        grows from there, so it is inert at every width the rail is painted at. Where it
        does bind the page box keeps its full --w-page and ends up flush against --root-pad
        on its right (measured 1072px and 27.22px), and the rail still keeps its --toc-edge
        on the left; without it the rail would run off the left of the screen instead. */
     --toc-rail-w: min(
       var(--toc-w-max),
       max(
         var(--toc-w-min),
         calc((100% - var(--w-page)) / 2 - var(--toc-gap) - var(--toc-edge))
       ),
       calc(100% - var(--w-page) - var(--root-pad) - var(--toc-gap) - var(--toc-edge))
     );
     --page-left: max(
       calc((100% - var(--w-page)) / 2),
       calc(var(--toc-edge) + var(--toc-rail-w) + var(--toc-gap))
     );
   }
 
   .toc-rail {
     /* The rail's inline-end coordinate and its top. Both are local to this box: the
        hairline beside it is generated on <main> and reads neither (see the rule block
        inside the switch). Anything that moves the rail moves --toc-x rather than `right`,
        so that the slide has one coordinate to interpolate.
 
        --toc-y is the rail's own top and nothing else's. The list keeps the inset because
        a list wants air under the header; the line does not, because a line that starts
        short of the header reads as cut off at its top. Measured from the header's bottom
        border at 1440 / 1700 / 1920 / 2560: about 43 / 52 / 60 / 60px of clearance to the
        top of the rail. */
     --toc-x: 100%;
     --toc-y: var(--sp-120);
 
     position: fixed;
     z-index: 1;
     top: var(--toc-y);
     inline-size: var(--toc-rail-w);
     /* Parked: right edge on x = 0, entirely left of the viewport. This is the off state
        and it is also the default, so a page that never reaches 1440px never paints it.
        Leftward overflow is not scrollable in an LTR document, so the parked box adds no
        horizontal scroll - verified at 320 / 375 / 768 / 1024 / 1262 / 1366 / 1439, with
        and without a classic scrollbar. */
     right: var(--toc-x);
     visibility: hidden;
     /* Distance is --page-left - --toc-gap, 256px at the switch. `visibility` interpolates
        as a step that counts as visible for any progress in (0,1), so one transition keeps
        the box painted for the whole slide out and shows it immediately on the way in.
        The hairline does not ride this: it is generated by the switch rather than moved by
        it, so it appears and disappears at the boundary instead of travelling.
        prefers-reduced-motion is handled twice over: the global rule at the foot of
        base.css kills every transition with !important, and the local rule below says so
        where a reader of this block will look. */
     transition: right 0.45s ease, visibility 0.45s;
 
     /* The box stays exactly as tall as its list, capped at the viewport. The 240px floor
        takes most of the overflow out: measured at 1440x900, where the box has 754px of
        room, the lists that scroll inside themselves go from three at 168px to one at 240.
        The one left is how-to-win, 1,014px of list, and it still scrolls at every rail
        width measured up to 392px — so this is not decoration and neither is the
        scroll-spy's scrollIntoView. Capping the box rather than sizing it to the viewport
        is also what keeps the gutter under the list clickable (hit-tested at x = 200,
        y = 400 / 700 / 1000 / 1200 on journalctl at 1700: the page, not this nav) and keeps
        `rail.scrollHeight > rail.clientHeight` — the guard the scroll-spy reads — meaning
        what it says. */
     max-block-size: calc(100dvh - var(--toc-y) - var(--sp-48));
     overflow-y: auto;
     overscroll-behavior: contain;
 
     /* No scrollbar, and no gradient in its place either.
 
        The bar itself first: a thin scrollbar paints an 11px track hard against this box's
        inline-end edge, which is exactly where the hairline is. Measured on how-to-win at
        1700x860 with `scrollbar-width: thin` and a --sand-dark thumb: thumb at
        x = 299-304 (#eed6aa), rule at x = 306, two verticals 2px apart running the same
        700px of gutter. At a glance that is a double rule, and the thinner of the two is
        the one the design means. The other candidates do not survive the same look.
        Moving it (direction: rtl on the scrollport) parks the identical bar on the other
        edge, 16px off the viewport, where it has even less to belong to; restyling cannot
        make an 11px bar not a bar; and the need for it cannot be removed — how-to-win is
        1,014px of list against a 754px box at 1440x900, and 28 entries is the corpus's own
        worst case, not a hypothetical.
 
        No gradient either. .code pre's four-gradient overflow cue, turned 90° for this box,
        is two `local` masks in --page-bg that scroll with the list and two `scroll` shadows
        fixed to the box, the mask covering the shadow at whichever end has no more list to
        show. On .code pre the shadow falls on a --sand plate that is already a surface, and
        it reads as depth; here it would fall on the page ground, where a 12px shadow across
        a 240px column reads as a grey band lying over the list — with the list scrolled
        even a little, that band sits behind the word CONTENTS. An overflow cue that has to
        be explained is not one.
 
        The masks alone would do nothing: a background paints behind text, so a --page-bg
        layer over --page-bg ground is invisible by construction — their whole job in that
        cue is covering the shadow at the two ends. The top edge clips whatever entry it
        lands on (fading the ink itself would take mask-image), and the scroll-spy's
        `rail.scrollTop = 0` at the document top means the resting state of the rail is its
        own top, with CONTENTS and entry one whole.
 
        What the hidden scrollbar costs is dragging, and only dragging: the list is still
        reachable by wheel, by trackpad, by keyboard (every entry is a link, and tabbing
        through scrolls the port) and by the scroll-spy's own scrollIntoView. */
     scrollbar-width: none;
 
     /* The +1px is the column the hairline is painted in: the line lands on the rail's own
        last pixel (see the rule block inside the switch), so this keeps --sp-30 of clear
        space between the text and the line. */
     padding-inline-end: calc(var(--sp-30) + 1px);
     font-family: var(--font-body);
 
     /* base.css styles the site navigation by element — `nav { display: flex; gap:
        --sp-50; flex-wrap: wrap }` — so any <nav> on the site is a wrapping flex row with
        a 24px gap unless it says otherwise. Without this line the title and the list
        become two flex items and the gap stacks on top of the title's own margin. Stated
        rather than inherited, because an element selector that reaches a second nav is
        the kind of thing that is invisible until something moves 24px. */
     display: block;
   }
 
   /* `scrollbar-width: none` covers Chrome 121+, Firefox and Safari 18.2+; this covers the
      WebKit and Blink builds below those. base.css already reaches for the same pseudo on
      .code pre, so it is the file's own idiom rather than a second mechanism. */
   .toc-rail::-webkit-scrollbar { inline-size: 0; block-size: 0; }
 
   /* The kicker idiom, at --fs-small rather than --fs-kicker: --fs-kicker is declared on
      .post and the rail is deliberately not inside .post. No 4px rule above it - that mark
      opens a section of the page, and this is furniture beside one. */
   .toc-rail__title {
     margin: 0 0 var(--sp-30);
     font-size: var(--fs-small);
     font-weight: 700;
     line-height: var(--lh-medium);
     letter-spacing: 0.105rem;
     text-transform: uppercase;
     color: var(--ppc-text);
   }
 
   .toc-rail__list { margin: 0; padding: 0; list-style: none; }
 
   /* The 4px mark, reused as a position marker instead of a section opener. Laid down
      transparent on every row so that marking one costs no layout shift. */
   .toc-rail__item {
     border-inline-start: 4px solid transparent;
     padding-inline-start: var(--sp-30);
   }
   .toc-rail__item + .toc-rail__item { margin-block-start: 0.4rem; }
   .toc-rail__item[data-level="1"] .toc-rail__link { padding-inline-start: var(--sp-30); }
   .toc-rail__item[data-level="2"] .toc-rail__link { padding-inline-start: calc(2 * var(--sp-30)); }
   .toc-rail__item:has(> [aria-current]) { border-inline-start-color: var(--ppc-ui); }
 
   /* Two lines, then an ellipsis. Clamping keeps the list scannable; the link text is
      untouched, so the accessible name is always the full heading however few lines are
      painted, and hover or keyboard focus lifts the clamp for the reader too.
 
      240px is the rail's floor, and this block is the reason for the number. Measured in
      the built page over all 136 entries on the 14 posts that carry contents, at 1440x900
      (13.88px type), rail inline-size against entries whose text does not fit two lines,
      against entries that fit on one, and against the number of DOCUMENTS hiding any
      heading text at all:
 
          rail       168  192  200  216  240  256  280  312  392
          clamped     25   10    8    5    3    2    2    1    0
          one-line    58   73   76   88   96  105  113  123  131
          documents    6    6    4    2    1    1    1    1    0
 
      The deciding row is the last one, not the first. At 168px — what a centred gutter
      leaves over at the switch — six of the 14 documents hide heading text. 200 clears
      bind9 and 안전하고, 216 clears sysmon and tso, and 240 clears how-to-win: 13 of the 14
      then print every heading in full. Everything past 240 buys exactly one more document,
      인지부조화이론, whose two longest headings are 57 and 73 characters against a corpus
      median of 18 and which does not print them whole at any width measured below 392px —
      a rail wider than the date rail, its gutter and a quarter of the measure together.
      Those two are a writing problem, not a width.
 
      So 240 is a floor and not a cap, and the geometry above is written to guarantee it by
      moving the page box rather than by hoping for a wide viewport. A 240px cap on what a
      centred gutter has spare would be exactly backwards: it changes nothing in this table
      for anyone below 1584px, and below 1584 is precisely where the rail is starved. Where
      the gutter is wide enough to pay for more out of empty space it grows to the 320px
      cap, and that is worth having but is not what the floor is for — rendered at 1920,
      where it reaches the cap: 123 of the 136 entries on one line and one entry clamped.
 
      What else the floor buys, at 1440x900 where the box has 754px of room: the lists that
      scroll inside themselves go 3 at 168 to 2 at 192 and 200 to 1 from 216 up. The one
      left is how-to-win, 1,014px of list at 240 and still scrolling at every width
      measured up to 392, so the scroll-spy's scrollIntoView is still doing work — do not
      delete it on the strength of the floor.
 
      keep-all is kept, and it holds with room to spare. The narrowest text box the rail
      offers is the level-2 entry at the deepest indent, 192.1px at the 240px floor against
      120.1px at 168, and the widest run that keep-all refuses to break is a property of
      the type, not of the box: 106.9px for sysmon_view.py, a Latin filename rather than one
      of the Korean 어절 the rule exists for, and 83.3px for the widest Hangul run, 84.1px at
      1920 where the type reaches its 14px cap. That is 85px of slack, where 168 would leave
      13. (Set bold as the current entry, the filename is 111.3px.) Note what the segments are: keep-all still takes the break opportunity in front of
      an opening parenthesis, so a nine-syllable run that brackets a gloss halfway through is
      two segments and not one, and the whitespace-delimited word is the wrong unit to
      measure. These figures come from wrapping each heading in a 1px box with break-word
      off and reading the extent of every line it produced. Measured over all 136 entries
      at every column of the table above: 0 entries overflow their box and 0 break inside a
      Korean word at any of them, so break-word never fires. It stays as the escape valve
      for anything past that.
 
      The clamp stays at two lines. At 240 exactly three entries exceed it and all three are
      in 인지부조화이론; a third line would spend the uniform one-to-two-line rhythm — the thing
      that makes the list scannable — on one document. */
   .toc-rail__link {
     display: -webkit-box;
     -webkit-box-orient: vertical;
     -webkit-line-clamp: 2;
     overflow: hidden;
     font-size: var(--fs-small);
     font-weight: 400;
     line-height: var(--lh-base);
     text-decoration: none;
     color: var(--page-meta);
     word-break: keep-all;
     overflow-wrap: break-word;
     /* The other half of the `nav a` inheritance. base.css sets the site nav in
        synthesised small-caps — right for five one-word section names across the top of
        the page, wrong for sentence-shaped headings. The border and padding resets
        override nothing in base.css as it stands, where `nav a` carries no bottom border
        or padding; they keep one off the rail if nav links are given one, since a 4px
        border plus 2px of padding would be 6px of dead space under each entry, 168px down
        how-to-win's 28. The rail draws its own current-item mark on the inline edge, so it
        wants neither. */
     font-variant-caps: normal;
     border-block-end: 0;
     padding-block-end: 0;
   }
   /* Hover and focus are the colour step to --crimson, the same gesture as the kicker and
      the inline list. The hover half sits inside the pointer gate: on a touch screen a
      bare :hover would leave one rail entry coloured until the next tap elsewhere, which
      on a rail of up to 28 entries reads as a wrong current-item mark. The clamp-lift at
      the end of this group (`.toc-rail__link:hover, .toc-rail__link:focus-visible`) is
      deliberately left ungated -- it is a way to read a clipped heading, not a way to mark
      one, and gating it would take that away from a touch reader entirely. */
   /* The ring is drawn inside the link: the rail scrolls, and a ring outside it is cut off
      by the scrollport on the last entry and on any entry at the edge of a scrolled rail. */
   .toc-rail__link:focus-visible { color: var(--crimson); outline-offset: -3px; }
   @media (hover: hover) {
     .toc-rail__link:hover { color: var(--crimson); }
   }
 
   /* Forced colours override `color` at rest and on hover alike, so the colour step above
      paints nothing there. An underline is what that mode can still draw, so it is the
      hover and focus mark here, at the 0.18em offset the prose uses. */
   @media (forced-colors: active) {
     .toc-rail__link:focus-visible { text-decoration: underline; text-underline-offset: 0.18em; }
   }
   @media (forced-colors: active) and (hover: hover) {
     .toc-rail__link:hover { text-decoration: underline; text-underline-offset: 0.18em; }
   }
   .toc-rail__link[aria-current] { color: var(--ppc-text); font-weight: 700; }
   /* Reading the clipped half of a heading should not need a pointer. */
   .toc-rail__link:hover,
   .toc-rail__link:focus-visible { -webkit-line-clamp: none; }
 
   /* ── which presentation ──────────────────────────────────────────────────
      1440px. What the switch has to guarantee is that pushing the page box out to
      --page-left still leaves the measure a gutter on its other side:
 
          vw >= --toc-edge + 240 + --toc-gap + --w-page + right gutter
             =     16      + 240 +    24     +   1024   +      96      =  1400px
 
      1440 clears that with 40px to spare and leaves 136px on the right. It is also the
      width at which a centred page box first leaves room for a 168px rail,
 
          vw >= --w-page + 2 x (168 + --toc-gap + --toc-edge)  =  1440px
 
      and it is kept there rather than lowered to 1400 so that every width either
      presentation was checked at stays on the same side of the switch. 96px is the
      article's own date rail plus its gutter: the measure keeps the same clearance to its
      right as it has to its left inside the page box. The width below which the document
      would actually scroll sideways is lower still - --toc-edge + 240 + --toc-gap +
      --w-page + --root-pad, about 1327px.
 
      Measured rail width: 240.0px at 1440, held to 1584, 256.0 at 1616, 320.0 from 1744 up
      where it holds at the cap. Below the switch the rail parks off-screen and the inline
      list is the contents. This is the one place either presentation is turned on or off,
      so they cannot both be showing and cannot both be hidden — checked in a browser at 21
      widths from 320 to 2560, both sides of the switch included, with and without a classic
      scrollbar, and on a post with no contents at all, where neither appears.
 
      If --w-content moves, this literal moves with it - a media query cannot read a
      custom property, which is why the rail's own geometry above is written so that a
      stale literal here can only park the rail early, never push it onto the text or the
      page box off the screen. */
   @media (min-width: 1440px) {
     .toc-rail {
       --toc-x: calc(100% - var(--page-left) + var(--toc-gap));
       visibility: visible;
     }
 
     /* The page box moves out to --page-left. The header does NOT go with it.
 
        This rule is a no-op from 1584 up: --page-left IS the centred position there, so
        `--page-left - --root-pad` is the margin `margin-inline: auto` was already
        computing. It bites only in the 1440-1584 band.
 
        A second rule here could restate base.css's header padding against --page-left
        and keep the wordmark on the page box's left edge through the shift. It does not
        exist, and the reason is what the shift looks like from the reading chair rather
        than from the arithmetic. base.css's padding is symmetric by construction;
        --page-left is not, because it is a max() that grows on the LEFT only — so inside
        the band such an override makes the bar asymmetric and slides the whole thing
        right, on article pages and nowhere else. Every other route keeps a still bar, so
        the one place a reader spends real time would be the one place the furniture moves
        under them. A bar that is in the same place on every page is worth more than a left
        edge shared with body text across a 144px band, and that is the trade this file
        takes. base.css states the fixed-bar contract; nothing on an article page may
        restate the header's padding.
 
        What it costs, stated rather than discovered: inside the band an article's page box
        starts up to 79.5px right of the wordmark above it — measured 79.5 at a 1440px
        window, 49.5 at 1500, 7.5 at 1584, 0.00 at 1700 and up and 0.00 at 1262 and below.
        Bounded by the same arithmetic as everything else here: --page-left is a max()
        against the centred position, so it is zero the moment a centred gutter can seat
        the rail, and never negative.
 
        Keyed on the ARTICLE, not on the rail. Keyed on `main:has(.toc-rail)`, the gutter
        would be reserved only where a rail is actually painted, and the price would be a
        step: moving between a post with contents and one without would move the left edge
        by up to 72px inside the band (79.5 with a classic scrollbar). Under the premise
        this page is built on — every post gets headings — the two forms converge, because
        every article ends up with a rail; keying on .post-shell arrives at that steady
        state early instead of shipping a step that exists only for as long as 16 documents
        are missing their headings.
 
        What it costs meanwhile, stated rather than discovered: those 16 get an empty 280px
        left gutter between 1440 and 1584, and their text sits up to 72px right of the
        Writing index entry it was clicked from. It is the same divergence every post with
        a rail has, bounded by the same arithmetic (--page-left is a max() against the
        centred position, so it is 0 from 1584 up and 0 below 1440), and it is uniform
        across all 30 articles instead of stepping between them. The rule below is keyed on
        the rail: a hairline with nothing beside it is a stray line, so the gutter is
        reserved on every article and marked on none that has no list to mark. */
     main:has(.post-shell) {
       /* Containing block for the rule below, and nothing else reads it. `position:
          relative` with `z-index: auto` establishes no stacking context, so the rail's own
          `z-index: 1` still resolves against the root; and `position: fixed` ignores a
          relative ancestor entirely, so the rail does not become a child coordinate
          system. Verified at 1440 / 1700 / 1920: the rail's computed inline-end edge is
          unchanged to the pixel. */
       position: relative;
       margin-inline-start: calc(var(--page-left) - var(--root-pad));
       margin-inline-end: auto;
     }
 
     /* ── the rule ──────────────────────────────────────────────────────────
        The hairline down the rail's inline-end edge. It is a box in the DOCUMENT rather
        than a box in the viewport, and that is what keeps its top joined to the header.
 
        A fixed line starts too low. `position: fixed` with `inset-block: var(--toc-y) 0`
        begins --sp-120 down the VIEWPORT — 103px at 1440, 112 at 1700, 120 from 1920 up —
        while the header is about 60px tall: on how-to-win at 1700x860 that puts the header
        rule at y = 59 and the line's top at y = 112, 52px of empty gutter between them.
        Scrolling does not close it either: a viewport-fixed line brings the band back at
        every scroll position, by then with nothing above it at all because the header is
        `position: static` and has scrolled away.
 
        Why no fixed box can be right here. It has one top, and the top this line needs is
        in two places: at the header's bottom edge while the header is on screen, and at
        the viewport's own top once it is not. An absolutely positioned box whose
        containing block begins at the header is both of those for free — scrolling carries
        its top off the top of the screen and the line simply runs to the edge.
 
        So: `inset-block: 0` inside <main>. Nothing here names a height, and that is the
        point. <main> is in normal flow directly under a full-bleed, `position: static`
        header and opens with padding rather than margin, so no margin collapses through
        it and main's padding box begins EXACTLY at the header's bottom border. The number
        that edge takes is 59.70px at 1440 and 59.88 at 1700 — 16 + a 26.70/26.88 shared
        line box + 16 + a 1px border — but it is never written down here, so --sp-40,
        --fs-nav or --lh-medium can all move and the line follows the header with no edit
        in this file. `inset-block-end: 0` is the same trade at the other end: main's
        padding box ends with its --sp-120 of bottom padding, directly above the site
        footer, so at the foot of the document the line stops where the footer starts.
 
        What it costs: the line is as long as <main> — nearly 4,000px on journalctl at 1700
        — instead of one screen tall, so it travels while the fixed rail stands still. A
        1px vertical line that spans the whole viewport at every scroll position is
        indistinguishable from one pinned to it — there is no feature on it that can be
        seen to move — and in exchange the top is right at scrollY 0 and at every scrollY
        after it. Measured on journalctl and how-to-win at 1700x860, at scrollY 0 / 400 /
        800 / 1200 and at the foot of each: painted from the header's edge, or from y = 0
        once past it, down to the viewport floor, or to the footer's top at the foot.
 
        It cannot be a pseudo-element of .toc-rail. .toc-rail is `position: fixed`, which
        makes it the containing block for any absolutely positioned descendant, so an abs
        child of it would be measured from the list box and clipped back to the list's own
        height. Hung on <main> the two are unrelated boxes, and the rail is free to stay
        fixed.
 
        Where it sits across is derived, not restated. The rail's inline-end edge is
        --toc-gap inside the page box's left edge by construction, and main's padding box
        begins --root-pad OUTSIDE that same edge (the margin above, plus base.css's
        `padding-inline: --root-pad`), so the line stands at --root-pad - --toc-gap from
        main's inline start, less its own 1px. Measured: -1.53px at 1440 and -1.00px from
        1488 up, where --root-pad reaches its 24px cap and cancels --toc-gap exactly — so
        across almost the whole band the line is simply the pixel before <main>. Both terms
        are :root tokens, --page-left is stated once, and the line tracks the page box
        because <main> does. The -1px puts the line on the rail's own last pixel rather
        than in the gap past it; the rail's padding-inline-end reserves that pixel (see
        .toc-rail). Measured at 1700x860: painted column x = 306, against a rail edge at
        306.5.
 
        Declared inside the switch and nowhere else. It has no parked state — a line whose
        x is measured from <main> would stand in the left margin at every width below
        1440 — so it is simply not generated there, and this media query is the one place
        where any part of either presentation is turned on or off. The one thing that
        costs is the slide: crossing 1440 the rail slides in from the left and the line
        appears at once beside it. That is a resize-only artefact, against an off-screen
        box on every one of these pages at every width. */
     main:has(.toc-rail)::before {
       content: "";
       position: absolute;
       inset-block: 0;
       inset-inline-start: calc(var(--root-pad) - var(--toc-gap) - 1px);
       inline-size: 1px;
       /* The header's rule, not the page hairline. Both lines frame the same reading
          column, so they are one mark in two places; --page-hairline also measured 1.93:1
          against --page-bg, which is under the 4.5:1 a 1px line needs to read as drawn. */
       background: var(--crimson);
       /* The empty gutter beside the list belongs to the page, not to this nav. */
       pointer-events: none;
     }
 
     .toc { display: none; }
   }
 
   /* The line is a painted box, and this is the one mode that does not keep it.
 
      Forced colours replace `background-color` with Canvas and `border-color` with a system
      colour, so a border survives Windows High Contrast Mode and a background does not.
      Measured in this page with forced-colors emulated, two 1px strips of one colour laid
      side by side over the gutter: as a border it paints
      rgb(0, 0, 0), as a background rgb(255, 255, 255) — the Canvas it sits on, which is to
      say nothing at all.
 
      So the line is drawn as a border here and only here, with no colour of its own so the
      UA forces one. box-sizing is border-box, so the 1px border is the same 1px box in the
      same place; nothing else about the geometry moves. Outside the switch above rather
      than inside it,
      because a nested @media is not worth relying on through the build; the selector only
      matches an element the switch has already generated. */
   @media (forced-colors: active) {
     main:has(.toc-rail)::before {
       background: none;
       border-inline-end: 1px solid;
     }
 
     /* The rail hides its scrollbar and paints no overflow cue of any kind, so the only
        thing saying the list continues is the entry the top edge clips. That trade is
        legible at normal contrast; a High Contrast reader should not have to take it. So
        the scrollbar comes back here, in the one mode where a second vertical bar is the
        lesser problem — it is drawn in system colours against a system Canvas, so it does
        not read as a tan twin of the rule the way a --sand-dark thumb would. */
     .toc-rail { scrollbar-width: thin; }
     .toc-rail::-webkit-scrollbar { inline-size: auto; block-size: auto; }
 
   }
 
   @media (prefers-reduced-motion: reduce) {
     .toc-rail { transition: none; }
   }
 
   /* Fixed furniture has no place on paper. A paper page is normally narrower than the
      switch, so the inline list is already the one showing; this block is what keeps the
      invariant true when it is not, since `print` and `min-width: 1440px` can both match
      and only this one may win. */
   @media print {
     .toc-rail { display: none; }
     /* `display: none` on the rail does not take the rule with it: the rule is a
        pseudo-element of <main>, and <main> prints. `content: none` generates no box at
        all. */
     main:has(.toc-rail)::before { content: none; }
     .toc { display: block; }
 
     /* `display: block` shows the <details>, not the list inside it. A closed <details>
        hides its own content, and the print pipeline does not open it: measured with
        Page.printToPDF on journalctl without the rule below, 405,092 bytes with the summary
        closed against 423,023 for the same page with the list opened by hand. So what
        paper gets from the line above alone is the word CONTENTS between two rules and
        nothing under it — the one presentation left on paper, printing none of itself.
 
        ::details-content is the UA's own box for that hidden content, so this prints the
        list without touching the open state on screen: no `open` attribute to set and
        restore, no beforeprint handler to depend on, and nothing at all outside @media
        print. An engine without the pseudo-element ignores the line and prints the
        summary alone. The marker goes with it — a disclosure triangle in front of a
        list that is already there is an instruction to click, on the one medium where
        nothing can be. */
     .toc::details-content { content-visibility: visible; }
     .toc__summary { list-style: none; }
   }
 
   /* ══ Body ════════════════════════════════════════════════════════════════ */
   .prose {
     font-size: var(--fs-body);
     line-height: var(--lh-large);
     /* Korean breaks between 어절, never inside one. keep-all behaves as `normal` for
        Latin, so it is safe for the whole column; break-word is the escape valve for a
        bare URL longer than the measure. */
     word-break: keep-all;
     overflow-wrap: break-word;
   }
   .post[lang='ko'] .prose { line-height: var(--lh-ko); }
 
   /* Gazette block rhythm, as measured:
        :where(.is-layout-constrained) > *  → spacing-48
        :where(p + p)                       → spacing-24
        :where(.wp-block-heading + p)       → spacing-24 */
   .prose > * { margin-block-start: var(--sp-48); }
   .prose > :first-child { margin-block-start: 0; }
   /* Paragraph to paragraph is the reference's .7em (--sp-para, 11.2px at this 16px body),
      not the Gazette's 24px. The two selectors take separate declarations because they
      are two different joins: a paragraph continuing a paragraph is the tightest join in
      the document, and a heading handing off to its own first paragraph is a section
      opening, which keeps --sp-24. The 48px block rhythm, the 64px above an h2/h3 and the
      list and figure gaps are all written off their own tokens and none of them reads
      --sp-para. */
   .prose > p + p { margin-block-start: var(--sp-para); }
   .prose > :is(h2, h3, h4, h5, h6) + p { margin-block-start: var(--sp-24); }
   /* A heading opens a section, so it gets more air than an ordinary block. */
   .prose > :is(h2, h3) { margin-block-start: var(--sp-64); }
   .prose > :is(h2, h3, h4, h5, h6) + :is(h3, h4, h5, h6) { margin-block-start: var(--sp-24); }
   .prose > :is(h2, h3, h4, h5, h6) { scroll-margin-block-start: var(--sp-40); }
   .prose p { text-wrap: pretty; }
 
   /* ── staccato ────────────────────────────────────────────────────────────
      Measured on the real corpus at this 928px column and 16px body: 532 of 789
      paragraphs (67%) set as a single line, and 19 documents are over half —
      dont-assume and journalctl are at 100%, i-have-to has 66 one-liners out of 69.
      proseShape()'s 60-character threshold does not move with the column or the type
      size: it reads the source, not the rendered line.
      A one-line Korean paragraph is a 28px line over an 11px gap; fifty in a row is not
      prose, it is verse. Those documents take the book setting instead: the indent marks
      the paragraph and the gap goes to zero. Indent OR gap, never both — two signals for
      one boundary. proseShape() picks them, 10 today; nothing is hand-tagged. 1em is the
      conventional Korean indent of one full square, a little wider than a KoBody
      syllable's 0.815em advance. */
   .post[data-rhythm='staccato'] .prose > p + p {
     margin-block-start: 0;
     text-indent: 1em;
   }
   /* A paragraph opening after any other block already has 48px of air above it;
      indenting it as well would mark one boundary twice. */
   .post[data-rhythm='staccato'] .prose > :not(p) + p { text-indent: 0; }
 
   /* ── links ───────────────────────────────────────────────────────────────
      Colour, not weight or underline (base.css): a prose link is crimson at the weight of
      the text around it and draws no rule. This offset is for the one prose link that
      does draw one, a footnote marker or backref on hover (see footnotes below); <ins> and
      <abbr> repeat it, so every underline in the prose sits at one depth. */
   .prose a { text-underline-offset: 0.18em; }
 
   /* ── emphasis ────────────────────────────────────────────────────────────
      Pretendard ships no italic, so a browser would synthesise an oblique by shearing
      Hangul — which skews the vertical stems the syllable block is built on. All 14 <em>
      runs in the corpus are on Korean pages, and eight of them already sit inside
      quotation marks, where the slant says nothing the marks do not. 500 is a real
      instance on the shipped face's 400–700 weight axis and does not collide with strong
      at 700. */
   .prose em { font-style: italic; }
   .post[lang='ko'] .prose em { font-style: normal; font-weight: 500; }
 
   /* ── inline semantics ────────────────────────────────────────────────────────
      Six elements Markdown has no syntax for, which an author therefore writes as raw HTML.
      satteri-guard lets them through (rawHtml is off, so they ship as opaque raw nodes),
      and without this block every one of them renders at its UA default -- which on this
      ground means a browser-yellow <mark> and a <kbd> in the engine's own monospace at full
      size. Zero in the corpus today; all six are one keystroke away in any technical post,
      and the whole cost of covering them is this block.
 
      <del> is deliberately absent: strikethrough is the one of these that Markdown DOES have
      syntax for (~~x~~), the UA line-through is correct, and a colour change would say
      something the author did not. */
   .prose kbd {
     font-family: var(--font-mono);
     font-size: 0.875em;
     /* Same plate, border and padding as the inline code span below -- a key and a code span
        are the same kind of object on the page, and a second treatment for them would be a
        second vocabulary. What carries the difference is the element itself, which is what a
        screen reader announces. */
     background: var(--sand);
     border: 1px solid var(--sand-dark);
     padding: 0.1em 0.3em;
   }
   /* The palette has no yellow, and --ppc-wash -- the token the ladder nominally reserves
      for emphasis grounds -- is capped at 1.25:1 against the page by design. Rendered, that
      is not a highlight: #f7ebeb on #fffbf4 is 1.13:1, a band the eye does not find.
      --sand is the one ground on this page that is provably legible at a glance, because
      every code plate and every inline code span already sits on it, and black over it is
      18.2:1. The padding is what turns a fill that hugs the glyphs into a marked run;
      leaving out the code span's 1px border and mono face is what keeps it from reading
      as code. */
   .prose mark { background: var(--sand); color: inherit; padding: 0.1em 0.2em; }
   /* A dotted underline is the one abbreviation convention that survives without a tooltip,
      and `help` is the cursor that says a title is there to be read. */
   .prose abbr[title] {
     text-decoration: underline dotted;
     text-underline-offset: 0.18em;
     cursor: help;
   }
   /* line-height: 0 is what keeps a footnote marker or an exponent from opening up the line
      it sits in; the offsets then place the glyph without the UA's `vertical-align`, which
      is what does the opening. */
   .prose :is(sub, sup) {
     font-size: 0.75em;
     line-height: 0;
     position: relative;
     vertical-align: baseline;
   }
   .prose sup { inset-block-end: 0.45em; }
   .prose sub { inset-block-start: 0.25em; }
   /* <ins> is underlined by the UA. The offset matches the link rule's, so it sits on the
      same line as every other underline in the prose, and the weight stays at the body's. */
   .prose ins { text-decoration-thickness: from-font; text-underline-offset: 0.18em; }
   .prose small { font-size: var(--fs-medium); color: var(--page-meta); }
 
   /* ── quotes ──────────────────────────────────────────────────────────────
      .wp-block-quote::before is an 8px bar with a 1rem gap, as measured. Its
      spacing-120 block margins are for pull quotes; the quotes in this corpus are
      citations and set-off notes inside running text, so they keep the ordinary 48px
      rhythm and the body size. */
   .prose blockquote {
     display: grid;
     grid-template-columns: calc(8px + 1rem) minmax(0, 1fr);
     margin-inline: 0;
   }
   .prose blockquote::before {
     content: "";
     grid-column: 1;
     grid-row: 1 / span 20;
     border-inline-start: 8px solid var(--ppc-ui);
     margin-inline-end: 1rem;
   }
   .prose blockquote > * { grid-column: 2; }
   .prose blockquote > :first-child { margin-block-start: 0; }
   /* A quoted paragraph is still a paragraph, so it takes --sp-para with the rest. This
      rule exists only to reach inside the blockquote, which `.prose > p + p` cannot. */
   .prose blockquote p + p { margin-block-start: var(--sp-para); }
 
   /* ── lists ───────────────────────────────────────────────────────────────
      113 bullets and 59 numbers across the corpus, nearly all inside technical
      documents where a list is a procedure. The marker hangs outside the measure so
      the text edge stays on the column's left edge. */
   .prose :is(ul, ol) { padding-inline-start: 1.4em; margin-inline: 0; }
   .prose li + li { margin-block-start: var(--sp-30); }
   .prose li > :is(ul, ol) { margin-block-start: var(--sp-30); }
   .prose li::marker { color: var(--page-meta); }
   .prose ol { font-variant-numeric: tabular-nums; }
   /* A list inside a staccato document keeps its gaps: the indent is for paragraphs. */
   .post[data-rhythm='staccato'] .prose li { text-indent: 0; }
 
   /* CommonMark's loose list, restored. A blank line between items wraps each item's content
      in <p>, which is the author's own gesture for "these are paragraphs, not entries"; with
      `p { margin: 0 }` in base.css a loose list and a tight one would render pixel for
      pixel the same. `:has(> p)` reads the distinction straight off the markup, and it is
      uniform per list -- CommonMark makes a list loose or tight as a whole, so either every
      item carries a <p> or none does and a mixed list cannot occur. */
   .prose li:has(> p) + li { margin-block-start: var(--sp-40); }
 
   /* ── task lists ──────────────────────────────────────────────────────────────
      GFM emits <ul class="contains-task-list"><li class="task-list-item">
      <input type="checkbox" disabled>. Unstyled that is a bullet AND a grey system checkbox
      on every row: two markers for one list. Zero in the corpus; a checklist is the most
      likely thing a procedural post (journalctl, bind9 and sysmon are all procedures) grows
      next, which is what earns it a block.
 
      The box hangs in the marker gutter, so a task item's text starts on exactly the column
      a plain item's text does, and it does that with inline margins rather than a grid. A
      grid holds only for a tight list: GFM emits the checkbox as a direct child of the
      <li> only in a TIGHT list, and moves it inside the item's first <p> the moment the list
      is loose. Rendered as a grid, the loose rows get an unstyled grey system checkbox (the
      child selector misses it), the <p> pinned to the text column with an empty marker
      column beside it, and the item's second paragraph and nested list at the wrong indent.
 
      The arithmetic below has no opinion about which shape it is in, because it is all on
      the input itself: -1.4em pulls the box out by the list's own indent, and the end margin
      gives back exactly what is left over, so the next inline content resumes on the li's
      content edge either way. font-size: inherit is load-bearing and not tidiness -- a UA
      gives an <input> 13.33px, and every em here has to be the list's em, not that one.
      Only .task-list-item is touched, so a plain <li> sharing the list keeps its bullet. */
   .prose .task-list-item { list-style: none; }
   /* Descendant, not child: in a loose list this input is li > p > input. */
   .prose .task-list-item input[type='checkbox'] {
     --box: 0.8em;
     font-size: inherit;
     margin-inline: -1.4em calc(1.4em - var(--box));
     /* appearance: none rather than accent-color: the control is `disabled`, and a disabled
        native checkbox is greyed out by the engine whatever accent it is given -- so the one
        state that has to read, "this is done", is the one accent-color cannot paint. */
     appearance: none;
     inline-size: var(--box);
     block-size: var(--box);
     /* The empty box IS this row's marker, so it is drawn in the colour the discs beside it
        are drawn in (`li::marker { color: var(--page-meta) }` above). --sand-dark, the
        border the inline code span and the copy control use, is 1.37:1 against the page
        and leaves the unchecked rows looking unmarked next to the filled ones -- which reads
        as "these items have no bullet", not as "these items are not done". */
     border: 1px solid var(--page-meta);
     background: var(--page-bg);
     /* The box is a picture of state, not a control -- it is disabled, and a pointer that
        says otherwise invites a click that does nothing. */
     cursor: default;
     /* An inline box with no text in it sits its bottom edge on the baseline, which is a
        touch low against the row it marks. */
     transform: translateY(0.05em);
   }
   /* Filled, not ticked. A drawn checkmark needs either a glyph outside the Latin subset or
      a pseudo-element on a form control, and the second is not reliable across engines; a
      filled crimson square against an empty one is unambiguous, costs one declaration
      and cannot fail to paint. The state is in the DOM as well (`checked`), which is what
      assistive tech reads either way. */
   .prose .task-list-item input[type='checkbox']:checked {
     background: var(--ppc-ui);
     border-color: var(--ppc-ui);
   }
   /* Its own block rather than the forced-colours block that follows the Contents switch:
      these two selectors have the same specificity as the task-list rules above, so an
      override has to come after them in source order. Placed before them, appearance stays
      `none` in forced colours and the checked square goes on painting a background the
      mode has already discarded. A background fill is exactly what forced colours drop, so
      "done" would become indistinguishable from "not done". Handing the box back to the
      engine is better than any fallback of ours: a High Contrast reader gets a real system
      checkbox, in system colours, carrying the state that is in the DOM either way. */
   @media (forced-colors: active) {
     .prose .task-list-item input[type='checkbox'] {
       appearance: auto;
       transform: none;
       /* No hang here. The box keeps its --box size (inline-size and block-size still
          apply to the native control), sits at the start of the row with 0.25em after it,
          and the item's text starts that much further in than a plain item's. */
       margin-inline: 0 0.25em;
     }
   }
 
   /* ── figures ─────────────────────────────────────────────────────────────
      Built by src/lib/satteri-figure.mjs: 26 images, 24 figures, 11 captions.
 
      Width is the body measure, not an extension. 21 of the 26 images are narrower than
      928px (356–896px) and six are strips as short as 12–38px tall; stretching any of
      them to the column would upscale a screenshot into mush. So no `width` is declared at
      all — satteri-prose.mjs stamps the intrinsic width/height, the browser takes that as
      the used width, and only the 5 oversize ones (1115–1965px) are pulled back by
      max-width. An image without a `width` never grows past its own pixels.
 
      No plate, and no frame of any kind: no --sand mat behind the images, no border
      around them, no padding to inset them. A photograph on this site is the thing itself,
      not a picture of a picture hung on the page. .fig__plate stays because it is
      satteri-figure's DOM contract and because the flex row below is what puts a
      three-image set on one line; it is layout and nothing else. A narrow strip, down to
      the 779x12 one, sits on the page ground, which is what every other block here does. */
   /* Every image, not only the ones satteri-figure lifted into a <figure>. It converts a
      paragraph holding nothing BUT images, so an image with text beside it, a linked image
      [![](a)](b), an image in a list or a table cell, and a raw-HTML <img> all stay bare --
      while satteri-prose stamps the intrinsic width on them just the same. Measured on a
      fixture carrying one bare 1965px screenshot: documentElement.scrollWidth 2379 against
      clientWidth 1659, i.e. the whole page scrolling sideways by 720px. None of the corpus's
      26 images escape today, which is what makes this the cheapest kind of fix: one rule,
      before the first post that does. `height: auto` is the other half -- without it the
      stamped height would hold while the width shrank, and the picture would squash. */
   .prose img { max-width: 100%; height: auto; }
 
   .prose .fig { margin-inline: 0; }
   .prose .fig__plate {
     display: flex;
     flex-wrap: wrap;
     gap: var(--sp-40);
     align-items: flex-start;
   }
   .prose .fig img { display: block; }
   /* 인지부조화이론.md puts three 600x800 scans on three adjacent lines, which
      CommonMark folds into a single paragraph. They are a set, so they share a row. */
   .prose .fig[data-count='3'] img { flex: 1 1 0; min-width: 0; }
   .prose .fig figcaption {
     margin-block-start: var(--sp-30);
     font-size: var(--fs-medium);
     line-height: var(--lh-base);
     color: var(--page-meta);
     text-wrap: pretty;
   }
 
   /* ── tables ──────────────────────────────────────────────────────────────
      Wrapped in .scroller by satteri-prose.mjs, so a wide table scrolls inside itself
      and the page never scrolls sideways. tabindex makes the overflow keyboard-
      reachable, which is why the wrapper is a focusable region. */
   .prose .scroller { overflow-x: auto; }
   .prose .scroller:focus-visible { outline: 3px solid var(--ppc-ui); outline-offset: 2px; }
   .prose table {
     border-collapse: collapse;
     width: 100%;
     font-size: var(--fs-medium);
     line-height: var(--lh-base);
   }
   .prose :is(th, td) {
     text-align: start;
     vertical-align: top;
     padding: var(--sp-30) var(--sp-40) var(--sp-30) 0;
     border-block-end: 1px solid var(--page-hairline);
   }
   .prose th {
     font-family: var(--font-body);
     font-size: var(--fs-small);
     font-weight: 700;
     letter-spacing: 0.105rem;
     text-transform: uppercase;
     color: var(--ppc-text);
     border-block-end: 4px solid var(--ppc-ui);
     white-space: nowrap;
   }
 
   /* ── code ────────────────────────────────────────────────────────────────
      The <figure class="code"> wrapper and the Shiki palette are owned by the
      `codeBlock` transformer in astro.config.mjs (theme: css-variables). Only the block
      rhythm and the inline span belong to this page. */
   .prose figure.code { margin-inline: 0; }
   /* The one fence that never reaches the plate. Astro ORs its own
      defaultExcludeLanguages = ["math"] into the highlight check, so a ```math fence skips
      the highlighter and arrives as a bare <pre> -- no plate, no scroll region, no copy
      control, and no overflow-x, which is the part that matters: a long line in a bare <pre>
      scrolls the PAGE. No value of excludeLangs un-excludes it and the corpus has 0 of them,
      so this is a guard, not a fix. Scoped away from .code pre, whose own overflow-x is an
      inline style this could not outrank in any case. */
   .prose pre:not(.code *) { max-width: 100%; overflow-x: auto; }
   .prose :not(pre) > code {
     font-family: var(--font-mono);
     font-size: 0.875em;
     background: var(--sand);
     border: 1px solid var(--sand-dark);
     padding: 0.1em 0.3em;
     word-break: break-all;
   }
 
   /* ── thematic break ──────────────────────────────────────────────────────
      It reuses the header's mark rather than introducing a second kind of line onto a
      page whose only graphic element is that mark. */
   .prose hr {
     width: 3rem;
     height: 0;
     border: 0;
     border-block-start: 4px solid var(--ppc-ui);
     margin-block: var(--sp-80);
   }
 
   /* ── footnotes ──────────────────────────────────────────────────────────────
      DOM contract, emitted by Sätteri's GFM footnotes:
        <sup><a data-footnote-ref aria-describedby="footnote-label">1</a></sup>   in the body
        <section data-footnotes class="footnotes">
          <h2 class="sr-only" id="footnote-label">Footnotes</h2>
          <ol><li id="user-content-fn-1"><p>… <a class="data-footnote-backref">↩</a></p></li>
 
      Zero in the corpus, and the most plausible missing construct in it: the posts that
      translate or comment on a source cite it with a parenthesis today. Unstyled, the
      apparatus renders at body size with nothing between it and the last paragraph, which
      reads as one more section rather than as notes.
 
      The separator is the 4px x 3rem mark, not a full-width hairline -- the same mark <hr>
      and the code plate's language label already use, and the only graphic element this page
      has. A hairline would be a second kind of line for the same job.
 
      The `↩` is U+21A9, and Lora has no glyph for it (the master in fonts-src/ carries no
      arrows at all), so no subset can supply it and that one glyph comes from a system
      fallback face. Left as it is on purpose: it is a single mark at the end of a note, the
      alternative is an ASCII digraph in the middle of typeset prose, and the Sätteri
      option that would change it (`gfm: { footnotes: { backContent } }`) is a worse trade
      than the fallback. */
   .prose .footnotes {
     margin-block-start: var(--sp-80);
     font-size: var(--fs-medium);
     line-height: var(--lh-base);
     color: var(--page-meta);
   }
   .prose .footnotes::before {
     content: '';
     display: block;
     inline-size: 3rem;
     block-size: 4px;
     background: var(--ppc-ui);
     margin-block-end: var(--sp-40);
   }
   /* The list is the notes themselves, so it sits on the text column rather than hanging its
      numbers off it -- the numbers ARE the content here, being what the body refers to. */
   .prose .footnotes ol { margin-block: 0; }
   .prose .footnotes li { scroll-margin-block-start: var(--sp-40); }
   /* Following a marker lands the reader in the middle of a list of near-identical
      paragraphs; this is the one thing that says which one was asked for. --ppc-wash is the
      section's emphasis ground, and the inline padding puts a margin around the text
      without moving it. */
   .prose .footnotes li:target {
     background: var(--ppc-wash);
     padding-inline: var(--sp-30);
     margin-inline: calc(-1 * var(--sp-30));
   }
   /* Same story as the checkbox: the mark is a background, and this mode has none. */
   @media (forced-colors: active) {
     .prose .footnotes li:target { background: none; border-inline-start: 2px solid; }
   }
   /* Both ends of the round trip. These keep an explicit accent colour of their own rather
      than inheriting the global link colour, because a bare numeral and a bare arrow are
      small targets that want the darker end of the family. They stay real links with a real focus ring
      -- the site's :focus-visible outline is untouched here. */
   .prose [data-footnote-ref],
   .prose .data-footnote-backref {
     text-decoration: none;
     font-weight: 400;
     color: var(--ppc-text);
   }
   /* The one link in the prose that draws an underline, and only on hover. These two are
      a bracketed numeral and a return arrow, roughly 8px of ink each, set inside running
      prose; on hover they take the colour step every prose link takes (base.css) and this
      plain underline with it, not an animated rule -- a 0.3s centre-out wipe across 8px is
      a flicker rather than a gesture. They are a deliberate pair -- same colour, same
      weight, same rule -- so neither changes without the other. Nothing renders here today
      either way: there are no footnotes in content/writing/. */
   .prose [data-footnote-ref]:hover,
   .prose .data-footnote-backref:hover { text-decoration: underline; }
   /* The backref is the last thing on a note's last line and reads as punctuation, not as a
      word, so it gets the space a word would have had and nothing else. */
   .prose .data-footnote-backref { margin-inline-start: 0.25em; }
 
   /* ══ Rail collapse ═══════════════════════════════════════════════════════
      The same 36rem breakpoint the index uses, so both pages fold at one width. */
   @container post (max-width: 36rem) {
     .post { grid-template-columns: minmax(0, 1fr); }
     .post > * { grid-column: 1; }
     .post__head { display: flex; flex-direction: column; align-items: flex-start; }
     .post__kicker { order: -2; }
   }
 </style>