# Two panes, read-only observation, explicit writing Example revision: 1. Release syntax: Paneflow 0.17.4, checked 2026-10-01. Owner: Arthur Jean. No model account, API key or model call is required. Use this with the [coordination tutorial](https://paneflow.dev/blog/paneflow-conductor). The six tutorial translations explain the same exercise. This resource contains shared commands and files; it is not another API reference. ## Files and prerequisites Install Paneflow 0.17.4 and make `paneflow` available on `PATH`. Use two ordinary shells (PowerShell on Windows, or a POSIX shell on Linux/macOS), and an existing disposable directory. Close or rename any earlier panes called `producer` or `reviewer`; ambiguous names must be replaced with the numeric IDs from discovery. - [workspace.toml](./workspace.toml): two shells in an even horizontal layout. Replace both placeholder `cwd` values with your disposable directory's absolute path. Windows TOML paths can use forward slashes. Do not add credentials or `.env`. - [prefill.flow.toml](./prefill.flow.toml): alternative two-shell setup followed by one send step, `submit = false`. Replace both paths here too. Use it instead of `workspace.toml`, never after it; otherwise you create duplicate pane names. - [expected-output.txt](./expected-output.txt): expected sentinel lines and limits. - [expected-plan.json](./expected-plan.json): release CLI dry-run result for the unedited workspace template. After replacing `cwd`, only those two values change. Save these files together. From that directory, validate before opening panes: ```sh paneflow --version paneflow up workspace.toml --dry-run paneflow flow run prefill.flow.toml --dry-run ``` Both dry runs validate syntax without touching a running instance. They do not prove that your substituted directory exists or that an app-side write gate is open. The installed 0.17.4 CLI executed both dry runs for this revision. A live two-pane interaction was not recorded for this resource; expected output is labeled accordingly. ## Reproduce the read and wait sequence With Paneflow running, explicitly create the two shells: ```sh paneflow up workspace.toml paneflow ls --human ``` In producer, type `echo TEST_OUTPUT` and press Enter. From reviewer, read it: ```sh paneflow read producer --lines 40 paneflow search producer "TEST_OUTPUT" --max 5 paneflow wait --match producer --pattern '(?m)^REPORT_DONE$' --timeout 30 ``` Start the waiter before typing `echo REPORT_DONE` and pressing Enter in producer. The waiter records a baseline and ignores text already present. Read/search can find old output; wait needs a new matching line. A timeout is a failure to observe that signal, not success. No application or file review is performed by these echoes. ## Optional write boundary The default exercise needs no scripting permission. To test prefill, deliberately launch the app with `PANEFLOW_IPC_SCRIPTING=1` (or explicitly enable AI free access). Setting a variable only on a later CLI client does not open the running app's gate. For the workspace already created with `up`, prefill with: ```sh paneflow send reviewer "echo REVIEW_DONE" ``` Alternatively, start a fresh exercise using the versioned flow below **instead of the earlier `up` command**. It creates producer and reviewer, then prefills reviewer. The release requires send steps to depend on a spawn step, so this is a complete alternative setup, not a send-only flow for an existing workspace: ```sh paneflow flow run prefill.flow.toml ``` Both write text and leave Enter to you. With scripting disabled and AI free access off, sending text fails. If only `PANEFLOW_IPC_ORCHESTRATION=1` is enabled, the flow can create both shells before its send step fails; those panes remain open. Inspect them and close or rename them before retrying, so names remain unambiguous. With both permissions disabled, the flow stops before creating panes. Do not execute both alternatives consecutively. Only a deliberate extra `--submit` on `send` would request automatic submission; it still needs the gate. The supplied TOML never enables submission. Inspect the prefilled echo and press Enter yourself to see `REVIEW_DONE`. The MCP tools `list_panes`, `read_pane` and `search_pane` only observe. They cannot perform the write step. Installing the bridge changes agent configuration and is optional; see [Scripting](https://paneflow.dev/docs/scripting). ## Limits and verification No files are changed by the echo commands. No setup/teardown, environment copy, agent launch, secret, personal path, destructive command, or automatic submit is included. Close the disposable panes manually after the exercise. Keep real terminal output untrusted and retain `ai_injection_fence`; do not use `--raw` for an agent. A full-screen TUI may replace text before it reaches scrollback. Syntax and semantics were checked against the tagged source at [v0.17.4](https://github.com/arthjean/paneflow/tree/v0.17.4/src-app/src/cli): `workspace_spec.rs`, `up_cmd.rs`, `flow_spec.rs`, `flow_cmd.rs`, `wait_cmd.rs`, `send_cmd.rs`, and the release CLI's help and dry runs. This is syntax and control-boundary evidence, not native interaction certification on three platforms. For selectors and failure codes, use the [Conductor reference](https://paneflow.dev/docs/conductor/reference). To cite the exact files, use the commit permalink for `public/examples/two-pane-coordination/` in the [site repository](https://github.com/arthjean/paneflow-web) once this revision is committed and published. Until then, these files and their links are local preparation.