@vibest/cli 0.0.1-beta.11 → 0.0.1-beta.13

package/harnesses/claude/.claude-plugin/plugin.json

@@ -6,5 +6,5 @@
   },
   "repository": "https://github.com/iamdin/orchestrate-my-agent-cli",
   "license": "MIT",
-  "version": "0.0.1-beta.11"
+  "version": "0.0.1-beta.13"
 }

package/harnesses/claude/skills/delegate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: delegate
-description: Hand work to subagents with `vibest run` and keep talking with the user while they work. Only vibest's main Agent (the coordinator) starts agents; a subagent must not use this skill. Use for any request to change, fix, build, investigate, research, test or verify code ("fix this bug", "add X", "look into why Y", "do these three things", "have an agent check it"), and whenever a task splits into independent parts that can run at the same time.
+description: Hand work to subagents with `vibest run` and keep talking with the user while they work. Only vibest's main agent (the coordinator) starts agents; a subagent must not use this skill. Use for any request to change, fix, build, investigate, research, test or verify code ("fix this bug", "add X", "look into why Y", "do these three things", "have an agent check it"), and whenever a task splits into independent parts that can run at the same time.
 ---
 
 # Delegate
@@ -12,19 +12,19 @@ You direct subagents. You stay with the user. Each result arrives in your inbox
 Split independent pieces. Research and review run in parallel. One writing subagent per set of files. A few shell reads (`git diff`, `rg`) you do yourself.
 
 ```
-vibest run <harness> --access write -- '<self-contained task>'
+vibest run <harness> -- '<self-contained task>'
 ```
 
 Its id is <id>.
 
 ```
-vibest run <harness> --access read --archive-on-completion -- '<task>'
+vibest run <harness> --archive-on-completion -- '<task>'
 ```
 
 `--archive-on-completion` is only for a session you will not message again after it completes. It archives once the session reports completed and that result has reached you. The branch is kept. Do not `vibest send` it after that. A `needs_input` or `failed` result has not archived it: send the answer to the id it printed; the flag still archives the completed result that follows. A reviewer that gets later rounds is the pipeline skill and must stay open, without this flag.
 
 - `<harness>` is `pi`, `claude` or `cursor` (`auto` only when a spawn plugin chooses).
-- `--access write` (the default) starts a new worktree. `--access read` stays in the project directory, read-only, with no new worktree.
+- Each session gets its own new worktree.
 - Several `vibest run` commands in one message start in parallel.
 - A subagent cannot see this conversation. Say what to achieve, where (paths, lines), what done means, and how to verify it. For code: run the tests and typecheck, commit, and report the branch and hash.
 - Long material: `vibest project write scratch <name>.md --if-version new -- '<text>'`. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch <name>.md`, then write again with the version it prints, or pick a new file name.
@@ -36,7 +36,7 @@ Tell the user in one or two lines what is running, then end your turn. Never gue
 
 ## Check the result
 
-An `<agent-result>` is a claim. For a session started with `--access write`, before you report success read `git -C <worktree> diff main...HEAD` and run the proving check in that worktree. A session started with `--access read` has no worktree; the result's worktree path is the project directory. Judge the report text. Do not treat `git diff main...HEAD` there as the subagent's work.
+An `<agent-result>` is a claim. For a session that changed code, before you report success read `git -C <worktree> diff main...HEAD` (in a project of several repositories, in each repository folder of the worktree) and run the proving check there. For research, judge the report text.
 
 - `status: needs_input` → `vibest send <id> -- '<the answer>'`, or ask the user. If it is waiting for the user's approval of an action, do not send the approval back: start a fresh agent with the approved action, quoting the user's words.
 - `status: failed`, or your check fails → `vibest send <id> -- '<the failure and what to fix>'`. It keeps its context. If a second correction fails, start a new `vibest run` or tell the user.

package/harnesses/claude/skills/pipeline/SKILL.md

@@ -1,19 +1,19 @@
 ---
 name: pipeline
-description: Plan, implement, review, then open a pull request, with the user approving the plan first. Only vibest's main Agent (the coordinator) starts agents; a subagent must not use this skill. Use when the user wants a plan or design before code, a review before merging, or a pull request at the end ("plan it first, then build it", "write a design, then implement", "implement it and have someone review it", "先出方案再写，写完找人 review 后提 PR", "do it as a pipeline", "/pipeline").
+description: Plan, implement, review, then open a pull request, with the user approving the plan first. Only vibest's main agent (the coordinator) starts agents; a subagent must not use this skill. Use when the user wants a plan or design before code, a review before merging, or a pull request at the end ("plan it first, then build it", "write a design, then implement", "implement it and have someone review it", "先出方案再写，写完找人 review 后提 PR", "do it as a pipeline", "/pipeline").
 ---
 
 # Pipeline
 
-Plan (read) → the user agrees → implement (write) → review until the reviewer approves → pull request. Follow delegate: do not poll; each result arrives by itself; check it yourself. The user stays in the loop and may step into any pane. What they say overrides the next step.
+Plan → the user agrees → implement → review until the reviewer approves → pull request. Follow delegate: do not poll; each result arrives by itself; check it yourself. The user stays in the loop and may step into any pane. What they say overrides the next step.
 
 ## 1. Plan
 
 ```
