morluto/rea

Fork 0

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

[GH-ISSUE #1252] feat(process): expose bounded live capture progress through CLI and MCP #450

New issue

Closed

opened 2026-10-15 18:25:09 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-15 18:25:09 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 9, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1252

Current limitation

The capture-process --json CLI emits final Evidence after the operation finishes, with no ongoing lifecycle/status stream. MCP emits started/completed notifications when the client supplies a progress token, but no elapsed/capture-unit updates during the run. Long sparse captures can therefore appear inactive while the child is progressing.

Executed observation

A finite child prints started, waits two seconds, then prints completed. On current main, the CLI emits its only stdout chunk after approximately 5.05 seconds overall, then exits0; stderr has no progress chunks. Overall time includes CLI startup and settlement. The published package behaves similarly. A real MCP timeout capture with onprogress receives only started and completed notifications.

Required behavior

Provide an optional structured live status/progress surface that keeps final JSON Evidence valid and separate. Report observed lifecycle phase, elapsed time and collected units with a bounded notification rate; unknown totals remain unknown. Avoid printing unrestricted child output or inventing percentages. CLI users should be able to monitor a long run without reading private producer files or inspecting PIDs manually.

Reuse the shared application progress boundary for CLI/MCP. Verify output separation, no-progress-token clients, sparse and busy children, timeout/cancellation and final cleanup status. Native cold-start phase visibility can reuse the same boundary but is not established by this process-only probe.

Source and relationship

src/application/process/ProcessCli.ts:47 and src/server/registerSessionTools.ts. Narrow follow-up to closed #98, which delivered the general progress/cancellation surface; related #1065. #1232/#1233 independently track observed interruption/settlement cancellation defects.

Verification and scope

Short real CLI and MCP probes executed on published/main. This does not claim that MCP has no progress support or that buffered CLI output proves a hung child.

Audit date: 2026-10-09. Latest npm dist-tag verified as rea-agents@6.1.0; current main tested at f4c99ab8a53806dd57dc24b3d5a600905bcb4686. Linux x64, Node 24.18.0, MCP client SDK 2.3.1. Native observations use unmodified Ghidra 12.1.4 and JDK 21, two CPUs and a 512 MiB Java heap. No target execution or executable mutation was used for the static native checks.

Originally created by @N0zoM1z0 on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1252 ### Current limitation The `capture-process --json` CLI emits final Evidence after the operation finishes, with no ongoing lifecycle/status stream. MCP emits started/completed notifications when the client supplies a progress token, but no elapsed/capture-unit updates during the run. Long sparse captures can therefore appear inactive while the child is progressing. ### Executed observation A finite child prints `started`, waits two seconds, then prints `completed`. On current main, the CLI emits its only stdout chunk after approximately 5.05 seconds overall, then exits0; stderr has no progress chunks. Overall time includes CLI startup and settlement. The published package behaves similarly. A real MCP timeout capture with `onprogress` receives only started and completed notifications. ### Required behavior Provide an optional structured live status/progress surface that keeps final JSON Evidence valid and separate. Report observed lifecycle phase, elapsed time and collected units with a bounded notification rate; unknown totals remain unknown. Avoid printing unrestricted child output or inventing percentages. CLI users should be able to monitor a long run without reading private producer files or inspecting PIDs manually. Reuse the shared application progress boundary for CLI/MCP. Verify output separation, no-progress-token clients, sparse and busy children, timeout/cancellation and final cleanup status. Native cold-start phase visibility can reuse the same boundary but is not established by this process-only probe. ### Source and relationship [src/application/process/ProcessCli.ts:47](https://github.com/morluto/rea/blob/f4c99ab8a53806dd57dc24b3d5a600905bcb4686/src/application/process/ProcessCli.ts#L47) and `src/server/registerSessionTools.ts`. Narrow follow-up to closed #98, which delivered the general progress/cancellation surface; related #1065. #1232/#1233 independently track observed interruption/settlement cancellation defects. ### Verification and scope Short real CLI and MCP probes executed on published/main. This does not claim that MCP has no progress support or that buffered CLI output proves a hung child. Audit date: 2026-10-09. Latest npm dist-tag verified as `rea-agents@6.1.0`; current main tested at `f4c99ab8a53806dd57dc24b3d5a600905bcb4686`. Linux x64, Node 24.18.0, MCP client SDK 2.3.1. Native observations use unmodified Ghidra 12.1.4 and JDK 21, two CPUs and a 512 MiB Java heap. No target execution or executable mutation was used for the static native checks.

bsakaguchi

2026-10-15 18:25:09 +00:00

closed this issue
added the
area: cli

area: mcp

triage

enhancement

P2: medium
labels

bsakaguchi commented

2026-10-15 18:25:10 +00:00

Author

Owner

@sathariels commented on GitHub (Oct 10, 2026):

Hi! I'd like to take this one. Rough plan:

Pass the existing rate-limited reporter from src/application/ProgressReporter.ts into captureProcessScenario and the capture lifecycle, and report observed phase, elapsed time and collected-unit counts as they happen. No totals or percentages unless they're actually known.
MCP: forward these as progress notifications only when the client sent a progress token; clients without one see no change.
CLI: write them as progress lines on stderr (same idea as the rea_progress lines in src/cli/javascriptApplicationAnalysis.ts), so the final JSON Evidence on stdout stays exactly as it is.
Tests for stdout/stderr separation, no-token MCP clients, a sparse and a busy child, timeout/cancellation, and final cleanup status.

Does that match what you had in mind, especially the stderr format for the CLI?

@sathariels commented on GitHub (Oct 10, 2026): Hi! I'd like to take this one. Rough plan: - Pass the existing rate-limited reporter from `src/application/ProgressReporter.ts` into `captureProcessScenario` and the capture lifecycle, and report observed phase, elapsed time and collected-unit counts as they happen. No totals or percentages unless they're actually known. - MCP: forward these as progress notifications only when the client sent a progress token; clients without one see no change. - CLI: write them as progress lines on stderr (same idea as the `rea_progress` lines in `src/cli/javascriptApplicationAnalysis.ts`), so the final JSON Evidence on stdout stays exactly as it is. - Tests for stdout/stderr separation, no-token MCP clients, a sparse and a busy child, timeout/cancellation, and final cleanup status. Does that match what you had in mind, especially the stderr format for the CLI?

bsakaguchi commented

2026-10-15 18:25:10 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 10, 2026):

