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/xi-editor/xi-mac 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

• 10 active contributors
• Distributed ownership (top contributor 46% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 5y 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 xi-editor/xi-mac repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/xi-editor/xi-mac.

What it runs against: a local clone of xi-editor/xi-mac — 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 xi-editor/xi-mac | 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 master exists | Catches branch renames | | 4 | Last commit ≤ 1738 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of xi-editor/xi-mac. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/xi-editor/xi-mac.git
#   cd xi-mac
#
# 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 xi-editor/xi-mac and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "xi-editor/xi-mac(\\.git)?\\b" \\
  && ok "origin remote is xi-editor/xi-mac" \\
  || miss "origin remote is not xi-editor/xi-mac (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1738 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1708d)"
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/xi-editor/xi-mac"
  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).

Xi-mac is the macOS native frontend for Xi Editor, a high-performance text editor with a Rust-based backend. It communicates with the xi-editor core (in a git submodule) via RPC to provide a modern, low-latency editing experience with <16ms frame targets and advanced text rendering via macOS Core Text. Split architecture with two entry points: Sources/XiEditor (main Cocoa app with AppDelegate.swift, custom views, and rendering logic) and Sources/XiCLI (thin command-line wrapper). Core editing engine lives in a git submodule (xi-editor/xi-editor) compiled to a Rust binary; frontend communicates via JSON-RPC. Assets (icons, fonts like Inconsolata) bundled in Resources/.

macOS developers and power users who want a modern editor with exceptional performance; also contributors working on Xi Editor's frontend who specifically develop or debug the Cocoa/Swift UI layer.

Early-stage but actively maintained: has CI via Travis, codecov integration, and structured PR/issue templates. However, the README explicitly warns 'this project is still in an early state' with no versioned releases yet. The codebase is substantial (363KB Swift), but the note that 'prebuilt binaries will be made available once we start creating versioned releases' signals pre-1.0 status.

Key risks: (1) Dependency on the xi-editor core submodule—if upstream stalls, this frontend becomes unmaintained; (2) Early-stage nature means APIs and behavior may change; (3) Rust toolchain requirement (rustup/cargo) adds build complexity; (4) Limited test visibility in the file list suggests test coverage may be sparse. No obvious single-maintainer risk given GitHub org structure.

Activity level unclear from file list alone, but the repo has CI configured (.travis.yml) and structured issue/PR templates (.github/), suggesting ongoing maintenance. No recent commit dates visible in the manifest, so check the repo directly for latest activity.

git clone --recurse-submodules https://github.com/xi-editor/xi-mac
cd xi-mac
xcodebuild
open build/Release/XiEditor.app

Or open XiEditor.xcodeproj in Xcode 10.2+ and hit Run. Requires Rust/rustup installed and up-to-date (run rustup update stable if build fails).

Daily commands: From Xcode: Product → Run (⌘R). From CLI: xcodebuild then open build/Release/XiEditor.app. To install system-wide: cp -r build/Release/XiEditor.app /Applications.

• Sources/XiEditor/AppDelegate.swift: Entry point for the macOS app; manages windows, file operations, and coordination with the Rust backend
• Sources/XiCLICore/Xi.swift: Handles JSON-RPC communication and protocol with the xi-editor core backend
• Sources/XiEditor/Annotation.swift: Manages syntax highlighting and text annotations received from the backend
• .gitmodules: Defines the xi-editor core submodule; crucial for build—missing or broken reference breaks compilation
• XiEditor.xcodeproj: Xcode project configuration; defines build targets (XiEditor app, XiCLI tool), Rust integration, and code signing
• Resources/fonts/: Bundled Inconsolata TTF fonts used for editor display; modifying these changes the editor's default font

UI/View logic: Sources/XiEditor/ contains the Cocoa views and controllers—start with AppDelegate.swift for app lifecycle. Text rendering: Look for Core Text usage in view files. RPC/Backend communication: Check Sources/XiCLICore/ (Xi.swift communicates with backend). Annotations (syntax highlighting, etc.): Sources/XiEditor/Annotation.swift. CLI tool: Sources/XiCLI/ if adding command-line features.

