morluto/rea
1
0
Fork 0
mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00
Code Issues 1.3k Projects Packages Wiki Activity

[GH-ISSUE #1065] [Feature] Roadmap: improve MCP usability and performance under bounded resources #390

New issue
Open
opened 2026-10-15 18:24:35 +00:00 by bsakaguchi · 47 comments
bsakaguchi commented 2026-10-15 18:24:35 +00:00
Owner
Copy link

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

Originally assigned to: @N0zoM1z0 on GitHub.

Before submitting

  • I searched open and closed issues and pull requests for related work.
  • I removed credentials, tokens, private host paths, and sensitive target data.

Area

MCP or agent integration; Evidence, artifacts, or reconstruction; native analysis or decompilation.

Current limitation

The intended workflow is: connect to REA once, select a target and question, and begin analysis. Validation of the actual published rea-agents@6.0.0 package finds unnecessary startup/context costs and failures that interrupt this workflow: ordinary JavaScript analysis can disconnect a default MCP client, client cancellation does not promptly stop analysis, and first Windows Ghidra analysis can exceed the client's default deadline on a constrained host.

This is a tracking issue for one workflow outcome: responsive, reliable MCP analysis with measured CPU, memory, disk, and context costs. Existing issues remain the owners of their specific contract decisions and failures. The work items below can be implemented independently; this issue does not select a new universal result contract.

Validated baseline

Validation date: 2026-10-08. Published package: rea-agents@6.0.0, release revision 6fee42689ae6e95a0182e0d4d0f55644e73e72be. MCP client/server SDK: 2.3.1. Linux tests used Node 24.18.0; native Windows tests used Node 22.19.0, Ghidra 12.1.4, and JDK 21. Heavy lanes ran sequentially with two CPUs and explicit heap budgets. Timing values describe these runs, rather than universal product limits.

Observation Measured behavior Owning boundary / related work
Large discovery payload 139 tool definitions occupy 2,038,662 UTF-8 bytes. First tools/list: 589 ms; subsequent requests: 252–462 ms. REA catalog and SDK schema projection; #723.
All output validators compiled before the first call First binary_session: 3.36 s, including 139 client-side validator compilations taking 3.02 s before request transmission. Warm call: 25.7 ms. Refreshing the list causes another 139 compilations, taking 2.96 s. Pinned client SDK cache/validator behavior; distinct from server execution.
Repeated response representations A small application fixture with 3,020 inventoried text bytes and nine parsed JavaScript files produces 847,473 Evidence bytes and a 3,559,384-byte MCP result: 4.20 times the Evidence size. REA result projection; #723.
Default MCP connection fails on a small source A 28,279-byte, 300-function source analyzed without cancellation closes the connection with ReadBuffer exceeded maximum size of 10485760 bytes; the next ping fails. The same CLI analysis completes with valid 9,583,065-byte JSON and zero parse failures. Result generation/projection, transport framing, and client consumption; #1053 and #1050.
Cancellation does not stop the observed workload The client sends cancellation around 206 ms and rejects locally around 207 ms. The server subsequently logs successful analysis and attempts an oversized response. The 300-function ping takes 4.39 s; the 1,200-function ping fails. Sampled client/server family peaks: 1.17/1.84 GiB. Application compute, MCP control responsiveness, publication, and lifecycle cleanup.
First Windows deep analysis exceeds the client deadline With two CPUs and a 512 MiB Java heap, opening a source-owned native x86 PE succeeds in 4.90 s; first binary_overview fails at 60.073 s with REQUEST_TIMEOUT. Separate x86 and x64 CLI/MCP acceptance passes with 360-second call deadlines. Client deadline versus provider startup/import/analysis; adjacent to #1048 and PR #974.

Catalog decomposition: input-facing definitions occupy 584,364 bytes; output schemas occupy 1,452,214 bytes. The full and input-facing representations measure 492,944 and 141,245 cl100k_base proxy tokens respectively. These are tokenizer proxies for selected representations, not observed model context or billing. Host tool selection and treatment of output schemas must be measured separately.

The 6.0.0 real Notion CLI run completes and produces 336,236,132 bytes of valid output, with exact baseline Evidence identities and statistics. This confirms that complete analysis can succeed while result delivery remains expensive. The separate server-side Invalid string length failure in #1053 occurred even with an enlarged 1 GiB client buffer; it is distinct from the default 10 MiB framing failure reproduced above.

Reduced reproduction

Generate an inert, source-owned fixture in an isolated working directory:

import { mkdirSync, writeFileSync } from "node:fs";

const source = Array.from({ length: 300 }, (_, i) =>
  `function selected_${i}(value) { const next = JSON.stringify(value); return next + 'item-${i}'; }`
).join("\n");
mkdirSync("fixture", { recursive: true });
writeFileSync("fixture/monolith.js", source);
  1. Start the published rea-agents@6.0.0 MCP server and connect with the pinned SDK 2.3.1 stdio client using its default receive-buffer setting.
  2. List tools and call binary_session once, separating initial validator compilation from the subsequent analysis measurement.
  3. Call the following tool with the fixture's absolute directory path, without cancellation, then ping the connection:
{
  "name": "analyze_javascript_application",
  "arguments": {
    "input_path": "<absolute-fixture-directory>",
    "format": "directory"
  }
}
  1. Compare with complete CLI analysis of the same bytes. The observed MCP failure is connection closure; the CLI result parses successfully.
  2. In a separate session, repeat with an SDK abort signal scheduled 200 ms after the first analysis progress notification. Record the outgoing cancellation notification, server completion/publication, ping responsiveness, owned-resource cleanup, and the next tool call. Client-local rejection alone is not a passing cancellation test.
  3. For the Windows deadline case, use a source-owned native x86 PE and configured bring-your-own Ghidra. Open with automatic provider selection, then call binary_overview with the SDK's unmodified default deadline. Compare a separate longer-deadline run under the same CPU/JVM budget. Keep client and provider deadlines separate in diagnostics.

The JavaScript fixture is parsed as text; its application code is not executed. Default framing failure and cancellation failure are separate experiments.

Use cases

  • A new agent connects once and obtains a useful answer from a modest JavaScript application without special client tuning or a lost session.
  • An analyst cancels expensive analysis and immediately continues investigating another question with the same MCP connection.
  • An agent requests a relevant function, object, relationship, or facet from a large retained analysis without repeatedly moving the complete graph through model context.
  • A Windows user starts first native analysis on a modest machine and receives useful progress, an accurate lifecycle outcome, and workable waiting/recovery guidance.

Desired outcome and success criteria

  • Ordinary supported requests either deliver a usable result or a typed, actionable constraint/recovery outcome while preserving the connection. A complete analysis is distinguishable from successful result delivery.
  • Complete Evidence remains available with exact identities, source locations, coverage, limitations, and unknowns. Caller-selected views relate honestly to the complete record and return useful findings inline.
  • Cancellation is evaluated at server execution and publication boundaries. Once cancellation is observed, owned work stops promptly, cleanup completes, and a subsequent request succeeds. Completion/cancellation races have an explicit tested outcome.
  • Catalog and validation optimizations preserve named contracts, the complete canonical inventory, schema validity after SDK conversion, correct cache invalidation, and representative client compatibility.
  • Improvements are measured with the same fixture and budgets before and after the change, including latency and sampled resource peaks. Wire bytes and tokenizer proxies are distinguished from actual host/model context use.

Acceptance ledger

  • Default SDK framing: the 300-function fixture has a usable result/recovery workflow and a working subsequent ping/tool call.
  • Real large ASAR: complete analysis/Evidence identities match the CLI baseline; transport recovery and selected views work without re-running analysis solely to shrink the response.
  • Cancellation: cover a single large file and many files, as well as parsing, graph completion, validation/hashing, and response preparation where applicable. Verify the actual stop/cleanup state and subsequent calls.
  • Catalog: measure cold and repeated listing, bytes, validator compilation count/time, and representative tool selection tasks; validate the converted JSON Schema dialect and previously fixed client constraints.
  • Cache correctness: cover tool metadata/availability changes, output-schema changes, and list refresh without stale validators or unnecessary recompilation.
  • Compatibility: test structured consumers and text fallbacks before changing repeated response fields; preserve meaningful CLI/MCP parity and exact contract binding.
  • Windows Ghidra: repeat native x86/x64 acceptance under bounded CPU/JVM settings; report client deadline, provider startup stages, progress, cancellation, target-byte identity, and owned-process/temp cleanup separately.
  • Performance: record first/warm call latency, server event-loop responsiveness, serialization/transfer/client parsing costs, response and Evidence sizes, cancellation-to-stop latency, process-family RSS, CPU use, and retained/temporary disk growth. Repeat runs where host noise affects the conclusion.

Authority boundaries and non-goals

REA remains local-only; provider protocols stay in provider adapters and shared workflows stay behind CLI/MCP adapters. Ghidra remains bring-your-own, with the existing read-only Windows authority. Target bytes and user-owned databases remain protected by their existing lifecycle contracts.

Retain existing complete-result contracts during low-risk performance work. Any response-field removal or default-result change requires the specific compatibility decision tracked in #723/#1050; this roadmap does not authorize silent truncation. Preserve complete self-describing discovery and exact named schema binding, including the client compatibility work from #919.

Keep CPU, memory, temporary disk, and concurrency budgets explicit in validation. A worker implementation must account for large object-transfer/serialization allocations and owned-worker cleanup. Avoid multiplying workers merely to improve one elapsed-time number.

Transport authentication credentials and explicitly sensitive caller values remain protected. Public verification evidence uses source-owned fixtures and sanitized measurements rather than private host paths or target source.

Alternatives considered

  • Cache catalog projection: reduces repeated computation but does not by itself reduce catalog wire size or model context.
  • Increase client buffers/heaps: can enable some complete transfers but does not remove server single-string limits or improve result consumption; #1053 already distinguishes those failures.
  • Use CLI --filter-output: useful for output selection, but it happens after full analysis and does not provide the same MCP workflow by itself.
  • Add more abort checks: useful inside interruptible work, but cannot promptly process a cancellation notification while a long synchronous operation blocks the MCP event loop.
  • Increase a server/provider timeout: does not extend another client's timer. Progress-based timeout resets require client support/configuration. PR #974 concerns the provider startup deadline, while this validation reproduced a separate 60-second client deadline.

Possible direction

T1 was completed in #1088. Implementation priority: effective cancellation next; low-risk catalog caching and Windows waiting guidance can proceed independently. Response representation changes and upstream-client optimization follow their own compatibility decisions.

  • T1 — Reliable result delivery (high priority; #1053/#1050): establish an honest transport-constraint outcome and a usable retained-Evidence/selected-view continuation. Preserve the full-result path and exact provenance. Measure analysis, admission, serialization, transfer, and client parsing independently.
  • T2 — Responsive cancellation (high priority): investigate bounded worker isolation and cooperative yielding for heavy phases. Keep the MCP control path responsive, avoid duplicate large graph copies where possible, and test cancellation/publication races and cleanup before extending the approach to other domains.
  • T3 — Catalog projection/cache efficiency (#723): cache the actual advertised schema representation at an appropriate SDK/adapter seam with correct invalidation. Evaluate schema-local reuse and input presentation through real client tasks before any representation change; keep the canonical inventory complete.
  • T4 — Response repetition (#723): quantify the two repetition layers (result versus evidence.normalized_result, then text versus structured output). Evaluate compatible representations with actual consumers. Removing one layer alone does not guarantee that a real ASAR response fits ordinary clients.
  • T5 — Client output-validator compilation: pursue per-tool lazy compilation and correct invalidation in the upstream SDK. For REA-controlled clients, evaluate the SDK's supported per-call toolDefinition option. Measure first call and refresh behavior while keeping validation active. Record external-client coverage separately from server improvements.
  • T6 — Windows first-analysis lifecycle (related: #1048, PR #974): first profile launch, import, auto-analysis, and bridge readiness. Improve supported client waiting/progress guidance, then evaluate lifecycle improvements using existing session/task mechanisms where appropriate. Verify reuse boundaries and exact target binding before introducing any persistence.

References

Originally created by @N0zoM1z0 on GitHub (Oct 8, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1065 Originally assigned to: @N0zoM1z0 on GitHub. # Before submitting - [x] I searched open and closed issues and pull requests for related work. - [x] I removed credentials, tokens, private host paths, and sensitive target data. ## Area MCP or agent integration; Evidence, artifacts, or reconstruction; native analysis or decompilation. ## Current limitation The intended workflow is: connect to REA once, select a target and question, and begin analysis. Validation of the actual published `rea-agents@6.0.0` package finds unnecessary startup/context costs and failures that interrupt this workflow: ordinary JavaScript analysis can disconnect a default MCP client, client cancellation does not promptly stop analysis, and first Windows Ghidra analysis can exceed the client's default deadline on a constrained host. This is a tracking issue for one workflow outcome: responsive, reliable MCP analysis with measured CPU, memory, disk, and context costs. Existing issues remain the owners of their specific contract decisions and failures. The work items below can be implemented independently; this issue does not select a new universal result contract. ### Validated baseline Validation date: 2026-10-08. Published package: `rea-agents@6.0.0`, release revision `6fee42689ae6e95a0182e0d4d0f55644e73e72be`. MCP client/server SDK: 2.3.1. Linux tests used Node 24.18.0; native Windows tests used Node 22.19.0, Ghidra 12.1.4, and JDK 21. Heavy lanes ran sequentially with two CPUs and explicit heap budgets. Timing values describe these runs, rather than universal product limits. | Observation | Measured behavior | Owning boundary / related work | | --- | --- | --- | | Large discovery payload | 139 tool definitions occupy 2,038,662 UTF-8 bytes. First `tools/list`: 589 ms; subsequent requests: 252–462 ms. | REA catalog and SDK schema projection; #723. | | All output validators compiled before the first call | First `binary_session`: 3.36 s, including 139 client-side validator compilations taking 3.02 s before request transmission. Warm call: 25.7 ms. Refreshing the list causes another 139 compilations, taking 2.96 s. | Pinned client SDK cache/validator behavior; distinct from server execution. | | Repeated response representations | A small application fixture with 3,020 inventoried text bytes and nine parsed JavaScript files produces 847,473 Evidence bytes and a 3,559,384-byte MCP result: 4.20 times the Evidence size. | REA result projection; #723. | | Default MCP connection fails on a small source | A 28,279-byte, 300-function source analyzed without cancellation closes the connection with `ReadBuffer exceeded maximum size of 10485760 bytes`; the next ping fails. The same CLI analysis completes with valid 9,583,065-byte JSON and zero parse failures. | Result generation/projection, transport framing, and client consumption; #1053 and #1050. | | Cancellation does not stop the observed workload | The client sends cancellation around 206 ms and rejects locally around 207 ms. The server subsequently logs successful analysis and attempts an oversized response. The 300-function ping takes 4.39 s; the 1,200-function ping fails. Sampled client/server family peaks: 1.17/1.84 GiB. | Application compute, MCP control responsiveness, publication, and lifecycle cleanup. | | First Windows deep analysis exceeds the client deadline | With two CPUs and a 512 MiB Java heap, opening a source-owned native x86 PE succeeds in 4.90 s; first `binary_overview` fails at 60.073 s with `REQUEST_TIMEOUT`. Separate x86 and x64 CLI/MCP acceptance passes with 360-second call deadlines. | Client deadline versus provider startup/import/analysis; adjacent to #1048 and PR #974. | Catalog decomposition: input-facing definitions occupy 584,364 bytes; output schemas occupy 1,452,214 bytes. The full and input-facing representations measure 492,944 and 141,245 `cl100k_base` proxy tokens respectively. These are tokenizer proxies for selected representations, not observed model context or billing. Host tool selection and treatment of output schemas must be measured separately. The 6.0.0 real Notion CLI run completes and produces 336,236,132 bytes of valid output, with exact baseline Evidence identities and statistics. This confirms that complete analysis can succeed while result delivery remains expensive. The separate server-side `Invalid string length` failure in #1053 occurred even with an enlarged 1 GiB client buffer; it is distinct from the default 10 MiB framing failure reproduced above. ### Reduced reproduction Generate an inert, source-owned fixture in an isolated working directory: ```js import { mkdirSync, writeFileSync } from "node:fs"; const source = Array.from({ length: 300 }, (_, i) => `function selected_${i}(value) { const next = JSON.stringify(value); return next + 'item-${i}'; }` ).join("\n"); mkdirSync("fixture", { recursive: true }); writeFileSync("fixture/monolith.js", source); ``` 1. Start the published `rea-agents@6.0.0` MCP server and connect with the pinned SDK 2.3.1 stdio client using its default receive-buffer setting. 2. List tools and call `binary_session` once, separating initial validator compilation from the subsequent analysis measurement. 3. Call the following tool with the fixture's absolute directory path, without cancellation, then ping the connection: ```json { "name": "analyze_javascript_application", "arguments": { "input_path": "<absolute-fixture-directory>", "format": "directory" } } ``` 4. Compare with complete CLI analysis of the same bytes. The observed MCP failure is connection closure; the CLI result parses successfully. 5. In a separate session, repeat with an SDK abort signal scheduled 200 ms after the first analysis progress notification. Record the outgoing cancellation notification, server completion/publication, ping responsiveness, owned-resource cleanup, and the next tool call. Client-local rejection alone is not a passing cancellation test. 6. For the Windows deadline case, use a source-owned native x86 PE and configured bring-your-own Ghidra. Open with automatic provider selection, then call `binary_overview` with the SDK's unmodified default deadline. Compare a separate longer-deadline run under the same CPU/JVM budget. Keep client and provider deadlines separate in diagnostics. The JavaScript fixture is parsed as text; its application code is not executed. Default framing failure and cancellation failure are separate experiments. ## Use cases - A new agent connects once and obtains a useful answer from a modest JavaScript application without special client tuning or a lost session. - An analyst cancels expensive analysis and immediately continues investigating another question with the same MCP connection. - An agent requests a relevant function, object, relationship, or facet from a large retained analysis without repeatedly moving the complete graph through model context. - A Windows user starts first native analysis on a modest machine and receives useful progress, an accurate lifecycle outcome, and workable waiting/recovery guidance. ## Desired outcome and success criteria - Ordinary supported requests either deliver a usable result or a typed, actionable constraint/recovery outcome while preserving the connection. A complete analysis is distinguishable from successful result delivery. - Complete Evidence remains available with exact identities, source locations, coverage, limitations, and unknowns. Caller-selected views relate honestly to the complete record and return useful findings inline. - Cancellation is evaluated at server execution and publication boundaries. Once cancellation is observed, owned work stops promptly, cleanup completes, and a subsequent request succeeds. Completion/cancellation races have an explicit tested outcome. - Catalog and validation optimizations preserve named contracts, the complete canonical inventory, schema validity after SDK conversion, correct cache invalidation, and representative client compatibility. - Improvements are measured with the same fixture and budgets before and after the change, including latency and sampled resource peaks. Wire bytes and tokenizer proxies are distinguished from actual host/model context use. ### Acceptance ledger - [x] Default SDK framing: the 300-function fixture has a usable result/recovery workflow and a working subsequent ping/tool call. - [x] Real large ASAR: complete analysis/Evidence identities match the CLI baseline; transport recovery and selected views work without re-running analysis solely to shrink the response. - [ ] Cancellation: cover a single large file and many files, as well as parsing, graph completion, validation/hashing, and response preparation where applicable. Verify the actual stop/cleanup state and subsequent calls. - [ ] Catalog: measure cold and repeated listing, bytes, validator compilation count/time, and representative tool selection tasks; validate the converted JSON Schema dialect and previously fixed client constraints. - [ ] Cache correctness: cover tool metadata/availability changes, output-schema changes, and list refresh without stale validators or unnecessary recompilation. - [ ] Compatibility: test structured consumers and text fallbacks before changing repeated response fields; preserve meaningful CLI/MCP parity and exact contract binding. - [ ] Windows Ghidra: repeat native x86/x64 acceptance under bounded CPU/JVM settings; report client deadline, provider startup stages, progress, cancellation, target-byte identity, and owned-process/temp cleanup separately. - [ ] Performance: record first/warm call latency, server event-loop responsiveness, serialization/transfer/client parsing costs, response and Evidence sizes, cancellation-to-stop latency, process-family RSS, CPU use, and retained/temporary disk growth. Repeat runs where host noise affects the conclusion. ## Authority boundaries and non-goals REA remains local-only; provider protocols stay in provider adapters and shared workflows stay behind CLI/MCP adapters. Ghidra remains bring-your-own, with the existing read-only Windows authority. Target bytes and user-owned databases remain protected by their existing lifecycle contracts. Retain existing complete-result contracts during low-risk performance work. Any response-field removal or default-result change requires the specific compatibility decision tracked in #723/#1050; this roadmap does not authorize silent truncation. Preserve complete self-describing discovery and exact named schema binding, including the client compatibility work from #919. Keep CPU, memory, temporary disk, and concurrency budgets explicit in validation. A worker implementation must account for large object-transfer/serialization allocations and owned-worker cleanup. Avoid multiplying workers merely to improve one elapsed-time number. Transport authentication credentials and explicitly sensitive caller values remain protected. Public verification evidence uses source-owned fixtures and sanitized measurements rather than private host paths or target source. ## Alternatives considered - **Cache catalog projection:** reduces repeated computation but does not by itself reduce catalog wire size or model context. - **Increase client buffers/heaps:** can enable some complete transfers but does not remove server single-string limits or improve result consumption; #1053 already distinguishes those failures. - **Use CLI `--filter-output`:** useful for output selection, but it happens after full analysis and does not provide the same MCP workflow by itself. - **Add more abort checks:** useful inside interruptible work, but cannot promptly process a cancellation notification while a long synchronous operation blocks the MCP event loop. - **Increase a server/provider timeout:** does not extend another client's timer. Progress-based timeout resets require client support/configuration. PR #974 concerns the provider startup deadline, while this validation reproduced a separate 60-second client deadline. ## Possible direction T1 was completed in #1088. Implementation priority: effective cancellation next; low-risk catalog caching and Windows waiting guidance can proceed independently. Response representation changes and upstream-client optimization follow their own compatibility decisions. - [x] **T1 — Reliable result delivery** (high priority; #1053/#1050): establish an honest transport-constraint outcome and a usable retained-Evidence/selected-view continuation. Preserve the full-result path and exact provenance. Measure analysis, admission, serialization, transfer, and client parsing independently. - [ ] **T2 — Responsive cancellation** (high priority): investigate bounded worker isolation and cooperative yielding for heavy phases. Keep the MCP control path responsive, avoid duplicate large graph copies where possible, and test cancellation/publication races and cleanup before extending the approach to other domains. - [ ] **T3 — Catalog projection/cache efficiency** (#723): cache the actual advertised schema representation at an appropriate SDK/adapter seam with correct invalidation. Evaluate schema-local reuse and input presentation through real client tasks before any representation change; keep the canonical inventory complete. - [ ] **T4 — Response repetition** (#723): quantify the two repetition layers (`result` versus `evidence.normalized_result`, then text versus structured output). Evaluate compatible representations with actual consumers. Removing one layer alone does not guarantee that a real ASAR response fits ordinary clients. - [ ] **T5 — Client output-validator compilation**: pursue per-tool lazy compilation and correct invalidation in the upstream SDK. For REA-controlled clients, evaluate the SDK's supported per-call `toolDefinition` option. Measure first call and refresh behavior while keeping validation active. Record external-client coverage separately from server improvements. - [ ] **T6 — Windows first-analysis lifecycle** (related: #1048, PR #974): first profile launch, import, auto-analysis, and bridge readiness. Improve supported client waiting/progress guidance, then evaluate lifecycle improvements using existing session/task mechanisms where appropriate. Verify reuse boundaries and exact target binding before introducing any persistence. ## References - #723 — discovery/result repetition and public compatibility decision. - #1050 — caller-selected large-result views. - #1053 — server serialization failure after complete ASAR analysis. - #1048 and PR #974 — adjacent Ghidra import/startup work; distinct from the client's request deadline. - #919 — previously fixed catalog/client compatibility constraints to preserve. - #746 and PR #1055 — completed large-ASAR algorithm/allocation work; the remaining transport/cancellation issues are separately verified here. - [Published 6.0.0 source revision](https://github.com/morluto/rea/commit/6fee42689ae6e95a0182e0d4d0f55644e73e72be). - [Result projection](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/src/server/toolResult.ts). - [JavaScript analysis](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/src/application/javascript/JavaScriptArtifactAnalysis.ts) and [reconstruction lifecycle](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/src/application/javascript/JavaScriptArtifactReconstruction.ts). - [Ghidra client startup lifecycle](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/src/ghidra/GhidraClient.ts).
bsakaguchi commented 2026-10-15 18:24:36 +00:00
Author
Owner
Copy link

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

Assigned this roadmap to myself to coordinate the work. T1 is implemented in #1088 and awaiting its final integrated CI run. Existing generated-input CI failures were independently fixed and merged through #1091; #1088 now includes that fix.

Real acceptance uses the complete Notion 7.6.1 and official Obsidian 1.12.7 ASARs, isolated installed packages, the SDK default receive buffer, Linux Node 24.18.0 and native Windows Node 22.19.0. Both retain the complete analysis, return an actionable 2,517-byte transport constraint, answer useful module traces, export all Evidence, preserve connection pings, and clean the session. Native Windows workflow peaks were 1.52 / 1.67 GiB under two CPUs and below-normal priority. Complete normalized results match across platforms apart from caller-selected input paths; Notion's full CLI bytes match the published 6.0.0 baseline exactly. Actual Chrome verification also covers a 9,331,405-byte PNG: full exported recovery under default budgets and byte-identical inline delivery with matched explicit larger budgets.

This completes the delivery/recovery portion, not the entire roadmap. Existing complete success contracts are preserved. Extended caller deadlines were used for the large-app acceptance, so the default waiting issue remains open.

T2 baseline on the full real Notion bundle confirms the late-cancellation bug: cancellation at Evidence creation rejects the client locally in 1.3 ms, but the server still completes and retains analysis, and a subsequent ping waits approximately 14 seconds. Work will address execution and publication boundaries rather than treating client-local rejection as successful server cancellation. Catalog/client compilation and representation work remain separate items.

<!-- gh-comment-id:6063174605 --> @N0zoM1z0 commented on GitHub (Oct 8, 2026): Assigned this roadmap to myself to coordinate the work. T1 is implemented in #1088 and awaiting its final integrated CI run. Existing generated-input CI failures were independently fixed and merged through #1091; #1088 now includes that fix. Real acceptance uses the complete Notion 7.6.1 and official Obsidian 1.12.7 ASARs, isolated installed packages, the SDK default receive buffer, Linux Node 24.18.0 and native Windows Node 22.19.0. Both retain the complete analysis, return an actionable 2,517-byte transport constraint, answer useful module traces, export all Evidence, preserve connection pings, and clean the session. Native Windows workflow peaks were 1.52 / 1.67 GiB under two CPUs and below-normal priority. Complete normalized results match across platforms apart from caller-selected input paths; Notion's full CLI bytes match the published 6.0.0 baseline exactly. Actual Chrome verification also covers a 9,331,405-byte PNG: full exported recovery under default budgets and byte-identical inline delivery with matched explicit larger budgets. This completes the delivery/recovery portion, not the entire roadmap. Existing complete success contracts are preserved. Extended caller deadlines were used for the large-app acceptance, so the default waiting issue remains open. T2 baseline on the full real Notion bundle confirms the late-cancellation bug: cancellation at Evidence creation rejects the client locally in 1.3 ms, but the server still completes and retains analysis, and a subsequent ping waits approximately 14 seconds. Work will address execution and publication boundaries rather than treating client-local rejection as successful server cancellation. Catalog/client compilation and representation work remain separate items.
bsakaguchi commented 2026-10-15 18:24:36 +00:00
Author
Owner
Copy link

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

The first T2 cancellation batch is merged in #1098 (cc0ee2ed), after all 23 checks passed. T2 remains open.

The application now cooperatively seals owned results, validates immutable JSON and hashes canonical Evidence, with cancellation checks before publication. CLI SIGINT/SIGTERM also reach the shared JavaScript application service. Complete result contracts, Evidence identities and CLI/MCP behavior are preserved.

Real full Notion and Obsidian tests independently observed server cancellation, no cancelled Evidence admission, a responsive connection and a usable subsequent request. Observed server-stop latency was approximately 7–12 ms for the tested sealing/hash phases. Native Windows full Obsidian export remained byte-identical to the previous verified export; the complete 429 MB export was independently checked and then deleted. A same-run Notion canonical-hash comparison preserved the exact digest with 10.4% hashing overhead; this batch improves cancellation correctness rather than claiming a throughput improvement.

Verification included 126 deterministic tests, static/generated-document checks, an isolated native Windows package installation and real full-artifact CLI/MCP workflows. No Muse Spark/opencode end-to-end claim is made.

Remaining T2 work includes single-file parsing, graph completion, full result validation and cancellation of full bundle export. The next investigation targets repeated graph validation and cloning; a shallow freeze or imported graph must never bypass external validation. Catalog and client-side validator work remain separate follow-up batches.

<!-- gh-comment-id:6065217819 --> @N0zoM1z0 commented on GitHub (Oct 8, 2026): The first T2 cancellation batch is merged in #1098 (`cc0ee2ed`), after all 23 checks passed. T2 remains open. The application now cooperatively seals owned results, validates immutable JSON and hashes canonical Evidence, with cancellation checks before publication. CLI SIGINT/SIGTERM also reach the shared JavaScript application service. Complete result contracts, Evidence identities and CLI/MCP behavior are preserved. Real full Notion and Obsidian tests independently observed server cancellation, no cancelled Evidence admission, a responsive connection and a usable subsequent request. Observed server-stop latency was approximately 7–12 ms for the tested sealing/hash phases. Native Windows full Obsidian export remained byte-identical to the previous verified export; the complete 429 MB export was independently checked and then deleted. A same-run Notion canonical-hash comparison preserved the exact digest with 10.4% hashing overhead; this batch improves cancellation correctness rather than claiming a throughput improvement. Verification included 126 deterministic tests, static/generated-document checks, an isolated native Windows package installation and real full-artifact CLI/MCP workflows. No Muse Spark/opencode end-to-end claim is made. Remaining T2 work includes single-file parsing, graph completion, full result validation and cancellation of full bundle export. The next investigation targets repeated graph validation and cloning; a shallow freeze or imported graph must never bypass external validation. Catalog and client-side validator work remain separate follow-up batches.
bsakaguchi commented 2026-10-15 18:24:36 +00:00
Author
Owner
Copy link

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

Merged #1112 as ec6db0f0630c4b0b35f0db84c0030784c1aa58a6 after all 24 checks passed, including native Windows, Linux x64/arm64, and macOS Intel/Apple Silicon package lanes.

This completes another part of T2: exact privately authenticated immutable graphs are reused at final result validation; sealing and cross-graph binding traversal remain cancellable. Mutable/imported graphs still receive complete validation. The public contracts and full Evidence remain intact.

  • Eight paired complete real Linux Notion/Obsidian analyses preserved exact IDs and independent normalized/full-Evidence digests. Final validation measured 10.6–14.9 seconds before and 16–28 ms after. Full analysis and RSS observations are in the PR; Obsidian memory was essentially unchanged.
  • Native Windows same-main Obsidian analysis/trace/export passed. The entire 429,265,076-byte bundle is byte-identical before/after. Actual full Notion cancellation during semantic-graph sealing stopped server work in 9.875 ms and preserved prior Evidence and subsequent requests.
  • After synchronizing main, both complete real applications passed again with the same commitments. 18 focused files passed (161 tests; four Linux-skipped Darwin-only tests), and native Apple CI passed.
  • The Apple workflow's stale reference to a moved process test was corrected; this was a deterministic missing-file failure, not a flake.

T2 remains open: source parsing and graph constructor validation still contain synchronous intervals; complete bundle export cancellation remains follow-up work. The catalog, client validator and default Windows first-analysis waiting tasks are also still open.

A stale unused compiled generated catalog is tracked separately in #1113. The actual live tools/list was verified current; the initial consumer assumption in that report was corrected. Output-only schema reference experiments are being investigated for T3, with complete inputs/inventory retained and actual-client/semantic acceptance still required.

Large exports, obsolete isolated installs and intermediate measurements were cleaned after compact verification proofs were retained. No target application was executed and no private host paths were published.

<!-- gh-comment-id:6066645657 --> @N0zoM1z0 commented on GitHub (Oct 8, 2026): Merged #1112 as `ec6db0f0630c4b0b35f0db84c0030784c1aa58a6` after all 24 checks passed, including native Windows, Linux x64/arm64, and macOS Intel/Apple Silicon package lanes. This completes another part of T2: exact privately authenticated immutable graphs are reused at final result validation; sealing and cross-graph binding traversal remain cancellable. Mutable/imported graphs still receive complete validation. The public contracts and full Evidence remain intact. - Eight paired complete real Linux Notion/Obsidian analyses preserved exact IDs and independent normalized/full-Evidence digests. Final validation measured 10.6–14.9 seconds before and 16–28 ms after. Full analysis and RSS observations are in the PR; Obsidian memory was essentially unchanged. - Native Windows same-main Obsidian analysis/trace/export passed. The entire 429,265,076-byte bundle is byte-identical before/after. Actual full Notion cancellation during semantic-graph sealing stopped server work in 9.875 ms and preserved prior Evidence and subsequent requests. - After synchronizing main, both complete real applications passed again with the same commitments. 18 focused files passed (161 tests; four Linux-skipped Darwin-only tests), and native Apple CI passed. - The Apple workflow's stale reference to a moved process test was corrected; this was a deterministic missing-file failure, not a flake. **T2 remains open:** source parsing and graph constructor validation still contain synchronous intervals; complete bundle export cancellation remains follow-up work. The catalog, client validator and default Windows first-analysis waiting tasks are also still open. A stale unused compiled generated catalog is tracked separately in #1113. The actual live `tools/list` was verified current; the initial consumer assumption in that report was corrected. Output-only schema reference experiments are being investigated for T3, with complete inputs/inventory retained and actual-client/semantic acceptance still required. Large exports, obsolete isolated installs and intermediate measurements were cleaned after compact verification proofs were retained. No target application was executed and no private host paths were published.
bsakaguchi commented 2026-10-15 18:24:36 +00:00
Author
Owner
Copy link

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

#1116 is merged as d1c904bac7977d44b06bf2f823587baedcc88b9e and all 22 exact-head checks have passed. This closes the corrected #1113 unused-generated-artifact report. The real production catalog was already current; this is a package/storage improvement, not a stale-client-schema fix.

Same-source package comparison, including identical native Windows controls, removed only the unused test module. Every remaining file is byte-identical. Compressed REA package size fell 19.37%, and unpacked REA contents fell 51.44%; these percentages exclude dependencies. Old-source single-build/cache restoration, 22 focused tests, static/docs checks, full Linux package verification and native Windows parity for all 138 actual input/output schemas passed.

Owned baseline worktrees, the stopped verifier workspace and the previous native Windows package were removed after compact proofs. The broader #1065 tasks remain open. Output-only reference experiments are next: all inputs remain byte-identical and real captured session results validate through the pinned SDK; controlled first-call samples measured 3.302/2.834 seconds before and 2.473/2.608 seconds with references. These are client validator benchmarks, not real-application or model-context acceptance. Input-facing token cost is unchanged, so that gap is still explicit.

<!-- gh-comment-id:6067160029 --> @N0zoM1z0 commented on GitHub (Oct 8, 2026): #1116 is merged as `d1c904bac7977d44b06bf2f823587baedcc88b9e` and all 22 exact-head checks have passed. This closes the corrected #1113 unused-generated-artifact report. The real production catalog was already current; this is a package/storage improvement, not a stale-client-schema fix. Same-source package comparison, including identical native Windows controls, removed only the unused test module. Every remaining file is byte-identical. Compressed REA package size fell 19.37%, and unpacked REA contents fell 51.44%; these percentages exclude dependencies. Old-source single-build/cache restoration, 22 focused tests, static/docs checks, full Linux package verification and native Windows parity for all 138 actual input/output schemas passed. Owned baseline worktrees, the stopped verifier workspace and the previous native Windows package were removed after compact proofs. The broader #1065 tasks remain open. Output-only reference experiments are next: all inputs remain byte-identical and real captured session results validate through the pinned SDK; controlled first-call samples measured 3.302/2.834 seconds before and 2.473/2.608 seconds with references. These are client validator benchmarks, not real-application or model-context acceptance. Input-facing token cost is unchanged, so that gap is still explicit.
bsakaguchi commented 2026-10-15 18:24:36 +00:00
Author
Owner
Copy link

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

Merged #1143 after all 22 exact-head CI checks passed. This completes another part of T3 while retaining all 138 named contracts and complete input/output semantics.

Two sequential paired measurements on the same source baseline reduced the complete catalog from 1,996,829 to 1,746,799 bytes (-12.5%). Controlled first successful client calls improved from 3.635/3.251 s to 2.160/2.128 s; maximum process RSS fell from 557/581 MB to 468/467 MB. The input-facing projection remains 549,243 bytes and 133,214 fixed-tokenizer proxy tokens; this change does not reduce that context.

The final isolated native Windows package completed full Notion and Obsidian analysis with identical Evidence identifiers and complete selected traces. Direct feature queries, client schema validation, ping and cleanup passed under two-CPU/resource guards. Local checks passed 30 focused tests, six static tasks, docs checks and the complete installed-package CLI/MCP verifier. Complete inline results still use the existing typed transport-budget recovery.

The umbrella remains open and assigned. T2 still needs synchronous source parsing/constructor and export cancellation work; T3 still includes input-facing context/selection; T5 and the external-client waiting portion of T6 remain open. T4 is deferred pending its separate compatibility decision.

<!-- gh-comment-id:6071957348 --> @N0zoM1z0 commented on GitHub (Oct 9, 2026): Merged #1143 after all 22 exact-head CI checks passed. This completes another part of T3 while retaining all 138 named contracts and complete input/output semantics. Two sequential paired measurements on the same source baseline reduced the complete catalog from 1,996,829 to 1,746,799 bytes (-12.5%). Controlled first successful client calls improved from 3.635/3.251 s to 2.160/2.128 s; maximum process RSS fell from 557/581 MB to 468/467 MB. The input-facing projection remains 549,243 bytes and 133,214 fixed-tokenizer proxy tokens; this change does not reduce that context. The final isolated native Windows package completed full Notion and Obsidian analysis with identical Evidence identifiers and complete selected traces. Direct feature queries, client schema validation, ping and cleanup passed under two-CPU/resource guards. Local checks passed 30 focused tests, six static tasks, docs checks and the complete installed-package CLI/MCP verifier. Complete inline results still use the existing typed transport-budget recovery. The umbrella remains open and assigned. T2 still needs synchronous source parsing/constructor and export cancellation work; T3 still includes input-facing context/selection; T5 and the external-client waiting portion of T6 remain open. T4 is deferred pending its separate compatibility decision.
bsakaguchi commented 2026-10-15 18:24:36 +00:00
Author
Owner
Copy link

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

Merged #1149 after all 22 exact-head CI checks passed. This completes the full-bundle export cancellation portion of T2.

Native Windows full Notion and Obsidian runs observed actual staged bytes before cancelling. Before the change, cancellation rejected locally but serialization continued for 33.854 / 40.374 seconds and published 336,236,424 / 429,232,879 bytes. After the change, staged content disappeared in 28.694 / 39.140 ms and complete staging directories disappeared in 28.947 / 69.317 ms (20 ms polling granularity). The cancelled request did not publish a file; an existing destination retained its original bytes.

The next full export succeeded in the same session, with every byte matching the corresponding baseline SHA-256. Evidence IDs and complete selected trace digests also matched; ping, query, close and owned-output cleanup passed. The comparator uses the same pre-trace ledger checkpoint because queries can retain additional Evidence. Native process-family peaks were 1,399,402,496 / 1,633,468,416 bytes under two-CPU/heap guards, with no resource stop. Large exports and obsolete test installations were cleaned after compact proofs were retained.

Local verification passed 16 focused tests, all six static tasks, docs checks, and the complete installed-package CLI/MCP verifier. No real Hopper/Ghidra/browser claim is made for this export-only change.

The umbrella remains open and assigned. Synchronous source parsing and graph constructors still need cancellation work. A naive independent per-file semantic worker would change the current global node-budget allocation/order and cross-file bindings; realm-local immutable proofs also do not survive object transfer automatically. Worker payload, ownership, cleanup and full real-app memory/parity measurements are required before choosing that migration.

An input-schema reuse probe reduced projection-only bytes from 478,286 to 430,339, but left non-object roots for project_managed_application_graph, inspect_web_page and inspect_electron_page. Default advertised inputs remain unchanged until root normalization, referenced guidance and actual client/call compatibility are established. T3 is therefore partial; T5 and external-client waiting in T6 remain open. T4 remains deferred to its separate compatibility decision.

<!-- gh-comment-id:6072429865 --> @N0zoM1z0 commented on GitHub (Oct 9, 2026): Merged #1149 after all 22 exact-head CI checks passed. This completes the full-bundle export cancellation portion of T2. Native Windows full Notion and Obsidian runs observed actual staged bytes before cancelling. Before the change, cancellation rejected locally but serialization continued for 33.854 / 40.374 seconds and published 336,236,424 / 429,232,879 bytes. After the change, staged content disappeared in 28.694 / 39.140 ms and complete staging directories disappeared in 28.947 / 69.317 ms (20 ms polling granularity). The cancelled request did not publish a file; an existing destination retained its original bytes. The next full export succeeded in the same session, with every byte matching the corresponding baseline SHA-256. Evidence IDs and complete selected trace digests also matched; ping, query, close and owned-output cleanup passed. The comparator uses the same pre-trace ledger checkpoint because queries can retain additional Evidence. Native process-family peaks were 1,399,402,496 / 1,633,468,416 bytes under two-CPU/heap guards, with no resource stop. Large exports and obsolete test installations were cleaned after compact proofs were retained. Local verification passed 16 focused tests, all six static tasks, docs checks, and the complete installed-package CLI/MCP verifier. No real Hopper/Ghidra/browser claim is made for this export-only change. The umbrella remains open and assigned. Synchronous source parsing and graph constructors still need cancellation work. A naive independent per-file semantic worker would change the current global node-budget allocation/order and cross-file bindings; realm-local immutable proofs also do not survive object transfer automatically. Worker payload, ownership, cleanup and full real-app memory/parity measurements are required before choosing that migration. An input-schema reuse probe reduced projection-only bytes from 478,286 to 430,339, but left non-object roots for `project_managed_application_graph`, `inspect_web_page` and `inspect_electron_page`. Default advertised inputs remain unchanged until root normalization, referenced guidance and actual client/call compatibility are established. T3 is therefore partial; T5 and external-client waiting in T6 remain open. T4 remains deferred to its separate compatibility decision.
bsakaguchi commented 2026-10-15 18:24:37 +00:00
Author
Owner
Copy link

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

T3 input-schema follow-up is in draft PR #1162 and assigned work remains with N0zoM1z0. Executed SDK comparison preserves all 138 tools, all expanded input meaning/guidance, all output schemas and remaining metadata. Input-facing discovery bytes improve 6.54%; cl100k_base proxy tokens improve 3.43%, without a claim about every model host. Forty focused tests, static gates and generated-document checks pass. Native Windows complete Notion now has byte-identical full Evidence export and identical retained tracing; complete Obsidian and final packaged acceptance are in progress. Root-union inputs retain their established inline object presentation. No default result-view or transport-contract change is included. T2 parser/constructor cancellation, T5 client eager output compilation and T6 external waiting remain separate; this does not complete #1065 or #723.

<!-- gh-comment-id:6072971923 --> @N0zoM1z0 commented on GitHub (Oct 9, 2026): T3 input-schema follow-up is in draft PR #1162 and assigned work remains with N0zoM1z0. Executed SDK comparison preserves all 138 tools, all expanded input meaning/guidance, all output schemas and remaining metadata. Input-facing discovery bytes improve 6.54%; cl100k_base proxy tokens improve 3.43%, without a claim about every model host. Forty focused tests, static gates and generated-document checks pass. Native Windows complete Notion now has byte-identical full Evidence export and identical retained tracing; complete Obsidian and final packaged acceptance are in progress. Root-union inputs retain their established inline object presentation. No default result-view or transport-contract change is included. T2 parser/constructor cancellation, T5 client eager output compilation and T6 external waiting remain separate; this does not complete #1065 or #723.
bsakaguchi commented 2026-10-15 18:24:37 +00:00
Author
Owner
Copy link

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

The Ghidra caching part is addressed by #1211: explicit, profile-bound reads now reuse snapshots despite private project writes. Real Windows MCP verification covered repeat queries, atomic save/close, and replay in a fresh MCP process; target bytes and cleanup checks passed. This does not remove cold engine startup cost.

A fresh profile of the complete Notion 7.6.1 ASAR still shows a 12.5 s event-loop stall during semantic graph construction. Whole-graph commitments and relationship validation dominate that stage. The analysis returned observations with 100,000 retained semantic nodes, 76,229 relations, and explicit coverage limits. Two CPUs, 1.5 GiB Node heap, sampled process-family peak 1.25 GiB.

Next: make the owned graph's commitment and relationship checks cooperative, retaining input schema cloning, canonical IDs, and all integrity checks. Large single-file parsing remains a separate step. Catalog/client context behavior and the compatibility-preserving default result remain open parts of this issue.

<!-- gh-comment-id:6075932882 --> @N0zoM1z0 commented on GitHub (Oct 9, 2026): The Ghidra caching part is addressed by #1211: explicit, profile-bound reads now reuse snapshots despite private project writes. Real Windows MCP verification covered repeat queries, atomic save/close, and replay in a fresh MCP process; target bytes and cleanup checks passed. This does not remove cold engine startup cost. A fresh profile of the complete Notion 7.6.1 ASAR still shows a **12.5 s event-loop stall** during semantic graph construction. Whole-graph commitments and relationship validation dominate that stage. The analysis returned observations with 100,000 retained semantic nodes, 76,229 relations, and explicit coverage limits. Two CPUs, 1.5 GiB Node heap, sampled process-family peak 1.25 GiB. Next: make the owned graph's commitment and relationship checks cooperative, retaining input schema cloning, canonical IDs, and all integrity checks. Large single-file parsing remains a separate step. Catalog/client context behavior and the compatibility-preserving default result remain open parts of this issue.
bsakaguchi commented 2026-10-15 18:24:37 +00:00
Author
Owner
Copy link

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

#1218 is merged with all 22 CI jobs green. Semantic graph commitment and integrity checks now yield through the cancellation driver while preserving input capture, all validation rules and canonical IDs.

The complete real Notion ASAR returns the same Evidence ID and retained observations. Its uninterrupted semantic factory interval drops from 12.50 s to 4.93 s. Actual stdio MCP cancellation during commitment stops the server in 4.7 ms, preserves prior Evidence and leaves the connection usable.

This remains a staged fix: one profiled pair took 62.89 s before and 66.14 s after, and whole-analysis maximum event-loop delay is still about 12 s. Source parsing, eager cloning/sorting, SDK-wide first-call schema compilation and the default full-result/context costs remain open.

<!-- gh-comment-id:6076317956 --> @N0zoM1z0 commented on GitHub (Oct 9, 2026): #1218 is merged with all 22 CI jobs green. Semantic graph commitment and integrity checks now yield through the cancellation driver while preserving input capture, all validation rules and canonical IDs. The complete real Notion ASAR returns the same Evidence ID and retained observations. Its uninterrupted semantic factory interval drops from 12.50 s to 4.93 s. Actual stdio MCP cancellation during commitment stops the server in 4.7 ms, preserves prior Evidence and leaves the connection usable. This remains a staged fix: one profiled pair took 62.89 s before and 66.14 s after, and whole-analysis maximum event-loop delay is still about 12 s. Source parsing, eager cloning/sorting, SDK-wide first-call schema compilation and the default full-result/context costs remain open.
bsakaguchi commented 2026-10-15 18:24:37 +00:00
Author
Owner
Copy link

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

Rechecked the DX-Ball working log against npm latest 6.1.0 and main f4c99ab8a53806dd57dc24b3d5a600905bcb4686 on 2026-10-09. Real stdio MCP, finite process/CLI fixtures, real Linux Ghidra 12.1.4 and cross-session snapshot replay were exercised serially under bounded CPU/heap/family RSS. This audit does not rerun the full game or establish other host/provider coverage.

Confirmed correctness defects:

  • #1241 (P1): default port normalization rewrites ordinary JSON numbers and does not retain the original terminal payload.
  • #1242 (P2): a decoded RET is reduced to generic terminal flow with a misleading blanket limitation.

Remaining usability/performance work relevant to this roadmap:

  • #1243: distinguish requested interior addresses from resolved batch procedure identity.
  • #1245 and #1247: compact typed references, native selected facets and discovery of reusable retained dossiers. The existing selected-view workflow currently covers JS/ELF parents.
  • #1248 and #1249: truthful snapshot counts and measured reduction of eager load/clone/serialization cost; lossless shared/compressed storage is a possible measured direction.
  • #1250 and #1251: per-dimension capture truncation and actionable complete-file digest status/budgets.
  • #1252 and #1253: bounded live capture progress and optional child finalization on timeout.
  • #1255: prominently document supported Ghidra heap/CPU controls and actual limits.

Additional native/artifact capability requests are tracked separately: #1244 (instruction/prototype conflict diagnostics), #1246 (data-region access/alias view), #1254 (PE resource inventory). They do not redefine completion of this roadmap.

Cleared historical reports: uppercase/padded addresses now succeed; malformed addresses identify the field and accepted format. Oversized native MCP results return a typed transport resource constraint with retained Evidence/export recovery; a following ping succeeds. Main snapshot-backed primitive and dossier reads preserve facts without launching Ghidra (approximately 53/119 ms in this run); explicit cache provenance intentionally changes Evidence identity. Zero primitive cache entries did not mean missing Evidence. Child nonzero exit remains correctly separate from recorder success. Allocation-wrapper signature spelling also differs from the old log, so the old literal void report was not filed as a current defect.

Cold new-query cost remains owned by #1048: approximately 29.3 s on this main run versus millisecond warm reads. The historical large-snapshot ~1 GiB Node sample was not re-established on current main; #1249 explicitly separates current source evidence and small-run measurements from that old observation. Heap control already works; custom injected JVM flags are intentionally cleared.

The log's timeout-argument mistake, mutable aliases, numeric-only address parser, EOF launch, Wine/observer/compiler failures and repetitive catalog copies were project/client behavior. Existing function annotation already works in the ephemeral database; persistent source-ledger integration and external SDK/runtime lineage remain future workflow suggestions, not newly proven analysis defects. Newly reported #1231/#1232/#1233 were checked for overlap and left with their existing owners.

All new issues include verification scope, source pointers, recovery or acceptance criteria, priority/area labels and triage. No repository code changed; #740 remains deferred.

<!-- gh-comment-id:6078170487 --> @N0zoM1z0 commented on GitHub (Oct 9, 2026): Rechecked the DX-Ball working log against npm latest 6.1.0 and main `f4c99ab8a53806dd57dc24b3d5a600905bcb4686` on 2026-10-09. Real stdio MCP, finite process/CLI fixtures, real Linux Ghidra 12.1.4 and cross-session snapshot replay were exercised serially under bounded CPU/heap/family RSS. This audit does not rerun the full game or establish other host/provider coverage. Confirmed correctness defects: - #1241 (P1): default port normalization rewrites ordinary JSON numbers and does not retain the original terminal payload. - #1242 (P2): a decoded RET is reduced to generic terminal flow with a misleading blanket limitation. Remaining usability/performance work relevant to this roadmap: - #1243: distinguish requested interior addresses from resolved batch procedure identity. - #1245 and #1247: compact typed references, native selected facets and discovery of reusable retained dossiers. The existing selected-view workflow currently covers JS/ELF parents. - #1248 and #1249: truthful snapshot counts and measured reduction of eager load/clone/serialization cost; lossless shared/compressed storage is a possible measured direction. - #1250 and #1251: per-dimension capture truncation and actionable complete-file digest status/budgets. - #1252 and #1253: bounded live capture progress and optional child finalization on timeout. - #1255: prominently document supported Ghidra heap/CPU controls and actual limits. Additional native/artifact capability requests are tracked separately: #1244 (instruction/prototype conflict diagnostics), #1246 (data-region access/alias view), #1254 (PE resource inventory). They do not redefine completion of this roadmap. Cleared historical reports: uppercase/padded addresses now succeed; malformed addresses identify the field and accepted format. Oversized native MCP results return a typed transport resource constraint with retained Evidence/export recovery; a following ping succeeds. Main snapshot-backed primitive and dossier reads preserve facts without launching Ghidra (approximately 53/119 ms in this run); explicit cache provenance intentionally changes Evidence identity. Zero primitive cache entries did not mean missing Evidence. Child nonzero exit remains correctly separate from recorder success. Allocation-wrapper signature spelling also differs from the old log, so the old literal void report was not filed as a current defect. Cold new-query cost remains owned by #1048: approximately 29.3 s on this main run versus millisecond warm reads. The historical large-snapshot ~1 GiB Node sample was not re-established on current main; #1249 explicitly separates current source evidence and small-run measurements from that old observation. Heap control already works; custom injected JVM flags are intentionally cleared. The log's timeout-argument mistake, mutable aliases, numeric-only address parser, EOF launch, Wine/observer/compiler failures and repetitive catalog copies were project/client behavior. Existing function annotation already works in the ephemeral database; persistent source-ledger integration and external SDK/runtime lineage remain future workflow suggestions, not newly proven analysis defects. Newly reported #1231/#1232/#1233 were checked for overlap and left with their existing owners. All new issues include verification scope, source pointers, recovery or acceptance criteria, priority/area labels and triage. No repository code changed; #740 remains deferred.
bsakaguchi commented 2026-10-15 18:24:37 +00:00
Author
Owner
Copy link

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

The requested follow-up batch now focuses on existing correctness, performance and usability, without adding analysis capabilities. Current main is aa5750c2.

Planned fixes: #1241 (normalization/source fidelity), #1242 (decoded return facts), #1243 (existing batch result identity), #1248 (snapshot receipt counts), #1249 (measured snapshot materialization cost), #1250 (existing capture completeness explanations), the diagnostic/documentation part of #1251, and #1255 (supported resource guidance).

New native/artifact views, field/ABI analysis, runtime streams and configurable finalization remain tracked for later. Existing result fields, canonical discovery and complete Evidence stay available. Each coherent change gets focused tests, actual affected CLI/MCP/provider verification, resource receipts and CI before merge. #740 remains deferred.

The #1241 branch already preserves ordinary JSON numbers and source PTY text when normalization changes a chunk; comparison uses the normalized projection and the comparison contract records the normalization version. Verification is in progress, so this is not a completion claim.

<!-- gh-comment-id:6078508578 --> @N0zoM1z0 commented on GitHub (Oct 9, 2026): The requested follow-up batch now focuses on existing correctness, performance and usability, without adding analysis capabilities. Current main is `aa5750c2`. Planned fixes: #1241 (normalization/source fidelity), #1242 (decoded return facts), #1243 (existing batch result identity), #1248 (snapshot receipt counts), #1249 (measured snapshot materialization cost), #1250 (existing capture completeness explanations), the diagnostic/documentation part of #1251, and #1255 (supported resource guidance). New native/artifact views, field/ABI analysis, runtime streams and configurable finalization remain tracked for later. Existing result fields, canonical discovery and complete Evidence stay available. Each coherent change gets focused tests, actual affected CLI/MCP/provider verification, resource receipts and CI before merge. #740 remains deferred. The #1241 branch already preserves ordinary JSON numbers and source PTY text when normalization changes a chunk; comparison uses the normalized projection and the comparison contract records the normalization version. Verification is in progress, so this is not a completion claim.
bsakaguchi commented 2026-10-15 18:24:37 +00:00
Author
Owner
Copy link

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

Rechecked current main 6ce3288f with the identity-validation change in #1366. PR #1366 is merged as 53ed942a after all 20 final-head validation jobs passed, including the actual real JavaScript recovery lane. Issue #1364 is closed, and the local main checkout is synchronized. This updates the older 6.0.0 measurements without attributing timing changes to this patch.

A real Notion ASAR was analyzed as inert text using the compiled CLI/MCP runtime, Node 24.18.0, two CPUs, a 1536 MiB Node heap and a 2304 MiB process-family guard. The same default SDK connection completed: analysis → actionable transport constraint/retained Evidence → summary/module views → structured invalid-input rejection → valid feature trace → close → expired-reference rejection → subsequent ping. Artifact SHA-256 stayed unchanged. Parent Evidence coverage and unknowns remain explicit, including the existing semantic node ceiling. This is a recovery workflow pass, not a claim that the complete result fits the default transport.

Observed surface Current measurement
Complete discovery 139 tools; 1,866,644 serialized UTF-8 bytes; cold/warm lists 260/98/55 ms
Default first/warm binary_session 2,678/25.5 ms; 139/0 validator preparations; response 406,854 bytes
Calls after list refresh 2,315/2,178 ms; 139 validator preparations each, taking 2,279/2,110 ms
Application analysis call 63.646 s; typed transport constraint 1,495 bytes with usable retained reference
Selected summary/module page 75.6/15.4 ms; 23,486/20,742 response bytes
Feature trace after rejected comparison 79.3 ms; 180,502 response bytes; successful output validation
Longest concurrent ping 12.037 s
Entire workflow / sampled family peak 73.746 s / 1.91 GiB

Validator counts instrument SDK getValidator calls, not AJV code-generation internals; a cached selected schema can still receive a cheap getValidator call. The supported per-call toolDefinition path kept output validation active and prepared only the selected output schema. This does not fix external clients that use the SDK's default catalog-wide path. Serialized bytes are not measured model-host context or billing. This run did not exercise cancellation or the Windows default deadline.

Current remaining priorities:

  • T2: large-file synchronous work still delays the control path. Measure actual cancellation delivery, stop/publication races and owned cleanup before choosing worker/cooperative-yield changes.
  • T3/T5: preserve the complete named catalog and correct invalidation while addressing refresh-wide client validator compilation. Actual host tool selection/context remains unverified.
  • T4 / #723: response repetition and structured/text compatibility remain a separate decision; no complete Evidence or default output fields were removed.
  • T6: bounded Windows first-analysis waiting/progress and the client's default deadline still need their dedicated acceptance lane.
  • #1247 / PR #1345: native dossier selected views are an available follow-up for review. Its contributor has not claimed real Ghidra/Hopper verification; full dossier discovery/reuse is still outside that PR's partial scope.

Previously reported #1241, #1242, #1243, #1248, #1249, #1250, #1255 and Windows/JADX #1262 are closed. #1251 remains open because only its digest diagnostics/documentation portion is complete; independent hashing budgets are still follow-up. Native reference views, capture progress/finalization and additional artifact capabilities remain with their existing issues.

This batch also merged schema portability #1302, regular-file admission #1273, Hopper restart #1275, extraction completeness #1319, attached-browser environment preservation #1321, wrong-host Ghidra admission #1280, streamed CLI JSON #1360 and package-pinned skill commands #1346 after final-head checks. #1366 fixes the additional CLI/MCP identity-validation mismatch found during this audit. #1065 remains open; #740 remains deferred.

<!-- gh-comment-id:6089191395 --> @N0zoM1z0 commented on GitHub (Oct 9, 2026): Rechecked current main `6ce3288f` with the identity-validation change in #1366. PR #1366 is merged as `53ed942a` after all 20 final-head validation jobs passed, including the actual real JavaScript recovery lane. Issue #1364 is closed, and the local main checkout is synchronized. This updates the older 6.0.0 measurements without attributing timing changes to this patch. A real Notion ASAR was analyzed as inert text using the compiled CLI/MCP runtime, Node 24.18.0, two CPUs, a 1536 MiB Node heap and a 2304 MiB process-family guard. The same default SDK connection completed: analysis → actionable transport constraint/retained Evidence → summary/module views → structured invalid-input rejection → valid feature trace → close → expired-reference rejection → subsequent ping. Artifact SHA-256 stayed unchanged. Parent Evidence coverage and unknowns remain explicit, including the existing semantic node ceiling. This is a recovery workflow pass, not a claim that the complete result fits the default transport. | Observed surface | Current measurement | | --- | --- | | Complete discovery | 139 tools; 1,866,644 serialized UTF-8 bytes; cold/warm lists 260/98/55 ms | | Default first/warm `binary_session` | 2,678/25.5 ms; 139/0 validator preparations; response 406,854 bytes | | Calls after list refresh | 2,315/2,178 ms; 139 validator preparations each, taking 2,279/2,110 ms | | Application analysis call | 63.646 s; typed transport constraint 1,495 bytes with usable retained reference | | Selected summary/module page | 75.6/15.4 ms; 23,486/20,742 response bytes | | Feature trace after rejected comparison | 79.3 ms; 180,502 response bytes; successful output validation | | Longest concurrent ping | 12.037 s | | Entire workflow / sampled family peak | 73.746 s / 1.91 GiB | Validator counts instrument SDK `getValidator` calls, not AJV code-generation internals; a cached selected schema can still receive a cheap `getValidator` call. The supported per-call `toolDefinition` path kept output validation active and prepared only the selected output schema. This does not fix external clients that use the SDK's default catalog-wide path. Serialized bytes are not measured model-host context or billing. This run did not exercise cancellation or the Windows default deadline. Current remaining priorities: - **T2:** large-file synchronous work still delays the control path. Measure actual cancellation delivery, stop/publication races and owned cleanup before choosing worker/cooperative-yield changes. - **T3/T5:** preserve the complete named catalog and correct invalidation while addressing refresh-wide client validator compilation. Actual host tool selection/context remains unverified. - **T4 / #723:** response repetition and structured/text compatibility remain a separate decision; no complete Evidence or default output fields were removed. - **T6:** bounded Windows first-analysis waiting/progress and the client's default deadline still need their dedicated acceptance lane. - **#1247 / PR #1345:** native dossier selected views are an available follow-up for review. Its contributor has not claimed real Ghidra/Hopper verification; full dossier discovery/reuse is still outside that PR's partial scope. Previously reported #1241, #1242, #1243, #1248, #1249, #1250, #1255 and Windows/JADX #1262 are closed. #1251 remains open because only its digest diagnostics/documentation portion is complete; independent hashing budgets are still follow-up. Native reference views, capture progress/finalization and additional artifact capabilities remain with their existing issues. This batch also merged schema portability #1302, regular-file admission #1273, Hopper restart #1275, extraction completeness #1319, attached-browser environment preservation #1321, wrong-host Ghidra admission #1280, streamed CLI JSON #1360 and package-pinned skill commands #1346 after final-head checks. #1366 fixes the additional CLI/MCP identity-validation mismatch found during this audit. #1065 remains open; #740 remains deferred.
bsakaguchi commented 2026-10-15 18:24:38 +00:00
Author
Owner
Copy link

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

Follow-up review of #1402, now merged as 499e2f54: omitted provider raw results no longer synthesize a second copy of the normalized result. Explicit raw reports, complete normalized results, and text/structured delivery remain preserved; affected Evidence IDs change.

Verified 57 focused CLI, MCP, cleanup, and snapshot tests plus lint/module boundaries on the exact PR head. Full local typechecking was stopped by the 2 GiB process-family RSS guard, including serial attempts; CI static checks, all test shards, and real Apple CLI/MCP verification passed. The Intel macOS package job was still running at this update, so the complete CI run is not yet reported green.

A separate source-owned 80-function fixture through the compiled public stdio MCP surface measured 10,248,992 bytes for complete analysis versus 20,372 bytes for a retained summary, with matching text/structured content, parent linkage, and a successful subsequent ping. The complete 139-tool catalog measured 1,870,560 serialized bytes. These are response-byte measurements, not actual model token-use measurements. Catalog cost and text/structured repetition remain open under #723; this is partial progress, not closure of #1065.

<!-- gh-comment-id:6093090888 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Follow-up review of #1402, now merged as `499e2f54`: omitted provider raw results no longer synthesize a second copy of the normalized result. Explicit raw reports, complete normalized results, and text/structured delivery remain preserved; affected Evidence IDs change. Verified 57 focused CLI, MCP, cleanup, and snapshot tests plus lint/module boundaries on the exact PR head. Full local typechecking was stopped by the 2 GiB process-family RSS guard, including serial attempts; CI static checks, all test shards, and real Apple CLI/MCP verification passed. The Intel macOS package job was still running at this update, so the complete CI run is not yet reported green. A separate source-owned 80-function fixture through the compiled public stdio MCP surface measured 10,248,992 bytes for complete analysis versus 20,372 bytes for a retained summary, with matching text/structured content, parent linkage, and a successful subsequent ping. The complete 139-tool catalog measured 1,870,560 serialized bytes. These are response-byte measurements, not actual model token-use measurements. Catalog cost and text/structured repetition remain open under #723; this is partial progress, not closure of #1065.
bsakaguchi commented 2026-10-15 18:24:38 +00:00
Author
Owner
Copy link

@CassieFox23 commented on GitHub (Oct 10, 2026):

TL;DR: I ran the T2 cancel test on Linux. The cancel reaches the server fast. The server only reads it when a long block of work ends. Then it stops and sends no reply. One late cancel did race a finished reply out.

I ran repro step 5 on main 8550913c and the 6.3.0 release. Fixture: the issue's generator at 300 and 1,200 functions. Each run is one analyze_javascript_application call per session, done three times.

Cancel timing on main, median of 3 runs:

Case Cancel sent Server stop Reply sent Next call
300, 200 ms after progress 206 ms 795 ms No (3/3) OK, 19 ms
1,200, 200 ms after progress 210 ms 2,842 ms No (3/3) OK, 25 ms
1,200, at 4,010 ms 4,011 ms 4,016 ms No (3/3) OK, 19 ms
  • The cancel waits for the first stage to end. At 1,200 functions, that block lasts 2.5 to 3 s. Pings wait too, up to 2.8 s. None failed.
  • When the block ends, the server stops in a few ms. A cancel sent after the block stops it within 31 ms. The analysis does not finish.
  • No child processes or temp files were left. No Evidence was kept for a cancelled call.
  • One race run did send a reply. The server had finished 46 ms before the cancel. The reply went out 11 ms after it. The client dropped it, and the next call worked.
  • The 6.3.0 release acts the same. The block is graph building, not parsing.

Not run

Edit: I ran the current release, 6.5.0, instead of 6.0.0. The results are in this comment. Step 4 is still not run.

  • Step 4, the CLI compare.
  • The 6.0.0 package. I ran 6.5.0 instead.
  • A real app, or many files at once.
  • Windows or macOS.
  • A heap snapshot. At 1,200 functions, server memory stays near 500 MiB after a cancel, up from 385 MiB. I don't know if that is held data.
  • An idle machine. Other test suites shared mine (load 6 to 13 on 24 threads). Treat the times as a bit noisy. Rerun on main 69fe5b601, see below.

Edit: The idle-machine rerun on main 69fe5b601 is in my new comment. The long block is gone there.

Thanks, N0zoM1z0, for the clear repro steps. I can share the harness if it helps.

Full tables (median [min–max] of 3 runs)

Times are ms from the tool call. "Server stop" is the server's own tool-done log line.

No cancel, main:

Size Analysis Reply Worst ping Peak RSS Next call
300 1,422 [1,214–1,518] typed resource_constraint, 1,529 B 478 [423–553] 744 MiB 25 ms
1,200 4,458 [4,444–4,836] typed resource_constraint, 1,529 B 2,317 [2,211–2,680] 846 MiB 23 ms

Cancel, main:

Case Cancel sent Server stop Stop minus cancel Reply sent Worst ping after cancel
300, 200 ms after progress 206 795 [726–870] 589 [520–664] 0/3 544 [475–617]
300, at 710 710 713 [712–741] 3 [2–31] 0/3 1 [1–2]
300, at 1,280 1,281 1,291 [1,285–1,293] 10 [5–12] 0/3 1 [1–2]
300, at 1,390 1,391 1,345 [1,232–1,395] see below 1/3 2 [2–2]
1,200, 200 ms after progress 210 2,842 [2,561–3,017] 2,632 [2,352–2,812] 0/3 2,589 [2,309–2,762]
1,200, at 2,230 2,231 2,560 [2,540–2,733] 328 [309–503] 0/3 306 [287–479]
1,200, at 4,010 4,011 4,016 [4,014–4,022] 5 [3–10] 0/3 3 [2–8]
1,200, at 4,370 4,371 4,381 [4,374–4,381] 10 [4–10] 0/3 2 [1–3]

The 1,390 runs split three ways. One stopped with no reply. One finished before its cancel timer fired. One finished first and its reply crossed the cancel.

Cancel, 6.3.0 release:

Case Cancel sent Server stop Reply sent Next call
300, 200 ms after progress 207 663 [653–736] 0/3 OK, 19 ms
1,200, 200 ms after progress 205 2,400 [2,371–2,448] 0/3 OK, 32 ms

Every run: no ping failed, no child process, no temp file left. The server quit 43 to 90 ms after close. Family peak never passed 981 MiB.

Timeline, 1,200 functions, cancel 200 ms after progress

This run used a small preload to log when the server SDK aborts the request. It does not change REA code. It also slows the run a bit.

ms Where Event
0 client tool call starts
5 server event loop blocks (3,132 ms)
7 server progress: start of analysis
207 client sends notifications/cancelled, rejects locally
3,137 server event loop free
3,142 server SDK aborts the request
3,144 server 12 queued pings answered (worst 2,894 ms)
3,147 server tool done, status error, no reply sent
5,769 client next binary_session OK (41 ms)
Where the event loop blocks (CPU profile, 1,200 functions)
Stage Wall ms Blocks? Main cost
Inventory and parsing 2,809 Yes, one block Semantic graph projection per file. Top self time: canonicalize 17%, emitCanonical 16%, zod 14%, GC 9%, hashing 7%. Babel parse is about 2%.
Build application graph 307 Yes, 0.3 s createImmutableJavaScriptSemanticGraphSteps: zod and ID checks.
Seal semantic graph 1,086 No Digest and freeze steps yield.
Validate result 288 No JSON value checks.
Hash Evidence 380 No Digest steps yield.
Encode reply about 70 Short Sizing the result for the stdio budget.

Most of the first block is building the semantic graph for the file. Digests and schema checks take most of that time.

How I measured
  • One MCP session per run, SDK 2.3.1 stdio client, default receive buffer.
  • Server started as node scripts/rea.mjs mcp, like the repo's MCP tests.
  • List tools, then one binary_session call to warm up the client checks.
  • Ping every 250 ms during the call.
  • A tap on both pipes logs the cancel note and any reply for the cancelled id.
  • The server's own log line gives its stop time and status.
  • After the call, wait for the server to go idle. Then check child processes and temp files, and make the next call.
  • A small preload, in labelled runs only, logs SDK aborts and event loop stalls.
  • A side process samples family RSS every 100 ms with a 2,304 MiB kill cap. It never fired.
Commands 
git -C rea.git archive 8550913cda311e5340cf012b9c4afd622e36e35b | tar -x -C src-main
cd src-main && npm ci && npm run build:cached
# client.mjs is the harness script, available on request
( ulimit -c 0; timeout 1200 taskset -c 2,3 node client.mjs --root src-main \
  --fixture f1200/fixture --mode after-progress --cancel-ms 200 \
  --server-node-args --max-old-space-size=1536 --out result.json )
node --cpu-prof --cpu-prof-interval=1000 --max-old-space-size=1536 scripts/rea.mjs mcp
Test setup
  • Box: Nobara Linux 44 (Fedora 44 base), Linux 7.2.9
  • CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads (runs pinned to 2)
  • RAM: 32 GB DDR4-3600
  • Node: 24.18.0
  • Head / base: 8550913c / 6.3.0 release
  • Other: MCP SDK client and server 2.3.1, 1,536 MiB server heap

🤖 Generated with Claude Code (Opus 5.5) 🦊

<!-- gh-comment-id:6093389881 --> @CassieFox23 commented on GitHub (Oct 10, 2026): **TL;DR:** I ran the T2 cancel test on Linux. The cancel reaches the server fast. The server only reads it when a long block of work ends. Then it stops and sends no reply. One late cancel did race a finished reply out. I ran repro step 5 on main `8550913c` and the 6.3.0 release. Fixture: the issue's generator at 300 and 1,200 functions. Each run is one `analyze_javascript_application` call per session, done three times. Cancel timing on main, median of 3 runs: | Case | Cancel sent | Server stop | Reply sent | Next call | | --- | --- | --- | --- | --- | | 300, 200 ms after progress | 206 ms | 795 ms | No (3/3) | OK, 19 ms | | 1,200, 200 ms after progress | 210 ms | 2,842 ms | No (3/3) | OK, 25 ms | | 1,200, at 4,010 ms | 4,011 ms | 4,016 ms | No (3/3) | OK, 19 ms | - The cancel waits for the first stage to end. At 1,200 functions, that block lasts 2.5 to 3 s. Pings wait too, up to 2.8 s. None failed. - When the block ends, the server stops in a few ms. A cancel sent after the block stops it within 31 ms. The analysis does not finish. - No child processes or temp files were left. No Evidence was kept for a cancelled call. - One race run did send a reply. The server had finished 46 ms before the cancel. The reply went out 11 ms after it. The client dropped it, and the next call worked. - The 6.3.0 release acts the same. The block is graph building, not parsing. **Not run** Edit: I ran the current release, 6.5.0, instead of 6.0.0. The results are in [this comment](https://github.com/morluto/rea/issues/1065#issuecomment-6182760992). Step 4 is still not run. - Step 4, the CLI compare. - ~~The 6.0.0 package.~~ I ran 6.5.0 instead. - A real app, or many files at once. - Windows or macOS. - A heap snapshot. At 1,200 functions, server memory stays near 500 MiB after a cancel, up from 385 MiB. I don't know if that is held data. - ~~An idle machine. Other test suites shared mine (load 6 to 13 on 24 threads). Treat the times as a bit noisy.~~ Rerun on main 69fe5b601, see below. Edit: The idle-machine rerun on main 69fe5b601 is in [my new comment](https://github.com/morluto/rea/issues/1065#issuecomment-6102662188). The long block is gone there. Thanks, N0zoM1z0, for the clear repro steps. I can share the harness if it helps. <details> <summary>Full tables (median [min–max] of 3 runs)</summary> Times are ms from the tool call. "Server stop" is the server's own tool-done log line. No cancel, main: | Size | Analysis | Reply | Worst ping | Peak RSS | Next call | | --- | --- | --- | --- | --- | --- | | 300 | 1,422 [1,214–1,518] | typed `resource_constraint`, 1,529 B | 478 [423–553] | 744 MiB | 25 ms | | 1,200 | 4,458 [4,444–4,836] | typed `resource_constraint`, 1,529 B | 2,317 [2,211–2,680] | 846 MiB | 23 ms | Cancel, main: | Case | Cancel sent | Server stop | Stop minus cancel | Reply sent | Worst ping after cancel | | --- | --- | --- | --- | --- | --- | | 300, 200 ms after progress | 206 | 795 [726–870] | 589 [520–664] | 0/3 | 544 [475–617] | | 300, at 710 | 710 | 713 [712–741] | 3 [2–31] | 0/3 | 1 [1–2] | | 300, at 1,280 | 1,281 | 1,291 [1,285–1,293] | 10 [5–12] | 0/3 | 1 [1–2] | | 300, at 1,390 | 1,391 | 1,345 [1,232–1,395] | see below | 1/3 | 2 [2–2] | | 1,200, 200 ms after progress | 210 | 2,842 [2,561–3,017] | 2,632 [2,352–2,812] | 0/3 | 2,589 [2,309–2,762] | | 1,200, at 2,230 | 2,231 | 2,560 [2,540–2,733] | 328 [309–503] | 0/3 | 306 [287–479] | | 1,200, at 4,010 | 4,011 | 4,016 [4,014–4,022] | 5 [3–10] | 0/3 | 3 [2–8] | | 1,200, at 4,370 | 4,371 | 4,381 [4,374–4,381] | 10 [4–10] | 0/3 | 2 [1–3] | The 1,390 runs split three ways. One stopped with no reply. One finished before its cancel timer fired. One finished first and its reply crossed the cancel. Cancel, 6.3.0 release: | Case | Cancel sent | Server stop | Reply sent | Next call | | --- | --- | --- | --- | --- | | 300, 200 ms after progress | 207 | 663 [653–736] | 0/3 | OK, 19 ms | | 1,200, 200 ms after progress | 205 | 2,400 [2,371–2,448] | 0/3 | OK, 32 ms | Every run: no ping failed, no child process, no temp file left. The server quit 43 to 90 ms after close. Family peak never passed 981 MiB. </details> <details> <summary>Timeline, 1,200 functions, cancel 200 ms after progress</summary> This run used a small preload to log when the server SDK aborts the request. It does not change REA code. It also slows the run a bit. | ms | Where | Event | | ---: | --- | --- | | 0 | client | tool call starts | | 5 | server | event loop blocks (3,132 ms) | | 7 | server | progress: start of analysis | | 207 | client | sends `notifications/cancelled`, rejects locally | | 3,137 | server | event loop free | | 3,142 | server | SDK aborts the request | | 3,144 | server | 12 queued pings answered (worst 2,894 ms) | | 3,147 | server | tool done, status error, no reply sent | | 5,769 | client | next `binary_session` OK (41 ms) | </details> <details> <summary>Where the event loop blocks (CPU profile, 1,200 functions)</summary> | Stage | Wall ms | Blocks? | Main cost | | --- | --- | --- | --- | | Inventory and parsing | 2,809 | Yes, one block | Semantic graph projection per file. Top self time: `canonicalize` 17%, `emitCanonical` 16%, zod 14%, GC 9%, hashing 7%. Babel parse is about 2%. | | Build application graph | 307 | Yes, 0.3 s | `createImmutableJavaScriptSemanticGraphSteps`: zod and ID checks. | | Seal semantic graph | 1,086 | No | Digest and freeze steps yield. | | Validate result | 288 | No | JSON value checks. | | Hash Evidence | 380 | No | Digest steps yield. | | Encode reply | about 70 | Short | Sizing the result for the stdio budget. | Most of the first block is building the semantic graph for the file. Digests and schema checks take most of that time. </details> <details> <summary>How I measured</summary> - One MCP session per run, SDK 2.3.1 stdio client, default receive buffer. - Server started as `node scripts/rea.mjs mcp`, like the repo's MCP tests. - List tools, then one `binary_session` call to warm up the client checks. - Ping every 250 ms during the call. - A tap on both pipes logs the cancel note and any reply for the cancelled id. - The server's own log line gives its stop time and status. - After the call, wait for the server to go idle. Then check child processes and temp files, and make the next call. - A small preload, in labelled runs only, logs SDK aborts and event loop stalls. - A side process samples family RSS every 100 ms with a 2,304 MiB kill cap. It never fired. </details> <details> <summary>Commands</summary> ```sh git -C rea.git archive 8550913cda311e5340cf012b9c4afd622e36e35b | tar -x -C src-main cd src-main && npm ci && npm run build:cached # client.mjs is the harness script, available on request ( ulimit -c 0; timeout 1200 taskset -c 2,3 node client.mjs --root src-main \ --fixture f1200/fixture --mode after-progress --cancel-ms 200 \ --server-node-args --max-old-space-size=1536 --out result.json ) node --cpu-prof --cpu-prof-interval=1000 --max-old-space-size=1536 scripts/rea.mjs mcp ``` </details> <details> <summary>Test setup</summary> - Box: Nobara Linux 44 (Fedora 44 base), Linux 7.2.9 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads (runs pinned to 2) - RAM: 32 GB DDR4-3600 - Node: 24.18.0 - Head / base: `8550913c` / 6.3.0 release - Other: MCP SDK client and server 2.3.1, 1,536 MiB server heap </details> 🤖 Generated with Claude Code (Opus 5.5) 🦊
bsakaguchi commented 2026-10-15 18:24:38 +00:00
Author
Owner
Copy link

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

Progress: #1402 finished 19/19 CI checks after the contributor merged it. #1410 is now merged (4d8ef3f), with all 19 final-head checks green; complete Evidence stayed identical in the controlled graph comparison. Its claim is narrower repeated family aggregation work, not whole-analysis throughput/token savings.

Prioritized contributor #1345 and pushed narrow follow-ups while preserving its commits. Final reviewed head is d21ba97b: caller-selected page bounds, API limitations/residual unknowns, recorded empty identity fields, actionable malformed-dossier details, CLI help/docs and simpler projection ownership. 34 focused regressions and full checking pass.

New real small-target verification used latest integrated main, a 16,784-byte source-owned ELF, Ghidra 12.1.4/JDK 21, verified JVM 512 MiB/two CPUs. Main CLI native-view rejection was reproduced; candidate CLI and public stdio MCP six-facet selection pass. Native full Evidence IDs match exactly across main CLI/candidate MCP; binary bytes are unchanged. Selected MCP results were 15,580–27,676 bytes versus 84,046 bytes complete, in 4–70 ms after ~91 s cold analysis. Family peak was 1,271,345,152 bytes. Small JavaScript CLI/MCP also produce the same Evidence ID with matching input choices. These are byte/behavior observations, not actual model-token measurements or broad provider coverage.

That runtime check exposed missing discriminator correction metadata. #1421 records the reproduced defect; ready PR #1425 fixes its shared owner with 49 passing focused tests and public CLI before/after reproduction. #1345 and #1425 are awaiting their current-head CI; no reviewers requested. #1247 discovery/cross-session work and this roadmap remain open.

<!-- gh-comment-id:6093479323 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Progress: #1402 finished 19/19 CI checks after the contributor merged it. #1410 is now merged (`4d8ef3f`), with all 19 final-head checks green; complete Evidence stayed identical in the controlled graph comparison. Its claim is narrower repeated family aggregation work, not whole-analysis throughput/token savings. Prioritized contributor #1345 and pushed narrow follow-ups while preserving its commits. Final reviewed head is `d21ba97b`: caller-selected page bounds, API limitations/residual unknowns, recorded empty identity fields, actionable malformed-dossier details, CLI help/docs and simpler projection ownership. 34 focused regressions and full checking pass. New real small-target verification used latest integrated main, a 16,784-byte source-owned ELF, Ghidra 12.1.4/JDK 21, verified JVM 512 MiB/two CPUs. Main CLI native-view rejection was reproduced; candidate CLI and public stdio MCP six-facet selection pass. Native full Evidence IDs match exactly across main CLI/candidate MCP; binary bytes are unchanged. Selected MCP results were 15,580–27,676 bytes versus 84,046 bytes complete, in 4–70 ms after ~91 s cold analysis. Family peak was 1,271,345,152 bytes. Small JavaScript CLI/MCP also produce the same Evidence ID with matching input choices. These are byte/behavior observations, not actual model-token measurements or broad provider coverage. That runtime check exposed missing discriminator correction metadata. #1421 records the reproduced defect; ready PR #1425 fixes its shared owner with 49 passing focused tests and public CLI before/after reproduction. #1345 and #1425 are awaiting their current-head CI; no reviewers requested. #1247 discovery/cross-session work and this roadmap remain open.
bsakaguchi commented 2026-10-15 18:24:38 +00:00
Author
Owner
Copy link

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

Small-target follow-up completed on main c29931ce:

  • #1410 merged after 19/19 final-head checks. Single-pass semantic family coverage preserves exact Evidence; the isolated aggregation measurement improved, while the end-to-end sample did not. No general throughput or token claim.
  • #1345 merged after 19/19 final-head checks and real Ghidra 12.1.4 CLI/stdin MCP verification on a 16,784-byte source-owned ELF. Six selected native facets preserve parent/subject identity, API limitations, unknowns and text/structured parity. Observed selected responses were 15,580–27,676 bytes versus 84,046 bytes for the complete dossier. Cold analysis remained about 91 seconds; byte reduction does not establish model-token savings or faster provider startup. #1247 remains partly open for discovery and snapshot-backed reuse.
  • #1425 merged after 19/19 final-head checks, closing #1421. Compiled CLI reproductions now retain actionable correction details for missing/unknown discriminators; 49 focused tests pass.
  • #1368 merged after 20/20 final-head checks, including Real JavaScript recovery. Independently built main failed on an inert 180 KB deep-member-access source; the reviewed candidate succeeds via real public CLI and stdio MCP, retaining three distinct return owners and exact CLI/MCP Evidence identity. 202 focused tests pass, and the follow-up small analysis and ping work.
  • #1414 remains ready and awaiting final-head CI at 4c08a7d3. Review reproduced a wrong literal on a 1,218-byte nine-alias target because of its former eight-arrival cap. Main's #1390 fixed-point propagation correctly reports unknown. The contributor PR now retains main's runtime unchanged and adds meaningful loop/compiled-CLI regressions. Eight branches pass and nine/twelve fail before removal of the cap; all cases pass afterward. All 377 focused tests and full serial static checks pass; all 704 test files are discovered exactly once. Contributor history is preserved, and both fork workflows have been approved. No reviewers were requested.

After these merges, an independently rebuilt public stdio MCP at c29931ce passes the deep source, ordinary two-function source, ping/follow-up, and portable selected view from the earlier real Ghidra dossier. The latter is inline Evidence verification, not another live-provider run. Default complete Evidence and text/structured contracts remain intact. The broader #1065 work remains open.

<!-- gh-comment-id:6093765340 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Small-target follow-up completed on main `c29931ce`: - #1410 merged after 19/19 final-head checks. Single-pass semantic family coverage preserves exact Evidence; the isolated aggregation measurement improved, while the end-to-end sample did not. No general throughput or token claim. - #1345 merged after 19/19 final-head checks and real Ghidra 12.1.4 CLI/stdin MCP verification on a 16,784-byte source-owned ELF. Six selected native facets preserve parent/subject identity, API limitations, unknowns and text/structured parity. Observed selected responses were 15,580–27,676 bytes versus 84,046 bytes for the complete dossier. Cold analysis remained about 91 seconds; byte reduction does not establish model-token savings or faster provider startup. #1247 remains partly open for discovery and snapshot-backed reuse. - #1425 merged after 19/19 final-head checks, closing #1421. Compiled CLI reproductions now retain actionable correction details for missing/unknown discriminators; 49 focused tests pass. - #1368 merged after 20/20 final-head checks, including Real JavaScript recovery. Independently built main failed on an inert 180 KB deep-member-access source; the reviewed candidate succeeds via real public CLI and stdio MCP, retaining three distinct return owners and exact CLI/MCP Evidence identity. 202 focused tests pass, and the follow-up small analysis and ping work. - #1414 remains ready and awaiting final-head CI at `4c08a7d3`. Review reproduced a wrong literal on a 1,218-byte nine-alias target because of its former eight-arrival cap. Main's #1390 fixed-point propagation correctly reports unknown. The contributor PR now retains main's runtime unchanged and adds meaningful loop/compiled-CLI regressions. Eight branches pass and nine/twelve fail before removal of the cap; all cases pass afterward. All 377 focused tests and full serial static checks pass; all 704 test files are discovered exactly once. Contributor history is preserved, and both fork workflows have been approved. No reviewers were requested. After these merges, an independently rebuilt public stdio MCP at `c29931ce` passes the deep source, ordinary two-function source, ping/follow-up, and portable selected view from the earlier real Ghidra dossier. The latter is inline Evidence verification, not another live-provider run. Default complete Evidence and text/structured contracts remain intact. The broader #1065 work remains open.
bsakaguchi commented 2026-10-15 18:24:38 +00:00
Author
Owner
Copy link

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

#1433 is merged as dc5af6d6 after all 19 final-head checks passed. Full discovery remains 139 tools; no default result or text/structured field was removed.

With the pinned SDK 2.3.1 default client and a real compiled stdio server, content/dialect-bound output-schema IDs reduce unchanged-catalog refreshes and same-client reconnects to zero new Ajv compilations. Initial discovery still compiles 118 distinct output schemas (21 shared-schema hits): 2,434.7 ms compilation within the first 2,743.6 ms call. Refresh calls measured 114.6/29.6 ms; these are individual two-CPU observations, not a general throughput or model-context claim. Schema changes, availability changes and reconnect correctness pass actual SDK regressions, and directory analysis → retained summary/module page → ping → close passes in both connections. Explicit schema IDs and relative external reference bases are preserved.

The remaining eager first-call cost is separately tracked upstream at modelcontextprotocol/typescript-sdk#2997. Discovery now measures 1,884,470 compact bytes because the IDs add metadata; context/tool-selection cost and result repetition under #723 remain open.

Recent #1345 real-Ghidra selected-facet verification and merges are recorded above. Large-file synchronous parsing/projection and eager graph capture still delay cancellation/ping; the real ASAR run at #1390 completes but observed a 19.17-second maximum ping delay, so completion does not establish T2 responsiveness. Windows first-analysis waiting remains a separate acceptance task. #1252 is being implemented by its contributor; I will avoid duplicating it. #1251 follow-up traced the existing file_bytes budget to hashing only and verified independent terminal/hash budgets through real CLI/MCP captures; the documentation and executable workflow are in #1440. #1065 remains open and #740 deferred.

<!-- gh-comment-id:6093929556 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): #1433 is merged as `dc5af6d6` after all 19 final-head checks passed. Full discovery remains 139 tools; no default result or text/structured field was removed. With the pinned SDK 2.3.1 default client and a real compiled stdio server, content/dialect-bound output-schema IDs reduce unchanged-catalog refreshes and same-client reconnects to **zero new Ajv compilations**. Initial discovery still compiles 118 distinct output schemas (21 shared-schema hits): 2,434.7 ms compilation within the first 2,743.6 ms call. Refresh calls measured 114.6/29.6 ms; these are individual two-CPU observations, not a general throughput or model-context claim. Schema changes, availability changes and reconnect correctness pass actual SDK regressions, and directory analysis → retained summary/module page → ping → close passes in both connections. Explicit schema IDs and relative external reference bases are preserved. The remaining eager first-call cost is separately tracked upstream at modelcontextprotocol/typescript-sdk#2997. Discovery now measures 1,884,470 compact bytes because the IDs add metadata; context/tool-selection cost and result repetition under #723 remain open. Recent #1345 real-Ghidra selected-facet verification and merges are recorded above. Large-file synchronous parsing/projection and eager graph capture still delay cancellation/ping; the real ASAR run at #1390 completes but observed a 19.17-second maximum ping delay, so completion does not establish T2 responsiveness. Windows first-analysis waiting remains a separate acceptance task. #1252 is being implemented by its contributor; I will avoid duplicating it. #1251 follow-up traced the existing `file_bytes` budget to hashing only and verified independent terminal/hash budgets through real CLI/MCP captures; the documentation and executable workflow are in #1440. #1065 remains open and #740 deferred.
bsakaguchi commented 2026-10-15 18:24:38 +00:00
Author
Owner
Copy link

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

Follow-up evidence for this batch:

  • #1414 was withdrawn by its author in favor of #1390. The earlier eight-expansion cap produced a false complete literal on a tiny public CLI fixture; no cap was merged and the withdrawn PR will not be reopened.
  • #1430 removes the redundant native macOS provenance copy. The real CLI/stdio MCP follow-up #1436 is now merged at ce16f7bc: all 19 final-head checks passed, including five native operations on a source-built macOS artifact with unchanged target bytes and CLI/MCP provenance parity. Default Evidence contracts remain intact.
  • Independently reproduced #1428 on main using a 338-byte JavaScript target, reviewed existing #1437, and ran 336 adjacent/actual CLI/stdio MCP tests. Another maintainer merged that exact reviewed head. The unused-default precision gap observed in an extra control already exists on main; it is not a regression introduced by #1437.
  • #1441 records a real CI teardown failure whose root cause remains unverified. Sixteen original-case local repetitions passed. Ready diagnostic PR #1443 retains the full incomplete stop reason and preserves ownership and partial-observation checks; it does not claim to fix the underlying cleanup failure.

Next existing contributor review: #1439, which defers optional Playwright and Git imports to their actual callers. I will compare the frozen latest-main build and candidate using public CLI workflows on a small target before accepting its performance claims.

<!-- gh-comment-id:6094050151 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Follow-up evidence for this batch: - #1414 was withdrawn by its author in favor of #1390. The earlier eight-expansion cap produced a false complete literal on a tiny public CLI fixture; no cap was merged and the withdrawn PR will not be reopened. - #1430 removes the redundant native macOS provenance copy. The real CLI/stdio MCP follow-up #1436 is now merged at `ce16f7bc`: all 19 final-head checks passed, including five native operations on a source-built macOS artifact with unchanged target bytes and CLI/MCP provenance parity. Default Evidence contracts remain intact. - Independently reproduced #1428 on main using a 338-byte JavaScript target, reviewed existing #1437, and ran 336 adjacent/actual CLI/stdio MCP tests. Another maintainer merged that exact reviewed head. The unused-default precision gap observed in an extra control already exists on main; it is not a regression introduced by #1437. - #1441 records a real CI teardown failure whose root cause remains unverified. Sixteen original-case local repetitions passed. Ready diagnostic PR #1443 retains the full incomplete stop reason and preserves ownership and partial-observation checks; it does not claim to fix the underlying cleanup failure. Next existing contributor review: #1439, which defers optional Playwright and Git imports to their actual callers. I will compare the frozen latest-main build and candidate using public CLI workflows on a small target before accepting its performance claims.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

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

Real Windows cold-start/recovery follow-up on a frozen bb6fa1c6 snapshot, under the owned D:\tmp\rea test root:

  • Windows x64 Node 22.19.0, bring-your-own Ghidra 12.1.4/JDK 21, freshly built 6.3.0 native controls. The source-owned 1,024-byte native PE has SHA-256 732ec6083ae3b63bcbda33f2d0fd7e1a6539babade07cbdae4fc20d3394faf49. The owning runner used two-CPU affinity, reduced priority and a configured 512 MiB Java heap; the guard did not capture a birth-matched Java affinity/heap observation, so that narrower child-process detail is not independently asserted. No unrelated tools were installed or upgraded.
  • Actual pinned SDK stdio MCP, one connection: ordinary binary_overview hit REQUEST_TIMEOUT after 60,015 ms. Ping remained responsive; close_binary succeeded in 646 ms, then the same path/provider reopened on that connection. A caller-selected 240-second request deadline completed the cold retry in 163,025 ms, reporting two procedures/two segments. The next overview took 18.7 ms. The server's startup allowance was 300 seconds; it did not extend the client's deadline.
  • The supplied progress token yielded only binary_overview: started before timeout, and started/completed for the successful retry. No intermediate import/auto-analysis progress was observed; those operation markers are not an analysis percentage or an automatic client-timeout extension.
  • Across 218 pings, maximum measured wait was 544 ms. Final close succeeded; input digest was unchanged; no owned Ghidra runtime root or birth-matched observed process-family member remained. Guard exit 0, 260.17-second wall time, 754,233,344-byte peak sampled family RSS, no resource/deadline stop. This is a small-target cold-start/recovery proof, not broad Windows provider or mutation coverage.

Remaining native usability work is therefore first-wait visibility and expensive-import reuse (#1048), rather than an unverified close/reopen recipe. Native cold-start progress is outside the contributor's process-capture progress scope in #1252.

#1440 is now merged after 19/19 final-head checks and #1251 is closed: existing whole-file hash budgets are independent of terminal-output retention and the documented CLI/MCP workflow verifies that boundary. Latest main also contains #1439 (CLI lazy optional imports) and #1434 (comparison-node indexing). Their narrow claims do not close large-file cancellation/responsiveness. Next I am independently reviewing existing contributor #1444 for repeated object-write complexity; all 20 current-head CI checks pass, with local/public workflow review still in progress. #740 remains deferred.

<!-- gh-comment-id:6094271131 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Real Windows cold-start/recovery follow-up on a frozen `bb6fa1c6` snapshot, under the owned `D:\tmp\rea` test root: - Windows x64 Node 22.19.0, bring-your-own Ghidra 12.1.4/JDK 21, freshly built 6.3.0 native controls. The source-owned 1,024-byte native PE has SHA-256 `732ec6083ae3b63bcbda33f2d0fd7e1a6539babade07cbdae4fc20d3394faf49`. The owning runner used two-CPU affinity, reduced priority and a configured 512 MiB Java heap; the guard did not capture a birth-matched Java affinity/heap observation, so that narrower child-process detail is not independently asserted. No unrelated tools were installed or upgraded. - Actual pinned SDK stdio MCP, one connection: ordinary `binary_overview` hit `REQUEST_TIMEOUT` after **60,015 ms**. Ping remained responsive; `close_binary` succeeded in **646 ms**, then the same path/provider reopened on that connection. A caller-selected 240-second request deadline completed the cold retry in **163,025 ms**, reporting two procedures/two segments. The next overview took **18.7 ms**. The server's startup allowance was 300 seconds; it did not extend the client's deadline. - The supplied progress token yielded only `binary_overview: started` before timeout, and started/completed for the successful retry. No intermediate import/auto-analysis progress was observed; those operation markers are not an analysis percentage or an automatic client-timeout extension. - Across 218 pings, maximum measured wait was **544 ms**. Final close succeeded; input digest was unchanged; no owned Ghidra runtime root or birth-matched observed process-family member remained. Guard exit 0, 260.17-second wall time, 754,233,344-byte peak sampled family RSS, no resource/deadline stop. This is a small-target cold-start/recovery proof, not broad Windows provider or mutation coverage. Remaining native usability work is therefore first-wait visibility and expensive-import reuse (#1048), rather than an unverified close/reopen recipe. Native cold-start progress is outside the contributor's process-capture progress scope in #1252. #1440 is now merged after 19/19 final-head checks and #1251 is closed: existing whole-file hash budgets are independent of terminal-output retention and the documented CLI/MCP workflow verifies that boundary. Latest main also contains #1439 (CLI lazy optional imports) and #1434 (comparison-node indexing). Their narrow claims do not close large-file cancellation/responsiveness. Next I am independently reviewing existing contributor #1444 for repeated object-write complexity; all 20 current-head CI checks pass, with local/public workflow review still in progress. #740 remains deferred.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

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

Current performance/usability follow-up, with latest main synchronized through 78e1308f:

  • Repeated object-write complexity: #1444 merged as 1ec490f3 after all 20 final-head checks, preserving contributor history. Independent review includes 327 adjacent cases, 57 actual CLI/stdio MCP alias/slot scenarios, 50,000 seeded old/new mutation-fold comparisons, and paired real Notion ASAR runs against frozen latest-main e09cfe9b. Both real runs retain the exact same Evidence and source digest. The candidate observation was 87.76 s versus 95.58 s; maximum ping still waited 17.74 s. These single observations support the narrow algorithmic change, not a T2 responsiveness or percentile claim.
  • Residual control-path blocking: new #1462 isolates synchronous per-file analysis/projection and eager graph capture. It still reproduces after merged #1457/#1460: explicit cancellation ends the warmed client wait at 205.2 ms, while ping waits another 572.7 ms on the same 67,469-byte fixture. No cancelled Evidence is retained; follow-up analysis/close and input identity pass. Full ASAR control responsiveness is not claimed fixed by the context-hash cache.
  • Windows first-query recovery: real native Windows SDK/Ghidra timeout → close → reopen → caller-selected longer-deadline retry → warm query succeeds, as recorded above. #1452 merged the measured workflow and its limitations (c89c8f53). First-wait progress and import reuse (#1048) remain; operation started/completed markers do not establish intermediate analysis progress.
  • Capture representation/usability: #1450 compacts normalized rendered rows while retaining raw admitted PTY chunks. #1465 now corrects the restoration/Unicode/normalization guide; duplicate #1466 was closed in its favor. Independent actual public stdio capture, normalization and owned cleanup checks agree. No model-token savings or universal pad-to-columns reconstruction claim.
  • Next existing contributor review: #1458 derives application graph IDs once while retaining full stored/untrusted graph checks. All 20 current-head checks pass; independent latest-main integration and public workflow verification are in progress. Its author reports no measurable end-to-end gain on real package analysis, so it is not a substitute for #1462.

Previously completed: #1433 removes repeated unchanged-catalog SDK compilations without reducing the full 139-tool inventory; SDK eager cold compilation remains upstream at modelcontextprotocol/typescript-sdk#2997. #1440 closes #1251 by documenting/testing the existing independent whole-file hash budget. #1345 selected native facets have real Linux Ghidra proof; #1247 discovery/snapshot reuse remains partly open. Windows DLL admission #1303 closes #1290; it does not add Windows mutation authority. #1443 preserves JADX cleanup failure diagnostics, while the root cause in #1441 remains unreproduced.

#1252 is still with its contributor (shared rate-limited CLI stderr/MCP-token reporter; no new PR seen at this refresh), and will not be duplicated. #1253 bounded child finalization and the private-bundle report #1387 remain distinct unresolved items. #740 stays deferred. #1065 remains open.

<!-- gh-comment-id:6094919195 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Current performance/usability follow-up, with latest main synchronized through `78e1308f`: - **Repeated object-write complexity:** #1444 merged as `1ec490f3` after all 20 final-head checks, preserving contributor history. Independent review includes 327 adjacent cases, 57 actual CLI/stdio MCP alias/slot scenarios, 50,000 seeded old/new mutation-fold comparisons, and paired real Notion ASAR runs against frozen latest-main `e09cfe9b`. Both real runs retain the exact same Evidence and source digest. The candidate observation was 87.76 s versus 95.58 s; maximum ping still waited 17.74 s. These single observations support the narrow algorithmic change, not a T2 responsiveness or percentile claim. - **Residual control-path blocking:** new #1462 isolates synchronous per-file analysis/projection and eager graph capture. It still reproduces after merged #1457/#1460: explicit cancellation ends the warmed client wait at 205.2 ms, while ping waits another 572.7 ms on the same 67,469-byte fixture. No cancelled Evidence is retained; follow-up analysis/close and input identity pass. Full ASAR control responsiveness is not claimed fixed by the context-hash cache. - **Windows first-query recovery:** real native Windows SDK/Ghidra timeout → close → reopen → caller-selected longer-deadline retry → warm query succeeds, as recorded above. #1452 merged the measured workflow and its limitations (`c89c8f53`). First-wait progress and import reuse (#1048) remain; operation started/completed markers do not establish intermediate analysis progress. - **Capture representation/usability:** #1450 compacts normalized rendered rows while retaining raw admitted PTY chunks. #1465 now corrects the restoration/Unicode/normalization guide; duplicate #1466 was closed in its favor. Independent actual public stdio capture, normalization and owned cleanup checks agree. No model-token savings or universal pad-to-columns reconstruction claim. - **Next existing contributor review:** #1458 derives application graph IDs once while retaining full stored/untrusted graph checks. All 20 current-head checks pass; independent latest-main integration and public workflow verification are in progress. Its author reports no measurable end-to-end gain on real package analysis, so it is not a substitute for #1462. Previously completed: #1433 removes repeated unchanged-catalog SDK compilations without reducing the full 139-tool inventory; SDK eager cold compilation remains upstream at modelcontextprotocol/typescript-sdk#2997. #1440 closes #1251 by documenting/testing the existing independent whole-file hash budget. #1345 selected native facets have real Linux Ghidra proof; #1247 discovery/snapshot reuse remains partly open. Windows DLL admission #1303 closes #1290; it does not add Windows mutation authority. #1443 preserves JADX cleanup failure diagnostics, while the root cause in #1441 remains unreproduced. #1252 is still with its contributor (shared rate-limited CLI stderr/MCP-token reporter; no new PR seen at this refresh), and will not be duplicated. #1253 bounded child finalization and the private-bundle report #1387 remain distinct unresolved items. #740 stays deferred. #1065 remains open.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

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

Independent maintenance update:

  • #1439 is merged: pinned Linux Node 24/two-CPU interleaved CLI startup samples show a 25.2% median reduction, with unchanged help/default Evidence and actual Git/owned Chromium/stdio MCP checks. MCP still resolves Playwright at startup; no MCP browser-laziness or model-token saving is claimed.
  • #1434 is merged after actual small-target comparison CLI/MCP identity/provenance checks. Tiny-target timings did not establish a speedup; the larger benchmark remains contributor evidence.
  • #1448 fixes the combined-main duplication gate by reusing existing comparison fixtures, without changing thresholds/exclusions. #1443 then integrated current main and is merged after19/19 final-head checks. The original #1441 cleanup root cause remains unreproduced; the new assertion preserves its typed reason.
  • The doctor investigation exposed a correctness bug, not a measured speedup. #1461 is merged after19/19 exact-head checks and closes #1454: a schema-invalid production probe is now rejected while retaining initialized server/full inventory. The meaningful stdio regression fails on original main and passes the fix; all9 doctor/help tests and full serial static checks pass. Valid doctor reports remain byte-identical at1593 bytes, and an actual74-byte CLI/MCP target preserves default Evidence, source digest, text/structured parity and ping. No deep-analysis-engine or model-token claim is implied by this protocol test.
  • Reviewed #1457 independently before it was merged by another maintainer. Actual1567-byte/two-file latest-main-control CLI/MCP Evidence is byte-identical (315871 CLI bytes), with unchanged116 nodes/74 relations/6 unknowns/9 contexts. The actual compiled registry on3 production contexts has interleaved10000-fact medians208.75→80.98ms. This validates the registry hotspot, not whole-product or token savings; Obsidian was not repeated.
  • #1450 was merged externally. Independent actual55-byte Linux PTY CLI/MCP capture preserves original admitted bytes, serialized content, source digest/parity/ping and owned cleanup. For the same identity-normalized capture, dropping rendered padding reduces structured JSON8517→6612 bytes (~22.4%). Actual CLI comparison explicitly rejects old/new line-format contracts. Expanded normalization and combining Unicode also disproved the universal pad-to-columns restoration recipe; #1464 records that, and own docs follow-up #1465 is now merged after the applicable docs-only checks.

Continuing with existing #1438/#1245: latest-main integration conflicts with the Windows fixture generator. Local resolution preserves contributor EXE bytes and main DLL bytes exactly, and scopes EXE-only compact-reference controls correctly. Source/schema integration checks are in progress; the contributor's actual Windows Ghidra runs remain attributed contributor evidence, not an independent local engine claim. All our Git identities use verified GitHub noreply addresses; no reviewers requested.

<!-- gh-comment-id:6095026898 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Independent maintenance update: - #1439 is merged: pinned Linux Node 24/two-CPU interleaved CLI startup samples show a 25.2% median reduction, with unchanged help/default Evidence and actual Git/owned Chromium/stdio MCP checks. MCP still resolves Playwright at startup; no MCP browser-laziness or model-token saving is claimed. - #1434 is merged after actual small-target comparison CLI/MCP identity/provenance checks. Tiny-target timings did not establish a speedup; the larger benchmark remains contributor evidence. - #1448 fixes the combined-main duplication gate by reusing existing comparison fixtures, without changing thresholds/exclusions. #1443 then integrated current main and is merged after19/19 final-head checks. The original #1441 cleanup root cause remains unreproduced; the new assertion preserves its typed reason. - The doctor investigation exposed a correctness bug, not a measured speedup. #1461 is merged after19/19 exact-head checks and closes #1454: a schema-invalid production probe is now rejected while retaining initialized server/full inventory. The meaningful stdio regression fails on original main and passes the fix; all9 doctor/help tests and full serial static checks pass. Valid doctor reports remain byte-identical at1593 bytes, and an actual74-byte CLI/MCP target preserves default Evidence, source digest, text/structured parity and ping. No deep-analysis-engine or model-token claim is implied by this protocol test. - Reviewed #1457 independently before it was merged by another maintainer. Actual1567-byte/two-file latest-main-control CLI/MCP Evidence is byte-identical (315871 CLI bytes), with unchanged116 nodes/74 relations/6 unknowns/9 contexts. The actual compiled registry on3 production contexts has interleaved10000-fact medians208.75→80.98ms. This validates the registry hotspot, not whole-product or token savings; Obsidian was not repeated. - #1450 was merged externally. Independent actual55-byte Linux PTY CLI/MCP capture preserves original admitted bytes, serialized content, source digest/parity/ping and owned cleanup. For the same identity-normalized capture, dropping rendered padding reduces structured JSON8517→6612 bytes (~22.4%). Actual CLI comparison explicitly rejects old/new line-format contracts. Expanded normalization and combining Unicode also disproved the universal pad-to-columns restoration recipe; #1464 records that, and own docs follow-up #1465 is now merged after the applicable docs-only checks. Continuing with existing #1438/#1245: latest-main integration conflicts with the Windows fixture generator. Local resolution preserves contributor EXE bytes and main DLL bytes exactly, and scopes EXE-only compact-reference controls correctly. Source/schema integration checks are in progress; the contributor's actual Windows Ghidra runs remain attributed contributor evidence, not an independent local engine claim. All our Git identities use verified GitHub noreply addresses; no reviewers requested.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

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

#1458 is now merged as 934ffd28 after all 20 original final-head checks. Independent local integration with main passes 46 focused cases (including real public CLI/stdio MCP) and complete serial static checks. Interleaved controlled comparison results are byte-identical: 4,000 modules measured 2,831–2,874 ms before and 2,288–2,295 ms after. This is a synthetic comparison observation, not a claim of general analysis throughput, T2 responsiveness or model-token savings.

The rebuilt integration is production-source-identical to frozen main 934ffd28 through #1457/#1458. A fresh real full Notion ASAR workflow still observes 13,078 ms maximum ping wait and preserves the exact complete Evidence ev_8b49aebfa361929c6c2b206271260bf2851a55e729884215b8f87fbb4ad8b490. Default discovery remains 139 tools. Typed framing recovery, retained summary/modules, feature trace, malformed distinct-input check, subsequent ping, close, expired selection and unchanged target bytes all pass. Guard exit 0 and 1,897,279,488-byte peak sampled family RSS.

The latest analysis observation was 163.45 s. A same-current-environment frozen 439bc1a5 control also varies substantially from its earlier run: 148.58 s / 36,265 ms max ping, same Evidence/input, guard exit 0 and 1,690,976,256-byte peak RSS. Phase costs vary; these single runs are not used to assign a throughput regression to one merge. They confirm that multi-second control pauses remain; #1462 now carries the latest full-workflow proof.

Recent issue/PR refresh: #1262 remains closed; #1251 and #1290 are closed; #1252 is still being implemented by its contributor, with no PR seen at this refresh. #1247 is partially fulfilled by merged #1345 and remains open for discovery/snapshot reuse. #1048 and upstream SDK #2997 remain open. New #1477 proposes removing exact duplicate NIB display attributes and still needs contract/provenance and applicable final-head review; its real app byte figures are contributor evidence. #1438 is under the other maintainer's active review. #740 remains deferred and #1065 remains open.

Later main refresh: 7296f2b5 adds #1473 (the artifact graph remains once in nested inventory Evidence) and #1474 (semantic node/relation identifier descriptions move into the schema). #1474 explicitly changes relation IDs and strict old-Evidence compatibility; the identical Evidence measurements above apply to the frozen pre-1474 pair. These new payload changes were merged by another maintainer; I am checking their adjacent actual current-MCP behavior without attributing their real-app measurements as independent evidence.

<!-- gh-comment-id:6095098832 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): #1458 is now merged as `934ffd28` after all 20 original final-head checks. Independent local integration with main passes 46 focused cases (including real public CLI/stdio MCP) and complete serial static checks. Interleaved controlled comparison results are byte-identical: 4,000 modules measured 2,831–2,874 ms before and 2,288–2,295 ms after. This is a synthetic comparison observation, not a claim of general analysis throughput, T2 responsiveness or model-token savings. The rebuilt integration is production-source-identical to frozen main `934ffd28` through #1457/#1458. A fresh real full Notion ASAR workflow still observes **13,078 ms maximum ping wait** and preserves the exact complete Evidence `ev_8b49aebfa361929c6c2b206271260bf2851a55e729884215b8f87fbb4ad8b490`. Default discovery remains 139 tools. Typed framing recovery, retained summary/modules, feature trace, malformed distinct-input check, subsequent ping, close, expired selection and unchanged target bytes all pass. Guard exit 0 and 1,897,279,488-byte peak sampled family RSS. The latest analysis observation was 163.45 s. A same-current-environment frozen `439bc1a5` control also varies substantially from its earlier run: 148.58 s / 36,265 ms max ping, same Evidence/input, guard exit 0 and 1,690,976,256-byte peak RSS. Phase costs vary; these single runs are not used to assign a throughput regression to one merge. They confirm that multi-second control pauses remain; #1462 now carries the latest full-workflow proof. Recent issue/PR refresh: #1262 remains closed; #1251 and #1290 are closed; #1252 is still being implemented by its contributor, with no PR seen at this refresh. #1247 is partially fulfilled by merged #1345 and remains open for discovery/snapshot reuse. #1048 and upstream SDK #2997 remain open. New #1477 proposes removing exact duplicate NIB display attributes and still needs contract/provenance and applicable final-head review; its real app byte figures are contributor evidence. #1438 is under the other maintainer's active review. #740 remains deferred and #1065 remains open. Later main refresh: `7296f2b5` adds #1473 (the artifact graph remains once in nested inventory Evidence) and #1474 (semantic node/relation identifier descriptions move into the schema). #1474 explicitly changes relation IDs and strict old-Evidence compatibility; the identical Evidence measurements above apply to the frozen pre-1474 pair. These new payload changes were merged by another maintainer; I am checking their adjacent actual current-MCP behavior without attributing their real-app measurements as independent evidence.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

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

Maintenance update: #1456 is merged after all 22 applicable checks passed on 561877ad. Review found and fixed two additional boundary problems: split/join changed the admitted empty-pattern behavior, and silently changing replacement semantics made historical captures compare as if they shared one contract. Literal replacements now preserve the empty-pattern boundaries, and captures with custom patterns explicitly version the replacement semantics. Legacy/new comparisons require recapture; no-pattern contracts are unchanged.

The merged five changed files are byte-identical to the reviewed head. Main advanced concurrently, so I also compiled current main 7a56fe62 and repeated the actual public CLI plus production SDK stdio MCP workflow on a source-owned 28-byte process target: literal dollar tokens, empty pattern, retained raw output/caller patterns, legacy comparison refusal, current/current comparison, owned cleanup, text/structured parity and subsequent ping all pass. This is Linux PTY verification, with no model-token or general throughput claim.

Independent verification of merged #1479 also establishes 1,958 placeholder descriptions removed from the actual 139-tool SDK catalog while retaining all other tool fields and schema validity. Summed input-schema JSON fell 13.8%; a cl100k_base reference count fell 10.5%. Those are catalog/reference-token measurements, not actual model billing or tool-selection quality. Current #1438 has all 19 applicable checks green and is still awaiting the requested contributor tiny-EXE Ghidra result on its current head. #1065 remains open.

<!-- gh-comment-id:6095970652 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Maintenance update: #1456 is merged after all 22 applicable checks passed on `561877ad`. Review found and fixed two additional boundary problems: split/join changed the admitted empty-pattern behavior, and silently changing replacement semantics made historical captures compare as if they shared one contract. Literal replacements now preserve the empty-pattern boundaries, and captures with custom patterns explicitly version the replacement semantics. Legacy/new comparisons require recapture; no-pattern contracts are unchanged. The merged five changed files are byte-identical to the reviewed head. Main advanced concurrently, so I also compiled current main `7a56fe62` and repeated the actual public CLI plus production SDK stdio MCP workflow on a source-owned 28-byte process target: literal dollar tokens, empty pattern, retained raw output/caller patterns, legacy comparison refusal, current/current comparison, owned cleanup, text/structured parity and subsequent ping all pass. This is Linux PTY verification, with no model-token or general throughput claim. Independent verification of merged #1479 also establishes 1,958 placeholder descriptions removed from the actual 139-tool SDK catalog while retaining all other tool fields and schema validity. Summed input-schema JSON fell 13.8%; a cl100k_base reference count fell 10.5%. Those are catalog/reference-token measurements, not actual model billing or tool-selection quality. Current #1438 has all 19 applicable checks green and is still awaiting the requested contributor tiny-EXE Ghidra result on its current head. #1065 remains open.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

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

Maintenance update: #1483 is merged as 3cd80cbb after 23/23 checks and actual post-merge 84-byte CLI/SDK MCP capture verification. The delayed-observer control avoids queued stale status while preserving final cleanup delivery and complete Evidence.

#1527 is merged as c73cf0ab after 19/19 checks. Independent runtime reproduction found duplicate output-schema IDs stopping both native verifiers; the consumer audit also found and fixed the Electron registration site. Fresh merged-main build and actual 44-byte JavaScript CLI/SDK MCP verification pass, as do native catalog-startup and exact Electron registration controls on 139 tools/118 distinct output IDs. Full native-engine and full Electron app workflows remain explicitly outside this local scope. Both contributor patches/authors are preserved.

Completed owned worktrees/build outputs were removed normally after verification; about 797 MiB has been reclaimed in this cleanup batch. No owned build is currently retained. Branches, small reproduction inputs/results and failed diagnosis receipts remain recoverable; root/shared dependencies and other workspaces were preserved. The iterative maintenance goal continues; #1438 still awaits its requested fresh native confirmation.

<!-- gh-comment-id:6097164516 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Maintenance update: #1483 is merged as `3cd80cbb` after 23/23 checks and actual post-merge 84-byte CLI/SDK MCP capture verification. The delayed-observer control avoids queued stale status while preserving final cleanup delivery and complete Evidence. #1527 is merged as `c73cf0ab` after 19/19 checks. Independent runtime reproduction found duplicate output-schema IDs stopping both native verifiers; the consumer audit also found and fixed the Electron registration site. Fresh merged-main build and actual 44-byte JavaScript CLI/SDK MCP verification pass, as do native catalog-startup and exact Electron registration controls on 139 tools/118 distinct output IDs. Full native-engine and full Electron app workflows remain explicitly outside this local scope. Both contributor patches/authors are preserved. Completed owned worktrees/build outputs were removed normally after verification; about 797 MiB has been reclaimed in this cleanup batch. No owned build is currently retained. Branches, small reproduction inputs/results and failed diagnosis receipts remain recoverable; root/shared dependencies and other workspaces were preserved. The iterative maintenance goal continues; #1438 still awaits its requested fresh native confirmation.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

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

2026-10-10 follow-up, with current main refreshed after each reviewed merge:

  • #1539 fixed the independently reproduced wide receiver-return argument-limit failure (#1538): public CLI/stdio MCP and 18 complete-IR comparisons passed, followed by 20 successful final-head checks. #1538 is closed. This does not establish a fix for the private exit-134 report #1387.
  • #1483's bounded capture progress update is merged, including the SDK cancellation-test follow-up. #1252 is closed; Linux real-child CLI/SDK boundary checks passed, with Windows PTY/macOS real capture outside the independent scope.
  • #1545 is merged after 202 focused tests, static checks, 30 complete-IR comparisons, four public real-ASAR workflows and 20 successful final-head CI checks. Complete Evidence identity is preserved. In the two constrained Linux observations per revision, main's longest sampled ping waited 1.24/4.71 s and the candidate's waited 0.55/0.94 s. Analysis wall time varied enough that no general throughput claim is made. Full results: https://github.com/morluto/rea/issues/1462#issuecomment-6097475211 . #1462 remains open.
  • Real Ghidra native collection coverage now includes all 15 facets and separately nonempty parameter/parameter-use rows, exact CLI/MCP page identity, stable run identity, close/expiry/input identity and cleanup. #1247 still needs discovery, snapshot-backed cross-session reuse and oversized-source acceptance: https://github.com/morluto/rea/issues/1247#issuecomment-6097329985 . No independent real Hopper or Windows native-page proof is claimed.
  • #1550 repairs the native verifier's concrete loss of caller-selected Node heap options (#1548), after actual child-boundary checks, static checks and 19 successful final-head checks. The full Ghidra verifier still hit the existing 2304 MiB total family-RSS guard; preserving the Node option alone does not bound concurrent verifier processes. #1548 is closed, with that limitation explicit in the PR.

Remaining priorities: #1462's remaining blocking stages; upstream SDK cold preparation issue modelcontextprotocol/typescript-sdk#2997; #1048 pre-imported Ghidra project reuse/first-wait usability; the remaining #1247 native reuse/oversized workflow; #1253 bounded child finalization. #1387 and #1441 remain unverified rather than assumed fixed. #740 remains deferred.

Cleanup: approximately 638 MiB of our obsolete build/cache/runtime/interrupted-verifier artifacts has been removed. Compact exact-digest reports and reproduction inputs remain. Original samples/BYO tools, protected files and unrelated maintenance worktrees were preserved.

<!-- gh-comment-id:6097502523 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): 2026-10-10 follow-up, with current main refreshed after each reviewed merge: - #1539 fixed the independently reproduced wide receiver-return argument-limit failure (#1538): public CLI/stdio MCP and 18 complete-IR comparisons passed, followed by 20 successful final-head checks. #1538 is closed. This does not establish a fix for the private exit-134 report #1387. - #1483's bounded capture progress update is merged, including the SDK cancellation-test follow-up. #1252 is closed; Linux real-child CLI/SDK boundary checks passed, with Windows PTY/macOS real capture outside the independent scope. - #1545 is merged after 202 focused tests, static checks, 30 complete-IR comparisons, four public real-ASAR workflows and 20 successful final-head CI checks. Complete Evidence identity is preserved. In the two constrained Linux observations per revision, main's longest sampled ping waited 1.24/4.71 s and the candidate's waited 0.55/0.94 s. Analysis wall time varied enough that no general throughput claim is made. Full results: https://github.com/morluto/rea/issues/1462#issuecomment-6097475211 . #1462 remains open. - Real Ghidra native collection coverage now includes all 15 facets and separately nonempty parameter/parameter-use rows, exact CLI/MCP page identity, stable run identity, close/expiry/input identity and cleanup. #1247 still needs discovery, snapshot-backed cross-session reuse and oversized-source acceptance: https://github.com/morluto/rea/issues/1247#issuecomment-6097329985 . No independent real Hopper or Windows native-page proof is claimed. - #1550 repairs the native verifier's concrete loss of caller-selected Node heap options (#1548), after actual child-boundary checks, static checks and 19 successful final-head checks. The full Ghidra verifier still hit the existing 2304 MiB total family-RSS guard; preserving the Node option alone does not bound concurrent verifier processes. #1548 is closed, with that limitation explicit in the PR. Remaining priorities: #1462's remaining blocking stages; upstream SDK cold preparation issue modelcontextprotocol/typescript-sdk#2997; #1048 pre-imported Ghidra project reuse/first-wait usability; the remaining #1247 native reuse/oversized workflow; #1253 bounded child finalization. #1387 and #1441 remain unverified rather than assumed fixed. #740 remains deferred. Cleanup: approximately 638 MiB of our obsolete build/cache/runtime/interrupted-verifier artifacts has been removed. Compact exact-digest reports and reproduction inputs remain. Original samples/BYO tools, protected files and unrelated maintenance worktrees were preserved.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

@BaaRai commented on GitHub (Oct 10, 2026):

One work-item suggestion for this roadmap, scoped to transports.

Motivation: the goal here is responsive, reliable MCP analysis, but stdio is currently the only server transport, and it requires the client to spawn a local process. Agents running in containers or on remote machines often cannot do that, so they cannot use REA at all today even though the analysis workflow itself would suit them.

Suggestion: offer a streamable HTTP transport alongside stdio, with an optional auth token for that transport. Same tool catalog, same contracts, stdio stays the default and remains fully supported. The security boundary for the HTTP listener (bind scope, token handling) is a design decision that belongs to this roadmap rather than something to assume in advance.

Happy to help scope or implement whichever slice the roadmap wants first if this fits.

<!-- gh-comment-id:6097655761 --> @BaaRai commented on GitHub (Oct 10, 2026): One work-item suggestion for this roadmap, scoped to transports. Motivation: the goal here is responsive, reliable MCP analysis, but stdio is currently the only server transport, and it requires the client to spawn a local process. Agents running in containers or on remote machines often cannot do that, so they cannot use REA at all today even though the analysis workflow itself would suit them. Suggestion: offer a streamable HTTP transport alongside stdio, with an optional auth token for that transport. Same tool catalog, same contracts, stdio stays the default and remains fully supported. The security boundary for the HTTP listener (bind scope, token handling) is a design decision that belongs to this roadmap rather than something to assume in advance. Happy to help scope or implement whichever slice the roadmap wants first if this fits.
bsakaguchi commented 2026-10-15 18:24:39 +00:00
Author
Owner
Copy link

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

Current main is 8c47a9ce; #1557 merged after all20 exact-final-head checks passed. Receiver/reference/Electron classification scans now cooperate with the existing analysis checkpoints; #1462 remains open for parsing and other long semantic steps. Independent real-ASAR complete Evidence identity,30 IR cases,CLI/SDK cancellation/recovery and162 post-main-integration tests passed.

New public Claude Code2.1.296 memory case: #1563. Verified exact npm artifact and Bun module table,2,589 modules/~47.3MiB contents; identified shareable4.54MiB member. Full tree on exact merged main still fatally exhausts old-space1024MiB (201.69s, family peak1356345344 bytes,zero JSON bytes), without external guard intervention. Isolated member fatally exhausts768MiB in current CLI and actual139-tool SDK/MCP server; MCP process dies, tool rejects CONNECTION_CLOSED and next ping is disconnected. Published6.3.0 independently reproduces the isolated failure. A production-domain diagnostic completes parsing/classification/static scanning and fails during semantic analysis; finer allocation ownership remains open. Single-member1024MiB completes but full tree does not: it is not a full-input workaround. All2,589 source hashes remain unchanged.

#1563 carries bug/performance/P1/domain/CLI/MCP labels and exact public extraction offsets/hashes. This does not establish the original poster's heap/REA version or close private-input #1387. Removed downloaded native carrier/tarball, video intermediates, obsolete release runtime and duplicate sample; retained compact receipts and the extracted producer input for the fix. Next user-requested work is review and actual install/runtime verification of #1359; #740 remains deferred.

<!-- gh-comment-id:6098310196 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Current main is `8c47a9ce`; #1557 merged after all20 exact-final-head checks passed. Receiver/reference/Electron classification scans now cooperate with the existing analysis checkpoints; #1462 remains open for parsing and other long semantic steps. Independent real-ASAR complete Evidence identity,30 IR cases,CLI/SDK cancellation/recovery and162 post-main-integration tests passed. New public Claude Code2.1.296 memory case: #1563. Verified exact npm artifact and Bun module table,2,589 modules/~47.3MiB contents; identified shareable4.54MiB member. Full tree on exact merged main still fatally exhausts old-space1024MiB (201.69s, family peak1356345344 bytes,zero JSON bytes), without external guard intervention. Isolated member fatally exhausts768MiB in current CLI and actual139-tool SDK/MCP server; MCP process dies, tool rejects CONNECTION_CLOSED and next ping is disconnected. Published6.3.0 independently reproduces the isolated failure. A production-domain diagnostic completes parsing/classification/static scanning and fails during semantic analysis; finer allocation ownership remains open. Single-member1024MiB completes but full tree does not: it is not a full-input workaround. All2,589 source hashes remain unchanged. #1563 carries bug/performance/P1/domain/CLI/MCP labels and exact public extraction offsets/hashes. This does not establish the original poster's heap/REA version or close private-input #1387. Removed downloaded native carrier/tarball, video intermediates, obsolete release runtime and duplicate sample; retained compact receipts and the extracted producer input for the fix. Next user-requested work is review and actual install/runtime verification of #1359; #740 remains deferred.
bsakaguchi commented 2026-10-15 18:24:40 +00:00
Author
Owner
Copy link

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

After accepting #1537 and #1378, I independently rebuilt their merged main revisions and repeated the actual small-target public CLI/SDK stdio MCP workflows. #1537 preserves the complete returned-reference result while reducing the directly counted property candidates in the fixture; #1378 fixes selected archive traversal with a real unrelated EACCES sibling, preserving the raw input path/digest and numeric Evidence. Their exact-head CI gates and postmerge probes passed.

#1393 is also merged after 20/20 exact-head checks. Freshly rebuilt merged main 649661dc passes the same independent 327-byte public fixture: four media-hint false preload nodes/edges disappear, with all remaining result content and provenance preserved except derived graph IDs/findings count. Its full CLI output is 69,582 -> 57,910 bytes and MCP reply 145,962 -> 121,490 bytes. 65 relevant tests and all local gates pass. These fixture byte counts are not billed-token or general throughput estimates.

Completed owned worktrees/builds are normally removed after postmerge verification. Shared dependencies, other workers' files, source branches and proof/failure receipts remain. This does not establish native Electron runtime or Windows/macOS behavior from the Linux public probes. The bounded-resource maintenance and remaining output/Evidence work continue under this roadmap and #723.

The completed cleanup now totals 911.6 MiB and 28 normally removed owned worktrees, with zero current owned builds retained. Next candidate #1560 is only a metadata lead so far: its advertised-input-example/catalog size claim still needs independent source review and an actual latest-main SDK/small-target reproduction on a new branch.

<!-- gh-comment-id:6098392417 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): After accepting #1537 and #1378, I independently rebuilt their merged main revisions and repeated the actual small-target public CLI/SDK stdio MCP workflows. #1537 preserves the complete returned-reference result while reducing the directly counted property candidates in the fixture; #1378 fixes selected archive traversal with a real unrelated EACCES sibling, preserving the raw input path/digest and numeric Evidence. Their exact-head CI gates and postmerge probes passed. #1393 is also merged after 20/20 exact-head checks. Freshly rebuilt merged main `649661dc` passes the same independent 327-byte public fixture: four media-hint false preload nodes/edges disappear, with all remaining result content and provenance preserved except derived graph IDs/findings count. Its full CLI output is 69,582 -> 57,910 bytes and MCP reply 145,962 -> 121,490 bytes. 65 relevant tests and all local gates pass. These fixture byte counts are not billed-token or general throughput estimates. Completed owned worktrees/builds are normally removed after postmerge verification. Shared dependencies, other workers' files, source branches and proof/failure receipts remain. This does not establish native Electron runtime or Windows/macOS behavior from the Linux public probes. The bounded-resource maintenance and remaining output/Evidence work continue under this roadmap and #723. The completed cleanup now totals 911.6 MiB and 28 normally removed owned worktrees, with zero current owned builds retained. Next candidate #1560 is only a metadata lead so far: its advertised-input-example/catalog size claim still needs independent source review and an actual latest-main SDK/small-target reproduction on a new branch.
bsakaguchi commented 2026-10-15 18:24:40 +00:00
Author
Owner
Copy link

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

Completed the user-requested review and actual Frida installation/runtime verification for #1359 at 4e766550. Eight inline findings and verification details are published as changes requested.

Real native Frida 17.23.2 works through the PR's Linux CLI native-function hook and Linux/Windows persistent SDK MCP workflows. The one-shot MCP workflow still returns an output-validation error on both hosts. Other reproduced issues concern availability, script-message provenance, cancellation retention/lifecycle facts, remote cleanup retry ownership, and optional-absent source builds; the keepalive-unit mismatch is confirmed from pinned producer source. The existing 42 focused tests and static checks pass despite these gaps. Remote removal failure used a production adapter seam; macOS and real remote/auth flows remain unverified. Windows online npm was denied EACCES, so the Windows runtime proof used verified official offline components and exactly matching existing dependency versions.

Main was refreshed to bddddccd and its runtime build passed within the 2304 MiB family-RSS budget. The #1563 memory reproducer remains verified at its recorded exact 8c47a9ce/published 6.3.0 baselines; this review does not establish a memory fix on the newer main. #1565 is a related resource-limit proposal.

Removed this review's owned installed components, worktree/build outputs, and archives: 343,422,960 logical bytes (~328 MiB), including 130 Windows junctions removed without touching shared dependencies. Compact reproduction reports/scripts and original PR history are retained. No owned heavy lane remains. #1065 remains active and #740 remains deferred.

<!-- gh-comment-id:6099025577 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Completed the user-requested review and actual Frida installation/runtime verification for #1359 at `4e766550`. [Eight inline findings and verification details](https://github.com/morluto/rea/pull/1359#pullrequestreview-5479514773) are published as changes requested. Real native Frida 17.23.2 works through the PR's Linux CLI native-function hook and Linux/Windows persistent SDK MCP workflows. The one-shot MCP workflow still returns an output-validation error on both hosts. Other reproduced issues concern availability, script-message provenance, cancellation retention/lifecycle facts, remote cleanup retry ownership, and optional-absent source builds; the keepalive-unit mismatch is confirmed from pinned producer source. The existing 42 focused tests and static checks pass despite these gaps. Remote removal failure used a production adapter seam; macOS and real remote/auth flows remain unverified. Windows online npm was denied `EACCES`, so the Windows runtime proof used verified official offline components and exactly matching existing dependency versions. Main was refreshed to `bddddccd` and its runtime build passed within the 2304 MiB family-RSS budget. The #1563 memory reproducer remains verified at its recorded exact `8c47a9ce`/published 6.3.0 baselines; this review does not establish a memory fix on the newer main. #1565 is a related resource-limit proposal. Removed this review's owned installed components, worktree/build outputs, and archives: 343,422,960 logical bytes (~328 MiB), including 130 Windows junctions removed without touching shared dependencies. Compact reproduction reports/scripts and original PR history are retained. No owned heavy lane remains. #1065 remains active and #740 remains deferred.
bsakaguchi commented 2026-10-15 18:24:40 +00:00
Author
Owner
Copy link

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

Current maintenance checkpoint: main is integrated through c1217e71; #1601 is at 03994825c118ced5eef90d62d5757c49d76147bd. The allocation changes and independent ancestry-cache follow-up are implemented and verified; final-head CI is still running, so the PR is not merged yet. The subsequent cache fix addresses a measured repeated-ancestry regression while retaining on-demand allocation.

Real public Claude Code 2.1.296 input remains the decisive memory case. The 4,762,637-byte member completes production domain semantics at 768 MiB with unchanged complete IR (256,300,420 bytes, SHA256 c109f190e1fb1719b73705096730bf4876338d191a9a07d88e3f6eaed019df04). Actual 170-tool pinned-SDK MCP at 1024 MiB passes retained-result selected views, exact-node trace, close/stale-reference, next analysis and ping. The full 2,351-file CLI still exits 134 at the same member at 1024 MiB. #1563 remains open; details: https://github.com/morluto/rea/issues/1563#issuecomment-6100488689 . No general throughput or billed-token improvement is claimed.

The requested #1359 review and actual Linux/Windows component installation/runtime testing are complete: https://github.com/morluto/rea/pull/1359#pullrequestreview-5479514773 . The original head 4e766550 is unchanged and still has 8 findings, including 2 P1 findings, with CHANGES_REQUESTED. Windows work was under D:\tmp\rea; remote-server/macOS proof gaps remain explicit. Installed private components/builds were cleaned as previously reported.

Newly verified Git import regression #1609 was filed with labels, then closed after independently verifying the existing main repair through the actual CLI and real Git/worktree boundaries. Streaming JSON's invalid-input assertion was stale; valid oversized and true bounded-memory cases pass. Main's snapshot-stream cleanup repair also passes all 33 JADX subprocess-boundary cases locally; this is not new real JADX verification.

Latest remaining status: #1462 is CLOSED; upstream typescript-sdk #2997, #1563, #1565 and private-bundle #1387 remain OPEN. #1253 now has PR #1583, which still needs independent Linux runtime review. #1048/#1247/#1441 retain the previously stated proof gaps. #740 remains deferred. This broad roadmap is not complete.

This continuation cleaned 5,515,507 logical bytes of owned duplicate/intermediate files; later single-module reruns used a hardlink instead of another payload copy, and that alias is now removed. The original extracted sample, compact receipts and useful shared runtime remain. All 2,589 original extracted file digests match; protected files and other worktrees were preserved.

<!-- gh-comment-id:6100523536 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): Current maintenance checkpoint: main is integrated through `c1217e71`; #1601 is at `03994825c118ced5eef90d62d5757c49d76147bd`. The allocation changes and independent ancestry-cache follow-up are implemented and verified; final-head CI is still running, so the PR is not merged yet. The subsequent cache fix addresses a measured repeated-ancestry regression while retaining on-demand allocation. Real public Claude Code 2.1.296 input remains the decisive memory case. The 4,762,637-byte member completes production domain semantics at 768 MiB with unchanged complete IR (256,300,420 bytes, SHA256 `c109f190e1fb1719b73705096730bf4876338d191a9a07d88e3f6eaed019df04`). Actual 170-tool pinned-SDK MCP at 1024 MiB passes retained-result selected views, exact-node trace, close/stale-reference, next analysis and ping. The full 2,351-file CLI still exits 134 at the same member at 1024 MiB. #1563 remains open; details: https://github.com/morluto/rea/issues/1563#issuecomment-6100488689 . No general throughput or billed-token improvement is claimed. The requested #1359 review and actual Linux/Windows component installation/runtime testing are complete: https://github.com/morluto/rea/pull/1359#pullrequestreview-5479514773 . The original head `4e766550` is unchanged and still has 8 findings, including 2 P1 findings, with CHANGES_REQUESTED. Windows work was under `D:\tmp\rea`; remote-server/macOS proof gaps remain explicit. Installed private components/builds were cleaned as previously reported. Newly verified Git import regression #1609 was filed with labels, then closed after independently verifying the existing main repair through the actual CLI and real Git/worktree boundaries. Streaming JSON's invalid-input assertion was stale; valid oversized and true bounded-memory cases pass. Main's snapshot-stream cleanup repair also passes all 33 JADX subprocess-boundary cases locally; this is not new real JADX verification. Latest remaining status: #1462 is CLOSED; upstream typescript-sdk #2997, #1563, #1565 and private-bundle #1387 remain OPEN. #1253 now has PR #1583, which still needs independent Linux runtime review. #1048/#1247/#1441 retain the previously stated proof gaps. #740 remains deferred. This broad roadmap is not complete. This continuation cleaned 5,515,507 logical bytes of owned duplicate/intermediate files; later single-module reruns used a hardlink instead of another payload copy, and that alias is now removed. The original extracted sample, compact receipts and useful shared runtime remain. All 2,589 original extracted file digests match; protected files and other worktrees were preserved.
bsakaguchi commented 2026-10-15 18:24:40 +00:00
Author
Owner
Copy link

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

#1601 is merged as b28c0337: all 20 final-head checks passed, including full CI and real JavaScript recovery. The allocation and lexical-scope cache changes preserve the separately recorded semantic identities and contributor follow-up history. Main's #1618 and #1616 maintenance/cleanup fixes are also merged; the overlapping test-only #1617 was closed as superseded.

The complete original public-memory case still fails after the merge. Fresh main b28c0337: real CLI at 1,024 MiB exits 134 with zero stdout; real 170-tool MCP at 768 MiB loses the connection and cannot answer the next ping or small analysis. All 2,589 source digests remain unchanged. #1563/#1565 need a bounded analysis and representation boundary; the diagnostic worker experiment is not a product fix. #1610 remains blocked by the actual full-directory and below-cutoff reproductions.

Requested #1359 installation/runtime review is complete on Linux and Windows at unchanged 4e766550: basic native CLI and persistent MCP workflows run, but 8 findings including 2 P1 defects require changes. Review: https://github.com/morluto/rea/pull/1359#pullrequestreview-5479514773 . Windows work stayed under D:\tmp\rea; installed review/build copies were cleaned. macOS and real remote-device behavior remain unverified.

#1253's #1583 has a new head 1cb45255 and conflicts with current main; independent Linux runtime verification is still pending. SDK2997, #1048, #1247, private #1387 and real-JADX #1441 retain their previously recorded gaps. #1462 is closed; #740 remains deferred.

Owned temporary checkouts, synthetic inputs and build/component copies were cleaned. Original reproducer inputs, compact receipts, useful runtime/caches and shared dependencies remain. #1065 remains active.

<!-- gh-comment-id:6101160654 --> @N0zoM1z0 commented on GitHub (Oct 10, 2026): #1601 is merged as `b28c0337`: all 20 final-head checks passed, including full CI and real JavaScript recovery. The allocation and lexical-scope cache changes preserve the separately recorded semantic identities and contributor follow-up history. Main's #1618 and #1616 maintenance/cleanup fixes are also merged; the overlapping test-only #1617 was closed as superseded. The complete original public-memory case still fails after the merge. Fresh main `b28c0337`: real CLI at 1,024 MiB exits 134 with zero stdout; real 170-tool MCP at 768 MiB loses the connection and cannot answer the next ping or small analysis. All 2,589 source digests remain unchanged. #1563/#1565 need a bounded analysis and representation boundary; the diagnostic worker experiment is not a product fix. #1610 remains blocked by the actual full-directory and below-cutoff reproductions. Requested #1359 installation/runtime review is complete on Linux and Windows at unchanged `4e766550`: basic native CLI and persistent MCP workflows run, but 8 findings including 2 P1 defects require changes. Review: https://github.com/morluto/rea/pull/1359#pullrequestreview-5479514773 . Windows work stayed under `D:\tmp\rea`; installed review/build copies were cleaned. macOS and real remote-device behavior remain unverified. #1253's #1583 has a new head `1cb45255` and conflicts with current main; independent Linux runtime verification is still pending. SDK2997, #1048, #1247, private #1387 and real-JADX #1441 retain their previously recorded gaps. #1462 is closed; #740 remains deferred. Owned temporary checkouts, synthetic inputs and build/component copies were cleaned. Original reproducer inputs, compact receipts, useful runtime/caches and shared dependencies remain. #1065 remains active.
bsakaguchi commented 2026-10-15 18:24:40 +00:00
Author
Owner
Copy link

@CassieFox23 commented on GitHub (Oct 10, 2026):

TL;DR: I reran my cancel test on current main on an idle machine. The server now stops about 15 ms after a cancel, where it took 2.6 s before. One gap is left: a cancel in the last 50 ms still lets the reply go out.

My first post on #1065 tested 8550913cd (#1407) while other test suites shared the machine. This post tests 69fe5b601. That is 225 commits later, and it includes #1601. The fixture is the same: the issue's generator at 300 and 1,200 functions. Each case ran 5 times. The machine was idle: on average about 1.5 jobs were running or waiting for a CPU thread, out of 24 threads. Most of that is the test itself.

  • No long block any more. At 1,200 functions the first stage lasted 2.8 s and froze the server for about 3 s. It now lasts 1.5 s. The longest freeze I saw is about 150 ms, in a run with the preload. The worst ping with no cancel was 55 ms. It was 2,317 ms.
  • The server reads the cancel at once. A cancel 200 ms after progress stops the server 15 ms later at 1,200 functions. It was 2,632 ms. At 300 functions it is 12 ms. It was 589 ms.
  • A timed run is faster too. No cancel, 1,200 functions: 3,123 ms, down from 4,458 ms. The old run shared the machine, so I can't say how much of that is the code.
  • One race is left. Two of 50 cancel runs hit it. The server had finished. The cancel arrived. The reply went out about 50 ms after the server logged "done". The client dropped it and the next call worked.
  • Nothing else changed. No ping failed. No child process or temp file was left. The next call worked every time. Node 22.23.1 and 26.11.1 act like 24.18.0.

Medians of 5 runs on Node 24.18.0. Times are ms from the tool call.

Case Cancel sent Server stop Stop minus cancel Reply sent after cancel
300, 200 ms after progress 206 217 12 0 of 5
300, at 460 461 498 37 0 of 5
300, at 710 711 720 8 0 of 5
300, at 820 820 828 6 0 of 5
300, at 900 900 904 4 1 of 5
1,200, 200 ms after progress 205 220 15 0 of 5
1,200, at 1,560 1,561 1,569 9 0 of 5
1,200, at 2,230 2,231 2,237 6 0 of 5
1,200, at 2,810 2,811 2,819 8 0 of 5
1,200, at 3,060 3,061 3,063 3 1 of 5

I moved the offsets. No cancel now ends at 3,123 ms (1,200) and 915 ms (300). So I used the same shares of that time: 50, 90 and 98 percent. I also kept the old 2,230 and 710. The old 4,010, 4,370 and 1,280 fall after the work ends, so I skipped them.

On Node 22.23.1, 24.18.0 and 26.11.1, the 1,200 case with a cancel 200 ms after progress stops 7, 15 and 12 ms after the cancel. No reply went out in any of the 11 runs.

Not run

  • Which of the 225 commits removed the block. I did not bisect.
  • The old head 8550913cd (#1407) on an idle machine. So I can't split the speed-up between the code and the load.
  • Step 4, the CLI compare, and the 6.0.0 package.
  • The 6.3.0 release. I did not rerun it.
  • A real app, many files at once, export, or native work.
  • Windows or macOS.
  • A heap snapshot, and the Evidence check after a cancel.
Min to max of 5 runs, and no-cancel numbers

Cancel, Node 24.18.0, median [min–max]:

Case Cancel sent Server stop Stop minus cancel Worst ping after cancel
300, 200 ms after progress 206 [204–209] 217 [209–224] 12 [3–16] 1 [1–5]
300, at 460 461 [460–462] 498 [473–503] 37 [12–43] 1 [1–2]
300, at 710 711 [711–712] 720 [717–723] 8 [7–11] 1 [1–1]
300, at 820 820 [820–822] 828 [825–834] 6 [4–12] 1 [1–1]
300, at 900 900 [900–901] 904 [895–910] 4 [-5–10] 1 [1–2]
1,200, 200 ms after progress 205 [204–209] 220 [214–221] 15 [7–17] 4 [2–5]
1,200, at 1,560 1,561 [1,561–1,562] 1,569 [1,566–1,574] 9 [5–13] 1 [1–1]
1,200, at 2,230 2,231 [2,230–2,231] 2,237 [2,234–2,238] 6 [4–7] 1 [1–1]
1,200, at 2,810 2,811 [2,810–2,811] 2,819 [2,814–2,821] 8 [4–11] 1 [1–1]
1,200, at 3,060 3,061 [3,060–3,061] 3,063 [3,049–3,067] 3 [-12–6] 1 [1–1]

A negative number means the server had finished before the cancel arrived. Those are the two race runs. In the 300-function case at 460, the stop came 37 ms late. I did not instrument that case.

No cancel, Node 24.18.0, median [min–max]:

Size Server analysis Worst ping Median ping Peak RSS Next call
300 915 [897–918] 9 [7–14] 7.5 [1.8–10.1] 760 MiB 16 ms
1,200 3,123 [3,052–3,269] 55 [13–82] 5.0 [3.9–7.3] 902 MiB 21 ms

First stage, 1,200 functions: 1,466 [1,451–1,547] ms. Build graph: 1,133 [1,071–1,200] ms. Validate: 232 [226–237] ms. Hash Evidence: 270 [268–294] ms. These come from the progress messages. This run has no separate seal message.

Cancel 200 ms after progress, 1,200 functions, by Node (3 runs each for 22 and 26):

Node 22.23.1 Node 24.18.0 (5 runs) Node 26.11.1
Stop minus cancel 7 [4–10] 15 [7–17] 12 [4–13]
Reply sent after cancel 0 of 3 0 of 5 0 of 3
Next call OK, 26 ms OK, 21 ms OK, 43 ms

Every run: no child process, no temp file left, no ping failed.

The two races
Run Server logged "done" Cancel sent Reply on the wire
1,200, at 3,060 3,049 3,061 3,104
300, at 900 895 900 946

The reply followed the "done" line by about 50 ms in both runs. That is roughly 2 percent of the 1,200 run and 5 percent of the 300 run. I aimed the cancels at the end, so two of 50 is not a rate.

Timeline, 1,200 functions, cancel 200 ms after progress

This run used a small preload that logs when the server SDK aborts the request. It does not change REA code. I took it after the timed runs, with other work starting on the machine, so it is not an idle run.

ms Where Event
0 client tool call starts
4 server progress: start of analysis
204 client sends notifications/cancelled
209 server SDK aborts the request
210 server tool done, status error, no reply sent
3,300 client next binary_session OK (79 ms)

In the first post, the same case read the cancel at 3,142 ms, after a 3,132 ms freeze. A no-cancel instrumented run now shows two freezes over 120 ms, of 122 and 156 ms. Both sit near the end of the first stage.

Load

Before each run, I waited while the one-minute load average was over 2.0. Two runs waited 15 s once. The load at the start of the 60 Node 24 runs was 0.90 to 2.00, median 1.52. In plain words, on average about 1.5 jobs were running or waiting for a CPU thread, out of 24 threads. Most of that is the test itself. The first post saw 6 to 13.

Commands 
git -C rea.git archive 69fe5b6010f2658d302cf2c6e6a8b770205da080 | tar -x -C src-main
cd src-main && npm ci && npm run build:cached
# client.mjs is the harness script, available on request
( ulimit -c 0; timeout 1200 taskset -c 2,3 node client.mjs --root src-main \
  --fixture f1200/fixture --mode after-progress --cancel-ms 200 \
  --server-node-args --max-old-space-size=1536 --out result.json )
Test setup
  • Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
  • CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads (runs pinned to 2)
  • RAM: 32 GB
  • Node: 22.23.1, 24.18.0, 26.11.1
  • Head: 69fe5b601. Base: 8550913cd.
  • Other: MCP SDK client and server 2.3.1, 1,536 MiB server heap

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

<!-- gh-comment-id:6102662188 --> @CassieFox23 commented on GitHub (Oct 10, 2026): **TL;DR:** I reran my cancel test on current main on an idle machine. The server now stops about 15 ms after a cancel, where it took 2.6 s before. One gap is left: a cancel in the last 50 ms still lets the reply go out. My first post on #1065 tested 8550913cd (#1407) while other test suites shared the machine. This post tests 69fe5b601. That is 225 commits later, and it includes #1601. The fixture is the same: the issue's generator at 300 and 1,200 functions. Each case ran 5 times. The machine was idle: on average about 1.5 jobs were running or waiting for a CPU thread, out of 24 threads. Most of that is the test itself. - **No long block any more.** At 1,200 functions the first stage lasted 2.8 s and froze the server for about 3 s. It now lasts 1.5 s. The longest freeze I saw is about 150 ms, in a run with the preload. The worst ping with no cancel was 55 ms. It was 2,317 ms. - **The server reads the cancel at once.** A cancel 200 ms after progress stops the server 15 ms later at 1,200 functions. It was 2,632 ms. At 300 functions it is 12 ms. It was 589 ms. - **A timed run is faster too.** No cancel, 1,200 functions: 3,123 ms, down from 4,458 ms. The old run shared the machine, so I can't say how much of that is the code. - **One race is left.** Two of 50 cancel runs hit it. The server had finished. The cancel arrived. The reply went out about 50 ms after the server logged "done". The client dropped it and the next call worked. - **Nothing else changed.** No ping failed. No child process or temp file was left. The next call worked every time. Node 22.23.1 and 26.11.1 act like 24.18.0. Medians of 5 runs on Node 24.18.0. Times are ms from the tool call. | Case | Cancel sent | Server stop | Stop minus cancel | Reply sent after cancel | | --- | --- | --- | --- | --- | | 300, 200 ms after progress | 206 | 217 | 12 | 0 of 5 | | 300, at 460 | 461 | 498 | 37 | 0 of 5 | | 300, at 710 | 711 | 720 | 8 | 0 of 5 | | 300, at 820 | 820 | 828 | 6 | 0 of 5 | | 300, at 900 | 900 | 904 | 4 | 1 of 5 | | 1,200, 200 ms after progress | 205 | 220 | 15 | 0 of 5 | | 1,200, at 1,560 | 1,561 | 1,569 | 9 | 0 of 5 | | 1,200, at 2,230 | 2,231 | 2,237 | 6 | 0 of 5 | | 1,200, at 2,810 | 2,811 | 2,819 | 8 | 0 of 5 | | 1,200, at 3,060 | 3,061 | 3,063 | 3 | 1 of 5 | I moved the offsets. No cancel now ends at 3,123 ms (1,200) and 915 ms (300). So I used the same shares of that time: 50, 90 and 98 percent. I also kept the old 2,230 and 710. The old 4,010, 4,370 and 1,280 fall after the work ends, so I skipped them. On Node 22.23.1, 24.18.0 and 26.11.1, the 1,200 case with a cancel 200 ms after progress stops 7, 15 and 12 ms after the cancel. No reply went out in any of the 11 runs. ### Not run - Which of the 225 commits removed the block. I did not bisect. - The old head 8550913cd (#1407) on an idle machine. So I can't split the speed-up between the code and the load. - Step 4, the CLI compare, and the 6.0.0 package. - The 6.3.0 release. I did not rerun it. - A real app, many files at once, export, or native work. - Windows or macOS. - A heap snapshot, and the Evidence check after a cancel. <details> <summary>Min to max of 5 runs, and no-cancel numbers</summary> Cancel, Node 24.18.0, median [min–max]: | Case | Cancel sent | Server stop | Stop minus cancel | Worst ping after cancel | | --- | --- | --- | --- | --- | | 300, 200 ms after progress | 206 [204–209] | 217 [209–224] | 12 [3–16] | 1 [1–5] | | 300, at 460 | 461 [460–462] | 498 [473–503] | 37 [12–43] | 1 [1–2] | | 300, at 710 | 711 [711–712] | 720 [717–723] | 8 [7–11] | 1 [1–1] | | 300, at 820 | 820 [820–822] | 828 [825–834] | 6 [4–12] | 1 [1–1] | | 300, at 900 | 900 [900–901] | 904 [895–910] | 4 [-5–10] | 1 [1–2] | | 1,200, 200 ms after progress | 205 [204–209] | 220 [214–221] | 15 [7–17] | 4 [2–5] | | 1,200, at 1,560 | 1,561 [1,561–1,562] | 1,569 [1,566–1,574] | 9 [5–13] | 1 [1–1] | | 1,200, at 2,230 | 2,231 [2,230–2,231] | 2,237 [2,234–2,238] | 6 [4–7] | 1 [1–1] | | 1,200, at 2,810 | 2,811 [2,810–2,811] | 2,819 [2,814–2,821] | 8 [4–11] | 1 [1–1] | | 1,200, at 3,060 | 3,061 [3,060–3,061] | 3,063 [3,049–3,067] | 3 [-12–6] | 1 [1–1] | A negative number means the server had finished before the cancel arrived. Those are the two race runs. In the 300-function case at 460, the stop came 37 ms late. I did not instrument that case. No cancel, Node 24.18.0, median [min–max]: | Size | Server analysis | Worst ping | Median ping | Peak RSS | Next call | | --- | --- | --- | --- | --- | --- | | 300 | 915 [897–918] | 9 [7–14] | 7.5 [1.8–10.1] | 760 MiB | 16 ms | | 1,200 | 3,123 [3,052–3,269] | 55 [13–82] | 5.0 [3.9–7.3] | 902 MiB | 21 ms | First stage, 1,200 functions: 1,466 [1,451–1,547] ms. Build graph: 1,133 [1,071–1,200] ms. Validate: 232 [226–237] ms. Hash Evidence: 270 [268–294] ms. These come from the progress messages. This run has no separate seal message. Cancel 200 ms after progress, 1,200 functions, by Node (3 runs each for 22 and 26): | | Node 22.23.1 | Node 24.18.0 (5 runs) | Node 26.11.1 | | --- | --- | --- | --- | | Stop minus cancel | 7 [4–10] | 15 [7–17] | 12 [4–13] | | Reply sent after cancel | 0 of 3 | 0 of 5 | 0 of 3 | | Next call | OK, 26 ms | OK, 21 ms | OK, 43 ms | Every run: no child process, no temp file left, no ping failed. </details> <details> <summary>The two races</summary> | Run | Server logged "done" | Cancel sent | Reply on the wire | | --- | --- | --- | --- | | 1,200, at 3,060 | 3,049 | 3,061 | 3,104 | | 300, at 900 | 895 | 900 | 946 | The reply followed the "done" line by about 50 ms in both runs. That is roughly 2 percent of the 1,200 run and 5 percent of the 300 run. I aimed the cancels at the end, so two of 50 is not a rate. </details> <details> <summary>Timeline, 1,200 functions, cancel 200 ms after progress</summary> This run used a small preload that logs when the server SDK aborts the request. It does not change REA code. I took it after the timed runs, with other work starting on the machine, so it is not an idle run. | ms | Where | Event | | ---: | --- | --- | | 0 | client | tool call starts | | 4 | server | progress: start of analysis | | 204 | client | sends `notifications/cancelled` | | 209 | server | SDK aborts the request | | 210 | server | tool done, status error, no reply sent | | 3,300 | client | next `binary_session` OK (79 ms) | In the first post, the same case read the cancel at 3,142 ms, after a 3,132 ms freeze. A no-cancel instrumented run now shows two freezes over 120 ms, of 122 and 156 ms. Both sit near the end of the first stage. </details> <details> <summary>Load</summary> Before each run, I waited while the one-minute load average was over 2.0. Two runs waited 15 s once. The load at the start of the 60 Node 24 runs was 0.90 to 2.00, median 1.52. In plain words, on average about 1.5 jobs were running or waiting for a CPU thread, out of 24 threads. Most of that is the test itself. The first post saw 6 to 13. </details> <details> <summary>Commands</summary> ```sh git -C rea.git archive 69fe5b6010f2658d302cf2c6e6a8b770205da080 | tar -x -C src-main cd src-main && npm ci && npm run build:cached # client.mjs is the harness script, available on request ( ulimit -c 0; timeout 1200 taskset -c 2,3 node client.mjs --root src-main \ --fixture f1200/fixture --mode after-progress --cancel-ms 200 \ --server-node-args --max-old-space-size=1536 --out result.json ) ``` </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.9 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads (runs pinned to 2) - RAM: 32 GB - Node: 22.23.1, 24.18.0, 26.11.1 - Head: 69fe5b601. Base: 8550913cd. - Other: MCP SDK client and server 2.3.1, 1,536 MiB server heap </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊
bsakaguchi commented 2026-10-15 18:24:40 +00:00
Author
Owner
Copy link

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

Memory and cancellation checkpoint: main is now 890dfa49f60a66e819e86ba29f3728f2e1e1827b. The owned JavaScript analyzer worker / bounded retained evidence fix is merged in #1651; preparation cancellation is corrected in main, and #1654 preserves a failed owned cleanup retry instead of hiding it behind a completed cancellation. All 19 exact-final-head checks for #1654 passed before its SHA-guarded merge. #1563, #1565 and #1653 are closed.

Real public memory input (the previously linked Bun application) was exercised through the actual 170-tool pinned-SDK MCP, with separate 768 MiB server and worker heaps. All 2,351 relevant files were inventoried; all 2,346 JavaScript files parsed, 9,291,366 AST nodes and 194,224 findings retained, zero parse failures. The analysis took about 176 seconds; sampled process-family RSS peaked at 1.70 GiB. All 2,589 original file digests are unchanged. The main MCP process survived, and retained summary/page/item, exact-node tracing, close/stale reference, next small analysis and ping passed. The default inline response exceeds the existing transport budget and reports a resource constraint with the retained Evidence reference. Application/deep semantic coverage is explicitly partial: complete static inventory does not establish complete semantic analysis, a general throughput improvement or a globally bounded process RSS.

A separate dense 1,600,024-byte control really exhausted the 512 MiB owned worker during semantics. Earlier static observations survived, the parent answered the public retained-result workflows and subsequent analysis, and no owned worker directories remained. A real Notion ASAR at 768/768 MiB completed its partial result with all 69 JavaScript sources parsed and 98 control pings (maximum observed latency 13.31 ms). This lower-budget partial result is not a like-for-like full-semantics speed comparison with the earlier larger-heap run. Real CLI cancellation returned exit 130 and complete JSON partial Evidence; retained observations and input digests were preserved.

The final #1654 tarball (ba885214, SHA256 38edbee085b1220e0d417d187ce0364e6133ee7619bf8bf9900c2615d403a98b) was independently installed with production dependencies on native Windows in an isolated Windows verification directory, using existing supported Node 22.19.0. Actual CLI JSON and pinned-SDK MCP pass: 170 tools, preparation cancellation with retained partial Evidence, timeout/partial views, later successful analysis, item/page lookup, trace, close and ping. Source hashes are unchanged and no owned worker roots remain. Installation used verified public lockfile tarballs offline because the initial host registry fetch stalled; this does not claim fresh online Windows installation worked. The cleanup-failure regression uses a real owned Node worker and an injected failing cleanup callback; an actual OS cleanup denial was not observed. Linux package verification and focused public/boundary checks are also recorded; no new real Hopper/Ghidra claim is made by this Node lifecycle change.

Requested #1359 install/runtime review is complete at unchanged 4e766550: real local Frida CLI and persistent MCP run on Linux and Windows, but 8 findings including 2 P1 defects still require changes. The reviewed head remains conflicted and CHANGES_REQUESTED: https://github.com/morluto/rea/pull/1359#pullrequestreview-5479514773 . Remote-server/authentication and macOS verification gaps remain explicit. #1610 is also unchanged/conflicted/CHANGES_REQUESTED; its fixed source-byte cutoff does not cover the below-cutoff dense failure.

Latest remaining work: improve bounded deep semantic coverage and agent result consumption; upstream typescript-sdk #2997 is still open. Private-input #1387 remains open and needs its own confirmation. #1253/#1583 now has head 0aea0d17 and still needs independent runtime review; #1632 and #1650 track current discovery/setup usability problems. #1251, #1252, #1262 and #1462 are closed, so they are no longer listed as open residuals. npm's latest published version remains 6.3.0; main's fixes are not yet a released npm update. #740 remains deferred, and this broader #1065 roadmap remains active.

This final installation/verification cleanup removed 136,296,393 logical bytes (~130 MiB) of owned Windows install/cache/temp files, tarballs and duplicate/synthetic inputs. Original samples, compact receipts/digests, scripts, useful shared runtime/dependencies and protected user files remain intact.

<!-- gh-comment-id:6103599843 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): Memory and cancellation checkpoint: main is now `890dfa49f60a66e819e86ba29f3728f2e1e1827b`. The owned JavaScript analyzer worker / bounded retained evidence fix is merged in #1651; preparation cancellation is corrected in main, and #1654 preserves a failed owned cleanup retry instead of hiding it behind a completed cancellation. All 19 exact-final-head checks for #1654 passed before its SHA-guarded merge. #1563, #1565 and #1653 are closed. Real public memory input (the previously linked Bun application) was exercised through the actual 170-tool pinned-SDK MCP, with separate 768 MiB server and worker heaps. All 2,351 relevant files were inventoried; all 2,346 JavaScript files parsed, 9,291,366 AST nodes and 194,224 findings retained, zero parse failures. The analysis took about 176 seconds; sampled process-family RSS peaked at 1.70 GiB. All 2,589 original file digests are unchanged. The main MCP process survived, and retained summary/page/item, exact-node tracing, close/stale reference, next small analysis and ping passed. The default inline response exceeds the existing transport budget and reports a resource constraint with the retained Evidence reference. **Application/deep semantic coverage is explicitly partial**: complete static inventory does not establish complete semantic analysis, a general throughput improvement or a globally bounded process RSS. A separate dense 1,600,024-byte control really exhausted the 512 MiB owned worker during semantics. Earlier static observations survived, the parent answered the public retained-result workflows and subsequent analysis, and no owned worker directories remained. A real Notion ASAR at 768/768 MiB completed its partial result with all 69 JavaScript sources parsed and 98 control pings (maximum observed latency 13.31 ms). This lower-budget partial result is not a like-for-like full-semantics speed comparison with the earlier larger-heap run. Real CLI cancellation returned exit 130 and complete JSON partial Evidence; retained observations and input digests were preserved. The final #1654 tarball (`ba885214`, SHA256 `38edbee085b1220e0d417d187ce0364e6133ee7619bf8bf9900c2615d403a98b`) was independently installed with production dependencies on native Windows in an isolated Windows verification directory, using existing supported Node 22.19.0. Actual CLI JSON and pinned-SDK MCP pass: 170 tools, preparation cancellation with retained partial Evidence, timeout/partial views, later successful analysis, item/page lookup, trace, close and ping. Source hashes are unchanged and no owned worker roots remain. Installation used verified public lockfile tarballs offline because the initial host registry fetch stalled; this does not claim fresh online Windows installation worked. The cleanup-failure regression uses a real owned Node worker and an injected failing cleanup callback; an actual OS cleanup denial was not observed. Linux package verification and focused public/boundary checks are also recorded; no new real Hopper/Ghidra claim is made by this Node lifecycle change. Requested #1359 install/runtime review is complete at unchanged `4e766550`: real local Frida CLI and persistent MCP run on Linux and Windows, but 8 findings including 2 P1 defects still require changes. The reviewed head remains conflicted and CHANGES_REQUESTED: https://github.com/morluto/rea/pull/1359#pullrequestreview-5479514773 . Remote-server/authentication and macOS verification gaps remain explicit. #1610 is also unchanged/conflicted/CHANGES_REQUESTED; its fixed source-byte cutoff does not cover the below-cutoff dense failure. Latest remaining work: improve bounded deep semantic coverage and agent result consumption; upstream typescript-sdk #2997 is still open. Private-input #1387 remains open and needs its own confirmation. #1253/#1583 now has head `0aea0d17` and still needs independent runtime review; #1632 and #1650 track current discovery/setup usability problems. #1251, #1252, #1262 and #1462 are closed, so they are no longer listed as open residuals. npm's latest published version remains 6.3.0; main's fixes are not yet a released npm update. #740 remains deferred, and this broader #1065 roadmap remains active. This final installation/verification cleanup removed 136,296,393 logical bytes (~130 MiB) of owned Windows install/cache/temp files, tarballs and duplicate/synthetic inputs. Original samples, compact receipts/digests, scripts, useful shared runtime/dependencies and protected user files remain intact.
bsakaguchi commented 2026-10-15 18:24:41 +00:00
Author
Owner
Copy link

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

Process-capture usability follow-up: #1583 is merged after all 31 checks passed on final head e980e6b0. This closes #1253. Optional finalization_ms lets a target write its final report after SIGTERM before a bounded escalation; output, file facts, actual finalizer exit codes, cancellation observations and cleanup uncertainty remain available through CLI/MCP. Initial identity retention now checks captured ownership as well as start identity.

Independent Linux verification passed 250 cases in 13 focused files, plus static/build/docs checks. Real CLI/MCP cases cover cooperative and nonzero exits, forced escalation, cancellation, unchanged default commitments, omitted content digests with explicit reasons, and detached owned cleanup. Representative identity-observation regressions do not manufacture OS PID reuse or signal foreign processes. Windows capture remains unsupported.

A shared acceptance-client improvement avoids compiling additional validators for unused tools while retaining complete schema validation and the normal SDK call path. One identical-runtime before/after pair measured connection plus first call at 13.65 s and 6.44 s; this measures the test helper. Upstream SDK #2997 remains open.

#1065 stays open: arbitrary-client catalog/SDK preparation, real-provider dossier usability, the unavailable original private #1387 bundle, and cold Windows Ghidra analysis still need their own evidence. #740 remains deferred. No release was published. Owned review build artifacts are cleaned after verification; compact receipts remain.

<!-- gh-comment-id:6104435371 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): Process-capture usability follow-up: #1583 is merged after all 31 checks passed on final head `e980e6b0`. This closes #1253. Optional `finalization_ms` lets a target write its final report after SIGTERM before a bounded escalation; output, file facts, actual finalizer exit codes, cancellation observations and cleanup uncertainty remain available through CLI/MCP. Initial identity retention now checks captured ownership as well as start identity. Independent Linux verification passed 250 cases in 13 focused files, plus static/build/docs checks. Real CLI/MCP cases cover cooperative and nonzero exits, forced escalation, cancellation, unchanged default commitments, omitted content digests with explicit reasons, and detached owned cleanup. Representative identity-observation regressions do not manufacture OS PID reuse or signal foreign processes. Windows capture remains unsupported. A shared acceptance-client improvement avoids compiling additional validators for unused tools while retaining complete schema validation and the normal SDK call path. One identical-runtime before/after pair measured connection plus first call at 13.65 s and 6.44 s; this measures the test helper. [Upstream SDK #2997](https://github.com/modelcontextprotocol/typescript-sdk/issues/2997) remains open. #1065 stays open: arbitrary-client catalog/SDK preparation, real-provider dossier usability, the unavailable original private #1387 bundle, and cold Windows Ghidra analysis still need their own evidence. #740 remains deferred. No release was published. Owned review build artifacts are cleaned after verification; compact receipts remain.
bsakaguchi commented 2026-10-15 18:24:41 +00:00
Author
Owner
Copy link

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

Merged #1687 as 89ea2cad1977b73a4ddf5818d54f5bc51cdae2b6 after all 31 checks passed on the reviewed source head 82c6ff66e183f2bae3268a38af46360356cce691.

Flameox 0.2.9 CPU and sampling-heap captures on an owned 29 KB JavaScript source identified cooperative canonical hashing as a REA-owned hotspot. The change reuses exact JSON key encodings within the existing digest-buffer quantum and avoids temporary ordinary member value frames. It also fixes a reproduced domain-continuation error where an omitted pending property discarded the object frame and skipped later properties. Sealed production graphs are immutable; this is not a claim of reproduced production corruption.

Seven randomized paired digest blocks retain complete normalized-result/Evidence/input oracles. Capture-process medians decrease from 1,184.00 ms to 943.54 ms; the paired median difference is -222.62 ms with bootstrap 95% interval [-250.01, -216.98] ms. This is a local digest-workload improvement. The separate five-block full CLI experiment passes all ten semantic oracles but has a timing interval crossing zero, so whole-CLI acceleration and billed-token reductions are not established.

After the merge, the entire code tree was audited against the expected merge, freshly built, and exercised through real public CLI and pinned-SDK stdio MCP on a 6.7 KB source. Complete normalized results and Evidence ID match the baseline, text/structured output agrees, input bytes remain unchanged and a subsequent ping succeeds. The 29 KB full CLI semantic/progress oracle also passes. Local coverage comprises 81 related tests and eight static/documentation/architecture/discovery gates. No local real Hopper/Ghidra, Electron/browser target runtime or full Bun-directory claim is added.

Owned generated builds and the temporary Flameox environment are cleaned; native profiles, receipts and losslessly compressed full public outputs remain available locally. #1065 remains open for the broader roadmap.

<!-- gh-comment-id:6105127949 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): Merged #1687 as `89ea2cad1977b73a4ddf5818d54f5bc51cdae2b6` after all 31 checks passed on the reviewed source head `82c6ff66e183f2bae3268a38af46360356cce691`. Flameox 0.2.9 CPU and sampling-heap captures on an owned 29 KB JavaScript source identified cooperative canonical hashing as a REA-owned hotspot. The change reuses exact JSON key encodings within the existing digest-buffer quantum and avoids temporary ordinary member value frames. It also fixes a reproduced domain-continuation error where an omitted pending property discarded the object frame and skipped later properties. Sealed production graphs are immutable; this is not a claim of reproduced production corruption. Seven randomized paired digest blocks retain complete normalized-result/Evidence/input oracles. Capture-process medians decrease from 1,184.00 ms to 943.54 ms; the paired median difference is -222.62 ms with bootstrap 95% interval [-250.01, -216.98] ms. This is a local digest-workload improvement. The separate five-block full CLI experiment passes all ten semantic oracles but has a timing interval crossing zero, so whole-CLI acceleration and billed-token reductions are not established. After the merge, the entire code tree was audited against the expected merge, freshly built, and exercised through real public CLI and pinned-SDK stdio MCP on a 6.7 KB source. Complete normalized results and Evidence ID match the baseline, text/structured output agrees, input bytes remain unchanged and a subsequent ping succeeds. The 29 KB full CLI semantic/progress oracle also passes. Local coverage comprises 81 related tests and eight static/documentation/architecture/discovery gates. No local real Hopper/Ghidra, Electron/browser target runtime or full Bun-directory claim is added. Owned generated builds and the temporary Flameox environment are cleaned; native profiles, receipts and losslessly compressed full public outputs remain available locally. #1065 remains open for the broader roadmap.
bsakaguchi commented 2026-10-15 18:24:41 +00:00
Author
Owner
Copy link

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

Current performance/usability follow-up:

  • #1682 is merged: retained-record discovery can return lightweight summaries and exact filters, so oversized native Evidence can be located and inspected through selected views. Final-head CI completed with all 31 jobs successful; #1247 is closed.
  • #1694 proposes the next narrow fix, using actual Flameox profiling: fuse streamed JSON token handling. Five paired 18.54 MB real-snapshot workloads all passed a full canonical-content/Evidence identity oracle; median paired total-process wall-time difference was −3.63 s. Temporary sampled allocations decreased substantially, without changing capacity admission or completeness semantics. Final-head checks and Windows verification are in progress.
  • The independently reported Windows startup I/O issue #1685 has since been closed by merged #1691. Our earlier Windows profile applies to the pre-fix runtime; the merged change has not yet been timed by this batch.

Remaining evidence gaps include the 83 MB snapshot capacity case (#1680), cold Ghidra lifecycle/progress (#1048), client SDK output-schema compilation, and the original private memory-heavy target from #1387. Public controls do not prove that private target fixed. #740 remains deferred.

#1359 still has the same reviewed head (4e766550), remains open/conflicting, and retains the requested changes from the actual Linux/Windows installed Frida review; no new head needs reinstallation yet.

<!-- gh-comment-id:6105315547 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): Current performance/usability follow-up: - #1682 is merged: retained-record discovery can return lightweight summaries and exact filters, so oversized native Evidence can be located and inspected through selected views. Final-head CI completed with all 31 jobs successful; #1247 is closed. - #1694 proposes the next narrow fix, using actual Flameox profiling: fuse streamed JSON token handling. Five paired 18.54 MB real-snapshot workloads all passed a full canonical-content/Evidence identity oracle; median paired total-process wall-time difference was −3.63 s. Temporary sampled allocations decreased substantially, without changing capacity admission or completeness semantics. Final-head checks and Windows verification are in progress. - The independently reported Windows startup I/O issue #1685 has since been closed by merged #1691. Our earlier Windows profile applies to the pre-fix runtime; the merged change has not yet been timed by this batch. Remaining evidence gaps include the 83 MB snapshot capacity case (#1680), cold Ghidra lifecycle/progress (#1048), client SDK output-schema compilation, and the original private memory-heavy target from #1387. Public controls do not prove that private target fixed. #740 remains deferred. #1359 still has the same reviewed head (`4e766550`), remains open/conflicting, and retains the requested changes from the actual Linux/Windows installed Frida review; no new head needs reinstallation yet.
bsakaguchi commented 2026-10-15 18:24:41 +00:00
Author
Owner
Copy link

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

#1694 is merged as 13e03e94 after exact final-head CI 31/31 success and local 30 focused tests, type/lint, Knip and formatting checks.

The change removes per-token async work from streamed JSON handling. Actual Flameox 0.2.9 profiling and five paired 18.54 MB real-snapshot workloads passed all complete canonical-content/Evidence identity oracles; median paired whole-process wall-time improvement was 3.63 s. Scoped cumulative sampled allocation estimates fell from 10.77 to 3.17 GB (single captures, collected objects included; not peak RSS). The merged reader source and compiled file match the measured candidate.

Complete source-built Windows package verification also passed: real Ghidra analysis, unique snapshot save, fresh MCP process rejecting the old reference before import, streamed snapshot restore, exact retained Evidence/view identity, CLI/MCP summary parity, healthy ping and clean owned-resource shutdown. Two CPUs, Node heap 768 MiB, JVM 512 MiB; target unchanged. This is not a published release or a Windows large-payload benchmark.

#1680 remains open for the larger 83 MB capacity case. The broader #740 work stays deferred. Owned installation/build intermediates are being removed; compact reproducible evidence is retained.

<!-- gh-comment-id:6105505433 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): #1694 is merged as `13e03e94` after exact final-head CI **31/31 success** and local **30 focused tests**, type/lint, Knip and formatting checks. The change removes per-token async work from streamed JSON handling. Actual Flameox 0.2.9 profiling and five paired 18.54 MB real-snapshot workloads passed all complete canonical-content/Evidence identity oracles; median paired whole-process wall-time improvement was 3.63 s. Scoped cumulative sampled allocation estimates fell from 10.77 to 3.17 GB (single captures, collected objects included; not peak RSS). The merged reader source and compiled file match the measured candidate. Complete source-built Windows package verification also passed: real Ghidra analysis, unique snapshot save, fresh MCP process rejecting the old reference before import, streamed snapshot restore, exact retained Evidence/view identity, CLI/MCP summary parity, healthy ping and clean owned-resource shutdown. Two CPUs, Node heap 768 MiB, JVM 512 MiB; target unchanged. This is not a published release or a Windows large-payload benchmark. #1680 remains open for the larger 83 MB capacity case. The broader #740 work stays deferred. Owned installation/build intermediates are being removed; compact reproducible evidence is retained.
bsakaguchi commented 2026-10-15 18:24:41 +00:00
Author
Owner
Copy link

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

Merged #1707 as 29ff887f6558cf00c0d6392889b890ed8a702a6f: readiness reuses its already parsed Evidence bundle while retaining ID/graph/manifest authentication, uses the shared streaming canonical digest, and removes an unused verifier temporary directory that leaked on fixture preflight failure.

Flameox 0.2.9 randomized paired runs used the complete 1,422,937-byte readiness input containing real CLI Evidence. All 14 full report/input SHA and semantic-ID oracles passed; process-wall medians were 1,207.54 → 970.29 ms, paired difference −261.49 ms (95% interval [−303.22, −164.86] ms). This is a local readiness report workload, with startup and oracle overhead included. Output length, end-to-end CLI acceleration, and billed token reductions are not claimed.

22 domain and 17 compiled bundle-boundary tests passed locally; all 31 exact-head CI checks passed, including Reconstruction readiness. A fresh merged build repeated actual CLI/SDK-MCP analysis of the 6,686-byte control target, preserving the full normalized-result hash, Evidence ID, text/structured parity, unchanged target bytes and ping. The verifier preflight now leaves zero unused temporary directories. Merged-tree and anonymity audits passed. Owned runtime/catalog/skill outputs and the 274 MB profiling environment were cleaned; useful native profiles and lossless evidence remain under /tmp.

<!-- gh-comment-id:6105865916 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): <!-- rea-readiness-1707-merged --> Merged [#1707](https://github.com/morluto/rea/pull/1707) as `29ff887f6558cf00c0d6392889b890ed8a702a6f`: readiness reuses its already parsed Evidence bundle while retaining ID/graph/manifest authentication, uses the shared streaming canonical digest, and removes an unused verifier temporary directory that leaked on fixture preflight failure. Flameox 0.2.9 randomized paired runs used the complete 1,422,937-byte readiness input containing real CLI Evidence. All 14 full report/input SHA and semantic-ID oracles passed; process-wall medians were 1,207.54 → 970.29 ms, paired difference −261.49 ms (95% interval [−303.22, −164.86] ms). This is a local readiness report workload, with startup and oracle overhead included. Output length, end-to-end CLI acceleration, and billed token reductions are not claimed. 22 domain and 17 compiled bundle-boundary tests passed locally; all 31 exact-head CI checks passed, including Reconstruction readiness. A fresh merged build repeated actual CLI/SDK-MCP analysis of the 6,686-byte control target, preserving the full normalized-result hash, Evidence ID, text/structured parity, unchanged target bytes and ping. The verifier preflight now leaves zero unused temporary directories. Merged-tree and anonymity audits passed. Owned runtime/catalog/skill outputs and the 274 MB profiling environment were cleaned; useful native profiles and lossless evidence remain under `/tmp`.
bsakaguchi commented 2026-10-15 18:24:41 +00:00
Author
Owner
Copy link

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

Merged #1716 as 092de8f4 after all 31 checks passed on exact final head 5e7f62fa. #1680 is closed. The original 83,049,642-byte legacy Ghidra snapshot now restores through real SDK MCP within the 768 MiB Node heap/two-CPU budget, preserving the complete 41,546,956-byte bundle digest and retained Evidence identities. Cancellation/recovery and closed-session invalidation pass. A fresh full Windows package independently passes real PE CLI/MCP and the same large file-import boundary; the latter is not Windows provider analysis of the Linux ELF target.

Re-tested revised #1359 at b4b8f8bd with official native Frida 17.23.2 on Linux and Windows, including a fresh offline Windows installation. CLI/native interception, persistent and one-shot public MCP, schemas, cancellation/export/recovery, optional-binding behavior, 47 focused tests, full single-threaded typechecking, lint/module boundaries, Knip and docs pass. The previous eight findings are addressed; the new review requests changes for two reproduced Evidence issues: losing an already observed resume on cancellation, and deleting an active producer's capture bucket during capacity eviction (the latter is an adapter ordering seam). The exact-head CI workflow is approved and still running; the PR is not merged.

Windows initialization remains qualified: the candidate's default 60-second connection failed once; an initialization-only 120-second option passed. Actual Flameox 0.2.9 analysis of that successful full server-lifetime CPU capture points toward module filesystem lookup; this is not a latest-main control, initialization-only attribution, causal performance result or memory-leak proof.

Owned Linux/Windows installations, native addons, archives, temporary builds and the Flameox environment are cleaned. Compact exact-identity proofs and native profiles remain. Main is refreshed to 844fa527; the fresh runtime/packaged-skill build passes under the unchanged resource guard.

#1065 remains open. The original private memory-heavy target in #1387, representative client cold preparation, and cold Ghidra waiting/progress still need their own evidence. #740 remains deferred.

<!-- gh-comment-id:6106428099 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): Merged [#1716](https://github.com/morluto/rea/pull/1716) as `092de8f4` after all 31 checks passed on exact final head `5e7f62fa`. #1680 is closed. The original 83,049,642-byte legacy Ghidra snapshot now restores through real SDK MCP within the 768 MiB Node heap/two-CPU budget, preserving the complete 41,546,956-byte bundle digest and retained Evidence identities. Cancellation/recovery and closed-session invalidation pass. A fresh full Windows package independently passes real PE CLI/MCP and the same large file-import boundary; the latter is not Windows provider analysis of the Linux ELF target. Re-tested revised [#1359](https://github.com/morluto/rea/pull/1359) at `b4b8f8bd` with official native Frida 17.23.2 on Linux and Windows, including a fresh offline Windows installation. CLI/native interception, persistent and one-shot public MCP, schemas, cancellation/export/recovery, optional-binding behavior, 47 focused tests, full single-threaded typechecking, lint/module boundaries, Knip and docs pass. The previous eight findings are addressed; [the new review](https://github.com/morluto/rea/pull/1359#pullrequestreview-5482225067) requests changes for two reproduced Evidence issues: losing an already observed resume on cancellation, and deleting an active producer's capture bucket during capacity eviction (the latter is an adapter ordering seam). The exact-head CI workflow is approved and still running; the PR is not merged. Windows initialization remains qualified: the candidate's default 60-second connection failed once; an initialization-only 120-second option passed. Actual Flameox 0.2.9 analysis of that successful full server-lifetime CPU capture points toward module filesystem lookup; this is not a latest-main control, initialization-only attribution, causal performance result or memory-leak proof. Owned Linux/Windows installations, native addons, archives, temporary builds and the Flameox environment are cleaned. Compact exact-identity proofs and native profiles remain. Main is refreshed to `844fa527`; the fresh runtime/packaged-skill build passes under the unchanged resource guard. #1065 remains open. The original private memory-heavy target in #1387, representative client cold preparation, and cold Ghidra waiting/progress still need their own evidence. #740 remains deferred.
bsakaguchi commented 2026-10-15 18:24:41 +00:00
Author
Owner
Copy link

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

SDK cold-call follow-up on frozen main 21650455a9c90a26e725c3505a3c17054cc4516c: the current full catalog is 170 tools / 1,954,693 JSON bytes. Released client 2.3.1 still prepares all 170 output validators on the first call (148 actual compilations).

I verified the existing upstream fix with real REA stdio workflows and Flameox 0.2.9, using private experimental builds of the exact owning cache module rather than changing REA's dependency. In five ordered pairs, first-call medians were 6.286 s → 0.724 s, with a median within-pair reduction of 5.533 s. Preparation/compilation fell to 1 / 1. Full discovery, all 340 input/output meta-schemas, same-catalog refresh/reconnect, complete retained analysis/view Evidence, text/structured parity, malformed-response rejection and recovery passed. Flameox's complete first-call rankings corroborated the Ajv compilation hotspot. Exact revisions, scope and evidence are on the existing upstream PR.

T3/T5 remain pending deployment: SDK issue #2997 is closed, but PR #2998 is still open/unmerged, and the official client dist-tag is still 2.3.1. This improves client cold preparation in the experiment; it does not reduce catalog bytes or establish a fix for #1387's unavailable original memory-heavy target. #723 remains open. Next independent performance work remains Windows first analysis/startup (#1048); #740 stays deferred.

The requested #1359 installed Linux/Windows review is complete at b4b8f8bd855743c69bc0acade9771e6eb23269bf, with two remaining review findings. Final CI is red: the product failure is 20 Frida options missing CLI help descriptions; the other two failed jobs depend on that shard. The exact test/log diagnosis is posted. It is awaiting the contributor's fixes, not a blind rerun or merge.

This SDK investigation made no tracked product-source/dependency edits. Temporary runtime copies and the isolated analysis environment have been removed; shared dependencies remain intact. Original native profiles, provenance, complete Flameox evidence, compact reports and regression oracles remain local.

<!-- gh-comment-id:6106699648 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): SDK cold-call follow-up on frozen main `21650455a9c90a26e725c3505a3c17054cc4516c`: the current full catalog is **170 tools / 1,954,693 JSON bytes**. Released client 2.3.1 still prepares all 170 output validators on the first call (148 actual compilations). I verified the existing upstream fix with real REA stdio workflows and **Flameox 0.2.9**, using private experimental builds of the exact owning cache module rather than changing REA's dependency. In five ordered pairs, first-call medians were **6.286 s → 0.724 s**, with a median within-pair reduction of **5.533 s**. Preparation/compilation fell to **1 / 1**. Full discovery, all 340 input/output meta-schemas, same-catalog refresh/reconnect, complete retained analysis/view Evidence, text/structured parity, malformed-response rejection and recovery passed. Flameox's complete first-call rankings corroborated the Ajv compilation hotspot. [Exact revisions, scope and evidence are on the existing upstream PR](https://github.com/modelcontextprotocol/typescript-sdk/pull/2998#issuecomment-6106691706). T3/T5 remain pending deployment: SDK [issue #2997](https://github.com/modelcontextprotocol/typescript-sdk/issues/2997) is closed, but [PR #2998](https://github.com/modelcontextprotocol/typescript-sdk/pull/2998) is still **open/unmerged**, and the official client dist-tag is still **2.3.1**. This improves client cold preparation in the experiment; it does not reduce catalog bytes or establish a fix for #1387's unavailable original memory-heavy target. #723 remains open. Next independent performance work remains Windows first analysis/startup (#1048); #740 stays deferred. The requested #1359 installed Linux/Windows review is complete at `b4b8f8bd855743c69bc0acade9771e6eb23269bf`, with [two remaining review findings](https://github.com/morluto/rea/pull/1359#pullrequestreview-5482225067). Final CI is red: the product failure is 20 Frida options missing CLI help descriptions; the other two failed jobs depend on that shard. [The exact test/log diagnosis is posted](https://github.com/morluto/rea/pull/1359#issuecomment-6106513972). It is awaiting the contributor's fixes, not a blind rerun or merge. This SDK investigation made no tracked product-source/dependency edits. Temporary runtime copies and the isolated analysis environment have been removed; shared dependencies remain intact. Original native profiles, provenance, complete Flameox evidence, compact reports and regression oracles remain local.
bsakaguchi commented 2026-10-15 18:24:41 +00:00
Author
Owner
Copy link

@morluto commented on GitHub (Oct 14, 2026):

Refreshed the client preparation probe at fa318995f, using released SDK 2.3.1 and the production REA server over in-memory transport. This controlled provider catalog advertised 182 tools, compact input schemas and full output schemas. Three alternating fresh-process pairs completed initialize, discovery and two equivalent overview calls.

Passing the called tool's current advertised toolDefinition retains its output validation while avoiding the SDK's first-call preparation of the whole cached catalog:

Measurement Default SDK call Named definition
Median first call 1,246 ms 17 ms
Median second call 0.457 ms 0.438 ms
Median complete process wall 1.90 s 0.65 s
Median aggregate CPU 2.55 s 1.02 s
Sampled process-family RSS range 693–700 MiB 437–459 MiB

Complete wire content was identical: tokenx estimated 702,193 tokens including output schemas, not billed model tokens. RSS sampling was nominally 10 ms plus process-list overhead; summed RSS may double-count shared pages and miss peaks. No real engine/model or external-client speedup is claimed.

This confirms the preparation cost remains; it does not establish that most workloads hit a 60-second deadline. Upstream PR #2998 remains unmerged. REA's independently confirmed client/provider deadline propagation fixes are delivered without a dependency patch or weaker production validation. Keeping this broader roadmap open.

<!-- gh-comment-id:6181113587 --> @morluto commented on GitHub (Oct 14, 2026): Refreshed the client preparation probe at [`fa318995f`](https://github.com/morluto/rea/commit/fa318995f5654b2c2cb76f496da9220d49fc12ca), using released SDK 2.3.1 and the production REA server over in-memory transport. This controlled provider catalog advertised **182 tools**, compact input schemas and full output schemas. Three alternating fresh-process pairs completed initialize, discovery and two equivalent overview calls. Passing the called tool's current advertised `toolDefinition` retains its output validation while avoiding the SDK's first-call preparation of the whole cached catalog: | Measurement | Default SDK call | Named definition | | --- | ---: | ---: | | Median first call | 1,246 ms | 17 ms | | Median second call | 0.457 ms | 0.438 ms | | Median complete process wall | 1.90 s | 0.65 s | | Median aggregate CPU | 2.55 s | 1.02 s | | Sampled process-family RSS range | 693–700 MiB | 437–459 MiB | Complete wire content was identical: tokenx estimated 702,193 tokens including output schemas, **not billed model tokens**. RSS sampling was nominally 10 ms plus process-list overhead; summed RSS may double-count shared pages and miss peaks. No real engine/model or external-client speedup is claimed. This confirms the preparation cost remains; it does not establish that most workloads hit a 60-second deadline. Upstream [PR #2998](https://github.com/modelcontextprotocol/typescript-sdk/pull/2998) remains unmerged. REA's independently confirmed client/provider deadline propagation fixes are delivered without a dependency patch or weaker production validation. Keeping this broader roadmap open.
bsakaguchi commented 2026-10-15 18:24:42 +00:00
Author
Owner
Copy link

@CassieFox23 commented on GitHub (Oct 15, 2026):

TL;DR: I tested the current release, rea-agents 6.5.0, on my 1,200-function file. It acts like main 69fe5b601 did. A cancel stops the server in under 1 second, and the next call works. I did not run the CLI compare.

My earlier comment listed two items as not run: the CLI compare, and the 6.0.0 package. This comment tests the current release, 6.5.0, instead. It installs rea-agents 6.5.0 from npm and runs repro steps 1 to 3 and the cancel test. The fixture is the same file as before. It comes from the issue's generator at 1,200 functions. It has 114,179 bytes and SHA-256 bf5ad06a…45a0. The release tag contains #1601, #1651 and #1654. Each case ran 3 times. The machine was busy. Other test suites shared it. At the start of each run, about 13 to 23 jobs were running or waiting for a CPU thread, out of 24 threads.

Check 6.5.0 Earlier result
Tools listed 207 not recorded
No cancel: reply typed resource_constraint, 1,705 bytes, connection kept 1,529 bytes in my 6.3.0 and main runs
No cancel: analysis time 5 to 10 s, busy machine 3 s on idle main 69fe5b601; 4 s on busy main 8550913cd
No cancel: worst ping under 1 s (3 of 3) 2 s on 8550913cd; under 1 s on 69fe5b601
Cancel 200 ms after progress: server stop after the cancel under 1 s (3 of 3) 2 to 3 s on 6.3.0 and 8550913cd; under 1 s on 69fe5b601
Reply sent after cancel 0 of 3 0 of 3 on 8550913cd
Next call and ping after cancel OK (3 of 3) OK
Child process or temp file left none none
  • The cancel still works. The server logs "tool done, status error" and sends no reply.
  • I can't say if the 5 to 10 s analysis time is slower than the 3 s on idle main. The machine was far busier this time. I did not rerun it idle.
  • I only measure whole seconds here, because the machine was under load. My 69fe5b601 comment has the finer numbers.

Still not run

  • Step 4, the CLI compare. I did not run the CLI on this fixture.
  • The 6.0.0 package itself. I ran 6.5.0 instead.
  • The 300-function size on 6.5.0.
  • A cancel in the last 50 ms of a run, where one reply went out on 69fe5b601.
  • An idle machine for 6.5.0.
  • A real app, or many files at once.
  • Windows or macOS.
  • A heap snapshot, and the Evidence check after a cancel.
Commands 
npm_config_cache=/tmp/i1065/npm-cache npm install --prefix /tmp/i1065/pkg rea-agents@latest
# client.mjs is the harness script, available on request
( ulimit -c 0; timeout 1200 node client.mjs \
  --root /tmp/i1065/pkg/node_modules/rea-agents --sdk-root /tmp/i1065/pkg \
  --fixture /tmp/i1065/f1200/fixture --mode after-progress --cancel-ms 200 \
  --server-node-args --max-old-space-size=1536 --out result.json )

Every run was under nice -n 19 and a 6 GB memory cap. Runs were not pinned to CPUs this time.

Test setup
  • Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
  • CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
  • RAM: 32 GB DDR4-3600
  • Node: 24.18.0
  • Head: 3b79af28e (#1693), the rea-agents 6.5.0 tag
  • Other: MCP SDK client and server 2.3.1, 1,536 MiB server heap

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

<!-- gh-comment-id:6182760992 --> @CassieFox23 commented on GitHub (Oct 15, 2026): **TL;DR:** I tested the current release, rea-agents 6.5.0, on my 1,200-function file. It acts like main 69fe5b601 did. A cancel stops the server in under 1 second, and the next call works. I did not run the CLI compare. My earlier [comment](https://github.com/morluto/rea/issues/1065#issuecomment-6093389881) listed two items as not run: the CLI compare, and the 6.0.0 package. This comment tests the current release, 6.5.0, instead. It installs rea-agents 6.5.0 from npm and runs repro steps 1 to 3 and the cancel test. The fixture is the same file as before. It comes from the issue's generator at 1,200 functions. It has 114,179 bytes and SHA-256 bf5ad06a…45a0. The release tag contains #1601, #1651 and #1654. Each case ran 3 times. The machine was busy. Other test suites shared it. At the start of each run, about 13 to 23 jobs were running or waiting for a CPU thread, out of 24 threads. | Check | 6.5.0 | Earlier result | | --- | --- | --- | | Tools listed | 207 | not recorded | | No cancel: reply | typed `resource_constraint`, 1,705 bytes, connection kept | 1,529 bytes in my 6.3.0 and main runs | | No cancel: analysis time | 5 to 10 s, busy machine | 3 s on idle main 69fe5b601; 4 s on busy main 8550913cd | | No cancel: worst ping | under 1 s (3 of 3) | 2 s on 8550913cd; under 1 s on 69fe5b601 | | Cancel 200 ms after progress: server stop after the cancel | under 1 s (3 of 3) | 2 to 3 s on 6.3.0 and 8550913cd; under 1 s on 69fe5b601 | | Reply sent after cancel | 0 of 3 | 0 of 3 on 8550913cd | | Next call and ping after cancel | OK (3 of 3) | OK | | Child process or temp file left | none | none | - The cancel still works. The server logs "tool done, status error" and sends no reply. - I can't say if the 5 to 10 s analysis time is slower than the 3 s on idle main. The machine was far busier this time. I did not rerun it idle. - I only measure whole seconds here, because the machine was under load. My 69fe5b601 comment has the finer numbers. ### Still not run - Step 4, the CLI compare. I did not run the CLI on this fixture. - The 6.0.0 package itself. I ran 6.5.0 instead. - The 300-function size on 6.5.0. - A cancel in the last 50 ms of a run, where one reply went out on 69fe5b601. - An idle machine for 6.5.0. - A real app, or many files at once. - Windows or macOS. - A heap snapshot, and the Evidence check after a cancel. <details> <summary>Commands</summary> ```sh npm_config_cache=/tmp/i1065/npm-cache npm install --prefix /tmp/i1065/pkg rea-agents@latest # client.mjs is the harness script, available on request ( ulimit -c 0; timeout 1200 node client.mjs \ --root /tmp/i1065/pkg/node_modules/rea-agents --sdk-root /tmp/i1065/pkg \ --fixture /tmp/i1065/f1200/fixture --mode after-progress --cancel-ms 200 \ --server-node-args --max-old-space-size=1536 --out result.json ) ``` Every run was under `nice -n 19` and a 6 GB memory cap. Runs were not pinned to CPUs this time. </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.9 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - RAM: 32 GB DDR4-3600 - Node: 24.18.0 - Head: 3b79af28e (#1693), the rea-agents 6.5.0 tag - Other: MCP SDK client and server 2.3.1, 1,536 MiB server heap </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊
bsakaguchi commented 2026-10-16 21:02:24 +00:00
Author
Owner
Copy link

@CassieFox23 commented on GitHub (Oct 15, 2026):

TL;DR: I ran step 4, the CLI compare, on main and on 6.5.0. The CLI finishes and writes valid JSON. The MCP server returns a typed size error and keeps the connection. The Evidence kept by the MCP session matches the CLI Evidence field for field. I also ran the cancel checks on 6.5.0 at 300 functions and in the last 50 ms.

My 6.5.0 comment listed step 4 as not run. This comment runs it. The fixture is the issue's generator at 300 and 1,200 functions. The 1,200 file has 114,179 bytes and SHA-256 bf5ad06a…45a0, the same file as before. Main is 9d6651e5b (#4131). The 6.5.0 package is the tag 3b79af28e (#1693).

Step 4: CLI against MCP, same bytes

Check 300 functions 1,200 functions
CLI on main: exit, time, peak memory 0, 3.0 s, 396 MiB 0, 6.5 s, 497 MiB
CLI on main: JSON size, and does it parse 6,191,232 bytes, parses 24,769,759 bytes, parses
MCP on main, default buffer Typed resource_constraint, 1,470 bytes of text. Connection kept. Next call OK. (My 6.5.0 comment said 1,705 bytes. That was the 6.5.0 build. This is main.) Same
Evidence kept by the MCP session, exported Same as the CLI Evidence, field for field Same
Evidence id, CLI and MCP Both ev_d3643cd0…8de1 Both ev_2103c003…9c86
CLI on 6.5.0 0, 3.2 s, 394 MiB, 6,191,235 bytes, parses not run
MCP on 6.5.0, exported Evidence against the 6.5.0 CLI Same, field for field not run

The issue's own CLI run on 6.0.0 wrote 9,583,065 bytes at 300 functions. Mine is 6,191,232 bytes on main. I did not run 6.0.0, so I can't say where the size changed. The MCP calls used a 1,500 MiB server heap cap. The CLI runs used none.

Cancel on 6.5.0 (harness from my earlier comments, 3 runs per row, cancel 200 ms after progress)

Case Cancel sent Server stop after the cancel Reply sent Next call
300 functions 209 to 210 ms 92 to 95 ms 0 of 3 OK, 3 of 3
1,200 functions 206 to 208 ms 91 to 108 ms 0 of 3 OK, 3 of 3

No ping failed. The worst ping after a cancel was 3.7 ms. No child process or temp file was left.

A cancel in the last 50 ms of a run. I set the cancel at 98 percent of the median no-cancel time. That is 1,918 ms for 300 functions, and 5,460 ms for 1,200. Each case ran 5 times. Most runs finished before the cancel timer fired, so no cancel was sent.

  • 300 functions: 1 of 5 cancels landed. The server had finished 39 ms before it. The reply went out anyway, and the client dropped it. The next call worked.
  • 1,200 functions: 2 of 5 cancels landed. In both, the server stopped 286 and 627 ms later and sent no reply.

So the late-cancel race from my 69fe5b601 comment is still there on 6.5.0 at 300 functions.

Still not run

  • The 6.0.0 package itself.
  • An idle machine. The one-minute load average was 3.6 to 4.9 at the start of the harness runs. That counts tasks waiting for one of 24 threads. Other test suites shared the box. Treat the times as rough.
  • A real app, or many files at once.
  • Windows or macOS.
  • A heap snapshot, and the Evidence check after a cancel.
Commands 
node scripts/rea.mjs analyze-javascript-application <fixture> --format json   # CLI, on main and on 6.5.0
node client.mjs --root <pkg> --sdk-root <pkg root> --fixture <fixture> --mode none            # MCP, no cancel
node client.mjs ... --mode after-progress --cancel-ms 200
node client.mjs ... --mode at-offset --cancel-ms <98 percent of median>
# my own script: analyze_javascript_application, get_evidence_bundle, export_evidence_bundle, then a key-sorted diff against the CLI JSON
npm install --prefix <tmp> rea-agents    # version 6.5.0

For the Evidence match I sorted keys and compared every field. The MCP call used format: "auto", as the CLI does. With format: "directory", only parameters.format and the id differ. The harness and my script are not in the repo. I can share them.

Test setup
  • Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
  • CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads. Harness runs pinned to 2 threads.
  • RAM: 32 GB DDR4-3600
  • Node: 24.18.0
  • Head / base: 9d6651e5b (#4131), the tip of main / 3b79af28e (#1693), the 6.5.0 tag
  • Other: MCP SDK client and server 2.3.1, 207 tools, 1,536 MiB server heap for MCP runs

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

<!-- gh-comment-id:6197923071 --> @CassieFox23 commented on GitHub (Oct 15, 2026): **TL;DR:** I ran step 4, the CLI compare, on main and on 6.5.0. The CLI finishes and writes valid JSON. The MCP server returns a typed size error and keeps the connection. The Evidence kept by the MCP session matches the CLI Evidence field for field. I also ran the cancel checks on 6.5.0 at 300 functions and in the last 50 ms. My [6.5.0 comment](https://github.com/morluto/rea/issues/1065#issuecomment-6182760992) listed step 4 as not run. This comment runs it. The fixture is the issue's generator at 300 and 1,200 functions. The 1,200 file has 114,179 bytes and SHA-256 bf5ad06a…45a0, the same file as before. Main is 9d6651e5b (#4131). The 6.5.0 package is the tag 3b79af28e (#1693). **Step 4: CLI against MCP, same bytes** | Check | 300 functions | 1,200 functions | | --- | --- | --- | | CLI on main: exit, time, peak memory | 0, 3.0 s, 396 MiB | 0, 6.5 s, 497 MiB | | CLI on main: JSON size, and does it parse | 6,191,232 bytes, parses | 24,769,759 bytes, parses | | MCP on main, default buffer | Typed `resource_constraint`, 1,470 bytes of text. Connection kept. Next call OK. (My 6.5.0 comment said 1,705 bytes. That was the 6.5.0 build. This is main.) | Same | | Evidence kept by the MCP session, exported | Same as the CLI Evidence, field for field | Same | | Evidence id, CLI and MCP | Both ev_d3643cd0…8de1 | Both ev_2103c003…9c86 | | CLI on 6.5.0 | 0, 3.2 s, 394 MiB, 6,191,235 bytes, parses | not run | | MCP on 6.5.0, exported Evidence against the 6.5.0 CLI | Same, field for field | not run | The issue's own CLI run on 6.0.0 wrote 9,583,065 bytes at 300 functions. Mine is 6,191,232 bytes on main. I did not run 6.0.0, so I can't say where the size changed. The MCP calls used a 1,500 MiB server heap cap. The CLI runs used none. **Cancel on 6.5.0** (harness from my earlier comments, 3 runs per row, cancel 200 ms after progress) | Case | Cancel sent | Server stop after the cancel | Reply sent | Next call | | --- | --- | --- | --- | --- | | 300 functions | 209 to 210 ms | 92 to 95 ms | 0 of 3 | OK, 3 of 3 | | 1,200 functions | 206 to 208 ms | 91 to 108 ms | 0 of 3 | OK, 3 of 3 | No ping failed. The worst ping after a cancel was 3.7 ms. No child process or temp file was left. **A cancel in the last 50 ms of a run.** I set the cancel at 98 percent of the median no-cancel time. That is 1,918 ms for 300 functions, and 5,460 ms for 1,200. Each case ran 5 times. Most runs finished before the cancel timer fired, so no cancel was sent. - 300 functions: 1 of 5 cancels landed. The server had finished 39 ms before it. The reply went out anyway, and the client dropped it. The next call worked. - 1,200 functions: 2 of 5 cancels landed. In both, the server stopped 286 and 627 ms later and sent no reply. So the late-cancel race from my 69fe5b601 comment is still there on 6.5.0 at 300 functions. ### Still not run - The 6.0.0 package itself. - An idle machine. The one-minute load average was 3.6 to 4.9 at the start of the harness runs. That counts tasks waiting for one of 24 threads. Other test suites shared the box. Treat the times as rough. - A real app, or many files at once. - Windows or macOS. - A heap snapshot, and the Evidence check after a cancel. <details> <summary>Commands</summary> ```sh node scripts/rea.mjs analyze-javascript-application <fixture> --format json # CLI, on main and on 6.5.0 node client.mjs --root <pkg> --sdk-root <pkg root> --fixture <fixture> --mode none # MCP, no cancel node client.mjs ... --mode after-progress --cancel-ms 200 node client.mjs ... --mode at-offset --cancel-ms <98 percent of median> # my own script: analyze_javascript_application, get_evidence_bundle, export_evidence_bundle, then a key-sorted diff against the CLI JSON npm install --prefix <tmp> rea-agents # version 6.5.0 ``` For the Evidence match I sorted keys and compared every field. The MCP call used `format: "auto"`, as the CLI does. With `format: "directory"`, only `parameters.format` and the id differ. The harness and my script are not in the repo. I can share them. </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.9 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads. Harness runs pinned to 2 threads. - RAM: 32 GB DDR4-3600 - Node: 24.18.0 - Head / base: 9d6651e5b (#4131), the tip of main / 3b79af28e (#1693), the 6.5.0 tag - Other: MCP SDK client and server 2.3.1, 207 tools, 1,536 MiB server heap for MCP runs </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊
bsakaguchi commented 2026-10-16 21:02:24 +00:00
Author
Owner
Copy link

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

Linux remeasurement for T5, at 9d676054858f963c817feb691a6afc71f50506f4, locked SDK2.3.1, Node24.18.0, actual stdio MCP and official Rizin0.9.1. Each completed task included1CLI+11tool calls, one complete207-tool catalog and three controlled native target lifecycles. The fixture stayed unchanged, an unrelated rizin-named control survived, and final process lineage was verified empty.

Same completed task Default cached catalog Supported per-call toolDefinition
Validator-preparation calls 207 (183 distinct schema hashes) 11 (4 distinct schemas)
Preparation time 6537ms 84ms
First native session request 6915ms 362ms
Whole task wall /CPU 14.20s /16.07s 8.01s /8.96s
Sampled process-family RSS 1.015GiB 0.858GiB

Instrumentation delegates to the same default AJV provider and returns its validators unchanged. Selected definitions come from the actual catalog by exact tool name; result validation remains enabled. The SDK's stamp-keyed outputValidator index eagerly invokes preparation for every listed tool on first lookup. The per-call option bypasses that index and prepares only the chosen definition.

One observed run per mode on a shared host/two cores; caches/frequency/scheduling uncontrolled. Counts describe preparation attempts, not proof that every unused schema compiled successfully. Full catalog wire size is unchanged:829,341 o200k_base proxy tokens, including output schemas; this is neither model billing nor proof the host sends the whole catalog to its model. Schema meta-validation covers414 converted schemas. Refresh/list_changed/invalidation and other external clients were not verified, so this is evidence for the existing T5 direction, not a completed compatibility or server-side performance fix. No production workaround was added to the Rizin repair (#4459).

<!-- gh-comment-id:6216228514 --> @N0zoM1z0 commented on GitHub (Oct 16, 2026): Linux remeasurement for **T5**, at `9d676054858f963c817feb691a6afc71f50506f4`, locked SDK2.3.1, Node24.18.0, actual stdio MCP and official Rizin0.9.1. Each completed task included1CLI+11tool calls, one complete207-tool catalog and three controlled native target lifecycles. The fixture stayed unchanged, an unrelated rizin-named control survived, and final process lineage was verified empty. | Same completed task | Default cached catalog | Supported per-call toolDefinition | |---|---:|---:| | Validator-preparation calls |207 (183 distinct schema hashes)|11 (4 distinct schemas)| | Preparation time |6537ms|84ms| | First native session request |6915ms|362ms| | Whole task wall /CPU |14.20s /16.07s|8.01s /8.96s| | Sampled process-family RSS |1.015GiB|0.858GiB| Instrumentation delegates to the same default AJV provider and returns its validators unchanged. Selected definitions come from the actual catalog by exact tool name; result validation remains enabled. The SDK's stamp-keyed outputValidator index eagerly invokes preparation for every listed tool on first lookup. The per-call option bypasses that index and prepares only the chosen definition. One observed run per mode on a shared host/two cores; caches/frequency/scheduling uncontrolled. Counts describe preparation attempts, not proof that every unused schema compiled successfully. Full catalog wire size is unchanged:829,341 o200k_base proxy tokens, including output schemas; this is neither model billing nor proof the host sends the whole catalog to its model. Schema meta-validation covers414 converted schemas. Refresh/list_changed/invalidation and other external clients were not verified, so this is evidence for the existing T5 direction, not a completed compatibility or server-side performance fix. No production workaround was added to the Rizin repair (#4459).
bsakaguchi commented 2026-10-16 21:02:24 +00:00
Author
Owner
Copy link

@harrisonoconnorhover commented on GitHub (Oct 16, 2026):

Apple Silicon follow-up (October 16): 12/12 nonterminal cancellation cases recovered successfully; no reproducible defect found in this scope.

Tested source revision 180ba03, not the published 6.5.0 package. Setup: M1 Pro, macOS 26.5.2, Node 24.18.0 arm64, SDK 2.3.1; real stdio MCP, default 10 MiB receive buffer, current advertised per-call toolDefinition, detail: "summary", and 768 MiB V8 old-space budgets for both server and analyzer worker. Synthetic input: 40 files × 30 functions, 121,000 source bytes, parsed without execution.

Cancellation trigger Runs Sent → observed server settlement
200 ms after first progress 3 154–177 ms
Mid-file sequence, at/after file 21 3 942–944 ms
Application graph construction 3 1,617–2,232 ms
Evidence hashing 3 199–206 ms

All 12 logged server status: "error" and sent no target response. Prior Evidence remained unchanged, retained summary views validated, and subsequent analysis/ping succeeded. Analyzer workers and transfer paths were gone before the next call; observed descendants and owned temporary directories were gone after shutdown. All 379 recorded ping probes passed (maximum 65.41 ms). One uncancelled control parsed all 40 files; 24 existing cancellation tests also passed. Graph-stage settlement includes preserving already-collected facts.

Terminal races: three additional attempts cancelled immediately on terminal progress. The client rejected locally, but the server logged success roughly 2–4 ms later and a successful response arrived. The server's cancellation-notification processing instant was not instrumented: these are completion races, not successful cancellation tests or proof that an already-observed cancellation was ignored.

Limitations: one busy Mac (one-minute load 21.5–39.7), serial runs without CPU pinning; no cross-host performance claim. Summary delivery only: no oversized full-result retest, full CLI/MCP Evidence parity, real-app/ASAR, released-package, other-OS, or exhaustive cleanup-interruption qualification. Harness and raw results remain local. No production changes were made.

<!-- gh-comment-id:6217933708 --> @harrisonoconnorhover commented on GitHub (Oct 16, 2026): Apple Silicon follow-up (October 16): **12/12 nonterminal cancellation cases recovered successfully; no reproducible defect found in this scope.** Tested source revision [180ba03](https://github.com/morluto/rea/commit/180ba03bfddd5916251e81e97a500b1ede7a9eea), not the published 6.5.0 package. Setup: M1 Pro, macOS 26.5.2, Node 24.18.0 arm64, SDK 2.3.1; real stdio MCP, default 10 MiB receive buffer, current advertised per-call `toolDefinition`, `detail: "summary"`, and 768 MiB V8 old-space budgets for both server and analyzer worker. Synthetic input: 40 files × 30 functions, 121,000 source bytes, parsed without execution. | Cancellation trigger | Runs | Sent → observed server settlement | | --- | ---: | ---: | | 200 ms after first progress | 3 | 154–177 ms | | Mid-file sequence, at/after file 21 | 3 | 942–944 ms | | Application graph construction | 3 | 1,617–2,232 ms | | Evidence hashing | 3 | 199–206 ms | All 12 logged server `status: "error"` and sent no target response. Prior Evidence remained unchanged, retained summary views validated, and subsequent analysis/ping succeeded. Analyzer workers and transfer paths were gone before the next call; observed descendants and owned temporary directories were gone after shutdown. All 379 recorded ping probes passed (maximum 65.41 ms). One uncancelled control parsed all 40 files; 24 existing cancellation tests also passed. Graph-stage settlement includes preserving already-collected facts. **Terminal races:** three additional attempts cancelled immediately on terminal progress. The client rejected locally, but the server logged success roughly 2–4 ms later and a successful response arrived. The server's cancellation-notification processing instant was not instrumented: these are completion races, **not** successful cancellation tests or proof that an already-observed cancellation was ignored. **Limitations:** one busy Mac (one-minute load 21.5–39.7), serial runs without CPU pinning; no cross-host performance claim. Summary delivery only: no oversized full-result retest, full CLI/MCP Evidence parity, real-app/ASAR, released-package, other-OS, or exhaustive cleanup-interruption qualification. Harness and raw results remain local. No production changes were made.
bsakaguchi commented 2026-10-31 00:29:09 +00:00
Author
Owner
Copy link

@Shreyash021104 commented on GitHub (Oct 21, 2026):

Updated catalog measurement on main a5f982d (2026-10-21), taken from a source build's tools/list over stdio and counted as compact JSON bytes:

2026-10-11 (frozen main, above) 2026-10-21 (a5f982d)
Tools 170 212
Full tools/list 1,954,693 B 3,484,718 B

Breakdown at a5f982d:

  • inputSchema: 724,037 B. outputSchema: 2,609,195 B.
  • Model-facing projection (name, description and inputSchema only): 843,441 B.
  • Largest input schemas: compare_web_captures 166,024 B; inspect_analysis_view 49,804; compare_application_versions 30,375; evaluate_reconstruction_coverage 24,776; project_managed_application_graph 22,281.

compare_web_captures alone is about 23% of all input-schema bytes. before_scenario and after_scenario are about 48.7 KB each, and before and after about 31.1 KB each. That may be relevant to #4973 (Claude connector warning) and #4620 (Gemini 400). Token counts were not measured.

<!-- gh-comment-id:6310483797 --> @Shreyash021104 commented on GitHub (Oct 21, 2026): Updated catalog measurement on `main` `a5f982d` (2026-10-21), taken from a source build's `tools/list` over stdio and counted as compact JSON bytes: | | 2026-10-11 (frozen main, above) | 2026-10-21 (`a5f982d`) | |---|---|---| | Tools | 170 | 212 | | Full `tools/list` | 1,954,693 B | 3,484,718 B | Breakdown at `a5f982d`: - `inputSchema`: 724,037 B. `outputSchema`: 2,609,195 B. - Model-facing projection (name, description and `inputSchema` only): 843,441 B. - Largest input schemas: `compare_web_captures` 166,024 B; `inspect_analysis_view` 49,804; `compare_application_versions` 30,375; `evaluate_reconstruction_coverage` 24,776; `project_managed_application_graph` 22,281. `compare_web_captures` alone is about 23% of all input-schema bytes. `before_scenario` and `after_scenario` are about 48.7 KB each, and `before` and `after` about 31.1 KB each. That may be relevant to #4973 (Claude connector warning) and #4620 (Gemini 400). Token counts were not measured.
bsakaguchi commented 2026-11-03 00:29:27 +00:00
Author
Owner
Copy link

@morluto commented on GitHub (Nov 2, 2026):

Overflow recovery text duplication

In the real Kuna 1.989 48,000-pointer overflow control documented on #8591, the compact-profile SDK response was 3,209 serialized bytes. Within its structured error, message and details.reason were identical 731-byte strings, and remediation.action was 602 bytes containing much of the same transport and continuation guidance. The structured reported_limits.continuation was usable: following it and the page offsets recovered the complete retained address list. This was one scripted client flow on macOS, not an autonomous-agent trace or a token measurement.

Source inspection points to mcpResponseOverflowProjection, which assembles the summary, transport facts, and next step into the reason, then repeats the facts in the remediation; the common resource-error projection also carries the reason as both message and detail. Consider whether each field can instead own a distinct part of the explanation while keeping the actionable continuation, completed-operation status, receive-buffer versus string-ceiling distinction, and existing client expectations intact. This is an investigation candidate, not evidence that repetition caused recovery failure; assess consumer compatibility and measure actual context impact before changing the shared error contract.

<!-- gh-comment-id:6584503086 --> @morluto commented on GitHub (Nov 2, 2026): ### Overflow recovery text duplication In the real Kuna 1.989 48,000-pointer overflow control documented on #8591, the compact-profile SDK response was 3,209 serialized bytes. Within its structured error, `message` and `details.reason` were identical 731-byte strings, and `remediation.action` was 602 bytes containing much of the same transport and continuation guidance. The structured `reported_limits.continuation` was usable: following it and the page offsets recovered the complete retained address list. This was one scripted client flow on macOS, not an autonomous-agent trace or a token measurement. Source inspection points to `mcpResponseOverflowProjection`, which assembles the summary, transport facts, and next step into the reason, then repeats the facts in the remediation; the common resource-error projection also carries the reason as both message and detail. Consider whether each field can instead own a distinct part of the explanation while keeping the actionable continuation, completed-operation status, receive-buffer versus string-ceiling distinction, and existing client expectations intact. This is an investigation candidate, not evidence that repetition caused recovery failure; assess consumer compatibility and measure actual context impact before changing the shared error contract.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
codex/procedure-reference-stacked
release-please--branches--main--components--rea-agents
release-please--branches--main--components--rea-agents--release-notes
codex/kuna-independent-retry
codex/byte-search-overlay-coverage
codex/open-failure-target-receipt
codex/kuna-xref-evidence
codex/ghidra-ambiguous-procedure-recovery
codex/function-source-bundle
codex/trace-function-integration-prototype
codex/snapshot-source-closure
codex/recorded-evidence-array-pages
codex/evidence-recovery-redesign
codex/trace-feature-address-scope
codex/call-discovery-scope
codex/ghidra-literal-candidate-evidence
codex/decompile-directory-independent-retry
codex/retry-provenance-base
codex/value-flow-capability-experiment
codex/ghidra-containing-instruction
cursor/readme-discord-button-ef9f
dependabot/github_actions/actions/setup-node-7.1.0
dependabot/github_actions/actions/upload-artifact-7.0.2
dependabot/npm_and_yarn/npm-minor-and-patch-d8d97ce6df
codex/kuna-1989
fix/8559-native-ui-fixture-ownership
fix/8555-go-verifier-mcp-ownership
codex/provider-capability-recovery
fix/8642-rizin-target-stdin
codex/ghidra-memory-effect-scope
codex/ghidra-annotation-entry-selector
codex/ghidra-readonly-recovery
codex/ghidra-regex-verifier-recovery
codex/evidence-discovery-view-guidance
fix/8545-bulk-append-overflow
fix/8428-navigation-refusal-alternatives
codex/address-context-recovery
codex/matching-member-limitations
codex/unknown-scope-contract
codex/evidence-view-guidance
feat/8373-native-trace-views
codex/ghidra-snapshot-verifier-binding
codex/elf-export-visibility
codex/evidence-view-recovery
codex/native-reference-cli-help
codex/provider-candidate-observation-scope
codex/kuna-session-verification
codex/ghidra-switch-lifetime-guidance
codex/pseudocode-paging-discovery
codex/clarify-evidence-view-support
codex/kuna-xrefs-selector-recovery
codex/context-capacity-recovery
codex/evidence-closure-large-links
codex/same-function-evidence-identity
codex/ghidra-verifier-inspected-jdk
codex/audit-guided-workflows
codex/crash-prompt-retained-dossiers
codex/analysis-view-error-recovery
codex/kuna-verifier-target-selection
codex/ghidra-selected-project-call-coverage
codex/docs-native-analysis-scope
codex/ghidra-java-socket-boundary
codex/ghidra-retained-snapshot-verifier
codex/ghidra-search-inventory-facts
fix/8284-zero-argument-parameter-bindings
fix/8198-ui-action-handler-offset
fix/8257-elf-entry-label-identity
fix/8304-deferred-output-schema-projection
fix/8277-call-path-computed-target-uncertainty
fix/pr-8089-conflicts
fix/ci-static-duplicate-export
dependabot/npm_and_yarn/lint-staged-17.6.0
dependabot/github_actions/actions/download-artifact-8.0.2
dependabot/npm_and_yarn/write-file-atomic-8.0.0
dependabot/npm_and_yarn/canonicalize-5.1.0
dependabot/github_actions/actions/cache/restore-6.1.0
dependabot/npm_and_yarn/toon-format/toon-4.4.0
dependabot/github_actions/actions/deploy-pages-5.0.1
codex/review-fixes-pr-2403
codex/review-fixes-pr-2400
codex/process-terminal-width
codex/test-brittleness-cleanup
verify/7167-browser-connect-macos
fix/7167-browser-connect
feat/native-matching-allowance-setting
feat/browser-scenario-dry-run
test/managed-caller-parameters-20261024
codex/parser-fortythird-boundaries
fix/6926-pinvoke-platform-decorations-20261023
fix/6889-har-body-encoding-20261023
fix/6888-sqlite-schema-budget-20261023
fix/dependency-security-gates-6708
cursor/evidence-overwrite-rebase-b4ac
feat/4057-verify-native-exports
fix/windows-acl-observer-overhead-20261022
cursor/erlang-beam-restack-4476
cursor/pe-certificate-review-bf32
fix/6116-javascript-application-fs-errors
fix/6061-unmapped-runtime-script-unknown
feat/browser-scenario-summary
fix/pe-certificates
codex/verify-3407
cursor/rebase-5699
cursor/rebase-5352
cursor/rebase-5600
cursor/fix-cli-schema-omission-10a8
codex/audit-hopper-shutdown-reasons-20261021
fix/demangle-swift-omitted-record
fix/nib-boolean-value-types
cursor/cancellation-partial-observation-a5ac
fix/ib-object-limit-reasons
fix/electron-fuse-limit-advice
fix/kuna-doctor-dangling-cache
fix/fixed-budget-refusal-advice
fix/js-ipc-listener-dedup
fix/js-return-member-provenance
fix/dmg-integrity-retry-advice
fix/ida-doctor-readiness
fix/kuna-version-probe-output-drain
fix/legacy-swift-runtime-name-matching
fix/dylib-lazy-load-commands
fix/browser-scenario-startup-cancel
fix/swift-nested-punycode-classification
fix/compare-unselected-scopes
fix/objc-method-budget-coverage
fix/dmg-mounted-root-observations
audit/ci-tests-20261019-round2
release/6.7.0
fix/wabt-cleanup-retry-resolution
fix/electron-fuse-elf-pe-architecture
fix/native-plist-descriptor-ownership
fix/kuna-caller-cleanup-ownership
experiment/atomic-codemode-20261016
review/first-contributor-3776
fix/call-resolution-full-read-cycles
fix/member-mutation-selection-repeat
experiment/atomic-re-tools-20261015
perf/member-mutation-lazy-origins
perf/static-network-mutation-index
fix/hopper-startup-lifecycle
audit/3050-windows-proof-20261015
feat/windows-window-capture-2183
audit/3049-windows-proof-20261015
audit/3735-macos-fixtures-20261015
fix/batch-decompile-null-pseudocode
fix/kuna-inventory-honors-jobs
experiment/browser-codemode-tool-design-20261015
fix/hopper-clean-runtime-argv
codex/review-2049-27f1b367
review-fixes/pr-2787-routing
fix/3360-scoped-this-emitters
fix/3367-replaced-global-effects
fix/3838-compact-any-value-items
test/hopper-download-probe-20261015
codex/windows-runtime-creation-red-green-20261015
codex/windows-readonly-root-red-green-20261015
codex/windows-root-share-red-green-20261015
codex/exp-1685-win-mcp-startup
codex/bug-sweep-20261015
investigate/2190-windows-package-phases
investigate/3543-macos-cli-deadline
perf/3281-reverse-tools-feedback-quality
fix/3406-hopper-doctor-fixture
fix/3341-wrapper-require-test-context
fix/3301-owned-uninstall-fixtures
fix/3164-compiler-input-ownership
fix/pcap-cleanup-stdout-newline-20261014
perf/interface-builder-summary
codex/review-fixes-pr-1977
fix/ghidra-effective-jvm-platform
fix/docs-turkish-rust-link-20261013
fix/main-maintenance-ci-20261010
fix/recover-binary-session-process-effects
codex/review-fixes-pr-2457
codex/ci-required-cancellation-gate
fix/main-format-baseline-20261013
fix/setup-preserve-entry-fields
cursor/restore-main-checks-1ffc
fix/ghidra-bridge-hashmap-import
codex/shared-ci-jadx-json-default-20261013
codex/shared-ci-ghidra-test-groups-20261013
codex/shared-ci-java-fixture-format-20261013
codex/fix-intrinsic-invocation-boundaries
test/release-preflight-reusable-jobs
test/js-parameter-provenance-expectation
fix/linux-hopper-verification-current
test/2419-ghidra-elf-probe-size
followup/pr-1544-native-ida
codex/fold-pr-2230-contribution
docs/readme-responsible-use
fix/issue-2064
fix/issue-2050
fix/issue-2053
fix/issue-1968
fix/issue-1945
experiment/codemode-bridge-20261011
fix/tool-effects-negative-wording-1904-20261012
fix/1842-electron-interop-provenance
feat/recover-javascript-multi-input
refactor/website-i18n-prep
fix/nativeaot-pe-virtual-extent
fix/browser-verifier-ci-hang
fix/pe-resources-input-selection
docs/beginner-friendly-guides
docs/beginner-setup-guide
fix/javascript-analysis-worker-1563
fix/1649-ghidra-duplicate-names
fix/javascript-export-keys-integration-1369
test/maintenance-boundary-contracts-20261011
review/javascript-export-keys-1369
review/process-live-progress-1483
test/javascript-1495-growth-ratio
fix/ci-escape-timing
docs/normalized-terminal-geometry-1450
release/6.3.0
archive/release-6.3.0-pr1381
release/6.2.0
fix/electron-preload-dynamic-override
fix/javascript-self-referential-bundler-edges
release/6.1.0
cursor/grok-client-cherry-pick-0b56
feat/signature-posture
feat/dyld-shared-cache
feat/artifact-integrity-policy
feat/pkg-inventory
release/6.0.0
chore/sync-release-5.0.0
release/5.0.0
cursor/cloud-agent-node-787e
fix/javascript-xhr-open-endpoints
review/pr-711-realpath-fallback-wording
cleanup/replay-confinement
codex/test-suite-performance
codex/issue-foundations
codex/address-open-issues-2026-07-20
agent/javascript-vite-rollup-esbuild-adapters
agent/process-cleanup
agent/triage-integration
agent/unknown-commands-registry
feat/mcp-identity-metadata
morlvps/issue_cleanup
codex/installer-redesign
morl/roadmap-investigation-core
morl/roadmap-investigation-docs
release-please--branches--main--components--rea
rea-agents-6.8.0
rea-agents-6.7.0
rea-agents-6.6.0
experiment/atomic-codemode-wait-runtime-20261016
rea-agents-6.5.0
rea-agents-6.4.0
rea-agents-6.3.0
rea-agents-6.2.0
rea-agents-6.1.0
rea-agents-6.0.0
rea-agents-5.0.0
rea-agents-4.1.0
rea-agents-4.0.1
rea-agents-4.0.0
rea-agents-3.2.1
rea-agents-3.2.0
rea-agents-3.1.0
rea-agents-3.0.0
rea-agents-2.7.0
rea-agents-2.6.0
rea-agents-2.5.1
rea-agents-2.5.0
rea-agents-2.4.0
rea-agents-2.3.0
rea-agents-2.2.0
rea-agents-2.1.0
rea-agents-2.0.0
rea-agents-1.7.0
rea-agents-1.6.0
rea-agents-1.5.0
rea-agents-1.4.0
rea-agents-1.3.0
rea-agents-1.2.0
rea-agents-1.1.0
rea-agents-1.0.0
rea-agents-0.5.0
rea-agents-0.4.0
rea-agents-0.3.0
rea-0.2.1
rea-0.2.0
Labels
Clear labels   
area: bridge

   
area: bridge

   
area: build

   
area: build

   
area: build

   
area: cli

   
area: domain

   
area: evidence

   
area: mcp

   
area: native

   
area: providers

   
area: runtime

   
area: server

   
area: setup

   
area: tests

   
bug

   
design

   
documentation

   
enhancement

   
enhancement

   
enhancement

   
experiment

   
help wanted

   
i18n

   
invalid

   
P0: critical

   
P1: high

   
P2: medium

   
P2: medium

   
P2: medium

   
P3: low

   
performance

   
provider-request

   
pull-request
Mirrored from GitHub Pull Request

  
question

   
roadmap

   
triage
No labels
area: bridge
area: bridge
area: build
area: build
area: build
area: cli
area: domain
area: evidence
area: mcp
area: native
area: providers
area: runtime
area: server
area: setup
area: tests
bug
design
documentation
enhancement
enhancement
enhancement
experiment
help wanted
i18n
invalid
P0: critical
P1: high
P2: medium
P2: medium
P2: medium
P3: low
performance
provider-request
pull-request
question
roadmap
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#390
No description provided.