[GH-ISSUE #4680] [Bug] Hopper regex search failures identify an inventory operation #2438

Closed
opened 2026-10-17 21:04:40 +00:00 by bsakaguchi · 2 comments
Owner

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

Before submitting

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

Area

Native analysis or decompilation

Observed behavior

rea search <program> fixture --provider hopper --mode regex --json returns an error identifying list_strings rather than the requested search_strings when its internal inventory request fails. Selecting --kind procedures returns list_procedures rather than search_procedures. Both capability refusals and ordinary bridge errors reproduced on both tested builds. Ordinary errors also name the inventory operation in the message. These observations use a stand-in executable implementing the Hopper bridge protocol; no real Hopper engine was used.

Reproduction

  1. For the source build, check out the revision below, use its pinned Node/npm toolchain, then run npm ci and npm run build:cached. For the published package, run npm install --prefix release --no-audit --no-fund rea-agents@6.5.0, then change directory to release/node_modules/rea-agents. Run the following fixture from either root, which contains scripts/rea.mjs.
  2. The fixture copies the system true executable as a native target, selects its stand-in launcher through HOPPER_LAUNCHER_PATH, and invokes the public CLI with a fresh HOME and TMPDIR and whitelist environment for each child. The launcher reads REA's production bootstrap and serves its authenticated Unix-socket protocol. The target is not executed. Temporary fixture directories are removed afterward.
node --input-type=module <<'NODE'
import assert from 'node:assert/strict';
import {mkdtemp,writeFile,copyFile,readFile,rm} from 'node:fs/promises';
import {spawn} from 'node:child_process';
import {join,dirname} from 'node:path';
import {tmpdir} from 'node:os';
const root=await mkdtemp(join(tmpdir(),'hopper-regex-repro-'));
const launcher=join(root,'fake-hopper');
await writeFile(launcher,"#!/usr/bin/env node\nimport {readFileSync,appendFileSync} from 'node:fs';\nimport {createServer} from 'node:net';\nconst source=readFileSync(process.argv[process.argv.indexOf('-Y')+1],'utf8');\nconst value=name=>JSON.parse(source.split('\\n').find(x=>x.startsWith(name+' = ')).split(' = ')[1]);\nconst token=value('REA_TOKEN'),run=value('REA_RUN_ID');\nconst server=createServer(socket=>{\n let data='';socket.setEncoding('utf8');socket.on('error',()=>{});\n socket.on('data',chunk=>{data+=chunk;let i;while((i=data.indexOf('\\n'))>=0){\n const q=JSON.parse(data.slice(0,i));data=data.slice(i+1);appendFileSync(process.env.FIXTURE_TRACE,q.method+'\\n');\n let reply;\n if(q.token!==token)throw Error('bad token');\n if(q.method==='health')reply={result:{name:'REA Hopper bridge',version:'1.0.0',run_id:run,process_id:process.pid}};\n else if(q.method.startsWith('shutdown')){reply={result:{shutdown:true,analysis_stopped:true,document_closed:true}};setTimeout(()=>{socket.destroy();server.close();},20);}\n else if(q.method.startsWith('list_')&&process.env.FIXTURE_MODE!=='valid')reply={error:{code:-32000,message:'fixture inventory unavailable',type:process.env.FIXTURE_MODE}};\n else if(q.method==='list_strings'||q.method==='list_procedures')reply={result:[{address:'0x1000',value:'fixture'}]};\n else if(q.method==='current_document')reply={result:'fixture'};\n else if(q.method==='search_strings'||q.method==='search_procedures')reply={result:[]};\n else reply={result:{}};\n socket.write(JSON.stringify({id:q.id,...reply})+'\\n');\n }});\n});server.listen(value('REA_SOCKET'));\n",{mode:0o700});
await copyFile('/usr/bin/true',join(root,'sample'));
try {
  for(const kind of ['strings','procedures']) {
    for(const mode of ['capability_unavailable','bridge_exception','valid']) {
      for(let repeat=1;repeat<=2;repeat++) {
        const home=await mkdtemp(join(root,'home-')),trace=join(home,'trace');
        const args=['scripts/rea.mjs','search',join(root,'sample'),'fixture','--provider','hopper','--kind',kind,'--mode','regex','--json'];
        const env={HOME:home,TMPDIR:home,PATH:root+':'+dirname(process.execPath)+':/usr/bin:/bin:/usr/sbin:/sbin',HOPPER_LAUNCHER_PATH:launcher,REA_LOG_LEVEL:'silent',FIXTURE_MODE:mode,FIXTURE_TRACE:trace};
        const child=spawn(process.execPath,args,{env});
        let stdout='',stderr='';
        child.stdout.on('data',x=>stdout+=x);
        child.stderr.on('data',x=>stderr+=x);
        const exit=await new Promise((resolve,reject)=>{child.on('error',reject);child.on('close',resolve);});
        const output=JSON.parse(stdout),calls=(await readFile(trace,'utf8')).trim().split('\n');
        assert.equal(stderr,'');
        const requested='search_'+kind,inventory='list_'+kind;
        assert.deepEqual(calls,['health',inventory,'shutdown_document']);
        if(mode==='valid') {
          assert.equal(exit,0);
          assert.equal(output.operation,requested);
          assert.deepEqual(output.normalized_result,[{address:'0x1000',value:'fixture'}]);
        } else {
          assert.equal(exit,1);
          assert.equal(output.code,mode==='capability_unavailable'?'capability_unavailable':'execution_failure');
          assert.equal(output.details.operation,inventory);
          if(mode==='bridge_exception')assert(output.message.includes(inventory));
        }
        console.log(JSON.stringify({kind,mode,repeat,exit,code:output.code??null,operation:output.details?.operation??output.operation,calls}));
      }
    }
  }
} finally {await rm(root,{recursive:true,force:true});}
NODE
  1. Each build completes twelve invocations: eight failures, covering both search kinds and both injected failure types twice, and four successful controls. The script asserts the observed faulty attribution to reproduce the current behavior; when checking restoration, expect the requested search_ operation in those failure assertions instead.

Expected behavior

An inventory failure returned for an accepted regex search should retain the caller's search_strings or search_procedures identity while preserving the provider failure classification, reason, request context and cleanup result. The CLI selects those search operations, successful controls report them, and the adjacent malformed-inventory and cancellation paths already attribute failures to them. The selected-runtime failure contract says these failures are reported at the operation that needs the runtime.

Impact and scope

The structured error misidentifies the accepted search operation in all sixteen injected failures across both builds. A machine-readable consumer receives an inventory-operation identity for its search request. The search still fails when the provider cannot supply inventory; no successful data was discarded. Eight successful controls passed. Real Hopper occurrence frequency and downstream automation consequences were not measured. No target mutation, data loss or security boundary crossing was observed.

  • Impact level: P2
  • Assessment status: supported
  • Impact basis: The public error's machine-readable operation identity refers to an internal request rather than the accepted search operation under two bounded provider failure classes.
  • Workaround status: unverified
  • Workaround basis: Successful provider replies avoid the trigger, but no practical workaround preserving the same failing regex search was verified.

REA version

Current main source commit 1e36e707b1f991fde826947bab04d436e64b7f97, package version 6.5.0, built from locked dependencies; separately installed published npm package rea-agents@6.5.0, identified by the npm registry as the latest published release.

Runtime and platform

Node.js v24.18.0; macOS 27.0.1, Darwin arm64. The source build used repository-pinned npm 11.16.0. Both builds used the simulated bridge described above.

Target and artifact context

A scratch copy of the system Mach-O universal true executable supplies target admission. The simulated provider supplies one synthetic string or procedure record at address 0x1000. Authentication values come from the test invocation's generated bootstrap and are never printed. No private target data is required.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

  • Expected source: src/cli/coreBinaryCommands.ts:487-510 selects the caller operation; src/hopper/HopperRegexSearch.ts:99-107 retains it for adjacent failures; docs/mcp-contracts.md:521-525 states the selected-runtime failure contract.
  • Failure source: src/hopper/HopperProvider.ts:310-317 routes regex searches to src/hopper/HopperRegexSearch.ts:90-97, which returns the inventory failure unchanged; src/hopper/HopperClient.ts:607-624 and src/hopper/HopperRequestQueue.ts:397-403 attach the inventory identity. The public CLI observations below establish the delivered result.
  • Evidence provenance: observed
  • Local verification: reproduced
  • Reproduction completeness: complete

Public commands invoked by the fixture, with its generated target path abbreviated as sample:

node scripts/rea.mjs search sample fixture --provider hopper --kind strings --mode regex --json
node scripts/rea.mjs search sample fixture --provider hopper --kind procedures --mode regex --json

Smallest meaningful results, observed twice for every row on each build:

kind        provider reply          exit  code                    reported operation
strings     capability_unavailable  1     capability_unavailable  list_strings
strings     bridge_exception        1     execution_failure       list_strings
strings     valid                   0     successful Evidence     search_strings
procedures  capability_unavailable  1     capability_unavailable  list_procedures
procedures  bridge_exception        1     execution_failure       list_procedures
procedures  valid                   0     successful Evidence     search_procedures

The ordinary error messages were Hopper list_strings failed (-32000, bridge_exception): fixture inventory unavailable and Hopper list_procedures failed (-32000, bridge_exception): fixture inventory unavailable. Capability refusals retained details.reason: "fixture inventory unavailable". Every trace contained health, the selected inventory operation, and shutdown_document; child stderr was empty. Successful controls returned the expected fixture record. These results establish REA's public behavior for simulated provider replies, not that a real Hopper bridge emits those replies.

Typed outcome or recovery expected

Replay the same provider failures and require exit 1 with details.operation equal to search_strings or search_procedures, while retaining each failure code and diagnostic context. Ordinary error messages should identify that accepted search. The valid controls must continue returning exit 0, the same matching fixture record, canonical search operation and completed cleanup. A direct inventory request, if separately exercised, must retain its own inventory identity.

Analysis or suspected cause

Source-derived reasoning: the Hopper provider routes regex searches to a local matcher that first obtains an inventory. Its failure branch returns the inventory error unchanged. Capability conversion and remote-error request context label that error with the wire method, so the inventory name reaches the public result. The malformed-inventory branch already retains the original search operation.

Additional context

Related #4607, #4614 and #4634 concern independent Cutter and IDA attribution paths. #4375 concerns Hopper startup diagnostic loss, rather than search operation identity. Open and closed Hopper/search/inventory/operation issue and PR searches, including the consolidation index #4330 and subsystem index #3537, found no matching report. MCP, timeout behavior and real-engine occurrence were not exercised. No regression range is known.

Originally created by @coygeek on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4680 ### Before submitting - [X] I searched the open and closed issues for a related report. - [X] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior `rea search <program> fixture --provider hopper --mode regex --json` returns an error identifying `list_strings` rather than the requested `search_strings` when its internal inventory request fails. Selecting `--kind procedures` returns `list_procedures` rather than `search_procedures`. Both capability refusals and ordinary bridge errors reproduced on both tested builds. Ordinary errors also name the inventory operation in the message. These observations use a stand-in executable implementing the Hopper bridge protocol; no real Hopper engine was used. ### Reproduction 1. For the source build, check out the revision below, use its pinned Node/npm toolchain, then run `npm ci` and `npm run build:cached`. For the published package, run `npm install --prefix release --no-audit --no-fund rea-agents@6.5.0`, then change directory to `release/node_modules/rea-agents`. Run the following fixture from either root, which contains `scripts/rea.mjs`. 2. The fixture copies the system `true` executable as a native target, selects its stand-in launcher through `HOPPER_LAUNCHER_PATH`, and invokes the public CLI with a fresh HOME and TMPDIR and whitelist environment for each child. The launcher reads REA's production bootstrap and serves its authenticated Unix-socket protocol. The target is not executed. Temporary fixture directories are removed afterward. ```sh node --input-type=module <<'NODE' import assert from 'node:assert/strict'; import {mkdtemp,writeFile,copyFile,readFile,rm} from 'node:fs/promises'; import {spawn} from 'node:child_process'; import {join,dirname} from 'node:path'; import {tmpdir} from 'node:os'; const root=await mkdtemp(join(tmpdir(),'hopper-regex-repro-')); const launcher=join(root,'fake-hopper'); await writeFile(launcher,"#!/usr/bin/env node\nimport {readFileSync,appendFileSync} from 'node:fs';\nimport {createServer} from 'node:net';\nconst source=readFileSync(process.argv[process.argv.indexOf('-Y')+1],'utf8');\nconst value=name=>JSON.parse(source.split('\\n').find(x=>x.startsWith(name+' = ')).split(' = ')[1]);\nconst token=value('REA_TOKEN'),run=value('REA_RUN_ID');\nconst server=createServer(socket=>{\n let data='';socket.setEncoding('utf8');socket.on('error',()=>{});\n socket.on('data',chunk=>{data+=chunk;let i;while((i=data.indexOf('\\n'))>=0){\n const q=JSON.parse(data.slice(0,i));data=data.slice(i+1);appendFileSync(process.env.FIXTURE_TRACE,q.method+'\\n');\n let reply;\n if(q.token!==token)throw Error('bad token');\n if(q.method==='health')reply={result:{name:'REA Hopper bridge',version:'1.0.0',run_id:run,process_id:process.pid}};\n else if(q.method.startsWith('shutdown')){reply={result:{shutdown:true,analysis_stopped:true,document_closed:true}};setTimeout(()=>{socket.destroy();server.close();},20);}\n else if(q.method.startsWith('list_')&&process.env.FIXTURE_MODE!=='valid')reply={error:{code:-32000,message:'fixture inventory unavailable',type:process.env.FIXTURE_MODE}};\n else if(q.method==='list_strings'||q.method==='list_procedures')reply={result:[{address:'0x1000',value:'fixture'}]};\n else if(q.method==='current_document')reply={result:'fixture'};\n else if(q.method==='search_strings'||q.method==='search_procedures')reply={result:[]};\n else reply={result:{}};\n socket.write(JSON.stringify({id:q.id,...reply})+'\\n');\n }});\n});server.listen(value('REA_SOCKET'));\n",{mode:0o700}); await copyFile('/usr/bin/true',join(root,'sample')); try { for(const kind of ['strings','procedures']) { for(const mode of ['capability_unavailable','bridge_exception','valid']) { for(let repeat=1;repeat<=2;repeat++) { const home=await mkdtemp(join(root,'home-')),trace=join(home,'trace'); const args=['scripts/rea.mjs','search',join(root,'sample'),'fixture','--provider','hopper','--kind',kind,'--mode','regex','--json']; const env={HOME:home,TMPDIR:home,PATH:root+':'+dirname(process.execPath)+':/usr/bin:/bin:/usr/sbin:/sbin',HOPPER_LAUNCHER_PATH:launcher,REA_LOG_LEVEL:'silent',FIXTURE_MODE:mode,FIXTURE_TRACE:trace}; const child=spawn(process.execPath,args,{env}); let stdout='',stderr=''; child.stdout.on('data',x=>stdout+=x); child.stderr.on('data',x=>stderr+=x); const exit=await new Promise((resolve,reject)=>{child.on('error',reject);child.on('close',resolve);}); const output=JSON.parse(stdout),calls=(await readFile(trace,'utf8')).trim().split('\n'); assert.equal(stderr,''); const requested='search_'+kind,inventory='list_'+kind; assert.deepEqual(calls,['health',inventory,'shutdown_document']); if(mode==='valid') { assert.equal(exit,0); assert.equal(output.operation,requested); assert.deepEqual(output.normalized_result,[{address:'0x1000',value:'fixture'}]); } else { assert.equal(exit,1); assert.equal(output.code,mode==='capability_unavailable'?'capability_unavailable':'execution_failure'); assert.equal(output.details.operation,inventory); if(mode==='bridge_exception')assert(output.message.includes(inventory)); } console.log(JSON.stringify({kind,mode,repeat,exit,code:output.code??null,operation:output.details?.operation??output.operation,calls})); } } } } finally {await rm(root,{recursive:true,force:true});} NODE ``` 3. Each build completes twelve invocations: eight failures, covering both search kinds and both injected failure types twice, and four successful controls. The script asserts the observed faulty attribution to reproduce the current behavior; when checking restoration, expect the requested `search_` operation in those failure assertions instead. ### Expected behavior An inventory failure returned for an accepted regex search should retain the caller's `search_strings` or `search_procedures` identity while preserving the provider failure classification, reason, request context and cleanup result. The CLI selects those search operations, successful controls report them, and the adjacent malformed-inventory and cancellation paths already attribute failures to them. The selected-runtime failure contract says these failures are reported at the operation that needs the runtime. ### Impact and scope The structured error misidentifies the accepted search operation in all sixteen injected failures across both builds. A machine-readable consumer receives an inventory-operation identity for its search request. The search still fails when the provider cannot supply inventory; no successful data was discarded. Eight successful controls passed. Real Hopper occurrence frequency and downstream automation consequences were not measured. No target mutation, data loss or security boundary crossing was observed. - Impact level: P2 - Assessment status: supported - Impact basis: The public error's machine-readable operation identity refers to an internal request rather than the accepted search operation under two bounded provider failure classes. - Workaround status: unverified - Workaround basis: Successful provider replies avoid the trigger, but no practical workaround preserving the same failing regex search was verified. ### REA version Current main source commit `1e36e707b1f991fde826947bab04d436e64b7f97`, package version 6.5.0, built from locked dependencies; separately installed published npm package `rea-agents@6.5.0`, identified by the npm registry as the latest published release. ### Runtime and platform Node.js v24.18.0; macOS 27.0.1, Darwin arm64. The source build used repository-pinned npm 11.16.0. Both builds used the simulated bridge described above. ### Target and artifact context A scratch copy of the system Mach-O universal `true` executable supplies target admission. The simulated provider supplies one synthetic string or procedure record at address `0x1000`. Authentication values come from the test invocation's generated bootstrap and are never printed. No private target data is required. ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence - Expected source: src/cli/coreBinaryCommands.ts:487-510 selects the caller operation; src/hopper/HopperRegexSearch.ts:99-107 retains it for adjacent failures; docs/mcp-contracts.md:521-525 states the selected-runtime failure contract. - Failure source: src/hopper/HopperProvider.ts:310-317 routes regex searches to src/hopper/HopperRegexSearch.ts:90-97, which returns the inventory failure unchanged; src/hopper/HopperClient.ts:607-624 and src/hopper/HopperRequestQueue.ts:397-403 attach the inventory identity. The public CLI observations below establish the delivered result. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete Public commands invoked by the fixture, with its generated target path abbreviated as `sample`: ```sh node scripts/rea.mjs search sample fixture --provider hopper --kind strings --mode regex --json node scripts/rea.mjs search sample fixture --provider hopper --kind procedures --mode regex --json ``` Smallest meaningful results, observed twice for every row on each build: ```text kind provider reply exit code reported operation strings capability_unavailable 1 capability_unavailable list_strings strings bridge_exception 1 execution_failure list_strings strings valid 0 successful Evidence search_strings procedures capability_unavailable 1 capability_unavailable list_procedures procedures bridge_exception 1 execution_failure list_procedures procedures valid 0 successful Evidence search_procedures ``` The ordinary error messages were `Hopper list_strings failed (-32000, bridge_exception): fixture inventory unavailable` and `Hopper list_procedures failed (-32000, bridge_exception): fixture inventory unavailable`. Capability refusals retained `details.reason: "fixture inventory unavailable"`. Every trace contained `health`, the selected inventory operation, and `shutdown_document`; child stderr was empty. Successful controls returned the expected fixture record. These results establish REA's public behavior for simulated provider replies, not that a real Hopper bridge emits those replies. ### Typed outcome or recovery expected Replay the same provider failures and require exit 1 with `details.operation` equal to `search_strings` or `search_procedures`, while retaining each failure code and diagnostic context. Ordinary error messages should identify that accepted search. The valid controls must continue returning exit 0, the same matching fixture record, canonical search operation and completed cleanup. A direct inventory request, if separately exercised, must retain its own inventory identity. ### Analysis or suspected cause Source-derived reasoning: the Hopper provider routes regex searches to a local matcher that first obtains an inventory. Its failure branch returns the inventory error unchanged. Capability conversion and remote-error request context label that error with the wire method, so the inventory name reaches the public result. The malformed-inventory branch already retains the original search operation. ### Additional context Related [#4607](https://github.com/morluto/rea/issues/4607), [#4614](https://github.com/morluto/rea/issues/4614) and [#4634](https://github.com/morluto/rea/issues/4634) concern independent Cutter and IDA attribution paths. [#4375](https://github.com/morluto/rea/issues/4375) concerns Hopper startup diagnostic loss, rather than search operation identity. Open and closed Hopper/search/inventory/operation issue and PR searches, including the consolidation index [#4330](https://github.com/morluto/rea/issues/4330) and subsystem index [#3537](https://github.com/morluto/rea/issues/3537), found no matching report. MCP, timeout behavior and real-engine occurrence were not exercised. No regression range is known.
Author
Owner

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

Published in 5853089885 on main.

The regex adapter returned inventory errors unchanged. Capability conversion also dropped the underlying request context. The fix attributes typed failures to the accepted search operation while preserving the original inventory method, request ID, bridge code/type, captured facts and live cleanup dependencies. Both post-inventory cancellation checkpoints retain the caller’s exact reason; a later cancellation does not replace an already produced physical failure.

Validation executed:

  • 114 focused checks in nine files, including six public CLI invocations (both search kinds × capability refusal, ordinary bridge error and success), real socket/child transport fixtures, provider projections, protocol, deadlines and cleanup retry.
  • A subsequent 31 checks in four files, including the expanded 15 source controls, error-schema conformance and existing official MCP SDK tool/argument controls. These overlap the earlier run and are not additive coverage.
  • check:fast, docs:check (including five README checks), and normal commit/pre-push hooks.

The CLI fixture waits for transport-close completion instead of terminating on a timer. Direct inventory capability checks retain their own inventory operation. Source controls preserve failed cleanup ownership through retry, typed timeout/process facts, opaque cancellation reasons and physical-failure precedence.

Scope: simulated Hopper bridge replies on macOS, with production CLI admission/bootstrap/transport/cleanup and existing MCP contracts exercised. No real Hopper engine or Windows runtime was used; the Hopper-specific failure was not replayed through MCP. Performance/token/peak-memory costs remain unmeasured; no performance improvement is claimed. The broader audit remains in progress.

<!-- gh-comment-id:6230028064 --> @morluto commented on GitHub (Oct 17, 2026): Published in 58530898852d3dc5c7415afac1b92d3fec2f8fb5 on main. The regex adapter returned inventory errors unchanged. Capability conversion also dropped the underlying request context. The fix attributes typed failures to the accepted search operation while preserving the original inventory method, request ID, bridge code/type, captured facts and live cleanup dependencies. Both post-inventory cancellation checkpoints retain the caller’s exact reason; a later cancellation does not replace an already produced physical failure. Validation executed: - 114 focused checks in nine files, including six public CLI invocations (both search kinds × capability refusal, ordinary bridge error and success), real socket/child transport fixtures, provider projections, protocol, deadlines and cleanup retry. - A subsequent 31 checks in four files, including the expanded 15 source controls, error-schema conformance and existing official MCP SDK tool/argument controls. These overlap the earlier run and are not additive coverage. - `check:fast`, `docs:check` (including five README checks), and normal commit/pre-push hooks. The CLI fixture waits for transport-close completion instead of terminating on a timer. Direct inventory capability checks retain their own inventory operation. Source controls preserve failed cleanup ownership through retry, typed timeout/process facts, opaque cancellation reasons and physical-failure precedence. Scope: simulated Hopper bridge replies on macOS, with production CLI admission/bootstrap/transport/cleanup and existing MCP contracts exercised. No real Hopper engine or Windows runtime was used; the Hopper-specific failure was not replayed through MCP. Performance/token/peak-memory costs remain unmeasured; no performance improvement is claimed. The broader audit remains in progress.
Author
Owner

@coygeek commented on GitHub (Oct 18, 2026):

Closing as addressed on main by 585308988. Hopper regex inventory failures now identify search_strings or search_procedures and preserve the original bridge request context, failure classification and cleanup ownership. I verified the committed source and regression coverage; I have not rerun the runtime reproduction.

<!-- gh-comment-id:6244108913 --> @coygeek commented on GitHub (Oct 18, 2026): Closing as addressed on `main` by [585308988](https://github.com/morluto/rea/commit/58530898852d3dc5c7415afac1b92d3fec2f8fb5). Hopper regex inventory failures now identify search_strings or search_procedures and preserve the original bridge request context, failure classification and cleanup ownership. I verified the committed source and regression coverage; I have not rerun the runtime reproduction.
Sign in to join this conversation.
No milestone
No project
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#2438
No description provided.