[GH-ISSUE #8448] [Design] Clarify CLI Evidence import versus MCP session retention #6607

New issue

Open

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

bsakaguchi commented

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

Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8448

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

How should rea evidence-import make its process-local validation outcome distinct from MCP's session-persistent import_evidence_bundle?

Context and evidence

On #8444 at f2de739f6 on macOS arm64, I ran rea evidence-import <canonical-bundle> --json on a one-record bundle. The command returned {"imported":1,"unknowns_added":0,"total":1}. A newly started target-free stdio MCP server had zero records; calling its own import_evidence_bundle on the same path then added one record. This confirms the CLI result does not populate that separate investigation; it does not test communicating with an already running MCP server.

Source inspection on main e18594b24 shows the CLI help says “Validate and import a bounded local Evidence bundle”, while its implementation reads and validates the bundle, returns its counts, and has no session owner. The CLI guide describes this as validation, so the discrepancy is in the command/help and receipt semantics rather than a claim that the guide promises persistence. No provider or target was started for the control.

Expected interaction with targets

No target interaction (documentation or usability only).

Boundary details (optional)

Keep CLI validation and MCP session mutation distinct; preserve Evidence authentication, caller-selected files, and canonical bundle semantics. Do not imply cross-process persistence or change an existing investigation without an explicit owner.

Options and tradeoffs

Consider clearer CLI help and a receipt naming the records as validated, an explicitly named validation command, or another contract that makes the difference obvious. Changing machine-readable receipt fields or command names can affect clients; assess actual usage and versioning instead of adding a compatibility alias by default.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise the documented CLI-to-MCP handoff and verify the CLI result explains what it did. Test human and JSON output as well as the named MCP session; confirm whether agents infer persistence in a representative workflow. The current observation alone does not measure agent confusion.

References

Related to #8427 and #8433; those concern recovering or retaining a selected Evidence record, whereas this question concerns what a successful CLI import receipt means. Source: src/cliEvidenceCommands.ts, src/application/EvidenceBundleCommands.ts; documentation: docs/cli.md, “Import, export and compare Evidence”.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8448 ### 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 How should `rea evidence-import` make its process-local validation outcome distinct from MCP's session-persistent `import_evidence_bundle`? ### Context and evidence On #8444 at `f2de739f6` on macOS arm64, I ran `rea evidence-import <canonical-bundle> --json` on a one-record bundle. The command returned `{"imported":1,"unknowns_added":0,"total":1}`. A newly started target-free stdio MCP server had zero records; calling its own `import_evidence_bundle` on the same path then added one record. This confirms the CLI result does not populate that separate investigation; it does not test communicating with an already running MCP server. Source inspection on main `e18594b24` shows the CLI help says “Validate and import a bounded local Evidence bundle”, while its implementation reads and validates the bundle, returns its counts, and has no session owner. The CLI guide describes this as validation, so the discrepancy is in the command/help and receipt semantics rather than a claim that the guide promises persistence. No provider or target was started for the control. ### Expected interaction with targets No target interaction (documentation or usability only). ### Boundary details (optional) Keep CLI validation and MCP session mutation distinct; preserve Evidence authentication, caller-selected files, and canonical bundle semantics. Do not imply cross-process persistence or change an existing investigation without an explicit owner. ### Options and tradeoffs Consider clearer CLI help and a receipt naming the records as validated, an explicitly named validation command, or another contract that makes the difference obvious. Changing machine-readable receipt fields or command names can affect clients; assess actual usage and versioning instead of adding a compatibility alias by default. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise the documented CLI-to-MCP handoff and verify the CLI result explains what it did. Test human and JSON output as well as the named MCP session; confirm whether agents infer persistence in a representative workflow. The current observation alone does not measure agent confusion. ### References Related to #8427 and #8433; those concern recovering or retaining a selected Evidence record, whereas this question concerns what a successful CLI import receipt means. Source: `src/cliEvidenceCommands.ts`, `src/application/EvidenceBundleCommands.ts`; documentation: `docs/cli.md`, “Import, export and compare Evidence”. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

enhancement

triage

labels

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

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

No description provided.

Rows
Columns