One ships project-aware integrations for VS Code and Zed. Both are thin clients
over one lsp and the same versioned lifecycle commands used by the CLI; an
editor never becomes another project model or source of semantic truth.
Open the project, not an isolated file
Open the directory containing one.one, keep the verified one installation
on PATH, and let the editor discover the nearest explicit project boundary.
The language client starts:
one lsp --workspace <project-root>VS Code may set one.cli.path to the selected One executable. Its separate
one.lsp.path setting is only for a dedicated syntax-server fallback; leaving
it empty keeps project resolution, embedded implementation tooling, and exact
lock evidence available through the CLI-hosted server. Zed likewise launches
one lsp over standard input and output.
Snapshot-bound features
Completion, hover, diagnostics, formatting, semantic tokens, references, and
definition navigation are bound to the open source revision, nearest
one.one, selected root, and exact one.lock. They do not query a newer
registry or infer an implementation language from body text.
- Completion is a bounded query over the current syntactic role, explicit imports, the selected lock, and the applicable owner or profile contract; a chosen candidate writes canonical qualified source, and resolution then decides whether the reference is valid.
- Hover, semantic tokens, and references describe the current normalized owner value, its proof path, and every in-scope reference without presenting an older value as current.
- Diagnostics label their boundary: lossless syntax, strict envelope and System IDL acceptance, semantic-owner validation, implementation-language analysis, or a later owner stage.
- Definition navigation is the go-to-definition path described below.
The snapshot binds tooling to authored source and meaning; it never accepts a newer lock or an untouched sibling edit on faith. Diagnostic shapes and exit outcomes follow the shared diagnostics contract.
An implementation body receives language-specific highlighting and analysis
only after its exact using profile and locked tooling admission match the
current claim. Rust and TypeScript public boundaries compose with their native
language tooling instead of fabricating .one definitions for private code.
Definition navigation and virtual documents
Go to definition follows authored names into their canonical owner contracts,
package exports, language rules, normalizers, implementation claims, generated
SDK source maps, plans, artifacts, grants, receipts, and evidence. Meaning that
has no literal project file opens as a read-only virtual document under
.one/vfs/; those documents are disposable projections, never editable source
of truth. Navigation may select a candidate edit range, but only reparsing the
complete affected input and revalidating the exact owner dependencies can
propose a source change.
Edit malformed source honestly
The lossless parser keeps incomplete or malformed bytes as the current authored state. Intact local references may still navigate, but the editor never shows an older valid normalized value as though it described newer invalid text. Fix the reported source error, save, and let the exact project check refresh the semantic projection.
Formatting applies only after strict envelope acceptance. It canonicalizes System IDL presentation while preserving implementation-body bytes until that body's selected profile formatter is separately admitted.
Use structured projections safely
VS Code can reopen a supported item as a synchronized form, table, graph, or combined view. An edit proposes a bounded patch against the exact source revision, reparses every affected input, reruns the required owner checks, and commits one ordinary undoable workspace edit only if the base revisions still match. If current source cannot be represented faithfully, the projection becomes read-only and the lossless source view remains available.
Lifecycle tasks, the One sidebar, MCP discovery, terminal TUI, and shell all
call the same public operations. A cached badge or editor output filename is
never lifecycle evidence; restore work from an exact plan: or operation:
reference with ordinary one inspect.
Editor, TUI, and daemon parity
The One sidebar, lifecycle tasks, One TUI, One Shell, MCP clients, and CI all drive the same versioned operations; an editor never acquires a separate project model or authority. The optional local daemon may accelerate repeated project work, but it is revision-bound and disposable: it never becomes a second project source, cache authority, or grant source. Losing the daemon, the editor, or the TUI leaves the canonical source and exact lock unchanged.
Honest limits
- Owner-aware features require the exact locked semantic package and profile. When either is unavailable, tooling returns typed unsupported output instead of guessed behavior.
- There is no cross-item "open declaration" and no generated Rust declaration SDK; duplicate or partial definitions fail with all source locations.
- Incomplete or malformed bytes remain the current authored state. Tooling never presents an older valid normalized value as though it described the newer bytes.
- Formatting canonicalizes System IDL presentation only after strict envelope acceptance, and preserves unknown implementation-body bytes until that body's profile formatter is separately admitted.
- Rowan syntax nodes, source ranges, and indexes locate bytes and propose patches; they never establish identity, acceptance, contract compatibility, selection, or authority. The accepted source language and exact lock remain authoritative.
Executable evidence
The acme-editor fixture
is the canonical external-editor project acceptance input, entering through
one.one, exact publications, one.lock, CAS-backed component evidence, and
the language server. one-lsp owns the current transcript tests for
completion, navigation, diagnostics, and revision-checked source transactions:
cargo test -p one-lsp