morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #2132] [Feature] Interactive TUI mode for driving rea without composing one-shot commands #699

New issue

Open

opened 2026-10-15 18:27:29 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:27:29 +00:00

Owner

Originally created by @BaaRai on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2132

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

CLI

Current limitation

Running rea with no arguments prints the command list and exits. Everything after that is a single-shot process: I need to know the subcommand name, its flags, and the save-then-project flow before I see anything readable. That is fine for agents and scripts, and docs/cli.md is explicit that the CLI is designed for them, but a person at a terminal has no guided entry point. The only interactive surface today is the setup wizard (src/cli/interactiveSetup.ts).

Use cases

First contact with the tool: I installed rea, I have a binary, an APK or an app directory, and I want to see what rea can tell me about it without reading the whole CLI guide first.
Iterative inspection of one target: run an operation, read a projected view, pick the next operation. Today every step is a new process, and the working state (target path, provider, saved Evidence file) lives in my head or in shell variables.
Discovering what this machine can do: rea knows which lanes admit the target and produces detailed refusal reasons when they do not, but that information only appears after I compose the right command. An interactive mode could show the admitted workflows for the picked target up front, with the refusal text next to the unavailable ones.

Desired outcome and success criteria

An optional interactive session that:

Launches explicitly (for example rea ui), or is offered when rea runs with no arguments attached to a TTY. Bare rea with piped stdio and --help keep printing the command list unchanged, so scripts see no difference.
Lets me pick or type a target path, then lists the workflows that admit it and shows why the others refuse.
Runs an operation on that target and pages through a projected view of the result (the same views inspect-analysis-view already renders) instead of dumping raw multi-megabyte JSON.
Keeps the target and the saved Evidence across operations, so follow-up commands do not re-take paths and provider flags.
Adds no new analysis capability: it is a selection and rendering layer over the existing commands and Evidence contracts, and machine-readable output stays unchanged when the mode is not used.

Authority boundaries and non-goals

No target mutation beyond what the underlying commands already perform; the interactive layer grants no additional privilege and starts no providers by itself.
Non-interactive behavior (CI, scripts, agent drivers) must remain unchanged.
A web dashboard or GUI is out of scope here; this request is about the terminal entry point.
Rendering should stay light in dependencies, consistent with a globally installed CLI.

Alternatives considered

Driving rea through a coding agent: the intended path and it works well, but it requires an agent client to be installed and configured, which is not always the case on the machine where the CLI was just installed, and quick lookups feel heavy there.
Reading docs/cli.md and composing commands: possible today, and it is exactly the entry cost described above. Each invocation is also stateless, so multi-step investigations mean manual bookkeeping.
Projecting saved Evidence with jq plus inspect-analysis-view: still requires knowing the view vocabulary and repeating the two-step save and project for every question.

Possible direction

A thin session loop over the existing command registry. The CLI already knows every command schema, and the admission checks plus the summary and page views already exist. The session would hold the current target and Evidence path, annotate the command list with admission results for that target, and delegate execution to the same workflows. Whether bare rea in a TTY should open the session directly or only print a hint pointing to it is a maintainer call; an explicit subcommand keeps the default behavior safe either way.

References