-vibest run <harness> --access read -- 'Write an implementation plan for: <goal, paths, constraints>. Read the code. Report the approach, the files to change, the steps, how to verify, and open questions. Do not modify files.'
+vibest run <harness> -- 'Write an implementation plan for: <goal, paths, constraints>. Read the code. Report the approach, the files to change, the steps, how to verify, and open questions. Do not modify files.'
 ```
 
-Its id is <planner id>. Tell the user the plan is being written and end your turn. `--access read` keeps the planner in the project directory, read-only, with no worktree. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
+Its id is <planner id>. Tell the user the plan is being written and end your turn. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
 
 ## 2. Agree
 
@@ -23,16 +23,15 @@ Show the plan in full, including open questions. Do not implement until the user
 
 ```
 vibest project write scratch pipeline-<topic>-plan.md --if-version new -- '<the agreed plan, verbatim>'
-vibest run <harness> --access write -- 'Implement the plan at <absolute scratch path> exactly. Run the tests and typecheck, commit on a branch, push, and report the branch and hash. Do not open a pull request.'
+vibest run <harness> -- 'Implement the plan at <absolute scratch path> exactly. Run the tests and typecheck, commit on a branch, push, and report the branch and hash. Do not open a pull request.'
 ```
 
-Its id is <implementer id>. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch pipeline-<topic>-plan.md`, then write again with the version it prints, or pick a new file name. Do not pass `--archive-on-completion`: this session stays for review and the pull request. When it reports, check the diff and the tests yourself before review. That diff is for this write session, which has a worktree.
+Its id is <implementer id>. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch pipeline-<topic>-plan.md`, then write again with the version it prints, or pick a new file name. Do not pass `--archive-on-completion`: this session stays for review and the pull request. When it reports, check the diff and the tests yourself before review.
 
 ## 4. Review
 
 `--peer` shares the implementer's worktree: a pane split off the implementer's pane. Archiving the reviewer never removes that worktree.
-Do not pass `--access read` on this session. That flag is the project directory and does not share a worktree, so the server refuses the pair.
-Read-only here is the prompt you pass, plus the peer git rule the session already has: no commit, and nothing that moves HEAD, a branch, or the index. The session is not started with `VIBEST_ACCESS=read`, so the harness is not in its read-only tool mode.
+Read-only here is the prompt you pass, plus the peer git rule the session already has: no commit, and nothing that moves HEAD, a branch, or the index.
 
 ```
 vibest run <harness> --peer <implementer id> -- 'Review the change on this branch against the plan at <absolute scratch path>. Run git diff main...HEAD. Do not modify files, commit, or move HEAD. Look for bugs, missing tests, and departures from the plan; run the tests. Start with "verdict: approve" or "verdict: changes requested", then each comment with file and line.'

package/harnesses/cursor/.cursor-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "vibest",
-  "version": "0.0.1-beta.11",
+  "version": "0.0.1-beta.13",
   "description": "vibest's Cursor CLI plugin: a session's turn-end result and the tool guard, loaded with `cursor-agent --plugin-dir`."
 }

