[GH-ISSUE #1757] fix(process): align capture Evidence provider admission across CLI and MCP #591

New issue

Closed

opened 2026-10-15 18:26:27 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:26:27 +00:00

Owner

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

Freshly built main 062723e44e937c1e1df865e9ae16184b41e70ae8 admits process-capture Evidence differently through the actual public CLI and SDK stdio MCP workflows.

Create two authenticated Evidence records from EMPTY_PROCESS_CAPTURE_EXAMPLE, using the exact capture_process_scenario operation and rea.process-capture predicate. For the left record change only its provider ID to fixture-provider or version to 1, using createEvidence to compute a valid digest; keep the right record current. The CLI compare-process-captures LEFT.json RIGHT.json --json correctly exits 1 with invalid_input. MCP compare_process_captures {left,right} succeeds, returns authenticated derived comparison Evidence and still answers ping.

Controls:

Current ID/version with an unrelated provider name is accepted by both adapters, although the canonical domain matcher rejects it.
Current exact provider and the explicitly supported legacy name REA deterministic process harness succeed through both adapters, with identical Evidence IDs.
Both inputs are authenticated before each call; successful replies authenticate as well. This is a producer-admission problem rather than digest tampering or a session failure.

The MCP parseCaptureSide in src/server/registerProcessComparisonTool.ts checks operation/predicate/result but omits provider identity. CLI parseCaptureEvidence in src/application/process/ProcessCli.ts duplicates ID/version checks and ignores the existing canonical current/legacy identity matcher isProcessEvidenceProvider. Related merged #706 established that matcher for downstream process-comparison consumers but did not cover capture admission into the comparison producer.

Expected: use one domain-owned process-provider admission rule at both adapters; reject independently rehashed unrelated IDs, versions and names with useful input errors, keep current and exact legacy v3 compatibility, and preserve successful Evidence/provenance/locations/links. Tampered Evidence must continue to fail authentication first. Check both left and right inputs and successful current/legacy controls.

Actual reproducer used pinned Node 24.18.0/npm 11.16.0 and remained below the 2 GiB process-family budget (peak approximately 767 MB). Capture data is a static authenticated fixture, not a live process-capture claim. No native provider, browser or target execution is involved. Full CLI/MCP replies are retained privately. Source files are unchanged in the simultaneous #1753 diagnostic fix; this is a separate admission defect. GitHub issue/PR searches found no existing fix beyond related #706.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1757 Freshly built main `062723e44e937c1e1df865e9ae16184b41e70ae8` admits process-capture Evidence differently through the actual public CLI and SDK stdio MCP workflows. Create two authenticated Evidence records from `EMPTY_PROCESS_CAPTURE_EXAMPLE`, using the exact `capture_process_scenario` operation and `rea.process-capture` predicate. For the left record change only its provider ID to `fixture-provider` or version to `1`, using `createEvidence` to compute a valid digest; keep the right record current. The CLI `compare-process-captures LEFT.json RIGHT.json --json` correctly exits 1 with `invalid_input`. MCP `compare_process_captures {left,right}` succeeds, returns authenticated derived comparison Evidence and still answers ping. Controls: - Current ID/version with an unrelated provider name is accepted by both adapters, although the canonical domain matcher rejects it. - Current exact provider and the explicitly supported legacy name `REA deterministic process harness` succeed through both adapters, with identical Evidence IDs. - Both inputs are authenticated before each call; successful replies authenticate as well. This is a producer-admission problem rather than digest tampering or a session failure. The MCP `parseCaptureSide` in `src/server/registerProcessComparisonTool.ts` checks operation/predicate/result but omits provider identity. CLI `parseCaptureEvidence` in `src/application/process/ProcessCli.ts` duplicates ID/version checks and ignores the existing canonical current/legacy identity matcher `isProcessEvidenceProvider`. Related merged #706 established that matcher for downstream process-comparison consumers but did not cover capture admission into the comparison producer. Expected: use one domain-owned process-provider admission rule at both adapters; reject independently rehashed unrelated IDs, versions and names with useful input errors, keep current and exact legacy v3 compatibility, and preserve successful Evidence/provenance/locations/links. Tampered Evidence must continue to fail authentication first. Check both left and right inputs and successful current/legacy controls. Actual reproducer used pinned Node 24.18.0/npm 11.16.0 and remained below the 2 GiB process-family budget (peak approximately 767 MB). Capture data is a static authenticated fixture, not a live process-capture claim. No native provider, browser or target execution is involved. Full CLI/MCP replies are retained privately. Source files are unchanged in the simultaneous #1753 diagnostic fix; this is a separate admission defect. GitHub issue/PR searches found no existing fix beyond related #706.

bsakaguchi

2026-10-15 18:26:27 +00:00

closed this issue
added the
area: runtime

bug
labels

bsakaguchi commented

2026-10-15 18:26:28 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 11, 2026):

