You're writing a 0sh script that will run inside a CellOS cell. The cell's authority contract is at the top of the file: env vars allowed, network scope, filesystem paths. You open the file in Vim. You add a function that makes a network call. You save. Nothing happens. No warning. No indicator that the network call you just wrote isn't in the cell's declared network scope. You find out at runtime, when the cell refuses to launch.
The editor is completely blind to the execution model around it. It's editing text that happens to be a script. It doesn't know what a cell is.
What general editors miss
Vim, Helix, nano — they edit files. They do it well. But they have no concept of a CellOS authority contract, a 0sh declaration scope, or what tsafe exec boundaries exist in the execution context. You can add LSP extensions to any of them, but an LSP that understands this stack — that knows what env vars are in scope for this cell, what network calls are allowed, what tsafe keys are injectable here — doesn't exist and would need to be purpose-built from scratch.
The gap isn't the editing experience. It's that the editor knows nothing about the program's execution context. You're writing blindly against a model the editor can't see.
tedit: editor as ecosystem peer
tedit is a terminal editor built specifically for this stack. Two modes: nano-style for keyboard-first minimal editing, and a TUI layout with split panes and a file tree for larger sessions. The differentiation isn't the editing mechanics — it's what the editor understands.
When you open a 0sh script inside a cell, tedit knows the cell's authority contract. If you reference an env var that isn't declared, it flags it inline before you run anything. If you add a network call to a domain that's outside the cell's allowed scope, you see it in the editor. If you're working with a tsafe exec boundary, it can show you which keys are injectable in this context.
tedit is in early development alongside the rest of the stack. The design is in progress. The core principle is fixed: an editor that doesn't understand the execution model is just a faster way to make the same mistakes.
What this is part of
tedit isn't standalone tooling. It's the editing surface for a stack where the execution model is explicit: CellOS cells with declared authority, 0sh scripts with scoped variables, tsafe exec boundaries for credentials. An editor that can't see that model is a liability in that stack. tedit is being built to be a peer to the model, not blind to it.