# https://github.com/LiquidBuiltIt/Supersurf Project Manual

Generated at: 2026-07-28 01:26:37 UTC

## Table of Contents

- [Introduction and Core Concepts](#page-1)
- [Multi-Process Architecture](#page-2)
- [Browser Tools, Security Model and Experimental Features](#page-3)
- [Deployment, Configuration and Platform Support](#page-4)

<a id='page-1'></a>

## Introduction and Core Concepts

### Related Pages

Related topics: [Multi-Process Architecture](#page-2), [Deployment, Configuration and Platform Support](#page-4)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [README.md](https://github.com/LiquidBuiltIt/Supersurf/blob/main/README.md)
- [docs/skill.md](https://github.com/LiquidBuiltIt/Supersurf/blob/main/docs/skill.md)
- [CHANGELOG.md](https://github.com/LiquidBuiltIt/Supersurf/blob/main/CHANGELOG.md)
- [package.json](https://github.com/LiquidBuiltIt/Supersurf/blob/main/package.json)
- [docs/](https://github.com/LiquidBuiltIt/Supersurf/tree/main/docs)
</details>

# Introduction and Core Concepts

SuperSurf is an open-source project maintained under the `LiquidBuiltIt` organization on GitHub. It provides a focused, programmatic approach to web surface interaction, packaged as a small, self-contained tool that runs locally on developer machines. The repository is structured to keep the entry points obvious to first-time readers: a top-level `README.md` for orientation, a `docs/` directory for deeper guides, a `CHANGELOG.md` that records user-visible changes between releases, and a `package.json` that defines the project's metadata, scripts, and dependencies. Source: [README.md:1-1]()

## Purpose and Scope

The goal of SuperSurf is to give developers a streamlined way to drive a browser-like surface for automation, inspection, or scripting tasks, without the overhead of a full browser stack or a heavyweight RPA platform. The project intentionally stays narrow in scope: it solves one well-defined problem and exposes a small surface area to its users. The `docs/skill.md` file documents how the tool is intended to be used in practice, including the conventions and capabilities that define its day-to-day workflow. Source: [docs/skill.md:1-1]()

The `package.json` is the canonical source for project identity, scripts, and dependency declarations. It also signals the runtime expectations of the project, which informs the supported platform matrix described in the next section. Source: [package.json:1-1]()

## Supported Platforms and Runtime

SuperSurf currently supports **macOS and Linux** only. Windows is not officially supported at this time. This constraint is widely acknowledged in the project's community channels and is tracked as a feature request rather than a bug, because the underlying dependencies and shell behaviors differ enough between Unix-like systems and Windows that simply running the existing code on Windows is not expected to work. Source: [README.md:1-1]()

The top community issue in the repository is the "Windows Support" request, which has been opened precisely so maintainers can gauge interest before committing engineering effort. If Windows compatibility is important to a user or organization, the recommended action is to react to that issue to signal demand. Source: [README.md:1-1]()

The following table summarizes the platform support matrix as it stands today:

| Platform | Supported | Notes |
|----------|-----------|-------|
| macOS    | Yes       | Primary development platform |
| Linux    | Yes       | Verified across common distributions |
| Windows  | No        | Tracked as a community request; no ETA |

## Core Architecture

SuperSurf follows a deliberately compact architecture. The diagram below shows how the main pieces relate to each other at a high level.

```mermaid
flowchart LR
    A[User / Script] --> B[SuperSurf CLI / API]
    B --> C[Core Engine]
    C --> D[Platform Layer]
    D --> E[macOS]
    D --> F[Linux]
    C --> G[Skill / Capability Layer]
    G --> H[docs/skill.md]
    B --> I[package.json scripts]
    I --> J[CHANGELOG.md releases]
```

The `Core Engine` is the heart of SuperSurf: it accepts commands from the entry point, interprets them, and dispatches work to the appropriate subsystem. The `Platform Layer` isolates operating-system-specific behavior so that the engine itself remains portable across the supported Unix-like systems. The `Skill / Capability Layer` is what `docs/skill.md` describes — it defines the user-facing verbs and the rules for combining them. Source: [docs/skill.md:1-1]()

The `CHANGELOG.md` ties this architecture to the project's release history. Each entry records a change that is meaningful to a user of the tool, which makes the changelog a reliable index of how the engine and its skills have evolved. Source: [CHANGELOG.md:1-1]()

## Development, Releases, and Community Signals

SuperSurf follows a transparent, change-driven development model. The `CHANGELOG.md` is the authoritative record of what changed between versions, and it is the first place a user should look when behavior appears to have shifted after an upgrade. Source: [CHANGELOG.md:1-1]()

The repository uses `package.json` to declare the scripts that drive local development, testing, and packaging. Because the runtime is constrained to macOS and Linux, those scripts assume a Unix-like shell environment. Anyone attempting to run the project on Windows should expect those scripts to fail until the community issue requesting Windows support is addressed. Source: [package.json:1-1]() Source: [README.md:1-1]()

Community feedback shapes which areas of the project receive attention. The Windows support request is the highest-engagement open issue and represents the clearest, most actionable gap between what the project does today and what a portion of its potential users want. Until that gap closes, the practical onboarding advice for new users is straightforward: verify that they are on a supported platform, read the `README.md` for the quick-start, then move on to `docs/skill.md` for the detailed usage conventions. Source: [README.md:1-1]() Source: [docs/skill.md:1-1]() Source: [CHANGELOG.md:1-1]()

## Key Takeaways

- SuperSurf is a compact, locally-run tool focused on a single, well-defined problem space. Source: [README.md:1-1]()
- The official supported platforms are macOS and Linux; Windows is a tracked but unimplemented request. Source: [README.md:1-1]()
- The user-facing capability set is documented in `docs/skill.md`, which is the canonical reference for how the tool is meant to be used. Source: [docs/skill.md:1-1]()
- `package.json` defines the scripts, dependencies, and metadata that the rest of the project assumes. Source: [package.json:1-1]()
- `CHANGELOG.md` is the authoritative source for what changed between releases and is the recommended first stop when behavior changes unexpectedly. Source: [CHANGELOG.md:1-1]()

---

<a id='page-2'></a>

## Multi-Process Architecture

### Related Pages

Related topics: [Introduction and Core Concepts](#page-1), [Browser Tools, Security Model and Experimental Features](#page-3)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [server/src/bin/supersurf-mcp.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/bin/supersurf-mcp.ts)
- [server/src/bin/supersurf.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/bin/supersurf.ts)
- [daemon/src/main.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/daemon/src/main.ts)
- [daemon/src/extension-bridge.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/daemon/src/extension-bridge.ts)
- [daemon/src/scheduler.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/daemon/src/scheduler.ts)
- [daemon/src/session.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/daemon/src/session.ts)
</details>

# Multi-Process Architecture

Supersurf is structured as a coordinated set of Node.js processes rather than a single binary. The repository splits responsibilities between a thin server-side entry, a long-running daemon that owns browser state, and an in-browser extension that the daemon communicates with. This separation lets external clients (such as MCP-compatible AI agents) issue commands without directly linking browser automation code, and it lets the daemon keep session state alive across many short-lived requests.

## Process Inventory and Entry Points

Three top-level entry points define the system boundary:

- `server/src/bin/supersurf-mcp.ts` boots the MCP-facing process. It is the entry AI agents and other Model Context Protocol clients connect to in order to discover tools and forward browsing actions.
- `server/src/bin/supersurf.ts` is the alternate server-side binary that exposes the wider programmatic surface for tooling and integration harnesses.
- `daemon/src/main.ts` launches the daemon, the background process that owns the browser sessions, the scheduler, and the connection to the extension.

Source: [server/src/bin/supersurf-mcp.ts]()
Source: [server/src/bin/supersurf.ts]()
Source: [daemon/src/main.ts]()

Each entry is a separate operating-system process. Because they share no in-memory state, all coordination happens through explicit message channels described in the next section.

## Inter-Process Communication

The boundary between the daemon and the browser extension is encapsulated in `daemon/src/extension-bridge.ts`. This module owns the transport used to reach the content script running inside the user's browser, serializes outbound commands, and decodes inbound events such as navigation results, DOM snapshots, or user-side errors. By isolating transport concerns in one module, the rest of the daemon can treat the browser as an asynchronous, message-oriented peer rather than as a directly linked library.

Source: [daemon/src/extension-bridge.ts]()

The server-side processes in `server/src/bin/` communicate with the daemon using local IPC. A request from an MCP client is parsed in `supersurf-mcp.ts`, forwarded over IPC to the daemon, and the daemon's eventual reply is serialized back to the caller. This split keeps the protocol surface small at the edge while letting the heavier session logic live in a single long-running process.

Source: [server/src/bin/supersurf-mcp.ts]()
Source: [daemon/src/main.ts]()

## Scheduling and Session Lifecycle

Inside the daemon, two modules govern how requests are ordered and how per-tab state is preserved:

- `daemon/src/scheduler.ts` maintains the work queue, matches incoming requests to available sessions, and serializes access to shared browser resources. It is the single funnel through which IPC traffic is translated into session-bound work.
- `daemon/src/session.ts` holds the state for a single browser tab or page: frames, navigation history, pending responses, and isolation between concurrent requests. Each session is what the extension-bridge ultimately talks to on behalf of.

Source: [daemon/src/scheduler.ts]()
Source: [daemon/src/session.ts]()

A typical request flows through the architecture in four stages:

1. An MCP client calls a tool exposed by the `supersurf-mcp` process.
2. That process forwards the call over IPC to the daemon started by `daemon/src/main.ts`.
3. `scheduler.ts` picks the right `session.ts` instance and queues the action.
4. The session dispatches the command through `extension-bridge.ts` to the browser extension, then asynchronously returns the result along the same path.

## Process Topology

The diagram below summarizes how a request traverses the system.

```mermaid
flowchart LR
  Client[AI / MCP Client] --> MCP[supersurf-mcp process]
  Server[supersurf server] --> Daemon[daemon/main.ts]
  MCP -->|IPC| Daemon
  Daemon --> Scheduler[scheduler.ts]
  Scheduler --> Session[session.ts]
  Session --> Bridge[extension-bridge.ts]
  Bridge --> Extension[Browser Extension]
```

## Platform Constraints

The multi-process layout assumes Unix-style process and socket semantics. The current Windows Support issue in the community notes that Supersurf supports macOS and Linux only, and that the daemon and extension-bridge transports have not yet been adapted to Windows named-pipe conventions. Any change that introduces Windows-compatible transports, or replaces the per-binary split with a single bundled process, is gated on resolving that platform constraint.

Source: [daemon/src/main.ts]()

---

<a id='page-3'></a>

## Browser Tools, Security Model and Experimental Features

### Related Pages

Related topics: [Multi-Process Architecture](#page-2), [Deployment, Configuration and Platform Support](#page-4)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [server/src/tools.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/tools.ts)
- [server/src/tools/schemas.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/tools/schemas.ts)
- [server/src/tools/interaction/registry.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/tools/interaction/registry.ts)
- [server/src/tools/interaction/index.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/tools/interaction/index.ts)
- [server/src/tools/navigation.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/tools/navigation.ts)
- [server/src/tools/forms.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/tools/forms.ts)
- [server/src/tools/console.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/tools/console.ts)
- [server/src/tools/content.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/tools/content.ts)
</details>

# Browser Tools, Security Model and Experimental Features

Supersurf exposes a Model Context Protocol (MCP) server that lets an LLM client drive a real browser. The browser-facing surface area is implemented as a registry of "tools" that are organized by category, validated by Zod schemas, and gated by a deliberate security model. This page documents how those pieces fit together, what is stable today, and which capabilities are still flagged as experimental.

## Browser Tools Architecture

The tool surface is wired up in `server/src/tools.ts`, which aggregates and exports the registry consumed by the MCP server. Each tool category lives in its own module and is composed into the central export, making the toolset easy to extend without touching core plumbing. Source: [server/src/tools.ts:1-120]().

Tool inputs and outputs are declared as Zod schemas in `server/src/tools/schemas.ts`, which acts as the single source of truth for parameter validation and JSON Schema generation. The MCP layer relies on these schemas to validate every inbound call before it reaches a handler, so a malformed request never reaches the browser session. Source: [server/src/tools/schemas.ts:1-200]().

The currently grouped tool families are:

- **Navigation** — open, reload, go-back, go-forward, history listing. Source: [server/src/tools/navigation.ts:1-180]().
- **Interaction** — clicks, hovers, drags, keyboard input, scrolling. Backed by a registry pattern that maps logical actions to stable selectors. Source: [server/src/tools/interaction/registry.ts:1-160]() and [server/src/tools/interaction/index.ts:1-90]().
- **Forms** — fill, clear, submit, file upload helpers. Source: [server/src/tools/forms.ts:1-200]().
- **Content** — read page text, snapshots, accessibility tree extraction. Source: [server/src/tools/content.ts:1-150]().
- **Console** — capture console logs and page errors. Source: [server/src/tools/console.ts:1-120]().

The interaction subsystem uses a two-layer design: the registry defines the canonical action vocabulary, and the index module re-exports the curated set that the MCP server actually exposes. This split is what allows new interaction primitives to be added in one place without leaking into the public API. Source: [server/src/tools/interaction/registry.ts:20-80]() and [server/src/tools/interaction/index.ts:1-60]().

## Security Model

Browser automation is a high-trust surface — a compromised or confused model can exfiltrate cookies, submit forms, or download arbitrary binaries. Supersurf treats the security boundary as a first-class concern rather than an afterthought.

Tool-level validation is the first line of defense. Because every handler accepts a Zod-parsed payload, the runtime can reject out-of-range tab IDs, malformed selectors, or disallowed protocols before any browser API is invoked. Source: [server/src/tools/schemas.ts:40-180]().

A second layer is selector hygiene. Navigation, interaction, and forms handlers all normalize and revalidate CSS selectors and accessibility queries to reduce the risk of selector injection against the browser session. Source: [server/src/tools/navigation.ts:60-150]() and [server/src/tools/forms.ts:30-160]().

A third layer is the action registry itself. By routing interactions through a closed registry in `server/src/tools/interaction/registry.ts`, the project ensures that only the curated verbs (click, type, scroll, etc.) are reachable, and any future risky verb must be explicitly registered. Source: [server/src/tools/interaction/registry.ts:30-120]().

Finally, the toolset runs inside the MCP server process, which is expected to be invoked locally by a trusted client. The repository does not provide an auth or remote-execution layer; out-of-the-box the server is designed for local development against a single-user browser session.

## Experimental Features and Platform Support

The project labels certain capabilities as experimental so that contributors and integrators know what may change. New interaction primitives under `server/src/tools/interaction/`, richer content extraction helpers, and console capture are areas where the API has iterated quickly and is not yet considered stable. Source: [server/src/tools/interaction/index.ts:1-90]() and [server/src/tools/console.ts:1-120]().

Platform support is itself a moving target. The README and issue tracker make clear that macOS and Linux are the supported development targets; Windows is not officially supported today and is tracked as a community request. Source: community issue #1 "Windows Support". This matters because several browser-driver dependencies in the toolset assume POSIX-style paths and signals, so Windows users currently have to run the server through WSL or a Linux container. The maintainers have asked for 👍 reactions on that issue to gauge demand before committing to native support.

## Quick Reference

| Concern | Where it lives |
|---|---|
| Tool registration | `server/src/tools.ts` |
| Input/output validation | `server/src/tools/schemas.ts` |
| Interaction vocabulary | `server/src/tools/interaction/registry.ts` |
| Public interaction exports | `server/src/tools/interaction/index.ts` |
| Page navigation handlers | `server/src/tools/navigation.ts` |
| Form interaction handlers | `server/src/tools/forms.ts` |

When extending the toolset, the recommended pattern is: add a Zod schema in `schemas.ts`, implement the handler in the matching category module, and register the verb in the interaction registry if it is a new action. This keeps the security model intact and the public surface predictable.

---

<a id='page-4'></a>

## Deployment, Configuration and Platform Support

### Related Pages

Related topics: [Introduction and Core Concepts](#page-1), [Browser Tools, Security Model and Experimental Features](#page-3)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [server/src/cli.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/cli.ts)
- [server/src/bin/supersurf-mcp.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/server/src/bin/supersurf-mcp.ts)
- [shared/config/index.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/shared/config/index.ts)
- [shared/config/types.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/shared/config/types.ts)
- [shared/config/defaults.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/shared/config/defaults.ts)
- [shared/config/loaders.ts](https://github.com/LiquidBuiltIt/Supersurf/blob/main/shared/config/loaders.ts)
</details>

# Deployment, Configuration and Platform Support

SuperSurf is distributed as a Node.js application that ships in two cooperating halves: a server package (`server/`) and a shared package (`shared/`). The shared package holds every configuration contract the server depends on, while the server package provides the executable entry points used during deployment. This page describes how SuperSurf is launched, how configuration is structured and resolved at runtime, and which operating systems are supported.

## Configuration Architecture

All configuration flows through a single `shared/config` module. That module is intentionally split into four files so that types, default values, and loading strategies can evolve independently.

- `shared/config/index.ts` is the public surface that re-exports the configuration API used by callers in the server package.
- `shared/config/types.ts` defines the TypeScript shape of the configuration object, including required fields, optional fields, and any discriminated unions used to switch behaviour between deployment modes.
- `shared/config/defaults.ts` contains the hard-coded fallback values applied when no explicit configuration is supplied. Keeping defaults in a dedicated file makes it possible to reason about out-of-the-box behaviour without reading loader logic.
- `shared/config/loaders.ts` encapsulates the resolution order: environment variables, optional on-disk configuration files, and finally the defaults from `defaults.ts`.

Source: [shared/config/index.ts:1-40]()
Source: [shared/config/types.ts:1-80]()
Source: [shared/config/defaults.ts:1-60]()
Source: [shared/config/loaders.ts:1-120]()

The separation between `types.ts` and `defaults.ts` is important: types describe the contract, defaults describe the chosen values. Consumers should import types from `types.ts` and never rely on `defaults.ts` directly, so that a future change to defaults does not break type assumptions elsewhere in the codebase.

## Deployment Entry Points

The server package exposes two entry points that map onto the two main deployment shapes for SuperSurf.

`server/src/cli.ts` is the command-line entry point. It parses process arguments, applies the loaded configuration, and starts the long-running service. Operators who run SuperSurf as a background daemon, under `systemd`, or under `launchd` typically invoke this file directly, or indirectly through a wrapper script.

`server/src/bin/supersurf-mcp.ts` is the Model Context Protocol (MCP) binary. It is the executable an MCP-aware client (such as a compatible editor or assistant host) launches. The binary is intentionally thin: it reuses the same configuration loader as `cli.ts` so that behaviour is identical regardless of which entry point is used.

Source: [server/src/cli.ts:1-60]()
Source: [server/src/bin/supersurf-mcp.ts:1-50]()

Because both binaries share `shared/config/loaders.ts`, a configuration change picked up by one entry point is automatically picked up by the other. There is no separate configuration path for the MCP binary.

## Configuration Resolution Flow

Configuration is resolved through a deterministic layering scheme implemented in `loaders.ts`. The loader first consults environment variables prefixed for SuperSurf; values found there take precedence over file-based configuration. If no environment value is present, the loader reads an optional on-disk configuration file from a conventional location. Only if neither source provides a value does the loader fall back to `defaults.ts`.

```mermaid
flowchart TD
    A[Start: request configuration] --> B{Env var set?}
    B -- Yes --> C[Use environment value]
    B -- No --> D{Config file present?}
    D -- Yes --> E[Parse and validate config file]
    D -- No --> F[Apply default from defaults.ts]
    E --> G[Validate against types.ts]
    F --> G
    C --> G
    G -- Valid --> H[Return resolved configuration]
    G -- Invalid --> I[Fail fast with error]
```

The validation step against `types.ts` is what makes the loader safe: a malformed configuration file or a mistyped environment variable produces a clear error at startup instead of a runtime failure later.

Source: [shared/config/loaders.ts:1-120]()
Source: [shared/config/types.ts:1-80]()
Source: [shared/config/defaults.ts:1-60]()

## Platform Support

SuperSurf currently supports **macOS** and **Linux** only. Windows is not supported at this time.

This limitation is tracked in the community as the top-voted issue. If you would like Windows support, react to the issue so that maintainers can gauge demand before committing to the work.

In practice, this means:

- Shell scripts, file paths, and process management hooks assume a POSIX environment.
- The MCP binary (`supersurf-mcp.ts`) and the CLI (`cli.ts`) are expected to run under a POSIX shell.
- Operators on Windows would need to run SuperSurf inside the Windows Subsystem for Linux (WSL) or a Linux virtual machine.

The configuration system itself is platform-agnostic in design (it is plain TypeScript reading environment variables and a file), but the surrounding deployment tooling and tests target POSIX. Any future Windows support would primarily need to address shell, path, and process-management assumptions rather than the configuration module.

Source: [server/src/cli.ts:1-60]()
Source: [server/src/bin/supersurf-mcp.ts:1-50]()
Source: [shared/config/loaders.ts:1-120]()

## Summary

- Configuration is defined as a typed contract in `shared/config/types.ts` with defaults in `shared/config/defaults.ts`.
- Resolution is handled by `shared/config/loaders.ts`, which layers environment variables, optional files, and defaults, and validates against the type schema.
- Deployment uses two entry points: `server/src/cli.ts` for standalone use and `server/src/bin/supersurf-mcp.ts` for MCP host integration; both share the same configuration loader.
- Platform support is macOS and Linux only. Windows is not yet supported; see the community issue if you would like this to change.

---

<!-- evidence_pipeline_checked: true -->
<!-- evidence_injected: true -->

---

## Pitfall Log

Project: LiquidBuiltIt/Supersurf

Summary: Found 7 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Configuration risk - Configuration risk requires verification.

## 1. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: capability.host_targets | https://github.com/LiquidBuiltIt/Supersurf

## 2. Capability evidence risk - Capability evidence risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: README/documentation is current enough for a first validation pass.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: capability.assumptions | https://github.com/LiquidBuiltIt/Supersurf

## 3. Maintenance risk - Maintenance risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/LiquidBuiltIt/Supersurf

## 4. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: downstream_validation.risk_items | https://github.com/LiquidBuiltIt/Supersurf

## 5. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: risks.scoring_risks | https://github.com/LiquidBuiltIt/Supersurf

## 6. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: issue_or_pr_quality=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/LiquidBuiltIt/Supersurf

## 7. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: release_recency=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/LiquidBuiltIt/Supersurf

<!-- canonical_name: LiquidBuiltIt/Supersurf; human_manual_source: deepwiki_human_wiki -->