remove call_tool and pipe references from docs
This commit is contained in:
Ollie Agent
parent
c377471e55
commit
e4fab8cfb1
2
core
2
core
|
|
@ -1 +1 @@
|
|||
Subproject commit b26bd7f5803521282f8cba8827e70a5b32b81edc
|
||||
Subproject commit 18d00191f8c5ba2634692d0f7c6b082698effc1a
|
||||
|
|
@ -67,7 +67,7 @@ D-Bus-only mode: olliesrv -no9p (same interface, no filesystem listener)
|
|||
│ │ (loop.go) │ │ (messages, │ │ ┌──────────────────┐ │ │
|
||||
│ │ │ │ task state, │ │ │ execute.Server │ │ │
|
||||
│ │ stream ←────┼──┤ compaction) │ │ │ (execute_code, │ │ │
|
||||
│ │ dispatch ───┼──┼───────────────┼──┤ │ call_tool, pipe)│ │ │
|
||||
│ │ dispatch ───┼──┼───────────────┼──┤ │ execute_code) │ │ │
|
||||
│ └─────────────┘ └──────────────┘ │ └────────┬─────────┘ │ │
|
||||
│ └───────────┼────────────┘ │
|
||||
└──────────────────────────────────────────────────┼──────────────┘
|
||||
|
|
@ -103,7 +103,7 @@ The core is a Go library (`ollie/pkg/`) with no binary. Frontends import it as a
|
|||
| `pkg/log/` | Structured logging |
|
||||
| `pkg/paths/` | Config and data directory resolution |
|
||||
| `pkg/tools/` | Server and Dispatcher interfaces |
|
||||
| `pkg/tools/execute/` | The execute.Server (execute_code, call_tool, pipe) |
|
||||
| `pkg/tools/execute/` | The execute.Server (execute_code) |
|
||||
| `pkg/tools/execute/tool.go` | Named tool script discovery and execution |
|
||||
| `internal/sandbox/` | Landlock sandbox config and command wrapper |
|
||||
|
||||
|
|
@ -279,8 +279,6 @@ The tool system has exactly one built-in server (`execute.Server`) that exposes
|
|||
| Executor | Purpose |
|
||||
|---|---|
|
||||
| `execute_code` | Run inline code steps (bash, python3, perl, lua, ...) |
|
||||
| `call_tool` | Run named scripts from `OLLIE_TOOLS_PATH` |
|
||||
| `pipe` | Sequential pipeline chaining stdout→stdin across steps |
|
||||
|
||||
All other capabilities are **tool scripts** — executable files discovered from `OLLIE_TOOLS_PATH` (default: `~/.config/ollie/tools`).
|
||||
|
||||
|
|
|
|||
31
doc/CORE.md
31
doc/CORE.md
|
|
@ -33,7 +33,6 @@ core/
|
|||
│ ├── server.go Server struct, Decl factory, ListTools, options
|
||||
│ ├── code.go Step resolution, validation, dispatch routing
|
||||
│ ├── tool.go Named tool script discovery and execution
|
||||
│ ├── pipe.go Pipeline stage execution, parallel fan-out
|
||||
│ ├── flock.go Advisory locking, parallelism classification
|
||||
│ └── tier.go Result tier classification (hot/warm/cold)
|
||||
└── internal/
|
||||
|
|
@ -404,36 +403,6 @@ Runs inline code steps sequentially (or parallel via `{parallel: [...]}`).
|
|||
|
||||
**Supported languages:** bash, python3, perl, lua, awk, sed, jq, ed, expect, bc.
|
||||
|
||||
#### call_tool
|
||||
|
||||
Runs named tool scripts from `OLLIE_TOOLS_PATH`.
|
||||
|
||||
**Input schema:**
|
||||
```json
|
||||
{
|
||||
"calls": [{"tool": "file_read", "args": ["/path"]}],
|
||||
"timeout": 30,
|
||||
"sandbox": "default"
|
||||
}
|
||||
```
|
||||
|
||||
Parallel fan-out is automatic for consecutive calls to `ollie:parallel read` tools.
|
||||
|
||||
#### pipe
|
||||
|
||||
Sequential pipeline — each stage's stdout feeds the next stage's stdin.
|
||||
|
||||
**Input schema:**
|
||||
```json
|
||||
{
|
||||
"stages": [
|
||||
{"tool": "file_grep", "args": ["TODO", "--path=src/"]},
|
||||
{"code": "wc -l"}
|
||||
],
|
||||
"timeout": 30
|
||||
}
|
||||
```
|
||||
|
||||
### Code Validation
|
||||
|
||||
Before execution, inline code is checked against dangerous patterns:
|
||||
|
|
|
|||
|
|
@ -41,4 +41,4 @@
|
|||
|
||||
This enables prompt pipelines where each stage transforms, filters, or augments the previous stage's output — all with standard shell syntax.
|
||||
|
||||
**Tool schema complexity and model capability** — The execute package originally exposed a single `execute_code` tool with a unified schema covering inline steps, stdin-chained pipelines, named tool scripts, parallel fan-out, elevated execution, and sandbox selection. Larger models with strong reasoning handled this without difficulty. Smaller models struggled: common failure modes included emitting both `steps` and `pipe` in the same call, confusing the two execution modes, and ignoring named tool scripts in favour of reimplementing them inline. The tool was therefore split into three purpose-specific primitives — `execute_code` (inline code, `steps` key), `call_tool` (named scripts, `calls` key), and `pipe` (stdin-chained pipeline, `stages` key) — giving smaller models a narrow, unambiguous contract per tool. The `{parallel: [...]}` fan-out option is retained inside `execute_code` and `pipe` stages. The trade-off: a minor ergonomic regression for large models that handled the unified schema well, offset by significantly more reliable behaviour from smaller models.
|
||||
**Tool schema complexity and model capability** — The execute package originally exposed a single `execute_code` tool with a unified schema covering inline steps, stdin-chained pipelines, named tool scripts, parallel fan-out, elevated execution, and sandbox selection. Larger models with strong reasoning handled this without difficulty. Smaller models struggled: common failure modes included confusing execution modes and ignoring named tool scripts in favour of reimplementing them inline. The tool was therefore split into two primitives — `execute_code` (inline code) and the tool registry (named scripts promoted to native callables) — giving smaller models a narrow, unambiguous contract per tool. The `{parallel: [...]}` fan-out option is retained inside `execute_code` stages.
|
||||
|
|
|
|||
|
|
@ -190,8 +190,7 @@ Option 2 is simplest and matches goq's philosophy of "the remote is a mirror of
|
|||
| Component | Location | Why |
|
||||
|---|---|---|
|
||||
| execute_code | Remote | Needs remote filesystem, build tools |
|
||||
| call_tool (file_*) | Remote | File I/O targets remote tree |
|
||||
| call_tool (lsp_*) | Remote | Language server needs remote source |
|
||||
| Named tool scripts | Remote | File I/O targets remote tree |
|
||||
| Sandbox | Remote | Landrun enforces on the execution host |
|
||||
| Working directory | Remote | The project lives there |
|
||||
|
||||
|
|
@ -218,7 +217,7 @@ All five phases are implemented:
|
|||
- `remote/` submodule with `main.go`
|
||||
- Wraps `execute.Server` with JSON-RPC stdio interface
|
||||
- Embeds `sandbox-remote.yaml` and tool scripts via `go:embed`
|
||||
- RPC methods: `execute_code`, `call_tool`, `pipe`, `list_tools`, `host_info`, `ping`
|
||||
- RPC methods: `execute_code`, `list_tools`, `host_info`, `ping`
|
||||
|
||||
### Phase 2: SSH bootstrap ✓
|
||||
- `core/pkg/remote/bootstrap.sh` embedded template
|
||||
|
|
@ -229,7 +228,7 @@ All five phases are implemented:
|
|||
### Phase 3: RemoteServer adapter ✓
|
||||
- `core/pkg/remote/remote.go` implements `tools.Server`
|
||||
- `ListTools()` calls remote `list_tools` RPC
|
||||
- `CallTool()` passes tool name as RPC method (routes execute_code/call_tool/pipe)
|
||||
- `CallTool()` passes tool name as RPC method (routes execute_code)
|
||||
- `HostInfo` fetched after connect (platform, arch, is_git_repo)
|
||||
|
||||
### Phase 4: Session integration ✓
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ $OLLIE/s/bfg "list 5 blog post ideas" | grep -v "^$" | head -3 | $OLLIE/s/bfg "e
|
|||
$OLLIE/u/optimize -n 3 -cm qwen/qwen3-8b -jm anthropic/claude-opus-4-6 "explain recursion"
|
||||
```
|
||||
|
||||
Progress goes to stderr; pipe the optimized prompt with content into a subsequent call:
|
||||
Progress goes to stderr; feed the optimized prompt with content into a subsequent call:
|
||||
|
||||
```sh
|
||||
prompt=$($OLLIE/u/optimize "translate this to Spanish" 2>/dev/null)
|
||||
|
|
@ -698,7 +698,7 @@ Each tool script embeds its documentation and metadata in comment headers:
|
|||
# **Args**: `[arg1, arg2]`
|
||||
#
|
||||
# ```
|
||||
# call_tool: calls=[{tool: "my_tool", args: ["value"]}]
|
||||
# file_edit: args=["/path", "old", "new"]
|
||||
# ```
|
||||
#
|
||||
# **Constraints**: any notes for the model.
|
||||
|
|
|
|||
Loading…
Reference in New Issue