package/harnesses/cursor/hooks/vibest.sh

@@ -1,5 +1,5 @@
 #!/bin/sh
-# @vibest/cursor 0.0.1-beta.11: `vibest integration guard` before a tool call, `vibest integration prompt` when the user submits, `vibest integration stop` at a turn end.
+# @vibest/cursor 0.0.1-beta.13: `vibest integration guard` before a tool call, `vibest integration prompt` when the user submits, `vibest integration stop` at a turn end.
 case "${1:-}" in
   guard)
     # preToolUse runs fail-closed, where no answer refuses: outside vibest, allow (it grants no approval).

package/harnesses/cursor/skills/delegate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: delegate
-description: Hand work to subagents with `vibest run` and keep talking with the user while they work. Only vibest's main Agent (the coordinator) starts agents; a subagent must not use this skill. Use for any request to change, fix, build, investigate, research, test or verify code ("fix this bug", "add X", "look into why Y", "do these three things", "have an agent check it"), and whenever a task splits into independent parts that can run at the same time.
+description: Hand work to subagents with `vibest run` and keep talking with the user while they work. Only vibest's main agent (the coordinator) starts agents; a subagent must not use this skill. Use for any request to change, fix, build, investigate, research, test or verify code ("fix this bug", "add X", "look into why Y", "do these three things", "have an agent check it"), and whenever a task splits into independent parts that can run at the same time.
 ---
 
 # Delegate
@@ -12,19 +12,19 @@ You direct subagents. You stay with the user. Each result arrives in your inbox
 Split independent pieces. Research and review run in parallel. One writing subagent per set of files. A few shell reads (`git diff`, `rg`) you do yourself.
 
 ```
-vibest run <harness> --access write -- '<self-contained task>'
+vibest run <harness> -- '<self-contained task>'
 ```
 
 Its id is <id>.
 
 ```
-vibest run <harness> --access read --archive-on-completion -- '<task>'
+vibest run <harness> --archive-on-completion -- '<task>'
 ```
 
 `--archive-on-completion` is only for a session you will not message again after it completes. It archives once the session reports completed and that result has reached you. The branch is kept. Do not `vibest send` it after that. A `needs_input` or `failed` result has not archived it: send the answer to the id it printed; the flag still archives the completed result that follows. A reviewer that gets later rounds is the pipeline skill and must stay open, without this flag.
 
 - `<harness>` is `pi`, `claude` or `cursor` (`auto` only when a spawn plugin chooses).
-- `--access write` (the default) starts a new worktree. `--access read` stays in the project directory, read-only, with no new worktree.
+- Each session gets its own new worktree.
 - Several `vibest run` commands in one message start in parallel.
 - A subagent cannot see this conversation. Say what to achieve, where (paths, lines), what done means, and how to verify it. For code: run the tests and typecheck, commit, and report the branch and hash.
 - Long material: `vibest project write scratch <name>.md --if-version new -- '<text>'`. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch <name>.md`, then write again with the version it prints, or pick a new file name.
@@ -36,7 +36,7 @@ Tell the user in one or two lines what is running, then end your turn. Never gue
 
 ## Check the result
 
-An `<agent-result>` is a claim. For a session started with `--access write`, before you report success read `git -C <worktree> diff main...HEAD` and run the proving check in that worktree. A session started with `--access read` has no worktree; the result's worktree path is the project directory. Judge the report text. Do not treat `git diff main...HEAD` there as the subagent's work.
+An `<agent-result>` is a claim. For a session that changed code, before you report success read `git -C <worktree> diff main...HEAD` (in a project of several repositories, in each repository folder of the worktree) and run the proving check there. For research, judge the report text.
 
 - `status: needs_input` → `vibest send <id> -- '<the answer>'`, or ask the user. If it is waiting for the user's approval of an action, do not send the approval back: start a fresh agent with the approved action, quoting the user's words.
 - `status: failed`, or your check fails → `vibest send <id> -- '<the failure and what to fix>'`. It keeps its context. If a second correction fails, start a new `vibest run` or tell the user.

package/harnesses/cursor/skills/pipeline/SKILL.md

@@ -1,19 +1,19 @@
 ---
 name: pipeline
-description: Plan, implement, review, then open a pull request, with the user approving the plan first. Only vibest's main Agent (the coordinator) starts agents; a subagent must not use this skill. Use when the user wants a plan or design before code, a review before merging, or a pull request at the end ("plan it first, then build it", "write a design, then implement", "implement it and have someone review it", "先出方案再写，写完找人 review 后提 PR", "do it as a pipeline", "/pipeline").
+description: Plan, implement, review, then open a pull request, with the user approving the plan first. Only vibest's main agent (the coordinator) starts agents; a subagent must not use this skill. Use when the user wants a plan or design before code, a review before merging, or a pull request at the end ("plan it first, then build it", "write a design, then implement", "implement it and have someone review it", "先出方案再写，写完找人 review 后提 PR", "do it as a pipeline", "/pipeline").
 ---
 
 # Pipeline
 
-Plan (read) → the user agrees → implement (write) → review until the reviewer approves → pull request. Follow delegate: do not poll; each result arrives by itself; check it yourself. The user stays in the loop and may step into any pane. What they say overrides the next step.
+Plan → the user agrees → implement → review until the reviewer approves → pull request. Follow delegate: do not poll; each result arrives by itself; check it yourself. The user stays in the loop and may step into any pane. What they say overrides the next step.
 
 ## 1. Plan
 
 ```
