[ { "productId": "alacritty", "storyId": "agent-drives-terminal", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Alacritty's only scripting surface is `alacritty msg` IPC, documented solely for creating new windows and reloading config (alacritty-docs-5, alacritty-docs-11/16) — there is no documented protocol for creating panes, running commands, or reading terminal output. The project explicitly states it deliberately excludes panes/splits, leaving that to window managers or multiplexers (alacritty-gh-3), and probes confirm no llms.txt or OpenAPI/API surface exists (alacritty-probe-1, alacritty-probe-2).", "evidenceIds": [ "alacritty-docs-5", "alacritty-docs-11", "alacritty-docs-16", "alacritty-gh-3", "alacritty-probe-1", "alacritty-probe-2" ] }, { "productId": "alacritty", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator with no llms.txt or agent-oriented documentation; a direct probe confirms llms.txt returns 404 and no OpenAPI/agent docs exist.", "evidenceIds": [ "alacritty-probe-1", "alacritty-probe-2" ] }, { "productId": "alacritty", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator with no AI/data-analysis features; this axis is a category error for this product type, not a missing capability.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a minimal GPU-accelerated terminal emulator with no AI features whatsoever; delegating tasks to a built-in AI assistant is entirely outside the scope of a terminal emulator's category, making this a category error rather than a missing feature.", "evidenceIds": [ "alacritty-gh-3", "alacritty-docs-4" ] }, { "productId": "alacritty", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "This product is not itself an agent, so publishing an official MCP server is plausible and the axis applies; no first-party MCP server appears in the evidence. (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator, not an AI agent/assistant; natural-language command operation is a category mismatch (wrong axis) for this product type.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "agentic-official-cli", "verdict": "full", "quality": 6, "confidence": "medium", "rationale": "Alacritty ships an official CLI: the `alacritty` binary itself plus documented subcommands like `alacritty msg create-window` for IPC control, which any script or agent can invoke non-interactively. Missing for 10: no AI-agent-specific documentation, no broader scripting/automation API beyond window creation/message IPC, and no independent corroboration of AI-driven usage.", "evidenceIds": [ "alacritty-docs-5", "alacritty-docs-11", "alacritty-docs-16" ] }, { "productId": "alacritty", "storyId": "agentic-public-api", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Alacritty documents a limited IPC surface via `alacritty msg` (e.g. create-window, config reload) that could be scripted by an external agent, but this is a narrow CLI/IPC mechanism rather than a full documented public API, and explicit probes show no OpenAPI spec or llms.txt endpoint exists. missing for 10: a comprehensive API reference (REST/RPC/plugin API), machine-readable API spec (OpenAPI/llms.txt), and evidence of AI/agent tooling built against it.", "evidenceIds": [ "alacritty-docs-11", "alacritty-docs-16", "alacritty-docs-5", "alacritty-probe-1", "alacritty-probe-2" ] }, { "productId": "alacritty", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator, not an API/service that issues credentials or manages agent authentication—this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "agentic-sdks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator, not an SDK/API product; the concept of 'official SDKs' for AI-native developers is a category mismatch (wrong axis) rather than a missing capability.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "ai-error-explanation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a GPU-accelerated terminal emulator with no AI features; it renders shell output but does not analyze commands or errors. AI explanation/fix suggestions are outside the scope of a terminal emulator's role (that belongs to a shell/CLI tool or AI assistant layered on top), making this a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "ai-privacy-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "api-interactive-docs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator, not an API/SDK product; an interactive API reference with runnable examples is a category mismatch for this kind of tool.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator, not a data platform or service with production/sandbox environments to test against; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "api-versioning-policy", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator, not an API/service product; the notion of versioned APIs with a deprecation policy is a category mismatch for this kind of tool.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "automation-bulk-operations", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a terminal emulator, not an AI-native automation or data-management tool; 'bulk operations across many items' is a category mismatch for a GPU-accelerated terminal application and doesn't map to any of its features (search, vi-mode, IPC control).", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "builtin-ai-agent", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "cli-remote-control", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Alacritty documents an IPC mechanism (`alacritty msg`) and explicitly shows opening new windows via `alacritty msg create-window` [alacritty-docs-5][alacritty-docs-11][alacritty-docs-16], satisfying the 'open windows' part of the story. However, there is no documentation of sending text to a running instance or querying terminal state via CLI/IPC, and a runtime probe could not even exercise `alacritty msg` on macOS due to a broken Homebrew cask [alacritty-probe-rt-1]. missing for 10: documented support for sending text input via CLI/IPC, ability to query terminal state, independent hands-on confirmation that `alacritty msg` works as described.", "evidenceIds": [ "alacritty-docs-5", "alacritty-docs-11", "alacritty-docs-16", "alacritty-probe-rt-1" ] }, { "productId": "alacritty", "storyId": "command-aware-features", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any shell-integration features like exit status reporting, command duration tracking, or completion notifications; Alacritty's documented feature set covers vi mode, search, selection, IPC/config, but nothing about command-aware shell integration.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "command-palette-discovery", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Alacritty explicitly positions itself as a minimal terminal with no built-in tabs, splits, or higher-level UI chrome, and there is no mention anywhere in docs or community evidence of a command palette or searchable action launcher; only scrollback search and vi-mode navigation exist, which are distinct features. No evidence supports discoverable/searchable command execution.", "evidenceIds": [ "alacritty-gh-3", "alacritty-docs-12", "alacritty-docs-13" ] }, { "productId": "alacritty", "storyId": "config-as-code", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Alacritty's config is a plain-text TOML file that supports importing additional files (great for dotfiles modularity), making it straightforward to version-control and sync across machines. Docs explicitly confirm TOML format and file import support. Missing for 10: no explicit community testimonial about dotfiles syncing workflow specifically.", "evidenceIds": [ "alacritty-docs-17", "alacritty-docs-8", "alacritty-docs-14" ] }, { "productId": "alacritty", "storyId": "cross-platform", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Alacritty documents cross-platform support (Linux, macOS, Windows, BSD) with a single TOML config file that can be imported across platforms (alacritty-gh-1, alacritty-gh-2, alacritty-docs-17, alacritty-docs-8/14), which is the vendor's basis for 'same config everywhere'. However hands-on reports concretely contradict smooth cross-platform parity: a user on Windows/WSL2 hit config gotchas after the TOML switch and couldn't get tmux/neovim shortcuts working before giving up (alacritty-comm-12), another notes modifier-key/shortcut problems in general (alacritty-comm-10), and a current runtime probe shows the macOS Homebrew cask install is broken due to a Gatekeeper failure, blocking straightforward install/use on macOS (alacritty-probe-rt-1). Missing for 10: independent confirmation that an identical config file behaves identically (especially keybindings) across all three OSes, and a working current macOS install path.", "evidenceIds": [ "alacritty-gh-1", "alacritty-gh-2", "alacritty-docs-17", "alacritty-docs-8", "alacritty-docs-14", "alacritty-comm-12", "alacritty-comm-10", "alacritty-probe-rt-1" ] }, { "productId": "alacritty", "storyId": "extensibility-plugins", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Alacritty's documented feature set is limited to TOML config, IPC via `alacritty msg`, vi-mode, search, and hints — there is no mention of Lua/Python scripting or a kittens-style plugin system, and the project explicitly positions itself as minimal (leaving multiplexing/extra features to other tools).", "evidenceIds": [ "alacritty-docs-8", "alacritty-docs-11", "alacritty-docs-17", "alacritty-gh-3", "alacritty-gh-5" ] }, { "productId": "alacritty", "storyId": "fonts-ligatures", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Community evidence explicitly states Alacritty lacks ligature support ('the classic ligature issue... given up hope there will ever be support') and no docs mention fallback-font configuration; only basic letter/line-spacing tuning (docs-33) is evidenced, which is insufficient to satisfy the combined ligatures+fallback+font-tuning story.", "evidenceIds": [ "alacritty-comm-8", "alacritty-docs-33" ] }, { "productId": "alacritty", "storyId": "gpu-accelerated-rendering", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Alacritty documents GPU rendering benchmarks (vtebench) showing it beats competitors, and multiple community users independently confirm it 'is the fastest' terminal they've used with performance described as 'amazing' [alacritty-gh-6, alacritty-comm-2, alacritty-comm-3, alacritty-comm-9]. However, a hands-on report describes concrete crashes during use — 'pty reader panicked at index out of bounds' and 'cursor fell off grid' — which are exactly the kind of failures that would occur under heavy terminal output, directly undermining the 'stays fast and responsive under heavy output' claim [alacritty-comm-5]. missing for 10: recent (non-2016) reproduction of the crash to confirm it still occurs, and first-party acknowledgment/fix of the pty-reader panic issue.", "evidenceIds": [ "alacritty-gh-6", "alacritty-comm-2", "alacritty-comm-3", "alacritty-comm-9", "alacritty-comm-5" ] }, { "productId": "alacritty", "storyId": "inline-images-graphics", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item mentions any inline image protocol (e.g., Sixel, Kitty graphics protocol, iTerm2 image protocol) or documented graphics support; Alacritty's docs focus on selection, search, vi mode, config, and IPC, with no mention of image rendering capability.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "measured-performance-claims", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Alacritty's GitHub README explicitly cites use of vtebench to quantify terminal throughput and claims it consistently outperforms competitors, and community anecdotes (HN threads) corroborate a perception of superior speed (e.g. faster startup than kitty, faster than iTerm2/Terminal in a `find` test). However, no actual published benchmark numbers, methodology, or reproducible latency/throughput figures are included in the evidence pack — only a claim of the benchmark's existence and qualitative community praise. Missing for 10: concrete vtebench output/numbers, methodology details, independent reproducible latency measurements.", "evidenceIds": [ "alacritty-gh-6", "alacritty-comm-2", "alacritty-comm-3", "alacritty-comm-14" ] }, { "productId": "alacritty", "storyId": "nl-command-generation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a GPU terminal emulator with no natural-language-to-shell-command generation feature; this AI-assistance axis is a category error for a terminal emulator, not a missing feature.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "openness-api-parity", "verdict": "partial", "quality": 2, "confidence": "medium", "rationale": "Alacritty offers a limited IPC via `alacritty msg` for actions like creating new windows and reloading config, but the vast majority of UI-driven features (vi mode navigation, search, selection, mouse interactions, hints) have no documented API/CLI equivalent. missing for 10: API parity for search/selection/vi-mode/mouse actions, documented full IPC command reference, evidence of programmatic control beyond window creation/config reload.", "evidenceIds": [ "alacritty-docs-5", "alacritty-docs-11", "alacritty-docs-16", "alacritty-docs-1", "alacritty-docs-12", "alacritty-docs-13" ] }, { "productId": "alacritty", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "openness-open-license", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Alacritty is a well-known open-source project hosted publicly on GitHub under an open license (BSD/Apache-style, common knowledge reinforced by the repo being the canonical source referenced throughout docs), with source, install instructions (cargo build/install), and INSTALL.md all publicly accessible. missing for 10: explicit citation of the LICENSE file text/name in the evidence pack.", "evidenceIds": [ "alacritty-gh-1", "alacritty-docs-18", "alacritty-docs-19", "alacritty-docs-10" ] }, { "productId": "alacritty", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a local terminal emulator with no cloud data storage or SaaS component; data residency/region selection is not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a local terminal emulator with no AI training or data-collection component; AI training data opt-out policy is not applicable to this product category.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Alacritty is a local terminal emulator with no data collection, cloud storage, or AI-related data handling; data retention/deletion controls are not a relevant axis for this category of product.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of telemetry, usage tracking, or any opt-out configuration setting for Alacritty; the docs cover config format, keybindings, and installation but never address data collection. missing for 10: any documentation or config option confirming telemetry exists or an opt-out mechanism, or explicit statement that no telemetry is collected.", "evidenceIds": [] }, { "productId": "alacritty", "storyId": "prompt-marks-navigation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence covers vi-mode navigation, scrollback search, and text selection, but there is no mention of shell integration (e.g., OSC 133 prompt/command marks) or a jump-to-previous/next-prompt feature. Missing for 10: any documentation of shell-integration hooks, prompt marks, or command-jump keybindings.", "evidenceIds": [ "alacritty-docs-1", "alacritty-docs-12", "alacritty-docs-20" ] }, { "productId": "alacritty", "storyId": "quake-dropdown-mode", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a global hotkey summon or quake-style dropdown window feature; Alacritty explicitly omits window-management features like tabs/splits, leaving such behavior to external tools (window managers/multiplexers), and no dropdown/hotkey capability is documented.", "evidenceIds": [ "alacritty-gh-3" ] }, { "productId": "alacritty", "storyId": "scripted-session-layouts", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Alacritty explicitly excludes window/session management, deferring tabs, splits, and layouts to external window managers or terminal multiplexers rather than providing built-in session/workspace config; no evidence of a startup-session or layout scripting mechanism exists in the pack.", "evidenceIds": [ "alacritty-gh-3", "alacritty-comm-4", "alacritty-comm-7" ] }, { "productId": "alacritty", "storyId": "scrollback-search", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Alacritty documents dedicated search functionality with forward/backward keybindings (Ctrl+Shift+F/B), and SearchStart/SearchEnd actions to jump between matches, plus vi-mode / (forward) and ? (backward) search integration. This directly satisfies searching scrollback and jumping between matches. Missing for 10: independent hands-on corroboration of search UX specifically (community evidence is silent on search quality) and no mention of match highlighting/count details.", "evidenceIds": [ "alacritty-docs-12", "alacritty-docs-26", "alacritty-docs-27", "alacritty-docs-20" ] }, { "productId": "alacritty", "storyId": "session-restore", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Alacritty explicitly does not implement tabs or splits, delegating such functionality to a window manager or multiplexer, and there is no evidence of any session/window/working-directory restoration feature after crash or restart.", "evidenceIds": [ "alacritty-gh-3", "alacritty-comm-7" ] }, { "productId": "alacritty", "storyId": "splits-tabs-panes", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Alacritty's own GitHub docs explicitly state it does not support tabs or splits, deferring that to a window manager or terminal multiplexer, and community feedback confirms the lack of tabs was a dealbreaker for some users.", "evidenceIds": [ "alacritty-gh-3", "alacritty-comm-7" ] }, { "productId": "alacritty", "storyId": "ssh-integration", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of any built-in SSH integration feature (e.g., automatic terminfo installation on remote host, shell-integration injection, or config sync over SSH) — only a passing mention that the local install ships a terminfo file. Community reports even describe friction with shortcuts inside tmux/neovim, but nothing about SSH-specific tooling.", "evidenceIds": [ "alacritty-docs-10", "alacritty-comm-10", "alacritty-comm-12" ] }, { "productId": "alacritty", "storyId": "theming-color-schemes", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Alacritty's TOML config lets users define custom colors via hex codes and import additional config files, which the community uses to build/swap color schemes, but there is no documented built-in mechanism for named themes or automatic OS light/dark mode switching. missing for 10: official theme gallery/switcher, automatic light/dark detection, live reload without restart for such changes.", "evidenceIds": [ "alacritty-docs-23", "alacritty-docs-30", "alacritty-docs-8", "alacritty-docs-14", "alacritty-docs-9", "alacritty-docs-15" ] }, { "productId": "alacritty", "storyId": "tmux-compat", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Alacritty explicitly positions itself as a minimal terminal that expects tabs/splits/multiplexing to be handled by an external tool like tmux (alacritty-gh-3), so tmux can be run inside it, but there is no documented native tmux integration or control mode. One community report even describes failing to get tmux shortcuts working properly under WSL2 (alacritty-comm-12), showing this isn't always frictionless. missing for 10: any native tmux control-mode/integration docs, first-party guidance on tmux keybinding compatibility, and stronger independent corroboration that tmux works smoothly.", "evidenceIds": [ "alacritty-gh-3", "alacritty-comm-12", "alacritty-comm-14", "alacritty-comm-10" ] }, { "productId": "alacritty", "storyId": "url-path-click", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Alacritty documents mouse-click URL opening (alacritty-docs-7, alacritty-docs-29) and keyboard-driven interaction via vi mode and 'terminal hints' for visible text (alacritty-docs-13, alacritty-docs-1), but the evidence never explicitly confirms hint/keyboard support for opening file paths specifically, only URLs. missing for 10: explicit documentation of file-path hint/click support, independent hands-on confirmation of URL/file clicking behavior.", "evidenceIds": [ "alacritty-docs-7", "alacritty-docs-29", "alacritty-docs-13", "alacritty-docs-1" ] }, { "productId": "ghostty", "storyId": "agent-drives-terminal", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Ghostty documents a built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events, which could let an agent create panes and send commands on macOS, but this is a niche, platform-limited mechanism, not a documented cross-platform control API, and there's no evidence it supports reading terminal output. A hands-on runtime probe explicitly found no remote-control/IPC interface beyond local CLI keybinding actions, meaning an external agent cannot send commands to or read output from a running instance via any documented protocol. missing for 10: cross-platform control API, documented output-reading mechanism, and confirmation that AppleScript scripting actually supports agent-driven read/write loops.", "evidenceIds": [ "ghostty-docs-9", "ghostty-docs-19", "ghostty-probe-rt-1" ] }, { "productId": "ghostty", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not a service with agent-facing docs; a direct probe confirms llms.txt and docs.md endpoints both return 404, meaning no agent-oriented docs are published for it to point at.", "evidenceIds": [ "ghostty-probe-1", "ghostty-probe-2" ] }, { "productId": "ghostty", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not a data/analytics product with AI-generated insights; this axis is a category error for its product type.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not an automation/orchestration platform; evidence shows only config, theming, and AppleScript scripting for launching windows/tabs, with a runtime probe explicitly confirming no remote-control/IPC interface exists for scripts or agents to run background automations. No evidence of scheduled tasks, background job runners, or agent-triggerable automation capabilities.", "evidenceIds": [ "ghostty-probe-rt-1", "ghostty-docs-9", "ghostty-docs-19" ] }, { "productId": "ghostty", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not an AI assistant product; there is no evidence (and no plausible category fit) for a built-in AI assistant to which tasks could be delegated. This is a wrong-axis question for a terminal emulator.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Ghostty is a GUI terminal emulator with GTK/macOS windowing dependencies (ghostty-comm-3, ghostty-comm-4), and a runtime probe found no remote-control/IPC interface, meaning scripts or agents cannot drive a running instance or invoke it headlessly for CI automation (ghostty-probe-rt-1). libghostty is for embedding terminal emulation in other apps, not for running Ghostty itself headlessly in CI.", "evidenceIds": [ "ghostty-probe-rt-1", "ghostty-comm-3", "ghostty-comm-4" ] }, { "productId": "ghostty", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not a service/platform with an agent-facing ecosystem; connecting an agent via an official MCP server is a category error for this product type — a terminal emulator's job is to run programs, not to expose an MCP server interface.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not an AI agent or assistant; operating it via natural-language commands is a category mismatch—it's a category error to expect NL command parsing from a terminal application itself (any NL interaction would occur via a shell/agent running inside it, not Ghostty).", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Ghostty only exposes a launch-time CLI (config flags, +list-actions/+help for bindable actions) but a runtime probe explicitly found no remote-control/IPC interface, meaning an external script or AI agent cannot send commands to or read output from a running Ghostty instance — the CLI is not built for agentic automation.", "evidenceIds": [ "ghostty-docs-37", "ghostty-probe-rt-1" ] }, { "productId": "ghostty", "storyId": "agentic-public-api", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Ghostty documents a macOS-only AppleScript dictionary for scripting windows/tabs/terminals/layouts and input events, and a libghostty C/Zig library for embedding terminal functionality, but these are aimed at embedding or macOS-specific automation, not a general documented public API for driving a running instance. A hands-on runtime probe found no remote-control/IPC interface — only a config-actions CLI — so an external agent/script cannot send commands to or read output from a live Ghostty session on the tested platform. Missing for 10: cross-platform scripting API, evidence AppleScript automation actually works end-to-end for external control, ability to read terminal output/state programmatically, and independent corroboration beyond vendor docs.", "evidenceIds": [ "ghostty-docs-9", "ghostty-docs-19", "ghostty-gh-2", "ghostty-gh-4", "ghostty-probe-rt-1", "ghostty-probe-1", "ghostty-probe-2", "ghostty-probe-3" ] }, { "productId": "ghostty", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not a service or API provider; issuing scoped/least-privilege API credentials for an agent is not an axis applicable to this product category.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "agentic-sdks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Ghostty does publish an official SDK — `libghostty`/`libghostty-vt`, a documented cross-platform C/Zig library for building terminal emulators or embedding terminal functionality, available across macOS/Linux/Windows/WASM. However, this is a general embedding library, not an AI-native or agent-oriented SDK, and a runtime probe found no remote-control/IPC interface, meaning agents can't programmatically drive a running Ghostty instance beyond config-time CLI actions. Missing for 10: AI-specific SDK documentation/examples, agent-facing runtime control API, and independent developer corroboration of building against libghostty for agentic use cases.", "evidenceIds": [ "ghostty-gh-2", "ghostty-gh-3", "ghostty-gh-4", "ghostty-docs-36", "ghostty-probe-rt-1" ] }, { "productId": "ghostty", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "ai-error-explanation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not an AI assistant or shell; it renders whatever shell/programs run inside it but has no built-in AI command-explanation or fix-suggestion feature, and the evidence pack (config, themes, rendering, latency, etc.) contains nothing about AI assistance — this is a wrong-axis capability for a terminal emulator itself.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "ai-privacy-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of any AI features, AI settings, session-data controls, or login requirements for Ghostty — it is documented purely as a native terminal emulator with configuration, theming, and libghostty embedding capabilities. Since terminal emulators (e.g., AI-augmented ones) can plausibly ship such features, the axis is applicable, but no evidence shows Ghostty offers or disables AI functionality or addresses data-egress/login controls.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "api-interactive-docs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not an API/SDK product with a hosted interactive API reference; there's no evidence of a REST/GraphQL API with runnable examples, and this axis is a category error for a terminal application (its docs/config reference and libghostty are static reference material, not an interactive runnable-example API explorer).", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not a testing/sandbox platform; sandboxed test environments for AI agents against production data are a wrong axis for this product category.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Ghostty exposes libghostty as an embeddable C/Zig API surface, which makes 'versioned API with deprecation policy' a fair question, but the evidence pack shows no mention of API versioning scheme or deprecation policy, and probes confirm no openapi/llms.txt docs describing such governance.", "evidenceIds": [ "ghostty-gh-2", "ghostty-gh-4", "ghostty-probe-3", "ghostty-probe-1" ] }, { "productId": "ghostty", "storyId": "automation-bulk-operations", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not a data/records management tool with collections of 'items' to bulk-act on; the story is a category error for this product type.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Ghostty offers fixed automatic behaviors (auto-detect password prompts, dark/light theme switching) and on-demand AppleScript scripting, but there is no evidence of a general user-definable rule/trigger system that fires actions on arbitrary terminal events, and a runtime probe explicitly found no remote-control/IPC surface for such automation.", "evidenceIds": [ "ghostty-docs-9", "ghostty-docs-10", "ghostty-docs-21", "ghostty-probe-rt-1" ] }, { "productId": "ghostty", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "builtin-ai-agent", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator with no built-in AI agent, planning, or command-approval workflow anywhere in its documented feature set; evidence covers configuration, themes, rendering, and scripting via AppleScript/CLI actions only. A runtime probe explicitly found no remote-control/IPC interface that would let an external agent send or approve commands, confirming absence of this capability.", "evidenceIds": [ "ghostty-probe-rt-1", "ghostty-docs-9", "ghostty-docs-37" ] }, { "productId": "ghostty", "storyId": "cli-remote-control", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Ghostty documents an AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events (macOS only), and exposes CLI flags mapping to config keys, but hands-on probing found no cross-platform CLI/IPC mechanism to remote-control a running instance — the CLI's +action surface only lists/binds actions locally, it cannot send text or query state of a live terminal from another process. missing for 10: a documented cross-platform IPC/socket/CLI remote-control protocol, evidence of sending text/querying state from an external script, and Linux/Windows equivalent to AppleScript automation.", "evidenceIds": [ "ghostty-docs-9", "ghostty-docs-19", "ghostty-docs-37", "ghostty-probe-rt-1" ] }, { "productId": "ghostty", "storyId": "command-aware-features", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of shell integration, exit status tracking, command duration, or completion notifications for Ghostty; only general feature docs (themes, keybindings, quick terminal, etc.) are present.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "command-palette-discovery", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Ghostty exposes keybindings, a config-driven action system, and a CLI `+list-actions`/`+help` surface, but nothing describes a searchable/discoverable command palette UI for running terminal actions interactively; the runtime probe explicitly notes there's no remote-control/interactive command surface beyond static CLI listing.", "evidenceIds": [ "ghostty-probe-rt-1", "ghostty-docs-4" ] }, { "productId": "ghostty", "storyId": "config-as-code", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Ghostty's config is a plain-text file (config-file key), supports splitting into multiple files for modular dotfiles, every key works as a CLI flag, and it can be reloaded live without restart, all of which make it straightforward to keep in a dotfiles repo and sync across machines. missing for 10: no explicit documentation or community confirmation of cross-platform (macOS/Linux/Windows) path consistency for the config file, and no first-party dotfiles-sync tooling or guide is mentioned.", "evidenceIds": [ "ghostty-docs-5", "ghostty-docs-6", "ghostty-docs-23", "ghostty-docs-37", "ghostty-docs-3" ] }, { "productId": "ghostty", "storyId": "cross-platform", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Ghostty documents strong config portability (single config file, config-file includes, hundreds of options, CLI-flag equivalence) and confirms macOS and Linux binaries, but the evidence pack never shows an actual Ghostty terminal app for Windows — only the underlying libghostty-vt library is said to target Windows/WebAssembly, and the docs explicitly note different default keybindings on macOS vs Linux, undercutting an identical experience even across the two platforms that are supported. missing for 10: confirmed Windows terminal application/binary release, identical default keybindings across platforms, and independent testimony of using the same config file on all three OSes.", "evidenceIds": [ "ghostty-docs-3", "ghostty-docs-5", "ghostty-docs-37", "ghostty-docs-15", "ghostty-docs-29", "ghostty-gh-4", "ghostty-docs-30" ] }, { "productId": "ghostty", "storyId": "extensibility-plugins", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Ghostty offers only configuration-file options, keybindings, and macOS-only AppleScript automation for driving the app externally; there is no evidence of a Lua/Python scripting API, plugin system, or kitten-style extension mechanism. The runtime probe explicitly confirms no remote-control/IPC surface exists beyond a fixed set of bindable actions, meaning scripts/plugins in a real language cannot extend the terminal.", "evidenceIds": [ "ghostty-docs-9", "ghostty-docs-19", "ghostty-probe-rt-1", "ghostty-docs-4" ] }, { "productId": "ghostty", "storyId": "fonts-ligatures", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Ghostty's docs explicitly cover ligature rendering (ghostty-docs-22/33), toggling programming ligatures via -calt (ghostty-docs-7), specifying font-features applied across all fonts (ghostty-docs-26), and configurable fallback fonts for missing codepoints (ghostty-docs-38), plus built-in nerd fonts and a default JetBrains Mono font (ghostty-docs-28). Community feedback corroborates deep, granular config tuning (minimum-contrast, selection colors) as a strength (ghostty-comm-5, ghostty-comm-6). Missing for 10: independent hands-on verification specifically of ligature rendering quality/fallback behavior beyond docs claims.", "evidenceIds": [ "ghostty-docs-22", "ghostty-docs-33", "ghostty-docs-7", "ghostty-docs-26", "ghostty-docs-38", "ghostty-docs-28", "ghostty-comm-5", "ghostty-comm-6" ] }, { "productId": "ghostty", "storyId": "gpu-accelerated-rendering", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Ghostty's docs/github tier claim libghostty provides core rendering performance (rendering capabilities, cross-platform GPU-based terminal library), but hands-on community reports concretely contradict smooth, fast performance under load: one user found higher input lag, blurrier fonts and 3-4x memory footprint versus a lightweight terminal, and an older independent latency benchmark showed Ghostty had the worst input latency among terminals tested — though a newer benchmark reported improved ~13ms latency and strong throughput comparable to Alacritty/Ptyxis. missing for 10: first-party performance benchmarks or documentation of GPU-rendering architecture, resolution of the reported high-memory/input-lag complaints, and consistent independent benchmark corroboration across time.", "evidenceIds": [ "ghostty-docs-36", "ghostty-gh-2", "ghostty-gh-3", "ghostty-comm-1", "ghostty-comm-7", "ghostty-comm-8", "ghostty-comm-9" ] }, { "productId": "ghostty", "storyId": "inline-images-graphics", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Ghostty's official docs explicitly document support for the Kitty graphics protocol, enabling inline image rendering directly in the terminal, and this is listed as a core feature alongside a broader reference on supported control sequences. Missing for 10: independent hands-on confirmation/testing of the graphics protocol specifically (community evidence covers other features but not image rendering) and detail on protocol coverage limits.", "evidenceIds": [ "ghostty-docs-2", "ghostty-docs-17", "ghostty-docs-1" ] }, { "productId": "ghostty", "storyId": "measured-performance-claims", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "No first-party published benchmarks exist in Ghostty's docs, but independent community benchmarks provide measured latency and throughput numbers (input latency improved to ~13ms in a newer test, throughput comparable to Alacritty/Ptyxis), while an older benchmark and a hands-on user reported markedly worse input latency and memory footprint than competitors. missing for 10: official vendor-published benchmark suite, consistent/reproducible throughput-latency methodology, and resolution of the conflicting community measurements.", "evidenceIds": [ "ghostty-comm-7", "ghostty-comm-8", "ghostty-comm-1" ] }, { "productId": "ghostty", "storyId": "nl-command-generation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a terminal emulator, not an AI assistant/shell; it has no natural-language-to-command generation feature, nor any documented AI integration for this purpose. This capability is a category error for a terminal emulator's product type, so the axis does not apply.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "openness-api-parity", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "Ghostty documents AppleScript automation for scripting windows/tabs/terminals (macOS only) and exposes config keys as CLI flags, but a hands-on runtime probe found no remote-control/IPC interface: the CLI only supports config/action listing, and there is no way for an external script or agent to send commands to or read output from a running Ghostty instance. This directly contradicts the idea of full UI/API parity for an AI-native user. missing for 10: a documented remote-control/scripting API beyond macOS AppleScript, ability to read terminal state/output programmatically, cross-platform (Linux/Windows) automation parity.", "evidenceIds": [ "ghostty-docs-9", "ghostty-docs-19", "ghostty-probe-rt-1", "ghostty-docs-37" ] }, { "productId": "ghostty", "storyId": "openness-full-export", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Ghostty's configuration lives in plain, human-readable text files that can be split, version-controlled, and passed as CLI flags, which gives a basic form of open, portable settings data — but there is no explicit 'export my data' feature, session/history export, or documented data-portability guarantee (and probes for llms.txt/docs export endpoints return 404). missing for 10: an explicit export/backup mechanism for data beyond config (e.g., scrollback, session state), documentation framing this as a data-ownership/exit story, and independent confirmation that users rely on this for full data portability.", "evidenceIds": [ "ghostty-docs-3", "ghostty-docs-5", "ghostty-docs-37", "ghostty-probe-1", "ghostty-probe-2" ] }, { "productId": "ghostty", "storyId": "openness-open-license", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Ghostty's source is hosted publicly on GitHub and the evidence confirms a public repo plus the libghostty/libghostty-vt libraries usable by developers, implying an open-source, readable codebase. However, no evidence item explicitly names or links the license text (e.g., MIT/Apache) confirming the terms under which the source can be read/used. Missing for 10: explicit license identification/citation, confirmation of license permissiveness, and any independent commentary on licensing terms.", "evidenceIds": [ "ghostty-gh-1", "ghostty-gh-2", "ghostty-gh-3", "ghostty-gh-4" ] }, { "productId": "ghostty", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a local terminal emulator application; it does not store user data in any cloud/region-selectable backend, so data residency/region selection is a category error for this product type.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a local terminal emulator, not an AI model provider or cloud service that trains on user data; AI-training data-use policy is not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Ghostty is a local terminal emulator with no cloud data storage, AI data processing, or account-based retention system — data retention/deletion controls are not a meaningful axis for this category of product.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack mentions telemetry, usage tracking, or an opt-out setting for Ghostty; the docs cover configuration, features, and performance but say nothing about data collection practices. Since this is a locally-installed terminal emulator, the axis is plausible (any app could collect usage data) but unaddressed, so it defaults to none rather than na.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "prompt-marks-navigation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack mentions shell integration, prompt/command marks, or scrollback navigation features (e.g., jump-to-prompt) for Ghostty; community feedback even highlights basic scrollback/search gaps without mentioning mark navigation.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "quake-dropdown-mode", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Ghostty documents a dedicated Quick Terminal feature that animates down for instant access without interrupting work, matching the quake-style dropdown request, and this is independently corroborated by a community member calling it 'ghostty's killer feature.' Custom global keybindings are also configurable via the keybind option. Missing for 10: explicit documentation confirming the Quick Terminal is bound to a global hotkey configurable across all platforms (evidence emphasizes macOS) and no independent hands-on walkthrough of summoning it via a custom global shortcut.", "evidenceIds": [ "ghostty-docs-8", "ghostty-docs-18", "ghostty-comm-12", "ghostty-docs-4" ] }, { "productId": "ghostty", "storyId": "scripted-session-layouts", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Ghostty offers rich config options, keybindings, and multi-window/tab/split support, plus a macOS-only AppleScript dictionary for 'scripting windows, tabs, terminals, layouts' which could approximate scripted startup layouts, but there is no documented session/layout file format or CLI flag to launch a predefined multi-window/tab/split workspace in one command (and probe evidence shows no external IPC/remote-control interface). missing for 10: cross-platform session/layout config file, documented 'launch project workspace' example, evidence of one-command startup replicating saved layouts, and confirmation the AppleScript route actually achieves this in practice.", "evidenceIds": [ "ghostty-docs-19", "ghostty-docs-9", "ghostty-docs-32", "ghostty-docs-40", "ghostty-docs-37", "ghostty-probe-rt-1" ] }, { "productId": "ghostty", "storyId": "scrollback-search", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No documentation feature for scrollback search exists, and multiple independent user reports confirm cmd-f/ctrl-f search does not work in Ghostty, calling it a blocker.", "evidenceIds": [ "ghostty-comm-13", "ghostty-comm-14", "ghostty-comm-16" ] }, { "productId": "ghostty", "storyId": "session-restore", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack of any session/window/tab restoration feature after restart or crash; docs only describe windows/tabs/splits creation and configuration, not persistence of state. This is a plausible axis for a terminal emulator (comparable tools offer session restore), but nothing here confirms Ghostty supports it.", "evidenceIds": [] }, { "productId": "ghostty", "storyId": "splits-tabs-panes", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Ghostty's official docs explicitly describe native support for multiple windows, each with its own tabs and splits, directly addressing the story of organizing work without an external multiplexer (ghostty-docs-32, ghostty-docs-40). Community discussion corroborates general daily-use satisfaction but does not specifically validate the pane/tab experience in depth. Missing for 10: independent hands-on validation specifically of the splits/tabs workflow (community comments focus on other features like search or scrollback), and no mention of pane resizing/navigation keybindings specifics.", "evidenceIds": [ "ghostty-docs-32", "ghostty-docs-40", "ghostty-docs-4" ] }, { "productId": "ghostty", "storyId": "ssh-integration", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "There is no documentation in the evidence pack describing an SSH integration feature that carries terminfo, shell integration, and config to remote hosts; instead, community reports describe Ghostty's custom TERM value causing 'missing or unsuitable terminal' errors on SSH and users citing SSH breakage as a recurring blocker.", "evidenceIds": [ "ghostty-comm-10", "ghostty-comm-11", "ghostty-comm-14" ] }, { "productId": "ghostty", "storyId": "theming-color-schemes", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docs explicitly confirm hundreds of built-in themes selectable via config, custom theme authoring, and automatic switching based on system light/dark mode, plus related fine-grained color config (minimum-contrast, selection colors) corroborated by community users praising these theming features. missing for 10: no independent hands-on demo/screenshot verifying auto light/dark switching in practice beyond docs claims.", "evidenceIds": [ "ghostty-docs-11", "ghostty-docs-21", "ghostty-docs-27", "ghostty-docs-12", "ghostty-comm-5", "ghostty-comm-6" ] }, { "productId": "ghostty", "storyId": "tmux-compat", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of tmux compatibility, tmux control mode, or any native tmux integration in Ghostty's docs or community reports; only SSH-related terminfo/control-character friction is discussed, which is a different issue. Since terminal emulators like iTerm2 do document explicit tmux control-mode support, this is a fair axis to expect evidence for, and none exists here.", "evidenceIds": [ "ghostty-comm-10", "ghostty-comm-11", "ghostty-comm-14" ] }, { "productId": "ghostty", "storyId": "url-path-click", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of clickable URL/path detection in terminal output; the closest feature (proxy icon drag) only concerns the current session's working directory in the title bar, not clicking links or paths within terminal output. Missing for 10: any documentation or community mention of URL/path hyperlink detection, click-to-open behavior, or keyboard-based link selection.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "agent-drives-terminal", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "iTerm2 ships a documented Python API explicitly for programmatic control — creating/manipulating sessions, panes, tabs, windows, reading and sending text, and building custom automation — plus AppleScript scripting, both well documented and corroborated by independent community praise calling the Python API 'basically AppleScript... but lets you touch pretty much everything.' This directly satisfies an agent programmatically driving panes/commands/output. missing for 10: no explicit example of an AI agent using the API end-to-end, and no independent hands-on report of agent-driven automation specifically (only general scripting use).", "evidenceIds": [ "iterm2-docs-13", "iterm2-docs-14", "iterm2-docs-33", "iterm2-gh-15", "iterm2-comm-5" ] }, { "productId": "iterm2", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes explicitly show no llms.txt or machine-readable/agent-oriented docs endpoint exists (404s), and no other evidence indicates agent-oriented documentation formats are offered.", "evidenceIds": [ "iterm2-probe-1", "iterm2-probe-2", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "iTerm2 ships an optional AI plugin providing a built-in LLM chat window that can be linked to sessions for context-aware help, command suggestions, and annotated explanations of terminal output (iterm2-docs-15, iterm2-gh-6), directly matching the 'AI-generated insights from data inside the product' story. However, the feature is opt-in, requires a user-supplied OpenAI key, and community reports noted the enable/disable toggle behaved unexpectedly (any text, even a stray space, activated data-sending), raising real caveats about robustness/trust rather than core functionality. Missing for 10: deeper first-party documentation of the AI feature's capabilities/limits, independent hands-on validation of insight quality, and confirmation the toggle bug was fully resolved.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6", "iterm2-comm-2", "iterm2-comm-3" ] }, { "productId": "iterm2", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "iTerm2 supports regex-based Triggers that autonomously fire actions (highlighting, running commands, notifications, invoking Python scripts) when patterns appear, and offers a full Python scripting API for background automation and custom features [iterm2-docs-16, iterm2-gh-2, iterm2-docs-13, iterm2-gh-15]. This provides generic background automation but isn't framed around AI-agent workflows specifically. missing for 10: evidence of AI-driven or agentic automations running unattended, scheduling/cron-like persistent background tasks tied to AI features, and independent confirmation that these automations run reliably without user oversight.", "evidenceIds": [ "iterm2-docs-16", "iterm2-gh-2", "iterm2-docs-13", "iterm2-gh-15", "iterm2-comm-5" ] }, { "productId": "iterm2", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "iTerm2 ships an optional AI plugin providing a built-in LLM chat window that can read terminal context, run commands on the user's behalf, and explain output (iterm2-docs-15, iterm2-gh-6), which matches the story of delegating tasks to an in-app assistant. However, it's an opt-in add-on requiring the user's own API key rather than a fully integrated default assistant, and community reports flagged a bug where the 'disabled' toggle didn't actually stop data being sent (iterm2-comm-2), raising real trust/reliability caveats. Missing for 10: first-party documentation of task-delegation scope/limits, independent hands-on validation that the assistant reliably executes delegated actions, and confirmation the toggle issue was resolved.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6", "iterm2-comm-1", "iterm2-comm-2", "iterm2-comm-3" ] }, { "productId": "iterm2", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "iTerm2 has an AI chat plugin and Python scripting API, but no evidence anywhere in the pack of MCP server integration or ability to plug in MCP tools. This is a plausible axis for a terminal with AI features, but absent evidence it defaults to none.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official MCP server for iTerm2; it offers an AI chat plugin (OpenAI-based) and Python/AppleScript scripting APIs, but nothing about MCP protocol support. Probes for docs/API specs also return 404s.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6", "iterm2-docs-13", "iterm2-probe-1" ] }, { "productId": "iterm2", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "iTerm2 ships an optional AI plugin/LLM chat window that can be linked to terminal sessions to provide context-aware help, explain output, and run commands on the user's behalf based on natural-language input (iterm2-docs-15, iterm2-gh-6). This is a genuine but optional, opt-in add-on requiring configuration (e.g., an OpenAI key) rather than a fully native, always-on NL interface, and community discussion flagged an early bug where the 'disabled' toggle didn't fully prevent data transmission (iterm2-comm-2), raising trust caveats without contradicting the core NL-command capability. Missing for 10: first-party documentation detailing the range/reliability of natural-language commands it can execute, independent hands-on reports confirming accurate command execution, and confirmation the toggle bug was fully resolved.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6", "iterm2-comm-2" ] }, { "productId": "iterm2", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "iTerm2 ships official automation surfaces — a Python scripting API and AppleScript support (iterm2-docs-13, iterm2-docs-14, iterm2-gh-15) — and community reports mention bundled command-line utilities like imgcat and it2dl for scripting terminal interactions (iterm2-comm-5, iterm2-comm-6), which could serve AI-native/agentic automation. However none of this constitutes a dedicated, documented 'official CLI' tool designed for agentic/AI-native control (e.g., no `iterm2` command-line binary with subcommands is described), and probes for machine-readable API docs (llms.txt, openapi.json) all 404 (iterm2-probe-1, iterm2-probe-3). Missing for 10: a first-party CLI binary/tool explicitly documented for scripting/automation, official docs framing it for AI-agent use, and independent confirmation of CLI-driven agentic workflows.", "evidenceIds": [ "iterm2-docs-13", "iterm2-docs-14", "iterm2-gh-15", "iterm2-comm-5", "iterm2-comm-6", "iterm2-probe-1", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "iTerm2 documents a full Python API (iterm2 package) for scripting/controlling the app, plus AppleScript support, both with dedicated documentation pages and community corroboration of hands-on use (imgcat, it2dl, Python scripting praised as far superior to AppleScript). This constitutes a documented public API for programmatic/agentic control, though it's not a modern REST/OpenAPI-style API and no llms.txt/OpenAPI spec exists. Missing for 10: a formal OpenAPI/REST-style spec or llms.txt discoverability layer, and no evidence of AI-agent-specific SDK usage beyond scripting.", "evidenceIds": [ "iterm2-docs-13", "iterm2-docs-14", "iterm2-docs-33", "iterm2-gh-15", "iterm2-comm-5", "iterm2-probe-1", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "iTerm2 has a Python scripting API and an optional AI plugin, but there is no evidence of any mechanism for issuing scoped or least-privilege API credentials for agents; no auth/permission-scoping model is documented, and openapi/API-key probes return 404.", "evidenceIds": [ "iterm2-docs-13", "iterm2-docs-15", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "iTerm2 ships an official, documented Python API for scripting and automating the terminal (create triggers, status bar components, menu items, full control), which an AI-native builder could use to construct agentic integrations, and this is corroborated by community praise for the API's flexibility. However, there's no dedicated 'AI SDK' or agent-specific developer kit — the AI feature (docs-15) is a plugin/toggle for chat, not an SDK — and probes show no llms.txt, machine-readable docs, or OpenAPI spec. Missing for 10: AI/agent-specific SDK or API, multi-language SDK support, official developer docs/examples framed around AI-agent integration.", "evidenceIds": [ "iterm2-docs-13", "iterm2-gh-15", "iterm2-comm-5", "iterm2-docs-15", "iterm2-probe-1", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any webhook subscription mechanism; iTerm2 offers triggers and a Python scripting API for local automation but nothing about outbound webhook events or subscriptions is documented.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "ai-error-explanation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "iTerm2 ships an optional AI plugin with a built-in LLM chat window that can link to a session, view terminal contents, and 'explain output with annotations' or run commands on your behalf, which is generic AI assistance but not documented as a specific 'command failed → suggested fix' workflow. missing for 10: explicit documentation of automatic failure detection, error-specific explanations, and suggested command fixes; independent hands-on evidence of this exact use case working.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6" ] }, { "productId": "iterm2", "storyId": "ai-privacy-controls", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "iTerm2 ships AI chat as an optional, install-only plugin with no forced login (iterm2-docs-15, iterm2-gh-6), suggesting users can ignore or avoid it entirely. However, hands-on community reports concretely contradict 'clear control': a user found that merely putting any text (even a stray space) in the API key field silently activates data-sending to OpenAI, with no reliable way to see the feature is actually disabled (iterm2-comm-2), and another reacted by switching terminals entirely over trust concerns (iterm2-comm-1). Missing for 10: no documentation on exactly what session data leaves the machine when AI chat is enabled, no fix/acknowledgment of the toggle bug, and no independent verification that the issue was resolved.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6", "iterm2-comm-1", "iterm2-comm-2", "iterm2-comm-3" ] }, { "productId": "iterm2", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "iTerm2 does have a Python scripting API (iterm2-docs-13) so this axis is plausible, but there's no evidence of an interactive API reference with runnable examples—probes confirm no OpenAPI/swagger docs, no llms.txt, and no docs-as-markdown endpoint, and no community or docs evidence describes an interactive/executable API playground.", "evidenceIds": [ "iterm2-docs-13", "iterm2-probe-1", "iterm2-probe-2", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "iTerm2 offers a Python scripting API but no evidence of a downloadable OpenAPI/machine-readable API spec; explicit probes for llms.txt, docs-md, and openapi.json all returned 404.", "evidenceIds": [ "iterm2-probe-1", "iterm2-probe-2", "iterm2-probe-3", "iterm2-docs-13" ] }, { "productId": "iterm2", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "iTerm2 is a terminal emulator, not a testing/sandbox environment product; the concept of a sandbox vs. production data separation is not an axis this product category addresses.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "There is no evidence of a versioned API contract or documented deprecation policy; the Python API docs exist but no version/deprecation policy is mentioned, and probes for API discovery artifacts (llms.txt, openapi.json) all 404.", "evidenceIds": [ "iterm2-docs-13", "iterm2-probe-1", "iterm2-probe-2", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "iTerm2 exposes a Python scripting API and AppleScript that can programmatically iterate over sessions/tabs, and Global Search lets users search across all tabs at once, which together imply some bulk-automation capability. However, there is no direct evidence of a dedicated bulk-operation feature (e.g., broadcast-to-all-panes) or hands-on proof that AI-driven bulk actions across many items actually work reliably. Missing for 10: explicit bulk-command/broadcast feature documentation, concrete examples of Python API performing multi-session bulk operations, independent confirmation of scale/performance.", "evidenceIds": [ "iterm2-docs-13", "iterm2-gh-15", "iterm2-docs-18", "iterm2-docs-14" ] }, { "productId": "iterm2", "storyId": "automation-rules-engine", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "iTerm2 supports user-defined Triggers that fire on regex matches from terminal output, enabling automatic actions like highlighting, running commands, sending notifications, invoking Python scripts, or opening a password manager — a documented rules-on-event automation system, further extensible via the Python API for custom triggers/behaviors. missing for 10: no independent hands-on validation of complex trigger chains, and no evidence of AI-specific event-triggering beyond generic regex triggers.", "evidenceIds": [ "iterm2-docs-16", "iterm2-gh-2", "iterm2-gh-15", "iterm2-docs-13" ] }, { "productId": "iterm2", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "iTerm2 offers triggers, Python scripting API, and AppleScript automation, but there is no evidence of a scheduler or mechanism for recurring/cron-like jobs or workflows; automation is event-triggered or manually scripted, not scheduled.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any version control, review, or rollback mechanism for automations (triggers, Python scripts, profiles). iTerm2 supports scripting and triggers, but nothing in the evidence pack shows versioning, diffing, review workflows, or rollback of these automations.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "builtin-ai-agent", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "iTerm2 ships an optional AI plugin providing a built-in LLM chat that can be linked to a session to give context-aware help, explain output, and 'run commands on your behalf' (iterm2-docs-15, iterm2-gh-6), which is a real but thin form of AI-agent delegation. However, there's no documented explicit plan-then-approve workflow (e.g., showing a command and requiring confirmation before execution), and community reports raise concerns that the AI toggle's off/on state was ambiguous, undermining confidence in a clean approval gate (iterm2-comm-1, iterm2-comm-2). Missing for 10: documented step-by-step approval/confirmation UI before command execution, evidence of autonomous multi-step planning, and independent hands-on validation that the agent respects user approval before running commands.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6", "iterm2-comm-1", "iterm2-comm-2" ] }, { "productId": "iterm2", "storyId": "cli-remote-control", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "iTerm2 documents a robust Python API for scripting/controlling the terminal (open sessions, send text, query state) and AppleScript support for launching/controlling sessions, with independent community corroboration praising the Python API's power over AppleScript. missing for 10: no evidence of a CLI-only (non-Python/AppleScript) IPC socket documentation, and no hands-on demonstration of specific 'query state' calls beyond general docs.", "evidenceIds": [ "iterm2-docs-13", "iterm2-docs-14", "iterm2-docs-33", "iterm2-gh-15", "iterm2-comm-5" ] }, { "productId": "iterm2", "storyId": "command-aware-features", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "iTerm2's shell integration docs confirm tracking of command history, prompts, directories, and hostnames, plus notifications for job completion/bells/activity and prompt navigation shortcuts. missing for 10: explicit documentation citing per-command exit status/duration display and independent hands-on confirmation of the notification-on-completion behavior.", "evidenceIds": [ "iterm2-docs-8", "iterm2-docs-31", "iterm2-docs-37", "iterm2-docs-9", "iterm2-docs-24" ] }, { "productId": "iterm2", "storyId": "command-palette-discovery", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "iTerm2's 'Open Quickly' (Cmd-Shift-O) is a searchable palette, but evidence describes it only as a search across sessions by tab title, command, hostname, directory, or badge — not a general command palette for discovering and invoking arbitrary terminal actions/menu commands. Missing for 10: evidence of listing/searching actual app commands or actions (not just sessions), evidence of executing arbitrary actions from the palette, and independent confirmation of this behaving like a true command palette.", "evidenceIds": [ "iterm2-gh-5", "iterm2-gh-7", "iterm2-gh-14", "iterm2-docs-4" ] }, { "productId": "iterm2", "storyId": "config-as-code", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of iTerm2's preferences file format, exporting/importing settings as plain-text/plist files, or any dotfiles-style sync workflow across machines. Without evidence for this specific capability, it cannot be credited even though it is a plausible axis for a terminal emulator.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "cross-platform", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "iTerm2 is a macOS-only application; no evidence pack item claims Linux or Windows support, and a community source explicitly notes the lack of a comparable replacement on Windows or Linux, confirming it does not run cross-platform.", "evidenceIds": [ "iterm2-comm-8", "iterm2-docs-20" ] }, { "productId": "iterm2", "storyId": "extensibility-plugins", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "iTerm2 offers a documented Python API for full automation/customization (custom status bar components, triggers, menu items, new features), plus AppleScript scripting and trigger-invoked Python scripts, with community hands-on praise calling it 'basically AppleScript... but not soul-crushing to write' and noting real-world tools like imgcat/it2dl built on it. This covers 'real language' scripting well beyond built-in options, though there's no mention of Lua or 'kittens' (a kitty-terminal concept) support specifically. Missing for 10: Lua scripting support, kitten-style plugin format, independent third-party plugin ecosystem showcase.", "evidenceIds": [ "iterm2-docs-13", "iterm2-docs-14", "iterm2-docs-33", "iterm2-gh-15", "iterm2-gh-2", "iterm2-comm-5" ] }, { "productId": "iterm2", "storyId": "fonts-ligatures", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of font rendering, ligature support, fallback fonts, or font-tuning settings anywhere in iTerm2's docs, GitHub feature list, or community discussion; only general 'mind-boggling number of options' and color-mode claims are present, which don't address fonts specifically. Missing for 10: any mention of font selection, ligature support, fallback font configuration, or font-size/spacing tuning options.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "gpu-accelerated-rendering", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions GPU acceleration, rendering architecture, or performance under heavy output/scrollback; the docs and community items cover features like panes, triggers, search, and scripting but nothing about rendering performance or GPU usage.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "inline-images-graphics", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "iTerm2 documents a custom escape sequence for inline image display (including animated GIFs), and community hands-on evidence corroborates real-world use via imgcat working over SSH. missing for 10: a formal protocol specification page/name (e.g. explicit 'inline images protocol' spec doc) and broader third-party adoption/compatibility discussion beyond one HN thread.", "evidenceIds": [ "iterm2-docs-11", "iterm2-comm-5" ] }, { "productId": "iterm2", "storyId": "measured-performance-claims", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item presents published benchmarks, latency/throughput numbers, or any measured performance data for iTerm2; the material covers features (panes, tmux integration, scripting) and unrelated community discussion (AI feature controversy, a security disclosure) with no performance metrics whatsoever.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "nl-command-generation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "iTerm2 ships an optional AI plugin and a built-in LLM chat window that can be linked to a session to 'run commands on your behalf' or explain output (iterm2-docs-15, iterm2-gh-6), which supports natural-language-to-command generation, but this is a separate opt-in chat pane requiring an API key rather than inline generation directly at the shell prompt. Community commentary focuses on privacy/toggle concerns (iterm2-comm-1, iterm2-comm-2) rather than confirming accuracy or in-place command insertion. Missing for 10: evidence of commands being generated and inserted directly into the terminal prompt (not just a chat window), and independent verification of command-generation quality/reliability.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6", "iterm2-comm-1", "iterm2-comm-2" ] }, { "productId": "iterm2", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "iTerm2's Python API is documented as controlling and extending iTerm2 behavior (custom status bar, triggers, menu items, session control), and a community hands-on review calls it able to 'touch pretty much everything' via scripting, which supports broad API-driven control. However, there's no evidence of a formal claim or documentation of full UI/API parity — no explicit list mapping every UI feature (e.g. AI chat, browser profiles, tmux integration) to API equivalents, and probes show no OpenAPI spec or llms.txt for verifying coverage. Missing for 10: explicit parity documentation, API coverage for newer UI features (AI chat, browser profiles), and independent verification that all UI actions are scriptable.", "evidenceIds": [ "iterm2-docs-13", "iterm2-gh-15", "iterm2-comm-5", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of any data export feature or open-format export for iTerm2's own data (settings, session history, paste history, profiles); the evidence pack instead shows probes for llms.txt/openapi returning 404s and no mention of export/portability tooling. missing for 10: documented export of preferences/profiles/history in open formats, data portability guarantees, migration/export tooling.", "evidenceIds": [ "iterm2-probe-1", "iterm2-probe-2", "iterm2-probe-3" ] }, { "productId": "iterm2", "storyId": "openness-open-license", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "The evidence repeatedly cites a public GitHub repository (github.com/gnachman/iTerm2) as the canonical source for iTerm2's features, indicating the source code is publicly hosted and readable. However, none of the evidence explicitly states or links to a specific open-source license (e.g., GPL) or license file, so the 'open license' claim is not directly confirmed. Missing for 10: explicit license identification/text, documentation page confirming licensing terms, independent confirmation of license compliance.", "evidenceIds": [ "iterm2-gh-1", "iterm2-gh-4", "iterm2-gh-15" ] }, { "productId": "iterm2", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "iTerm2 is a local desktop terminal emulator that runs on the user's own machine; data residency/region selection is a cloud-service concept and doesn't apply to a local application (the optional AI plugin sends data to OpenAI's API but offers no region choice, which is a separate privacy-toggle concern, not residency).", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "privacy-no-training", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "iTerm2's AI features are documented as optional/opt-in (an installable plugin and an LLM chat window that 'optionally' interacts with terminal contents), implying a way to keep AI features off, but hands-on community reports show the opt-in control was broken: entering any value (even a space) in the API-key field activated data-sending to OpenAI regardless of intent, meaning users could not reliably prevent their terminal data from being sent to a third-party AI provider. There is no vendor documentation addressing training-data usage or an explicit training opt-out policy at all. missing for 10: explicit training-data opt-out/privacy statement, evidence the opt-in toggle was fixed and verified reliable, independent corroboration beyond the single HN thread.", "evidenceIds": [ "iterm2-docs-15", "iterm2-gh-6", "iterm2-comm-1", "iterm2-comm-2", "iterm2-comm-3" ] }, { "productId": "iterm2", "storyId": "privacy-retention-controls", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "iTerm2's AI plugin is opt-in and framed as controllable (docs-15), but hands-on community reports show the 'disable' toggle for sending data to OpenAI is not reliable — any non-empty (even accidental whitespace) API key field activates data transmission, undermining claimed control over what data leaves the machine (comm-2). No documentation addresses retention windows, deletion of stored chat/AI data, or data lifecycle policies at all. missing for 10: explicit data retention/deletion settings, documentation on how long AI chat context or API data is stored, independent confirmation that the toggle issue was fixed.", "evidenceIds": [ "iterm2-docs-15", "iterm2-comm-2", "iterm2-comm-1", "iterm2-comm-3" ] }, { "productId": "iterm2", "storyId": "privacy-telemetry-optout", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "iTerm2's AI feature is documented as an optional, install-only component (iterm2-docs-15), implying users can opt out of any AI-related data sharing by not installing/enabling it. However, hands-on community reports directly contradict this: users found that entering any text (even a stray space) in the OpenAI API key field silently activated data-sending, meaning the feature wasn't truly opt-out/disabled as claimed [iterm2-comm-2], while other users defended the feature as inactive-by-default [iterm2-comm-3]. Missing for 10: no general telemetry/usage-tracking opt-out setting is documented at all (the evidence only covers the AI plugin's data flow to OpenAI, not broader telemetry), and no vendor response addressing the toggle bug is provided.", "evidenceIds": [ "iterm2-docs-15", "iterm2-comm-1", "iterm2-comm-2", "iterm2-comm-3" ] }, { "productId": "iterm2", "storyId": "prompt-marks-navigation", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "iTerm2's shell integration explicitly tracks prompts and sets marks at each command, and docs describe navigating between previous shell prompts with ⇧⌘↑/⇧⌘↓, corroborated by GitHub feature list mentioning marks at each prompt and copy mode working with marks to jump between prompts. Missing for 10: no independent hands-on account specifically confirming the prompt-jump keybinding in practice beyond docs/GitHub summaries.", "evidenceIds": [ "iterm2-docs-8", "iterm2-docs-9", "iterm2-docs-31", "iterm2-docs-24", "iterm2-gh-10", "iterm2-gh-8" ] }, { "productId": "iterm2", "storyId": "quake-dropdown-mode", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docs explicitly describe a global hotkey to bring iTerm2 to the foreground from any app, and GitHub evidence confirms a quake-style dropdown that slides down from a screen edge, even over fullscreen apps. Missing for 10: independent hands-on user testimonial specifically praising the hotkey/dropdown window feature.", "evidenceIds": [ "iterm2-docs-2", "iterm2-docs-26", "iterm2-gh-17" ] }, { "productId": "iterm2", "storyId": "scripted-session-layouts", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "iTerm2's AppleScript scripting explicitly supports launching the app and opening multiple sessions with profiles into new tabs/windows (a scripted workspace startup), and the Python API/triggers offer additional automation of session/window setup; profiles themselves can also be tied to directories/hosts for one-command workspace opening. missing for 10: no first-party example of a saved 'window arrangement' config file format or direct hands-on community confirmation of a single-command full-layout launch.", "evidenceIds": [ "iterm2-docs-14", "iterm2-docs-33", "iterm2-docs-13", "iterm2-docs-32", "iterm2-comm-5" ] }, { "productId": "iterm2", "storyId": "scrollback-search", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs describe a robust find-on-page feature with instant highlighting of all matches and regex support, plus Global Search across all tabs, directly matching the story of searching scrollback and jumping between matches. Missing for 10: independent hands-on confirmation of match-jump behavior (next/prev match navigation) and details on keyboard shortcuts for cycling matches.", "evidenceIds": [ "iterm2-docs-3", "iterm2-docs-34", "iterm2-docs-18" ] }, { "productId": "iterm2", "storyId": "session-restore", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Session restoration via long-lived server processes reconnects shells (including working directories via shell integration) after crash/restart, and tmux -CC integration persists windows/tabs/panes even when iTerm2 or the SSH session drops. Missing for 10: no independent/hands-on confirmation of restoring exact tab/pane layout after a full app crash, only vendor/docs claims.", "evidenceIds": [ "iterm2-gh-4", "iterm2-gh-9", "iterm2-gh-11", "iterm2-docs-12", "iterm2-docs-19", "iterm2-docs-8", "iterm2-docs-31" ] }, { "productId": "iterm2", "storyId": "splits-tabs-panes", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "iTerm2 natively supports splitting tabs into multiple panes (vertical/horizontal) and organizing sessions across tabs and windows, directly replacing the need for tmux/screen for basic pane-and-tab workflows, with session restoration and profile-based organization further supporting this. missing for 10: independent hands-on verification specifically of pane-splitting workflow (community evidence focuses on other features like imgcat/scripting rather than confirming multiplexing usability directly).", "evidenceIds": [ "iterm2-docs-1", "iterm2-docs-25", "iterm2-gh-4", "iterm2-docs-30", "iterm2-docs-32" ] }, { "productId": "iterm2", "storyId": "ssh-integration", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "iTerm2 documents shell integration explicitly designed to work 'even over ssh', tracking command history, cwd, and hostname (iterm2-docs-8, iterm2-docs-31), plus automatic profile switching keyed to SSH hostname/user (iterm2-docs-10, iterm2-docs-32) and tmux -CC integration that persists sessions across SSH drops (iterm2-docs-12, iterm2-docs-19, iterm2-docs-23). Community hands-on reports corroborate SSH-aware features working in practice, e.g. imgcat rendering images 'even across SSH connections' and it2dl for remote file downloads (iterm2-comm-5, iterm2-comm-6). Missing for 10: explicit documentation of terminfo propagation itself and independent benchmarking of config/profile carry-over reliability across varied SSH setups.", "evidenceIds": [ "iterm2-docs-8", "iterm2-docs-31", "iterm2-docs-10", "iterm2-docs-32", "iterm2-docs-12", "iterm2-docs-19", "iterm2-docs-23", "iterm2-comm-5", "iterm2-comm-6" ] }, { "productId": "iterm2", "storyId": "theming-color-schemes", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of color schemes, themes, or automatic light/dark mode switching for iTerm2 despite this being a plausible and well-known capability for a terminal emulator; no docs, GitHub, or community citations address theming at all. missing for 10: any documentation or mention of color scheme/theme support, dark mode toggling, or automatic OS appearance syncing.", "evidenceIds": [] }, { "productId": "iterm2", "storyId": "tmux-compat", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "iTerm2 has a well-documented native tmux control mode (tmux -CC) that integrates tmux sessions natively into iTerm2's window/pane UI while preserving persistence across SSH disconnects and app restarts, plus standard tmux-in-terminal usage is naturally supported. Missing for 10: independent hands-on corroboration specifically of tmux -CC mode (community evidence covers other features, not tmux integration directly).", "evidenceIds": [ "iterm2-docs-12", "iterm2-docs-19", "iterm2-docs-23", "iterm2-docs-40" ] }, { "productId": "iterm2", "storyId": "url-path-click", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Smart Selection with quad-click and Cmd-click to open URLs/paths, plus keyboard-based selection (Copy Mode/vim-like navigation), are documented and corroborated by community hands-on reports (Semantic History opening files in editor via Cmd+Click). missing for 10: no independent verification of full keyboard-only 'select and open' flow beyond selection, only Cmd-click for opening.", "evidenceIds": [ "iterm2-gh-3", "iterm2-docs-17", "iterm2-docs-38", "iterm2-gh-8", "iterm2-gh-13", "iterm2-comm-7", "iterm2-docs-5" ] }, { "productId": "kitty", "storyId": "agent-drives-terminal", "verdict": "full", "quality": 10, "confidence": "high", "rationale": "kitty ships a documented remote-control protocol (kitty @ commands) letting scripts/agents open windows, send text, read output, and manage layouts, and this was independently verified hands-on end-to-end (ls, send-text, get-text, close-window) confirming a real programmatic control loop.", "evidenceIds": [ "kitty-docs-1", "kitty-docs-23", "kitty-docs-27", "kitty-probe-4", "kitty-probe-rt-1" ] }, { "productId": "kitty", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes explicitly show no llms.txt (404), no markdown-flavored docs endpoint, and no OpenAPI/agent-discovery spec; all documentation is standard human-oriented HTML with no agent-oriented onboarding artifact for pointing an AI agent at.", "evidenceIds": [ "kitty-probe-1", "kitty-probe-2", "kitty-probe-3" ] }, { "productId": "kitty", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Kitty is a terminal emulator; it has no data ingestion, analytics, or AI-generated insight/suggestion feature over user data. The evidence covers remote control, graphics protocol, shell integration, and performance/config feedback — none relate to AI-generated insights from data, which is a category mismatch for a terminal emulator.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "kitty", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a terminal emulator, not an AI assistant product; it has no built-in AI/agent feature to delegate tasks to. Its remote-control and scripting capabilities allow external tools/agents to control kitty, but that's the reverse relationship — this is a category mismatch, not a missing feature.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "agentic-headless", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Kitty documents and hands-on-verifies a scripts/remote-control interface (kitten @ commands) and supports launching in `--detach` mode with a listening socket, which enables automation-style control loops (open, send-text, read-text, close) as verified in the runtime probe. However, kitty is fundamentally a GUI terminal emulator; there is no documentation of a true headless/no-display mode for CI pipelines (e.g., Xvfb-free operation) or CI-specific guidance. Missing for 10: explicit CI/headless-without-display documentation, and independent confirmation of running in a CI pipeline environment.", "evidenceIds": [ "kitty-docs-1", "kitty-docs-23", "kitty-probe-rt-1", "kitty-probe-4" ] }, { "productId": "kitty", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "kitty", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "This product is not itself an agent, so publishing an official MCP server is plausible and the axis applies; no first-party MCP server appears in the evidence. (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "kitty", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a terminal emulator; it offers scriptable remote-control and shell integration but no natural-language/AI command interface is claimed or evidenced. This axis concerns operating via NL commands, which is a category mismatch for a low-level terminal emulator rather than a missing feature of its type — no evidence contradicts this to flip it applicable.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "agentic-official-cli", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "kitty ships an official `kitty @` remote-control CLI (kitten) documented and hands-on verified to list windows, send text, read output, and close windows via JSON — a full scriptable automation loop suitable for AI-native agent control. missing for 10: independent third-party corroboration beyond the single hands-on probe and official docs.", "evidenceIds": [ "kitty-docs-1", "kitty-docs-23", "kitty-probe-4", "kitty-probe-rt-1" ] }, { "productId": "kitty", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "kitty ships a well-documented remote-control API (`kitty @` / `kitten @`) allowing scripts/agents to open windows, send text, read output, and manage layout, and this was independently verified hands-on with a full agent-control loop (list, send-text, get-text, close-window). Missing for 10: no formal OpenAPI/machine-readable schema (probe shows 404s for openapi.json/llms.txt), so discovery is documentation-only rather than a structured API spec.", "evidenceIds": [ "kitty-docs-1", "kitty-docs-23", "kitty-probe-rt-1", "kitty-probe-4", "kitty-probe-3" ] }, { "productId": "kitty", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "kitty's remote-control feature allows scripts to control the terminal, but there is no evidence of scoped or least-privilege credential issuance — the remote control model uses a single unix socket/password with allow/deny options, not per-agent scoped API keys or tokens. No documentation or probe evidence shows credential scoping, permission tiers, or revocable least-privilege tokens for agents.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "agentic-sdks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a terminal emulator; 'official SDKs' for building applications is a category error here — it exposes remote-control APIs/protocols (covered by other stories) but does not offer language SDKs as a product axis for a terminal emulator.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "kitty", "storyId": "ai-error-explanation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a terminal emulator, not an AI/LLM-integrated shell or agent; there is no evidence of any built-in AI explanation or auto-fix feature for failed commands, and this capability is not a fair expectation of a terminal emulator's core feature set (as opposed to a shell/AI-CLI wrapper).", "evidenceIds": [] }, { "productId": "kitty", "storyId": "ai-privacy-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "kitty", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of an interactive API reference with runnable examples; probes explicitly show no OpenAPI/llms.txt and only static docs pages for remote-control, which is documentation, not an interactive/runnable API explorer.", "evidenceIds": [ "kitty-probe-1", "kitty-probe-3", "kitty-docs-1" ] }, { "productId": "kitty", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes explicitly checked for a machine-readable API spec (OpenAPI/swagger/llms.txt) and all returned 404s; kitty's remote-control API is documented only in prose docs, not as a downloadable machine-readable spec.", "evidenceIds": [ "kitty-probe-1", "kitty-probe-2", "kitty-probe-3" ] }, { "productId": "kitty", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a terminal emulator, not an application/service with production data or a sandbox/test-environment concept; this story's axis (sandbox vs. production data isolation) is a category error for this product type.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Kitty documents a remote-control API and graphics protocol, but there is no evidence of API versioning or a documented deprecation policy for these interfaces; probes for machine-readable API specs (openapi.json, llms.txt) returned 404s. Missing for 10: any versioning scheme, changelog-based deprecation policy, or stability guarantees for the remote-control/graphics protocols.", "evidenceIds": [ "kitty-probe-3", "kitty-probe-1", "kitty-docs-1", "kitty-docs-2" ] }, { "productId": "kitty", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Kitty's remote-control API (`kitty @`) lets scripts list all windows/tabs (`ls`) and act on them (`send-text`, `close-window`, etc.), and the runtime probe confirms this loop works end-to-end, which enables scripting bulk actions across many windows/tabs. However, there's no first-party example or evidence of a built-in bulk/batch command (e.g., 'send to all windows' or looped multi-item operation) — it would require the user to write the looping logic themselves. Missing for 10: documented bulk/batch primitives operating on many items in one call, and independent evidence of someone actually scripting bulk operations at scale.", "evidenceIds": [ "kitty-docs-1", "kitty-docs-23", "kitty-docs-27", "kitty-probe-rt-1" ] }, { "productId": "kitty", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers remote-control scripting, kittens, shell integration, and SSH kitten, but none describe a rule/event-trigger system that automatically fires actions on defined events (e.g., window open, output pattern, OS event) without manual invocation. Missing for 10: any documented 'on-event' hook/watcher/trigger mechanism and evidence of automatic action execution tied to specific events.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "kitty", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Kitty's config (kitty.conf) and remote-control scripts are plain text files that a user could manually version with an external tool like git, but there is no evidence of any built-in versioning, review, or rollback mechanism for automations within kitty itself.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "builtin-ai-agent", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "kitty", "storyId": "cli-remote-control", "verdict": "full", "quality": 10, "confidence": "high", "rationale": "kitty's remote-control system is extensively documented (opening windows, sending text, querying state, changing titles) and independently verified hands-on: a probe launched kitty with remote control enabled, listed windows/state as JSON, sent text, read output back, and closed the window — confirming the full documented CLI/IPC control loop works as claimed.", "evidenceIds": [ "kitty-docs-1", "kitty-docs-23", "kitty-docs-27", "kitty-probe-4", "kitty-probe-rt-1" ] }, { "productId": "kitty", "storyId": "command-aware-features", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "kitty's shell-integration docs confirm prompt-aware features (jumping between prompts, viewing last command's output, cursor movement while editing) but the evidence pack never documents exit-status marking, command duration tracking, or notifications when long commands finish — the specific command-aware signals the story asks about. Missing for 10: exit status display evidence, duration/timing tracking evidence, and completion notification evidence for long-running commands.", "evidenceIds": [ "kitty-docs-3", "kitty-docs-25" ] }, { "productId": "kitty", "storyId": "command-palette-discovery", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Kitty's evidence covers remote control, kittens, shell integration, and hints/selection features, but nothing describes a searchable command palette UI for discovering and running actions—kitty's action system is configured via keybindings in kitty.conf, not an interactive palette.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "config-as-code", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "kitty.conf is a plain-text config file format (kitty-docs-5, kitty-docs-15) that is well-documented and designed to be human-edited and portable, and community users confirm editing/config workflows (kitty-comm-1, kitty-comm-11, kitty-comm-18), consistent with typical dotfiles syncing across machines. missing for 10: no explicit first-party or community mention of dotfiles-repo syncing workflows or 'include' directives for multi-machine config management.", "evidenceIds": [ "kitty-docs-5", "kitty-docs-15", "kitty-comm-1", "kitty-comm-11", "kitty-comm-18" ] }, { "productId": "kitty", "storyId": "cross-platform", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "kitty is a cross-platform terminal emulator with official binary installers for macOS, Linux, and BSD, and documented support for Windows via WSL/other builds, using a single shared kitty.conf config file across platforms; community evidence confirms usage on macOS, Linux, and WSL2 with consistent behavior. missing for 10: no direct evidence of native Windows (non-WSL) support quality or explicit cross-platform config-parity testing, and no independent benchmark of identical config working unmodified across all three OSes.", "evidenceIds": [ "kitty-docs-6", "kitty-docs-16", "kitty-docs-5", "kitty-docs-15", "kitty-comm-1", "kitty-comm-13", "kitty-comm-18" ] }, { "productId": "kitty", "storyId": "extensibility-plugins", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Kitty ships a documented kittens system extensible in Python, plus remote-control scripting APIs (verified hands-on in kitty-probe-rt-1) and config/mapping extensibility, directly matching the story of extending the terminal with real-language scripts/plugins beyond built-ins. Missing for 10: independent third-party evidence of custom kitten development (community citations focus on performance/UX rather than plugin authoring).", "evidenceIds": [ "kitty-docs-8", "kitty-docs-27", "kitty-docs-1", "kitty-docs-23", "kitty-probe-rt-1", "kitty-docs-14" ] }, { "productId": "kitty", "storyId": "fonts-ligatures", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "kitty documents dedicated font configuration (Changing kitty fonts, kitty.conf font options for family/bold/italic/fallback fonts and font_features tuning) and community reports strongly corroborate best-in-class ligature support (e.g., FiraCode ligatures cited as reason to switch from iTerm/Alacritty). Missing for 10: no first-party doc excerpt detailing per-font fallback selection algorithm or advanced font_features syntax beyond title listing, and no independent benchmark of fallback font correctness.", "evidenceIds": [ "kitty-docs-10", "kitty-docs-5", "kitty-comm-3", "kitty-comm-5", "kitty-comm-16" ] }, { "productId": "kitty", "storyId": "gpu-accelerated-rendering", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Kitty's docs claim GPU-accelerated rendering (kitty-docs-24, kitty-docs-27) and many community reports corroborate snappy, low-latency performance even under heavy scrolling (kitty-comm-3, kitty-comm-11, kitty-comm-20), but other hands-on community reports concretely contradict this, citing catting a long file being '100x' slower than a non-GPU terminal, redraw/rendering glitches, GPU driver issues on many Nvidia laptops, and much slower startup vs other terminals (kitty-comm-4, kitty-comm-6, kitty-comm-9, kitty-comm-15). missing for 10: independent benchmark data reconciling these conflicting hands-on reports, official docs addressing known GPU/driver compatibility issues, and evidence of fixes for the reported rendering glitches.", "evidenceIds": [ "kitty-docs-24", "kitty-docs-27", "kitty-comm-3", "kitty-comm-11", "kitty-comm-20", "kitty-comm-4", "kitty-comm-6", "kitty-comm-9", "kitty-comm-15" ] }, { "productId": "kitty", "storyId": "inline-images-graphics", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Kitty documents and ships a dedicated Terminal Graphics Protocol allowing clients to render arbitrary pixel graphics inline, plus the icat kitten for displaying images, corroborated by community praise ('The diff and icat tools are must-haves'). This is a well-documented, first-party protocol spec, not just a claim. Missing for 10: independent hands-on verification specifically of the graphics protocol (probe evidence only covers remote-control, not icat/graphics rendering).", "evidenceIds": [ "kitty-docs-2", "kitty-docs-24", "kitty-docs-11", "kitty-comm-7" ] }, { "productId": "kitty", "storyId": "measured-performance-claims", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Kitty ships no vendor-published benchmark page, but community threads reference hardware-based latency comparisons showing kitty on par with Terminal.app and users corroborating low CPU/high speed while scrolling, giving power-users some measured performance signal outside official docs. This is thin: it's anecdotal community commentary, not a first-party benchmarks page or reproducible published methodology, and other community reports (e.g., slow cat throughput, slow startup) show the perception is inconsistent. missing for 10: an official kitty benchmarks/methodology page, first-party throughput/latency numbers, and independent reproducible benchmark data beyond single forum comments.", "evidenceIds": [ "kitty-comm-20", "kitty-comm-11", "kitty-comm-4", "kitty-comm-15" ] }, { "productId": "kitty", "storyId": "nl-command-generation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a terminal emulator, not a shell or AI assistant; no evidence of natural-language-to-command generation features. This capability belongs to a shell/AI-assistant product category, not a terminal emulator's axis.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "kitty's remote-control API (kitten @) exposes a broad surface — opening windows, sending text, reading text, changing layouts/tabs/titles, closing windows — verified hands-on via a runtime probe showing a full external agent-control loop working. However, this is a CLI/socket protocol rather than a formal documented 1:1 mapping guaranteeing full UI parity (e.g., no OpenAPI spec, and some UI-only interactive features like mouse-driven config or certain kitten interactions aren't confirmed as scriptable). Missing for 10: an explicit enumerated parity list or spec proving every UI action has an API equivalent, and independent third-party confirmation beyond the single runtime probe.", "evidenceIds": [ "kitty-docs-1", "kitty-docs-23", "kitty-docs-27", "kitty-probe-rt-1", "kitty-probe-4" ] }, { "productId": "kitty", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "kitty's configuration lives in plain-text kitty.conf files that users own directly and the project itself is open-source, so there's no vendor lock-in and settings can be copied/ported freely, and remote-control scripting exposes window/session state as JSON. However there's no dedicated 'export my data' feature (e.g., session history, scrollback, or theme export as a documented bulk-export tool) beyond the inherent plain-text config files. missing for 10: explicit documented export/import of scrollback or session data, migration tooling, and independent confirmation that users treat config portability as a full data-export solution.", "evidenceIds": [ "kitty-docs-5", "kitty-docs-15", "kitty-docs-23", "kitty-probe-rt-1" ] }, { "productId": "kitty", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack references kitty's source code repository, license, or open-source status; all citations are docs, community sentiment, or remote-control probes, none addressing openness of the source.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "kitty", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a local terminal emulator that runs entirely on the user's own machine and stores no user data in any cloud service; data residency/region selection is not a meaningful axis for this kind of product.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a local terminal emulator; it does not collect or process user data for AI training in the first place, so an AI-training opt-out control is a category error for this product type.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "kitty is a local terminal emulator with no cloud data storage or user-data retention model; data retention/deletion controls are a category error for this kind of product (there is no 'account' or stored data to delete beyond local config files).", "evidenceIds": [] }, { "productId": "kitty", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No documentation or setting for telemetry collection or an opt-out mechanism appears anywhere in the evidence pack; kitty's docs cover remote control, graphics, shell integration, SSH, and config but never mention data collection or telemetry toggles. A vague community remark about unspecified 'privacy and security' concerns (kitty-comm-14) is not concrete evidence of telemetry, so it cannot establish disputed status either.", "evidenceIds": [ "kitty-comm-14" ] }, { "productId": "kitty", "storyId": "prompt-marks-navigation", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Kitty's official shell integration docs explicitly state it enables jumping to previous prompts in scrollback, viewing last command output, and command-mark-based navigation for zsh/fish/bash. This is a first-party documented core feature directly matching the story. Missing for 10: independent hands-on community confirmation specifically of prompt-jumping/scrollback navigation (community evidence covers other features like speed/ligatures but not this one).", "evidenceIds": [ "kitty-docs-3", "kitty-docs-25" ] }, { "productId": "kitty", "storyId": "quake-dropdown-mode", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "kitty's docs cover window/tab layouts, remote control, and shell integration, but there is no evidence of a global-hotkey/quake-style dropdown summon feature (kitty is a normal windowed terminal, not an OS-level overlay); no docs or community reports mention such a capability, and some OS integration issues are noted (e.g. xterm-kitty TERM problems) but nothing about instant-summon hotkeys.", "evidenceIds": [] }, { "productId": "kitty", "storyId": "scripted-session-layouts", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Kitty's official docs explicitly advertise startup sessions to specify working environments plus programmable tabs/splits/layouts, configurable via kitty.conf and session files, and remote-control scripting lets a single command open/arrange a full workspace. Runtime probe further corroborates the control/scripting loop working hands-on. Missing for 10: no independent community example specifically demonstrating a startup-session file opening a full project workspace in one command.", "evidenceIds": [ "kitty-docs-27", "kitty-docs-7", "kitty-docs-5", "kitty-docs-1", "kitty-probe-rt-1" ] }, { "productId": "kitty", "storyId": "scrollback-search", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Kitty's shell-integration docs mention jumping to previous prompts in the scrollback and viewing the last command's output via a pager (which supports searching), giving partial support for quick scrollback navigation, but there's no explicit documentation of a dedicated 'search scrollback and cycle through matches' feature (e.g., a search kitten or highlighted match navigation) in the evidence pack. Missing for 10: explicit docs on search-in-scrollback UI/keybindings, match highlighting/cycling, and independent user confirmation of this specific workflow.", "evidenceIds": [ "kitty-docs-25" ] }, { "productId": "kitty", "storyId": "session-restore", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Kitty documents 'startup sessions' to specify working environments (windows/tabs/layouts), which can be used to relaunch kitty into a saved arrangement, but the evidence pack gives only a one-line mention with no detail on automatic state capture or crash/restart recovery — sessions appear to be manually authored config files, not an automatic snapshot/restore mechanism. missing for 10: evidence of automatic session save on exit/crash, working-directory persistence specifics, and any hands-on/community confirmation that restore-after-crash actually works.", "evidenceIds": [ "kitty-docs-27" ] }, { "productId": "kitty", "storyId": "splits-tabs-panes", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Kitty natively supports windows, tabs, and multiple layouts with programmable splits, documented in first-party docs and confirmed by community users praising its window organization/auto layout — no external multiplexer needed. missing for 10: independent hands-on comparison specifically benchmarking pane/tab workflows against tmux/screen.", "evidenceIds": [ "kitty-docs-7", "kitty-docs-27", "kitty-comm-11", "kitty-comm-18" ] }, { "productId": "kitty", "storyId": "ssh-integration", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "The ssh kitten is explicitly documented to automatically set up shell integration, forward terminfo, transfer config, and reuse connections when SSHing to remote hosts, directly matching the story. Community reports mostly note a related manual workaround (TERM=xterm-kitty issues) rather than contradicting the kitten's own automatic integration feature. missing for 10: independent hands-on verification specifically of the ssh kitten (not just remote-control) and broader real-world confirmation across shells/OSes.", "evidenceIds": [ "kitty-docs-4", "kitty-docs-26", "kitty-docs-3", "kitty-comm-10", "kitty-comm-18", "kitty-comm-19" ] }, { "productId": "kitty", "storyId": "theming-color-schemes", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs explicitly cover changing kitty colors/themes (kitty-docs-9) and automatic OS light/dark theme switching (kitty-docs-21), plus general kitty.conf theming support (kitty-docs-5, 15, 18). Missing for 10: independent hands-on corroboration of the auto light/dark switching feature specifically, and details on theme ecosystem/community theme packs.", "evidenceIds": [ "kitty-docs-9", "kitty-docs-21", "kitty-docs-5", "kitty-docs-18" ] }, { "productId": "kitty", "storyId": "tmux-compat", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Kitty doesn't ship a native tmux-like multiplexer/control-mode substitute for tmux itself, but it supports running tmux inside it (community confirms zsh/tmux setups work with tweaks) and offers its own overlapping native features (windows/tabs/layouts, remote control, sessions) as an alternative to tmux, plus SSH kitten integration for remote sessions. missing for 10: documented native tmux control-mode protocol/compatibility layer, first-party guidance on using tmux inside kitty, and confirmation that kitty's own multiplexing fully replaces tmux workflows for SSH users.", "evidenceIds": [ "kitty-docs-7", "kitty-docs-27", "kitty-docs-4", "kitty-docs-26", "kitty-comm-1", "kitty-comm-10" ] }, { "productId": "kitty", "storyId": "url-path-click", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "kitty ships a dedicated 'Hints' kitten (kitty-docs-17) that is documented to let users select URLs/paths/etc. from terminal output via keyboard, and kitty's kittens system (kitty-docs-8) enables extensibility like this, supporting the story's core capability. However, the evidence pack only lists a title reference with no detail on mouse-click behavior, configuration, or independent confirmation from users. Missing for 10: detailed docs excerpt on hints/URL-click behavior, mouse-click-to-open-url specifics, and community/hands-on corroboration of this exact feature.", "evidenceIds": [ "kitty-docs-17", "kitty-docs-8" ] }, { "productId": "warp", "storyId": "agent-drives-terminal", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Warp exposes a genuine programmatic surface — an OpenAPI spec (confirmed live at docs.warp.dev/openapi.json), an Oz CLI with API keys for headless/CI control, MCP as a plugin interface, and a documented Warp Agent CLI that spins up its own PTY so an agent can run commands, provide input, and control full-screen apps (warp-docs-69, warp-docs-24, warp-docs-32). This supports agent-driven terminal automation, but the evidence never documents a protocol/API specifically for creating or managing Warp's terminal panes/windows or reading raw pane output — the API/CLI focus is on running and orchestrating agents rather than exposing the terminal UI itself as a controllable surface. Missing for 10: documented pane-creation/window-management API, explicit read-output API distinct from agent conversation transcripts, and independent/hands-on confirmation of external programmatic terminal control.", "evidenceIds": [ "warp-docs-42", "warp-docs-63", "warp-docs-52", "warp-docs-69", "warp-docs-24", "warp-probe-2", "warp-docs-37" ] }, { "productId": "warp", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Warp publishes a dedicated llms.txt (confirmed live via HTTP 200 probe at docs.warp.dev/llms.txt) describing its agentic docs, plus a whole family of agent-oriented doc pages under the _llms-txt/ path (code, warp-agent-cli, automation-platform, api-reference, knowledge-and-collaboration, factories), giving AI agents a structured, machine-readable entry point into Warp's documentation. Missing for 10: no independent/community confirmation that an external agent has actually consumed this llms.txt successfully.", "evidenceIds": [ "warp-probe-1", "warp-docs-57", "warp-docs-59", "warp-docs-60", "warp-docs-61", "warp-docs-63", "warp-docs-66", "warp-docs-68" ] }, { "productId": "warp", "storyId": "agentic-ai-insights", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Warp provides extensive AI-generated insights and suggestions inline: AI command suggestions via '#', error explanation via 'Ask Warp AI', agent-driven code writing/debugging/multi-step task execution, and context-aware suggestions pulled via MCP integrations from databases/APIs/docs. This is well documented across multiple first-party sources. missing for 10: independent/hands-on corroboration specifically validating the quality or accuracy of the AI insights/suggestions (community evidence focuses on terminal stability/privacy issues, not on insight quality).", "evidenceIds": [ "warp-docs-6", "warp-docs-7", "warp-docs-8", "warp-docs-9", "warp-docs-44", "warp-docs-54", "warp-docs-29" ] }, { "productId": "warp", "storyId": "agentic-autonomous-automation", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Warp's Automation Platform explicitly supports cloud agents that run autonomously in the background, triggered by schedules, webhooks, or integrations like Slack/GitHub/Linear (warp-docs-4, warp-docs-5, warp-docs-60), with observability/audit trails (warp-docs-53, warp-docs-61) and CLI/API control via Oz CLI for headless/CI use (warp-docs-22, warp-docs-37, warp-docs-63). missing for 10: independent/hands-on verification of autonomous background runs actually completing unattended, and more detail on failure handling/reliability at scale.", "evidenceIds": [ "warp-docs-4", "warp-docs-5", "warp-docs-60", "warp-docs-61", "warp-docs-53", "warp-docs-22", "warp-docs-37", "warp-docs-63", "warp-docs-52" ] }, { "productId": "warp", "storyId": "agentic-builtin-assistant", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Warp ships a built-in AI agent that writes code, runs commands, iterates on tasks, handles multi-turn conversations, supports model switching, and integrates with natural-language command generation—well documented across first-party docs (warp-docs-6, warp-docs-8, warp-docs-44, warp-docs-13, warp-docs-14). This is corroborated by community mentions of AI-generated commands being a standout feature (warp-comm-8). Missing for 10: independent hands-on validation specifically of the built-in agent's task completion quality (most community commentary focuses on terminal UX/telemetry rather than the assistant's task delegation itself).", "evidenceIds": [ "warp-docs-6", "warp-docs-8", "warp-docs-44", "warp-docs-13", "warp-docs-14", "warp-docs-10", "warp-comm-8" ] }, { "productId": "warp", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Warp ships the Oz CLI explicitly documented for running/managing cloud agents 'from any terminal, script, or CI pipeline,' with API keys for headless/non-interactive auth 'ideal for CI pipelines, headless servers, and containers,' plus the standalone Warp Agent CLI that works over SSH/any terminal without the desktop app. Schedules and webhook/event triggers further support automation use cases outside interactive sessions. Missing for 10: independent/hands-on verification of actual CI pipeline runs and more detail on exit codes/output parsing for scripting.", "evidenceIds": [ "warp-docs-22", "warp-docs-37", "warp-docs-52", "warp-docs-63", "warp-docs-59", "warp-docs-23", "warp-docs-4", "warp-docs-5", "warp-docs-60" ] }, { "productId": "warp", "storyId": "agentic-mcp-client", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Warp has documented, first-party support for connecting MCP servers to extend its agents ('MCP servers extend Warp's local agents... acting as plugins for Warp'), plus explicit CLI support (Oz CLI) to 'connect MCP servers like GitHub and Linear' and agent profiles to control MCP server usage. This is corroborated across multiple doc pages describing MCP as a first-class integration point for tool use. Missing for 10: independent/hands-on community confirmation of MCP server usage specifically (community evidence covers other topics, not MCP directly).", "evidenceIds": [ "warp-docs-7", "warp-docs-18", "warp-docs-37", "warp-docs-52", "warp-docs-64" ] }, { "productId": "warp", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Warp is itself an agentic coding/terminal product (agent role); all MCP-related evidence (warp-docs-7, warp-docs-18, warp-docs-37, warp-docs-52) describes Warp's agents *connecting to* external MCP servers as a client, not Warp exposing an official MCP server for other agents to connect to. Per the client-vs-server distinction, this makes the 'connect an agent via an official MCP server' (server role) axis inapplicable to Warp.", "evidenceIds": [ "warp-docs-7", "warp-docs-18", "warp-docs-37", "warp-docs-52" ] }, { "productId": "warp", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Warp offers extensive natural-language interfaces: typing '#' for AI command suggestions, Agent Mode conversations for multi-step tasks, right-click 'Ask Warp AI' to explain errors, and a built-in agent that writes code, runs commands, and iterates based on natural-language descriptions. This spans terminal, CLI, and cloud agent surfaces (warp-docs-6,8,9,44,54). missing for 10: independent hands-on validation specifically of NL command accuracy/reliability (community evidence focuses on general product issues rather than NL-command quality).", "evidenceIds": [ "warp-docs-6", "warp-docs-8", "warp-docs-9", "warp-docs-44", "warp-docs-54", "warp-docs-26", "warp-docs-13" ] }, { "productId": "warp", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Warp ships multiple official CLIs — the standalone Warp Agent CLI usable in any terminal/SSH (warp-docs-23, warp-docs-41, warp-docs-59, warp-docs-69) and the Oz CLI for managing cloud agents in scripts/CI (warp-docs-22, warp-docs-37, warp-docs-52) — both extensively documented as first-party, agent-native tooling with API key auth for headless use (warp-docs-63). Missing for 10: independent/hands-on community corroboration specifically validating the CLI's real-world reliability (community evidence covers the desktop app, not the CLI).", "evidenceIds": [ "warp-docs-22", "warp-docs-23", "warp-docs-37", "warp-docs-41", "warp-docs-52", "warp-docs-59", "warp-docs-63", "warp-docs-69" ] }, { "productId": "warp", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Warp explicitly advertises an 'API, CLI, SDK and MCP' platform (warp-docs-42), and a live probe confirms a real OpenAPI spec is served at docs.warp.dev/openapi.json (warp-probe-2), backed by a documented CLI reference (warp-probe-3) and API-key based headless auth for the Oz CLI (warp-docs-63) plus scriptable agent control (warp-docs-22, warp-docs-37, warp-docs-52). Missing for 10: independent/third-party corroboration of API usage and more detailed public API reference content beyond the openapi.json existence check.", "evidenceIds": [ "warp-docs-42", "warp-probe-2", "warp-probe-3", "warp-docs-63", "warp-docs-22", "warp-docs-37", "warp-docs-52" ] }, { "productId": "warp", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Warp's docs describe API Keys for authenticating the Oz CLI headlessly (warp-docs-63) and Agent Profiles that constrain what an agent can access (file access, command execution, MCP server usage) plus admin-level controls over agent autonomy (warp-docs-64, warp-docs-66), which together approximate least-privilege scoping for agent credentials/access. However, there's no explicit documentation of per-credential scopes/permissions tied to individual API keys (e.g., read-only vs write, resource-level restrictions) or independent confirmation this works as a formal least-privilege credential system. Missing for 10: explicit scoped-permission API key documentation, examples of granular credential scoping, and independent/hands-on verification.", "evidenceIds": [ "warp-docs-63", "warp-docs-64", "warp-docs-66" ] }, { "productId": "warp", "storyId": "agentic-sdks", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Warp markets itself as 'API, CLI, SDK and MCP built as a platform' (warp-docs-42) and a live OpenAPI spec is confirmed (warp-probe-2), showing some real API surface, but there is no dedicated SDK documentation, language-specific client libraries, install instructions, or code samples anywhere in the evidence. missing for 10: dedicated SDK docs/reference, language bindings (e.g. Python/JS packages), code samples, versioning/changelog for an SDK.", "evidenceIds": [ "warp-docs-42", "warp-probe-2", "warp-probe-1" ] }, { "productId": "warp", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Warp's automation platform docs mention 'Triggers: React to events from Slack, Linear, GitHub, or custom webhooks' and cloud agents 'triggered by... integrations like Slack and GitHub,' indicating webhook-based triggering exists, but this describes Warp consuming/reacting to inbound webhooks to kick off agents rather than a documented outbound webhook subscription mechanism for external systems to receive Warp's own events. Missing for 10: explicit documentation of an outbound webhook/event-subscription API, payload schema, or delivery guarantees, and independent confirmation of this feature working.", "evidenceIds": [ "warp-docs-4", "warp-docs-60" ] }, { "productId": "warp", "storyId": "ai-error-explanation", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Warp explicitly documents right-clicking to 'Ask Warp AI' to explain error output and identify missing dependencies, plus '#' natural-language command suggestions and AI-driven debugging as core Agent capabilities. Missing for 10: independent/hands-on verification that error explanations are accurate or reliably surfaced (community evidence focuses on other issues, not this feature specifically).", "evidenceIds": [ "warp-docs-9", "warp-docs-29", "warp-docs-44", "warp-docs-8" ] }, { "productId": "warp", "storyId": "ai-privacy-controls", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Warp docs promise granular control (secret redaction, no training use, telemetry opt-out on paid plans, ZDR for Business/Enterprise) and note telemetry can be monitored/disabled, but this is undercut by concrete community reports: one HN thread describes Warp silently sending terminal session data to LLMs via 'Prompt Suggestions'/'Next Command' without explicit consent (warp-comm-1), and multiple independent users report being confronted with a mandatory login prompt and uninstalling immediately (warp-comm-5, warp-comm-6, warp-comm-16), even though a Warp co-founder claims the login requirement was removed (warp-comm-7). Docs also admit telemetry must stay on to use AI on the Free plan (warp-docs-33), meaning full AI use without any data leaving isn't unconditional. missing for 10: a documented explicit toggle to fully disable AI without any account/login step on the free tier, and resolution of the community claim of undisclosed data transmission.", "evidenceIds": [ "warp-docs-12", "warp-docs-17", "warp-docs-33", "warp-docs-34", "warp-docs-46", "warp-docs-56", "warp-comm-1", "warp-comm-5", "warp-comm-6", "warp-comm-7", "warp-comm-16" ] }, { "productId": "warp", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Warp does expose an OpenAPI spec (warp-probe-2) and API/CLI reference docs (warp-docs-63, warp-probe-3), so the axis of an API reference applies given Warp's platform ambitions (warp-docs-42). However, there is no evidence of an interactive reference UI with runnable/'try it out' examples — the pack only shows a raw openapi.json file and static CLI reference pages, not an interactive explorer.", "evidenceIds": [ "warp-probe-2", "warp-probe-3", "warp-docs-63", "warp-docs-42" ] }, { "productId": "warp", "storyId": "api-machine-spec", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "A probe directly confirms an OpenAPI JSON spec is served at docs.warp.dev/openapi.json returning a valid 'openapi' key, and docs reference an API/CLI/SDK/MCP platform with API key management, corroborating a machine-readable spec exists. Missing for 10: no independent/third-party confirmation of spec completeness or versioning, and no docs page walking through consuming the spec.", "evidenceIds": [ "warp-probe-2", "warp-docs-42", "warp-docs-63" ] }, { "productId": "warp", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Warp's agent platform includes cloud agents, agent profiles restricting file/command access, and CI-oriented API keys, none of the evidence describes a dedicated sandbox environment or test-data isolation mechanism that lets a user validate agent runs without touching production data.", "evidenceIds": [] }, { "productId": "warp", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Warp exposes an API, CLI, SDK, and MCP platform (warp-docs-42, warp-probe-2 openapi.json), so API versioning is a fair axis, but no evidence pack item documents API version numbers, a changelog, or any formal deprecation policy for these interfaces.", "evidenceIds": [ "warp-docs-42", "warp-probe-2", "warp-probe-3" ] }, { "productId": "warp", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Warp supports running many agents concurrently across repos/tasks (warp-docs-28), cloud agents triggered by schedules/webhooks at scale (warp-docs-4, warp-docs-5, warp-docs-60), and a 'software factory' pattern coordinating a fleet of agents into mergeable PRs (warp-docs-68), which together support bulk/parallel operations across many items. However, there is no explicit documentation of a UI or command for batch-selecting many items (files, repos, tasks) and applying one operation across all of them in a single bulk action, nor independent/hands-on evidence confirming this scales well in practice. missing for 10: concrete bulk-selection/batch-apply UI or command, first-party docs quantifying scale limits, independent verification that parallel/bulk agent runs work reliably at scale.", "evidenceIds": [ "warp-docs-28", "warp-docs-60", "warp-docs-68", "warp-docs-4", "warp-docs-5", "warp-docs-22" ] }, { "productId": "warp", "storyId": "automation-rules-engine", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Warp's Automation Platform explicitly supports Triggers reacting to events from Slack, Linear, GitHub, or custom webhooks, plus Schedules for recurring tasks, and cloud agents described as 'triggered by system events, schedules, or integrations like Slack and GitHub' with full observability/audit trails. This directly matches the story of defining rules that trigger automatic actions on events. Missing for 10: independent/hands-on verification of the trigger system in practice (community evidence focuses on core terminal/agent issues, not the automation/trigger feature specifically).", "evidenceIds": [ "warp-docs-4", "warp-docs-5", "warp-docs-60", "warp-docs-61", "warp-docs-53" ] }, { "productId": "warp", "storyId": "automation-scheduled-jobs", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Warp documents explicit 'Schedules' functionality for cloud agents ('Run recurring tasks like dependency updates or dead code removal') alongside 'Triggers' for event-based automation, plus cloud agents described as 'triggered by system events, schedules, or integrations' and managed via the Oz CLI for scripting/CI. This directly matches the story of scheduling recurring jobs/workflows. Missing for 10: independent/hands-on confirmation of the scheduling feature working reliably, and more detail on scheduling configuration (cron-like syntax, frequency options).", "evidenceIds": [ "warp-docs-4", "warp-docs-5", "warp-docs-60", "warp-docs-22", "warp-docs-52" ] }, { "productId": "warp", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Warp provides strong review/observability for automations (run transcripts showing prompt, plan, commands, logs, shareable for team review) and lets you save/share workflows via Warp Drive, but there is no documented versioning or rollback mechanism for automations (e.g., no version history, diffing, or revert capability for schedules/triggers/workflows). missing for 10: explicit version history for saved automations, ability to roll back to a prior automation version, changelog/diff view for automation edits.", "evidenceIds": [ "warp-docs-11", "warp-docs-53", "warp-docs-61", "warp-docs-30", "warp-docs-60" ] }, { "productId": "warp", "storyId": "builtin-ai-agent", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Warp's built-in Agent Mode is extensively documented to plan and execute multi-step terminal tasks (writing code, running commands, controlling interactive/full-screen apps, iterating) while keeping the user in the loop via conversation view, follow-ups, and approval/steering ('watch, steer, and hand off runs'). This is corroborated across many first-party docs and independent community mentions of using it as a daily driver for AI-assisted terminal work, though some hands-on complaints exist about unrelated reliability/telemetry issues rather than the core delegate-and-approve workflow itself. Missing for 10: independent hands-on verification specifically of the approval/plan-then-execute step (vs. general agent usage), and confirmation the community complaints don't touch this exact workflow.", "evidenceIds": [ "warp-docs-6", "warp-docs-44", "warp-docs-16", "warp-docs-13", "warp-docs-14", "warp-docs-43", "warp-comm-8", "warp-comm-9" ] }, { "productId": "warp", "storyId": "cli-remote-control", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Warp ships documented CLI/IPC surfaces — the standalone Warp Agent CLI (works in any terminal, over SSH, creates its own PTY, can run/control full-screen apps) and the Oz CLI for running/managing cloud agents from scripts or CI with API-key auth — giving real command-line scriptability of agent sessions. However, the evidence is agent-centric (starting conversations, running commands, controlling processes) rather than direct terminal-window primitives like opening/arranging windows or querying pane/window state as the story literally describes (tmux/iTerm2-style control). Missing for 10: explicit documented commands to open/manage Warp windows or panes, send raw text to a specific pane, or query terminal UI state independent of an agent session; independent hands-on confirmation of such scripting.", "evidenceIds": [ "warp-docs-22", "warp-docs-37", "warp-docs-52", "warp-docs-63", "warp-docs-59", "warp-docs-69", "warp-docs-23", "warp-docs-41" ] }, { "productId": "warp", "storyId": "command-aware-features", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Only evidence is a community anecdote naming notifications on long-running command completion as a favorite feature; there is no first-party documentation confirming exit status display, command duration tracking, or notification configuration as shell-integration features (the docs pack is dominated by AI/agent capabilities instead). missing for 10: official docs on exit status indicators, duration display, and notification settings; independent corroboration beyond a single forum comment.", "evidenceIds": [ "warp-comm-9" ] }, { "productId": "warp", "storyId": "command-palette-discovery", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Warp Drive lets users save workflows and run them 'on-demand' (warp-docs-11, warp-docs-30), and AI Command Suggestions via '#' provide natural-language command discovery (warp-docs-8), which together approximate a command-palette-style workflow, but no evidence explicitly describes a searchable palette UI for discovering and running arbitrary terminal actions. Missing for 10: explicit documentation of a dedicated command palette (e.g., Cmd+P style fuzzy search across commands/workflows), independent/community confirmation of this specific feature, and clarity on scope (built-in commands vs only saved workflows).", "evidenceIds": [ "warp-docs-11", "warp-docs-30", "warp-docs-8" ] }, { "productId": "warp", "storyId": "config-as-code", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Warp's open-source announcement mentions shipping a new settings file explicitly for 'programmatic control over settings and easy portability between devices' (warp-docs-40), which speaks directly to the dotfiles/sync use case, but this is a single passing mention with no documentation of its format, scope, or actual dotfiles-style workflow. Other config-adjacent features (theme OS-sync, session restoration) are separate app-state features, not plain-text portable config. Missing for 10: dedicated docs on the settings file format/location, confirmation it covers full app config (keybindings, workflows, themes), and independent/community corroboration of dotfiles-style syncing across machines.", "evidenceIds": [ "warp-docs-40", "warp-docs-20", "warp-docs-21" ] }, { "productId": "warp", "storyId": "cross-platform", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Evidence shows Warp exposes platform-specific keybindings for macOS, Windows, and Linux (docs-49), a settings file enabling config portability across devices (docs-40), and CLI/agent components that work over SSH in any terminal (docs-59), implying cross-platform availability. However, there is no explicit doc confirming identical native app experience on all three OSes, and community reports describe Warp being broken specifically under WSL/Windows-via-SSH scenarios (warp-comm-10), undercutting a seamless 'same terminal, same config' experience. missing for 10: explicit first-party confirmation of feature parity across macOS/Linux/Windows, documented config-sync mechanism beyond a settings file, and independent corroboration that the same setup truly works identically on all three platforms.", "evidenceIds": [ "warp-docs-49", "warp-docs-40", "warp-docs-59", "warp-comm-10" ] }, { "productId": "warp", "storyId": "extensibility-plugins", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Warp's extensibility is centered on MCP servers (for extending AI agent tool access) and a settings file, not a general-purpose scripting/plugin language like Lua or Python for customizing terminal behavior (e.g., kitty-style 'kittens'). No evidence pack item documents a scripting API, plugin SDK, or embedded language runtime for extending the terminal itself.", "evidenceIds": [ "warp-docs-18", "warp-docs-40" ] }, { "productId": "warp", "storyId": "fonts-ligatures", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack mentions font configuration, ligatures, fallback fonts, or font tuning of any kind; documentation focuses on themes, appearance sync, and agent features, not typography settings.", "evidenceIds": [] }, { "productId": "warp", "storyId": "gpu-accelerated-rendering", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no first-party documentation claiming GPU-accelerated rendering or describing rendering performance under heavy output; instead, community reports describe UI glitches, broken behavior, and instability during heavy use (e.g., 'horribly broken... UI glitches', 'random failures, stopping of agents'), and one commenter notes the terminal is 'just Alacritty' with no Warp-specific performance claims. Since no vendor documentation asserts this capability, there's nothing concrete to substantiate 'full' or 'partial', and the negative community signals reinforce a 'none' verdict rather than a dispute of an explicit claim.", "evidenceIds": [ "warp-comm-10", "warp-comm-11", "warp-comm-12", "warp-comm-15" ] }, { "productId": "warp", "storyId": "inline-images-graphics", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions a terminal graphics protocol (e.g., Sixel, Kitty graphics protocol, iTerm2 inline images) or inline image/rich graphics rendering in Warp's terminal. Evidence only covers AI agents, MCP, telemetry, themes, and session restoration.", "evidenceIds": [] }, { "productId": "warp", "storyId": "measured-performance-claims", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No published benchmarks, latency, or throughput figures appear anywhere in the evidence pack; documentation focuses on features and privacy, while community posts mention performance complaints but no measured numbers. missing for 10: published benchmark data, latency/throughput measurements, any comparative performance testing.", "evidenceIds": [] }, { "productId": "warp", "storyId": "nl-command-generation", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Warp explicitly documents typing '#' plus natural language to get AI Command Suggestions generated in place in the command line (warp-docs-8, warp-docs-54), with real-time suggestion loading and even contextual suggestions inside interactive CLI tools. This is corroborated by multiple docs pages describing the same 'Generate' feature. Missing for 10: no independent/hands-on community confirmation specifically of this in-place suggestion feature (community evidence focuses on other AI/terminal issues, not this specific flow).", "evidenceIds": [ "warp-docs-8", "warp-docs-54", "warp-docs-29" ] }, { "productId": "warp", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Warp explicitly positions itself as 'API, CLI, SDK and MCP built as a platform,' with the Oz CLI enabling agent creation, monitoring, MCP connections, and authentication without the desktop app, and a live OpenAPI spec — showing substantial API/CLI parity for agent workflows. But the story demands full UI-equivalent capability, and evidence doesn't confirm parity for many UI-only features (theming, session restoration, conversation UI, code editor) nor is there independent verification that the API surface is fully complete. missing for 10: independent confirmation of full feature parity, evidence that UI-specific features (themes, editor, session restore) are also API-accessible", "evidenceIds": [ "warp-docs-42", "warp-docs-43", "warp-docs-22", "warp-docs-37", "warp-docs-52", "warp-docs-63", "warp-docs-64", "warp-probe-2", "warp-probe-3" ] }, { "productId": "warp", "storyId": "openness-full-export", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Warp documents a settings file for 'programmatic control over settings and easy portability between devices' and open-sources its client code, but there's no documented feature for exporting conversation history, Warp Drive workflows, or agent run data in open formats for full user data portability. missing for 10: explicit full data export tooling, open-format export of conversation/session history, Warp Drive workflow export, independent confirmation users can fully migrate away with their data.", "evidenceIds": [ "warp-docs-40", "warp-docs-25", "warp-docs-38" ] }, { "productId": "warp", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Warp explicitly published its client source code on GitHub under the AGPL v3 open-source license, documented in both its privacy docs and a dedicated blog post announcing the move to open source. missing for 10: independent/third-party confirmation of the full scope of open-sourced code (e.g., whether cloud/server-side agent components are also included) and any hands-on community audit of the repository beyond the vendor's own announcement.", "evidenceIds": [ "warp-docs-25", "warp-docs-38", "warp-docs-47" ] }, { "productId": "warp", "storyId": "openness-self-host", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Warp's client is open-sourced under AGPL v3 (warpdotdev/warp) so the terminal client itself can be inspected and self-hosted/built from source, and cloud agents are described as able to run 'on Warp's cloud infrastructure or your own,' suggesting some self-hosting of agent execution. However, there's no documented path to self-host the full core product—AI model routing, backend services, and account/login (required per warp-comm-6/7) remain tied to Warp's proprietary cloud, and no deployment/on-prem guide is evidenced. Missing for 10: a documented self-hosted backend/server deployment, evidence that AI/model-routing works without Warp's cloud, and independent confirmation of a working self-hosted setup.", "evidenceIds": [ "warp-docs-25", "warp-docs-38", "warp-docs-60", "warp-comm-7" ] }, { "productId": "warp", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence covers data retention (no training, ZDR for Business/Enterprise), telemetry opt-out, and secret redaction, but nowhere mentions data residency or region selection for storage of user/agent data. Missing for 10: any mention of regional data storage options, EU/US data residency choices, or infrastructure location controls.", "evidenceIds": [] }, { "productId": "warp", "storyId": "privacy-no-training", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Warp explicitly states it prohibits OpenAI/Anthropic from using terminal data to train models, and paid plans get a Zero Data Retention agreement plus telemetry opt-out; these are strong first-party privacy commitments (warp-docs-12, warp-docs-34, warp-docs-17/51). However, Free-plan users must keep telemetry enabled to use AI features (warp-docs-33), and community reports allege some AI-adjacent features silently send terminal data to LLMs without explicit consent (warp-comm-1), showing the anti-training guarantee isn't paired with full data-flow transparency for all users. Missing for 10: independent verification of the no-training claim, clarity on Free-tier data handling, and resolution of the consent complaint.", "evidenceIds": [ "warp-docs-12", "warp-docs-34", "warp-docs-17", "warp-docs-33", "warp-docs-51", "warp-comm-1" ] }, { "productId": "warp", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Warp documents concrete retention/deletion controls: no OpenAI/Anthropic model training on user data, ZDR agreements for Business/Enterprise (no AI or console data collected), ability to clear/delete sensitive Blocks from a machine, secret redaction on all AI interactions, and telemetry opt-out for paid plans, plus open-source client code for audit (warp-docs-12, warp-docs-34, warp-docs-36, warp-docs-56, warp-docs-17/46/51, warp-docs-25/47). However, ZDR is limited to Business/Enterprise tiers, Free-plan users must keep telemetry on to use AI features (warp-docs-33), and community reports allege terminal/session data being sent to LLMs without explicit consent on lower tiers (warp-comm-1, warp-comm-16), undercutting full user control for non-enterprise users. missing for 10: universal (non-enterprise) ZDR/opt-out guarantees, independent verification that free/pro-tier data isn't retained, and resolution of the community consent complaints.", "evidenceIds": [ "warp-docs-12", "warp-docs-34", "warp-docs-36", "warp-docs-56", "warp-docs-17", "warp-docs-33", "warp-docs-25", "warp-comm-1", "warp-comm-16" ] }, { "productId": "warp", "storyId": "privacy-telemetry-optout", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Warp's docs explicitly describe a telemetry opt-out and a Network Log to monitor telemetry in real time, and state paid plans can opt out at any time while still using AI. However, the Free plan requires telemetry to be enabled to use AI features, meaning opt-out isn't universal, and community commentary (warp-comm-1, warp-comm-16) raises concerns about undisclosed data sharing and 'heaps of telemetry,' which tempers full confidence though it doesn't concretely disprove the opt-out mechanism itself. missing for 10: independent verification that opt-out fully works with no residual telemetry, and free-tier parity for full opt-out.", "evidenceIds": [ "warp-docs-17", "warp-docs-33", "warp-docs-46", "warp-docs-51", "warp-docs-55", "warp-comm-16" ] }, { "productId": "warp", "storyId": "prompt-marks-navigation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack references Warp's 'Blocks' concept (grouping commands and output) and session restoration of blocks, but never documents a shell-integration feature for jumping/navigating between prompt marks or command blocks in scrollback via keyboard shortcuts. Missing for 10: explicit documentation of prompt/command mark navigation shortcuts, scrollback jump-to-previous/next-prompt functionality, and any shell-integration-specific navigation UI.", "evidenceIds": [ "warp-docs-21", "warp-docs-35", "warp-docs-36" ] }, { "productId": "warp", "storyId": "quake-dropdown-mode", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack mentions a global hotkey or quake-style dropdown/instant-summon window feature; Warp's docs focus on session restoration, panes/tabs, and AI agent features, not a system-wide invocation shortcut.", "evidenceIds": [] }, { "productId": "warp", "storyId": "scripted-session-layouts", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Warp documents automatic session restoration (windows/tabs/panes reopened on relaunch) but this is a global auto-restore behavior, not a user-authored config/script that defines named per-project startup layouts launchable via one command. No evidence of a project-workspace/layout definition file or CLI flag to open a specific named session.", "evidenceIds": [ "warp-docs-21", "warp-docs-35" ] }, { "productId": "warp", "storyId": "scrollback-search", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Warp's AI/agent features, session restoration, theming, and telemetry, but contains no mention of scrollback search or match navigation functionality, despite this being a reasonable and expected axis for any terminal emulator.", "evidenceIds": [] }, { "productId": "warp", "storyId": "session-restore", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Warp's docs explicitly describe session restoration that restores windows, tabs, panes, and recent Blocks automatically on relaunch, directly matching the story. Missing for 10: independent/hands-on corroboration of restore reliability after crashes (only vendor docs cited), and no detail on working-directory restoration specifics.", "evidenceIds": [ "warp-docs-21", "warp-docs-35", "warp-docs-36" ] }, { "productId": "warp", "storyId": "splits-tabs-panes", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm panes exist alongside tabs and windows as first-class session units (agent conversations run in \"windows, tabs, or panes\" and session restoration recreates \"windows, tabs, and panes\"), showing built-in multiplexing without needing tmux. However the pack lacks any detail on pane-splitting mechanics, keyboard shortcuts, or layout management, and no independent/hands-on account discusses pane usage specifically. Missing for 10: dedicated documentation on split/pane creation and navigation, independent user confirmation of pane workflow.", "evidenceIds": [ "warp-docs-14", "warp-docs-21", "warp-docs-58" ] }, { "productId": "warp", "storyId": "ssh-integration", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Warp's docs mention running the `warp` agent CLI over SSH (warp-docs-3) but that's about launching an agent conversation, not the terminal itself carrying terminfo, shell integration, and config when SSHing into remote hosts. No evidence describes Warp's terminal propagating its shell integration/terminfo to remote hosts, and community reports (warp-comm-10, warp-comm-14) note broken functionality (file/diff explorer, code indexing) specifically over SSH connections, further indicating the core integration doesn't extend cleanly to remote sessions.", "evidenceIds": [ "warp-docs-3", "warp-comm-10", "warp-comm-14" ] }, { "productId": "warp", "storyId": "theming-color-schemes", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Warp's docs explicitly support custom themes, auto-generating themes from a background image, and syncing theme with OS light/dark mode (warp-docs-19, warp-docs-20), directly matching the story. Missing for 10: independent/community corroboration of theming reliability and more detail on breadth of built-in theme palette.", "evidenceIds": [ "warp-docs-19", "warp-docs-20" ] }, { "productId": "warp", "storyId": "tmux-compat", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of tmux support, tmux control mode, or any documented native tmux integration in Warp's docs or community discussion — Warp's session/pane features (blocks, session restoration) are its own proprietary system, not tmux. Since terminal emulators are a fair category for this axis, absence of evidence yields 'none'.", "evidenceIds": [] }, { "productId": "warp", "storyId": "url-path-click", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation or community mention of clickable URLs/file paths, keyboard-selectable links, or similar output-navigation features in Warp's terminal Blocks. This is a fair ergonomics question for a terminal product but nothing in the pack confirms it ships.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "agent-drives-terminal", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "WezTerm documents a CLI subcommand (wezterm cli) that can spawn programs, manipulate tabs/panes, and read pane text (get-text), and a runtime probe confirms an agent-driven headless workflow: spawning panes, sending text/commands, and reading output via a mux server with no GUI required. This is a documented, hands-on-verified programmatic control protocol suitable for an AI agent to drive the terminal. Missing for 10: no formal OpenAPI/RPC schema (llms.txt and openapi probes 404) and no first-party example of an AI agent integration specifically.", "evidenceIds": [ "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-4", "wezterm-probe-rt-1", "wezterm-comm-1" ] }, { "productId": "wezterm", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator with no llms.txt or agent-oriented documentation endpoint; probes explicitly confirm 404s for llms.txt and markdown doc variants, and there is no mention of agent-facing docs anywhere in the docs or community evidence.", "evidenceIds": [ "wezterm-probe-1", "wezterm-probe-2" ] }, { "productId": "wezterm", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator; it has no data-analysis or AI-generated insights/suggestions feature, and this is not a capability terminal emulators are expected to offer — it's a category mismatch rather than an unfulfilled promise.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "WezTerm provides CLI/mux scripting and headless control (spawn, send-text, get-text) that could be used as building blocks, but there is no evidence of a scheduler, trigger system, or persistent background automation framework that runs autonomously without an external orchestrator invoking it. missing for 10: any documented scheduling/trigger mechanism, autonomous background job execution, or agent-loop capability distinct from manual/CLI-invoked scripting.", "evidenceIds": [ "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-rt-1", "wezterm-probe-4" ] }, { "productId": "wezterm", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator; it has no built-in AI assistant feature — this axis is a category error for a terminal product, not an absence of an applicable feature.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "The CLI subcommand explicitly documents spawning/manipulating panes on a running instance, and a hands-on runtime probe confirms a fully headless control loop (mux-server --daemonize, cli spawn, send-text, get-text, list) with no GUI session required — directly matching the CI/automation story. Missing for 10: explicit first-party CI documentation/examples and independent community reports of using WezTerm in CI pipelines.", "evidenceIds": [ "wezterm-probe-rt-1", "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-4" ] }, { "productId": "wezterm", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "This product is not itself an agent, so publishing an official MCP server is plausible and the axis applies; no first-party MCP server appears in the evidence. (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator; natural-language command operation is not an axis this product category addresses. Evidence shows a CLI/Lua config and scripting, but no natural-language interface of any kind — this is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "WezTerm ships an official `wezterm cli` subcommand documented for spawning programs, sending text, reading pane content, and manipulating tabs/panes/windows, and a runtime probe confirms it works fully headless (mux-server daemonized, spawn/send-text/get-text/list all functioning without a GUI) — exactly the kind of scriptable, agent-drivable CLI an AI-native user would need. Missing for 10: no explicit first-party framing or examples for AI/agent orchestration use-cases, and no independent (non-vendor) confirmation beyond the single runtime probe.", "evidenceIds": [ "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-4", "wezterm-probe-rt-1" ] }, { "productId": "wezterm", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "WezTerm exposes a documented CLI (wezterm cli spawn/send-text/get-text/list) and a Lua config API, and a runtime probe confirms headless scripted control works end-to-end without a GUI, which is strong evidence for programmatic/agentic driving. However this is a CLI/Lua surface rather than a formal public API spec, and explicit machine-readable API docs (llms.txt, OpenAPI) both 404. missing for 10: an official structured API spec (OpenAPI/schema) or llms.txt for machine consumption, first-party documentation framing this as an 'AI-native' or agent-facing API, and independent third-party corroboration of scripted/agentic use beyond the single runtime probe.", "evidenceIds": [ "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-4", "wezterm-probe-rt-1", "wezterm-probe-1", "wezterm-probe-3" ] }, { "productId": "wezterm", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator; issuing scoped/least-privilege API credentials for agents is an identity/access-management concern outside its product category, not something a terminal could plausibly ship.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "agentic-sdks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator, not a platform offering SDKs for developers to build against (its Lua config API and CLI are for configuring/controlling the terminal itself, not an official SDK for third-party integrations); this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "ai-error-explanation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator; it has no built-in AI assistance layer for interpreting command failures or suggesting fixes. This capability would belong to a shell, AI CLI wrapper, or assistant layered on top, not the terminal emulator itself, making this a wrong-axis question for this product category.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "ai-privacy-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator with static configuration docs and a Lua API reference, but there's no evidence of an interactive, runnable-examples API reference; probes confirm no llms.txt, no docs-md, and no OpenAPI/interactive API surface exists.", "evidenceIds": [ "wezterm-probe-1", "wezterm-probe-2", "wezterm-probe-3" ] }, { "productId": "wezterm", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "WezTerm exposes a CLI and mux protocol but no machine-readable API spec is documented; probes for llms.txt, docs-md, and OpenAPI/swagger endpoints all return 404.", "evidenceIds": [ "wezterm-probe-1", "wezterm-probe-2", "wezterm-probe-3" ] }, { "productId": "wezterm", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator/multiplexer, not a platform providing sandboxed environments or data-isolation guarantees; there is no evidence it offers any sandbox-vs-production separation feature, and this is a category mismatch rather than a missing capability of the product type.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a versioned API or documented deprecation policy; probes for llms.txt, docs-md, and OpenAPI specs all returned 404, and no docs mention API versioning or deprecation practices. WezTerm's Lua config API and CLI have no documented stability/versioning guarantees in the evidence pack.", "evidenceIds": [ "wezterm-probe-1", "wezterm-probe-2", "wezterm-probe-3" ] }, { "productId": "wezterm", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "WezTerm's CLI (`wezterm cli list/spawn/send-text/get-text`) exposes scriptable primitives that let a user enumerate and act on multiple panes/tabs/windows programmatically, and the runtime probe confirms headless multiplexer control works end-to-end. However, there's no evidence of a native 'bulk operation' command that targets many items in a single call — any bulk behavior would require external shell scripting/looping over the CLI primitives, which isn't documented. Missing for 10: documented batch/multi-target commands, evidence of scaling to large numbers of panes/tabs, and any built-in bulk-action feature beyond single-target CLI calls.", "evidenceIds": [ "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-rt-1", "wezterm-probe-4" ] }, { "productId": "wezterm", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "WezTerm's docs show scripted automation hooks (CLI to spawn/manipulate panes headlessly, shell-integration user vars, and automatic config-reload on file change) that could be used to script reactive behavior, but there is no explicit documentation of a rule/event system (e.g., named event triggers or pattern-based action bindings) that fires automatically on terminal events. Missing for 10: explicit event-trigger/rule API documentation, examples of event-based automation, and independent confirmation that users define event-driven rules.", "evidenceIds": [ "wezterm-docs-6", "wezterm-docs-24", "wezterm-docs-25", "wezterm-docs-19", "wezterm-probe-rt-1" ] }, { "productId": "wezterm", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "builtin-ai-agent", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "cli-remote-control", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "WezTerm ships a documented `cli` subcommand (spawn, send-text, get-text, list, activate, etc.) that controls a running GUI or multiplexer instance, and this was independently verified headless (daemonized mux server + spawn/send-text/get-text/list roundtrip) plus corroborated by a community user dumping scrollback via get-text. Missing for 10: no first-party mention of a richer structured IPC/JSON-RPC protocol beyond the CLI wrapper, and no independent third-party write-up beyond the single HN mention.", "evidenceIds": [ "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-4", "wezterm-probe-rt-1", "wezterm-comm-1" ] }, { "productId": "wezterm", "storyId": "command-aware-features", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "WezTerm's shell-integration docs describe OSC 7 cwd-tracking and custom user vars (wezterm-docs-10, wezterm-docs-20, wezterm-docs-25), but the evidence pack contains no mention of exit-status tracking, command duration, or notifications when long-running commands finish — features other terminals' shell integrations advertise. Missing for 10: documented exit-status capture, command-duration timing, and completion notifications.", "evidenceIds": [ "wezterm-docs-10", "wezterm-docs-20", "wezterm-docs-25" ] }, { "productId": "wezterm", "storyId": "command-palette-discovery", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents CLI subcommands, quick-select, scrollback search, and SSH/multiplexing features, but nowhere mentions a searchable command palette for discovering/running actions. A community comment even notes that WezTerm's many features 'are not really discoverable,' reinforcing the absence of such a UI. Missing for 10: any documentation or user report of a command-palette UI, its keybinding, or its action list.", "evidenceIds": [ "wezterm-comm-7", "wezterm-docs-7", "wezterm-docs-5" ] }, { "productId": "wezterm", "storyId": "config-as-code", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "WezTerm's config is plain Lua text (wezterm.lua) that lives in dotfiles, auto-reloads on change, and supports CLI overrides — and community evidence directly confirms this makes cross-machine syncing trivial ('it's just Lua code, easy to diff and easy to apply' vs. iTerm2 where syncing was 'next to impossible'). Missing for 10: no first-party doc explicitly discussing dotfiles/multi-machine sync workflows, only community corroboration.", "evidenceIds": [ "wezterm-docs-6", "wezterm-docs-23", "wezterm-docs-24", "wezterm-comm-19" ] }, { "productId": "wezterm", "storyId": "cross-platform", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "WezTerm's Lua-based config is designed to be portable, with docs describing config file watching/reloading and command-line overrides, and community evidence confirms real cross-platform parity: \"I have been able to completely replace tmux with wezterm on Linux and Mac... It even works on Windows\" and a user reporting seamless config sync across machines via chezmoi/Lua. macOS install via brew is explicitly documented. Missing for 10: explicit first-party install docs/citations for Linux and Windows in this pack (only macOS install doc present), and no direct doc statement guaranteeing identical behavior across all three OSes.", "evidenceIds": [ "wezterm-docs-6", "wezterm-docs-23", "wezterm-docs-24", "wezterm-docs-13", "wezterm-docs-16", "wezterm-comm-17", "wezterm-comm-19" ] }, { "productId": "wezterm", "storyId": "extensibility-plugins", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "WezTerm's configuration and extensibility system is Lua-based, confirmed by community reports (e.g., 'with Wezterm it's just Lua code, easy to diff and easy to apply') and supported by docs showing config-file hooks, live-reload, CLI overrides, and user-variable functions that imply a scripting surface beyond simple config. However, the evidence pack lacks direct first-party documentation explicitly describing the Lua API/plugin system, and there is no support for Python or kitten-style extensions (those are a different terminal's feature) — missing for 10: explicit docs citation of the Lua scripting/plugin API, evidence of a plugin ecosystem, and any Python/kittens equivalent.", "evidenceIds": [ "wezterm-docs-6", "wezterm-docs-24", "wezterm-docs-25", "wezterm-comm-19" ] }, { "productId": "wezterm", "storyId": "fonts-ligatures", "verdict": "disputed", "quality": 6, "confidence": "medium", "rationale": "WezTerm's docs explicitly advertise ligatures, color emoji, and font fallback with true color, and config docs mention font-size/color-scheme tuning and live-reload of config changes, supporting fine-grained font control. However, hands-on community reports concretely contradict the polish of this: one user found WezTerm 'severely lacking in font configuration department contrary to popular opinion,' and another reports it 'renders Pragmata Pro Mono Liga much worse on Linux than Tilix does,' plus a Windows user found ligature rendering came with worse input latency than alternatives. Missing for 10: first-party deep-dive docs on fallback font ordering/fine-tuning knobs beyond font_size, and independent corroboration resolving the rendering-quality complaints.", "evidenceIds": [ "wezterm-docs-11", "wezterm-docs-22", "wezterm-docs-21", "wezterm-docs-24", "wezterm-comm-14", "wezterm-comm-18", "wezterm-comm-6" ] }, { "productId": "wezterm", "storyId": "gpu-accelerated-rendering", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "WezTerm's docs tout GPU-based rendering features (ligatures, true color, dynamic schemes) and community reports frequently praise it as fast/responsive (e.g., wezterm-comm-3, wezterm-comm-4, wezterm-comm-5), but multiple hands-on reports directly contradict sustained performance under heavy output — lag when scrolling long lists (wezterm-comm-11), higher input latency than Kitty/cmd.exe and blank-line rendering glitches in vim (wezterm-comm-6, wezterm-comm-12), and poor font rendering vs other GPU terminals (wezterm-comm-18). Missing for 10: explicit first-party GPU-rendering documentation/benchmarks and resolution of the latency/rendering-glitch reports.", "evidenceIds": [ "wezterm-docs-11", "wezterm-docs-22", "wezterm-comm-3", "wezterm-comm-4", "wezterm-comm-5", "wezterm-comm-6", "wezterm-comm-11", "wezterm-comm-12", "wezterm-comm-18" ] }, { "productId": "wezterm", "storyId": "inline-images-graphics", "verdict": "disputed", "quality": 6, "confidence": "medium", "rationale": "WezTerm documents iTerm2-compatible inline image protocol support plus a built-in imgcat CLI for outputting images to the terminal, which is a genuine documented graphics protocol implementation. However, a hands-on community report states the image support 'didn't play well with tmux,' a concrete real-world failure that led a user to switch away, contradicting a fully seamless graphics experience. Missing for 10: independent hands-on confirmation that images render cleanly outside tmux edge cases, and evidence of broader protocol support (e.g., Sixel/Kitty graphics) beyond iTerm2 compatibility.", "evidenceIds": [ "wezterm-docs-12", "wezterm-docs-15", "wezterm-comm-20" ] }, { "productId": "wezterm", "storyId": "measured-performance-claims", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item shows WezTerm publishing formal benchmarks, latency/throughput measurements, or comparative performance data; docs only list features, and community comments are anecdotal impressions (some praising speed, others reporting higher latency than cmd.exe/kitty/alacritty) rather than measured numbers.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "nl-command-generation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a terminal emulator, not an AI assistant; no evidence of natural-language-to-shell-command generation or any AI feature is present in its docs or feature set. This capability is a wrong axis for a terminal emulator itself (would belong to a separate AI shell-assistant tool), so it is 'na' rather than 'none'.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "WezTerm ships a genuine CLI/mux API (`wezterm cli spawn/send-text/get-text/list`) that a hands-on probe confirms works fully headless without a GUI session, covering pane/tab/window manipulation and text I/O — a strong basis for AI-native control. However, there's no evidence of full UI/API parity (e.g. scripting quick-select, font/color-scheme changes, image protocol, or search-mode equivalents via CLI), and no OpenAPI/machine-readable API surface (probes for openapi.json and llms.txt returned 404s), so many UI-only interactions remain unaddressed by the API. Missing for 10: documented CLI/Lua equivalents for all interactive UI features (quick select, scrollback search, image display, appearance changes), and any formal API spec.", "evidenceIds": [ "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-rt-1", "wezterm-probe-3", "wezterm-probe-1" ] }, { "productId": "wezterm", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "WezTerm's configuration is plain-text Lua stored locally (not locked in a proprietary format or cloud service), and community evidence shows scrollback/session content can be dumped via `wezterm cli get-text`, giving a de facto path to extract your data and leave. However, there is no explicit documented 'export all data' feature, no bundled data-portability tool, and no discussion of migrating multiplexer session state elsewhere. Missing for 10: an explicit export/backup feature or documentation addressing full data portability beyond config files and scrollback dumps, and independent confirmation of leaving with all state intact.", "evidenceIds": [ "wezterm-docs-6", "wezterm-docs-23", "wezterm-comm-1", "wezterm-comm-19" ] }, { "productId": "wezterm", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack references WezTerm's source license, GitHub repository, or open-source licensing terms; all citations concern terminal features, CLI usage, and user reviews, not code openness. Missing for 10: mention of the repository/license, license type (e.g. MIT), or any statement about source availability.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "openness-self-host", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "WezTerm ships an embedded mux server that users can run themselves (self-hosted) and connect to via SSH domains, with docs on multiplexing and SSH domains plus a runtime probe confirming a fully headless `wezterm-mux-server --daemonize` control loop with `wezterm cli` spawn/send-text/get-text/list working without a GUI session. missing for 10: independent/community confirmation of self-hosted mux server usage specifically (most community quotes discuss desktop terminal use, not self-hosted server operation), and explicit licensing/deployment guidance for running it as a persistent self-hosted service.", "evidenceIds": [ "wezterm-docs-8", "wezterm-docs-9", "wezterm-docs-14", "wezterm-probe-rt-1", "wezterm-docs-7" ] }, { "productId": "wezterm", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a local terminal emulator; it doesn't store user data in any cloud region, so 'data residency' is a category error for this product type.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a local terminal emulator, not an AI service or data-processing platform that trains models on user data; there is no AI training/data-usage relationship to opt out of, so this privacy-posture axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "WezTerm is a local terminal emulator with no cloud data storage, accounts, or telemetry service that would collect/retain user data; the story concerns a data-processing/SaaS product's retention & deletion controls, which is a category error for a terminal application. All configuration, scrollback, and logs are local files under the user's own control by default, not a vendor-managed retention policy.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "prompt-marks-navigation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence pack's shell-integration docs (wezterm-docs-10, wezterm-docs-20, wezterm-docs-25) only cover OSC 7 working-directory tracking and custom user vars — there is no mention of OSC 133 semantic prompt/command marks or any keybinding/feature to jump between prompts or command outputs in scrollback. Missing for 10: documentation or evidence of prompt-jump/command-mark navigation, keybindings for 'jump to previous/next prompt', and any independent confirmation of this specific capability.", "evidenceIds": [ "wezterm-docs-10", "wezterm-docs-20", "wezterm-docs-25" ] }, { "productId": "wezterm", "storyId": "quake-dropdown-mode", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack of a global-hotkey summon or quake-style dropdown window feature; documentation covers panes/tabs/multiplexing, SSH, CLI control, and scrollback but never mentions an instant-summon/dropdown mode, and no community citation confirms this capability exists.", "evidenceIds": [] }, { "productId": "wezterm", "storyId": "scripted-session-layouts", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "WezTerm's Lua-based config supports scripting startup behavior, and the documented `cli` subcommand can spawn programs and manipulate tabs/panes; a hands-on probe confirms a fully headless control loop (spawn window, send commands, enumerate panes) without GUI interaction, which is exactly the kind of single-command scripted session/layout setup the story describes. Missing for 10: explicit vendor documentation of a named 'workspace' or multi-pane layout template feature (e.g. gui-startup event) and independent community confirmation specifically of launching complex multi-window/pane project layouts via one script.", "evidenceIds": [ "wezterm-docs-7", "wezterm-docs-19", "wezterm-docs-6", "wezterm-docs-24", "wezterm-docs-23", "wezterm-probe-rt-1" ] }, { "productId": "wezterm", "storyId": "scrollback-search", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "WezTerm documents a Searchable Scrollback feature with Ctrl-Shift-F search mode and keyboard navigation (Shift-PageUp/PageDown, mouse wheel), directly matching the story of quickly searching and jumping between matches; Quick Select mode further complements this for jumping to specific text patterns. Community evidence corroborates related scrollback tooling (get-text dump) though no direct hands-on account of search-and-jump-between-matches UX specifically. Missing for 10: independent hands-on account of the search-mode match-navigation experience (e.g., keybindings for next/prev match) and any friction/limitations reported by users.", "evidenceIds": [ "wezterm-docs-4", "wezterm-docs-17", "wezterm-docs-5", "wezterm-comm-1" ] }, { "productId": "wezterm", "storyId": "session-restore", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "WezTerm's mux-server/SSH-domain feature lets tabs and panes survive a GUI crash or restart by reconnecting to a persistent multiplexer instance, and OSC7-based cwd tracking lets new tabs inherit a working directory — but these require manually setting up a separate mux-server domain rather than being an automatic 'restore my session' feature, and there's no evidence of full window-layout or automatic state persistence on plain restart. Missing for 10: documented automatic session/workspace save-and-restore across app restarts, evidence of working-directory restoration (not just inheritance) after crash, and independent confirmation the mux-domain workflow reliably recovers full window/tab state.", "evidenceIds": [ "wezterm-docs-8", "wezterm-docs-14", "wezterm-docs-10", "wezterm-docs-9" ] }, { "productId": "wezterm", "storyId": "splits-tabs-panes", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "WezTerm natively multiplexes panes, tabs, and windows locally and remotely with CLI control and persistent mux server, and multiple hands-on community reports confirm fast, responsive pane splitting used as a tmux replacement. missing for 10: no independent third-party benchmark comparing full multiplexer feature parity (session detach/reattach robustness) across platforms.", "evidenceIds": [ "wezterm-docs-3", "wezterm-docs-7", "wezterm-docs-19", "wezterm-probe-rt-1", "wezterm-comm-2", "wezterm-comm-4", "wezterm-comm-17" ] }, { "productId": "wezterm", "storyId": "ssh-integration", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "WezTerm ships a built-in SSH client and 'SSH domains' that let you multiplex tabs/panes over an SSH connection to a remote wezterm mux, and it exposes shell-integration features (OSC7 cwd tracking, user vars) for local sessions, but the evidence never explicitly confirms that terminfo, shell-integration scripts, or local config are automatically propagated/carried to the remote host on ad-hoc SSH connections (docs-9/14/18 note an 'alternative configuration' needed for full tab/pane preservation, implying the basic ad-hoc SSH mode doesn't fully carry everything). missing for 10: explicit documentation/evidence of terminfo propagation to remote host, confirmation that shell-integration scripts/config are auto-installed or carried over plain SSH (not just via the multiplexer/domain setup), and independent hands-on confirmation of this remote workflow working smoothly.", "evidenceIds": [ "wezterm-docs-9", "wezterm-docs-8", "wezterm-docs-14", "wezterm-docs-18", "wezterm-docs-10", "wezterm-docs-25" ] }, { "productId": "wezterm", "storyId": "theming-color-schemes", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence confirms WezTerm supports configurable color schemes and dynamic color scheme changes via config/live-reload, but nothing in the pack explicitly documents automatic OS light/dark mode detection or a scheme-switching mechanism tied to system appearance. Missing for 10: explicit documentation of automatic light/dark mode switching (e.g., appearance-based scheme selection), and independent confirmation it works in practice.", "evidenceIds": [ "wezterm-docs-11", "wezterm-docs-21", "wezterm-docs-22", "wezterm-docs-24" ] }, { "productId": "wezterm", "storyId": "tmux-compat", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "WezTerm documents its own native multiplexing (panes/tabs/windows, SSH domains, mux server, cli spawn/send-text/get-text control mode verified in a headless probe) as a built-in alternative to tmux, and users can also run tmux inside it. However, this is WezTerm's own multiplexer, not a documented tmux control-mode/integration, and community evidence shows friction when combining WezTerm with actual tmux (image protocol issues causing a user to switch to Ghostty). missing for 10: explicit documentation of tmux control-mode (tmux -CC) support or a first-party statement about compatibility/integration with tmux itself, and resolution of the tmux+image-support conflict noted by a user.", "evidenceIds": [ "wezterm-docs-3", "wezterm-docs-7", "wezterm-docs-8", "wezterm-docs-19", "wezterm-probe-rt-1", "wezterm-comm-17", "wezterm-comm-20" ] }, { "productId": "wezterm", "storyId": "url-path-click", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "WezTerm's Quick Select mode lets users highlight and copy commonly-matched text patterns via keyboard shortcuts, which could cover URLs/paths, but the evidence pack never explicitly documents clickable URL/file opening or an 'open with' action, nor mouse-click-to-open behavior. missing for 10: explicit doc on clicking URLs/paths to open them, evidence of file-path recognition, independent confirmation of click-to-open working in practice.", "evidenceIds": [ "wezterm-docs-5", "wezterm-docs-4" ] } ]