[PR #6209] [MERGED] feat(artifacts): make ASAR header admission configurable #7204

New issue

Closed

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

bsakaguchi commented

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

Owner

📋 Pull Request Information

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

Base: main ← Head: feat/asar-header-admission-setting

📝 Commits (2)

1f28b74 feat(artifacts): make ASAR header admission configurable
a157dc4 fix(artifacts): resolve ASAR header admission from the caller's environment

📊 Changes

53 files changed (+657 additions, -127 deletions)

View changed files

📝 .agents/skills/reverse-engineer-anything/references/javascript-applications.md (+4 -4)
📝 docs/electron-observation.md (+5 -5)
📝 docs/javascript-artifact-reconstruction.md (+10 -7)
📝 src/application/javascript/JavaScriptApplicationService.ts (+17 -2)
📝 src/application/javascript/JavaScriptArtifactReconstruction.ts (+8 -1)
📝 src/artifacts/ArtifactClassificationProbe.ts (+5 -2)
📝 src/artifacts/ArtifactHash.ts (+3 -1)
📝 src/artifacts/ArtifactOperationFailure.ts (+7 -3)
📝 src/artifacts/ArtifactProvider.ts (+2 -0)
📝 src/artifacts/AsarArtifactReader.ts (+9 -2)
📝 src/artifacts/AsarHeader.ts (+57 -24)
📝 src/artifacts/extraction/ArtifactExtraction.ts (+6 -1)
📝 src/artifacts/inventory/ArtifactGraphConstruction.ts (+2 -1)
📝 src/artifacts/inventory/classify.ts (+13 -3)
📝 src/artifacts/inventory/reader.ts (+8 -1)
📝 src/artifacts/inventory/scanCanonical.ts (+8 -1)
📝 src/artifacts/inventory/scanReader.ts (+11 -1)
📝 src/artifacts/inventory/types.ts (+3 -0)
📝 src/artifacts/javascript/JavaScriptArtifactFiles.ts (+10 -1)
📝 src/artifacts/javascript/JavaScriptArtifactReader.ts (+8 -1)

...and 33 more files

📄 Description

What broke: ASAR header/index admission was a hard-coded 16 MiB with "no runtime override", so a large Electron index could only be analyzed after extraction.
Fix: REA_ASAR_MAX_HEADER_BYTES (default 16777216, max 268435456). Each composition root resolves it from the environment it selected and threads it to every ASAR consumer; startup/doctor validate it and recovery names the effective value and source.
Risk: Low. Unset is byte-for-byte identical (same summary digest on a real 43 MB archive); invalid values fail closed as configuration_invalid.

Summary

Fixes #6176 (P0 ASAR item; the regex matching deadline is left for a separate PR).

Before: MAX_ASAR_HEADER_BYTES was a module constant shared by four consumers, and recovery text said the release had no override. After: operators can raise (up to 256 MiB) or lower the admission with one environment setting. The default stays the same.

Problem and expected behavior

An app whose ASAR header exceeds 16 MiB is refused by inspect_artifact, inventory_artifact, analyze_javascript_application, extract_artifact and Electron page resolution. Raising max_heap_mb or host memory does not help, and the only workaround was extracting the archive. Expected, per the issue: a named setting whose default equals today's constant, a documented maximum, recovery that names the effective value, and no change when unset.

Change and scope

src/config/asarHeaderAdmission.ts owns the setting: schema, default, maximum and constraint text. REA_ASAR_MAX_HEADER_BYTES joins the runtime environment schema, so MCP startup, rea doctor and setup/registration validation reject invalid values.
AsarHeader.ts replaces the constant with resolveAsarHeaderAdmission(environment). Nothing reads process.env; helpers without an environment use the default. The signature probe carries its admission and reports it with a limit observation, so inventory raises the failure for the same admission the probe used.
Owners resolve the admission from the environment they already select and pass that one value down:
- ArtifactProvider (inventory/inspection) and extraction resolve it into ArtifactInventoryOptions.asarHeaderAdmission. That reaches the root classification probe, root and nested AsarArtifactReaders, and the per-entry hashing probes.
- JavaScript application analysis parses it from the environment passed by its server (ServerToolContext.environment) or CLI caller.
- CdpElectronProvider and V8InspectorProvider receive it from createOptionalObservationFactories(selectedEnvironment) and the CLI contexts, and forward it to every authorizedElectronFile call.
The Electron header cache is process-wide, so it records header size and refuses a header cached under a larger admission when a provider with a smaller one asks. It is still bounded by the admission in use.
An invalid value fails closed. Artifact owners throw ConfigurationError, which translateArtifactFailure now passes through as typed (before, it became a generic I/O failure), and JS analysis returns it as a Result.
ArtifactAdmissionLimit gains source; error details add maximum_header_bytes_source and setting.
The maximum follows a real constraint: the header JSON is decoded into one string and parsed, and 256 MiB keeps it well under Node's ~512 Mi UTF-16 code-unit string ceiling. There is no floor, because a lower value only refuses more archives.
Not included: the regex deadline, decoder heaps and MCP startup budgets (P1 in the issue).

Contract and boundary impact

Semantic owner and earliest changed stage: src/config/asarHeaderAdmission.ts (value) and src/artifacts/AsarHeader.ts (admission, before any header allocation).
Contribution scope fit and linked maintainer decision: maintainer-authored issue #6176 lists this setting as P0; proposal posted on the issue before implementation.
CLI and MCP/tool-catalog contract: no schema change. Limit-error details add maximum_header_bytes_source and setting; recovery text now names the setting instead of "no runtime override".
Provider, bridge, target-format, or platform compatibility: none.
Evidence, artifact, provenance, or reconstruction contract: successful results unchanged (admission does not affect admitted output).
Target selection, authority, upstream behavior, and cleanup details: not applicable.
Generated metadata, package, or installation impact: none.

Expected effects:

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Tests added or updated (tests/boundary/filesystem/asarHeaderAdmission.test.ts):
- a raised setting admits a header 4 bytes above the default, and the value just below still refuses it;
- the caller's environment wins over the ambient one, which is the review scenario. With the ambient env stubbed to "1", createDirectAnalysis({REA_ASAR_MAX_HEADER_BYTES: header-1}) refuses a real @electron/asar archive for inventory_artifact and inspect_artifact, naming the setting, and createDirectAnalysis({}) admits it. JS analysis refuses at header-1 and admits at the exact header size;
- eight invalid spellings ("", 0, -1, leading zero, units, exponent, whitespace, max+1) are refused by both the parser and parseEnvironment. At each owner an invalid value surfaces as configuration_invalid, not a default fallback;
- electronFileScope.test.ts: a header cached under a larger admission is not reused for a smaller one.
- clientConfigurationEnvironment.test.ts gains a setup/doctor refusal row; existing default-boundary tests were updated to the new owner.

Real-app evidence, executed on this Mac (Node 26.5.0) with rea inspect-artifact /Applications/Signal.app/Contents/Resources/app.asar --integrity-policy record-and-continue --detail summary --evidence_output …. Signal's archive is 43 MB with a 400,496-byte header. Baseline = merge-base origin/main build; 3 runs each:

Build / setting	exit	wall	CPU user+sys	peak RSS	summary digest
baseline, unset	0	1.10 / 1.17 / 1.11 s	1.70 / 1.87 / 1.74 s	459–467 MiB	`7cf24efd802cd252`
this PR, unset	0	1.09 / 1.09 / 1.06 s	1.68 / 1.61 / 1.63 s	456–465 MiB	`7cf24efd802cd252`
this PR, `=400496`	0	1.07 s	1.70 s	470 MiB	`7cf24efd802cd252`
this PR, `=268435456`	0	1.08 s	1.69 s	457 MiB	`7cf24efd802cd252`
this PR, `=400495`	1 `truncated`	0.55 s	0.78 s	327 MiB	refused before header allocation
this PR, `=0`	1 `configuration_invalid`	0.54 s	0.71 s	326 MiB	—

Unset output is identical to baseline, and time and memory are within run-to-run noise. Token cost of successful results is unchanged. analyze-javascript-application on Obsidian's app.asar (6,984-byte header) is refused at =6983 and admitted at =6984, where it then reaches Obsidian's own unrelated unpacked-integrity mismatch. With REA_ASAR_MAX_HEADER_BYTES=0, rea doctor reports runtime-configuration:REA_ASAR_MAX_HEADER_BYTES as config_drift.

User-visible output at =400495:

code: truncated
message: ASAR header/index admission is limited to 400495 bytes by REA_ASAR_MAX_HEADER_BYTES. Set REA_ASAR_MAX_HEADER_BYTES in the environment that starts REA to a byte count up to 256 MiB / 268435456 bytes (default 16 MiB / 16777216 bytes), then restart REA. …
details: { reason: "limit", admission: "asar-header", maximum_header_bytes: 400495, maximum_header_bytes_source: "setting", setting: "REA_ASAR_MAX_HEADER_BYTES" }

Remaining proof gaps: no real application with a header above 16 MiB was available, so the raise path is covered by the sparse-file boundary test rather than a real app. Windows and Linux were not run locally (CI).

For evidence-bearing changes:

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

npm run test:focused -- <78 ASAR/Electron/V8/CLI/optional-provider test files> — 77 files passed. 1564 tests passed, 10 skipped, 1 failed: src/inspector/JavaScriptRuntimeScope.cancellation.test.ts › stops Inspector target authorization after the current stat settles, which fails identically on unmodified origin/main on this macOS host (pre-existing, not changed here).
npm run test:focused -- tests/boundary/filesystem/clientConfigurationEnvironment.test.ts tests/boundary/filesystem/electronFileScope.test.ts src/browser/ElectronFileScope.cleanup.test.ts tests/boundary/mcp/asarListingAdmissionMcp.test.ts — 39 passed, 10 skipped.
npm run check:fast — passed.
npm run format:check — passed.
npm run docs:check — passed.
Real-app runs above (npm run build:cached on both trees).

Compatibility, safety, and release

Breaking changes or migration steps: none; unset behavior is unchanged. The internal export MAX_ASAR_HEADER_BYTES is replaced by DEFAULT_ASAR_MAX_HEADER_BYTES (config) and resolveAsarHeaderAdmission().
Real Hopper/Ghidra, browser, or OS coverage: macOS arm64 only, with real Signal and Obsidian archives; no browser.
Package or release metadata impact: none.
Security, privacy, process, or containment review: the maximum bounds a caller-raised allocation; invalid values fail closed. The Electron header cache budget follows the same admission.

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.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🤖 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/6209 **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:** `feat/asar-header-admission-setting` --- ### 📝 Commits (2) - [`1f28b74`](https://github.com/morluto/rea/commit/1f28b7478150f6b759b9263129031b58d22edd2b) feat(artifacts): make ASAR header admission configurable - [`a157dc4`](https://github.com/morluto/rea/commit/a157dc49b37e3a094c71716200a2b73dc0445821) fix(artifacts): resolve ASAR header admission from the caller's environment ### 📊 Changes **53 files changed** (+657 additions, -127 deletions) <details> <summary>View changed files</summary> 📝 `.agents/skills/reverse-engineer-anything/references/javascript-applications.md` (+4 -4) 📝 `docs/electron-observation.md` (+5 -5) 📝 `docs/javascript-artifact-reconstruction.md` (+10 -7) 📝 `src/application/javascript/JavaScriptApplicationService.ts` (+17 -2) 📝 `src/application/javascript/JavaScriptArtifactReconstruction.ts` (+8 -1) 📝 `src/artifacts/ArtifactClassificationProbe.ts` (+5 -2) 📝 `src/artifacts/ArtifactHash.ts` (+3 -1) 📝 `src/artifacts/ArtifactOperationFailure.ts` (+7 -3) 📝 `src/artifacts/ArtifactProvider.ts` (+2 -0) 📝 `src/artifacts/AsarArtifactReader.ts` (+9 -2) 📝 `src/artifacts/AsarHeader.ts` (+57 -24) 📝 `src/artifacts/extraction/ArtifactExtraction.ts` (+6 -1) 📝 `src/artifacts/inventory/ArtifactGraphConstruction.ts` (+2 -1) 📝 `src/artifacts/inventory/classify.ts` (+13 -3) 📝 `src/artifacts/inventory/reader.ts` (+8 -1) 📝 `src/artifacts/inventory/scanCanonical.ts` (+8 -1) 📝 `src/artifacts/inventory/scanReader.ts` (+11 -1) 📝 `src/artifacts/inventory/types.ts` (+3 -0) 📝 `src/artifacts/javascript/JavaScriptArtifactFiles.ts` (+10 -1) 📝 `src/artifacts/javascript/JavaScriptArtifactReader.ts` (+8 -1) _...and 33 more files_ </details> ### 📄 Description > **What broke:** ASAR header/index admission was a hard-coded 16 MiB with "no runtime override", so a large Electron index could only be analyzed after extraction. > **Fix:** `REA_ASAR_MAX_HEADER_BYTES` (default 16777216, max 268435456). Each composition root resolves it from the environment it selected and threads it to every ASAR consumer; startup/doctor validate it and recovery names the effective value and source. > **Risk:** Low. Unset is byte-for-byte identical (same summary digest on a real 43 MB archive); invalid values fail closed as `configuration_invalid`. ## Summary Fixes #6176 (P0 ASAR item; the regex matching deadline is left for a separate PR). Before: `MAX_ASAR_HEADER_BYTES` was a module constant shared by four consumers, and recovery text said the release had no override. After: operators can raise (up to 256 MiB) or lower the admission with one environment setting. The default stays the same. ## Problem and expected behavior An app whose ASAR header exceeds 16 MiB is refused by `inspect_artifact`, `inventory_artifact`, `analyze_javascript_application`, `extract_artifact` and Electron page resolution. Raising `max_heap_mb` or host memory does not help, and the only workaround was extracting the archive. Expected, per the issue: a named setting whose default equals today's constant, a documented maximum, recovery that names the effective value, and no change when unset. ## Change and scope - `src/config/asarHeaderAdmission.ts` owns the setting: schema, default, maximum and constraint text. `REA_ASAR_MAX_HEADER_BYTES` joins the runtime environment schema, so MCP startup, `rea doctor` and setup/registration validation reject invalid values. - `AsarHeader.ts` replaces the constant with `resolveAsarHeaderAdmission(environment)`. Nothing reads `process.env`; helpers without an environment use the default. The signature probe carries its admission and reports it with a `limit` observation, so inventory raises the failure for the same admission the probe used. - Owners resolve the admission from the environment they already select and pass that one value down: - `ArtifactProvider` (inventory/inspection) and extraction resolve it into `ArtifactInventoryOptions.asarHeaderAdmission`. That reaches the root classification probe, root and nested `AsarArtifactReader`s, and the per-entry hashing probes. - JavaScript application analysis parses it from the `environment` passed by its server (`ServerToolContext.environment`) or CLI caller. - `CdpElectronProvider` and `V8InspectorProvider` receive it from `createOptionalObservationFactories(selectedEnvironment)` and the CLI contexts, and forward it to every `authorizedElectronFile` call. - The Electron header cache is process-wide, so it records header size and refuses a header cached under a larger admission when a provider with a smaller one asks. It is still bounded by the admission in use. - An invalid value fails closed. Artifact owners throw `ConfigurationError`, which `translateArtifactFailure` now passes through as typed (before, it became a generic I/O failure), and JS analysis returns it as a `Result`. - `ArtifactAdmissionLimit` gains `source`; error details add `maximum_header_bytes_source` and `setting`. - The maximum follows a real constraint: the header JSON is decoded into one string and parsed, and 256 MiB keeps it well under Node's ~512 Mi UTF-16 code-unit string ceiling. There is no floor, because a lower value only refuses more archives. - Not included: the regex deadline, decoder heaps and MCP startup budgets (P1 in the issue). ## Contract and boundary impact - Semantic owner and earliest changed stage: `src/config/asarHeaderAdmission.ts` (value) and `src/artifacts/AsarHeader.ts` (admission, before any header allocation). - Contribution scope fit and linked maintainer decision: maintainer-authored issue #6176 lists this setting as P0; proposal posted on the issue before implementation. - CLI and MCP/tool-catalog contract: no schema change. Limit-error details add `maximum_header_bytes_source` and `setting`; recovery text now names the setting instead of "no runtime override". - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: successful results unchanged (admission does not affect admitted output). - Target selection, authority, upstream behavior, and cleanup details: not applicable. - Generated metadata, package, or installation impact: none. Expected effects: - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated (`tests/boundary/filesystem/asarHeaderAdmission.test.ts`): - a raised setting admits a header 4 bytes above the default, and the value just below still refuses it; - the caller's environment wins over the ambient one, which is the review scenario. With the ambient env stubbed to `"1"`, `createDirectAnalysis({REA_ASAR_MAX_HEADER_BYTES: header-1})` refuses a real `@electron/asar` archive for `inventory_artifact` and `inspect_artifact`, naming the setting, and `createDirectAnalysis({})` admits it. JS analysis refuses at `header-1` and admits at the exact header size; - eight invalid spellings (`""`, `0`, `-1`, leading zero, units, exponent, whitespace, max+1) are refused by both the parser and `parseEnvironment`. At each owner an invalid value surfaces as `configuration_invalid`, not a default fallback; - `electronFileScope.test.ts`: a header cached under a larger admission is not reused for a smaller one. - `clientConfigurationEnvironment.test.ts` gains a setup/doctor refusal row; existing default-boundary tests were updated to the new owner. - Real-app evidence, executed on this Mac (Node 26.5.0) with `rea inspect-artifact /Applications/Signal.app/Contents/Resources/app.asar --integrity-policy record-and-continue --detail summary --evidence_output …`. Signal's archive is 43 MB with a 400,496-byte header. Baseline = merge-base `origin/main` build; 3 runs each: | Build / setting | exit | wall | CPU user+sys | peak RSS | summary digest | | --- | --- | --- | --- | --- | --- | | baseline, unset | 0 | 1.10 / 1.17 / 1.11 s | 1.70 / 1.87 / 1.74 s | 459–467 MiB | `7cf24efd802cd252` | | this PR, unset | 0 | 1.09 / 1.09 / 1.06 s | 1.68 / 1.61 / 1.63 s | 456–465 MiB | `7cf24efd802cd252` | | this PR, `=400496` | 0 | 1.07 s | 1.70 s | 470 MiB | `7cf24efd802cd252` | | this PR, `=268435456` | 0 | 1.08 s | 1.69 s | 457 MiB | `7cf24efd802cd252` | | this PR, `=400495` | 1 `truncated` | 0.55 s | 0.78 s | 327 MiB | refused before header allocation | | this PR, `=0` | 1 `configuration_invalid` | 0.54 s | 0.71 s | 326 MiB | — | Unset output is identical to baseline, and time and memory are within run-to-run noise. Token cost of successful results is unchanged. `analyze-javascript-application` on Obsidian's `app.asar` (6,984-byte header) is refused at `=6983` and admitted at `=6984`, where it then reaches Obsidian's own unrelated unpacked-integrity mismatch. With `REA_ASAR_MAX_HEADER_BYTES=0`, `rea doctor` reports `runtime-configuration:REA_ASAR_MAX_HEADER_BYTES` as `config_drift`. - User-visible output at `=400495`: ``` code: truncated message: ASAR header/index admission is limited to 400495 bytes by REA_ASAR_MAX_HEADER_BYTES. Set REA_ASAR_MAX_HEADER_BYTES in the environment that starts REA to a byte count up to 256 MiB / 268435456 bytes (default 16 MiB / 16777216 bytes), then restart REA. … details: { reason: "limit", admission: "asar-header", maximum_header_bytes: 400495, maximum_header_bytes_source: "setting", setting: "REA_ASAR_MAX_HEADER_BYTES" } ``` - Remaining proof gaps: no real application with a header above 16 MiB was available, so the raise path is covered by the sparse-file boundary test rather than a real app. Windows and Linux were not run locally (CI). For evidence-bearing changes: - [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 - `npm run test:focused -- <78 ASAR/Electron/V8/CLI/optional-provider test files>` — 77 files passed. 1564 tests passed, 10 skipped, 1 failed: `src/inspector/JavaScriptRuntimeScope.cancellation.test.ts › stops Inspector target authorization after the current stat settles`, which fails identically on unmodified `origin/main` on this macOS host (pre-existing, not changed here). - `npm run test:focused -- tests/boundary/filesystem/clientConfigurationEnvironment.test.ts tests/boundary/filesystem/electronFileScope.test.ts src/browser/ElectronFileScope.cleanup.test.ts tests/boundary/mcp/asarListingAdmissionMcp.test.ts` — 39 passed, 10 skipped. - `npm run check:fast` — passed. - `npm run format:check` — passed. - `npm run docs:check` — passed. - Real-app runs above (`npm run build:cached` on both trees). ## Compatibility, safety, and release - Breaking changes or migration steps: none; unset behavior is unchanged. The internal export `MAX_ASAR_HEADER_BYTES` is replaced by `DEFAULT_ASAR_MAX_HEADER_BYTES` (config) and `resolveAsarHeaderAdmission()`. - Real Hopper/Ghidra, browser, or OS coverage: macOS arm64 only, with real Signal and Obsidian archives; no browser. - Package or release metadata impact: none. - Security, privacy, process, or containment review: the maximum bounds a caller-raised allocation; invalid values fail closed. The Electron header cache budget follows the same admission. ## 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. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. 🤖 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:06 +00:00