docs: name environment files interface and explain ripgrep seam

This commit is contained in:
Kit Langton
2026-08-05 17:54:49 -04:00
parent 56405af7d6
commit e1b863dcb3
+9 -4
View File
@@ -73,18 +73,23 @@ export interface Interface {
Reuses the interface proven on `origin/remote-workspaces-plan` (`fd92aeac66`) nearly verbatim — a local implementation already exists there and the Location graph already composes over it:
```ts
// packages/core/src/workspace/environment.ts
export * as WorkspaceEnvironment from "./environment"
export interface Interface {
readonly platform: NodeJS.Platform
readonly directory: string // the Workspace root, absolute in the provider filesystem
readonly files: FileBackend // read / resolve / list / write / writeIfUnchanged / remove ...
readonly files: Files // read / resolve / list / write / writeIfUnchanged / remove ...
readonly process: ChildProcessSpawner["Service"]
readonly shell: Shell
readonly ripgrep: Effect.Effect<string, Error>
readonly shell: Shell // executable + args lowering for the bash tool
readonly ripgrep: Effect.Effect<string, Error> // path to rg INSIDE this environment
}
```
- Naming follows the core convention: consumers reference `WorkspaceEnvironment.Service` (tag) and `WorkspaceEnvironment.Interface` (shape). `Files` (the branch called it `FileBackend`) and `Shell` nest in the same namespace since they exist only as environment fields. `ChildProcessSpawner["Service"]` is indexed access because effect's key holds its shape as a phantom member — there is no `.Service` type on it.
- `files` earns its place next to `process`: Modal and Vercel both expose direct filesystem APIs that are dramatically faster than round-tripping `cat` through a shell, and read/write/edit are the hottest operations.
- `shell` and `ripgrep` stay required at the seam but core exports Linux defaults, so a minimal driver satisfies them in one line each and is otherwise `create`/`connect`/`destroy` + files + spawn.
- `ripgrep` exists because glob/grep shell out to an rg binary. Locally `RipgrepBinary.Service` downloads a pinned rg into managed host storage; that path is meaningless inside a sandbox, so the environment answers "where is rg in here" — lazily locating or installing on first use if needed.
- `shell` and `ripgrep` stay required at the seam but core exports Linux defaults (bash lowering; rg baked into the image and found on PATH), so a minimal driver satisfies them in one line each and is otherwise `create`/`connect`/`destroy` + files + spawn.
- Core builds tools (bash, read, edit, glob, grep) *on top of* the environment. Drivers never know what a tool is.
## Persistence