CkEditor

An AI-first IDE. Rust + egui, native, keyboard-first.

Vim keybindings, LSP, project-wide search, git worktree / branch-context workflows, terminal, filesystem coherence, and AI assistance — built around the principle that every unit of work is a Context (a worktree forked from a protected root branch), and the UI is a reflection of state that Project owns.

Status

The Context-model foundation has landed. Active work:

• Context lifecycle refactor — consolidating Context lifecycle onto Project as a closed API, removing ContextKind::MainCheckout, introducing a user-set root_branch. Load-bearing; the Context feature is not done.
• AI integration — per-Context MCP bus and editor-state tools. PR 3 landed; later PRs in flight.
• Files layer — three-layer I/O and watcher. The ck-files crate is sealed (the pilot for the extraction roadmap).

Priority order: functionality → real end-to-end testing → hardening.

Documentation

All design docs live under docs/:

• docs/architecture/ — landed and in-flight subsystems: Context model, files layer, AI integration.
• docs/roadmap/ — plans: lifecycle refactor, crate extraction, future tools (ck-arch, ck-typeset), deferred quality hardening.
• docs/features/ — feature designs (ck-notes), AI-integration next-steps pointer, parked design records.

Project rules — architecture linter, sealing contract, commit workflow, baseline policy — live in CLAUDE.md.

Where to start reading

If you are new to this codebase, in order:

1. CLAUDE.md — domain vocabulary, crate structure, the Project / Context reference, sealing contract, commit workflow.
2. docs/architecture/ckeditor-context-model.md — the foundation. Every other piece depends on this.
3. docs/roadmap/ckeditor-project-lifecycle.md — what is changing about Context next, and why.
4. docs/architecture/ckeditor-files.md — how reads and writes flow. Prerequisite for AI integration.
5. docs/architecture/ckeditor-ai-integration.md — per-Context MCP bus, no ghost-patch layer.

Crates

Crate	Purpose
ckeditor	Main application, UI layout, panels
ck-editor	Buffer, cursor, vim, syntax highlighting
ck-files	Unified source-file I/O primitives + filesystem watcher (sealed pilot)
ck-lsp	LSP client (transport, protocol, server management)
ck-types	Shared types (LSP positions, ranges, text edits)
ck-ui	Reusable egui components
ck-terminal	Terminal emulator integration
ck-mcp-editor	MCP server exposing editor state to AI agents
ck-notes	Notes / workflow data model (in flight)
ck-testing-e2e	End-to-end test harness
ckeditor-lint	Architecture linter and metric ratchet

Build, run, test

Use the scripts under scripts/:

• scripts/run.sh — run the editor
• scripts/lint.sh — architecture linter (zero errors, zero warnings)
• scripts/test.sh --gates — full validation (lint + e2e + workspace tests)
• scripts/ratchet.sh — lock in metric improvements

Commit via /ck-commit (runs all gates + ratchets the baseline + merges into master with --no-ff).

Scope discipline

"AI-first IDE" is the positioning, not a license to bolt on every IDE feature. Out of scope by default: GUI debugger menus, mouse-driven refactor wizards, visual designers, anything that breaks the keyboard-first flow. When in doubt: does it serve the AI-assisted, keyboard-driven reading / navigating / editing loop, or is it IDE-feature-parity for its own sake?