@justai/cuts 0.133.0 → 0.138.0

package/src/Toolbar.astro

@@ -286,382 +286,308 @@ import AuthMount from "./AuthMount.astro";
 </div>
 
 <style>
-  /* ---- app toolbar — sticky to the top of the active region (kernel + posts); it never
-     enters the Profile (it lives inside .below). Flat / knife-cut: a left group and a
-     right group, no rounded pills. ---- */
-  /* queries: tb-slot · why is the toolbar wrapped · the bar changes height · the kernel is 26px
-   *          short · a band of the feed at the bottom · the toolbar reserves a box · sticky flow
-   *
-   * ── THE SLOT IS WHAT FLOW SEES; THE BAR IS WHAT THE EYE SEES ──────────────────────────────
-   *
-   * `position: sticky` NEVER LEAVES FLOW. It reserves its full border box and paints inside it — so
-   * the bar's LIVE height positioned everything under it (52 with the title strip shut, 78 open)
-   * while `--shell-top` was deliberately frozen at the open height so that nothing would sample the
-   * 0.35s animation. The HEIGHT stopped sampling it. THE POSITION NEVER DID. Two numbers that must
-   * be equal, written a hundred lines apart in two packages, and their difference is a band of the
-   * next section above the fold: measured on the live persona with the scroll untouched, the kernel
-   * sat 52px below `#below` instead of 78 and 25.81px of the feed was on screen.
-   *
-   * The wrapper separates them. The SLOT is sticky and its box is `--shell-top`; the BAR is static
-   * inside it and may be any height it likes. Nothing above the kernel changes size any more, so
-   * there is nothing for an engine to compensate for — which is also why only a device ever showed
-   * it: Blink scroll-anchors the step away and WebKit has no scroll anchoring. */
-  .tb-slot { position: sticky; top: 0; z-index: 40; display: flow-root; }
-  /* queries: the title strip moves the fold · the page drifts after it lands · a band of posts under
-   *          the game · tb-slot min-height · the slot follows the bar · the strip pushes the page down
-   *
-   * ── THE BOX IS THE SLOT'S OWN, SO IT TRAVELS WITH THE SLOT ─────────────────────────────────────
-   *
-   * `position: sticky` never leaves flow: it reserves its full border box, so whatever the bar's LIVE
-   * height is at any instant, that is where everything under it sits. The strip opens and closes over
-   * 0.35s inside that box — so without a reserved height the shell breathes 26px and the whole
-   * document below it breathes with it. That is the drift the founder lost days to.
-   *
-   * IT LIVED IN `@justai/ui`'s base.css UNTIL 2026-08-06, and measured on pin.games that was the same
-   * as not existing: a persona that never imports base.css got the slot's structure from here and its
-   * BOX from a file it does not load, so the slot collapsed to the bar and posts moved 26px between
-   * the kernel and the profile. The first law again — a component brings its own ground — and the
-   * slot is this component's element, so its box is this component's business. The rule that keeps
-   * the whole strip safe cannot be the one rule that lives somewhere the strip does not.
-   *
-   * AND THE RESERVED BAND WEARS THE BAR'S OWN MATERIAL, not the room's. A slot taller than its bar is
-   * 26px of SOMETHING under the shelf whenever the strip is shut — the state at the profile, on
-   * screen, at rest. Painted in the persona's ground it was a hard black band between a light profile
-   * and a light kernel: the founder photographed it within a minute. It is the BAR'S box, so it takes
-   * the bar's fill, bleeding by the same `--edge` expression so the two cannot leave slivers. */
-  .tb-slot { min-height: var(--shell-top, 78px); }
-  .tb-slot::before {
-    content: "";
-    position: absolute;
-    z-index: -1;
-    inset-block: 0;
-    inset-inline:
-      calc(-1 * max(var(--edge, 16px), env(safe-area-inset-left)))
-      calc(-1 * max(var(--edge, 16px), env(safe-area-inset-right)));
-    background: var(--toolbar-bg, #1e202a);
-  }
-  /* The shelf's fill has two branches and so must its box: `--toolbar-bg` is one token but its
-     FALLBACK differs by scheme, and a band carrying only the dark default is a black strip on a light
-     page — which is exactly what the founder photographed a minute after the first attempt. */
-  @media (prefers-color-scheme: light) {
-    /* Guarded like every light fork in the fleet: data-theme="dark" wins over the media query. */
-    :global(html:not([data-theme="dark"])) .tb-slot::before { background: var(--toolbar-bg, #fbfcfe); }
-  }
-  .toolbar {
-    /* position, top and z-index live on .tb-slot above — this element is static inside it now. */
-    display: flex; flex-direction: column;
-    /* full-bleed: the bar (frosted bg + hairline) touches the contained-view edges; the icons stay
-       aligned with the body via matching inline padding. --edge is the persona's page inline padding
-       (16px default; a persona that pads its body differently — e.g. time at 20px — sets --edge so the
-       bar bleeds to the SAME edge as its content instead of a hardcoded 16px). */
-    margin-inline: calc(-1 * max(var(--edge, 16px), env(safe-area-inset-left))) calc(-1 * max(var(--edge, 16px), env(safe-area-inset-right)));
-    padding-block: max(8px, env(safe-area-inset-top)) 8px;
-    padding-inline: max(var(--edge, 16px), env(safe-area-inset-left)) max(var(--edge, 16px), env(safe-area-inset-right));
-
-    /* ── THE BAR IS A SHELF, NOT A TINT ──────────────────────────────────────────────────────
+  /* Scoped by Astro's hash AND placed in the cascade: a persona overriding this never has to
+     out-specify it. See @justai/ui/tokens.css for the order, and for what deliberately stays out. */
+  @layer justai.components {
+    /* ---- app toolbar — sticky to the top of the active region (kernel + posts); it never
+       enters the Profile (it lives inside .below). Flat / knife-cut: a left group and a
+       right group, no rounded pills. ---- */
+    /* queries: tb-slot · why is the toolbar wrapped · the bar changes height · the kernel is 26px
+     *          short · a band of the feed at the bottom · the toolbar reserves a box · sticky flow
      *
-     * queries: the toolbar reads as a black strip · why is the bar darker in dark than in light ·
-     *          the bar looks flat against the column · toolbar material · --toolbar-bg
+     * ── THE SLOT IS WHAT FLOW SEES; THE BAR IS WHAT THE EYE SEES ──────────────────────────────
      *
-     * It used to derive its fill from `--bg` — `color-mix(--bg 70%, transparent)` under a blur.
-     * One declaration, but it meant two different things: `--bg` is a near-white in light and #000
-     * in dark, so the same rule read "lighten a near-white a little" on one ground and "pull a
-     * lifted surface to pure black" on the other. Measured against the column it sits on: **-6 in
-     * light, -17 in dark.** That asymmetry was a by-product of the token, never a decision.
+     * `position: sticky` NEVER LEAVES FLOW. It reserves its full border box and paints inside it — so
+     * the bar's LIVE height positioned everything under it (52 with the title strip shut, 78 open)
+     * while `--shell-top` was deliberately frozen at the open height so that nothing would sample the
+     * 0.35s animation. The HEIGHT stopped sampling it. THE POSITION NEVER DID. Two numbers that must
+     * be equal, written a hundred lines apart in two packages, and their difference is a band of the
+     * next section above the fold: measured on the live persona with the scroll untouched, the kernel
+     * sat 52px below `#below` instead of 78 and 25.81px of the feed was on screen.
      *
-     * So it takes the CARD's material instead, and the light comes from above like everything else:
-     * an opaque fill with a shadow cast downward, and the page sliding under it. The fill is opaque
-     * ON PURPOSE — the blur was inert in light anyway, because the column is 92% opaque and there is
-     * nothing behind it to refract.
+     * The wrapper separates them. The SLOT is sticky and its box is `--shell-top`; the BAR is static
+     * inside it and may be any height it likes. Nothing above the kernel changes size any more, so
+     * there is nothing for an engine to compensate for — which is also why only a device ever showed
+     * it: Blink scroll-anchors the step away and WebKit has no scroll anchoring. */
+    .tb-slot { position: sticky; top: 0; z-index: 40; display: flow-root; }
+    /* queries: the title strip moves the fold · the page drifts after it lands · a band of posts under
+     *          the game · tb-slot min-height · the slot follows the bar · the strip pushes the page down
      *
-     * WHY IT IS HERE NOW. app.zone settled this, qr copied it verbatim — same two hex values, same
-     * two shadows — and BOTH left a comment saying it belongs in cuts. Two consumers is the
-     * promotion trigger, and the note the second one wrote is the specification:
+     * ── THE BOX IS THE SLOT'S OWN, SO IT TRAVELS WITH THE SLOT ─────────────────────────────────────
      *
-     *     "the right end state is cuts reading `var(--toolbar-bg, <its current expression>)`,
-     *      after which these four declarations delete themselves and the tokens alone do the work."
+     * `position: sticky` never leaves flow: it reserves its full border box, so whatever the bar's LIVE
+     * height is at any instant, that is where everything under it sits. The strip opens and closes over
+     * 0.35s inside that box — so without a reserved height the shell breathes 26px and the whole
+     * document below it breathes with it. That is the drift the founder lost days to.
      *
-     * The token remains the seam: a persona whose ground is genuinely different sets `--toolbar-bg`
-     * and `--toolbar-shadow` and this rule steps aside. */
-    background: var(--toolbar-bg, #1e202a);
-    box-shadow: var(--toolbar-shadow, 0 2px 12px -2px rgba(0, 0, 0, 0.55));
-    /* No hairline: it was the only thing separating the bar from the column, and the shadow does
-       that now. A line under an OPAQUE shelf reads as a seam rather than as a separation. */
-    border-block-end: none;
-  }
-  @media (prefers-color-scheme: light) {
-    :global(html:not([data-theme="dark"])) .toolbar {
-      background: var(--toolbar-bg, #fbfcfe);
-      box-shadow: var(--toolbar-shadow, 0 1px 2px rgba(16, 24, 40, 0.06), 0 8px 20px -8px rgba(16, 24, 40, 0.16));
+     * IT LIVED IN `@justai/ui`'s base.css UNTIL 2026-08-06, and measured on pin.games that was the same
+     * as not existing: a persona that never imports base.css got the slot's structure from here and its
+     * BOX from a file it does not load, so the slot collapsed to the bar and posts moved 26px between
+     * the kernel and the profile. The first law again — a component brings its own ground — and the
+     * slot is this component's element, so its box is this component's business. The rule that keeps
+     * the whole strip safe cannot be the one rule that lives somewhere the strip does not.
+     *
+     * AND THE RESERVED BAND WEARS THE BAR'S OWN MATERIAL, not the room's. A slot taller than its bar is
+     * 26px of SOMETHING under the shelf whenever the strip is shut — the state at the profile, on
+     * screen, at rest. Painted in the persona's ground it was a hard black band between a light profile
+     * and a light kernel: the founder photographed it within a minute. It is the BAR'S box, so it takes
+     * the bar's fill, bleeding by the same `--edge` expression so the two cannot leave slivers. */
+    .tb-slot { min-height: var(--shell-top, 78px); }
+    .tb-slot::before {
+      content: "";
+      position: absolute;
+      z-index: -1;
+      inset-block: 0;
+      inset-inline:
+        calc(-1 * max(var(--edge, 16px), env(safe-area-inset-left)))
+        calc(-1 * max(var(--edge, 16px), env(safe-area-inset-right)));
+      background: var(--toolbar-bg, #1e202a);
     }
-  }
-  /* `.stuck` is still set by the script below and still means "content is under the bar" — it simply
-     has nothing to paint now that the shelf is opaque and always shadowed. Kept because the class is
-     part of this cut's contract and a consumer may hang its own behaviour on it. */
-  @media (min-width: 640px) { .toolbar { margin-inline: -28px; padding-inline: 28px; } }
-  /* icons row + the scroll-reactive title strip below it */
-  .tb-row { display: flex; align-items: center; justify-content: space-between; gap: 8px; }
-  /* queries: --tb-strip · the title strip's height · the toolbar changes height · 26px ·
-   *          the kernel is 26px short · the game frame does not reach the fold
-   *
-   * ── THE ONE NUMBER THAT MAKES THIS ROW'S HEIGHT A MOVING TARGET, DECLARED SO IT CAN BE READ ──
-   *
-   * The strip opens and closes over 0.35s, so `.toolbar`'s height is anywhere in a 26px range at any
-   * given moment — and anything that measures the row and feeds a LAYOUT with it is sampling an
-   * animation. `--shell-top` did exactly that and the kernel's height came out 26px short whenever
-   * the page happened to be measured with the strip open, which is to say whenever somebody opened
-   * the persona at #kernel. It reads as a strip of the next section showing above the fold.
-   *
-   * So the number is a custom property rather than a literal: this rule uses it, and @justai/core's
-   * `personaScroll` reads it to compute the row's EXPANDED height without waiting for or racing the
-   * transition — `toolbar - strip` is the row, and the row plus this is what the bar will be. One
-   * declaration, two readers, and nothing samples a moving value. */
-  .toolbar { --tb-strip: 26px; }
-  /* queries: the bar grows after load · why does the strip animate on arrival · data-motion ·
-   *          first paint animation · can this transition wait for the first interaction
-   *
-   * ── THE TRANSITION IS ALSO A DAMPER, WHICH IS WHY IT CANNOT SIMPLY WAIT ─────────────────────
-   *
-   * The founder asked the obvious and right question: *"şu geçiş süresi güzel — ama neden bu özellik
-   * kullanıcının ilk interaction'ından sonra aktif edilmiyor?"* A persona lands on its kernel, so the
-   * strip's correct state on the first frame is open; animating into it grows the bar 26px just after
-   * the page appears, which is a glitch nobody asked for.
-   *
-   * IT WAS TRIED, AND IT BREAKS SOMETHING ELSE. Gated behind a `data-motion` flag set on the first
-   * pointer/key/wheel, the strip snaps open during the landing — and that 26px arrives in a SINGLE
-   * frame, inside `#below`, while the scroll spy is deciding which cut is active. That is the
-   * bistable oscillator `personaScroll` documents at length: the spy measures a page its own output
-   * moved. Measured: with the gate in place, `#navProfile` no longer navigates — the page re-asserts
-   * the kernel and stays. The 0.35s is not only easing; it is what keeps that step out of one frame.
-   *
-   * SO THE HEIGHT IS NEVER READ INSTEAD. `--shell-top` is computed as `row + --tb-strip` — the row
-   * being the bar minus whatever the strip currently is, which is the same number at every frame of
-   * the transition. Nothing samples the animation, so nothing depends on when it was sampled.
-   *
-   * The real fix for the founder's question is a toolbar whose height does not change at all: reserve
-   * the strip's space always and fade only its content. That removes the feedback at the source and
-   * makes the gate free — and it is a fleet-wide design decision about how the bar looks at the
-   * profile, so it is his to take rather than one to slip in. */
-  .tb-title { display: flex; align-items: center; height: 0; overflow: hidden; opacity: 0; transition: height 0.35s var(--ease-out), opacity 0.25s var(--ease-out); }
-  /* The fallback is not decoration: the token is declared on `.toolbar` and consumed here, which is
-     a different selector — so the framework's own token spec reads it as ungrounded and is right to.
-     A rule that silently collapses to `height: 0` would close the strip and say nothing. */
-  .tb-title.show { height: 26px; height: var(--tb-strip, 26px); opacity: 1; }
-  .tb-title-text { font-size: var(--fs-sm); font-weight: 600; letter-spacing: -0.01em; color: var(--text); white-space: nowrap; overflow: hidden; text-overflow: ellipsis; transition: opacity 0.16s var(--ease-out); }
-  .tb-title-text.fade { opacity: 0; }
-  /* nav lives on the left, beside the back affordance — the middle is intentionally empty */
-  .tb-left { display: flex; align-items: center; gap: 2px; min-width: 0; }
-  .tb-nav-group { display: flex; align-items: center; gap: 2px; }
-  .tb-right { display: flex; align-items: center; min-width: 0; }
-
-  /* ── the withdraw: what this row does while a game is playing ───────────────────────────────
-   * Opacity and pointer-events here; the INERT that takes them out of the tab order is set in the
-   * script, because CSS cannot. The transition matters more than it looks: chrome that snaps away
-   * reads as breaking, chrome that withdraws reads as dimming the house lights. */
-  /* ── HOW THIS ROW GOES QUIET WHILE A GAME PLAYS: IT DOES NOT ─────────────────────────────────
-   * queries: toolbar during a game · theater · toolbar looks disabled
-   *
-   * Four versions in one day, each struck by the founder, and the last one is no CSS at all. A
-   * pause handle in the row; then inert; then faded ("disable gibi gozukmemeli - tiklanabiliyorsa");
-   * then stepped under a custom dim layer. The standing answer: the stage switches the page to the
-   * persona's own DARK THEME (data-theme on html, see Preroll), and this row simply wears it - the
-   * same bar every dark-system visitor already sees, fully alive, auto-pausing the game when
-   * touched. Nothing here needs to know a game exists. */
-  /* icon-only section nav — current cut highlighted */
-  .tb-nav {
-    display: grid; place-items: center; width: 38px; height: 36px;
-    color: var(--text-dim);
-    transition: color 0.2s, opacity 0.2s, transform 0.2s var(--ease-spring);
-  }
-  .tb-nav:hover { color: var(--text); }
-  .tb-nav:active { transform: scale(0.9); }
-  /* The active glyph is a graphic, so it wants 3:1 rather than 4.5 — which a light accent still
-     misses. Same ink hook as everywhere the accent stops being paint. */
-  .tb-nav.active { color: var(--accent-text, var(--accent)); }
-
-  /* queries: should the persona mark be coloured · the mark is always accent · two icons look active
-     THE MARK IS A CUT ICON LIKE THE OTHER TWO — the founder's rule, 2026-08-03: the ACTIVE cut wears
-     the accent and no passive one does, the persona's own mark included.
-
-     This comment used to argue the opposite: *"the three stroke icons are generic glyphs whose colour
-     IS a UI state; a mark is an identity… a faded logo reads as disabled."* Kept, because it is a true
-     premise ageing into a wrong conclusion. It was true while the mark arrived as an `<img>`, which
-     cannot take `currentColor` — dimming was then the only way to say "not here", and a dimmed logo
-     does read as disabled. The premise expired when `toolbarMark` began deriving an inline SVG: an
-     inline mark can be INK, and ink is not dimming. `toolbarMark` neutralises its paint, so the two
-     rules below reach it exactly as they reach the bolt and the bubble.
+    /* The shelf's fill has two branches and so must its box: `--toolbar-bg` is one token but its
+       FALLBACK differs by scheme, and a band carrying only the dark default is a black strip on a light
+       page — which is exactly what the founder photographed a minute after the first attempt. */
+    @media (prefers-color-scheme: light) {
+      /* Guarded like every light fork in the fleet: data-theme="dark" wins over the media query. */
+      :global(html:not([data-theme="dark"])) .tb-slot::before { background: var(--toolbar-bg, #fbfcfe); }
+    }
+    .toolbar {
+      /* position, top and z-index live on .tb-slot above — this element is static inside it now. */
+      display: flex; flex-direction: column;
+      /* full-bleed: the bar (frosted bg + hairline) touches the contained-view edges; the icons stay
+         aligned with the body via matching inline padding. --edge is the persona's page inline padding
+         (16px default; a persona that pads its body differently — e.g. time at 20px — sets --edge so the
+         bar bleeds to the SAME edge as its content instead of a hardcoded 16px). */
+      margin-inline: calc(-1 * max(var(--edge, 16px), env(safe-area-inset-left))) calc(-1 * max(var(--edge, 16px), env(safe-area-inset-right)));
+      padding-block: max(8px, env(safe-area-inset-top)) 8px;
+      padding-inline: max(var(--edge, 16px), env(safe-area-inset-left)) max(var(--edge, 16px), env(safe-area-inset-right));
 
-     A mark that keeps its colours while another cut is current is a second voice on the one channel
-     the accent has — measured, several passive marks were more coloured than the active icon. A
-     persona that wants its own gradient WHILE CURRENT re-points to it from its own CSS; the `<defs>`
-     survive the derivation for that. `.tb-mark` remains, because the sizing rule below still needs to
-     know a mark is here. */
-  /* The shell sizes the mark and says NOTHING about `display`, deliberately. Two files arrive for the two
-     themes — an SVG's internal `prefers-color-scheme` does not survive <img>, measured — and the persona
-     hides one with a media query. A `display: block` here would be two classes deep against the persona's
-     one and would WIN, showing both marks stacked. That exact mistake shipped once in this shell and the
-     founder counted the duplicate logos before anyone read the CSS. Width and height only.
+      /* ── THE BAR IS A SHELF, NOT A TINT ──────────────────────────────────────────────────────
+       *
+       * queries: the toolbar reads as a black strip · why is the bar darker in dark than in light ·
+       *          the bar looks flat against the column · toolbar material · --toolbar-bg
+       *
+       * It used to derive its fill from `--bg` — `color-mix(--bg 70%, transparent)` under a blur.
+       * One declaration, but it meant two different things: `--bg` is a near-white in light and #000
+       * in dark, so the same rule read "lighten a near-white a little" on one ground and "pull a
+       * lifted surface to pure black" on the other. Measured against the column it sits on: **-6 in
+       * light, -17 in dark.** That asymmetry was a by-product of the token, never a decision.
+       *
+       * So it takes the CARD's material instead, and the light comes from above like everything else:
+       * an opaque fill with a shadow cast downward, and the page sliding under it. The fill is opaque
+       * ON PURPOSE — the blur was inert in light anyway, because the column is 92% opaque and there is
+       * nothing behind it to refract.
+       *
+       * WHY IT IS HERE NOW. app.zone settled this, qr copied it verbatim — same two hex values, same
+       * two shadows — and BOTH left a comment saying it belongs in cuts. Two consumers is the
+       * promotion trigger, and the note the second one wrote is the specification:
+       *
+       *     "the right end state is cuts reading `var(--toolbar-bg, <its current expression>)`,
+       *      after which these four declarations delete themselves and the tokens alone do the work."
+       *
+       * The token remains the seam: a persona whose ground is genuinely different sets `--toolbar-bg`
+       * and `--toolbar-shadow` and this rule steps aside. */
+      background: var(--toolbar-bg, #1e202a);
+      box-shadow: var(--toolbar-shadow, 0 2px 12px -2px rgba(0, 0, 0, 0.55));
+      /* No hairline: it was the only thing separating the bar from the column, and the shadow does
+         that now. A line under an OPAQUE shelf reads as a seam rather than as a separation. */
+      border-block-end: none;
+    }
+    @media (prefers-color-scheme: light) {
+      :global(html:not([data-theme="dark"])) .toolbar {
+        background: var(--toolbar-bg, #fbfcfe);
+        box-shadow: var(--toolbar-shadow, 0 1px 2px rgba(16, 24, 40, 0.06), 0 8px 20px -8px rgba(16, 24, 40, 0.16));
+      }
+    }
+    /* `.stuck` is still set by the script below and still means "content is under the bar" — it simply
+       has nothing to paint now that the shelf is opaque and always shadowed. Kept because the class is
+       part of this cut's contract and a consumer may hang its own behaviour on it. */
+    @media (min-width: 640px) { .toolbar { margin-inline: -28px; padding-inline: 28px; } }
+    /* icons row + the scroll-reactive title strip below it */
+    .tb-row { display: flex; align-items: center; justify-content: space-between; gap: 8px; }
+    /* queries: --tb-strip · the title strip's height · the toolbar changes height · 26px ·
+     *          the kernel is 26px short · the game frame does not reach the fold
+     *
+     * ── THE ONE NUMBER THAT MAKES THIS ROW'S HEIGHT A MOVING TARGET, DECLARED SO IT CAN BE READ ──
+     *
+     * The strip opens and closes over 0.35s, so `.toolbar`'s height is anywhere in a 26px range at any
+     * given moment — and anything that measures the row and feeds a LAYOUT with it is sampling an
+     * animation. `--shell-top` did exactly that and the kernel's height came out 26px short whenever
+     * the page happened to be measured with the strip open, which is to say whenever somebody opened
+     * the persona at #kernel. It reads as a strip of the next section showing above the fold.
+     *
+     * So the number is a custom property rather than a literal: this rule uses it, and @justai/core's
+     * `personaScroll` reads it to compute the row's EXPANDED height without waiting for or racing the
+     * transition — `toolbar - strip` is the row, and the row plus this is what the bar will be. One
+     * declaration, two readers, and nothing samples a moving value. */
+    .toolbar { --tb-strip: 26px; }
+    /* queries: the bar grows after load · why does the strip animate on arrival · data-motion ·
+     *          first paint animation · can this transition wait for the first interaction
+     *
+     * ── THE TRANSITION IS ALSO A DAMPER, WHICH IS WHY IT CANNOT SIMPLY WAIT ─────────────────────
+     *
+     * The founder asked the obvious and right question: *"şu geçiş süresi güzel — ama neden bu özellik
+     * kullanıcının ilk interaction'ından sonra aktif edilmiyor?"* A persona lands on its kernel, so the
+     * strip's correct state on the first frame is open; animating into it grows the bar 26px just after
+     * the page appears, which is a glitch nobody asked for.
+     *
+     * IT WAS TRIED, AND IT BREAKS SOMETHING ELSE. Gated behind a `data-motion` flag set on the first
+     * pointer/key/wheel, the strip snaps open during the landing — and that 26px arrives in a SINGLE
+     * frame, inside `#below`, while the scroll spy is deciding which cut is active. That is the
+     * bistable oscillator `personaScroll` documents at length: the spy measures a page its own output
+     * moved. Measured: with the gate in place, `#navProfile` no longer navigates — the page re-asserts
+     * the kernel and stays. The 0.35s is not only easing; it is what keeps that step out of one frame.
+     *
+     * SO THE HEIGHT IS NEVER READ INSTEAD. `--shell-top` is computed as `row + --tb-strip` — the row
+     * being the bar minus whatever the strip currently is, which is the same number at every frame of
+     * the transition. Nothing samples the animation, so nothing depends on when it was sampled.
+     *
+     * The real fix for the founder's question is a toolbar whose height does not change at all: reserve
+     * the strip's space always and fade only its content. That removes the feedback at the source and
+     * makes the gate free — and it is a fleet-wide design decision about how the bar looks at the
+     * profile, so it is his to take rather than one to slip in. */
+    .tb-title { display: flex; align-items: center; height: 0; overflow: hidden; opacity: 0; transition: height 0.35s var(--ease-out), opacity 0.25s var(--ease-out); }
+    /* The fallback is not decoration: the token is declared on `.toolbar` and consumed here, which is
+       a different selector — so the framework's own token spec reads it as ungrounded and is right to.
+       A rule that silently collapses to `height: 0` would close the strip and say nothing. */
+    .tb-title.show { height: 26px; height: var(--tb-strip, 26px); opacity: 1; }
+    .tb-title-text { font-size: var(--fs-sm); font-weight: 600; letter-spacing: -0.01em; color: var(--text); white-space: nowrap; overflow: hidden; text-overflow: ellipsis; transition: opacity 0.16s var(--ease-out); }
+    .tb-title-text.fade { opacity: 0; }
+    /* nav lives on the left, beside the back affordance — the middle is intentionally empty */
+    .tb-left { display: flex; align-items: center; gap: 2px; min-width: 0; }
+    .tb-nav-group { display: flex; align-items: center; gap: 2px; }
+    .tb-right { display: flex; align-items: center; min-width: 0; }
 
-     19px, the same box the stroke icons get. 0.65.0 set this to 14.5px to make the mark's INK match the
-     neighbours' — a glyph carries padding and a mark does not, so at an equal box the mark reads about a
-     third larger. The measurement was right and the conclusion was the founder's to make, not mine: he
-     wants the mark at its own size. A logo is allowed to be more present than a glyph.
-     So the difference stays, and it is a difference in ink rather than in box: mark ~19px, glyphs ~14.3px
-     inside the same 19px. If the row is ever to read level, the way there is to grow the GLYPHS, not to
-     shrink the identity. */
-  /* ── EVERY ICON READS AT 20 ─────────────────────────────────────────────────────────────────
-   *
-   * queries: toolbar icon size · 20 · why is my icon smaller than the others · 26.67 · the mark
-   *          looks small · icon ink
-   *
-   * The founder's rule, and it is about the DRAWING rather than the box: an icon's picture hits 20
-   * on its longer side, whichever side its design naturally uses. A bolt is tall and narrow and hits
-   * 20 on its height; a folder hits it on its width. The container is whatever that takes.
-   *
-   * One number, two boxes, because a viewBox is not a drawing:
-   *
-   *   a MARK fills its own viewBox        → a 20px box puts 20px on screen
-   *   a GLYPH sits inside 18 of 24 (0.75) → 20 / 0.75 = 26.67px
-   *
-   * A persona whose mark does NOT fill its viewBox needs its own number, and that is where the
-   * confusion came from: those marks looked small in the same box as everything else because their
-   * drawing occupies less of it. The box is derived — 20 divided by how much of the viewBox the
-   * drawing uses — so a redraw changes it, and the comment beside each one says so.
-   *
-   * (This replaced a 19-with-a-20-in-front rule that lasted an afternoon. The distinction was real —
-   * the first slot is not one of the sections — but it is said by POSITION and the -7px pull above,
-   * not by a pixel of size nobody can see and everybody can drift.) */
-  .tb-nav.tb-mark :global(img) { width: 20px; height: 20px; }
+    /* ── the withdraw: what this row does while a game is playing ───────────────────────────────
+     * Opacity and pointer-events here; the INERT that takes them out of the tab order is set in the
+     * script, because CSS cannot. The transition matters more than it looks: chrome that snaps away
+     * reads as breaking, chrome that withdraws reads as dimming the house lights. */
+    /* ── HOW THIS ROW GOES QUIET WHILE A GAME PLAYS: IT DOES NOT ─────────────────────────────────
+     * queries: toolbar during a game · theater · toolbar looks disabled
+     *
+     * Four versions in one day, each struck by the founder, and the last one is no CSS at all. A
+     * pause handle in the row; then inert; then faded ("disable gibi gozukmemeli - tiklanabiliyorsa");
+     * then stepped under a custom dim layer. The standing answer: the stage switches the page to the
+     * persona's own DARK THEME (data-theme on html, see Preroll), and this row simply wears it - the
+     * same bar every dark-system visitor already sees, fully alive, auto-pausing the game when
+     * touched. Nothing here needs to know a game exists. */
+    /* icon-only section nav — current cut highlighted */
+    .tb-nav {
+      display: grid; place-items: center; width: 38px; height: 36px;
+      color: var(--text-dim);
+      transition: color 0.2s, opacity 0.2s, transform 0.2s var(--ease-spring);
+    }
+    .tb-nav:hover { color: var(--text); }
+    .tb-nav:active { transform: scale(0.9); }
+    /* The active glyph is a graphic, so it wants 3:1 rather than 4.5 — which a light accent still
+       misses. Same ink hook as everywhere the accent stops being paint. */
+    .tb-nav.active { color: var(--accent-text, var(--accent)); }
 
-  /* ── THE FIRST POSITION STARTS WHERE THE ROW STARTS ─────────────────────────────────────────
-   *
-   * queries: the first icon is further in on a child persona · navParent inset · -7px ·
-   *          the row starts in a different place
-   *
-   * `BackToZone` pulls itself 7px left so the row begins flush with the bar's edge rather than a tap
-   * target's worth inside it. Anything standing in the first position has the same job and needs the
-   * same pull — measured on a live child, the parent's face sat 26px from the bar's edge where a
-   * persona's way out sits at 17. Nine pixels, found by eye before any probe looked: a person moving
-   * between two surfaces sees a difference no single page can show.
-   *
-   * POSITION IS WHAT MAKES THE FIRST SLOT DIFFERENT — not size. Every icon reads at 20; what says
-   * "this one is the way out rather than a section" is where it sits, flush to the edge, before the
-   * group. Structural for that reason: BackToZone sizes and pulls itself, and when it is absent the
-   * nav group becomes the first child of `.tb-left` and its first item inherits the job. */
-  .tb-left > .tb-nav-group:first-child > .tb-nav:first-child { margin-inline-start: -7px; }
-  .tb-nav :global(svg) { width: 20px; height: 20px; }
+    /* queries: should the persona mark be coloured · the mark is always accent · two icons look active
+       THE MARK IS A CUT ICON LIKE THE OTHER TWO — the founder's rule, 2026-08-03: the ACTIVE cut wears
+       the accent and no passive one does, the persona's own mark included.
 
-  /* ── EQUAL INK, TWO BOXES ────────────────────────────────────────────────────────────────────
-   *
-   * queries: the toolbar icons are not the same size · the mark looks bigger than the glyphs ·
-   *          the row is not level · 25.33px
-   *
-   * The paragraph above ends by naming the way out — *"grow the GLYPHS, not the identity"* — and
-   * this is that, arriving from the two repos that measured it.
-   *
-   * "19px" means two different things in this row. A Lucide glyph is drawn in a 24 viewBox with its
-   * ink between 3 and 21, so a 19px box puts **14.25px** of ink on screen; a mark runs to the edge
-   * of its own viewBox and puts **18.65px**. The mark therefore reads about a third larger, which is
-   * exactly what it did — and while the mark was still coloured, colour carried part of that
-   * difference. Now that it is monochrome at rest, the size gap is the only thing left and it shows.
-   *
-   * 19 × 24/18 = 25.33px is the box at which a glyph's INK measures 19px, the same 19px the mark
-   * occupies. `:not(.tb-mark)` is not a special case — it is the same rule read the other way: a
-   * glyph carries padding inside its viewBox and a mark does not, so equal ink needs unequal boxes.
-   *
-   * app.zone settled it, qr arrived at the identical number, and qr's own comment says why it is
-   * here: *"otherwise every persona has to remember to carry it, which is precisely the thing the
-   * shared shell exists to prevent."* */
-  .tb-nav:not(.tb-mark) :global(svg) { width: 26.67px; height: 26.67px; }
+       This comment used to argue the opposite: *"the three stroke icons are generic glyphs whose colour
+       IS a UI state; a mark is an identity… a faded logo reads as disabled."* Kept, because it is a true
+       premise ageing into a wrong conclusion. It was true while the mark arrived as an `<img>`, which
+       cannot take `currentColor` — dimming was then the only way to say "not here", and a dimmed logo
+       does read as disabled. The premise expired when `toolbarMark` began deriving an inline SVG: an
+       inline mark can be INK, and ink is not dimming. `toolbarMark` neutralises its paint, so the two
+       rules below reach it exactly as they reach the bolt and the bubble.
 
-  /* THE BUBBLE HANGS. Its silhouette's centre measures 1.05px below the line the other three sit on
-     (39.05 against 38.0) because the tail is part of the shape and pulls the box down with it — the
-     glyph is centred while the thing you SEE is not. A pixel is inside the noise on most rows; on
-     four icons at one size sharing one baseline it is the only thing left that is not level.
-     Nudged rather than redrawn, and `transform` on the svg never collides with the press feedback:
-     `.tb-nav:active`'s scale lives on the anchor. Both repos carry this verbatim. */
-  #navPosts :global(svg) { transform: translateY(-1px); }
-</style>
+       A mark that keeps its colours while another cut is current is a second voice on the one channel
+       the accent has — measured, several passive marks were more coloured than the active icon. A
+       persona that wants its own gradient WHILE CURRENT re-points to it from its own CSS; the `<defs>`
+       survive the derivation for that. `.tb-mark` remains, because the sizing rule below still needs to
+       know a mark is here. */
+    /* The shell sizes the mark and says NOTHING about `display`, deliberately. Two files arrive for the two
+       themes — an SVG's internal `prefers-color-scheme` does not survive <img>, measured — and the persona
+       hides one with a media query. A `display: block` here would be two classes deep against the persona's
+       one and would WIN, showing both marks stacked. That exact mistake shipped once in this shell and the
+       founder counted the duplicate logos before anyone read the CSS. Width and height only.
 
-<script>
-  // queries: where does the toolbar's scroll behaviour live · land on the kernel · scroll spy ·
-  //          title strip · why is the scroll code not in this file any more
-  //
-  // The BEHAVIOUR moved to @justai/core (`personaScroll`); what stays here is the markup and the CSS.
-  //
-  // It moved because this cut can only serve pages that adopt its markup, and three surfaces cannot:
-  // `/me` and `/files` carry extra navigation of their own and the feed is a different build. All
-  // three hand-wrote the same eighty lines, and by the third copy they had drifted — `/files` opened
-  // on the profile with an empty title strip, and its hash writer clobbered the query string where
-  // this one preserved it. One implementation, four consumers.
-  //
-  // The defaults ARE this cut's contract — the three cut ids, `nav<Cut>`, `#tbTitle`/`#tbTitleText`,
-  // `.toolbar`, `#below` — so a persona using the shell passes nothing at all.
-  import { personaScroll, adoptMark } from "@justai/core";
+       19px, the same box the stroke icons get. 0.65.0 set this to 14.5px to make the mark's INK match the
+       neighbours' — a glyph carries padding and a mark does not, so at an equal box the mark reads about a
+       third larger. The measurement was right and the conclusion was the founder's to make, not mine: he
+       wants the mark at its own size. A logo is allowed to be more present than a glyph.
+       So the difference stays, and it is a difference in ink rather than in box: mark ~19px, glyphs ~14.3px
+       inside the same 19px. If the row is ever to read level, the way there is to grow the GLYPHS, not to
+       shrink the identity. */
+    /* ── EVERY ICON READS AT 20 ─────────────────────────────────────────────────────────────────
+     *
+     * queries: toolbar icon size · 20 · why is my icon smaller than the others · 26.67 · the mark
+     *          looks small · icon ink
+     *
+     * The founder's rule, and it is about the DRAWING rather than the box: an icon's picture hits 20
+     * on its longer side, whichever side its design naturally uses. A bolt is tall and narrow and hits
+     * 20 on its height; a folder hits it on its width. The container is whatever that takes.
+     *
+     * One number, two boxes, because a viewBox is not a drawing:
+     *
+     *   a MARK fills its own viewBox        → a 20px box puts 20px on screen
+     *   a GLYPH sits inside 18 of 24 (0.75) → 20 / 0.75 = 26.67px
+     *
+     * A persona whose mark does NOT fill its viewBox needs its own number, and that is where the
+     * confusion came from: those marks looked small in the same box as everything else because their
+     * drawing occupies less of it. The box is derived — 20 divided by how much of the viewBox the
+     * drawing uses — so a redraw changes it, and the comment beside each one says so.
+     *
+     * (This replaced a 19-with-a-20-in-front rule that lasted an afternoon. The distinction was real —
+     * the first slot is not one of the sections — but it is said by POSITION and the -7px pull above,
+     * not by a pixel of size nobody can see and everybody can drift.) */
+    .tb-nav.tb-mark :global(img) { width: 20px; height: 20px; }
 
-  // queries: the parent icon in a child toolbar has a background · navParent tile · the child's row
-  //          does not match the persona's · who removes the ground for a child persona
-  //
-  // THE ROW TAKES CARE OF ITS OWN MARK. Every other icon here is an ink; `parent` renders the host's
-  // avatar file, which is a TILE, so a child's row is the one place in the fleet where a background
-  // still shows. The persona's own mark is derived at build time from a file the repo imports — a
-  // child has only a URL, so `adoptMark` fetches it and runs the same derivation in the browser,
-  // measuring the box from the drawing instead of being told it.
-  //
-  // Here rather than in the three children because this cut is what rendered `#navParent`: three
-  // consumers each remembering a line is O(N), and the third one always forgets.
-  if (document.getElementById("navParent")) adoptMark({ id: "navParent" });
+    /* ── THE FIRST POSITION STARTS WHERE THE ROW STARTS ─────────────────────────────────────────
+     *
+     * queries: the first icon is further in on a child persona · navParent inset · -7px ·
+     *          the row starts in a different place
+     *
+     * `BackToZone` pulls itself 7px left so the row begins flush with the bar's edge rather than a tap
+     * target's worth inside it. Anything standing in the first position has the same job and needs the
+     * same pull — measured on a live child, the parent's face sat 26px from the bar's edge where a
+     * persona's way out sits at 17. Nine pixels, found by eye before any probe looked: a person moving
+     * between two surfaces sees a difference no single page can show.
+     *
+     * POSITION IS WHAT MAKES THE FIRST SLOT DIFFERENT — not size. Every icon reads at 20; what says
+     * "this one is the way out rather than a section" is where it sits, flush to the edge, before the
+     * group. Structural for that reason: BackToZone sizes and pulls itself, and when it is absent the
+     * nav group becomes the first child of `.tb-left` and its first item inherits the job. */
+    .tb-left > .tb-nav-group:first-child > .tb-nav:first-child { margin-inline-start: -7px; }
+    .tb-nav :global(svg) { width: 20px; height: 20px; }
 
-  // queries: the persona mark is an image · the golden rule does not apply · currentColor img ·
-  //          the mark keeps its colours when I did not pass profileIcon
-  //
-  // THE FALLBACK HAS TO OBEY THE RULE TOO. A persona that passes `profileIcon` hands over a mark
-  // derived at build time — ink, ground-less, sized. A persona that passes nothing gets the `<img>`
-  // above, and an image obeys nothing: it cannot take `currentColor`, so it wears its own colours
-  // while another cut is current, which is exactly what the accent must never do.
-  //
-  // It is the child persona's problem in a different costume — a mark known only as a URL — so it
-  // takes the child's answer: fetch it and derive it here. Same function, same three edits, and the
-  // row's own `.tb-nav` / `.tb-nav.active` rules reach it afterwards like any glyph.
-  //
-  // The build-time path stays the better one and stays the default advice: it costs no request and
-  // no frame of the wrong picture. This is the floor under a persona that has not got there yet.
-  const ownMark = document.querySelector("#navProfile img");
-  if (ownMark) adoptMark({ id: "navProfile" });
+    /* ── EQUAL INK, TWO BOXES ────────────────────────────────────────────────────────────────────
+     *
+     * queries: the toolbar icons are not the same size · the mark looks bigger than the glyphs ·
+     *          the row is not level · 25.33px
+     *
+     * The paragraph above ends by naming the way out — *"grow the GLYPHS, not the identity"* — and
+     * this is that, arriving from the two repos that measured it.
+     *
+     * "19px" means two different things in this row. A Lucide glyph is drawn in a 24 viewBox with its
+     * ink between 3 and 21, so a 19px box puts **14.25px** of ink on screen; a mark runs to the edge
+     * of its own viewBox and puts **18.65px**. The mark therefore reads about a third larger, which is
+     * exactly what it did — and while the mark was still coloured, colour carried part of that
+     * difference. Now that it is monochrome at rest, the size gap is the only thing left and it shows.
+     *
+     * 19 × 24/18 = 25.33px is the box at which a glyph's INK measures 19px, the same 19px the mark
+     * occupies. `:not(.tb-mark)` is not a special case — it is the same rule read the other way: a
+     * glyph carries padding inside its viewBox and a mark does not, so equal ink needs unequal boxes.
+     *
+     * app.zone settled it, qr arrived at the identical number, and qr's own comment says why it is
+     * here: *"otherwise every persona has to remember to carry it, which is precisely the thing the
+     * shared shell exists to prevent."* */
+    .tb-nav:not(.tb-mark) :global(svg) { width: 26.67px; height: 26.67px; }
 
-  // Both or neither — see the props above. When both are set the strip names the SECTIONS; core's
-  // default, which names the persona and its handle, is left entirely alone otherwise. Nothing here
-  // reproduces that default, which is the point: `.pname` and `.handle` stay core's business.
-  // ── the stage: the row stays LIVE, and using it pauses the game ───────────────────────────
-  // queries: toolbar during a game · tapping posts while playing · auto pause · data-stage-silent
-  //
-  // The row went inert for one version and the founder unlocked it: every control stays enabled,
-  // and touching ANY of them while a game is playing asks the game to pause first — so a player who
-  // reaches for the posts mid-flight gets a paused gull and the feed, in one tap. The event is not
-  // blocked: the action proceeds naturally while the pause lands beside it (a locked page still
-  // scrolls programmatically, so even the hash navigation works before the unlock).
-  //
-  // Declarative seam, as asked: an element that must NOT pause the game opts out by carrying
-  // `data-stage-silent` — on itself or any ancestor. Everything else pauses by default, because a
-  // rule with a default and an opt-out survives a fleet; a per-element opt-in is the third copy
-  // that forgets.
-  document.querySelector(".toolbar")?.addEventListener(
-    "click",
-    (e) => {
-      if (document.documentElement.dataset.stage !== "playing") return;
-      const hit = (e.target as Element | null)?.closest?.("a, button, select, [role=button]");
-      if (!hit || hit.closest("[data-stage-silent]")) return;
-      document.dispatchEvent(new CustomEvent("justai:pause-request"));
-    },
-    true,
-  );
+    /* THE BUBBLE HANGS. Its silhouette's centre measures 1.05px below the line the other three sit on
+       (39.05 against 38.0) because the tail is part of the shape and pulls the box down with it — the
+       glyph is centred while the thing you SEE is not. A pixel is inside the noise on most rows; on
+       four icons at one size sharing one baseline it is the only thing left that is not level.
+       Nudged rather than redrawn, and `transform` on the svg never collides with the press feedback:
+       `.tb-nav:active`'s scale lives on the anchor. Both repos carry this verbatim. */
+    #navPosts :global(svg) { transform: translateY(-1px); }
+  }
+</style>
 
-  const bar = document.querySelector(".toolbar") as HTMLElement | null;
-  const kt = bar?.dataset.kernelTitle;
-  const pt = bar?.dataset.postsTitle;
-  personaScroll(
-    kt && pt
-      ? { titleFor: (id: string) => (id === "kernel" ? kt : id === "posts" ? pt : "") }
-      : undefined,
-  );
-</script>
+  <script>
+    // The behaviour lives in ./behaviour/toolbar.ts — see that file for why it is not in here.
+    import "./behaviour/toolbar";
+  </script>