docs/cli.md, in particular the single-invocation model and the saved-Evidence projection flow around inspect-analysis-view
The interactive setup adapter precedent in src/cli/interactiveSetup.ts (issue #398 fixed an early wizard defect there)

Originally created by @BaaRai on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2132 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area CLI ### Current limitation Running `rea` with no arguments prints the command list and exits. Everything after that is a single-shot process: I need to know the subcommand name, its flags, and the save-then-project flow before I see anything readable. That is fine for agents and scripts, and docs/cli.md is explicit that the CLI is designed for them, but a person at a terminal has no guided entry point. The only interactive surface today is the setup wizard (src/cli/interactiveSetup.ts). ### Use cases - First contact with the tool: I installed rea, I have a binary, an APK or an app directory, and I want to see what rea can tell me about it without reading the whole CLI guide first. - Iterative inspection of one target: run an operation, read a projected view, pick the next operation. Today every step is a new process, and the working state (target path, provider, saved Evidence file) lives in my head or in shell variables. - Discovering what this machine can do: rea knows which lanes admit the target and produces detailed refusal reasons when they do not, but that information only appears after I compose the right command. An interactive mode could show the admitted workflows for the picked target up front, with the refusal text next to the unavailable ones. ### Desired outcome and success criteria An optional interactive session that: 1. Launches explicitly (for example `rea ui`), or is offered when `rea` runs with no arguments attached to a TTY. Bare `rea` with piped stdio and `--help` keep printing the command list unchanged, so scripts see no difference. 2. Lets me pick or type a target path, then lists the workflows that admit it and shows why the others refuse. 3. Runs an operation on that target and pages through a projected view of the result (the same views `inspect-analysis-view` already renders) instead of dumping raw multi-megabyte JSON. 4. Keeps the target and the saved Evidence across operations, so follow-up commands do not re-take paths and provider flags. 5. Adds no new analysis capability: it is a selection and rendering layer over the existing commands and Evidence contracts, and machine-readable output stays unchanged when the mode is not used. ### Authority boundaries and non-goals - No target mutation beyond what the underlying commands already perform; the interactive layer grants no additional privilege and starts no providers by itself. - Non-interactive behavior (CI, scripts, agent drivers) must remain unchanged. - A web dashboard or GUI is out of scope here; this request is about the terminal entry point. - Rendering should stay light in dependencies, consistent with a globally installed CLI. ### Alternatives considered - Driving rea through a coding agent: the intended path and it works well, but it requires an agent client to be installed and configured, which is not always the case on the machine where the CLI was just installed, and quick lookups feel heavy there. - Reading docs/cli.md and composing commands: possible today, and it is exactly the entry cost described above. Each invocation is also stateless, so multi-step investigations mean manual bookkeeping. - Projecting saved Evidence with jq plus `inspect-analysis-view`: still requires knowing the view vocabulary and repeating the two-step save and project for every question. ### Possible direction A thin session loop over the existing command registry. The CLI already knows every command schema, and the admission checks plus the summary and page views already exist. The session would hold the current target and Evidence path, annotate the command list with admission results for that target, and delegate execution to the same workflows. Whether bare `rea` in a TTY should open the session directly or only print a hint pointing to it is a maintainer call; an explicit subcommand keeps the default behavior safe either way. ### References - docs/cli.md, in particular the single-invocation model and the saved-Evidence projection flow around `inspect-analysis-view` - The interactive setup adapter precedent in src/cli/interactiveSetup.ts (issue #398 fixed an early wizard defect there)

bsakaguchi added the

P3: low

area: cli

enhancement

labels

2026-10-15 18:27:29 +00:00

bsakaguchi commented

2026-10-15 18:27:30 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Design & Architectural Boundary Notes

While an interactive terminal UI (TUI) provides a welcoming user experience for human analysts exploring binaries:

Core Focus & Resource Bounds: REA's primary architectural contract prioritizes agent/LLM-first headless workflows via shared CLI JSON endpoints and MCP servers (AGENTS.md and docs/cli.md).
Implementation Strategy: Rather than embedding heavy interactive terminal libraries (like Ink or Blessed) into core dependencies, an interactive mode should sit either:
1. As an optional subcommand (rea tui <target>) or companion CLI package (@rea-agents/tui) consuming existing CLI JSON commands under the hood.
2. Or driven via interactive agent REPL prompts (e.g. Claude Code / Codex skill guidance).

@matbrgz commented on GitHub (Oct 12, 2026): ### Design & Architectural Boundary Notes While an interactive terminal UI (TUI) provides a welcoming user experience for human analysts exploring binaries: - **Core Focus & Resource Bounds:** REA's primary architectural contract prioritizes agent/LLM-first headless workflows via shared CLI JSON endpoints and MCP servers (`AGENTS.md` and `docs/cli.md`). - **Implementation Strategy:** Rather than embedding heavy interactive terminal libraries (like Ink or Blessed) into core dependencies, an interactive mode should sit either: 1. As an optional subcommand (`rea tui <target>`) or companion CLI package (`@rea-agents/tui`) consuming existing CLI JSON commands under the hood. 2. Or driven via interactive agent REPL prompts (e.g. Claude Code / Codex skill guidance).

bsakaguchi referenced this issue

2026-10-15 18:28:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:15:17 +00:00

[PR #699] [MERGED] feat(ghidra): enable Windows x64 read-only analysis #2179

bsakaguchi referenced this issue

2026-10-16 21:15:24 +00:00

[PR #705] [MERGED] fix: integrate 14 approved fix PRs (668,671,673,675,678-681,685-690) #2185

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:29:27 +00:00

bsakaguchi commented

2026-10-31 00:29:28 +00:00

Author

Owner

@BaaRai commented on GitHub (Oct 18, 2026):

Thanks matbrgz, this is a useful boundary check and I agree with the core constraints.

The proposal is narrower than a general TUI: no new analysis capability, no new authority, and no change to any agent-facing surface. It is a session shell that selects existing commands and pages existing views.

On your two options I lean to the first, and I would take your wording over mine: rea tui <target> as an optional subcommand that consumes the same CLI JSON commands under the hood. Concretely what that needs:

No Ink or Blessed. A line-oriented prompt with ANSI paging covers it, and it can live behind a separate entry point that the main CLI path does not import, so startup cost and dependency weight for agents stay exactly as they are.
If maintainers prefer a companion package, the same code can ship as @rea-agents/tui with rea as a peer dependency.

The agent-first path stays the default. Bare rea keeps printing the command list, --help is unchanged, and piped stdio is unchanged. Only an explicit rea tui opens a session. After your comment I would not gate anything on a TTY heuristic either, since that makes behavior differ by environment for no benefit.

The one piece of state it keeps, the current target and saved Evidence path, is what makes the second invocation cheaper than retyping flags and provider selection. Everything else delegates to the existing commands, including the admission results, the refusal text, and the projection views that inspect-analysis-view already renders.

On the interactive agent REPL: that is the better path when an agent client is installed, and I use it. The gap here is a machine where rea was just installed as a CLI and no agent is configured, which is also the moment a new user forms an opinion of the tool.

If that scope is acceptable, I can prototype rea tui <target> with no core dependency change and post the diff for review before anything else.

@BaaRai commented on GitHub (Oct 18, 2026): Thanks matbrgz, this is a useful boundary check and I agree with the core constraints. The proposal is narrower than a general TUI: no new analysis capability, no new authority, and no change to any agent-facing surface. It is a session shell that selects existing commands and pages existing views. On your two options I lean to the first, and I would take your wording over mine: `rea tui <target>` as an optional subcommand that consumes the same CLI JSON commands under the hood. Concretely what that needs: - No Ink or Blessed. A line-oriented prompt with ANSI paging covers it, and it can live behind a separate entry point that the main CLI path does not import, so startup cost and dependency weight for agents stay exactly as they are. - If maintainers prefer a companion package, the same code can ship as `@rea-agents/tui` with rea as a peer dependency. The agent-first path stays the default. Bare `rea` keeps printing the command list, `--help` is unchanged, and piped stdio is unchanged. Only an explicit `rea tui` opens a session. After your comment I would not gate anything on a TTY heuristic either, since that makes behavior differ by environment for no benefit. The one piece of state it keeps, the current target and saved Evidence path, is what makes the second invocation cheaper than retyping flags and provider selection. Everything else delegates to the existing commands, including the admission results, the refusal text, and the projection views that `inspect-analysis-view` already renders. On the interactive agent REPL: that is the better path when an agent client is installed, and I use it. The gap here is a machine where rea was just installed as a CLI and no agent is configured, which is also the moment a new user forms an opinion of the tool. If that scope is acceptable, I can prototype `rea tui <target>` with no core dependency change and post the diff for review before anything else.

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#699

No description provided.

Rows
Columns