-vibest run <harness> --access read -- 'Write an implementation plan for: <goal, paths, constraints>. Read the code. Report the approach, the files to change, the steps, how to verify, and open questions. Do not modify files.'
+vibest run <harness> -- 'Write an implementation plan for: <goal, paths, constraints>. Read the code. Report the approach, the files to change, the steps, how to verify, and open questions. Do not modify files.'
 ```
 
-Its id is <planner id>. Tell the user the plan is being written and end your turn. `--access read` keeps the planner in the project directory, read-only, with no worktree. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
+Its id is <planner id>. Tell the user the plan is being written and end your turn. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
 
 ## 2. Agree
 
@@ -23,16 +23,15 @@ Show the plan in full, including open questions. Do not implement until the user
 
 ```
 vibest project write scratch pipeline-<topic>-plan.md --if-version new -- '<the agreed plan, verbatim>'
-vibest run <harness> --access write -- 'Implement the plan at <absolute scratch path> exactly. Run the tests and typecheck, commit on a branch, push, and report the branch and hash. Do not open a pull request.'
+vibest run <harness> -- 'Implement the plan at <absolute scratch path> exactly. Run the tests and typecheck, commit on a branch, push, and report the branch and hash. Do not open a pull request.'
 ```
 
-Its id is <implementer id>. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch pipeline-<topic>-plan.md`, then write again with the version it prints, or pick a new file name. Do not pass `--archive-on-completion`: this session stays for review and the pull request. When it reports, check the diff and the tests yourself before review. That diff is for this write session, which has a worktree.
+Its id is <implementer id>. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch pipeline-<topic>-plan.md`, then write again with the version it prints, or pick a new file name. Do not pass `--archive-on-completion`: this session stays for review and the pull request. When it reports, check the diff and the tests yourself before review.
 
 ## 4. Review
 
 `--peer` shares the implementer's worktree: a pane split off the implementer's pane. Archiving the reviewer never removes that worktree.
-Do not pass `--access read` on this session. That flag is the project directory and does not share a worktree, so the server refuses the pair.
-Read-only here is the prompt you pass, plus the peer git rule the session already has: no commit, and nothing that moves HEAD, a branch, or the index. The session is not started with `VIBEST_ACCESS=read`, so the harness is not in its read-only tool mode.
+Read-only here is the prompt you pass, plus the peer git rule the session already has: no commit, and nothing that moves HEAD, a branch, or the index.
 
 ```
 vibest run <harness> --peer <implementer id> -- 'Review the change on this branch against the plan at <absolute scratch path>. Run git diff main...HEAD. Do not modify files, commit, or move HEAD. Look for bugs, missing tests, and departures from the plan; run the tests. Start with "verdict: approve" or "verdict: changes requested", then each comment with file and line.'

package/harnesses/pi/extension.mjs

