morluto/rea

Fork 0

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

[GH-ISSUE #7604] [Bug] evidence-export omits the residual-unknown revision count from its receipt #4534

New issue

Closed

opened 2026-10-31 00:50:34 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:50:34 +00:00

Owner

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

Before submitting

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

Area

CLI

Observed behavior

node scripts/rea.mjs evidence-export SOURCE OUTPUT --json writes the canonical bundle and exits successfully, but returns only path, bytes, and records. It omits the unknowns revision count carried by the named MCP export result. Adding --full-output leaves the count absent from data as well.

I observed this with a bundle containing no unknown revisions and with an independently constructed bundle containing two revisions of one question. Both exported files retained their complete unknowns arrays.

Reproduction

From the baseline checkout with its existing build and Node v24.22.1 on PATH, run the following shell script. TMPDIR must name an existing scratch directory. It creates its own input and isolates REA's HOME/XDG paths:

set -eu
rea_verify_cli="$PWD/scripts/rea.mjs"
rea_verify_root="$(mktemp -d "$TMPDIR/rea-verify.XXXXXX")"
trap 'rm -rf "$rea_verify_root"' EXIT
mkdir -p "$rea_verify_root/home" "$rea_verify_root/config" "$rea_verify_root/cache" "$rea_verify_root/data" "$rea_verify_root/state" "$rea_verify_root/app/resources"
printf x > "$rea_verify_root/app/resources/app.asar"
rea_verify() {
  env HOME="$rea_verify_root/home" XDG_CONFIG_HOME="$rea_verify_root/config" XDG_CACHE_HOME="$rea_verify_root/cache" XDG_DATA_HOME="$rea_verify_root/data" XDG_STATE_HOME="$rea_verify_root/state" node "$rea_verify_cli" "$@"
}
rea_verify inspect-desktop-application "$rea_verify_root/app" --detail summary --evidence_output "$rea_verify_root/bundle.json" --json > /dev/null
rea_verify evidence-export "$rea_verify_root/bundle.json" "$rea_verify_root/export.json" --json
rea_verify evidence-export "$rea_verify_root/bundle.json" "$rea_verify_root/export-full.json" --json --full-output
node -e 'const fs=require("node:fs");const b=JSON.parse(fs.readFileSync(process.argv[1],"utf8"));console.log(JSON.stringify({records:b.records.length,unknowns:b.unknowns.length}));' "$rea_verify_root/export.json"

Both export commands exit 0, but neither receipt includes unknowns. The last command prints {"records":1,"unknowns":0} from the exported file.

The omission reproduced in normal and full-output modes for the zero-revision fixture. A separate export of a two-record, two-revision canonical fixture also omitted the count.

Expected behavior

The successful CLI export receipt should include the same residual-unknown revision count as the named export operation, including unknowns: 0 when the bundle has no revisions. The original export feature calls for identical CLI/MCP semantics, and the advertised MCP result requires this count.

There is a distinction in the current discovery surface: evidence-export --schema --json lists only input arguments and options. It provides no CLI output schema, so it neither declares this field optional nor independently requires it. The CLI guide promises shared workflows and Evidence contracts but does not enumerate the export receipt's fields. This report concerns drift between the shared export semantics and the CLI receipt, rather than a claim that the CLI advertises its own four-field output schema.

Impact and scope

The CLI receipt cannot distinguish an export with no unknown revisions from one with retained revision history. Reusing the named export result contract to validate the receipt fails because the count is missing. I directly reproduced that validation failure for the two-revision fixture.

The canonical export itself succeeds and preserves the revision history. Reading unknowns.length from the exported JSON is a demonstrated workaround. No data loss was observed. Runtime verification covered the public CLI and target-free MCP schema discovery; MCP export-handler behavior was inspected in source rather than exercised with this fixture.

REA version

Exact node scripts/rea.mjs --version output:

6.8.0

Baseline: 65f1c447344a423fa2785847dbcea1e9a9e2454a.

Runtime and platform

Node v24.22.1; Darwin 27.0.0; arm64. No Hopper or other GUI application was launched.

Target and artifact context

A synthetic desktop directory containing a one-byte resources/app.asar file, inspected in summary mode to create a valid one-record Evidence bundle. The nonzero control used production domain constructors to create two records and two revisions of one residual question.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

Normal export output, with the selected path abbreviated (the byte count depends on the fixture's paths):

{"path":"<selected output>","bytes":5976,"records":1}

The full-output result similarly contained data: {path, bytes, records} without unknowns. Reading the resulting file produced:

{"records":1,"unknowns":0}

For the separate two-revision fixture, the CLI returned records: 2 without unknowns, while the file contained two unknown revisions. Validating {result: receipt} with the named export_evidence_bundle output contract failed at result.unknowns with Invalid input: expected number, received undefined.

A real stdio MCP tools/list request to the baseline advertised this required array for the referenced export result object:

["path","bytes","records","unknowns"]

Contract and reachability evidence at the baseline:

src/contracts/toolOutputSchemaGroups.ts:557-563 declares the required four-field export result. src/contracts/toolOutputSchemaPrimitives.ts:33-35 wraps it under result.
src/cliEvidenceCommands.ts:38-59 registers the supported CLI entry point and returns the application command's success value without declaring an output schema.
src/application/EvidenceBundleCommands.ts:282-292 projects the successful CLI receipt with only three fields.
src/server/registerSessionRecordTools.ts:61-68 constructs the MCP receipt with unknowns: bundle.unknowns.length.
docs/cli.md:3-4 describes shared workflows and Evidence contracts; its export section at lines 541-568 documents invocation and publication behavior without a receipt-field list.
Original export feature #51 specifies identical CLI/MCP semantics and was closed as implemented. It is background contract evidence, not an earlier report of this omission.

PR #3572 previously proposed exactly this correction and a shared result projection. It is closed and unmerged. Its closing comment says the author closed it to free an open-PR slot and retained the branch for reopening. It does not declare the omission intended or identify a superseding fix. Searches of open and closed issues, issue comments, and open/merged/closed-unmerged PRs found no existing issue reporting this omission and no open PR that fixes it. Related open PRs #5597 and #4482 address overwrite advice and bundle auditing respectively; their diffs do not add the missing count.

Analysis or suspected cause

The CLI and MCP construct their success receipts separately. The CLI projection lacks the field that the MCP projection derives from the same kind of bundle. That source difference explains the observed omission; this verification did not implement a correction.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: Successful CLI exports repeatedly omit machine-readable revision-count information present in the shared export result, causing the demonstrated named-contract validation failure. The exported evidence remains intact.
Workaround status: available
Workaround basis: Reading the exported file's unknowns.length recovered the correct counts for both the zero-revision and two-revision fixtures.

Originally created by @coygeek on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7604 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area CLI ### Observed behavior `node scripts/rea.mjs evidence-export SOURCE OUTPUT --json` writes the canonical bundle and exits successfully, but returns only `path`, `bytes`, and `records`. It omits the `unknowns` revision count carried by the named MCP export result. Adding `--full-output` leaves the count absent from `data` as well. I observed this with a bundle containing no unknown revisions and with an independently constructed bundle containing two revisions of one question. Both exported files retained their complete `unknowns` arrays. ### Reproduction 1. From the baseline checkout with its existing build and Node v24.22.1 on PATH, run the following shell script. TMPDIR must name an existing scratch directory. It creates its own input and isolates REA's HOME/XDG paths: ```sh set -eu rea_verify_cli="$PWD/scripts/rea.mjs" rea_verify_root="$(mktemp -d "$TMPDIR/rea-verify.XXXXXX")" trap 'rm -rf "$rea_verify_root"' EXIT mkdir -p "$rea_verify_root/home" "$rea_verify_root/config" "$rea_verify_root/cache" "$rea_verify_root/data" "$rea_verify_root/state" "$rea_verify_root/app/resources" printf x > "$rea_verify_root/app/resources/app.asar" rea_verify() { env HOME="$rea_verify_root/home" XDG_CONFIG_HOME="$rea_verify_root/config" XDG_CACHE_HOME="$rea_verify_root/cache" XDG_DATA_HOME="$rea_verify_root/data" XDG_STATE_HOME="$rea_verify_root/state" node "$rea_verify_cli" "$@" } rea_verify inspect-desktop-application "$rea_verify_root/app" --detail summary --evidence_output "$rea_verify_root/bundle.json" --json > /dev/null rea_verify evidence-export "$rea_verify_root/bundle.json" "$rea_verify_root/export.json" --json rea_verify evidence-export "$rea_verify_root/bundle.json" "$rea_verify_root/export-full.json" --json --full-output node -e 'const fs=require("node:fs");const b=JSON.parse(fs.readFileSync(process.argv[1],"utf8"));console.log(JSON.stringify({records:b.records.length,unknowns:b.unknowns.length}));' "$rea_verify_root/export.json" ``` 2. Both export commands exit 0, but neither receipt includes `unknowns`. The last command prints `{"records":1,"unknowns":0}` from the exported file. The omission reproduced in normal and full-output modes for the zero-revision fixture. A separate export of a two-record, two-revision canonical fixture also omitted the count. ### Expected behavior The successful CLI export receipt should include the same residual-unknown revision count as the named export operation, including `unknowns: 0` when the bundle has no revisions. The original export feature calls for identical CLI/MCP semantics, and the advertised MCP result requires this count. There is a distinction in the current discovery surface: `evidence-export --schema --json` lists only input arguments and options. It provides no CLI output schema, so it neither declares this field optional nor independently requires it. The CLI guide promises shared workflows and Evidence contracts but does not enumerate the export receipt's fields. This report concerns drift between the shared export semantics and the CLI receipt, rather than a claim that the CLI advertises its own four-field output schema. ### Impact and scope The CLI receipt cannot distinguish an export with no unknown revisions from one with retained revision history. Reusing the named export result contract to validate the receipt fails because the count is missing. I directly reproduced that validation failure for the two-revision fixture. The canonical export itself succeeds and preserves the revision history. Reading `unknowns.length` from the exported JSON is a demonstrated workaround. No data loss was observed. Runtime verification covered the public CLI and target-free MCP schema discovery; MCP export-handler behavior was inspected in source rather than exercised with this fixture. ### REA version Exact `node scripts/rea.mjs --version` output: ```text 6.8.0 ``` Baseline: `65f1c447344a423fa2785847dbcea1e9a9e2454a`. ### Runtime and platform Node v24.22.1; Darwin 27.0.0; arm64. No Hopper or other GUI application was launched. ### Target and artifact context A synthetic desktop directory containing a one-byte `resources/app.asar` file, inspected in summary mode to create a valid one-record Evidence bundle. The nonzero control used production domain constructors to create two records and two revisions of one residual question. ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence Normal export output, with the selected path abbreviated (the byte count depends on the fixture's paths): ```json {"path":"<selected output>","bytes":5976,"records":1} ``` The full-output result similarly contained `data: {path, bytes, records}` without `unknowns`. Reading the resulting file produced: ```json {"records":1,"unknowns":0} ``` For the separate two-revision fixture, the CLI returned `records: 2` without `unknowns`, while the file contained two unknown revisions. Validating `{result: receipt}` with the named `export_evidence_bundle` output contract failed at `result.unknowns` with `Invalid input: expected number, received undefined`. A real stdio MCP `tools/list` request to the baseline advertised this required array for the referenced export result object: ```json ["path","bytes","records","unknowns"] ``` Contract and reachability evidence at the baseline: - `src/contracts/toolOutputSchemaGroups.ts:557-563` declares the required four-field export result. `src/contracts/toolOutputSchemaPrimitives.ts:33-35` wraps it under `result`. - `src/cliEvidenceCommands.ts:38-59` registers the supported CLI entry point and returns the application command's success value without declaring an output schema. - `src/application/EvidenceBundleCommands.ts:282-292` projects the successful CLI receipt with only three fields. - `src/server/registerSessionRecordTools.ts:61-68` constructs the MCP receipt with `unknowns: bundle.unknowns.length`. - `docs/cli.md:3-4` describes shared workflows and Evidence contracts; its export section at lines 541-568 documents invocation and publication behavior without a receipt-field list. - [Original export feature #51](https://github.com/morluto/rea/issues/51) specifies identical CLI/MCP semantics and was closed as implemented. It is background contract evidence, not an earlier report of this omission. [PR #3572](https://github.com/morluto/rea/pull/3572) previously proposed exactly this correction and a shared result projection. It is closed and unmerged. Its [closing comment](https://github.com/morluto/rea/pull/3572#issuecomment-6285107820) says the author closed it to free an open-PR slot and retained the branch for reopening. It does not declare the omission intended or identify a superseding fix. Searches of open and closed issues, issue comments, and open/merged/closed-unmerged PRs found no existing issue reporting this omission and no open PR that fixes it. Related open PRs #5597 and #4482 address overwrite advice and bundle auditing respectively; their diffs do not add the missing count. ### Analysis or suspected cause The CLI and MCP construct their success receipts separately. The CLI projection lacks the field that the MCP projection derives from the same kind of bundle. That source difference explains the observed omission; this verification did not implement a correction. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: Successful CLI exports repeatedly omit machine-readable revision-count information present in the shared export result, causing the demonstrated named-contract validation failure. The exported evidence remains intact. - Workaround status: available - Workaround basis: Reading the exported file's unknowns.length recovered the correct counts for both the zero-revision and two-revision fixtures.

bsakaguchi closed this issue

2026-10-31 00:50:34 +00:00

bsakaguchi referenced this issue

2026-10-31 01:13:23 +00:00

[PR #4545] [CLOSED] fix(objc): isolate empty Objective-C ivar names #6298

bsakaguchi referenced this issue

2026-10-31 01:13:23 +00:00

[PR #4547] [CLOSED] fix(native): report symbols named without an address as unlocated #6299

bsakaguchi referenced this issue

2026-10-31 01:14:30 +00:00

[PR #4861] [CLOSED] fix(native): retain methods around empty Objective-C selectors #6445