morluto/rea

Fork 0

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

[PR #4059] [CLOSED] fix(setup): keep Hopper recovery advice within supported hosts #6025

New issue

Closed

opened 2026-10-31 01:11:15 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4059
Author: @biniyapp
Created: 10/15/2026
Status: ❌ Closed

Base: main ← Head: fix/windows-hopper-remediation-3944

📝 Commits (1)

169c374 fix(setup): keep Hopper recovery advice within supported hosts

📊 Changes

4 files changed (+89 additions, -1 deletions)

View changed files

📝 src/application/Setup.recovery.test.ts (+44 -0)
📝 src/application/Setup.ts (+3 -1)
📝 src/application/SetupPlan.ts (+2 -0)
📝 tests/boundary/filesystem/setupUnavailableProvider.test.ts (+40 -0)

📄 Description

Summary

Fixes #3944. Setup no longer recommends --install-hopper on a host where its existing installer eligibility check says installation is unsupported.

Problem and expected behavior

An unhealthy Windows setup with no Hopper launcher and the manual grok_bot client returned an unsupported installation hint before the applicable manual registration instructions. Following that hint was rejected by the installer guard. Recovery should offer supported actions without hiding the unhealthy result.

Change and scope

Expose the already-computed hopperInstallSupported fact from setup discovery and reuse it in final remediation. This avoids adding a separate Windows-only rule or repeating host probes. The same correction covers older macOS versions and unsupported Linux distributions. Supported-host advice, the macOS post-install activation hint, manual client instructions, readiness status and explicit installation rejection are preserved.

Contract and boundary impact

Semantic owner and earliest changed stage: SetupPlan retains its installer eligibility fact; Setup consumes it when composing final recovery text.
Contribution scope fit and linked maintainer decision: routine usability correction within existing setup scope; a new capability decision is not applicable.
CLI and MCP/tool-catalog contract: setup recovery text changes; no flags, schemas or tool catalog changes.
Provider, bridge, target-format, or platform compatibility: no new platform/provider support. Existing installation gates are unchanged.
Evidence, artifact, provenance, or reconstruction contract: unchanged.
Target selection, authority, upstream behavior, and cleanup: no new target interaction, installation authority, host probes or cleanup behavior.
Generated metadata, package, or installation impact: no package/version/generated-metadata changes; installer eligibility is reused rather than changed.

Expected effects of this change:

Documentation or usability only; no target interaction.

Evidence and regression coverage

Executed on macOS arm64 with Node 24.18.0 / npm 11.16.0:

Before the production fix, the new service cases failed for Windows, macOS 11.7 and unsupported Linux; supported macOS/Linux controls passed.
The new production setup/doctor boundary case also failed before the fix: needs_human, doctor.healthy: false, no planned/applied actions, but remediation included --install-hopper.
After the fix, the boundary case retains the manual Grok Bot instructions and unhealthy status, omits that hint, and still rejects explicitly requested Windows Hopper installation before applying actions.
Existing coverage also checks healthy Windows client setup without a provider and no-write repeated configuration.

Representative remediation prefix from the production-boundary Windows scenario:

Before: Hopper is optional for non-Hopper providers. Rerun with --yes --install-hopper for deep native analysis.
After:  Run rea doctor and apply each reported remediation.

Both retain the existing Grok Bot manual instructions. This is simulated Windows diagnostics through the real setup/doctor workflow, not native Windows CLI evidence.

Validation performed

npm run test:focused -- src/application/Setup.recovery.test.ts src/application/Setup.planning.test.ts src/application/Setup.configuration.test.ts src/application/Setup.initialSnapshot.test.ts tests/boundary/filesystem/setupUnavailableProvider.test.ts — 63 tests passed across 5 files.
npm run check — passed typecheck, lint (0 errors; warnings remain), format, knip, metadata, module boundaries and architecture guards.
npm run verify:test-discovery — all 1,331 test files discovered exactly once.
npm run verify:package — passed on macOS, including packaged setup/uninstall, idempotence, CLI/MCP and workspace cleanup.
npm pack --dry-run --json — passed.
git diff --check — passed.

Compatibility, safety, and release

Breaking changes or migration steps: none; existing unsupported installation requests still fail before mutations.
Real Hopper/Ghidra, browser, or OS coverage: no new real-engine run. Windows and Linux conditions were simulated; native Windows/Linux CLI verification remains unavailable.
Package or release metadata impact: none.
Security/privacy/process review: no new installation, configuration-write or process-launch behavior; no private artifacts or credentials included.
No performance benchmark or complete local test-suite run; focused regressions and the official package lane ran.

Author readiness

Human owner: @biniyapp

AI-assisted draft. Human review and readiness declarations are intentionally pending.

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

Human owner has completed the readiness declarations.
Required CI checks pass for the current revision.
Maintainer review is complete.

_{🔄 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/4059 **Author:** [@biniyapp](https://github.com/biniyapp) **Created:** 10/15/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/windows-hopper-remediation-3944` --- ### 📝 Commits (1) - [`169c374`](https://github.com/morluto/rea/commit/169c374e5a3d9637f57bd9ff4c6450444fba965b) fix(setup): keep Hopper recovery advice within supported hosts ### 📊 Changes **4 files changed** (+89 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/application/Setup.recovery.test.ts` (+44 -0) 📝 `src/application/Setup.ts` (+3 -1) 📝 `src/application/SetupPlan.ts` (+2 -0) 📝 `tests/boundary/filesystem/setupUnavailableProvider.test.ts` (+40 -0) </details> ### 📄 Description ## Summary Fixes #3944. Setup no longer recommends `--install-hopper` on a host where its existing installer eligibility check says installation is unsupported. ## Problem and expected behavior An unhealthy Windows setup with no Hopper launcher and the manual `grok_bot` client returned an unsupported installation hint before the applicable manual registration instructions. Following that hint was rejected by the installer guard. Recovery should offer supported actions without hiding the unhealthy result. ## Change and scope Expose the already-computed `hopperInstallSupported` fact from setup discovery and reuse it in final remediation. This avoids adding a separate Windows-only rule or repeating host probes. The same correction covers older macOS versions and unsupported Linux distributions. Supported-host advice, the macOS post-install activation hint, manual client instructions, readiness status and explicit installation rejection are preserved. ## Contract and boundary impact - Semantic owner and earliest changed stage: `SetupPlan` retains its installer eligibility fact; `Setup` consumes it when composing final recovery text. - Contribution scope fit and linked maintainer decision: routine usability correction within existing setup scope; a new capability decision is not applicable. - CLI and MCP/tool-catalog contract: setup recovery text changes; no flags, schemas or tool catalog changes. - Provider, bridge, target-format, or platform compatibility: no new platform/provider support. Existing installation gates are unchanged. - Evidence, artifact, provenance, or reconstruction contract: unchanged. - Target selection, authority, upstream behavior, and cleanup: no new target interaction, installation authority, host probes or cleanup behavior. - Generated metadata, package, or installation impact: no package/version/generated-metadata changes; installer eligibility is reused rather than changed. Expected effects of this change: - [x] Documentation or usability only; no target interaction. ## Evidence and regression coverage Executed on macOS arm64 with Node 24.18.0 / npm 11.16.0: - Before the production fix, the new service cases failed for Windows, macOS 11.7 and unsupported Linux; supported macOS/Linux controls passed. - The new production setup/doctor boundary case also failed before the fix: `needs_human`, `doctor.healthy: false`, no planned/applied actions, but remediation included `--install-hopper`. - After the fix, the boundary case retains the manual Grok Bot instructions and unhealthy status, omits that hint, and still rejects explicitly requested Windows Hopper installation before applying actions. - Existing coverage also checks healthy Windows client setup without a provider and no-write repeated configuration. Representative remediation prefix from the production-boundary Windows scenario: ```text Before: Hopper is optional for non-Hopper providers. Rerun with --yes --install-hopper for deep native analysis. After: Run rea doctor and apply each reported remediation. ``` Both retain the existing Grok Bot manual instructions. This is simulated Windows diagnostics through the real setup/doctor workflow, not native Windows CLI evidence. ## Validation performed - `npm run test:focused -- src/application/Setup.recovery.test.ts src/application/Setup.planning.test.ts src/application/Setup.configuration.test.ts src/application/Setup.initialSnapshot.test.ts tests/boundary/filesystem/setupUnavailableProvider.test.ts` — 63 tests passed across 5 files. - `npm run check` — passed typecheck, lint (0 errors; warnings remain), format, knip, metadata, module boundaries and architecture guards. - `npm run verify:test-discovery` — all 1,331 test files discovered exactly once. - `npm run verify:package` — passed on macOS, including packaged setup/uninstall, idempotence, CLI/MCP and workspace cleanup. - `npm pack --dry-run --json` — passed. - `git diff --check` — passed. ## Compatibility, safety, and release - Breaking changes or migration steps: none; existing unsupported installation requests still fail before mutations. - Real Hopper/Ghidra, browser, or OS coverage: no new real-engine run. Windows and Linux conditions were simulated; native Windows/Linux CLI verification remains unavailable. - Package or release metadata impact: none. - Security/privacy/process review: no new installation, configuration-write or process-launch behavior; no private artifacts or credentials included. - No performance benchmark or complete local test-suite run; focused regressions and the official package lane ran. ## Author readiness Human owner: @biniyapp AI-assisted draft. Human review and readiness declarations are intentionally pending. - [ ] 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 - [ ] Human owner has completed the readiness declarations. - [ ] Required CI checks pass for the current revision. - [ ] Maintainer review is complete. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

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

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-11-01 21:45:38 +00:00

[PR #6025] [CLOSED] test(analysis-view): cover JavaScript summary limitation counts #7131

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

No description provided.

Rows
Columns