morluto/rea

Fork 0

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

[PR #3090] feat(providers): enable agent-aware deep provider selection #5607

New issue

Open

opened 2026-10-31 01:07:56 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:07:56 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/3090
Author: @whoishaha
Created: 10/14/2026
Status: 🔄 Open

Base: main ← Head: feat/auto-provider-selection-2417

📝 Commits (10+)

ed27ee6 feat(providers): add agent-aware provider selection
133c9b1 fix(providers): improve selection diagnostics and auto-route reuse
f29d7ac merge: reconcile upstream provider and session changes
aa98412 fix(providers): address provider selection review feedback
ba1b989 Merge branch 'morluto:main' into feat/auto-provider-selection-2417
db372f1 fix(providers): record an explicit choice on the retained fast path
90eaa7e Merge branch 'main' into feat/auto-provider-selection-2417
1ecc427 Update candidates eligibility to 'ineligible'
6e37b8f Update src/application/binary/AnalysisProviderRegistry.ts
bb14b1f test(mcp): expect the admitting selection record on recovery

📊 Changes

29 files changed (+3103 additions, -163 deletions)

View changed files

📝 .agents/skills/reverse-engineer-anything/SKILL.md (+61 -0)
📝 docs/cli.md (+17 -2)
📝 docs/installation.md (+7 -5)
📝 docs/mcp-contracts.md (+77 -9)
➕ docs/specs/providers/auto-provider-selection/plan.md (+207 -0)
➕ docs/specs/providers/auto-provider-selection/spec.md (+269 -0)
➕ docs/specs/providers/auto-provider-selection/tasks.md (+254 -0)
📝 src/application/CapabilityInventory.test.ts (+233 -0)
📝 src/application/CapabilityInventory.ts (+123 -3)
📝 src/application/InvestigationProviders.ts (+7 -0)
📝 src/application/binary/AnalysisProviderEvaluation.ts (+27 -1)
📝 src/application/binary/AnalysisProviderRegistry.test.ts (+271 -17)
📝 src/application/binary/AnalysisProviderRegistry.ts (+80 -42)
➕ src/application/binary/AutoProviderSelectionPolicy.test.ts (+148 -0)
➕ src/application/binary/AutoProviderSelectionPolicy.ts (+65 -0)
📝 src/application/binary/BinarySession.ts (+50 -0)
📝 src/application/binary/BinarySessionOpen.ts (+20 -1)
📝 src/application/binary/BinarySessionStatus.test.ts (+1 -0)
📝 src/application/binary/BinarySessionStatus.ts (+4 -0)
➕ src/application/binary/ProviderSelectionEvidence.test.ts (+318 -0)

...and 9 more files

📄 Description

Summary

Refs #2417

This PR introduces agent-aware deep analysis provider selection. Instead of rejecting open_binary(provider_id: "auto") when multiple deep providers qualify, REA admits the target in a selection_required state. External agents can inspect provider eligibility, resolved identities, capabilities, and tool availability through binary_session, then select a concrete provider with the existing open_binary interface.

REA provides validated compatibility facts and enforces binding and lifecycle rules; the external agent makes the task-dependent choice. The change introduces no embedded LLM, automatic provider ranking, speculative multi-engine execution, or implicit runtime fallback.

Problem and expected behavior

Previously, multiple eligible providers caused an immediate ProviderSelectionError(reason: "ambiguous") during target admission, before an agent could inspect the candidates in an admitted session.

Eligible deep providers	New behavior
Zero	Admit unbound; retain supported auxiliary and artifact-only operations
One	Automatically bind the sole eligible provider
Multiple	Admit with `selection_required`; do not start an arbitrary deep engine
Explicit provider ID	Validate and bind the specified provider
Deep operation before choosing	Return a typed `ambiguous` error with actionable tool-availability diagnostics
Compatible repeated open	Preserve the live client and retained analysis state
Provider execution failure	Surface the failure without automatic fallback

The agent's workflow is: open the target, inspect binary_session, choose an eligible provider based on the requested analysis operations, then reopen with an explicit provider_id before deep analysis.

Change and scope

Selection and discovery

Add AutoProviderSelectionPolicy.ts with deterministic bound, unbound, and selection_required outcomes based on availability, target support, and resolved analysis profiles.
Expose analysis_provider_selection_state and per-candidate eligibility (eligible, ineligible, unevaluated) in session metadata. Candidate ordering is independent of registration order.
Attribute eligible candidates and their capability descriptors to the identity and concrete version resolved by the analysis profile. analysis_provider_binding remains authoritative for the selected provider.

Actionable operation diagnostics

Introduce provider_selection_required rather than incorrectly reporting provider_missing when a valid provider choice is pending.
Filter remediation by the specific requested operation and its composed requirements; recommend only eligible providers that declare the required capabilities. If no eligible provider can perform the operation, keep provider_missing.
Preserve auxiliary and artifact-only tool availability while a deep provider is unbound.

Session lifecycle and selection Evidence

Continue using open_binary for provider selection and switching; no additional MCP tool is introduced.
Reuse a compatible resolved automatic route for unchanged target bytes, avoiding unnecessary client retirement or snapshot invalidation.
When a newly resolved explicit choice reuses a live client, record the distinct selection decision and adopt the updated route metadata. Keep the client, run ID, profile, and snapshot intact. Equivalent repeated choices deduplicate by Evidence identity.
Add deterministic REA-owned rea.provider-selection Evidence for target identity, evaluated candidates, rejections, selection state, selected provider, and decision rule. Use confidence: "derived" and authority: "analyst-inference" so a routing decision cannot masquerade as binary-derived artifact proof. caller_rationale remains null rather than fabricating agent reasoning.
Existing cancellation, cleanup, serialized transitions, and no-fallback boundaries are retained.

Review-driven fixes

Four Greptile P2 findings have been addressed in subsequent commits:

Resolved provider versions disappear: propagate the resolved provider identity to every eligible candidate and its capabilities.
Provider advice cannot resolve failures: offer only candidates that can satisfy each requested operation.
Selection records claim artifact proof: explicitly mark selection Evidence as analyst-inference, with regression assertions.
Explicit choices go unrecorded: record a new explicit decision during the retained fast path and update session route metadata without recreating the client.

Files, documentation, and exclusions

Implementation and regression coverage span the provider registry/policy, candidate evaluation, binary session, capability inventory, selection Evidence, and MCP composition tests. Authored documentation was updated in .agents/skills/reverse-engineer-anything/SKILL.md, docs/cli.md, docs/installation.md, and docs/mcp-contracts.md. The design and verification records are in docs/specs/providers/auto-provider-selection/{spec,plan,tasks}.md.

Out of scope: embedded LLMs, engine-specific priority matrices, speculative provider startup, runtime fallback, new adapters, new target-execution or mutation authority, and a separate provider-switching tool.

See the contribution-scope policy. The changed default multi-provider admission behavior and public fields still require maintainer contract/scope approval under #2417 before integration.

Contract and boundary impact

Semantic owner and earliest changed stage: AnalysisProviderRegistry, AutoProviderSelectionPolicy, and the binary session-opening boundary, after target/provider eligibility evaluation and before deep-client startup.
Contribution scope fit and linked maintainer decision: Existing general-purpose provider orchestration; no new execution or mutation authority. The default admission behavior and new public contract require maintainer approval under #2417.
CLI and MCP/tool-catalog contract: open_binary input unchanged; binary_session adds selection state and candidate eligibility. Tool availability adds the provider_selection_required reason and operation-specific remediation. No new MCP tool.
Provider, bridge, target-format, or platform compatibility: Existing adapters, target formats, and provider capabilities unchanged. Explicit provider selection and configured preferences retain precedence.
Evidence, artifact, provenance, or reconstruction contract: Selection records are REA-attributed analyst-inference decisions, distinct from engine-produced analysis. They carry no analysis profile and are not analysis snapshot replay bindings.
Target selection, authority, upstream behavior, and cleanup details: Existing target identity checks, serialized transitions, cancellation, client retirement, and snapshot validation remain in effect. Fast-path selection metadata is updated only after recording a new decision succeeds.
Generated metadata (docs/public/product-catalog.json), package, or installation impact: No new dependencies or deep provider installations. Authored skill documentation is updated; ignored generated catalogs and build artifacts are not part of the intended feature.

Expected effects (including existing provider workflows; the new pending-selection path does not itself start an engine or mutate target bytes):

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

Checked effects reflect inherited provider workflows, including engine startup and provider-owned temporary analysis artifacts; they are not newly granted capabilities. Unchecked effects are not an assertion about every existing adapter.

Evidence and regression coverage

Tests added or updated: Pure selection policy, provider registry, target eligibility and version attribution, repeated-open lifecycle, retained client and route provenance, cancellation/cleanup, selection Evidence identity and authority, operation-level capability diagnostics, and MCP InMemoryTransport integration.
Base reproduction or other evidence: On the original implementation, initial open_binary(auto) returned ambiguous with multiple eligible deep providers. The new tests assert admission with selection_required and defer the typed ambiguous error to the attempted deep operation. Review-response regressions cover all four P2 findings, including explicit choice retention on a live client.
User-visible CLI/MCP output: A representative test has analysis_provider_selection_state: "selection_required", analysis_provider_binding: null, and two eligible candidates, alpha and beta. For analyze_function, the tool-availability entry reports available: false, reason: "provider_selection_required", and remediation to choose alpha (the eligible provider that declares the operation). Operations no eligible provider can run retain provider_missing. These are simulated-provider examples, not real Ghidra/IDA/Hopper runs.
Remaining proof gaps: Real multi-provider Ghidra/IDA/Hopper tests, POSIX-specific lanes, full acceptance tests, and an approved full GitHub CI run remain unverified. Maintainer approval of the changed public behavior is pending.
Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

The following historical local results are recorded in docs/specs/providers/auto-provider-selection/tasks.md, on Windows 11 with Node.js 26.3.0 and npm 12.0.2. The baseline comparison used upstream fb28ec153; these observations are not a claim that the latest merged head passed all checks.

npm ci — passed on the recorded checkout.
npm run test:focused -- <9 affected test files> — 9 files / 71 tests passed in the recorded run.
npm run verify:test-discovery — 1,058 test files discovered exactly once.
npm run check:fast — passed in the recorded run.
npm run check — passed in the recorded run, including typecheck, lint, format, dependency, metadata, and architecture checks.
npm run docs:generate and npm run docs:check — passed in the recorded run.
npm run test:fast — baseline: 5,462 passed / 126 failed; feature: 5,491 passed / 126 failed, with the same 26 failing files.
npm run test:mcp — baseline: 432 passed / 43 failed; feature: 435 passed / 43 failed, with the same 12 failing files.

Baseline-equivalent failures were attributed to local Windows symlink/executable permissions, listen EACCES, and unavailable optional toolchains. Later review fixes added targeted regression tests; the explicit-choice fast-path regression was reported to fail without the fix. No unperformed full-suite run is represented as passing.

Current CI limitation: GitHub Actions workflows for the latest PR revision have awaited maintainer approval rather than completing their jobs. Real multi-provider integration, POSIX-specific verification, npm run check:pr, and npm run test:acceptance remain unverified.

Compatibility, safety, and release

Breaking changes or migration steps: Previously, open_binary(auto) failed immediately on multiple eligible providers. It now admits the target successfully in selection_required with no deep binding. Consumers that assumed successful admission meant a deep engine was bound must inspect analysis_provider_binding or analysis_provider_selection_state and explicitly select a provider before deep analysis. Maintainer guidance on compatibility labeling and migration is requested.
Real Hopper/Ghidra, browser, or OS coverage: Mock-provider lifecycle and MCP boundary tests on Windows; real multi-provider and POSIX-specific integration not yet verified. Browser functionality unchanged.
Package or release metadata impact: No new third-party dependencies or provider installations; authored skill guidance and documentation updated. Release classification pending maintainer review.
Security, privacy, process, or containment review: No new speculative engine execution, runtime fallback, instrumentation, target mutation, or protection-recovery authority. Provider-selection Evidence is REA-owned and not misclassified as artifact proof. Existing authority and cleanup boundaries remain in use.

Author readiness

Human owner: @whoishaha

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

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

The contract/scope decision and remaining verification gaps must be resolved before integration. The Author readiness boxes above are intentionally unchecked until the human owner personally verifies and attests to them.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/3090 **Author:** [@whoishaha](https://github.com/whoishaha) **Created:** 10/14/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `feat/auto-provider-selection-2417` --- ### 📝 Commits (10+) - [`ed27ee6`](https://github.com/morluto/rea/commit/ed27ee6b3dcfd2d97572d4b6d9df0cd6619eee60) feat(providers): add agent-aware provider selection - [`133c9b1`](https://github.com/morluto/rea/commit/133c9b1ea4ae4ba59ce7e74b9776175ce619135e) fix(providers): improve selection diagnostics and auto-route reuse - [`f29d7ac`](https://github.com/morluto/rea/commit/f29d7ac24da173f16068fa9b2eab55149693828e) merge: reconcile upstream provider and session changes - [`aa98412`](https://github.com/morluto/rea/commit/aa9841260e6fa337c1f6475839b120a55327fdde) fix(providers): address provider selection review feedback - [`ba1b989`](https://github.com/morluto/rea/commit/ba1b98978be7b763db563b58ab0bdd8202a1a959) Merge branch 'morluto:main' into feat/auto-provider-selection-2417 - [`db372f1`](https://github.com/morluto/rea/commit/db372f16e33e3f396dc60dfd57bbdfd1a9dbd349) fix(providers): record an explicit choice on the retained fast path - [`90eaa7e`](https://github.com/morluto/rea/commit/90eaa7e92a18ffc97ac4f54438f98b72ab22e7b6) Merge branch 'main' into feat/auto-provider-selection-2417 - [`1ecc427`](https://github.com/morluto/rea/commit/1ecc42773f6fdcdf8fb1329a9c909fbd9ddc3053) Update candidates eligibility to 'ineligible' - [`6e37b8f`](https://github.com/morluto/rea/commit/6e37b8fead192782e97c183a9e7cd99c29b53dc1) Update src/application/binary/AnalysisProviderRegistry.ts - [`bb14b1f`](https://github.com/morluto/rea/commit/bb14b1ffdf1455587d301561123fe5581839bf55) test(mcp): expect the admitting selection record on recovery ### 📊 Changes **29 files changed** (+3103 additions, -163 deletions) <details> <summary>View changed files</summary> 📝 `.agents/skills/reverse-engineer-anything/SKILL.md` (+61 -0) 📝 `docs/cli.md` (+17 -2) 📝 `docs/installation.md` (+7 -5) 📝 `docs/mcp-contracts.md` (+77 -9) ➕ `docs/specs/providers/auto-provider-selection/plan.md` (+207 -0) ➕ `docs/specs/providers/auto-provider-selection/spec.md` (+269 -0) ➕ `docs/specs/providers/auto-provider-selection/tasks.md` (+254 -0) 📝 `src/application/CapabilityInventory.test.ts` (+233 -0) 📝 `src/application/CapabilityInventory.ts` (+123 -3) 📝 `src/application/InvestigationProviders.ts` (+7 -0) 📝 `src/application/binary/AnalysisProviderEvaluation.ts` (+27 -1) 📝 `src/application/binary/AnalysisProviderRegistry.test.ts` (+271 -17) 📝 `src/application/binary/AnalysisProviderRegistry.ts` (+80 -42) ➕ `src/application/binary/AutoProviderSelectionPolicy.test.ts` (+148 -0) ➕ `src/application/binary/AutoProviderSelectionPolicy.ts` (+65 -0) 📝 `src/application/binary/BinarySession.ts` (+50 -0) 📝 `src/application/binary/BinarySessionOpen.ts` (+20 -1) 📝 `src/application/binary/BinarySessionStatus.test.ts` (+1 -0) 📝 `src/application/binary/BinarySessionStatus.ts` (+4 -0) ➕ `src/application/binary/ProviderSelectionEvidence.test.ts` (+318 -0) _...and 9 more files_ </details> ### 📄 Description ## Summary Refs #2417 This PR introduces **agent-aware deep analysis provider selection**. Instead of rejecting `open_binary(provider_id: "auto")` when multiple deep providers qualify, REA admits the target in a `selection_required` state. External agents can inspect provider eligibility, resolved identities, capabilities, and tool availability through `binary_session`, then select a concrete provider with the existing `open_binary` interface. REA provides validated compatibility facts and enforces binding and lifecycle rules; the external agent makes the task-dependent choice. The change introduces no embedded LLM, automatic provider ranking, speculative multi-engine execution, or implicit runtime fallback. ## Problem and expected behavior Previously, multiple eligible providers caused an immediate `ProviderSelectionError(reason: "ambiguous")` during target admission, before an agent could inspect the candidates in an admitted session. | Eligible deep providers | New behavior | | --- | --- | | Zero | Admit unbound; retain supported auxiliary and artifact-only operations | | One | Automatically bind the sole eligible provider | | Multiple | Admit with `selection_required`; do not start an arbitrary deep engine | | Explicit provider ID | Validate and bind the specified provider | | Deep operation before choosing | Return a typed `ambiguous` error with actionable tool-availability diagnostics | | Compatible repeated open | Preserve the live client and retained analysis state | | Provider execution failure | Surface the failure without automatic fallback | The agent's workflow is: open the target, inspect `binary_session`, choose an eligible provider based on the requested analysis operations, then reopen with an explicit `provider_id` before deep analysis. ## Change and scope ### Selection and discovery - Add `AutoProviderSelectionPolicy.ts` with deterministic `bound`, `unbound`, and `selection_required` outcomes based on availability, target support, and resolved analysis profiles. - Expose `analysis_provider_selection_state` and per-candidate `eligibility` (`eligible`, `ineligible`, `unevaluated`) in session metadata. Candidate ordering is independent of registration order. - Attribute eligible candidates and their capability descriptors to the identity and concrete version resolved by the analysis profile. `analysis_provider_binding` remains authoritative for the selected provider. ### Actionable operation diagnostics - Introduce `provider_selection_required` rather than incorrectly reporting `provider_missing` when a valid provider choice is pending. - Filter remediation by the **specific requested operation** and its composed requirements; recommend only eligible providers that declare the required capabilities. If no eligible provider can perform the operation, keep `provider_missing`. - Preserve auxiliary and artifact-only tool availability while a deep provider is unbound. ### Session lifecycle and selection Evidence - Continue using `open_binary` for provider selection and switching; no additional MCP tool is introduced. - Reuse a compatible resolved automatic route for unchanged target bytes, avoiding unnecessary client retirement or snapshot invalidation. - When a newly resolved explicit choice reuses a live client, record the distinct selection decision and adopt the updated route metadata. Keep the client, run ID, profile, and snapshot intact. Equivalent repeated choices deduplicate by Evidence identity. - Add deterministic REA-owned `rea.provider-selection` Evidence for target identity, evaluated candidates, rejections, selection state, selected provider, and decision rule. Use `confidence: "derived"` and `authority: "analyst-inference"` so a routing decision cannot masquerade as binary-derived artifact proof. `caller_rationale` remains `null` rather than fabricating agent reasoning. - Existing cancellation, cleanup, serialized transitions, and no-fallback boundaries are retained. ### Review-driven fixes Four Greptile P2 findings have been addressed in subsequent commits: 1. **Resolved provider versions disappear:** propagate the resolved provider identity to every eligible candidate and its capabilities. 2. **Provider advice cannot resolve failures:** offer only candidates that can satisfy each requested operation. 3. **Selection records claim artifact proof:** explicitly mark selection Evidence as `analyst-inference`, with regression assertions. 4. **Explicit choices go unrecorded:** record a new explicit decision during the retained fast path and update session route metadata without recreating the client. ### Files, documentation, and exclusions Implementation and regression coverage span the provider registry/policy, candidate evaluation, binary session, capability inventory, selection Evidence, and MCP composition tests. Authored documentation was updated in `.agents/skills/reverse-engineer-anything/SKILL.md`, `docs/cli.md`, `docs/installation.md`, and `docs/mcp-contracts.md`. The design and verification records are in `docs/specs/providers/auto-provider-selection/{spec,plan,tasks}.md`. Out of scope: embedded LLMs, engine-specific priority matrices, speculative provider startup, runtime fallback, new adapters, new target-execution or mutation authority, and a separate provider-switching tool. See [the contribution-scope policy](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). The changed default multi-provider admission behavior and public fields still require maintainer contract/scope approval under #2417 before integration. ## Contract and boundary impact - **Semantic owner and earliest changed stage:** `AnalysisProviderRegistry`, `AutoProviderSelectionPolicy`, and the binary session-opening boundary, after target/provider eligibility evaluation and before deep-client startup. - **Contribution scope fit and linked maintainer decision:** Existing general-purpose provider orchestration; no new execution or mutation authority. The default admission behavior and new public contract require maintainer approval under #2417. - **CLI and MCP/tool-catalog contract:** `open_binary` input unchanged; `binary_session` adds selection state and candidate eligibility. Tool availability adds the `provider_selection_required` reason and operation-specific remediation. No new MCP tool. - **Provider, bridge, target-format, or platform compatibility:** Existing adapters, target formats, and provider capabilities unchanged. Explicit provider selection and configured preferences retain precedence. - **Evidence, artifact, provenance, or reconstruction contract:** Selection records are REA-attributed `analyst-inference` decisions, distinct from engine-produced analysis. They carry no analysis profile and are not analysis snapshot replay bindings. - **Target selection, authority, upstream behavior, and cleanup details:** Existing target identity checks, serialized transitions, cancellation, client retirement, and snapshot validation remain in effect. Fast-path selection metadata is updated only after recording a new decision succeeds. - **Generated metadata (`docs/public/product-catalog.json`), package, or installation impact:** No new dependencies or deep provider installations. Authored skill documentation is updated; ignored generated catalogs and build artifacts are not part of the intended feature. Expected effects (including existing provider workflows; the new pending-selection path does not itself start an engine or mutate target bytes): - [x] Read existing files or captured data. - [x] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [x] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. Checked effects reflect inherited provider workflows, including engine startup and provider-owned temporary analysis artifacts; they are not newly granted capabilities. Unchecked effects are not an assertion about every existing adapter. ## Evidence and regression coverage - **Tests added or updated:** Pure selection policy, provider registry, target eligibility and version attribution, repeated-open lifecycle, retained client and route provenance, cancellation/cleanup, selection Evidence identity and authority, operation-level capability diagnostics, and MCP `InMemoryTransport` integration. - **Base reproduction or other evidence:** On the original implementation, initial `open_binary(auto)` returned `ambiguous` with multiple eligible deep providers. The new tests assert admission with `selection_required` and defer the typed `ambiguous` error to the attempted deep operation. Review-response regressions cover all four P2 findings, including explicit choice retention on a live client. - **User-visible CLI/MCP output:** A representative test has `analysis_provider_selection_state: "selection_required"`, `analysis_provider_binding: null`, and two `eligible` candidates, `alpha` and `beta`. For `analyze_function`, the tool-availability entry reports `available: false`, `reason: "provider_selection_required"`, and remediation to choose `alpha` (the eligible provider that declares the operation). Operations no eligible provider can run retain `provider_missing`. These are simulated-provider examples, not real Ghidra/IDA/Hopper runs. - **Remaining proof gaps:** Real multi-provider Ghidra/IDA/Hopper tests, POSIX-specific lanes, full acceptance tests, and an approved full GitHub CI run remain unverified. Maintainer approval of the changed public behavior is pending. - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed The following **historical local results** are recorded in `docs/specs/providers/auto-provider-selection/tasks.md`, on Windows 11 with Node.js `26.3.0` and npm `12.0.2`. The baseline comparison used upstream `fb28ec153`; these observations are **not** a claim that the latest merged head passed all checks. - `npm ci` — passed on the recorded checkout. - `npm run test:focused -- <9 affected test files>` — 9 files / 71 tests passed in the recorded run. - `npm run verify:test-discovery` — 1,058 test files discovered exactly once. - `npm run check:fast` — passed in the recorded run. - `npm run check` — passed in the recorded run, including typecheck, lint, format, dependency, metadata, and architecture checks. - `npm run docs:generate` and `npm run docs:check` — passed in the recorded run. - `npm run test:fast` — baseline: 5,462 passed / 126 failed; feature: 5,491 passed / 126 failed, with the same 26 failing files. - `npm run test:mcp` — baseline: 432 passed / 43 failed; feature: 435 passed / 43 failed, with the same 12 failing files. Baseline-equivalent failures were attributed to local Windows symlink/executable permissions, `listen EACCES`, and unavailable optional toolchains. Later review fixes added targeted regression tests; the explicit-choice fast-path regression was reported to fail without the fix. No unperformed full-suite run is represented as passing. **Current CI limitation:** GitHub Actions workflows for the latest PR revision have awaited maintainer approval rather than completing their jobs. Real multi-provider integration, POSIX-specific verification, `npm run check:pr`, and `npm run test:acceptance` remain unverified. ## Compatibility, safety, and release - **Breaking changes or migration steps:** Previously, `open_binary(auto)` failed immediately on multiple eligible providers. It now admits the target successfully in `selection_required` with no deep binding. Consumers that assumed successful admission meant a deep engine was bound must inspect `analysis_provider_binding` or `analysis_provider_selection_state` and explicitly select a provider before deep analysis. Maintainer guidance on compatibility labeling and migration is requested. - **Real Hopper/Ghidra, browser, or OS coverage:** Mock-provider lifecycle and MCP boundary tests on Windows; real multi-provider and POSIX-specific integration not yet verified. Browser functionality unchanged. - **Package or release metadata impact:** No new third-party dependencies or provider installations; authored skill guidance and documentation updated. Release classification pending maintainer review. - **Security, privacy, process, or containment review:** No new speculative engine execution, runtime fallback, instrumentation, target mutation, or protection-recovery authority. Provider-selection Evidence is REA-owned and not misclassified as artifact proof. Existing authority and cleanup boundaries remain in use. ## Author readiness Human owner: @whoishaha - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. The contract/scope decision and remaining verification gaps must be resolved before integration. **The Author readiness boxes above are intentionally unchecked until the human owner personally verifies and attests to them.** --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-31 01:07:56 +00:00

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#5607

No description provided.

Rows
Columns