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/atom-archive/xray 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

• 3 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 7y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 89% of recent commits

_{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 atom-archive/xray repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/atom-archive/xray.

What it runs against: a local clone of atom-archive/xray — 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 atom-archive/xray | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2511 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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"

# 4. Critical files exist
test -f "memo_core/src/lib.rs" \\
  && ok "memo_core/src/lib.rs" \\
  || miss "missing critical file: memo_core/src/lib.rs"
test -f "memo_core/src/buffer.rs" \\
  && ok "memo_core/src/buffer.rs" \\
  || miss "missing critical file: memo_core/src/buffer.rs"
test -f "xray_core/src/app.rs" \\
  && ok "xray_core/src/app.rs" \\
  || miss "missing critical file: xray_core/src/app.rs"
test -f "memo_core/src/operation_queue.rs" \\
  && ok "memo_core/src/operation_queue.rs" \\
  || miss "missing critical file: memo_core/src/operation_queue.rs"
test -f "memo_core/src/serialization/schema.fbs" \\
  && ok "memo_core/src/serialization/schema.fbs" \\
  || miss "missing critical file: memo_core/src/serialization/schema.fbs"

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

Xray is an experimental Electron-based text editor built around Memo, an operation-based version control system that tracks changes at keystroke granularity and synchronizes branches in real time via CRDT semantics. It's designed from first principles for collaborative coding, with a Rust-based core (memo_core) handling buffer operations, epochs, and work trees, exposed to JavaScript clients via FFI bindings (memo_js). Monorepo (Cargo.toml workspace) with six crates: memo_core (Rust, buffer + epoch + CRDT logic), memo_js (Node bindings), xray_core/xray_server/xray_cli/xray_wasm (higher-level integrations). Core state lives in memo_core/src/{buffer.rs, epoch.rs, operation_queue.rs, work_tree.rs}; serialization via Flatbuffers schema; architectural patterns documented in docs/architecture/00X_*.md.

Atom maintainers and experimental Electron developers exploring next-generation collaborative editor architectures; teams interested in real-time co-editing without traditional lock-based VCS overhead. Not for end-users—this is explicitly archived research.

Archived experimental project (GitHub did not move forward). Last documented work: October 2, 2018. Rust-heavy codebase (861KB) with CI via Travis, structured docs in docs/architecture/, but no visible active development or release cycle. Status: research artifact, not production-ready.

Archived upstream means no security updates or maintenance; heavy Rust/FFI boundary (memo_core ↔ memo_js) introduces marshalling complexity and potential ABI brittleness. No visible test suite in top-level structure. Flatbuffers serialization schema (memo_core/src/serialization/schema.fbs) is the critical path but tightly coupled to epoch/operation logic. Single workspace owner (Atom/GitHub) with no active issue triage.

Nothing—project is archived. Last update doc is October 2, 2018 (docs/updates/2018_10_02.md). Work was focused on Memo sub-project maturity: operation queuing, epoch tracking, and real-time branch synchronization semantics. README explicitly states GitHub decided not to move forward.

git clone https://github.com/atom/xray.git && cd xray && cargo build (Rust workspace). Node dependencies under memo_js require nvm (see memo_js/.nvmrc for version pinning). Flatbuffers schema compilation via memo_core/script/compile_flatbuffers before running tests.

Daily commands: cd memo_core && cargo build; cd ../memo_js && npm install && npm run build (requires Node version from .nvmrc). No visible top-level dev server script; project is modular and archived before UI completion.

• memo_core/src/lib.rs — Core CRDT and operation-based versioning system; the foundation for all text synchronization and conflict resolution.
• memo_core/src/buffer.rs — Buffer management and text state representation; essential for understanding how edits are tracked and merged.
• xray_core/src/app.rs — Main application orchestration layer that coordinates editor state, file I/O, and protocol communication.
• memo_core/src/operation_queue.rs — Operation sequencing and epoch management; critical for understanding order-independent change tracking.
• memo_core/src/serialization/schema.fbs — FlatBuffers schema defining the wire protocol; required to understand client-server communication format.
• memo_js/src/lib.rs — WebAssembly bindings to memo_core; bridge between JavaScript frontend and Rust backend for real-time sync.

Add a new text editing operation

1. Define the operation variant in the operation enum (likely in memo_core/src/lib.rs or buffer.rs) (memo_core/src/buffer.rs)
2. Implement the operation application logic that mutates the buffer state (memo_core/src/buffer.rs)
3. Add serialization support in the FlatBuffers schema (memo_core/src/serialization/schema.fbs)
4. Expose the operation via JavaScript bindings in memo_js/src/lib.rs (memo_js/src/lib.rs)
5. Wire the operation from UI events (client-side) to the operation buffer (xray_browser/src/client.js)

Add a new UI feature or command

1. Define the command handler in the app state machine (xray_core/src/app.rs)
2. Add UI elements and event listeners (HTML/CSS/JavaScript) (xray_browser/src/ui.js)
3. Connect UI events to commands via the client message protocol (xray_browser/src/client.js)
4. If needed, extend the buffer or view logic to support the feature (xray_core/src/buffer_view.rs)

Support a new file type or project structure

1. Extend work tree parsing if needed (multi-file representation) (memo_core/src/work_tree.rs)
2. Add file system traversal or filtering logic (xray_core/src/fs.rs)
3. Update the file finder or project initialization (xray_core/src/file_finder.rs)
4. Update the project structure management (xray_core/src/project.rs)

• Rust + memo_core CRDT — Performance-critical conflict-free replication system; Rust provides memory safety and speed for operation composition and causal ordering at keystroke scale.
• Electron + Web UI — Cross-platform desktop editor with familiar web technologies; allows rapid UI iteration while leveraging Rust backend for core logic.
• WebAssembly (wasm-bindgen) — Exposes high-performance Rust CRDT to JavaScript without serialization overhead; memo_js bridges browser and memo_core seamlessly.
• FlatBuffers serialization — Efficient, schema-driven binary protocol for low-latency client-server communication; supports real-time collaborative sync without parsing overhead.
• Epochs for causal ordering — Replaces vector clocks with lighter-weight epoch metadata; ensures operations converge to the same final state regardless of merge order or network delays.

• Operation-based CRDT vs. state-based CRDT

  • Why: Xray/Memo tracks changes at keystroke granularity to enable undo/redo, branching, and real-time collaboration with fine-grained conflict resolution.
  • Consequence: Higher memory and computation overhead per operation, but richer history and merge semantics; enables per-keystroke synchronization rather than snapshot-only.

• Electron + HTML/CSS/JS UI rather than native platform UI

  • Why: Enables single codebase for Windows/Mac/Linux and rapid prototyping; leverages web ecosystem for styling and layout.
  • Consequence: Larger bundle size and slightly higher memory footprint than native; dependency on Electron versioning and security updates.

• Epochs instead of vector clocks or CRDT counters

  • Why: Simpler, more efficient causality tracking for local editing workflows; epoch advances are coarse-grained (per keystroke batch or flush).
  • Consequence: Weaker causality information than full vector clocks; requires careful epoch advance semantics but faster merge computation.

• FlatBuffers over Protocol Buffers or MessagePack

  • Why: Zero-copy deserialization and schema evolution; no allocation overhead for network messages.
  • Consequence: Schema-first design; schema.fbs must be manually updated and regenerated; less human-readable than JSON.

• Real-time server-based collaboration (Memo is local-first; multi-client sync is experimental).
• Full LSP or language-server integration (editor targets code and prose equally; language tooling deferred).
• Plugin system or package manager (xray is a testbed, not a production extension platform).
• Guaranteed persistence or crash recovery (xray_core is in-memory; durability is delegated to filesystem).
• Cross-editor interoperability (Memo format is Xray-specific; not a universal version-control format).

Flatbuffers schema compilation (memo_core/script/compile_flatbuffers) must run before Rust build; no auto-invocation visible. Node version pinned in memo_js/.nvmrc (likely old, e.g., v10–v12 era given 2018 dates). FFI boundary between Rust and JavaScript likely requires specific build order (memo_core before memo_js). No Makefile or cargo-xtask; build process is implicit. Archived status means Electron version, dependencies, and Rust editions are obsolete; will not compile on modern systems without significant patching.

• CRDT (Conflict-free Replicated Data Type) — Memo's core data structure for decentralized synchronization; understanding CRDTs is essential to grasp why Memo avoids traditional locking and how concurrent edits merge without coordination
• Operational Transformation (OT) — Competing approach to CRDT for real-time co-editing; Memo chose CRDTs but understanding OT trade-offs (causality, ordering) clarifies design decisions
• Flatbuffers Serialization — Wire format for all buffer/epoch state (memo_core/src/serialization/schema.fbs); understanding schema evolution is critical for backwards compatibility and debugging client-server mismatches
• FFI (Foreign Function Interface) — Xray bridges Rust (memo_core) and JavaScript (memo_js) via Node FFI bindings; understanding ABI stability and type marshalling is essential for modifying either layer without crashes
• B-tree (Work Tree Index) — memo_core/src/btree.rs implements range-queryable index for file operations and path lookups; critical for O(log n) workspace scans without loading all files into memory

• atom/atom — Xray is the spiritual successor to Atom; shares editor philosophy but attempts radical redesign around CRDT and collaboration
• codesync/codesync — Modern real-time collaborative editor; addresses same problem (live co-editing) that Memo/Xray pioneered but after project was archived
• yjs/yjs — Production CRDT implementation for shared state; directly comparable to Memo's epoch-based approach for conflict-free replication
• xi-editor/xi-core — Concurrent Rust-based text editor engine (2016–2018 era); similar architectural era and performance focus to Xray
• rust-lang/rust-clippy — Not directly related but Xray heavy Rust codebase likely benefited from Clippy; useful for understanding Rust idioms in archived project

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 memo_core buffer and CRDT operations

The memo_core package is foundational to Xray but has no visible test files in memo_core/src/. Given the complexity of CRDT logic (evidenced by docs/architecture/003_memo_epochs.md and docs/architecture/002_shared_workspaces.md), adding comprehensive tests for buffer.rs, epoch.rs, and operation_queue.rs would prevent regressions and improve confidence in the core data structure implementations.

• [ ] Create memo_core/src/tests/ directory structure
• [ ] Add unit tests in memo_core/src/buffer.rs for insert/delete operations across different buffer states
• [ ] Add unit tests in memo_core/src/epoch.rs validating epoch ordering and causality tracking
• [ ] Add unit tests in memo_core/src/operation_queue.rs for queue ordering and conflict resolution
• [ ] Verify tests run via 'cargo test' in the memo_core workspace

Complete and document the truncated README.md for memo_core

The root README.md cuts off mid-sentence at 'Memo](./memo_core), which will serve as the foundation of Xray but also be available as a standal'. More critically, memo_core/README.md exists but likely lacks documentation of the FlatBuffers schema (memo_core/src/serialization/schema.fbs) and the relationship between key modules (btree.rs, work_tree.rs, operation_queue.rs). New contributors cannot understand the architecture without this.

• [ ] Complete the truncated sentence in root README.md's Q3 2018 Focus section
• [ ] Expand memo_core/README.md with architecture overview referencing btree.rs and work_tree.rs
• [ ] Document the FlatBuffers schema format and serialization strategy in memo_core/README.md
• [ ] Add a module dependency diagram or reference to docs/architecture/003_memo_epochs.md
• [ ] Include a quick-start example for using memo_core as a library

Add integration test suite for memo_js TypeScript bindings

memo_js bridges Rust (memo_core) and JavaScript/TypeScript, but memo_js/test/tests.ts appears minimal with no visible test output configuration. The webpack.config.js and TypeScript setup suggest tests may not be running in CI (evidenced by .travis.yml likely not covering JS tests). Adding proper test coverage ensures the WASM bindings expose memo_core APIs correctly and prevents breakage between Rust and JS layers.

• [ ] Expand memo_js/test/tests.ts with test cases for buffer creation, insert, delete, and query operations
• [ ] Configure jest or mocha in memo_js/package.json for proper test runner integration
• [ ] Add npm test script to memo_js/package.json that builds WASM and runs TypeScript tests
• [ ] Update .travis.yml to include 'cd memo_js && npm test' step after building WASM
• [ ] Document test execution in memo_js/README.md for contributors

• Add unit tests to memo_core/src/buffer.rs covering CRDT conflict resolution; file has no visible test module despite being safety-critical.
• Document the epoch advancement protocol in docs/architecture/003_memo_epochs.md with concrete pseudocode examples (currently high-level; implementers lack step-by-step guidance).
• Create a memo_core/examples/ directory with a standalone Rust binary that demonstrates buffer creation, operations, and serialization without FFI (useful for testing core logic in isolation).

This is an archived, unmaintained project from 2018 with significant security concerns. The primary risks stem from: (1) Complete lack of maintenance and security updates, (2) Extremely outdated dependencies with known vulnerabilities, (3) Old Rust toolchain with potential compiler-level vulnerabilities, and (4) Custom protocol implementations that may not have undergone security review. This codebase should NOT be used in production environments. If functionality is needed, consider using actively maintained alternatives or conducting a comprehensive security audit and dependency update before any deployment.

• Medium · Archived Project with No Active Maintenance — Repository root / README.md. The repository is explicitly archived and no longer actively maintained by GitHub/Atom team. This means security vulnerabilities discovered in dependencies will not be patched, and the codebase may contain unmitigated security issues. Fix: Do not use this project in production. If you need similar functionality, consider using actively maintained alternatives or forking and maintaining your own version with regular security updates.
• High · Outdated Rust Toolchain — rust-toolchain. The project references a rust-toolchain file (likely pinned to an old version from 2018). Rust compiler versions from 2018 may contain known security vulnerabilities in the standard library and compiler itself. Fix: Update to the latest stable Rust version and regenerate the rust-toolchain file. Run 'rustup update' and test thoroughly.
• High · Outdated Dependencies — Cargo.lock, Cargo.toml (all workspace members). The Cargo.lock file and dependencies are from 2018 (based on documentation dates through October 2018). Dependencies from that era likely contain known CVEs that have been patched in subsequent versions. Fix: Audit all dependencies using 'cargo audit'. Update to latest compatible versions and resolve any security advisories before deployment.
• Medium · FlatBuffers Schema Generated Code — memo_core/src/serialization/schema_generated.rs. The file 'memo_core/src/serialization/schema_generated.rs' appears to be auto-generated from FlatBuffers schema. Generated code is typically not reviewed and may contain security issues. Additionally, the generator and schema version are unknown. Fix: Review the FlatBuffers schema definition (schema.fbs) for security implications. Ensure the FlatBuffers compiler is up-to-date and re-generate if updating.
• Medium · Network Protocol Implementation — xray_server, xray_core, memo_core. The project implements a custom client-server protocol (documented in docs/architecture/001_client_server_protocol.md). Custom cryptographic or authentication implementations may contain flaws if not professionally audited. Fix: Conduct security code review of authentication and encryption mechanisms. Use established libraries (e.g., rustls, ring) rather than custom implementations. Have protocol reviewed by security experts.
• Medium · Electron-Based Application Surface — xray_browser, electron configuration. As an Electron-based text editor, the application inherits Electron security considerations including Node.js context exposure and IPC message handling. Outdated Electron versions from 2018 likely contain known vulnerabilities. Fix: Document exact Electron version if in use. Review Electron security guidelines. Ensure proper context isolation and disable node integration where possible.
• Low · WebAssembly Module Usage — xray_wasm. The xray_wasm workspace member suggests WebAssembly usage. WASM modules from 2018 may have outdated dependencies or unpatched vulnerabilities in the wasm-bindgen or wasm toolchain. Fix: Audit the WASM build toolchain and dependencies. Validate that wasm-bindgen and related tools are from secure versions.
• Low · Incomplete Documentation Visibility — Hidden files throughout repository. File structure shows partial visibility. Hidden files or configurations (e.g., .env, .aws, .git/config) may contain secrets or misconfigurations not visible in the provided listing. Fix: Ensure .gitignore properly excludes secrets, credentials, and sensitive configuration files. Scan repository history for accidentally committed secrets using 'git-secrets' or similar tools.

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.