readme: add filesystem-as-interface and simple front-ends to observed benefits
This commit is contained in:
parent
8b55fc3895
commit
a15965b8a7
|
|
@ -60,6 +60,10 @@ git submodule update --remote
|
|||
|
||||
## Observed Benefits
|
||||
|
||||
**Filesystem as interface** — if you know how to operate a filesystem, you know how to operate ollie. Rename a session → `mv` the session directory. Start a new session → open `s/new`, fill in the fields, save. Prompt the agent → write your prompt to `s/{id}/prompt`. Check status → `cat s/{id}/state`. Any tool that reads and writes files — shell scripts, `ed`, a GUI file manager, `vim`, Python, even `cat` and `echo` — is already a fully capable ollie client. No SDK, no API, no protocol to learn.
|
||||
|
||||
**Simple front-ends** — building a front-end is just reading and writing files. A TUI reads `chat`, writes `prompt`, polls `state`. A web UI does the same over a thin bridge. An Emacs mode opens files it already knows how to edit. The protocol surface is zero because the protocol *is* the filesystem.
|
||||
|
||||
**Crash resiliency** — `reasoning_plan` persists plans to the `ollie/pl` filesystem by default. If a session crashes or is killed mid-task, recovery is trivial: point a fresh session at the plan that was being executed. The agent's prompting already tells it how to discover plans in `pl/`, so it can resume cold — reading the plan, seeing which steps are done and which aren't, and picking up where the previous session left off. No context replay, no manual re-prompting, no lost work.
|
||||
|
||||
## Credits
|
||||
|
|
|
|||
Loading…
Reference in New Issue