morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #6714] [Bug] Signal decoder search omits an exact Greek sigma substring in catalog names and help #4083

New issue

Closed

opened 2026-10-31 00:46:41 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:46:41 +00:00

Owner

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

Before submitting

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

Area

Provider or capability discovery

Observed behavior

inspect_signal_decoders uses parseDecoderDiscovery to filter decoder names and help lines. When the producer text contains ΟΣ, the valid query Σ returns no rows and matching: 0, although the text contains that exact uppercase character. The whole-word query ΟΣ, empty query, and ASCII case-insensitive control work in both catalog and help modes.

This is an executed production-parser reproduction using synthetic producer text and the real public input schema. A sigrok installation, CLI/MCP transports, and hardware were not exercised. The adapter reach described below is source-derived.

Reproduction

Run this from the source checkout after installing its locked dependencies. This exact eight-case probe was executed once before drafting:

node --import tsx --input-type=module <<'JS'
import {parseDecoderDiscovery} from './src/signals/parseDecoderDiscovery.ts';
import {inspectSignalDecodersInputSchema} from './src/domain/signals/signalDecoders.ts';
for (const [decoder,text] of [
 [null,'Supported protocol decoders:\n  sample  ΟΣ\n  control  ASCII\n'],
 ['sample','ID: sample\nName: ΟΣ\nDescription: ASCII\n']
]) {
 for(const query of ['', 'Σ', 'ΟΣ', 'ascii']) {
  const input=inspectSignalDecodersInputSchema.parse({decoder,query,limit:null});
  const result=parseDecoderDiscovery(text,input);
  console.log(JSON.stringify({decoder,query,exactSubstring:text.includes(query),...result}));
 }
}
JS

Expected behavior

The public query schema promises a case-insensitive literal substring in decoder names or help lines. Relaxing case sensitivity must preserve an exact literal match. These strings and both selectors pass that schema; the parser accepts their catalog/help framing. No expectation about decoding signals or executing the selected protocol is involved.

Impact and scope

Decoder discovery can omit matching names or help lines when Greek sigma is word-final. Both demonstrated searches report zero matches rather than a limitation. The observed scope is the two synthetic producer-text fixtures; prevalence in real installed decoders and end-to-end sigrok behavior are unknown. Empty-query controls retained every fixture row, providing a parser-level workaround: request the full catalog/help and read the original text.

REA version

Package manifest 6.7.0; executed source revision 8c4f96ef4759fd78da66c4b9726825ca71d7ee0c. Before drafting, source comparison confirmed the parser and input schema are identical in the latest published release tag rea-agents-6.7.0; the published npm artifact was not executed.

Runtime and platform

Node.js v26.12.1; Linux x64; repository-locked tsx. No external analysis provider was launched.

Target and artifact context

In-memory catalog and help text with a valid ASCII decoder ID and a Unicode display name. No recording, executable target, or sensitive data.

Interface

Other

Earliest failure stage

Transport or result projection

Relevant output or evidence

The failing catalog row and its whole-word control were:

{"decoder":null,"query":"Σ","exactSubstring":true,"decoders":[],"help_lines":[],"output_window":{"unit":"decoders","examined":2,"matching":0,"returned":0,"has_more":false}}
{"decoder":null,"query":"ΟΣ","exactSubstring":true,"decoders":[{"id":"sample","name":"ΟΣ"}],"help_lines":[],"output_window":{"unit":"decoders","examined":2,"matching":1,"returned":1,"has_more":false}}

The failing help row and its whole-word control were:

{"decoder":"sample","query":"Σ","exactSubstring":true,"decoders":[],"help_lines":[],"output_window":{"unit":"help-lines","examined":3,"matching":0,"returned":0,"has_more":false}}
{"decoder":"sample","query":"ΟΣ","exactSubstring":true,"decoders":[],"help_lines":[{"line_number":2,"text":"Name: ΟΣ"}],"output_window":{"unit":"help-lines","examined":3,"matching":1,"returned":1,"has_more":false}}

