docs: final updates

docs/src/cli.md

@@ -71,7 +71,7 @@ The `janet` format prints the `(yield)`ed value as a valid Janet expression. Thi
 
 ### recall
 
-> For this to work, you must have [enabled command detection](/command-detection.md#enabling-command-detection).
+> For this to work, you must have [enabled command detection](/command-detection.md#enabling-command-detection) and `cy` must be installed on your system (ie available in your `$PATH`.)
 
 `cy recall <reference>` prints the output of a command run in `cy` to standard output. In other words, if you run a command and later need to filter its output or pipe it to a file, you can do so without rerunning the command. `<reference>` is an identifier for a command run in `cy`.
 
@@ -108,3 +108,4 @@ You do not have to come up with these yourself. Running the {{api action/recall-
 * `node` is an integer [NodeID](/api.md#nodeid) that specifies the pane from which the command will be read.
 * `server` is the name of the socket the `cy` server is running on (the value of the `--socket-name` flag above).
 
+Both `server` and `node` can be derived by `cy` when `cy recall` is run in a pane in a `cy` server, but if `server` is specified, you can also run `cy recall` _outside of a cy server:_ `cy recall default:0:1`.

docs/src/roadmap.md

@@ -10,7 +10,7 @@
 - [ ] **Searching through all recorded sessions:** Right now {{api replay/open-file}} is not very useful. There should be a mechanism for searching all recorded `.borg` files for a string.
 - [x] [`v0.9.0`](https://github.com/cfoust/cy/releases/tag/v0.9.0) **Command-line API access:** Users should be able to run Janet code with something like `cy -c '(some-code)'` to control `cy` programmatically just like they can control `tmux`. The result of this code could be written to standard output as JSON for easy interoperability.
   - [ ] **fzf-cy\*:** `cy` literally uses `fzf`'s algorithm and its fuzzy finder should be able to be used as a drop-in replacement for `fzf` just like in [fzf-tmux](https://github.com/junegunn/fzf/blob/master/bin/fzf-tmux). In other words, `cy`'s fuzzy finder should support everything (within reason) that `fzf` does.
-- [ ] **Using the output of previous commands:** Similar to a Jupyter notebook, users should be able to access the output of previously executed commands from the command line. In essence, you could run `grep` on the output of a command you just ran without rerunning it: `cy -1 | grep 'some string'` where `-1` refers to the most recently executed command.
+- [x] [`v0.9.0`](https://github.com/cfoust/cy/releases/tag/v0.9.0) **Using the output of previous commands:** Similar to a Jupyter notebook, users should be able to access the output of previously executed commands from the command line. In essence, you could run `grep` on the output of a command you just ran without rerunning it: `cy -1 | grep 'some string'` where `-1` refers to the most recently executed command.
 - [ ] **Command history replacement\*:** The eventual goal of `cy` is to be able to replace `ctrl+r` in Bash (and other shells) with a command browser that not only lets you fuzzy-find a command among all of the commands you've ever run, but also see its output. Replaying a `.borg` file to find all the commands run inside it is an expensive operation, so it's likely that this would involve some kind of SQLite caching mechanism.
 - [ ] **Client session replay:** `cy` should record _everything_ that happens on screen and let users open replay mode for the whole session, not just for individual panes. It is up for debate whether this should be saved to disk.
   - [ ] **Smarter rendering algorithm:** `cy` uses a "damage" algorithm to detect what parts of the screen have changed and only rerender those portions. This is intended to minimize the burden on the client's terminal emulator. Unfortunately, the current approach will break searching the screen in client session recordings, so it needs to be rewritten to preserve the byte order of sequential cells that share the same styling.