[PR #6214] [MERGED] fix(javascript): keep unmapped captured runtime scripts unknown #7205

New issue

Closed

opened 2026-11-01 21:46:08 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:46:08 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6214
Author: @kaoru0822-kitauji
Created: 10/22/2026
Status: ✅ Merged
Merged: 10/22/2026
Merged by: @kaoru0822-kitauji

Base: main ← Head: fix/6061-unmapped-runtime-script-unknown

📝 Commits (1)

e308f35 fix(javascript): keep unmapped captured runtime scripts unknown

📊 Changes

3 files changed (+266 additions, -35 deletions)

View changed files

📝 docs/javascript-runtime-reconciliation.md (+5 -1)
📝 src/domain/javascript/javascriptRuntimeReconciliationMatching.ts (+60 -34)
📝 tests/boundary/filesystem/javascript-applications/javascriptRuntimeContentPriority.test.ts (+201 -0)

📄 Description

What broke: reconcile-javascript-runtime reported a captured script whose bytes matched no static digest as high-confidence unmatched (no-static-content-match) and counted it in summary.unmatched, even when no layer had an automatic or caller-declared mapping for its location.
Fix: The matcher now records whether any mapping applied while it locates candidates. The captured-source and source-free branches share one no-candidate classification: unmapped gives unknown/no-authorized-location-mapping, mapped gives unmatched/no-static-content-match.
Risk: Low. No schema change; both reasons already exist. The only output change is for captured scripts at unmapped locations with no content match, which move from unmatched to unknown. Unique and ambiguous content-only correspondence and mapped disagreement are unchanged.

Summary

Fixes #6061.

Matching rule 6 in docs/javascript-runtime-reconciliation.md says missing authorization mappings stay unknown rather than becoming absence claims. The source-free branch already followed it. The captured-source branch did not, so a script captured outside every mapped root became a high-confidence negative correspondence.

Problem and expected behavior

Smallest trigger: one application layer with runtime_mappings: [], an Electron capture whose script lives under a separate root (no implicit artifact-root correspondence), captured bytes export const unrelated = 17;\n. On base the script item was status: "unmatched", confidence: "high", reason: "no-static-content-match", and summary.unmatched was 1. Expected: status: "unknown", confidence: "unknown", reason: "no-authorized-location-mapping", not counted as unmatched. If the captured bytes equal a static asset, it must still be a unique content-sha256 match.

Change and scope

src/domain/javascript/javascriptRuntimeReconciliationMatching.ts: candidatesWithLocation becomes locateEntity, which returns { locations, mapped } from the same mappedRuntimePaths pass. The source-free branch used to call mappedRuntimePaths a second time; that call is gone. The new withoutStaticCandidate helper owns the mapped/unmapped decision for both branches. Confidence for a mapped absence stays as before: high when captured bytes were compared against every static digest, unknown for a location-only absence.
docs/javascript-runtime-reconciliation.md: rule 6 now names both outcomes explicitly.
Not changed: a known digest disagreement at a mapped candidate (rule 5), unavailable mapped digests, and content-only ambiguity. Workers and targets have no captured bytes, so they already used the source-free branch. Browser, Electron, and Inspector observations all go through this one classifier, and only mappedRuntimePaths depends on whether the location is a file or a URL.

Contribution scope: not applicable. This is an ordinary fix within existing boundaries.

Contract and boundary impact

Semantic owner and earliest changed stage: the runtime reconciliation matcher (reconcileEntity/reconcileCapturedSource).
Contribution scope fit and linked maintainer decision: not applicable (ordinary fix).
CLI and MCP/tool-catalog contract: no schema change. no-authorized-location-mapping is already in the reason enum. Counts move from summary.unmatched to summary.unknown only for the case above.
Provider, bridge, target-format, or platform compatibility: none.
Evidence, artifact, provenance, or reconstruction contract: removes an unsupported high-confidence absence claim. No observed_as edge was emitted before or after.
Target selection, authority, upstream behavior, and cleanup details: unchanged.
Generated metadata, package, or installation impact: none. docs:check passes.
Read existing files or captured data.

Evidence and regression coverage

Tests added in tests/boundary/filesystem/javascript-applications/javascriptRuntimeContentPriority.test.ts, through reconcileJavaScriptRuntime with production static analysis and the synthetic Electron Evidence fixture:
- Unmapped captured script with no content match gives unknown/no-authorized-location-mapping, summary.unmatched: 0, and no observed_as edge. The source-free worker in the same capture gives the same result.
- Mapping present, no candidate at the mapped path, no content match gives unmatched/high/no-static-content-match. Checked for an explicit file-root mapping and for the implicit artifact-root correspondence with an empty mapping list.
- Two layers where only the first or only the second maps the location give unmatched. With neither mapped, the result is unknown.
- Unmapped content-only correspondence: one digest candidate gives matched/content-sha256, and two duplicate candidates in separate layers give ambiguous with candidate_static_count: 2. Neither counts as unmatched.
- URL-located captured script, modeled at the matcher boundary, with a url-prefix mapping: inside the prefix it is unmatched, outside it is unknown.
Base reproduction: with only the matcher file reverted on base 719d56ebf, 3 of the new cases fail with status: "unmatched", confidence: "high", reason: "no-static-content-match": the unmapped case, neither-layer-mapped, and URL outside prefix. The mapped and content-only counterexamples pass on base and after the fix.

User-visible CLI output: I ran the issue's CLI repro test (real scripts/rea.mjs reconcile-javascript-runtime after npm run build:cached; temporary file, not committed) with the fix:

{"equal":false,"summary":{"matched":0,"ambiguous":0,"unmatched":0,"unknown":3},"item":{"status":"unknown","basis":"none","confidence":"unknown","reason":"no-authorized-location-mapping","candidate_static_count":0}}
{"equal":true,"summary":{"matched":1,"ambiguous":0,"unmatched":0,"unknown":2},"item":{"status":"matched","basis":"content-sha256","confidence":"high","reason":"unique-content-match","candidate_static_count":1}}

Remaining proof gaps: no real Electron, browser, or Inspector target was run. Browser and Inspector URL locations are covered only by the matcher-boundary case. MCP transport was not exercised for this case, though it uses the same service.
Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

Issue CLI repro (temporary test, vitest run after npm run build:cached): 2 passed, with the output above.
npm run test:focused -- tests/boundary/filesystem/javascript-applications/javascriptRuntimeContentPriority.test.ts: 20 passed. With the matcher fix reverted: 3 failed, 17 passed.
npm run test:focused -- on the content-priority, reconciliation, reconciliation-ambiguity, Inspector observation, Inspector unresolved-target, Electron CLI, CDP script-metadata, browser MCP, selected-path Evidence, and JSON-input-status suites: 147 passed, 1 failed. The failure is javascriptRuntimeObservation.test.ts > includes targets outside the old caller root filter. It fails the same way on unmodified base 719d56ebf in this environment: the provider reports unverifiable-file-location for macOS temp paths. It is unrelated to this change.
npm run check:fast: passed.
npm run format:check: passed.
npm run docs:check: passed.

Compatibility, safety, and release

Breaking changes or migration steps: none. Consumers that counted these unmapped scripts as unmatched now see them as unknown, as the documented rule requires.
Real Hopper/Ghidra, browser, or OS coverage: none. Tested on macOS arm64 with Node v26.5.0 and synthetic passive Evidence.
Package or release metadata impact: none.
Security, privacy, process, or containment review: no new I/O, authority, or process interaction.

Author readiness

Human owner: @kaoru0822-kitauji

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/6214 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/22/2026 **Status:** ✅ Merged **Merged:** 10/22/2026 **Merged by:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Base:** `main` ← **Head:** `fix/6061-unmapped-runtime-script-unknown` --- ### 📝 Commits (1) - [`e308f35`](https://github.com/morluto/rea/commit/e308f35c43bb2efaef56b17ef78bfa2bf2d6f090) fix(javascript): keep unmapped captured runtime scripts unknown ### 📊 Changes **3 files changed** (+266 additions, -35 deletions) <details> <summary>View changed files</summary> 📝 `docs/javascript-runtime-reconciliation.md` (+5 -1) 📝 `src/domain/javascript/javascriptRuntimeReconciliationMatching.ts` (+60 -34) 📝 `tests/boundary/filesystem/javascript-applications/javascriptRuntimeContentPriority.test.ts` (+201 -0) </details> ### 📄 Description **What broke:** `reconcile-javascript-runtime` reported a captured script whose bytes matched no static digest as high-confidence `unmatched` (`no-static-content-match`) and counted it in `summary.unmatched`, even when no layer had an automatic or caller-declared mapping for its location. **Fix:** The matcher now records whether any mapping applied while it locates candidates. The captured-source and source-free branches share one no-candidate classification: unmapped gives `unknown`/`no-authorized-location-mapping`, mapped gives `unmatched`/`no-static-content-match`. **Risk:** Low. No schema change; both reasons already exist. The only output change is for captured scripts at unmapped locations with no content match, which move from `unmatched` to `unknown`. Unique and ambiguous content-only correspondence and mapped disagreement are unchanged. ## Summary Fixes #6061. Matching rule 6 in `docs/javascript-runtime-reconciliation.md` says missing authorization mappings stay unknown rather than becoming absence claims. The source-free branch already followed it. The captured-source branch did not, so a script captured outside every mapped root became a high-confidence negative correspondence. ## Problem and expected behavior Smallest trigger: one application layer with `runtime_mappings: []`, an Electron capture whose script lives under a separate root (no implicit artifact-root correspondence), captured bytes `export const unrelated = 17;\n`. On base the script item was `status: "unmatched"`, `confidence: "high"`, `reason: "no-static-content-match"`, and `summary.unmatched` was 1. Expected: `status: "unknown"`, `confidence: "unknown"`, `reason: "no-authorized-location-mapping"`, not counted as unmatched. If the captured bytes equal a static asset, it must still be a unique `content-sha256` match. ## Change and scope - `src/domain/javascript/javascriptRuntimeReconciliationMatching.ts`: `candidatesWithLocation` becomes `locateEntity`, which returns `{ locations, mapped }` from the same `mappedRuntimePaths` pass. The source-free branch used to call `mappedRuntimePaths` a second time; that call is gone. The new `withoutStaticCandidate` helper owns the mapped/unmapped decision for both branches. Confidence for a mapped absence stays as before: `high` when captured bytes were compared against every static digest, `unknown` for a location-only absence. - `docs/javascript-runtime-reconciliation.md`: rule 6 now names both outcomes explicitly. - Not changed: a known digest disagreement at a mapped candidate (rule 5), unavailable mapped digests, and content-only ambiguity. Workers and targets have no captured bytes, so they already used the source-free branch. Browser, Electron, and Inspector observations all go through this one classifier, and only `mappedRuntimePaths` depends on whether the location is a file or a URL. Contribution scope: not applicable. This is an ordinary fix within existing boundaries. ## Contract and boundary impact - Semantic owner and earliest changed stage: the runtime reconciliation matcher (`reconcileEntity`/`reconcileCapturedSource`). - Contribution scope fit and linked maintainer decision: not applicable (ordinary fix). - CLI and MCP/tool-catalog contract: no schema change. `no-authorized-location-mapping` is already in the reason enum. Counts move from `summary.unmatched` to `summary.unknown` only for the case above. - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: removes an unsupported high-confidence absence claim. No `observed_as` edge was emitted before or after. - Target selection, authority, upstream behavior, and cleanup details: unchanged. - Generated metadata, package, or installation impact: none. `docs:check` passes. - [x] Read existing files or captured data. ## Evidence and regression coverage - Tests added in `tests/boundary/filesystem/javascript-applications/javascriptRuntimeContentPriority.test.ts`, through `reconcileJavaScriptRuntime` with production static analysis and the synthetic Electron Evidence fixture: - Unmapped captured script with no content match gives `unknown`/`no-authorized-location-mapping`, `summary.unmatched: 0`, and no `observed_as` edge. The source-free worker in the same capture gives the same result. - Mapping present, no candidate at the mapped path, no content match gives `unmatched`/`high`/`no-static-content-match`. Checked for an explicit `file-root` mapping and for the implicit artifact-root correspondence with an empty mapping list. - Two layers where only the first or only the second maps the location give `unmatched`. With neither mapped, the result is `unknown`. - Unmapped content-only correspondence: one digest candidate gives `matched`/`content-sha256`, and two duplicate candidates in separate layers give `ambiguous` with `candidate_static_count: 2`. Neither counts as unmatched. - URL-located captured script, modeled at the matcher boundary, with a `url-prefix` mapping: inside the prefix it is `unmatched`, outside it is `unknown`. - Base reproduction: with only the matcher file reverted on base `719d56ebf`, 3 of the new cases fail with `status: "unmatched"`, `confidence: "high"`, `reason: "no-static-content-match"`: the unmapped case, neither-layer-mapped, and URL outside prefix. The mapped and content-only counterexamples pass on base and after the fix. - User-visible CLI output: I ran the issue's CLI repro test (real `scripts/rea.mjs reconcile-javascript-runtime` after `npm run build:cached`; temporary file, not committed) with the fix: ```json {"equal":false,"summary":{"matched":0,"ambiguous":0,"unmatched":0,"unknown":3},"item":{"status":"unknown","basis":"none","confidence":"unknown","reason":"no-authorized-location-mapping","candidate_static_count":0}} {"equal":true,"summary":{"matched":1,"ambiguous":0,"unmatched":0,"unknown":2},"item":{"status":"matched","basis":"content-sha256","confidence":"high","reason":"unique-content-match","candidate_static_count":1}} ``` - Remaining proof gaps: no real Electron, browser, or Inspector target was run. Browser and Inspector URL locations are covered only by the matcher-boundary case. MCP transport was not exercised for this case, though it uses the same service. - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - Issue CLI repro (temporary test, `vitest run` after `npm run build:cached`): 2 passed, with the output above. - `npm run test:focused -- tests/boundary/filesystem/javascript-applications/javascriptRuntimeContentPriority.test.ts`: 20 passed. With the matcher fix reverted: 3 failed, 17 passed. - `npm run test:focused --` on the content-priority, reconciliation, reconciliation-ambiguity, Inspector observation, Inspector unresolved-target, Electron CLI, CDP script-metadata, browser MCP, selected-path Evidence, and JSON-input-status suites: 147 passed, 1 failed. The failure is `javascriptRuntimeObservation.test.ts > includes targets outside the old caller root filter`. It fails the same way on unmodified base `719d56ebf` in this environment: the provider reports `unverifiable-file-location` for macOS temp paths. It is unrelated to this change. - `npm run check:fast`: passed. - `npm run format:check`: passed. - `npm run docs:check`: passed. ## Compatibility, safety, and release - Breaking changes or migration steps: none. Consumers that counted these unmapped scripts as `unmatched` now see them as `unknown`, as the documented rule requires. - Real Hopper/Ghidra, browser, or OS coverage: none. Tested on macOS arm64 with Node v26.5.0 and synthetic passive Evidence. - Package or release metadata impact: none. - Security, privacy, process, or containment review: no new I/O, authority, or process interaction. ## Author readiness Human owner: @kaoru0822-kitauji - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-11-01 21:46:08 +00:00