[GH-ISSUE #8347] feat(investigation): separate record lifetime from engine cleanup #6554

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

Originally created by @gensokyo-dev on GitHub (Oct 31, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8347

Before submitting

  • I searched open and closed issues and pull requests for related work.
  • I understand the contribution scope must be reviewed before integration.
  • This request contains no credentials, private samples or sensitive target data.

Area

Evidence, artifacts, or reconstruction; CLI/MCP integration.

Current limitation

At main 60149282f, BinarySession.close() defaults to clearing both the investigation ledger and analysis snapshot state. Direct target switching already preserves records. Explicit close_binary clears records even without an active target, and its record clear runs before the final cleanup failure result is returned. InvestigationRecords is structurally separate but its lifecycle is still controlled by the engine session.

An isolated public stdio MCP probe imported two authentic earlier jq captures and added authored Unknown revision history. It observed 4 Evidence records / 2 Unknown revisions before a target-free close_binary, 0 / 0 after, then an exact missing-reference error. Importing an explicitly exported bundle restored the complete data. The executed build was the earlier merged Evidence refactor; the relevant close/record source implementations match the pinned main. This is not a new real-provider execution claim.

Desired outcome and success criteria

  • Engine close frees provider/target resources and invalidates engine replay state while preserving complete investigation Evidence, Unknown revisions and exact references across domains, including no-target and cleanup-failure paths.
  • An explicit reset_investigation operation drains admitted work and clears the investigation plus source/replay bindings, without closing a healthy active engine. Later work cannot repopulate the cleared investigation from an older admitted request.
  • An optional caller-selected save path checkpoints the complete canonical Evidence bundle before reset. Save/cancellation/cleanup failure preserves the records and publication facts. A fresh process can authenticate/import that file and recover original references and Unknown history.
  • Retained state has an explicit resource admission boundary and efficient accounting. Refused additions do not evict old records or partially commit an Unknown transaction. Returned state stays compact; existing filtered/paged complete Evidence access remains available.
  • Shared application owners serve MCP and existing CLI bundle workflows. No empty one-shot CLI reset command is required.

Expected interaction with targets

Read existing files or captured data; write caller-selected Evidence bundle checkpoints; release existing owned provider resources. Reset clears the current connection's investigation records. No new target execution, injection, memory/register mutation, protection recovery or provider capability.

Scope and alternatives

This is an intentional lifecycle-contract change following the new caller-requested direction, superseding the clear-on-target-close policy discussed in #50/#721. Keep the existing bundle format, authentication and atomic file owner. Do not persist to an undisclosed location. Continuous append-only journaling, crash-durable acknowledgement of every record, persistent engine databases, and multi-workspace catalogs remain separate work (#4809, #8165).

Verification available so far

Observed public MCP reproduction described above; resource scope used one CPU, 4GiB hard / 3GiB early-stop memory and verified process cleanup. The probe took 5.145s with 297,570,304-byte kernel family peak and no OOM. Planned verification: lifecycle and capacity boundaries, real CLI/MCP workflows across native/managed/JS/mobile/WASM/process artifacts, actual local Codex CLI gpt-6.1-terra / high, exact identities/coverage/Unknown history, cancellation/finalization/failure recovery, and explicit checkpoint transfer to a fresh process. No controlled performance improvement is claimed yet.

References

#721, #50, #740, #4809, #8293, #4002, #7671.

Originally created by @gensokyo-dev on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8347 ### Before submitting - [x] I searched open and closed issues and pull requests for related work. - [x] I understand the contribution scope must be reviewed before integration. - [x] This request contains no credentials, private samples or sensitive target data. ### Area Evidence, artifacts, or reconstruction; CLI/MCP integration. ### Current limitation At main `60149282f`, `BinarySession.close()` defaults to clearing both the investigation ledger and analysis snapshot state. Direct target switching already preserves records. Explicit `close_binary` clears records even without an active target, and its record clear runs before the final cleanup failure result is returned. `InvestigationRecords` is structurally separate but its lifecycle is still controlled by the engine session. An isolated public stdio MCP probe imported two authentic earlier jq captures and added authored Unknown revision history. It observed 4 Evidence records / 2 Unknown revisions before a target-free `close_binary`, 0 / 0 after, then an exact missing-reference error. Importing an explicitly exported bundle restored the complete data. The executed build was the earlier merged Evidence refactor; the relevant close/record source implementations match the pinned main. This is not a new real-provider execution claim. ### Desired outcome and success criteria - Engine close frees provider/target resources and invalidates engine replay state while preserving complete investigation Evidence, Unknown revisions and exact references across domains, including no-target and cleanup-failure paths. - An explicit `reset_investigation` operation drains admitted work and clears the investigation plus source/replay bindings, without closing a healthy active engine. Later work cannot repopulate the cleared investigation from an older admitted request. - An optional caller-selected save path checkpoints the complete canonical Evidence bundle before reset. Save/cancellation/cleanup failure preserves the records and publication facts. A fresh process can authenticate/import that file and recover original references and Unknown history. - Retained state has an explicit resource admission boundary and efficient accounting. Refused additions do not evict old records or partially commit an Unknown transaction. Returned state stays compact; existing filtered/paged complete Evidence access remains available. - Shared application owners serve MCP and existing CLI bundle workflows. No empty one-shot CLI reset command is required. ### Expected interaction with targets Read existing files or captured data; write caller-selected Evidence bundle checkpoints; release existing owned provider resources. Reset clears the current connection's investigation records. No new target execution, injection, memory/register mutation, protection recovery or provider capability. ### Scope and alternatives This is an intentional lifecycle-contract change following the new caller-requested direction, superseding the clear-on-target-close policy discussed in #50/#721. Keep the existing bundle format, authentication and atomic file owner. Do not persist to an undisclosed location. Continuous append-only journaling, crash-durable acknowledgement of every record, persistent engine databases, and multi-workspace catalogs remain separate work (#4809, #8165). ### Verification available so far Observed public MCP reproduction described above; resource scope used one CPU, 4GiB hard / 3GiB early-stop memory and verified process cleanup. The probe took 5.145s with 297,570,304-byte kernel family peak and no OOM. Planned verification: lifecycle and capacity boundaries, real CLI/MCP workflows across native/managed/JS/mobile/WASM/process artifacts, actual local Codex CLI `gpt-6.1-terra` / high, exact identities/coverage/Unknown history, cancellation/finalization/failure recovery, and explicit checkpoint transfer to a fresh process. No controlled performance improvement is claimed yet. ### References #721, #50, #740, #4809, #8293, #4002, #7671.
Sign in to join this conversation.
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#6554
No description provided.