[GH-ISSUE #725] [Feature] Distinguish observed export property presence from unknown values and variant pairing #323

New issue

Closed

opened 2026-10-15 18:23:52 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:23:52 +00:00

Owner

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

Before submitting

I searched the open and closed issues and relevant pull requests for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Current limitation

The selected search.js::search export had one object return in each version. V1 returned {matches, count} and V2 {matches, total, query}. compare_javascript_export_shapes selected the correct exports but returned added=0, removed=0, changed=0, unknown=2 because the variants lacked reciprocal unique literal discriminators.

A tagged control with kind: "results" paired one variant and exposed /count, /total, and /query with observed presence/absence, but classified all three as unknown because length/call-expression values were unresolved. Coverage was explicitly partial; current output did not claim equivalence.

Use cases

An analyst wants to identify returned property names changed between two local JS versions, while retaining uncertainty about dynamic values and variant identity.

Desired outcome and success criteria

Show observed per-variant property inventories and presence/absence facts even when pairing or values are unknown.
Separate variant-pairing confidence, property presence, and value resolution.
Keep unpaired variants and source locations visible; never infer a runtime correspondence from source order.
The untagged and tagged controls above explain the distinct boundaries inline.
A dynamic value remains unknown without obscuring an independently observed property fact.
Preserve sound completeness rules, authority, and CLI/MCP semantic parity.

Authority boundaries and non-goals

Static syntax evidence only. No execution, assumed runtime equivalence, arbitrary single-variant pairing, evaluation of call expressions, or mutation of the inspected app.

Alternatives considered

General application-version comparison succeeded but did not directly answer the export-property question. Adding a discriminator helped pairing but left value-driven unknown labels. Manual source inspection is a workaround, not a complete tool answer.

Possible direction

Extend the existing export-shape result with per-variant presence inventories or presence-specific facts, keeping current value/pairing unknowns and source provenance.

References

Hands-on public CLI/MCP evaluation, findings F06. Baseline: REA 4.0.1, source revision c3bc38bf6c74d2175a4680530dcadd6cab0e7791; evaluation date 2026-10-06.

Use the three-file JS fixture in the target-diagnostics report: change only the return expression between versions, then add the literal tag for the control. Related #698 preserves container-only shape paths, a distinct issue already included in this baseline. docs/tool-design.md

Related evaluation issues: #720.

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/725 ### Before submitting - [x] I searched the open and closed issues and relevant pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Current limitation The selected search.js::search export had one object return in each version. V1 returned `{matches, count}` and V2 `{matches, total, query}`. compare_javascript_export_shapes selected the correct exports but returned added=0, removed=0, changed=0, unknown=2 because the variants lacked reciprocal unique literal discriminators. A tagged control with `kind: "results"` paired one variant and exposed `/count`, `/total`, and `/query` with observed presence/absence, but classified all three as unknown because length/call-expression values were unresolved. Coverage was explicitly partial; current output did not claim equivalence. ### Use cases An analyst wants to identify returned property names changed between two local JS versions, while retaining uncertainty about dynamic values and variant identity. ### Desired outcome and success criteria - Show observed per-variant property inventories and presence/absence facts even when pairing or values are unknown. - Separate variant-pairing confidence, property presence, and value resolution. - Keep unpaired variants and source locations visible; never infer a runtime correspondence from source order. - The untagged and tagged controls above explain the distinct boundaries inline. - A dynamic value remains unknown without obscuring an independently observed property fact. - Preserve sound completeness rules, authority, and CLI/MCP semantic parity. ### Authority boundaries and non-goals Static syntax evidence only. No execution, assumed runtime equivalence, arbitrary single-variant pairing, evaluation of call expressions, or mutation of the inspected app. ### Alternatives considered General application-version comparison succeeded but did not directly answer the export-property question. Adding a discriminator helped pairing but left value-driven unknown labels. Manual source inspection is a workaround, not a complete tool answer. ### Possible direction Extend the existing export-shape result with per-variant presence inventories or presence-specific facts, keeping current value/pairing unknowns and source provenance. ### References Hands-on public CLI/MCP evaluation, findings F06. Baseline: REA 4.0.1, source revision [c3bc38bf6c74d2175a4680530dcadd6cab0e7791](https://github.com/morluto/rea/commit/c3bc38bf6c74d2175a4680530dcadd6cab0e7791); evaluation date 2026-10-06. Use the three-file JS fixture in the target-diagnostics report: change only the return expression between versions, then add the literal tag for the control. Related [#698](https://github.com/morluto/rea/pull/698) preserves container-only shape paths, a distinct issue already included in this baseline. [docs/tool-design.md](https://github.com/morluto/rea/blob/c3bc38bf6c74d2175a4680530dcadd6cab0e7791/docs/tool-design.md) Related evaluation issues: [#720](https://github.com/morluto/rea/issues/720).

bsakaguchi

2026-10-15 18:23:52 +00:00