morluto/rea

Fork 0

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

[GH-ISSUE #4394] [Feature] Persist target-keyed investigation notes across sessions #1747

New issue

Open

opened 2026-10-16 21:09:48 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:09:48 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4394

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Current limitation

The bundled reverse-engineer-anything skill tells agents to "Keep a concise finding ledger linking each conclusion to Evidence IDs, confidence/evidence type, search boundary, and remaining unknowns. Update the shared index or investigation report so later passes can reuse results." (.agents/skills/reverse-engineer-anything/SKILL.md, step 7 of the investigation plan). No REA operation stores, finds, or validates that ledger, and the skill does not define its format or location.

What persists today is raw and session-scoped:

Evidence lives in the connection's ledger; close_binary clears it and "a fresh connection has its own ledger" (docs/mcp-contracts.md). Keeping it requires a manual export_evidence_bundle to a caller-chosen path and a later import_evidence_bundle from that exact path; nothing looks a bundle up by target.
close_binary snapshot_path snapshots are "cached observations, not a saved provider database" (docs/cli.md), reusable only for eligible exact queries.
The residual-unknowns ledger (record_unknown, update_unknown, list_unknowns) is MCP-session state.
rea uninstall --purge-data removes only ~/.rea/cache and ~/.rea/state (src/application/Uninstall.ts); neither holds curated findings.

So each new session on a previously studied binary starts from zero, and the skill's instruction to "update the shared index" has nothing behind it, which invites agents to invent ad hoc files with no schema, no secret or path checks, and no link back to Evidence.

Use cases

An agent returns to an application a week later (new session, same sha256) and needs the previous pass's conclusions, open questions, and the Evidence IDs that supported them before deciding what to re-run.
A new build of the same program arrives; the agent wants the notes from the prior build as hypotheses to re-verify, clearly marked as coming from a different digest.
Several agents or analysts split an investigation; each needs to see what the others already concluded and with what confidence.

Measured frequency: none; this is a design gap observed in source, not a measured workflow cost.

Desired outcome and success criteria

Give agents a local, schema-checked place to record what an investigation of a specific artifact established, keyed by the artifact's content digest, so a later session on the same artifact (or a related build) can find and reuse those conclusions instead of rediscovering them.

A note is keyed by artifact identity (subject.digest.sha256 or the art_ artifact ID), never by file path or product name alone, and records: title, conclusions, each conclusion's supporting Evidence IDs and confidence (observed/derived/inferred), search boundary, open questions or linked unknowns, the REA version, and a date.
An agent can list and search notes for the artifact it has open (exact digest match) and, separately, for related artifacts by name or tag, with results clearly distinguishing same-digest notes from related-artifact notes.
Writing a note validates it against a schema and rejects: missing required fields, Evidence IDs that are not well-formed, likely secrets (tokens, private keys), and absolute home-directory paths; it warns on large verbatim code blocks or decompiler output, consistent with DISCLAIMER.md ("copying proprietary software or reproducing its protected code and assets").
When a note cites Evidence IDs, an agent can tell whether those IDs are present in a given exported bundle, so a reused conclusion can be re-verified rather than trusted.
Notes are local-only by default. Nothing is uploaded, synced, or published by REA.
The bundled skill's finding-ledger step points at this facility instead of an undefined "shared index".

Expected interaction with targets

No target interaction (documentation or usability only)

Target and scope details (optional)

Notes describe targets but never read, launch, or modify them; storage would sit under REA's existing data root alongside ~/.rea/state. Non-goals: remote sync, sharing, or a public knowledge base; storing raw target bytes or decompiled function bodies; replacing Evidence bundles, which remain the authoritative record. Open scope question: whether notes belong in REA core or as an agent-skill convention plus a validator, given the related reporting proposals below.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

Possible check: open a fixture binary, record a note citing two Evidence IDs, close the session, start a new MCP connection, open the same fixture, and confirm the note is returned by digest; open a byte-different fixture with the same filename and confirm the note is not returned as a same-digest match. Negative checks: a note containing a PEM private key or a /Users/<name>/ path is rejected or flagged.

Alternatives considered

Manual export_evidence_bundle / import_evidence_bundle: preserves raw Evidence but not curated conclusions, and requires the agent to remember the bundle path.
#1142 (TraceBrief, open) and draft PR #3812 (evidence-gated findings triage, experiments/ only): both render or validate one report from one bundle; neither persists findings across sessions or looks them up by target. A notes store could reuse #3812's bundle-citation validation.
#133 (closed): cross-invocation persistence of residual unknowns only.
Free-form Markdown files chosen by each agent: what happens today; no schema, no secret or path checks, no Evidence linkage.

Possible direction

Reuse existing identities and validators rather than adding new ones: artifactIdForContent (src/domain/artifactIdentity.ts), Evidence IDs and confidence values (src/domain/evidence.ts), evidenceBundleForTarget (src/domain/evidenceBundle.ts) for per-target bundle slices, and the atomic JSON writer in src/application/JsonFiles.ts. A small MCP surface (record_note, list_notes, search_notes) plus CLI equivalents would likely suffice.

References

Checked against main at commit 8ab5024 (rea-agents 6.5.0).
Related: #1142, #3812, #133, #51.

Originally created by @coygeek on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4394 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Current limitation The bundled `reverse-engineer-anything` skill tells agents to "Keep a concise finding ledger linking each conclusion to Evidence IDs, confidence/evidence type, search boundary, and remaining unknowns. Update the shared index or investigation report so later passes can reuse results." (`.agents/skills/reverse-engineer-anything/SKILL.md`, step 7 of the investigation plan). No REA operation stores, finds, or validates that ledger, and the skill does not define its format or location. What persists today is raw and session-scoped: - Evidence lives in the connection's ledger; `close_binary` clears it and "a fresh connection has its own ledger" (`docs/mcp-contracts.md`). Keeping it requires a manual `export_evidence_bundle` to a caller-chosen path and a later `import_evidence_bundle` from that exact path; nothing looks a bundle up by target. - `close_binary` `snapshot_path` snapshots are "cached observations, not a saved provider database" (`docs/cli.md`), reusable only for eligible exact queries. - The residual-unknowns ledger (`record_unknown`, `update_unknown`, `list_unknowns`) is MCP-session state. - `rea uninstall --purge-data` removes only `~/.rea/cache` and `~/.rea/state` (`src/application/Uninstall.ts`); neither holds curated findings. So each new session on a previously studied binary starts from zero, and the skill's instruction to "update the shared index" has nothing behind it, which invites agents to invent ad hoc files with no schema, no secret or path checks, and no link back to Evidence. ### Use cases - An agent returns to an application a week later (new session, same `sha256`) and needs the previous pass's conclusions, open questions, and the Evidence IDs that supported them before deciding what to re-run. - A new build of the same program arrives; the agent wants the notes from the prior build as hypotheses to re-verify, clearly marked as coming from a different digest. - Several agents or analysts split an investigation; each needs to see what the others already concluded and with what confidence. Measured frequency: none; this is a design gap observed in source, not a measured workflow cost. ### Desired outcome and success criteria Give agents a local, schema-checked place to record what an investigation of a specific artifact established, keyed by the artifact's content digest, so a later session on the same artifact (or a related build) can find and reuse those conclusions instead of rediscovering them. - A note is keyed by artifact identity (`subject.digest.sha256` or the `art_` artifact ID), never by file path or product name alone, and records: title, conclusions, each conclusion's supporting Evidence IDs and confidence (`observed`/`derived`/`inferred`), search boundary, open questions or linked unknowns, the REA version, and a date. - An agent can list and search notes for the artifact it has open (exact digest match) and, separately, for related artifacts by name or tag, with results clearly distinguishing same-digest notes from related-artifact notes. - Writing a note validates it against a schema and rejects: missing required fields, Evidence IDs that are not well-formed, likely secrets (tokens, private keys), and absolute home-directory paths; it warns on large verbatim code blocks or decompiler output, consistent with `DISCLAIMER.md` ("copying proprietary software or reproducing its protected code and assets"). - When a note cites Evidence IDs, an agent can tell whether those IDs are present in a given exported bundle, so a reused conclusion can be re-verified rather than trusted. - Notes are local-only by default. Nothing is uploaded, synced, or published by REA. - The bundled skill's finding-ledger step points at this facility instead of an undefined "shared index". ### Expected interaction with targets No target interaction (documentation or usability only) ### Target and scope details (optional) Notes describe targets but never read, launch, or modify them; storage would sit under REA's existing data root alongside `~/.rea/state`. Non-goals: remote sync, sharing, or a public knowledge base; storing raw target bytes or decompiled function bodies; replacing Evidence bundles, which remain the authoritative record. Open scope question: whether notes belong in REA core or as an agent-skill convention plus a validator, given the related reporting proposals below. ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) Possible check: open a fixture binary, record a note citing two Evidence IDs, close the session, start a new MCP connection, open the same fixture, and confirm the note is returned by digest; open a byte-different fixture with the same filename and confirm the note is not returned as a same-digest match. Negative checks: a note containing a PEM private key or a `/Users/<name>/` path is rejected or flagged. ### Alternatives considered - Manual `export_evidence_bundle` / `import_evidence_bundle`: preserves raw Evidence but not curated conclusions, and requires the agent to remember the bundle path. - #1142 (TraceBrief, open) and draft PR #3812 (evidence-gated findings triage, `experiments/` only): both render or validate one report from one bundle; neither persists findings across sessions or looks them up by target. A notes store could reuse #3812's bundle-citation validation. - #133 (closed): cross-invocation persistence of residual unknowns only. - Free-form Markdown files chosen by each agent: what happens today; no schema, no secret or path checks, no Evidence linkage. ### Possible direction Reuse existing identities and validators rather than adding new ones: `artifactIdForContent` (`src/domain/artifactIdentity.ts`), Evidence IDs and confidence values (`src/domain/evidence.ts`), `evidenceBundleForTarget` (`src/domain/evidenceBundle.ts`) for per-target bundle slices, and the atomic JSON writer in `src/application/JsonFiles.ts`. A small MCP surface (`record_note`, `list_notes`, `search_notes`) plus CLI equivalents would likely suffice. ### References - Checked against `main` at commit 8ab5024 (`rea-agents` 6.5.0). - Related: #1142, #3812, #133, #51.

bsakaguchi referenced this issue

2026-10-17 21:02:48 +00:00

[GH-ISSUE #4246] [Design] Caller-selected Ghidra language and base address for raw-binary imports #1669

bsakaguchi referenced this issue

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

[GH-ISSUE #1741] [Feature] Add PowerPC (32-bit big-endian) native analysis through Ghidra, with a GameCube/Wii DOL follow-up #584

bsakaguchi referenced this issue

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

[GH-ISSUE #1741] [Feature] Add PowerPC (32-bit big-endian) native analysis through Ghidra, with a GameCube/Wii DOL follow-up #584

bsakaguchi referenced this issue

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

[GH-ISSUE #3070] [Feature] powerpc code #1076

bsakaguchi commented

2026-10-31 00:32:31 +00:00

Author

Owner

@Wakkatobakka commented on GitHub (Oct 29, 2026):

Hey! I came across this while looking into REA and thought I'd reach out.

I've been building a couple of tools, Artifact Passport and Workbench Continuity, to help preserve context and carry work between AI sessions.

This issue sounds pretty similar to some problems I've been tackling. I'm not sure how much overlap there is, but I'd be happy to contribute if any of my existing work could be useful! 🤘

@Wakkatobakka commented on GitHub (Oct 29, 2026): Hey! I came across this while looking into REA and thought I'd reach out. I've been building a couple of tools, [Artifact Passport](https://github.com/Wakkatobakka/artifact-passport) and [Workbench Continuity](https://github.com/Wakkatobakka/workbench-continuity), to help preserve context and carry work between AI sessions. This issue sounds pretty similar to some problems I've been tackling. I'm not sure how much overlap there is, but I'd be happy to contribute if any of my existing work could be useful! 🤘

bsakaguchi referenced this issue

2026-10-31 00:41:06 +00:00

[GH-ISSUE #5744] [Feature] Analyze Thumb-only Cortex-M firmware in the raw-binary lane instead of refusing its entry point and decoding it as ARM state #3491

bsakaguchi referenced this issue

2026-10-31 00:55:07 +00:00

[PR #1747] [MERGED] feat(ghidra): admit 32-bit big-endian PowerPC ELF #4792