The empty-query controls returned two catalog rows and three help lines. Query ascii returned the uppercase ASCII row in each mode. The command exited 0. These are direct parser observations; they do not establish a real installed decoder's output.

Source-derived public reach: the sigrok adapter passes the selected tool's stdout directly to this parser. The CLI command and MCP contract expose the same query without an ASCII restriction on names/help.

Typed outcome or recovery expected

Return the matching catalog row or original help line for Σ, with matching: 1, while retaining the passing whole-word, empty-query and ASCII controls. This is the proposed restoration check, not a claim that a fix was tested.

Analysis or suspected cause

Source-derived: the parser lowercases the query separately from each complete name/help line. Contextual lowercasing produces ος for ΟΣ and σ for the standalone query Σ; includes therefore rejects an exact source substring.

Additional context

Related #6634 covers the separate native analysisSearchPredicate used by IDA/Kuna. Decoder discovery implements its own filter and does not call that helper; fixing only the native matcher leaves this catalog/help failure. Open and closed searches for sigrok sigma, decoder Unicode, and signal/substring reports found no decoder-specific match during investigation. NOT_ENOUGH_INFO: real-world decoder prevalence and the first affected release were not established.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: The production discovery parser omits an exact matching decoder/help row and reports zero matches for two accepted inputs. The demonstrated effect is bounded to search results.
Workaround status: available
Workaround basis: In the same parser probe, an empty query retained all original rows, allowing the caller to read the full catalog/help. A real sigrok/CLI/MCP workflow was not run.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6714 ### 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 Provider or capability discovery ### Observed behavior `inspect_signal_decoders` uses `parseDecoderDiscovery` to filter decoder names and help lines. When the producer text contains `ΟΣ`, the valid query `Σ` returns no rows and `matching: 0`, although the text contains that exact uppercase character. The whole-word query `ΟΣ`, empty query, and ASCII case-insensitive control work in both catalog and help modes. This is an executed production-parser reproduction using synthetic producer text and the real public input schema. A sigrok installation, CLI/MCP transports, and hardware were not exercised. The adapter reach described below is source-derived. ### Reproduction Run this from the source checkout after installing its locked dependencies. This exact eight-case probe was executed once before drafting: ```sh node --import tsx --input-type=module <<'JS' import {parseDecoderDiscovery} from './src/signals/parseDecoderDiscovery.ts'; import {inspectSignalDecodersInputSchema} from './src/domain/signals/signalDecoders.ts'; for (const [decoder,text] of [ [null,'Supported protocol decoders:\n sample ΟΣ\n control ASCII\n'], ['sample','ID: sample\nName: ΟΣ\nDescription: ASCII\n'] ]) { for(const query of ['', 'Σ', 'ΟΣ', 'ascii']) { const input=inspectSignalDecodersInputSchema.parse({decoder,query,limit:null}); const result=parseDecoderDiscovery(text,input); console.log(JSON.stringify({decoder,query,exactSubstring:text.includes(query),...result})); } } JS ``` ### Expected behavior The [public query schema](https://github.com/morluto/rea/blob/8c4f96ef4759fd78da66c4b9726825ca71d7ee0c/src/domain/signals/signalDecoders.ts#L14-L20) promises a case-insensitive literal substring in decoder names or help lines. Relaxing case sensitivity must preserve an exact literal match. These strings and both selectors pass that schema; the parser accepts their catalog/help framing. No expectation about decoding signals or executing the selected protocol is involved. ### Impact and scope Decoder discovery can omit matching names or help lines when Greek sigma is word-final. Both demonstrated searches report zero matches rather than a limitation. The observed scope is the two synthetic producer-text fixtures; prevalence in real installed decoders and end-to-end sigrok behavior are unknown. Empty-query controls retained every fixture row, providing a parser-level workaround: request the full catalog/help and read the original text. ### REA version Package manifest 6.7.0; executed source revision `8c4f96ef4759fd78da66c4b9726825ca71d7ee0c`. Before drafting, source comparison confirmed the parser and input schema are identical in the latest published release tag `rea-agents-6.7.0`; the published npm artifact was not executed. ### Runtime and platform Node.js v26.12.1; Linux x64; repository-locked tsx. No external analysis provider was launched. ### Target and artifact context In-memory catalog and help text with a valid ASCII decoder ID and a Unicode display name. No recording, executable target, or sensitive data. ### Interface Other ### Earliest failure stage Transport or result projection ### Relevant output or evidence The failing catalog row and its whole-word control were: ```json {"decoder":null,"query":"Σ","exactSubstring":true,"decoders":[],"help_lines":[],"output_window":{"unit":"decoders","examined":2,"matching":0,"returned":0,"has_more":false}} {"decoder":null,"query":"ΟΣ","exactSubstring":true,"decoders":[{"id":"sample","name":"ΟΣ"}],"help_lines":[],"output_window":{"unit":"decoders","examined":2,"matching":1,"returned":1,"has_more":false}} ``` The failing help row and its whole-word control were: ```json {"decoder":"sample","query":"Σ","exactSubstring":true,"decoders":[],"help_lines":[],"output_window":{"unit":"help-lines","examined":3,"matching":0,"returned":0,"has_more":false}} {"decoder":"sample","query":"ΟΣ","exactSubstring":true,"decoders":[],"help_lines":[{"line_number":2,"text":"Name: ΟΣ"}],"output_window":{"unit":"help-lines","examined":3,"matching":1,"returned":1,"has_more":false}} ``` The empty-query controls returned two catalog rows and three help lines. Query `ascii` returned the uppercase `ASCII` row in each mode. The command exited 0. These are direct parser observations; they do not establish a real installed decoder's output. Source-derived public reach: [the sigrok adapter passes the selected tool's stdout directly to this parser](https://github.com/morluto/rea/blob/8c4f96ef4759fd78da66c4b9726825ca71d7ee0c/src/signals/SigrokRecordingProvider.ts#L299-L309). The [CLI command](https://github.com/morluto/rea/blob/8c4f96ef4759fd78da66c4b9726825ca71d7ee0c/src/cli/signalCommands.ts#L27-L68) and MCP contract expose the same query without an ASCII restriction on names/help. ### Typed outcome or recovery expected Return the matching catalog row or original help line for `Σ`, with `matching: 1`, while retaining the passing whole-word, empty-query and ASCII controls. This is the proposed restoration check, not a claim that a fix was tested. ### Analysis or suspected cause Source-derived: [the parser lowercases the query separately from each complete name/help line](https://github.com/morluto/rea/blob/8c4f96ef4759fd78da66c4b9726825ca71d7ee0c/src/signals/parseDecoderDiscovery.ts#L23-L54). Contextual lowercasing produces `ος` for `ΟΣ` and `σ` for the standalone query `Σ`; `includes` therefore rejects an exact source substring. ### Additional context Related [#6634](https://github.com/morluto/rea/issues/6634) covers the separate native `analysisSearchPredicate` used by IDA/Kuna. Decoder discovery implements its own filter and does not call that helper; fixing only the native matcher leaves this catalog/help failure. Open and closed searches for `sigrok sigma`, `decoder Unicode`, and signal/substring reports found no decoder-specific match during investigation. NOT_ENOUGH_INFO: real-world decoder prevalence and the first affected release were not established. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: The production discovery parser omits an exact matching decoder/help row and reports zero matches for two accepted inputs. The demonstrated effect is bounded to search results. - Workaround status: available - Workaround basis: In the same parser probe, an empty query retained all original rows, allowing the caller to read the full catalog/help. A real sigrok/CLI/MCP workflow was not run.

bsakaguchi closed this issue

2026-10-31 00:46:41 +00:00

bsakaguchi referenced this issue

2026-10-31 01:11:25 +00:00

[PR #4083] perf(cli): skip command schemas for standalone version queries #6045

bsakaguchi referenced this issue

2026-11-03 00:29:36 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425

bsakaguchi referenced this issue

2026-11-04 00:49:08 +00:00

[GH-ISSUE #3813] perf: CLI startup and doctor catalog digests make clientProfileLifecycle time out on CI #1475

bsakaguchi referenced this issue