Rechecked after fetching the new main 6ff4d4a0: created a separate clean branch/worktree, freshly compiled that exact main, and repeated the actual CLI + SDK stdio MCP five-case matrix. Wrong provider ID and version still produce CLI invalid_input versus successful authenticated MCP comparison Evidence. An unrelated name still passes both despite failing the canonical matcher; current and explicitly supported legacy names pass with equal CLI/MCP Evidence IDs. Peak process-family RSS was 774 MB. The new regressions fail for all six independent wrong-provider left/right cases; successful current/legacy controls pass. Digest-tampering controls are tracked separately, retaining authentication as the first check. No live capture is claimed.

@N0zoM1z0 commented on GitHub (Oct 11, 2026): Rechecked after fetching the new main `6ff4d4a0`: created a separate clean branch/worktree, freshly compiled that exact main, and repeated the actual CLI + SDK stdio MCP five-case matrix. Wrong provider ID and version still produce CLI `invalid_input` versus successful authenticated MCP comparison Evidence. An unrelated name still passes both despite failing the canonical matcher; current and explicitly supported legacy names pass with equal CLI/MCP Evidence IDs. Peak process-family RSS was 774 MB. The new regressions fail for all six independent wrong-provider left/right cases; successful current/legacy controls pass. Digest-tampering controls are tracked separately, retaining authentication as the first check. No live capture is claimed.

bsakaguchi commented

2026-10-15 18:26:28 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 11, 2026):

Repeated the actual CLI + SDK stdio MCP matrix again using a freshly compiled exact main e5699d23 from the separate Hermes review worktree. The provider bug still reproduces; source admission rules are unchanged by the recent main updates. Current and exact legacy identity controls continue to return equal authenticated CLI/MCP Evidence. The fix in #1760 has passed 24 regressions, full typecheck/lint/format/architecture checks, and the actual public matrix after independent review; complete successful records remain identical to main.

@N0zoM1z0 commented on GitHub (Oct 11, 2026): Repeated the actual CLI + SDK stdio MCP matrix again using a freshly compiled exact main `e5699d23` from the separate Hermes review worktree. The provider bug still reproduces; source admission rules are unchanged by the recent main updates. Current and exact legacy identity controls continue to return equal authenticated CLI/MCP Evidence. The fix in #1760 has passed 24 regressions, full typecheck/lint/format/architecture checks, and the actual public matrix after independent review; complete successful records remain identical to main.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:14:07 +00:00

[PR #591] [MERGED] fix(javascript): honor package exports condition order #2091

bsakaguchi referenced this issue

2026-10-16 21:14:21 +00:00

[PR #606] [MERGED] fix(javascript): preserve Node exports fallback stop reasons #2105

bsakaguchi referenced this issue

2026-10-17 21:10:29 +00:00

[PR #1333] [CLOSED] fix(javascript): reject invalid package exports configurations #2806