@@ -15903,7 +15903,6 @@ var init_layout = __esm(() => {
         database: path.join(home, "vibest.db"),
         socket: path.join(home, "vibest.sock"),
         daemonInfo: path.join(home, "vibestd.pid"),
-        daemonLock: path.join(home, "vibestd.lock"),
         results: path.join(home, "results"),
         reports: path.join(home, "reports"),
         worktrees: path.join(home, "worktrees"),
@@ -16085,7 +16084,8 @@ var init_harness = __esm(() => {
       const spawner = yield* ChildProcessSpawner;
       const harnesses = yield* Harnesses;
       const self = yield* VibestCommand;
-      const beside = self.length === 1 && path.isAbsolute(self[0]) ? path.join(path.dirname(path.dirname(self[0])), "harnesses") : undefined;
+      const pkg = self.length === 1 && path.isAbsolute(self[0]) ? path.dirname(path.dirname(self[0])) : undefined;
+      const beside = pkg === undefined ? undefined : yield* findFirst2([path.join(pkg, "harnesses"), path.join(pkg, "..", "cli", "harnesses"), path.join(pkg, "..", "..", "..", "harnesses")], (dir) => fs.exists(dir).pipe(orElseSucceed2(() => false))).pipe(map7((found) => getOrElse(found, () => path.join(pkg, "harnesses"))));
       const plugins = getOrUndefined(yield* option3(String7("VIBEST_HARNESSES"))) || beside;
       const searchPath = (yield* String7("PATH").pipe(withDefault3(""))).split(":").filter(Boolean);
       const { listModels } = yield* promise2(() => Promise.resolve().then(() => (init_models(), exports_models)));
@@ -19358,7 +19358,7 @@ init_session();
 // ../../protocol/package.json
 var package_default = {
   name: "@vibest/protocol",
-  version: "0.0.1-beta.11",
+  version: "0.0.1-beta.13",
   private: true,
   type: "module",
   license: "MIT",
@@ -19511,8 +19511,7 @@ class VibestRpcs extends make31(make29("Ping", { success: PingResult }), scoped4
     agent: optional2(String6),
     machine: optional2(RuntimeMachine),
     peer: optional2(String6),
-    archive: optional2(Boolean3),
-    access: optional2(Literals(["read", "write"]))
+    archive: optional2(Boolean3)
   },
   success: Struct({
     id: String6,
@@ -19954,63 +19953,6 @@ var HERDR_CONTROL = new Set(["agent", "pane", "tab", "workspace", "worktree", "s
 var HARNESS_CLIS = new Set(["pi", "claude", "cursor-agent"]);
 var GH_UNSAFE = new Set(["alias", "extension", "ext", "config", "auth"]);
 var firstWord = (words) => words.find((w) => !w.startsWith("-")) ?? "";
-var WRITE_BIN = new Set(["rm", "rmdir", "mv", "cp", "tee", "touch", "mkdir", "truncate", "dd", "ln", "unlink", "install"]);
-var GIT_WRITE = new Set(["add", "commit", "push", "merge", "rebase", "reset", "checkout", "switch", "restore", "clean", "worktree", "pull", "cherry-pick", "revert", "am", "apply", "stash", "init", "mv", "rm"]);
-var gitSubcommand = (argv) => {
-  for (let i = 1;i < argv.length; i++) {
-    const word = argv[i];
-    if (word === "-c" || word === "-C") {
-      i++;
-      continue;
-    }
-    if (!word.startsWith("-"))
-      return word;
-  }
-  return "";
-};
-var writesByRedirect = (command) => {
-  let quote;
-  for (let i = 0;i < command.length; i++) {
-    const c = command[i];
-    if (quote === "'") {
-      if (c === "'")
-        quote = undefined;
-      continue;
-    }
-    if (quote === '"') {
-      if (c === '"')
-        quote = undefined;
-      else if (c === "\\")
-        i++;
-      continue;
-    }
-    if (c === "'" || c === '"') {
-      quote = c;
-      continue;
-    }
-    if (c === "\\") {
-      i++;
-      continue;
-    }
-    if (c === ">" && command[i + 1] !== "&")
-      return true;
-  }
-  return false;
-};
-var writeLike = (command) => {
-  if (writesByRedirect(command))
-    return true;
-  for (const p of programsOf(command)) {
-    const name = base(p.argv[0] ?? "");
-    if (WRITE_BIN.has(name))
-      return true;
-    if (name === "git" && GIT_WRITE.has(gitSubcommand(p.argv)))
-      return true;
-    if ((name === "sed" || name === "perl") && p.argv.slice(1).some((a) => a === "-i" || a.startsWith("-i") || a === "--in-place" || a.startsWith("--in-place=")))
-      return true;
-  }
-  return false;
-};
 var shellBlock = (command, vibest, coordinator) => {
   for (const p of programsOf(command)) {
     const [program = "", ...rest] = p.argv;
@@ -20074,8 +20016,7 @@ var coordinator = (call) => gen2(function* () {
     return "The coordinator does not edit files; hand the change to a session.";
   return;
 });
-var OFF_LIMITS = "The Project directory is off limits to sessions, except your scratchpad.";
-var READ_ONLY = "This session is read-only; it does not edit files or run commands that write.";
+var OFF_LIMITS = "The project directory is off limits to sessions, except your scratchpad.";
 var SHELL_WORDS = /[^\s'"`;|&()<>=,]+/g;
 var SHELL_SEARCH = /(?:^|[\s;&|(])(?:rg|ag|ack|grep|egrep|find|fd|tree|du)\s/;
 var session = fn2("Guard.session")(function* (call) {
@@ -20144,18 +20085,7 @@ var decodePreToolUse = decodeUnknownEffect2(fromJsonString2(Struct({
   workspace_roots: optional2(ArraySchema(String6))
 })));
 var COORDINATOR = "coordinator";
-var readSession = (call) => gen2(function* () {
-  const denied = yield* session(call);
-  if (denied)
-    return denied;
-  if (fileWritingTool(call.tool))
-    return READ_ONLY;
-  const command = SHELL_TOOLS.has(call.tool.toLowerCase()) ? shellCommand(call.input) : undefined;
-  if (command !== undefined && writeLike(command))
-    return READ_ONLY;
-  return;
-});
-var rulesOf = (agent, access = "write") => agent === COORDINATOR ? coordinator : access === "read" ? readSession : session;
+var rulesOf = (agent) => agent === COORDINATOR ? coordinator : session;
 
 // ../../core/src/results.ts
 init_dist();
@@ -21089,8 +21019,7 @@ var extension2 = unwrap(gen2(function* () {
   const agent = getOrUndefined(yield* option3(String7("VIBEST_AGENT")));
   if (!agent)
     return empty4;
-  const access = getOrUndefined(yield* option3(String7("VIBEST_ACCESS")));
-  const guard = effectDiscard(guarded(rulesOf(agent, access === "read" ? "read" : "write")));
+  const guard = effectDiscard(guarded(rulesOf(agent)));
   if (agent === COORDINATOR)
     return coordinator2.pipe(provideMerge(guard));
   const sessionId = getOrUndefined(yield* option3(String7("VIBEST_SESSION_ID")));

package/harnesses/pi/skills/delegate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: delegate
-description: Hand work to subagents with `vibest run` and keep talking with the user while they work. Only vibest's main Agent (the coordinator) starts agents; a subagent must not use this skill. Use for any request to change, fix, build, investigate, research, test or verify code ("fix this bug", "add X", "look into why Y", "do these three things", "have an agent check it"), and whenever a task splits into independent parts that can run at the same time.
+description: Hand work to subagents with `vibest run` and keep talking with the user while they work. Only vibest's main agent (the coordinator) starts agents; a subagent must not use this skill. Use for any request to change, fix, build, investigate, research, test or verify code ("fix this bug", "add X", "look into why Y", "do these three things", "have an agent check it"), and whenever a task splits into independent parts that can run at the same time.
 ---
 
 # Delegate
@@ -12,19 +12,19 @@ You direct subagents. You stay with the user. Each result arrives in your inbox
 Split independent pieces. Research and review run in parallel. One writing subagent per set of files. A few shell reads (`git diff`, `rg`) you do yourself.
 
 ```
-vibest run <harness> --access write -- '<self-contained task>'
+vibest run <harness> -- '<self-contained task>'
 ```
 
 Its id is <id>.
 
 ```
-vibest run <harness> --access read --archive-on-completion -- '<task>'
+vibest run <harness> --archive-on-completion -- '<task>'
 ```
 
 `--archive-on-completion` is only for a session you will not message again after it completes. It archives once the session reports completed and that result has reached you. The branch is kept. Do not `vibest send` it after that. A `needs_input` or `failed` result has not archived it: send the answer to the id it printed; the flag still archives the completed result that follows. A reviewer that gets later rounds is the pipeline skill and must stay open, without this flag.
 
 - `<harness>` is `pi`, `claude` or `cursor` (`auto` only when a spawn plugin chooses).
-- `--access write` (the default) starts a new worktree. `--access read` stays in the project directory, read-only, with no new worktree.
+- Each session gets its own new worktree.
 - Several `vibest run` commands in one message start in parallel.
 - A subagent cannot see this conversation. Say what to achieve, where (paths, lines), what done means, and how to verify it. For code: run the tests and typecheck, commit, and report the branch and hash.
 - Long material: `vibest project write scratch <name>.md --if-version new -- '<text>'`. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch <name>.md`, then write again with the version it prints, or pick a new file name.
@@ -36,7 +36,7 @@ Tell the user in one or two lines what is running, then end your turn. Never gue
 
 ## Check the result
 
-An `<agent-result>` is a claim. For a session started with `--access write`, before you report success read `git -C <worktree> diff main...HEAD` and run the proving check in that worktree. A session started with `--access read` has no worktree; the result's worktree path is the project directory. Judge the report text. Do not treat `git diff main...HEAD` there as the subagent's work.
+An `<agent-result>` is a claim. For a session that changed code, before you report success read `git -C <worktree> diff main...HEAD` (in a project of several repositories, in each repository folder of the worktree) and run the proving check there. For research, judge the report text.
 
 - `status: needs_input` → `vibest send <id> -- '<the answer>'`, or ask the user. If it is waiting for the user's approval of an action, do not send the approval back: start a fresh agent with the approved action, quoting the user's words.
 - `status: failed`, or your check fails → `vibest send <id> -- '<the failure and what to fix>'`. It keeps its context. If a second correction fails, start a new `vibest run` or tell the user.

package/harnesses/pi/skills/pipeline/SKILL.md

@@ -1,19 +1,19 @@
 ---
 name: pipeline
-description: Plan, implement, review, then open a pull request, with the user approving the plan first. Only vibest's main Agent (the coordinator) starts agents; a subagent must not use this skill. Use when the user wants a plan or design before code, a review before merging, or a pull request at the end ("plan it first, then build it", "write a design, then implement", "implement it and have someone review it", "先出方案再写，写完找人 review 后提 PR", "do it as a pipeline", "/pipeline").
+description: Plan, implement, review, then open a pull request, with the user approving the plan first. Only vibest's main agent (the coordinator) starts agents; a subagent must not use this skill. Use when the user wants a plan or design before code, a review before merging, or a pull request at the end ("plan it first, then build it", "write a design, then implement", "implement it and have someone review it", "先出方案再写，写完找人 review 后提 PR", "do it as a pipeline", "/pipeline").
 ---
 
 # Pipeline
 
-Plan (read) → the user agrees → implement (write) → review until the reviewer approves → pull request. Follow delegate: do not poll; each result arrives by itself; check it yourself. The user stays in the loop and may step into any pane. What they say overrides the next step.
+Plan → the user agrees → implement → review until the reviewer approves → pull request. Follow delegate: do not poll; each result arrives by itself; check it yourself. The user stays in the loop and may step into any pane. What they say overrides the next step.
 
 ## 1. Plan
 
 ```
-vibest run <harness> --access read -- 'Write an implementation plan for: <goal, paths, constraints>. Read the code. Report the approach, the files to change, the steps, how to verify, and open questions. Do not modify files.'
+vibest run <harness> -- 'Write an implementation plan for: <goal, paths, constraints>. Read the code. Report the approach, the files to change, the steps, how to verify, and open questions. Do not modify files.'
 ```
 
-Its id is <planner id>. Tell the user the plan is being written and end your turn. `--access read` keeps the planner in the project directory, read-only, with no worktree. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
+Its id is <planner id>. Tell the user the plan is being written and end your turn. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
 
 ## 2. Agree
 
@@ -23,16 +23,15 @@ Show the plan in full, including open questions. Do not implement until the user
 
 ```
 vibest project write scratch pipeline-<topic>-plan.md --if-version new -- '<the agreed plan, verbatim>'
-vibest run <harness> --access write -- 'Implement the plan at <absolute scratch path> exactly. Run the tests and typecheck, commit on a branch, push, and report the branch and hash. Do not open a pull request.'
+vibest run <harness> -- 'Implement the plan at <absolute scratch path> exactly. Run the tests and typecheck, commit on a branch, push, and report the branch and hash. Do not open a pull request.'
 ```
 
-Its id is <implementer id>. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch pipeline-<topic>-plan.md`, then write again with the version it prints, or pick a new file name. Do not pass `--archive-on-completion`: this session stays for review and the pull request. When it reports, check the diff and the tests yourself before review. That diff is for this write session, which has a worktree.
+Its id is <implementer id>. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch pipeline-<topic>-plan.md`, then write again with the version it prints, or pick a new file name. Do not pass `--archive-on-completion`: this session stays for review and the pull request. When it reports, check the diff and the tests yourself before review.
 
 ## 4. Review
 
 `--peer` shares the implementer's worktree: a pane split off the implementer's pane. Archiving the reviewer never removes that worktree.
-Do not pass `--access read` on this session. That flag is the project directory and does not share a worktree, so the server refuses the pair.
-Read-only here is the prompt you pass, plus the peer git rule the session already has: no commit, and nothing that moves HEAD, a branch, or the index. The session is not started with `VIBEST_ACCESS=read`, so the harness is not in its read-only tool mode.
+Read-only here is the prompt you pass, plus the peer git rule the session already has: no commit, and nothing that moves HEAD, a branch, or the index.
 
 ```
 vibest run <harness> --peer <implementer id> -- 'Review the change on this branch against the plan at <absolute scratch path>. Run git diff main...HEAD. Do not modify files, commit, or move HEAD. Look for bugs, missing tests, and departures from the plan; run the tests. Start with "verdict: approve" or "verdict: changes requested", then each comment with file and line.'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibest/cli",
-  "version": "0.0.1-beta.11",
+  "version": "0.0.1-beta.13",
   "description": "vibest: vibestd daemon and the vibest CLI. A coordinator directing sessions in herdr panes.",
   "type": "module",
   "license": "MIT",
@@ -24,19 +24,19 @@
   "devDependencies": {
     "@effect/platform-bun": "4.0.2",
     "@effect/sql-sqlite-bun": "4.0.2",
-    "@vibest/client": "0.0.1-beta.11",
-    "@vibest/core": "0.0.1-beta.11",
-    "@vibest/plugin": "0.0.1-beta.11",
-    "@vibest/protocol": "0.0.1-beta.11",
-    "@vibest/runtime-herdr": "0.0.1-beta.11",
-    "@vibest/schema": "0.0.1-beta.11",
-    "@vibest/server": "0.0.1-beta.11",
+    "@vibest/client": "0.0.1-beta.13",
+    "@vibest/core": "0.0.1-beta.13",
+    "@vibest/plugin": "0.0.1-beta.13",
+    "@vibest/protocol": "0.0.1-beta.13",
+    "@vibest/runtime-herdr": "0.0.1-beta.13",
+    "@vibest/schema": "0.0.1-beta.13",
+    "@vibest/server": "0.0.1-beta.13",
     "effect": "4.0.2",
-    "effect-herdr-sdk": "0.0.1-beta.11"
+    "effect-herdr-sdk": "0.0.1-beta.13"
   },
   "optionalDependencies": {
-    "@vibest/cli-darwin-arm64": "0.0.1-beta.11",
-    "@vibest/cli-linux-x64": "0.0.1-beta.11"
+    "@vibest/cli-darwin-arm64": "0.0.1-beta.13",
+    "@vibest/cli-linux-x64": "0.0.1-beta.13"
   },
   "imports": {
     "#platform": {