morluto/rea

Fork 0

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

[GH-ISSUE #8375] [Design] Make Unknown history direction explicit in bundle comparisons #6574

New issue

Open

opened 2026-11-01 21:12:22 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

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

Should compare_bundles and rea compare explicitly identify which side extends a residual-unknown history, so an agent can tell an earlier snapshot from a later one without reopening both bundles?

Context and evidence

On macOS arm64, I traced a two-call-site synthetic Mach-O with verified Kuna 1.986 and the partial-trace change in PR #8368. The trace retained two independent unavailable-owner Unknowns. I exported bundle A, switched the same REA session to Ghidra 12.1.4, observed a containing procedure for one call site, and advanced that Unknown from revision 1 (open) to revision 2 (investigating), keeping both the original trace and Ghidra observation as supporting Evidence. The other Unknown was untouched. An independent nm/otool check confirmed the selected call site in this fixture. I exported bundle B. This update is an investigation record, not an automatic or verified resolution.

A fresh MCP server running current main d54a4661 imported B and returned revision 2, still investigating, with truthVerified:false. Comparing A with B and B with A both returned that Unknown's classification: "history_advanced", conclusion_kind: "observed_change", and summary.unknowns_advanced: 1. The left_digest and right_digest values swapped as expected, but neither output explicitly says which side is the earlier prefix or gives the revision numbers. Both overall results were unknown due to one-sided Evidence membership. Comparing B with itself returned unchanged. CLI rea compare on main produced the same forward/reverse classifications.

This does not claim the symmetric prefix classification is incorrect or that the comparison proves a question resolved. The explicit information available today includes the two head digests and Evidence IDs; inspecting the authenticated bundle histories supplies the revisions and direction. The design question is whether the inline answer should make the prefix direction immediately available to an agent.

Expected interaction with targets

Read caller-selected local Evidence bundles; no provider restart, target execution or mutation is needed for the comparison.

Boundary details

Keep left/right bundle identity, exact Unknown and revision-digest provenance, complete history validation, and the distinction between an advanced history and a true answer. Divergent histories, missing histories and incomplete capture must not be treated as a linear advancement or proof of absence. Reversing the bundle arguments should reverse any explicitly directional field.

Options and tradeoffs

Consider a typed earlier/extended side or left/right head revision information on history_advanced; alternatively document clearly that the classification is symmetric and expose a bounded way to inspect each retained history. Reuse the existing history-comparison owner rather than inferring chronology from evidence-ID ordering. Consider output compatibility and the cost of repeating revision details.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise identical bundles, A→B and B→A, revision-only changes with no truth resolution, divergent valid histories and one-sided histories through MCP and CLI. Confirm stale revision updates remain conflicts, no resolution is inferred, imported histories remain authenticated, and outputs stay bounded for large ledgers. A controlled agent study is needed to establish whether the current presentation causes mistakes in practice.

References

compare_bundles contract; symmetric prefix comparison; #8372 covers the separate question of correlating provider address spaces.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8375 ### 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 Should `compare_bundles` and `rea compare` explicitly identify which side extends a residual-unknown history, so an agent can tell an earlier snapshot from a later one without reopening both bundles? ### Context and evidence On macOS arm64, I traced a two-call-site synthetic Mach-O with verified Kuna 1.986 and the partial-trace change in PR #8368. The trace retained two independent unavailable-owner Unknowns. I exported bundle A, switched the same REA session to Ghidra 12.1.4, observed a containing procedure for one call site, and advanced that Unknown from revision 1 (`open`) to revision 2 (`investigating`), keeping both the original trace and Ghidra observation as supporting Evidence. The other Unknown was untouched. An independent `nm`/`otool` check confirmed the selected call site in this fixture. I exported bundle B. This update is an investigation record, not an automatic or verified resolution. A fresh MCP server running **current main `d54a4661`** imported B and returned revision 2, still `investigating`, with `truthVerified:false`. Comparing A with B and B with A both returned that Unknown's `classification: "history_advanced"`, `conclusion_kind: "observed_change"`, and `summary.unknowns_advanced: 1`. The `left_digest` and `right_digest` values swapped as expected, but neither output explicitly says which side is the earlier prefix or gives the revision numbers. Both overall results were `unknown` due to one-sided Evidence membership. Comparing B with itself returned `unchanged`. CLI `rea compare` on main produced the same forward/reverse classifications. This does **not** claim the symmetric prefix classification is incorrect or that the comparison proves a question resolved. The explicit information available today includes the two head digests and Evidence IDs; inspecting the authenticated bundle histories supplies the revisions and direction. The design question is whether the inline answer should make the prefix direction immediately available to an agent. ### Expected interaction with targets Read caller-selected local Evidence bundles; no provider restart, target execution or mutation is needed for the comparison. ### Boundary details Keep left/right bundle identity, exact Unknown and revision-digest provenance, complete history validation, and the distinction between an advanced history and a true answer. Divergent histories, missing histories and incomplete capture must not be treated as a linear advancement or proof of absence. Reversing the bundle arguments should reverse any explicitly directional field. ### Options and tradeoffs Consider a typed earlier/extended side or left/right head revision information on `history_advanced`; alternatively document clearly that the classification is symmetric and expose a bounded way to inspect each retained history. Reuse the existing history-comparison owner rather than inferring chronology from evidence-ID ordering. Consider output compatibility and the cost of repeating revision details. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise identical bundles, A→B and B→A, revision-only changes with no truth resolution, divergent valid histories and one-sided histories through MCP and CLI. Confirm stale revision updates remain conflicts, no resolution is inferred, imported histories remain authenticated, and outputs stay bounded for large ledgers. A controlled agent study is needed to establish whether the current presentation causes mistakes in practice. ### References [`compare_bundles` contract](https://github.com/morluto/rea/blob/d54a4661da20382ad8456564a08569fdd24131c5/src/contracts/sessionToolContracts.ts#L123-L127); [symmetric prefix comparison](https://github.com/morluto/rea/blob/d54a4661da20382ad8456564a08569fdd24131c5/src/domain/bundleComparison.ts#L240-L260); #8372 covers the separate question of correlating provider address spaces. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Follow-up control on current main d54a4661, using the real-provider trace bundle described above: two independent target-free MCP servers imported revision 1 and created different revision 2 heads (investigating and blocked). Neither was marked truth-verified. After exporting each branch, a third server compared them in both orders: both reports classified the Unknown as history_diverged with conclusion_kind: "contradiction", and each overall comparison remained unknown because of one-sided Evidence. Comparing a bundle with itself returned unchanged. CLI rea compare returned the same forward, reverse and self classifications. The contradiction describes the revision histories, not proof that either substantive claim is false.

Importing the second branch into a session already holding the first returned nonretryable evidence_integrity_mismatch with the exact Unknown ID and revision; its guidance recommended inspecting histories in separate sessions. Exports immediately before and after the failed import had identical SHA-256, and the original current head remained unchanged. This is a CLI/MCP control on one small authenticated history, with synthetic mutations after the real-provider observation; it does not establish large-ledger or cancellation behavior.

@morluto commented on GitHub (Oct 31, 2026): Follow-up control on current main `d54a4661`, using the real-provider trace bundle described above: two independent target-free MCP servers imported revision 1 and created different revision 2 heads (`investigating` and `blocked`). Neither was marked truth-verified. After exporting each branch, a third server compared them in both orders: both reports classified the Unknown as `history_diverged` with `conclusion_kind: "contradiction"`, and each overall comparison remained `unknown` because of one-sided Evidence. Comparing a bundle with itself returned `unchanged`. CLI `rea compare` returned the same forward, reverse and self classifications. The contradiction describes the revision histories, not proof that either substantive claim is false. Importing the second branch into a session already holding the first returned nonretryable `evidence_integrity_mismatch` with the exact Unknown ID and revision; its guidance recommended inspecting histories in separate sessions. Exports immediately before and after the failed import had identical SHA-256, and the original current head remained unchanged. This is a CLI/MCP control on one small authenticated history, with synthetic mutations after the real-provider observation; it does not establish large-ledger or cancellation behavior.

bsakaguchi referenced this issue

2026-11-03 13:39:38 +00:00

[PR #7160] fix(pe): admit Authenticode nesting depth of signed Windows binaries #7685

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

No description provided.

Rows
Columns