Merge branch 'remove-execute-pipe'

core

@@ -1 +1 @@
-Subproject commit fe51f96dcc17f531f5308031e0d28e79198b60f7
+Subproject commit 9ef3dd07cc6660c49de0ee8b35013f93d7e51a1b

doc/ARCHITECTURE.md

@@ -13,7 +13,7 @@ pkg/
   config/        — Agent config struct and loader
   mcp/           — MCP client (concrete)
   tools/         — Server and Dispatcher interfaces
-  tools/execute/   — execute.Server: execute_code, execute_pipe
+  tools/execute/   — execute.Server: execute_code
 
 internal/
   sandbox/       — landrun sandbox config and command wrapper
@@ -56,7 +56,7 @@ Frontend
               ├── backend.ChatStream()              — LLM call
               └── tools.Dispatcher.Dispatch(...)   — tool dispatch
                     ├── "execute"   → tools.Server
-                    │       execute_code / execute_pipe
+                    │       execute_code
                     └── "<servername>"  → tools.Server (MCP)
 ```
 
@@ -64,18 +64,17 @@ All tool calls go through one `tools.Dispatcher.Dispatch` path. Every registered
 
 ## Built-in Tools
 
-Two built-in tools via `execute.Server`:
+One built-in tool via `execute.Server`:
 
 | Tool | What it does |
 |---|---|
-| `execute_code` | Runs one or more steps in a sandbox; steps may be inline code or named tool scripts; multiple steps run in parallel, results in submission order |
-| `execute_pipe` | Chains stages sequentially, piping stdout → stdin; stages may be `{code}`, `{tool, args}`, or `{parallel:[...]}` for concurrent fan-out |
+| `execute_code` | Runs a pipeline of stages sequentially, piping stdout → stdin. Each stage is `{code}`, `{tool, args}`, or `{parallel:[...]}` for concurrent fan-out. Single stage = degenerate case, raw output. |
 
-`OLLIE_TOOLS_PATH` defaults to `~/.config/ollie/tools`. The directory can be a symlink or a mountpoint — `{tool}` steps in `execute_code` and `execute_pipe` resolve scripts from this path.
+`OLLIE_TOOLS_PATH` defaults to `~/.config/ollie/tools`. The directory can be a symlink or a mountpoint — `{tool}` steps in `execute_code` resolve scripts from this path.
 
 ## Tool Scripts
 
-Capabilities beyond `execute_code` and `execute_pipe` are implemented as tool scripts in `OLLIE_TOOLS_PATH`. Scripts are invoked via `execute_code` `{tool}` steps or as `{tool}` stages in `execute_pipe`. The agent discovers available scripts via `t/idx`.
+Capabilities beyond `execute_code` are implemented as tool scripts in `OLLIE_TOOLS_PATH`. Scripts are invoked via `execute_code` `{tool}` steps. The agent discovers available scripts via `t/idx`.
 
 Examples from the default install: `file_read`, `file_write`, `file_edit`, `file_glob`, `file_grep`, `memory_remember`, `memory_recall`, `reasoning_think`, `task_plan`, `task_complete`, `subagent_spawn`.
 
@@ -94,7 +93,7 @@ Everything else — listing plans, inspecting a specific step, bulk operations
 
 ## Parallel Execution and Sub-agents
 
-`execute_code` implements fork-join at the shell level: multiple steps run concurrently in goroutines, results collected in submission order. Steps may be inline code (`{code, language}`) or named tool scripts (`{tool, args}`). `execute_pipe` extends this with `{parallel:[...]}` stages for fan-out within a sequential pipeline.
+`execute_code` is a sequential pipeline: stages run in order, stdout piped to the next stage's stdin. A `{parallel:[...]}` stage fans out concurrently within the pipeline, concatenating results in submission order before passing them downstream. A single simple stage is the degenerate case and returns raw output.
 
 Sub-agents are implemented as a tool script (`subagent_spawn`) on top of the `b/` batch namespace. The script writes a job spec to `b/new`, polls `b/{id}/status` per job in background subshells, joins on all, and concatenates results. The `b/` namespace (backed by `BatchStore`) handles agent lifecycle, cancellation, and result storage.
 
@@ -109,7 +108,7 @@ execute_code parallel steps
                                joined in submission order
 ```
 
-The architecture boundary is preserved: `execute_code` and `execute_pipe` are built-in tools in `core`; everything else is a tool script; `b/` is a 9P namespace. No layer knows about the others.
+The architecture boundary is preserved: `execute_code` is the only built-in tool in `core`; everything else is a tool script; `b/` is a 9P namespace. No layer knows about the others.
 
 ## Typical Consumer Setup
 

doc/IDEAS.md

@@ -93,7 +93,7 @@ A session can spawn ephemeral child sessions to handle a focused task, then tear
 
 **Sub-agents as function calls** — the parent primes the child with exactly the context it needs (excerpts from its own `chat`, relevant beads, local file contents) and receives a single focused reply. Failures are isolated; a child that errors or stalls can be killed and retried without affecting the parent. The pattern composes naturally: a sub-agent can itself spawn sub-agents, building a call tree bounded only by the number of sessions open at once.
 
