feat(site): track scroll viewport auto-follow

Author: beorn

CLAUDE.md

@@ -357,6 +357,13 @@ For `"manual"` and `"unprobed"` features, set the `probe` field to
 `"Manual verification required — no automated probe available."` and don't add a
 matching entry in `packages/probe-defs/`.
 
+For UI-owned viewport behavior, prefer `"manual"` plus an exact reproduction
+recipe over a fake automated probe. Examples: whether output while the user is
+scrolled up yanks the viewport to the live bottom, whether a scrollbar appears,
+or whether a copy/search UI opens. App-side PTY probes can observe parser output,
+cursor position, cell state, and query responses; they cannot observe the user's
+scrollback viewport unless a terminal exposes a separate automation API.
+
 ### Valid Tags
 
 Tags in `features.json` **must** match keys in `standards.json` or `categories.json`. Using an

content/categories.json

@@ -32,7 +32,7 @@
   "scrollback": {
     "label": "Scrollback",
     "order": 7,
-    "description": "Scroll buffer behavior, reverse index, total line tracking, and alternate screen interaction. Scrollback handling is one of the least standardized areas of terminal emulation — terminals differ in buffer size limits, whether alternate screen content enters scrollback, and how reverse index interacts with scroll regions.\n\nScrollback is the most implementation-specific area of terminal behavior. The ECMA-48 standard says nothing about scroll buffers — it's entirely a terminal emulator convention. Buffer sizes range from 0 lines (Alacritty's default was famously 0 on first release, fixed after user revolt) to 10 million+ (iTerm2). Kitty chose a different approach entirely: infinite scrollback stored efficiently on disk. The debate over whether the alternate screen should preserve scrollback has generated more terminal GitHub issues than almost any other topic."
+    "description": "Scroll buffer behavior, reverse index, total line tracking, viewport auto-follow policy, and alternate screen interaction. Scrollback handling is one of the least standardized areas of terminal emulation — terminals differ in buffer size limits, whether alternate screen content enters scrollback, whether new output yanks a scrolled-up viewport back to the live bottom, and how reverse index interacts with scroll regions.\n\nScrollback is the most implementation-specific area of terminal behavior. The ECMA-48 standard says nothing about scroll buffers — it's entirely a terminal emulator convention. Buffer sizes range from 0 lines (Alacritty's default was famously 0 on first release, fixed after user revolt) to 10 million+ (iTerm2). Kitty chose a different approach entirely: infinite scrollback stored efficiently on disk. The debate over whether the alternate screen should preserve scrollback, and whether output should auto-follow while the user is reading history, has generated more terminal GitHub issues than almost any other topic."
   },
   "reset": {
     "label": "Reset",

content/features.json

@@ -1197,6 +1197,16 @@
     "body": "DECSTBM with no parameters (<code>ESC [ r</code>) resets the scroll region to the full screen. After reset, scrolling operations should affect all rows. Applications use this to restore normal scrolling behavior after using scroll regions. Failing to properly reset can leave the terminal in a state where only part of the screen scrolls, causing rendering corruption for subsequent applications.",
     "probe": "Set DECSTBM 5;10, then send <code>\\x1b[r</code> (no params), write 30 lines, verify full-screen scrolling works (total lines > screen height)."
   },
+  "scrollback.viewport-hold-output": {
+    "name": "Viewport holds on output",
+    "slug": "viewport-holds-on-output",
+    "url": "https://invisible-island.net/xterm/manpage/xterm.html",
+    "tags": ["xterm-extensions"],
+    "baseline": "modern",
+    "body": "Tests whether the visible scrollback viewport stays anchored when new output arrives while the user is scrolled up in the main screen. This is a terminal UI policy, not a VT escape sequence: the application can write output, but the terminal emulator owns the user's viewport position.\n\nThis behavior matters for long-running inline applications, build logs, and agent UIs. If output forces the viewport back to the live bottom, users lose their place while reading history. If the viewport stays anchored, the newest output remains below the visible region until the user scrolls back down or presses a key that the terminal treats as an explicit return to the live region.\n\nTerminals expose this policy under different names and defaults. xterm has <code>scrollTtyOutput</code>; Ghostty exposes <code>scroll-to-bottom</code> with separate <code>keystroke</code> and <code>output</code> flags. Synchronized output (<code>DECSET 2026</code>) should only batch painting, but the manual probe repeats the test inside a synchronized-output block because terminal UI policies can still differ around batched output.",
+    "probe": "Manual UI probe. Fill scrollback with at least two pages of lines, scroll the viewport up until the live bottom is no longer visible, then emit a uniquely named marker line without keyboard input. Pass if the viewport remains on the old lines; fail if it jumps to the marker at the bottom. Repeat with the marker wrapped in <code>\\x1b[?2026h</code> ... <code>\\x1b[?2026l</code> to check synchronized output, and record any terminal setting that changes the result.",
+    "probeStatus": "manual"
+  },
   "extensions.kitty-keyboard": {
     "name": "Kitty keyboard protocol",
     "slug": "kitty-keyboard-protocol",

scripts/generate-api.ts

@@ -288,8 +288,9 @@ export function generateApi(outDir?: string): { dataPath: string; badgeCount: nu
     kitty: "kitty",
   }
 
-  // Merge all feature IDs
-  const allFeatureIds = new Set([...app.featureIds, ...headless.featureIds])
+  // Merge all feature IDs. features.json is authoritative for published
+  // feature pages; result files may lag for manual/unprobed features.
+  const allFeatureIds = new Set([...Object.keys(featuresJson), ...app.featureIds, ...headless.featureIds])
 
   // Build features map
   const features: ApiData["features"] = {}