morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #8398] [Design] Give `capture_process_scenario` a prepare-only mode so the preparation prompt can suggest a non-executing call #6585

New issue

Open

opened 2026-11-01 21:12:26 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:26 +00:00

Owner

Originally created by @trackoor on GitHub (Oct 31, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8398

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Should capture_process_scenario accept a dry_run (prepare-only) request that validates the scenario and returns the resolved plan without spawning the command, so that the prepare_bounded_process_capture prompt can suggest a tool call that cannot execute the target? Or should that prompt's first step suggest no tool at all?

Context and evidence

Source-derived, from main at 6e9ee97a69; no agent run is claimed.

docs/mcp-prompts.md:62 describes prepare_bounded_process_capture as "Design a bounded controlled process experiment before execution", and after #3954 its first step says "Prepare the scenario without running it ... A selected executable and working directory do not authorize execution" (src/contracts/promptContracts.ts:437-440).
That same step still lists capture_process_scenario as its tool (promptContracts.ts:437), and that tool has one behavior: "Run one caller-selected command under a PTY" (src/contracts/sessionToolContracts.ts:104-108). Its input schema (src/domain/process/processScenario.ts:180) has no field that asks for validation without a launch, and its effect audit marks it executesForeignCode and idempotent: false (src/contracts/toolEffects.ts:740-747). PR #4664 kept "prompt arguments, tool suggestions, provider behavior and authority unchanged".
The rendered prompt therefore pairs an instruction not to run anything with the only tool that runs it, and a consuming agent that follows the "Tools:" line of the step has no non-executing call to make. Of the six guided workflows, this is the only step whose suggested tool executes a caller-selected command while its instruction asks for preparation only. (We ran a static policy check over the six prompt contracts using the tool effects from toolEffects.ts; the other steps that suggest executing tools, trace_crash step 4 and the comparison steps, do ask for execution.)
Precedent inside REA: export_environment_bundle has dry_run, which "reports without writing" and "still checks output_directory" (src/contracts/environmentToolContracts.ts:14,36).
Unknown: how often consuming agents call the suggested tool from a preparation prompt. NOT_ENOUGH_INFO; the regression in tests/boundary/mcp/promptMcp.test.ts:230-235 checks the rendered text and zero executions during rendering, not agent behavior.

Expected interaction with targets

No target interaction (documentation or usability only) for the dry run itself: the proposed mode resolves the command, working directory, environment, budgets and observation paths and returns them, and launches nothing. (The existing non-dry-run call keeps its declared effects.)

Boundary details (optional)

A dry run should carry the same admission checks as a run (terminal cell budget, environment key rules, reserved REA_PROCESS_RUN_ID, absolute paths) so that a later real capture with the same scenario is not refused for a reason the plan did not show.
Its Evidence record should say status: "planned" (as the environment build's dry run does) so a retained planned scenario is never mistaken for a capture.

Options and tradeoffs

dry_run: true on capture_process_scenario: one tool, one schema, the prompt's step suggests the same tool with dry_run: true. Mirrors export_environment_bundle.
A separate prepare_process_scenario tool: clearer effect audit (effects()), one more catalog entry.
No tool in the first step of prepare_bounded_process_capture (the design happens in the agent's answer), compare_process_captures stays in step 2. Smallest change; the step then has no Tools: line.

Verification available so far

I can suggest a sample or manual check: prompts/get prepare_bounded_process_capture, then the suggested call with dry_run: true for /usr/bin/true, asserting a planned result and no process launch (the existing promptMcp test already asserts zero executions during rendering and could cover the planned call).

Success criteria and open questions

A consuming agent that follows the preparation prompt's suggestions cannot execute the selected command without a separately requested capture.
Open: whether the planned scenario should be reusable by reference (an Evidence id) by the later capture.

References

docs/mcp-prompts.md:62; src/contracts/promptContracts.ts:414-452; src/contracts/sessionToolContracts.ts:104-108
src/domain/process/processScenario.ts:180; src/contracts/toolEffects.ts:740-747
src/contracts/environmentToolContracts.ts:14,36 (the dry_run precedent)
#3954, #4664

Originally created by @trackoor on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8398 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Should `capture_process_scenario` accept a `dry_run` (prepare-only) request that validates the scenario and returns the resolved plan without spawning the command, so that the `prepare_bounded_process_capture` prompt can suggest a tool call that cannot execute the target? Or should that prompt's first step suggest no tool at all? ### Context and evidence Source-derived, from main at 6e9ee97a69cb16c7150d8b550e705cba055ee4f0; no agent run is claimed. - `docs/mcp-prompts.md:62` describes `prepare_bounded_process_capture` as "Design a bounded controlled process experiment before execution", and after #3954 its first step says "Prepare the scenario without running it ... A selected executable and working directory do not authorize execution" (`src/contracts/promptContracts.ts:437-440`). - That same step still lists `capture_process_scenario` as its tool (`promptContracts.ts:437`), and that tool has one behavior: "Run one caller-selected command under a PTY" (`src/contracts/sessionToolContracts.ts:104-108`). Its input schema (`src/domain/process/processScenario.ts:180`) has no field that asks for validation without a launch, and its effect audit marks it `executesForeignCode` and `idempotent: false` (`src/contracts/toolEffects.ts:740-747`). PR #4664 kept "prompt arguments, tool suggestions, provider behavior and authority unchanged". - The rendered prompt therefore pairs an instruction not to run anything with the only tool that runs it, and a consuming agent that follows the "Tools:" line of the step has no non-executing call to make. Of the six guided workflows, this is the only step whose suggested tool executes a caller-selected command while its instruction asks for preparation only. (We ran a static policy check over the six prompt contracts using the tool effects from `toolEffects.ts`; the other steps that suggest executing tools, `trace_crash` step 4 and the comparison steps, do ask for execution.) - Precedent inside REA: `export_environment_bundle` has `dry_run`, which "reports without writing" and "still checks output_directory" (`src/contracts/environmentToolContracts.ts:14,36`). - Unknown: how often consuming agents call the suggested tool from a preparation prompt. `NOT_ENOUGH_INFO`; the regression in `tests/boundary/mcp/promptMcp.test.ts:230-235` checks the rendered text and zero executions during rendering, not agent behavior. ### Expected interaction with targets No target interaction (documentation or usability only) for the dry run itself: the proposed mode resolves the command, working directory, environment, budgets and observation paths and returns them, and launches nothing. (The existing non-dry-run call keeps its declared effects.) ### Boundary details (optional) - A dry run should carry the same admission checks as a run (terminal cell budget, environment key rules, reserved `REA_PROCESS_RUN_ID`, absolute paths) so that a later real capture with the same scenario is not refused for a reason the plan did not show. - Its Evidence record should say `status: "planned"` (as the environment build's dry run does) so a retained planned scenario is never mistaken for a capture. ### Options and tradeoffs 1. `dry_run: true` on `capture_process_scenario`: one tool, one schema, the prompt's step suggests the same tool with `dry_run: true`. Mirrors `export_environment_bundle`. 2. A separate `prepare_process_scenario` tool: clearer effect audit (`effects()`), one more catalog entry. 3. No tool in the first step of `prepare_bounded_process_capture` (the design happens in the agent's answer), `compare_process_captures` stays in step 2. Smallest change; the step then has no `Tools:` line. ### Verification available so far I can suggest a sample or manual check: `prompts/get prepare_bounded_process_capture`, then the suggested call with `dry_run: true` for `/usr/bin/true`, asserting a `planned` result and no process launch (the existing promptMcp test already asserts zero executions during rendering and could cover the planned call). ### Success criteria and open questions - A consuming agent that follows the preparation prompt's suggestions cannot execute the selected command without a separately requested capture. - Open: whether the planned scenario should be reusable by reference (an Evidence id) by the later capture. ### References - `docs/mcp-prompts.md:62`; `src/contracts/promptContracts.ts:414-452`; `src/contracts/sessionToolContracts.ts:104-108` - `src/domain/process/processScenario.ts:180`; `src/contracts/toolEffects.ts:740-747` - `src/contracts/environmentToolContracts.ts:14,36` (the `dry_run` precedent) - #3954, #4664

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6585

No description provided.

Rows
Columns

[GH-ISSUE #8398] [Design] Give capture_process_scenario a prepare-only mode so the preparation prompt can suggest a non-executing call #6585