Submodule gotcha: Clone must use --recurse-submodules or git submodule update --init --recursive or Rust build will fail (xi-editor core won't exist). Rust version lock: Build requires latest stable Rust (checked via rustup); rustup update stable is often needed before first build. Code signing: Depending on your dev team provisioning, the Xcode project may require code-signing certificate setup to build/run. No obvious build artifacts: xcodebuild outputs to build/Release/, not the standard Xcode DerivedData; clean builds can be slow due to Rust recompilation.

• JSON-RPC 2.0 — Xi-mac communicates with the Rust backend exclusively via JSON-RPC; understanding the protocol is essential to modify or extend backend communication
• CRDT (Conflict-free Replicated Data Type) — The xi-editor core uses rope and CRDT-like data structures for concurrent text editing; understanding this helps predict editing behavior and async semantics
• Core Text (macOS) — Xi-mac uses Core Text for all text rendering and layout; knowing this framework is crucial for modifying font, line spacing, or glyph rendering logic
• Cocoa event loop and responder chain — macOS Cocoa's input handling model determines how keystrokes route to the backend; essential for debugging input lag or keybinding issues
• RPC protocol versioning and async message handling — Xi maintains a versioned RPC protocol; frontend must handle out-of-order responses and notifications; mishandling breaks the editor state
• Submodule-based dependency management — Xi-mac uses git submodules for the backend; this unusual pattern (vs. package managers) means build failures are often submodule-related, not code errors

• xi-editor/xi-editor — The Rust backend core (in this repo's submodule); must understand its RPC protocol to develop frontend features
• xi-editor/xi-win — Sibling frontend for Windows; same backend, different UI framework (C#/WPF); useful for understanding cross-platform RPC patterns
• xi-editor/xi-term — Terminal frontend for xi; helps understand minimal RPC client implementation and headless backend usage
• microsoft/vscode — Similar architecture (extensible editor with language server protocol); alternative approach to high-performance, modular editing
• neovim/neovim — Another Rust+Cocoa editor project on macOS; reference for how to architect native UI + external backend communication

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 unit tests for Core message types (CoreRequest.swift, CoreNotification.swift)

The Sources/XiEditor/Core/ directory contains critical message serialization/deserialization logic for communicating with the Rust backend, but there are no visible test files. These messages are the contract between frontend and backend, making them high-risk for regressions. Adding comprehensive unit tests would improve reliability and serve as documentation for the protocol.

• [ ] Create Tests/XiEditor/Core/CoreRequestTests.swift to test encoding/decoding of CoreRequest messages
• [ ] Create Tests/XiEditor/Core/CoreNotificationTests.swift to test parsing of CoreNotification payloads
• [ ] Add tests for edge cases in DefStyle.swift and FindStatus.swift JSON parsing
• [ ] Update .travis.yml to run these new tests in the CI pipeline

Add integration tests for ClientImplementation.swift <-> Client.swift protocol

The Client.swift and ClientImplementation.swift files implement the core RPC protocol between the macOS UI and xi-core backend. There appear to be no integration tests verifying this bidirectional communication works correctly. This is a critical integration point that could catch protocol breakages early.

• [ ] Create Tests/XiEditor/ClientImplementationTests.swift with mock xi-core backend responses
• [ ] Test the full request-response cycle for key operations (open document, edit, find-replace)
• [ ] Verify error handling when backend returns invalid responses
• [ ] Test concurrent message handling to catch race conditions

Document CLI interface with examples (Sources/XiCLI/main.swift and Sources/XiCLICore/)

The repo includes a CLI component (XiCLI) but there is no CLI documentation in README.md or a dedicated CLI_USAGE.md file. New contributors and users don't know what CLI commands are available or how to use them. This would involve examining the CLI implementation and documenting it properly.

• [ ] Review Sources/XiCLI/main.swift and Sources/XiCLICore/*.swift to identify all available commands and options
• [ ] Create docs/CLI_USAGE.md documenting all CLI commands, arguments, and example usage
• [ ] Add a 'CLI' section to README.md linking to the new documentation
• [ ] Add code examples showing how to invoke xi from the command line

• Add missing unit tests for Sources/XiEditor/Annotation.swift (syntax highlighting logic)—currently no test files visible for this core feature
• Expand keyboard shortcuts documentation: Resources/XiEditor.help/Contents/Resources/en.lproj/pages/KeyboardShortcuts.html is present but may be incomplete; audit actual keybindings in AppDelegate and add any missing entries
• Add localization strings: Resources/XiEditor.help/Contents/Resources/en.lproj/ suggests i18n support exists, but only English present—contribute French or German translations to en.lproj/InfoPlist.strings

The xi-editor Mac frontend demonstrates reasonable security hygiene for a desktop application. The main concerns are: (1) RPC communication security between the macOS frontend and Rust backend requires thorough review for proper validation and encryption; (2) Input handling in search/replace and text processing features should be hardened against injection attacks; (3) Plugin execution model needs clear security boundaries and sandboxing; (4) Missing formal

• Medium · Missing Security Headers in Help Resources — Resources/XiEditor.help/Contents/Resources/en.lproj/*.html. The help resources include HTML files (XiEditor.html, AboutXiEditor.html, KeyboardShortcuts.html) served locally without apparent Content Security Policy or security headers. While this is a local application, if any help system includes remote content loading, XSS vulnerabilities could occur. Fix: Ensure all HTML help files use proper Content Security Policy headers. Validate that no remote content is loaded dynamically without proper sanitization. If using WebView to display help, configure appropriate security policies.
• Medium · RPC Communication Security Not Evident — Sources/XiEditor/RPCSending.swift, Sources/XiEditor/ClientImplementation.swift, Sources/XiEditor/Client.swift. The codebase includes RPC communication (RPCSending.swift, ClientImplementation.swift) with a Rust backend. Security of the RPC channel (encryption, authentication, validation) is not apparent from the file structure and naming conventions. Fix: Review RPC implementation to ensure: 1) All messages are properly serialized/deserialized with type checking, 2) Communication channel uses TLS/encryption if over network, 3) Input validation occurs on all received data from the backend, 4) No serialization vulnerabilities (unsafe deserialization).
• Medium · Potential Unsafe Input Handling in Search/Replace — Sources/XiEditor/Search.swift, Sources/XiEditor/Core/ReplaceStatus.swift. Search and replace functionality (Search.swift, ReplaceStatus.swift) may process untrusted input without sufficient validation. Text editors are common targets for injection attacks through search patterns. Fix: Implement comprehensive input validation for search/replace operations. Escape regex metacharacters appropriately. Validate pattern syntax before passing to backend. Implement size limits on search queries.
• Low · Third-party Font Files Without Integrity Verification — Resources/fonts/Inconsolata-Bold.ttf, Resources/fonts/Inconsolata-Regular.ttf. The project includes third-party font files (Inconsolata-Bold.ttf, Inconsolata-Regular.ttf) bundled without apparent integrity checks or signature verification. Fix: Document the source and version of bundled fonts. Consider implementing checksum verification at runtime. Regularly audit bundled resources for tampering. Document the OFL license compliance in build artifacts.
• Low · Missing Security Considerations Documentation — Root directory (missing SECURITY.md). No visible SECURITY.md file or security policy documented for reporting vulnerabilities. The CODE_OF_CONDUCT.md and CONTRIBUTING.md exist but security guidance is missing. Fix: Create a SECURITY.md file documenting: 1) How to responsibly disclose vulnerabilities, 2) Security considerations for contributors, 3) Known security limitations of the architecture.
• Low · Subprocess/Plugin Execution Risk — Sources/XiEditor/PluginCommand.swift. The presence of PluginCommand.swift and plugin support suggests external plugin execution. Without visible sandboxing or security policies, plugins could pose a privilege escalation or code execution risk. Fix: Document plugin security model. Implement: 1) Plugin signature verification, 2) Capability-based sandboxing if possible, 3) Clear user consent for plugin installation, 4) Plugin permission declarations, 5) Regular security audits of default plugins.
• Low · Insufficient Error Handling Transparency — Sources/XiCLICore/RuntimeError.swift. RuntimeError.swift exists but error handling patterns across the codebase are not transparent from filenames. Verbose error messages could leak system information. Fix: Review error messages to ensure they don't leak sensitive information (paths, system details, backend internals). Implement proper error logging that distinguishes between user-facing messages and debug information.

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.