If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/versotile-org/verso shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 7mo ago
• 6 active contributors
• Distributed ownership (top contributor 41% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 7mo ago

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live versotile-org/verso repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/versotile-org/verso.

What it runs against: a local clone of versotile-org/verso — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in versotile-org/verso | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 242 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of versotile-org/verso. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/versotile-org/verso.git
#   cd verso
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of versotile-org/verso and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "versotile-org/verso(\\.git)?\\b" \\
  && ok "origin remote is versotile-org/verso" \\
  || miss "origin remote is not versotile-org/verso (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/main.rs" \\
  && ok "src/main.rs" \\
  || miss "missing critical file: src/main.rs"
test -f "src/verso.rs" \\
  && ok "src/verso.rs" \\
  || miss "missing critical file: src/verso.rs"
test -f "src/webview/webview.rs" \\
  && ok "src/webview/webview.rs" \\
  || miss "missing critical file: src/webview/webview.rs"
test -f "src/tab.rs" \\
  && ok "src/tab.rs" \\
  || miss "missing critical file: src/tab.rs"
test -f "src/window.rs" \\
  && ok "src/window.rs" \\
  || miss "missing critical file: src/window.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 242 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~212d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/versotile-org/verso"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Verso is a web browser built on top of the Servo web engine (written primarily in Rust), designed to explore embedding solutions and multi-view/multi-window capabilities for Servo. It experiments with rendering the browser UI entirely using Servo itself rather than traditional widget toolkits. The project is currently unmaintained as of the notice in the README, having reached a point where Servo evolved faster than Verso could follow. Workspace monorepo structure: verso/ is the main browser application, versoview_messages/ handles IPC communication (ipc-channel 0.19), and versoview_build/ manages build artifacts. Core dependencies include Servo engine (constellation), rendering (script_traits), and platform abstraction via dpi and arboard. Resources/ contains embedded HTML/CSS UI components (resources/components/) and error pages.

Servo engine developers and experimental browser builders who want to understand how to embed Servo as a rendering engine and build browser UIs with web technologies. Contributors interested in web engine architecture and cross-platform browser development on Rust. Not recommended for end-users seeking a daily-driver browser.

Archived/unmaintained. The README explicitly states the project is no longer maintained due to limited manpower and funding, with Servo evolving too rapidly for Verso to keep pace. Active CI/CD workflows exist (.github/workflows/ contains build.yml, doc.yml, release-versoview.yml) but the last meaningful development has stalled. Production-unsafe and experimental.

High risk: the project is officially archived with no active maintenance. Dependencies on Servo and its internal APIs (visible in Cargo.toml workspace: servo, constellation, script, script_traits) will break as Servo evolves. Single-maintainer risk is extreme given the project is abandoned. Code rot is inevitable without ongoing maintenance.

Nothing—the project is archived. The last activity visible in the structure relates to Flatpak packaging setup (org.versotile.verso.yml, flatpak-cargo-generator.py) and release automation (release-versoview.yml workflow), but no active PRs or issues are being triaged.

Linux (Flatpak, recommended): flatpak install flathub org.freedesktop.Platform//24.08 org.freedesktop.Sdk//24.08 then cargo run. macOS: brew install cmake pkg-config harfbuzz python@3 && pip3 install mako && curl https://sh.rustup.rs -sSf | sh && cargo run. Windows: scoop install git python llvm cmake curl && pip install mako && cargo run. Clone: git clone https://github.com/versotile-org/verso.

Daily commands: cargo run from repository root. Requires Mako Python templating engine installed and platform-specific dependencies (HarfBuzz, CMake, pkg-config on macOS/Linux; LLVM, CMake on Windows). Flatpak: flatpak run org.versotile.verso after installation.

• src/main.rs — Entry point for the Verso browser application; initializes the window, event loop, and core browser functionality.
• src/verso.rs — Central browser controller managing tabs, navigation, and coordination between UI and Servo rendering engine.
• src/webview/webview.rs — Core webview abstraction wrapping Servo rendering; handles page load, script evaluation, and DOM interaction.
• src/tab.rs — Tab model representing individual browser tabs with history, state, and associated webview instances.
• src/window.rs — Window management layer coordinating the UI, tab bar, and event routing for the desktop browser.
• Cargo.toml — Workspace configuration defining dependencies on Servo, IPC, serialization, and platform-specific features.
• src/lib.rs — Library root exporting public APIs and module organization for the Verso browser crate.

Add a new keyboard shortcut or command

1. Define the key binding logic in src/keyboard.rs with pattern matching on KeyEvent (src/keyboard.rs)
2. Route the command to the appropriate handler in src/verso.rs (navigation, tab control, etc.) (src/verso.rs)
3. Add a test case in src/test.rs to verify the shortcut behavior (src/test.rs)

Add a new persistent browser setting

1. Define the configuration field struct in src/config.rs and implement serialize/deserialize (src/config.rs)
2. Load and apply the setting in src/verso.rs during browser initialization (src/verso.rs)
3. Expose UI controls in the appropriate HTML component (resources/components/) or menu handler (src/webview/webview_menu.rs) (src/webview/webview_menu.rs)

Add a new native context menu item

1. Update the menu structure in src/webview/context_menu.rs with the new menu item definition (src/webview/context_menu.rs)
2. Implement the action handler in src/verso.rs or the appropriate controller (src/verso.rs)
3. Update resources/components/context_menu.html to render the new item visually (resources/components/context_menu.html)

Add a new storage feature (bookmarks, history, etc.)

1. Define the data model struct in the relevant file (e.g., src/bookmark.rs) with Serde traits (src/bookmark.rs)
2. Implement persistence logic in src/storage.rs for CRUD operations (src/storage.rs)
3. Expose API methods in src/verso.rs to access and modify the data (src/verso.rs)
4. Create or update UI components in resources/components/ to display the data (resources/components/bookmark.html)

• Servo (Rust web engine) — Enables safe, modern web rendering without C++ legacy code; goal is to identify what Servo needs for production browser use.
• Rust (systems language) — Memory safety without garbage collection; critical for a browser handling untrusted web content.
• IPC channels (ipc-channel crate) — Multi-process architecture allows rendering to be isolated from the browser UI, improving stability and security.
• Serde + Bincode serialization — Fast binary serialization for IPC messages and persistent storage (bookmarks, config, history).
• Flatpak + native packaging — Distributes Verso on Linux and other platforms with consistent runtime environment.

• Built on Servo instead of Chromium/WebKit

  • Why: Servo is a research project with safety-first design; allows Verso to drive Servo's development toward production readiness.
  • Consequence: Limited web compatibility and performance compared to Chrome/Safari; no longer actively maintained as project is archived.

• Single-process WebView in main UI thread (based on code structure)

  • Why: Simplifies state management and event routing in a small team project.
  • Consequence: Long-running JS or rendering can freeze the UI; scaling to multiple processes would require significant refactoring.

• HTML/CSS/JS resources for UI components (prompts, menus) vs. native widgets

  • Why: Reuses browser rendering engine; allows consistent styling and faster UI iteration.
  • Consequence: Non-native look-and-feel on some platforms; increased memory overhead.

• Persistence via local files (config, bookmarks) rather than encrypted database

  • Why: Minimal dependencies and straightforward implementation for a prototype browser.
  • Consequence: Credentials and sensitive data may be stored in plaintext; no easy sync across devices.

• Not a production-ready browser for general users; explicitly archived and no longer maintained.
• Not designed for mobile platforms (desktop-only with mouse/keyboard input).
• Does not implement multi-process architecture for renderer isolation (simplified single-process model).
• Does not support cross-device sync or cloud backup of bookmarks/history.
• Does not include ad-blocking, password manager, or extensions (out of scope for prototype).

Mako Python templating engine must be installed (pip install mako) before build succeeds—missing this causes cryptic build errors. Servo API is in flux; this repo is pinned to a specific Servo version in Cargo.lock that may not compile with current Servo. Flatpak build requires specific freedesktop SDK version (24.08). ipc-channel requires nightly Rust features in some cases. build.rs uses cfg_aliases but the actual configuration logic is not visible—check for required env vars like CARGO_CFG_* or SERVO_*. MSVC toolchain required on Windows (not MinGW).

• IPC (Inter-Process Communication) — Verso uses ipc-channel to split rendering and UI into separate processes for isolation and stability, a pattern critical to modern browser architecture that you'll encounter throughout the codebase
• Servo Web Engine Architecture — Verso is built entirely around embedding and extending Servo; understanding its layout/painting pipeline, script bindings, and compositor is essential to modifying Verso
• Multi-window / Multi-view Pattern — Verso's explicit design goal is exploring multi-window and multi-view capabilities on top of Servo; this requires careful state management and windowing abstractions unseen in traditional single-window browsers
• Flatpak Sandboxing — The primary packaging model for Linux (org.versotile.verso.yml); understanding Flatpak portals, permissions, and runtime versions is required to build and deploy Verso on Linux
• Workspace-based Monorepo — Verso uses Cargo workspaces (verso, versoview_messages, versoview_build) for code organization; this pattern is critical for understanding dependency flow and build order
• Feature Flags (Conditional Compilation) — Verso uses features like 'bluetooth', 'background_hang_monitor', 'flatpak', 'tracing' to conditionally compile code; understanding feature interactions is crucial for platform-specific development
• Web Components via HTML Resources — Browser UI is implemented as HTML/CSS/JS components in resources/components/ rather than native widgets; this is Verso's experimental approach to 'self-hosting' the browser in Servo itself

• servo/servo — The underlying web rendering engine; Verso depends entirely on Servo's architecture and APIs, so understanding Servo is essential
• mozilla/firefox — Alternative established browser built on Gecko engine; provides reference for multi-process architecture and UI/content separation patterns that Verso explores
• tauri-apps/tauri — Similar approach of embedding a web engine (WebKit/Chromium) in Rust for desktop apps; shares IPC and window management concerns with Verso
• denoland/deno — Rust-based runtime that also packages Chromium/V8 as an embedded engine; demonstrates Rust + web engine embedding patterns and deployment via single binary
• helix-editor/helix — Rust TUI application showing cross-platform terminal UI patterns; useful reference for the clipboard/input handling that Verso does via arboard

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for src/utils/content_disposition_parser.rs

The content_disposition_parser module handles HTTP Content-Disposition headers, which is security-sensitive for download handling. Currently there is no test.rs file, and this utility lacks visible test coverage. Adding tests would catch edge cases in filename parsing, encoding handling, and malformed headers that could cause download issues or security vulnerabilities.

• [ ] Review src/utils/content_disposition_parser.rs for edge cases (RFC 6266 compliance, special characters, encoding)
• [ ] Add test module to src/utils/content_disposition_parser.rs with tests for: valid filenames, UTF-8 encoding, fallback names, and malformed inputs
• [ ] Test integration with src/download.rs to ensure parsed filenames are handled correctly
• [ ] Run cargo test and ensure all tests pass

Add GitHub Actions workflow for Rust clippy linting and format checking

The repo has .github/workflows for build, docs, and release but lacks automated linting. Given this is a complex Rust project with workspace members (verso, versoview_messages, versoview_build), adding clippy and rustfmt checks would catch code quality issues early and enforce consistency across the three workspace crates.

• [ ] Create .github/workflows/lint.yml that runs on push/PR to main and develop branches
• [ ] Configure job to run cargo clippy --all --all-features -- -D warnings for all workspace members
• [ ] Add secondary job for cargo fmt --all -- --check to enforce formatting
• [ ] Test the workflow locally with act or by creating a draft PR
• [ ] Document the linting expectations in .github/CONTRIBUTING.md

Refactor src/utils/mod.rs and create feature-specific utility modules

The src/utils/ directory currently only exports content_disposition_parser.rs, but the codebase has scattered utility logic across src/keyboard.rs, src/touch.rs, and src/storage.rs that could benefit from consolidated helpers. Additionally, the resources/ directory contains multiple parser-like files (gatt_blocklist.txt, hsts_preload.json, public_domains.txt) that lack corresponding Rust parsers in utils. Creating dedicated modules would improve code organization and maintainability.

• [ ] Create src/utils/domain_parser.rs to parse and validate domains from resources/public_domains.txt and resources/hsts_preload.json
• [ ] Create src/utils/input_handler.rs and consolidate keyboard/touch normalization logic from src/keyboard.rs and src/touch.rs
• [ ] Update src/utils/mod.rs to export the new modules and ensure all utilities are documented with examples
• [ ] Add tests for each new utility module following the pattern in content_disposition_parser.rs
• [ ] Update src/lib.rs to use the reorganized utilities instead of duplicated logic

• Add missing unit tests for resources/components/*.html interactive behavior—most UI components lack test coverage (e.g., resources/components/prompt_test.html exists but other prompts have no corresponding tests)
• Document the IPC protocol: create docs/IPC_PROTOCOL.md mapping messages in versoview_messages/ to their handlers and responses, as message flow is undocumented
• Implement missing resource hot-reload for development: add a debug feature flag to watch resources/ directory and live-reload HTML/CSS without recompiling, reducing dev cycle friction

• High · Incomplete Dependency List in Cargo.toml — Cargo.toml - [dependencies] section. The provided Cargo.toml snippet appears truncated (ends mid-dependency at 'env_lo'). This incomplete view prevents full verification of all dependencies against known security advisories. Critical dependencies like 'arboard', 'crossbeam-channel', and others are present but truncated dependency specifications could mask vulnerable versions. Fix: Ensure the complete Cargo.toml is reviewed. Run 'cargo audit' to check for known vulnerabilities in all dependencies. Verify all dependencies have explicit version constraints and are kept up-to-date.
• Medium · Workspace Edition '2024' May Not Exist — Cargo.toml - [workspace.package] edition field. The Cargo.toml specifies edition = '2024', but Rust editions typically follow years when they're released (2015, 2018, 2021). Edition '2024' may not be valid in current Rust toolchains, which could cause build failures or unexpected behavior. This could be a typo for '2021'. Fix: Change edition to a valid Rust edition (2021 is current). Verify with 'cargo check' that the project builds correctly.
• Medium · Overly Permissive Feature Flags — Cargo.toml - [features] default section. The 'default' features include 'bluetooth' and 'background_hang_monitor' without explicit security review notes. These features enable functionality that should be carefully audited for security implications, especially Bluetooth which involves hardware access and external communication. Fix: Review Bluetooth implementation for proper input validation and access controls. Document security assumptions. Consider making these opt-in rather than default. Implement proper permission/capability checks.
• Medium · Third-Party WebIDL Code Inclusion — third_party/WebIDL/ directory. The repository includes third-party WebIDL Python code in 'third_party/WebIDL/' directory. The presence of pycache files and Python bytecode (.cpython-311.pyc, .cpython-312.pyc) suggests this code is executed during the build process. The security of this code and whether it's been audited is unclear. Fix: Verify the upstream source and version of WebIDL code. Review build.rs to understand how this code is used. Remove pycache directories and .pyc files from version control. Document the supply chain source for this dependency.
• Low · Preload Lists and Static Resources — resources/hsts_preload.json, resources/public_domains.txt. HSTS preload list (hsts_preload.json) and public_domains.txt are included as static resources. These lists should be regularly updated to remain effective. Outdated HSTS preload lists could reduce security effectiveness. Fix: Implement a mechanism to periodically update security-critical resources like HSTS preload lists. Consider fetching these from authoritative sources rather than bundling them. Document update frequency.
• Low · Project Maintenance Status — README.md. The README explicitly states 'Verso is currently no longer maintained'. This is a significant security concern as the browser will not receive security patches, bug fixes, or updates to accommodate new web standards and security requirements. Fix: Users should not use this browser in production. Archive the repository to prevent confusion. If revival is planned, implement proper security review process and establish maintenance cadence.
• Low · Missing Input Validation Documentation — src/utils/content_disposition_parser.rs. File 'src/utils/content_disposition_parser.rs' suggests HTTP header parsing. Without reviewing the implementation, there's potential risk of parsing vulnerabilities that could lead to directory traversal or filename injection attacks. Fix: Ensure Content-Disposition header parsing strictly validates and sanitizes values. Review for compliance with RFC 6266. Test with malformed inputs including null bytes, path traversal attempts, and special characters.
• Low · IPC Channel Usage — Cargo.toml - ipc. The codebase uses 'ipc-channel' for inter-process communication (version 0.19). While this is a legitimate dependency, IPC mechanisms are security-sensitive and require careful handling to prevent privilege escalation or message tampering. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.