Yes, that matches the intended scope. Please use the shared rate-limited reporter and the existing rea_progress JSON-line format on stderr; keep final Evidence JSON alone on stdout.

Report observed capture/settlement/cleanup phases, elapsed time and collected units, with unknown totals left unknown. Keep progress optional, bounded and free of unrestricted child-output forwarding. MCP should send it only for a caller-supplied progress token. The proposed sparse/busy, no-token, timeout/cancellation and cleanup checks are the right boundaries. This process-capture work does not establish native-provider cold-start progress or completion.

Thanks for taking #1252. I am continuing the adjacent large-file responsiveness, schema-validator cost and native-result investigations under #1065, so I will avoid duplicating this implementation while your change is in progress.

@N0zoM1z0 commented on GitHub (Oct 10, 2026): Yes, that matches the intended scope. Please use the shared rate-limited reporter and the existing `rea_progress` JSON-line format on stderr; keep final Evidence JSON alone on stdout. Report observed capture/settlement/cleanup phases, elapsed time and collected units, with unknown totals left unknown. Keep progress optional, bounded and free of unrestricted child-output forwarding. MCP should send it only for a caller-supplied progress token. The proposed sparse/busy, no-token, timeout/cancellation and cleanup checks are the right boundaries. This process-capture work does not establish native-provider cold-start progress or completion. Thanks for taking #1252. I am continuing the adjacent large-file responsiveness, schema-validator cost and native-result investigations under #1065, so I will avoid duplicating this implementation while your change is in progress.

bsakaguchi commented

2026-10-15 18:25:10 +00:00

Author

Owner

@sathariels commented on GitHub (Oct 10, 2026):

Thanks, that all makes sense, and I'll keep native cold-start out of scope. I'm on it now and should have the PR up in around 7 hours.

@sathariels commented on GitHub (Oct 10, 2026): Thanks, that all makes sense, and I'll keep native cold-start out of scope. I'm on it now and should have the PR up in around 7 hours.

bsakaguchi referenced this issue

2026-10-15 18:31:03 +00:00

[GH-ISSUE #3153] [Feature] Inventory Windows Installer (.msi / OLE CFB) packages read-only: streams, embedded cabinets and File-table names #1099

bsakaguchi referenced this issue

2026-10-16 21:13:12 +00:00

[PR #450] [MERGED] feat(package): add MSIX/MSI/AppX package, resource, and signature analysis #1995

bsakaguchi added

enhancement

and removed

enhancement

labels

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