Repository navigation
Environment contract: honor the repo's existing env spec when provisioning worktrees #396
Description
From the reproducible-environments research: read the repo's existing environment spec (devcontainer.json, copilot-setup-steps.yml, Dockerfile, .flox/) and use it to provision each worktree's run environment; a Solenta-native environment block (setup script, pinned tool versions, env vars vs secrets) only when none exists. Setup output is logged, cached across threads, and edits to the setup spec are approval-worthy (supply-chain surface). Unifies #153 and #188 under established standards.
Activity
currentbits commentedon Aug 18, 2026
Research note (Kimi Work privacy scare, Aug 2026): their feedback report silently attached the user's 5 latest sessions, no disclosure. The rule for the bug-report export: disclose EXACTLY what is included before sending, redact by default, and make raw transcript inclusion an explicit opt-in.
currentbits commentedon Aug 18, 2026
Round 29 intel: intentic's environment model is "the machine is an image you approve": the agent proposes the environment (a Dockerfile describing its toolchain), the human approves it, and that approved image is what the sandbox runs. This is the missing approval gate for the environment contract: agent-proposed, human-approved, then frozen. Also worth noting from their Extension API: extension code installs require a full 40-character commit SHA, not a branch, so "the code you approved is the code that runs." Same rule should apply to any repo-pinned env setup Solenta honors (#153 setup scripts): pin or hash what was approved, and re-ask when it changes.
currentbits commentedon Oct 24, 2026
PR #1709 makes new worktrees run the setup and pick up the env from devcontainer.json / copilot-setup-steps.yml when neither project settings nor solenta.json define a setup. It all goes through solenta.json's approval hash, so an edit to the spec re-prompts. Still open after it: Dockerfile and .flox/ environments (they need a container runtime or
flox activate), reusing setup across threads, and an approval button for specs that have env vars but no setup command. Those are suggested as follow-up threads.New worktrees reuse the main checkout's node_modules when the lockfil…
currentbits commentedon Oct 24, 2026
Setup caching landed in #1711 (0c9a963). On macOS, a new worktree whose lockfile matches the main checkout's starts with a
cp -Rcclone of its node_modules, then setup runs (a near no-op fornpm install/pnpm install;npm cigains nothing). It logs[setup] reused …, falls back to a normal setup on any miss or error, and can be turned off per project ("Reuse node_modules from the main checkout").currentbits commentedon Oct 24, 2026
Landed from Solenta thread "Fork: Environment contract: honor the repo's existing env sp" (PR #1711). Closed on merge.
Provision worktrees from the repo's devcontainer.json or copilot-setu…