-`spawn_subagents.py` reads a JSON spec from stdin, fans out the work concurrently, and returns a JSON array of results — a single `execute_code` `{tool}` step from the parent's perspective. Note: this requires adding Python language support to `execute_code` and `execute_pipe`, which is low effort.
+`spawn_subagents.py` reads a JSON spec from stdin, fans out the work concurrently, and returns a JSON array of results — a single `execute_code` `{tool}` step from the parent's perspective. Note: this requires adding Python language support to `execute_code`, which is low effort.
 
 ```python
 #!/usr/bin/env python3

doc/OBSERVATIONS.md

@@ -6,15 +6,15 @@
 
 **Crash resiliency** — Memory (`m/`) and plans (`pl/`) are written to persistent storage outside the session. If a session crashes or is killed mid-task, neither is lost — a fresh session picks up where the previous one left off.
 
-**[Code execution tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool)** — Anthropic describes code execution as "a foundational primitive for building high-performance agents." ollie takes that literally: `execute_code` is the base layer, and `execute_pipe` builds directly on top of it. Named tool scripts are first-class citizens of `execute_code` steps — new capabilities are added by dropping a script into `t/` and a skill in `sk/`.
+**[Code execution tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool)** — Anthropic describes code execution as "a foundational primitive for building high-performance agents." ollie takes that literally: `execute_code` is the only built-in tool. It is a pipeline executor — single stage, multi-stage, and parallel fan-out are all the same primitive. New capabilities are added by dropping a script into `t/` and a skill in `sk/`.
 
-**Parallel execution** — `execute_code` accepts a `steps` array; multiple steps run concurrently in goroutines and results are collected in submission order. `execute_pipe` supports `{parallel: [...]}` stages for fan-out within a pipeline. Both accept inline code and named tool scripts interchangeably.
+**Parallel execution** — `execute_code` accepts a `steps` array of pipeline stages. A `{parallel: [...]}` stage fans out concurrently within the pipeline. Sequential stages chain stdout → stdin. All stages accept inline code and named tool scripts interchangeably.
 
 **Radical transparency** — The rendered system prompt for any session is readable at `s/{id}/systemprompt` — the prompt the agent is actually running with, not a reconstruction. The prompt parts that compose it live in `p/`; the agent can read its own instructions but cannot modify them.
 
 **Discoverability** — `ls s/{id}/` shows every control surface. `cat t/idx` and `cat sk/idx` list available tools and skills. `cat help` explains the rest.
 
-**Composability** — Tools compose via `execute_pipe`, chaining code and named tool scripts the same way Unix pipes chain programs. Sessions chain by reading `s/{id}/chat` and writing to another session's `prompt` or `enqueue`.
+**Composability** — `execute_code` stages chain the same way Unix pipes chain programs. Sessions chain by reading `s/{id}/chat` and writing to another session's `prompt` or `enqueue`.
 
 **Passive memory** — Every session's chat history accumulates at `s/{id}/chat`, searchable with `grep`. An agent doesn't need to actively decide what to remember. This extends across sessions: an agent can search another session's chat for answers that have already been worked through.
 

prompts/01_ollie.md

@@ -8,7 +8,7 @@ The ollie 9P filesystem is mounted at `{{.OllieMountPath}}`. All persistent stat
 
 | Path | Contents |
 |---|---|
-| `{{.OllieMountPath}}/t/`        | Tool scripts — run as `{tool}` steps in `execute_code` or `execute_pipe` |
+| `{{.OllieMountPath}}/t/`        | Tool scripts — run as `{tool}` steps in `execute_code` |
 | `{{.OllieMountPath}}/sk/`       | Skills — domain-specific knowledge files |
 | `{{.OllieMountPath}}/pl/`       | Task plans — markdown checklists |
 | `{{.OllieMountPath}}/m/`        | Memory files |

prompts/02_tools.md

@@ -1,6 +1,6 @@
 # Tools
 
-Tool scripts live at `{{.OllieMountPath}}/t`. Run them as `{tool}` steps in `execute_code` or as `{tool}` stages in `execute_pipe`.
+Tool scripts live at `{{.OllieMountPath}}/t`. Run them as `{tool}` steps in `execute_code`.
 
 Supported languages are detected from the script's shebang line:
 - `#!/usr/bin/env bash` — runs with `bash -c`
@@ -16,14 +16,15 @@ args: <required> [optional]
 
 Search before acting: `grep -A2 "keyword" {{.OllieMountPath}}/t/idx`
 
-## Parallel execution
+## execute_code
 
-`execute_code` accepts a `steps` array. Multiple steps run concurrently; results are returned in submission order. Single-step calls return raw output.
+`execute_code` accepts a `steps` array of pipeline stages. Stages run sequentially, each stage's stdout fed to the next stage's stdin. A single stage returning raw output is the degenerate case.
 
-`execute_pipe` stages may be `{parallel: [...]}` to fan out concurrently within a pipeline. All parallel steps should produce the same output schema so their concatenated output is coherent for the next stage. Load the `execute-pipe` skill for full pipeline patterns and the ETL pattern for disparate schemas.
+Each stage is one of:
+- `{code, language}` — inline code; `language` defaults to `bash`
+- `{tool, args}` — named script from `t/`; language detected from shebang
+- `{parallel: [...]}` — concurrent fan-out; outputs concatenated in submission order, fed to next stage
 
-## Language selection
+Supported inline languages: `bash`, `python3`, `perl`, `lua`, `awk`, `sed`, `jq`, `ed`, `expect`, `bc`.
 
-For inline code steps (`{code}`), set `language` to choose the interpreter (default: `bash`). Supported: `bash`, `python3`, `perl`, `lua`, `awk`, `sed`, `jq`, `ed`, `expect`, `bc`.
-
-For tool steps (`{tool}`), the interpreter is determined by the script's shebang line — `language` is ignored.
+All parallel steps in a stage should produce the same output schema so their concatenated output is coherent for the next stage. Load the `execute-pipe` skill for pipeline patterns and the ETL pattern for disparate schemas.

skills

@@ -1 +1 @@
-Subproject commit 611e3384c307b7752931de4206019a4c8ef6e3a0
+Subproject commit f48f2086824a27530872748e62ed1fa748360fcf