morluto/rea

Fork 0

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

[GH-ISSUE #8471] [Design] Distinguish local value flow from call-resolution availability #6618

New issue

Open

opened 2026-11-01 21:12:43 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:43 +00:00

Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8471

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

How should binary_session.tool_availability distinguish a missing native def-use model from missing call-target resolution, while accurately reporting useful local-only value tracing?

Context and evidence

On REA main a6caa79bf4f393c02601fbf2f6df246eae0b1558, Node 24.22.1 and macOS arm64, I opened a source-owned x86-64 Mach-O through Kuna 1.986. Public stdio MCP binary_session({detail:"complete"}) reported trace_native_values unavailable, reason: "provider_missing", with remediation Configure a provider for required operation resolve_native_call_targets. The same actual call to trace_native_values succeeded, with zero nodes/edges, one procedure and the explicit unknown Provider has no native def-use model; its source analyze_function dossier had native_value_flow: null. Both full and compact advertised schema profiles produced those facts.

On the same unchanged, unexecuted target in a fresh Ghidra 12.1.4/JDK 21 session, availability was true, the dossier had an available value-flow model, and the trace returned 39 nodes and 46 edges. Compact advertised-schema validation passed. This is one selected procedure on one host, not an agent-selection study or a general provider comparison. The Kuna result does not establish useful value tracing; its unknown correctly qualifies the empty graph. On a separate source-owned arm64 import fixture with Ghidra marked available, directly tracing EXTERNAL:0x1 returned an explicit no-HighFunction-model unknown and no nodes. Provider-level support therefore cannot guarantee that every selected function has a value model; see #8476 for the separate thunk-boundary issue.

In a separate public MCP controlled-provider experiment, the provider declared analyze_function but no call-target resolver and supplied captured real Ghidra dossiers. Full and compact profiles both reported the workflow unavailable. The call-containing dossier still returned 4 local nodes and 3 edges with one explicit call-resolution unknown. A second captured no-call leaf returned 7 nodes and 5 edges with no unknowns; no call resolver was needed for that selected procedure. Both outputs passed their fetched advertised schemas. This is a simulated provider using real captured input, not evidence that another real provider offers that capability. It demonstrates that local value flow and cross-function resolution can be distinct outcomes.

Source-derived explanation: CapabilityInventory.ts declares analyze_function and resolve_native_call_targets as requirements. NativeValueTrace.ts inspects the dossier's optional value flow, emits an unknown and continues without resolving calls when the model is absent; call resolution only occurs for retained call operations. Thus the reported missing resolver is true but does not identify the earlier missing value model. The MCP contract asks callers to use availability to choose operations, while separately noting that discovery need not block qualified direct invocation.

Expected interaction with targets

No target interaction for the discovery-design question. The controls read the local fixture and launched existing headless providers; the target was not executed or modified.

Boundary details

Keep provider selection explicit. Preserve the observed graph, source identity and unknowns. Distinguish a callable qualified result, lack of the core value-flow facet, and optional cross-function call-target coverage. Do not infer zero dependencies from zero nodes or claim that installing a call-target resolver alone supplies a def-use model.

Options and tradeoffs

Add a provider-owned, typed indication of value-flow support and use it in discovery, if that facet can be declared truthfully across targets and provider states.
Clarify availability/remediation to describe the missing core facet and that a direct call may still return an unknown-qualified result, while retaining the current conservative unavailable status.
Keep existing behavior if availability is explicitly defined as useful complete workflow capability, but make the explanation accurate. Avoid adding a provider API wrapper solely for parity.

The best representation and whether the extra distinction justifies schema/context cost are open questions; no implementation is proposed as proven here.

Verification available so far

I have observed results.

Success criteria and open questions

Test both current-provider capabilities and actual public calls, including Ghidra with value flow, Kuna with no model, a value model without call-target resolution (the public MCP experiment above is not yet a committed regression), and a per-function failure or empty model. Verify summary and complete discovery, full/compact schemas, unchanged target selection, and unknown/provenance retention. Determine whether these statuses express callability, useful partial operation, or complete prerequisites; do not silently alter existing callers' interpretation.

References

Related to #8322 (different target-specific discovery mismatch), #8358 (call-argument coverage) and #8282 (source Evidence closure). @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Current Kuna 1.989 and explicit facet-unavailability control

On #8785 head 465e8b1e0 with the same self-built, unexecuted arm64 Mach-O used in #8783, I called binary_session(detail: complete) and then trace_native_values for the same procedure in real stdio MCP sessions, with compact and full input/output profiles. Kuna 1.989 discovery still reported available: false, reason: provider_missing, and remediation to configure resolve_native_call_targets. The direct trace succeeded with no nodes and an explicit unknown: REA's Kuna provider does not report native def-use observations. Real Ghidra 12.1.4 discovery on the same fixture was available and its direct trace returned nine nodes and no unknowns. The target SHA-256 stayed c244f7d7d9fa9b7f4cfcb1f69d69cc1f83ad98fe38b0293b223b3ca7d9076363.

The provider-specific dossier fix improves the result's explanation but does not change discovery: CapabilityInventory still composes operation requirements and does not express whether an analyze_function dossier supplies value flow. Do not infer provider-level support from a single dossier or claim that the optional call resolver alone would provide a value model. This is one target and host, not a completeness or agent-selection measurement.

Capability ownership and projection boundary

Source inspection on #8785 465e8b1e0: CapabilityDescriptor declares an operation, readiness, effects and limitations, but no typed declaration for a dossier facet. BinarySessionStatus.providerCapabilitySets groups those facts for session output, and expandProviderCapabilities reconstructs operation descriptors before CapabilityInventory evaluates the required operations. The existing trace_native_values composition therefore cannot distinguish an analyze_function implementation that can supply a value-flow model from one that does not, except by interpreting prose or executing a function. #8785's explicit per-dossier unavailability fixes the returned observation, not this static capability boundary.

A candidate design should put any declared support/absence at the provider capability owner, preserve it through grouped status serialization and expansion, and use an explicit unknown when a provider does not declare the facet. “Provider can supply value flow” must mean the operation may produce it, not that every selected function will have a model: the real Ghidra external-function control in #8785 returns an explicit function-specific unavailable reason. Model local value flow separately from optional cross-function call resolution; preserve the current direct-call unknowns and target/provider selection. This is a proposed direction, not a validated schema or implementation. Verify full and compact SDK catalogs, grouping/ungrouping, provider readiness failures, unknown third-party capabilities, and the existing captured-dossier local-only controls before changing the meaning of available.

Summary discovery control

The same real-provider control was repeated using binary_session(detail: summary) rather than complete discovery. In compact and full MCP input/output profiles, Kuna 1.989 still reported trace_native_values unavailable with remediation to configure resolve_native_call_targets; the actual trace returned zero nodes and the explicit REA Kuna value-flow-unavailable unknown. Ghidra 12.1.4 summary reported available and the same requested trace returned nine nodes with no unknowns. The unexecuted target SHA-256 remained c244f7d7d9fa9b7f4cfcb1f69d69cc1f83ad98fe38b0293b223b3ca7d9076363. Thus this is visible on both session detail levels for this fixture, not only in the complete inventory. It does not establish general graph completeness or measure an agent's tool selection.

Existing mode contract and local-trace boundary

Source inspection at #8785 465e8b1e0 adds two constraints to a possible implementation. First, toolAvailabilityMode requires available: false to carry at least one missing_operations entry, while an available mode requires that list to be empty; it has no unknown state or typed missing-facet field. Encoding a missing value-flow facet as a made-up operation would misrepresent the provider contract. Any schema change needs to preserve the distinction between absent declaration, explicitly unavailable facet, and an unhealthy or missing operation through compact/full status grouping and SDK conversion.

Second, trace_native_values has no explicit local-only mode. Its max_depth: 0 limits expansion into callees, but the workflow still attempts resolve_native_call_targets for retained CALL/CALLIND operations before applying the depth check. Without that operation it can still return the already collected local graph plus a call-resolution unknown, as shown by the captured-dossier control above. That is a partial outcome, not proof that the caller selected a standalone local-only mode. A discovery redesign should describe that actual behavior or deliberately add and verify a distinct caller choice; it should not label max_depth: 0 as suppressing call resolution.

Real depth-zero call-resolution control

With real Ghidra 12.1.4 on an unexecuted arm64 Mach-O, trace_native_values for _audit_caller with max_depth: 0 and max_functions: 1 returned five local nodes plus a direct call edge from 0x1000003f4 to _audit_leaf at 0x1000003c0. It separately reported the call-depth budget and unavailable callee parameter bindings as unknowns. Both compact and full stdio MCP profiles produced this result, and target SHA-256 remained 510a23fc3c152175b9977130b3b1711d580e47d22a085cdee6a4e0c9dea2c51a. This real control supports the source-derived distinction above: zero depth prevents callee expansion but does not suppress call-target resolution. It is one function and host, not a completeness or runtime execution claim.

Unmerged provider-declaration prototype

In an isolated, uncommitted checkout based on #8785 465e8b1e0, I prototyped a typed analyze_function value-flow declaration (supported, unavailable with reason, or undeclared), preserved it through provider-capability grouping/expansion, and exposed a separate value_flow_support fact on the trace's availability group. Undeclared providers projected unknown; it did not fabricate a missing operation or expose a local-only mode. The prototype left the existing top-level available decision and remediation unchanged.

Real stdio MCP against the unexecuted arm64 Mach-O above returned unavailable with the REA Kuna reason for Kuna 1.989, and supported for Ghidra 12.1.4, in summary status in both compact and full input/output profiles. Fetched binary_session output schemas declared JSON Schema 2020-12; Ajv 2020 with strict and format checks disabled accepted the schemas and actual responses. Existing session-status and capability-inventory source tests passed (69 tests), and check:ci:fast passed. The target digest remained unchanged. This checks one fixture and host, not per-function capability or agent selection.

A separate synthetic provider with both required operations showed why the prototype is incomplete: when it declared value flow unavailable, the existing top-level availability still reported available: true with no remediation while the new fact said unavailable. With no facet declaration it also reported top-level available and the new fact unknown. For real Kuna, the old call-resolver remediation persisted alongside the new unavailable fact. A final design must decide and document whether top-level availability means operation callability or useful prerequisites, make its remediation consistent with that meaning, and avoid interpreting a provider's declared potential as a guarantee for every function. It also needs real local-without-resolver behavior, runtime/readiness and schema/client checks beyond this experiment. No production change or merge is proposed from this prototype alone.

Revised, still-unmerged availability experiment

I extended the isolated prototype to use the provider's typed declaration in the existing availability decision. A declared-unavailable value-flow facet now makes this workflow unavailable with the provider's reason and guidance to select a provider that can supply value flow; it separately notes that cross-function tracing needs call-target resolution. If value flow is declared supported but the resolver is missing, the explanation says a direct trace may still return local observations with call-resolution unknowns, without advertising a fictitious local-only mode. Undeclared facet support remains unknown. When the resolver is unhealthy, its owner-provided repair instruction remains present, including when value flow is also unavailable.

A synthetic nine-case capability matrix covered supported/unavailable/undeclared facet declarations crossed with present/missing/unhealthy resolver operations, including grouped summary and complete status expansion. Real Kuna 1.989 and Ghidra 12.1.4 binary_session summary controls in both schema profiles produced the intended facet states and more relevant Kuna remediation; their fetched 2020-12 output schemas and actual responses validated with Ajv 2020 (strict and format checks disabled). A real Ghidra external-function control still returned its function-specific no-HighFunction reason despite the provider's general ability to produce value flow. Existing capability/status source tests (69) and check:ci:fast passed.

This remains a prototype, not a production change: the boolean top-level available remains true when operation prerequisites are present but value-flow support is undeclared, with the separate unknown field qualifying it. Whether that accurately conveys the public contract needs review; so do descriptor scoping, mixed-provider routes, failure precedence, serialized context cost, actual partial local-flow behavior without a resolver and client compatibility. The typed declaration describes a provider's ability for some functions, never a guarantee for a particular function. No agent-selection or performance measurement was made.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8471 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed How should `binary_session.tool_availability` distinguish a missing native def-use model from missing call-target resolution, while accurately reporting useful local-only value tracing? ### Context and evidence On REA main `a6caa79bf4f393c02601fbf2f6df246eae0b1558`, Node 24.22.1 and macOS arm64, I opened a source-owned x86-64 Mach-O through Kuna 1.986. Public stdio MCP `binary_session({detail:"complete"})` reported `trace_native_values` unavailable, `reason: "provider_missing"`, with remediation `Configure a provider for required operation resolve_native_call_targets.` The same actual call to `trace_native_values` succeeded, with zero nodes/edges, one procedure and the explicit unknown `Provider has no native def-use model`; its source `analyze_function` dossier had `native_value_flow: null`. Both full and compact advertised schema profiles produced those facts. On the same unchanged, unexecuted target in a fresh Ghidra 12.1.4/JDK 21 session, availability was true, the dossier had an available value-flow model, and the trace returned 39 nodes and 46 edges. Compact advertised-schema validation passed. This is one selected procedure on one host, not an agent-selection study or a general provider comparison. The Kuna result does **not** establish useful value tracing; its unknown correctly qualifies the empty graph. On a separate source-owned arm64 import fixture with Ghidra marked available, directly tracing `EXTERNAL:0x1` returned an explicit no-HighFunction-model unknown and no nodes. Provider-level support therefore cannot guarantee that every selected function has a value model; see #8476 for the separate thunk-boundary issue. In a separate **public MCP controlled-provider** experiment, the provider declared `analyze_function` but no call-target resolver and supplied captured real Ghidra dossiers. Full and compact profiles both reported the workflow unavailable. The call-containing dossier still returned 4 local nodes and 3 edges with one explicit call-resolution unknown. A second captured no-call leaf returned 7 nodes and 5 edges with no unknowns; no call resolver was needed for that selected procedure. Both outputs passed their fetched advertised schemas. This is a simulated provider using real captured input, not evidence that another real provider offers that capability. It demonstrates that local value flow and cross-function resolution can be distinct outcomes. Source-derived explanation: `CapabilityInventory.ts` declares `analyze_function` and `resolve_native_call_targets` as requirements. `NativeValueTrace.ts` inspects the dossier's optional value flow, emits an unknown and continues without resolving calls when the model is absent; call resolution only occurs for retained call operations. Thus the reported missing resolver is true but does not identify the earlier missing value model. [The MCP contract](https://github.com/morluto/rea/blob/a6caa79bf4f393c02601fbf2f6df246eae0b1558/docs/mcp-contracts.md#L730) asks callers to use availability to choose operations, while separately noting that discovery need not block qualified direct invocation. ### Expected interaction with targets No target interaction for the discovery-design question. The controls read the local fixture and launched existing headless providers; the target was not executed or modified. ### Boundary details Keep provider selection explicit. Preserve the observed graph, source identity and unknowns. Distinguish a callable qualified result, lack of the core value-flow facet, and optional cross-function call-target coverage. Do not infer zero dependencies from zero nodes or claim that installing a call-target resolver alone supplies a def-use model. ### Options and tradeoffs - Add a provider-owned, typed indication of value-flow support and use it in discovery, if that facet can be declared truthfully across targets and provider states. - Clarify availability/remediation to describe the missing core facet and that a direct call may still return an unknown-qualified result, while retaining the current conservative unavailable status. - Keep existing behavior if availability is explicitly defined as useful complete workflow capability, but make the explanation accurate. Avoid adding a provider API wrapper solely for parity. The best representation and whether the extra distinction justifies schema/context cost are open questions; no implementation is proposed as proven here. ### Verification available so far I have observed results. ### Success criteria and open questions Test both current-provider capabilities and actual public calls, including Ghidra with value flow, Kuna with no model, a value model without call-target resolution (the public MCP experiment above is not yet a committed regression), and a per-function failure or empty model. Verify summary and complete discovery, full/compact schemas, unchanged target selection, and unknown/provenance retention. Determine whether these statuses express callability, useful partial operation, or complete prerequisites; do not silently alter existing callers' interpretation. ### References Related to #8322 (different target-specific discovery mismatch), #8358 (call-argument coverage) and #8282 (source Evidence closure). @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Current Kuna 1.989 and explicit facet-unavailability control On #8785 head `465e8b1e0` with the same self-built, unexecuted arm64 Mach-O used in #8783, I called `binary_session(detail: complete)` and then `trace_native_values` for the same procedure in real stdio MCP sessions, with compact and full input/output profiles. Kuna 1.989 discovery still reported `available: false`, `reason: provider_missing`, and remediation to configure `resolve_native_call_targets`. The direct trace succeeded with no nodes and an explicit unknown: `REA's Kuna provider does not report native def-use observations.` Real Ghidra 12.1.4 discovery on the same fixture was available and its direct trace returned nine nodes and no unknowns. The target SHA-256 stayed `c244f7d7d9fa9b7f4cfcb1f69d69cc1f83ad98fe38b0293b223b3ca7d9076363`. The provider-specific dossier fix improves the result's explanation but does not change discovery: `CapabilityInventory` still composes operation requirements and does not express whether an `analyze_function` dossier supplies value flow. Do not infer provider-level support from a single dossier or claim that the optional call resolver alone would provide a value model. This is one target and host, not a completeness or agent-selection measurement. ### Capability ownership and projection boundary Source inspection on #8785 `465e8b1e0`: `CapabilityDescriptor` declares an operation, readiness, effects and limitations, but no typed declaration for a dossier facet. `BinarySessionStatus.providerCapabilitySets` groups those facts for session output, and `expandProviderCapabilities` reconstructs operation descriptors before `CapabilityInventory` evaluates the required operations. The existing `trace_native_values` composition therefore cannot distinguish an `analyze_function` implementation that can supply a value-flow model from one that does not, except by interpreting prose or executing a function. #8785's explicit per-dossier unavailability fixes the returned observation, not this static capability boundary. A candidate design should put any declared support/absence at the provider capability owner, preserve it through grouped status serialization and expansion, and use an explicit unknown when a provider does not declare the facet. “Provider can supply value flow” must mean the operation may produce it, not that every selected function will have a model: the real Ghidra external-function control in #8785 returns an explicit function-specific unavailable reason. Model local value flow separately from optional cross-function call resolution; preserve the current direct-call unknowns and target/provider selection. This is a proposed direction, not a validated schema or implementation. Verify full and compact SDK catalogs, grouping/ungrouping, provider readiness failures, unknown third-party capabilities, and the existing captured-dossier local-only controls before changing the meaning of `available`. ### Summary discovery control The same real-provider control was repeated using `binary_session(detail: summary)` rather than complete discovery. In compact and full MCP input/output profiles, Kuna 1.989 still reported `trace_native_values` unavailable with remediation to configure `resolve_native_call_targets`; the actual trace returned zero nodes and the explicit REA Kuna value-flow-unavailable unknown. Ghidra 12.1.4 summary reported available and the same requested trace returned nine nodes with no unknowns. The unexecuted target SHA-256 remained `c244f7d7d9fa9b7f4cfcb1f69d69cc1f83ad98fe38b0293b223b3ca7d9076363`. Thus this is visible on both session detail levels for this fixture, not only in the complete inventory. It does not establish general graph completeness or measure an agent's tool selection. ### Existing mode contract and local-trace boundary Source inspection at #8785 `465e8b1e0` adds two constraints to a possible implementation. First, `toolAvailabilityMode` requires `available: false` to carry at least one `missing_operations` entry, while an available mode requires that list to be empty; it has no unknown state or typed missing-facet field. Encoding a missing value-flow facet as a made-up operation would misrepresent the provider contract. Any schema change needs to preserve the distinction between absent declaration, explicitly unavailable facet, and an unhealthy or missing operation through compact/full status grouping and SDK conversion. Second, `trace_native_values` has no explicit local-only mode. Its `max_depth: 0` limits expansion into callees, but the workflow still attempts `resolve_native_call_targets` for retained CALL/CALLIND operations before applying the depth check. Without that operation it can still return the already collected local graph plus a call-resolution unknown, as shown by the captured-dossier control above. That is a partial outcome, not proof that the caller selected a standalone local-only mode. A discovery redesign should describe that actual behavior or deliberately add and verify a distinct caller choice; it should not label `max_depth: 0` as suppressing call resolution. ### Real depth-zero call-resolution control With real Ghidra 12.1.4 on an unexecuted arm64 Mach-O, `trace_native_values` for `_audit_caller` with `max_depth: 0` and `max_functions: 1` returned five local nodes plus a `direct` call edge from `0x1000003f4` to `_audit_leaf` at `0x1000003c0`. It separately reported the call-depth budget and unavailable callee parameter bindings as unknowns. Both compact and full stdio MCP profiles produced this result, and target SHA-256 remained `510a23fc3c152175b9977130b3b1711d580e47d22a085cdee6a4e0c9dea2c51a`. This real control supports the source-derived distinction above: zero depth prevents callee expansion but does not suppress call-target resolution. It is one function and host, not a completeness or runtime execution claim. ### Unmerged provider-declaration prototype In an isolated, uncommitted checkout based on #8785 `465e8b1e0`, I prototyped a typed `analyze_function` value-flow declaration (`supported`, `unavailable` with reason, or undeclared), preserved it through provider-capability grouping/expansion, and exposed a separate `value_flow_support` fact on the trace's availability group. Undeclared providers projected `unknown`; it did not fabricate a missing operation or expose a local-only mode. The prototype left the existing top-level `available` decision and remediation unchanged. Real stdio MCP against the unexecuted arm64 Mach-O above returned `unavailable` with the REA Kuna reason for Kuna 1.989, and `supported` for Ghidra 12.1.4, in summary status in both compact and full input/output profiles. Fetched `binary_session` output schemas declared JSON Schema 2020-12; Ajv 2020 with strict and format checks disabled accepted the schemas and actual responses. Existing session-status and capability-inventory source tests passed (69 tests), and `check:ci:fast` passed. The target digest remained unchanged. This checks one fixture and host, not per-function capability or agent selection. A separate synthetic provider with both required operations showed why the prototype is incomplete: when it declared value flow unavailable, the existing top-level availability still reported `available: true` with no remediation while the new fact said unavailable. With no facet declaration it also reported top-level available and the new fact unknown. For real Kuna, the old call-resolver remediation persisted alongside the new unavailable fact. A final design must decide and document whether top-level availability means operation callability or useful prerequisites, make its remediation consistent with that meaning, and avoid interpreting a provider's declared potential as a guarantee for every function. It also needs real local-without-resolver behavior, runtime/readiness and schema/client checks beyond this experiment. No production change or merge is proposed from this prototype alone. ### Revised, still-unmerged availability experiment I extended the isolated prototype to use the provider's typed declaration in the existing availability decision. A declared-unavailable value-flow facet now makes this workflow unavailable with the provider's reason and guidance to select a provider that can supply value flow; it separately notes that cross-function tracing needs call-target resolution. If value flow is declared supported but the resolver is missing, the explanation says a direct trace may still return local observations with call-resolution unknowns, without advertising a fictitious local-only mode. Undeclared facet support remains `unknown`. When the resolver is unhealthy, its owner-provided repair instruction remains present, including when value flow is also unavailable. A synthetic nine-case capability matrix covered supported/unavailable/undeclared facet declarations crossed with present/missing/unhealthy resolver operations, including grouped summary and complete status expansion. Real Kuna 1.989 and Ghidra 12.1.4 `binary_session` summary controls in both schema profiles produced the intended facet states and more relevant Kuna remediation; their fetched 2020-12 output schemas and actual responses validated with Ajv 2020 (strict and format checks disabled). A real Ghidra external-function control still returned its function-specific no-HighFunction reason despite the provider's general ability to produce value flow. Existing capability/status source tests (69) and `check:ci:fast` passed. This remains a prototype, not a production change: the boolean top-level `available` remains true when operation prerequisites are present but value-flow support is undeclared, with the separate `unknown` field qualifying it. Whether that accurately conveys the public contract needs review; so do descriptor scoping, mixed-provider routes, failure precedence, serialized context cost, actual partial local-flow behavior without a resolver and client compatibility. The typed declaration describes a provider's ability for some functions, never a guarantee for a particular function. No agent-selection or performance measurement was made.

bsakaguchi added the

enhancement

triage

labels

2026-11-01 21:12:43 +00:00

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-11-03 12:24:57 +00:00