morluto/rea

Fork 0

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

[GH-ISSUE #5105] [Bug] Setup advertises Kuna for deep analysis after its cache check fails #3142

New issue

Closed

opened 2026-10-31 00:37:07 +00:00 by bsakaguchi · 8 comments

bsakaguchi commented

2026-10-31 00:37:07 +00:00

Owner

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

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

A mocked-boundary reproduction with a synthetic Kuna version executable and a real regular file as the configured cache root returns available: true despite cache.ok: false and open_options_invalid. Setup retains availableProviders: ["kuna"]; when its selected readiness scope succeeds, its interactive renderer prints Deep analysis: Kuna under What you can do now.

The real provider-scoped doctor workflow correctly returns healthy: false. The defect is the availability/setup projection. No real Kuna analysis or CLI subprocess was executed.

Reproduction

Executed on macOS from the source checkout with locked dependencies already installed. Save the following as $WORK/probe.mts, where $WORK is an isolated writable directory outside the checkout. It uses existing recording-host fixtures, actual application workflows, and the actual renderer. It performs no setup mutations.

import assert from 'node:assert/strict';
import { mkdir, writeFile } from 'node:fs/promises';
import { join } from 'node:path';
import { pathToFileURL } from 'node:url';
const root = process.cwd();
const load = (path: string) => import(pathToFileURL(join(root, path)).href);
const { inspectKunaProviderOwned } = await load('tests/boundary/providers/kuna/kunaFileCloseOwner.ts');
const { runDoctor } = await load('src/application/Doctor.ts');
const { runSetup } = await load('src/application/Setup.ts');
const { renderInteractiveSetupResult } = await load('src/cli/interactiveSetup.ts');
const { FakeSetupHost, options } = await load('src/application/Setup.fixture.ts');
const work = process.env.PROBE_ROOT!;
const kuna = join(work, 'kuna');
await writeFile(kuna, '#!/bin/sh\nprintf "kuna 1.833\\n"\n', { mode: 0o700 });
const occupied = join(work, 'occupied');
await writeFile(occupied, 'not a directory');
const ready = join(work, 'ready');
await mkdir(ready, { recursive: true });
for (const [name, cache] of [['blocked', occupied], ['ready', ready]]) {
  const inspection = await inspectKunaProviderOwned({ HOME: join(work, 'home'), REA_KUNA_COMMAND: kuna, REA_KUNA_CACHE_DIR: cache });
  const host = {
    platform: process.platform, architecture: process.arch,
    runtime: { id: 'node', version: process.versions.node }, homeDirectory: join(work, 'home'),
    macosVersion: async () => '14.5', executable: async () => false,
    brewHopperPath: async () => undefined, manualHopperPaths: async () => [],
    providerInspections: async () => [inspection], clientRegistrations: async () => [],
  };
  const report = await runDoctor(undefined, host, { providers: ['kuna'] });
  const setupHost = new FakeSetupHost();
  Object.defineProperty(setupHost, 'homeDirectory', { value: join(work, 'home') });
  setupHost.doctor = async (scope: any) => runDoctor(undefined, host, scope);
  const setup = await runSetup({ ...options(false), dryRun: false, installSkill: false, proposeHopper: false, clientIds: [] }, setupHost);
  renderInteractiveSetupResult(setup, {});
  const result = { case: name, setupStatus: setup.status, setupHealthy: setup.doctor.healthy, available: inspection.available, checks: inspection.checks.map(({name, ok, code}: any) => ({name, ok, code})), healthy: report.healthy, availableProviders: setup.doctor.availableProviders, mutations: { configurations: setupHost.configurations, installs: setupHost.hopperInstalls + setupHost.skillInstalls } };
  console.log(JSON.stringify(result));
  assert.equal(setup.status, 'ready');
  assert.equal(inspection.available, true);
  assert.equal(report.healthy, name === 'ready');
  assert.deepEqual(setup.doctor.availableProviders, ['kuna']);
  assert.equal(setupHost.configurations + setupHost.hopperInstalls + setupHost.skillInstalls, 0);
}

From the checkout root:

mkdir -p "$WORK/home" "$WORK/tmp"
env -i PATH="$PATH" HOME="$WORK/home" TMPDIR="$WORK/tmp" PROBE_ROOT="$WORK" \
  node --import ./node_modules/tsx/dist/loader.mjs "$WORK/probe.mts"

The assertions passed. Both the blocked-cache case and writable-directory control were exercised; the control changes the cache check and provider-scoped health to success.

Expected behavior

Exclude a provider with a known unusable required cache from the ready deep-analysis summary, or explicitly separate installed-engine discovery from usable-provider readiness in the exposed fields.

The expectation follows from the renderer's actual ready-capability use of availableProviders and Kuna's own unusable-cache diagnosis and remediation. IDA already gates availability on required workspace checks.

Impact and scope

Callers using simplified provider availability, including setup's ready summary, receive an incorrect deep-analysis recommendation for this bounded configuration error. The detailed cache check remains actionable, and explicitly scoped doctor reports unhealthy. Choosing a writable cache directory cleared the check failure in the control. No data loss, real analysis failure, or user-impact frequency was measured.

REA version

Source revision 3537e58c1ab29309f06eabf50bc52adba9817a0c; package version 6.7.0. No installed REA version queried.

Runtime and platform

Node v26.12.0; macOS 27.0.1; arm64. Synthetic executable prints kuna 1.833; no real Kuna installation used. Other platforms were not exercised.

Target and artifact context

No binary target. A harmless version-printing shell script, one regular cache-path file, and one writable-directory control. Doctor host discovery and setup host ports are synthetic; cache checks, version probing, doctor scope evaluation, setup projection, and result rendering execute actual source.

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Observed mocked-boundary output, shortened to relevant fields:

blocked: available=true; installation.ok=true; cache.ok=false; code=open_options_invalid
blocked: provider-scoped healthy=false
blocked: setupStatus=ready; setupHealthy=true; availableProviders=[kuna]
What you can do now
Deep analysis: Kuna
ready control: cache.ok=true; provider-scoped healthy=true
both cases: configurations=0; installs=0

Source: Kuna inspection sets availability before the cache result; setup filters only by availability; renderer directly maps the resulting providers.

Typed outcome or recovery expected

Expose Kuna as unavailable/not ready for analysis while its required cache check fails, retaining the existing cache remediation and any independently valid registration settings.

Analysis or suspected cause

Source-derived cause: installation success fixes available to true; the later failed cache check never changes it. Setup projects that flag directly. Setup's scoped health can legitimately ignore an unselected provider, but its deep-analysis summary still consumes that provider's incorrect availability.

Additional context

The relevant Kuna doctor, setup projection, and renderer files are unchanged between the 6.7.0 source tag and the tested main revision. This is SOURCE-ONLY release coverage; no stable-release runtime was executed. NOT_ENOUGH_INFO: first affected release and real-engine behavior were not established. Existing reports about Kuna doctor documentation, cancellation/lifecycle work, and native prerequisite checks do not cover this trigger and result.

Originally created by @coygeek on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5105 ## 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 A mocked-boundary reproduction with a synthetic Kuna version executable and a real regular file as the configured cache root returns `available: true` despite `cache.ok: false` and `open_options_invalid`. Setup retains `availableProviders: ["kuna"]`; when its selected readiness scope succeeds, its interactive renderer prints `Deep analysis: Kuna` under `What you can do now`. The real provider-scoped doctor workflow correctly returns `healthy: false`. The defect is the availability/setup projection. No real Kuna analysis or CLI subprocess was executed. ## Reproduction Executed on macOS from the source checkout with locked dependencies already installed. Save the following as `$WORK/probe.mts`, where `$WORK` is an isolated writable directory outside the checkout. It uses existing recording-host fixtures, actual application workflows, and the actual renderer. It performs no setup mutations. ```ts import assert from 'node:assert/strict'; import { mkdir, writeFile } from 'node:fs/promises'; import { join } from 'node:path'; import { pathToFileURL } from 'node:url'; const root = process.cwd(); const load = (path: string) => import(pathToFileURL(join(root, path)).href); const { inspectKunaProviderOwned } = await load('tests/boundary/providers/kuna/kunaFileCloseOwner.ts'); const { runDoctor } = await load('src/application/Doctor.ts'); const { runSetup } = await load('src/application/Setup.ts'); const { renderInteractiveSetupResult } = await load('src/cli/interactiveSetup.ts'); const { FakeSetupHost, options } = await load('src/application/Setup.fixture.ts'); const work = process.env.PROBE_ROOT!; const kuna = join(work, 'kuna'); await writeFile(kuna, '#!/bin/sh\nprintf "kuna 1.833\\n"\n', { mode: 0o700 }); const occupied = join(work, 'occupied'); await writeFile(occupied, 'not a directory'); const ready = join(work, 'ready'); await mkdir(ready, { recursive: true }); for (const [name, cache] of [['blocked', occupied], ['ready', ready]]) { const inspection = await inspectKunaProviderOwned({ HOME: join(work, 'home'), REA_KUNA_COMMAND: kuna, REA_KUNA_CACHE_DIR: cache }); const host = { platform: process.platform, architecture: process.arch, runtime: { id: 'node', version: process.versions.node }, homeDirectory: join(work, 'home'), macosVersion: async () => '14.5', executable: async () => false, brewHopperPath: async () => undefined, manualHopperPaths: async () => [], providerInspections: async () => [inspection], clientRegistrations: async () => [], }; const report = await runDoctor(undefined, host, { providers: ['kuna'] }); const setupHost = new FakeSetupHost(); Object.defineProperty(setupHost, 'homeDirectory', { value: join(work, 'home') }); setupHost.doctor = async (scope: any) => runDoctor(undefined, host, scope); const setup = await runSetup({ ...options(false), dryRun: false, installSkill: false, proposeHopper: false, clientIds: [] }, setupHost); renderInteractiveSetupResult(setup, {}); const result = { case: name, setupStatus: setup.status, setupHealthy: setup.doctor.healthy, available: inspection.available, checks: inspection.checks.map(({name, ok, code}: any) => ({name, ok, code})), healthy: report.healthy, availableProviders: setup.doctor.availableProviders, mutations: { configurations: setupHost.configurations, installs: setupHost.hopperInstalls + setupHost.skillInstalls } }; console.log(JSON.stringify(result)); assert.equal(setup.status, 'ready'); assert.equal(inspection.available, true); assert.equal(report.healthy, name === 'ready'); assert.deepEqual(setup.doctor.availableProviders, ['kuna']); assert.equal(setupHost.configurations + setupHost.hopperInstalls + setupHost.skillInstalls, 0); } ``` From the checkout root: ```sh mkdir -p "$WORK/home" "$WORK/tmp" env -i PATH="$PATH" HOME="$WORK/home" TMPDIR="$WORK/tmp" PROBE_ROOT="$WORK" \ node --import ./node_modules/tsx/dist/loader.mjs "$WORK/probe.mts" ``` The assertions passed. Both the blocked-cache case and writable-directory control were exercised; the control changes the cache check and provider-scoped health to success. ## Expected behavior Exclude a provider with a known unusable required cache from the ready deep-analysis summary, or explicitly separate installed-engine discovery from usable-provider readiness in the exposed fields. The expectation follows from the renderer's actual [ready-capability use of `availableProviders`](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/cli/interactiveSetup.ts#L240-L255) and Kuna's own [unusable-cache diagnosis and remediation](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/kuna/KunaDoctor.ts#L157-L167). IDA already [gates availability on required workspace checks](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/ida/IdaDoctor.ts#L14-L21). ## Impact and scope Callers using simplified provider availability, including setup's ready summary, receive an incorrect deep-analysis recommendation for this bounded configuration error. The detailed cache check remains actionable, and explicitly scoped doctor reports unhealthy. Choosing a writable cache directory cleared the check failure in the control. No data loss, real analysis failure, or user-impact frequency was measured. ## REA version Source revision `3537e58c1ab29309f06eabf50bc52adba9817a0c`; package version 6.7.0. No installed REA version queried. ## Runtime and platform Node v26.12.0; macOS 27.0.1; arm64. Synthetic executable prints `kuna 1.833`; no real Kuna installation used. Other platforms were not exercised. ## Target and artifact context No binary target. A harmless version-printing shell script, one regular cache-path file, and one writable-directory control. Doctor host discovery and setup host ports are synthetic; cache checks, version probing, doctor scope evaluation, setup projection, and result rendering execute actual source. ## Interface Package or setup ## Earliest failure stage Setup or provider admission ## Relevant output or evidence Observed mocked-boundary output, shortened to relevant fields: ```text blocked: available=true; installation.ok=true; cache.ok=false; code=open_options_invalid blocked: provider-scoped healthy=false blocked: setupStatus=ready; setupHealthy=true; availableProviders=[kuna] What you can do now Deep analysis: Kuna ready control: cache.ok=true; provider-scoped healthy=true both cases: configurations=0; installs=0 ``` Source: [Kuna inspection sets availability before the cache result](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/kuna/KunaDoctor.ts#L81-L112); [setup filters only by availability](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/Setup.ts#L575-L588); [renderer directly maps the resulting providers](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/cli/interactiveSetup.ts#L273-L274). ## Typed outcome or recovery expected Expose Kuna as unavailable/not ready for analysis while its required cache check fails, retaining the existing cache remediation and any independently valid registration settings. ## Analysis or suspected cause Source-derived cause: installation success fixes `available` to true; the later failed cache check never changes it. Setup projects that flag directly. Setup's scoped health can legitimately ignore an unselected provider, but its deep-analysis summary still consumes that provider's incorrect availability. ## Additional context The relevant Kuna doctor, setup projection, and renderer files are unchanged between the 6.7.0 source tag and the tested main revision. This is SOURCE-ONLY release coverage; no stable-release runtime was executed. NOT_ENOUGH_INFO: first affected release and real-engine behavior were not established. Existing reports about Kuna doctor documentation, cancellation/lifecycle work, and native prerequisite checks do not cover this trigger and result.

bsakaguchi closed this issue

2026-10-31 00:37:07 +00:00

bsakaguchi commented

2026-10-31 00:37:08 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 19, 2026):

Confirmed — setup advertises availability without readiness: Kuna shows up under "What you can do now" even when cache.ok is false and open_options are invalid, which sets users up for a broken deep-analysis attempt right after setup. The doctor correctly reports healthy: false, so the projection is what's wrong.

I'd make the setup readiness gate consume the cache/workspace check the same way doctor does (instead of filtering only on availability), and treat cache failure as a remediation hint in the renderer rather than a ready provider — matching the unusable-cache diagnosis path.

@XinwangTao commented on GitHub (Oct 19, 2026): Confirmed — setup advertises availability without readiness: Kuna shows up under "What you can do now" even when cache.ok is false and open_options are invalid, which sets users up for a broken deep-analysis attempt right after setup. The doctor correctly reports healthy: false, so the projection is what's wrong. I'd make the setup readiness gate consume the cache/workspace check the same way doctor does (instead of filtering only on availability), and treat cache failure as a remediation hint in the renderer rather than a ready provider — matching the unusable-cache diagnosis path.

bsakaguchi commented

2026-10-31 00:37:08 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

Taking this one — the fix is in Setup.summarizeDoctor's availability projection (currently filters on available only), tightening it to require the provider's cache/readiness check to pass, with tests covering the cache-failed vs cache-ok cases. Will push a branch shortly.

@akushonkamen commented on GitHub (Oct 19, 2026): Taking this one — the fix is in `Setup.summarizeDoctor`'s availability projection (currently filters on `available` only), tightening it to require the provider's cache/readiness check to pass, with tests covering the cache-failed vs cache-ok cases. Will push a branch shortly.

bsakaguchi commented

2026-10-31 00:37:08 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

Fixed on branch (fork: akushonkamen/rea).

Root cause: summarizeDoctor in src/application/Setup.ts projected availableProviders by filtering provider inspections on available alone (src/application/Setup.ts:573-580), never consuming the inspection's checks. So when Kuna's cache check failed (ok: false, open_options_invalid), setup still advertised Deep analysis: Kuna even though the provider-scoped doctor correctly reports healthy: false.

Fix: tighten the projection predicate to available && checks.every(({ ok }) => ok), matching how doctor aggregates provider health (providerDoctorChecks in src/application/DoctorDiagnostics.ts:298). Hopper's existing startsWith("hopper") branch is untouched; providers with no failing checks behave exactly as before.

Tests (all local, CPU-only):

Red first: new cases in src/application/Setup.recovery.test.ts reproduce the issue via FakeSetupHost.providerInspections — cache-failed → availableProviders must not include kuna; cache-ok → still advertised. Red run: 1 failed / 13 passed before the fix.
Green after fix: npx vitest run src/application/Setup.planning.test.ts src/application/Setup.recovery.test.ts tests/boundary/providers/kuna/kunaDoctor.test.ts tests/boundary/cli/cliSetup.test.ts → 58 passed.
npx vitest run --project boundary → exit 0 (no failures).
npm run check:fast (typecheck + lint) → pass.

Note: I have not opened a PR for this — a human maintainer needs to fill the Author readiness checklist. The branch is ready whenever someone picks it up.

@akushonkamen commented on GitHub (Oct 19, 2026): Fixed on branch [](https://github.com/akushonkamen/rea/commits/fix/5105-kuna-readiness-projection) (fork: akushonkamen/rea). **Root cause**: `summarizeDoctor` in `src/application/Setup.ts` projected `availableProviders` by filtering provider inspections on `available` alone (`src/application/Setup.ts:573-580`), never consuming the inspection's `checks`. So when Kuna's cache check failed (`ok: false`, `open_options_invalid`), setup still advertised `Deep analysis: Kuna` even though the provider-scoped doctor correctly reports `healthy: false`. **Fix**: tighten the projection predicate to `available && checks.every(({ ok }) => ok)`, matching how doctor aggregates provider health (`providerDoctorChecks` in `src/application/DoctorDiagnostics.ts:298`). Hopper's existing `startsWith("hopper")` branch is untouched; providers with no failing checks behave exactly as before. **Tests** (all local, CPU-only): - Red first: new cases in `src/application/Setup.recovery.test.ts` reproduce the issue via `FakeSetupHost.providerInspections` — cache-failed → `availableProviders` must not include `kuna`; cache-ok → still advertised. Red run: 1 failed / 13 passed before the fix. - Green after fix: `npx vitest run src/application/Setup.planning.test.ts src/application/Setup.recovery.test.ts tests/boundary/providers/kuna/kunaDoctor.test.ts tests/boundary/cli/cliSetup.test.ts` → 58 passed. - `npx vitest run --project boundary` → exit 0 (no failures). - `npm run check:fast` (typecheck + lint) → pass. Note: I have not opened a PR for this — a human maintainer needs to fill the Author readiness checklist. The branch is ready whenever someone picks it up.

bsakaguchi commented

2026-10-31 00:37:09 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

Correction to my earlier progress comment: shell escaping dropped the branch name. The fix branch is fix/5105-kuna-readiness-projection on fork akushonkamen/rea — see https://github.com/akushonkamen/rea/commits/fix/5105-kuna-readiness-projection — commit b17eb3585, based on morluto/rea@0e62094b6.

@akushonkamen commented on GitHub (Oct 19, 2026): Correction to my earlier progress comment: shell escaping dropped the branch name. The fix branch is **fix/5105-kuna-readiness-projection** on fork akushonkamen/rea — see https://github.com/akushonkamen/rea/commits/fix/5105-kuna-readiness-projection — commit b17eb3585, based on morluto/rea@0e62094b6.

bsakaguchi commented

2026-10-31 00:37:09 +00:00

Author

Owner

@BaaRai commented on GitHub (Oct 20, 2026):

Thank you akushonkamen, the diagnosis is right and the fix is the correct shape.

I verified it independently on 8a2e5b2d9 (the branch head has moved past the b17eb3585 named in the earlier comment):

Root cause confirmed in the source. summarizeDoctor filters providerInspections on available alone, never consuming checks, while the hopper branch in the same projection requires every check to pass. And inspectKunaProvider returns available: true whenever the installation resolves, with the cache check appended separately (src/kuna/KunaDoctor.ts), so a failed cache root lands exactly in that gap. The provider-scoped doctor's healthy: false comes from the checks, which is why the two disagreed.
The tightened filter only changes Kuna's behavior. Walking the other inspections: GhidraInstallation returns unavailable whenever any check failed and the doctor mirrors native_authority into available; IDA computes available: valid && workspaceChecks.every(({ ok }) => ok); JADX reports available exactly when its single configuration check is ok. So available && checks.every(ok) is a no-op for those three and matches how hopper is already treated.
Your Setup.recovery tests pass 14/14 here (Node 24, Windows), and the setup acceptance suite gives identical results on your head and on your base commit on this box, so nothing new surfaces from the change.

One FYI: #5565 touches the neighboring Kuna doctor path (rejecting a dangling cache root link). The two changes look compositional rather than conflicting, but worth a glance when both are in review.

Looking forward to the PR.

@BaaRai commented on GitHub (Oct 20, 2026): Thank you akushonkamen, the diagnosis is right and the fix is the correct shape. I verified it independently on 8a2e5b2d9 (the branch head has moved past the b17eb3585 named in the earlier comment): - Root cause confirmed in the source. `summarizeDoctor` filters `providerInspections` on `available` alone, never consuming `checks`, while the hopper branch in the same projection requires every check to pass. And `inspectKunaProvider` returns `available: true` whenever the installation resolves, with the cache check appended separately (`src/kuna/KunaDoctor.ts`), so a failed cache root lands exactly in that gap. The provider-scoped doctor's `healthy: false` comes from the checks, which is why the two disagreed. - The tightened filter only changes Kuna's behavior. Walking the other inspections: `GhidraInstallation` returns `unavailable` whenever any check failed and the doctor mirrors `native_authority` into `available`; IDA computes `available: valid && workspaceChecks.every(({ ok }) => ok)`; JADX reports available exactly when its single configuration check is ok. So `available && checks.every(ok)` is a no-op for those three and matches how hopper is already treated. - Your `Setup.recovery` tests pass 14/14 here (Node 24, Windows), and the setup acceptance suite gives identical results on your head and on your base commit on this box, so nothing new surfaces from the change. One FYI: #5565 touches the neighboring Kuna doctor path (rejecting a dangling cache root link). The two changes look compositional rather than conflicting, but worth a glance when both are in review. Looking forward to the PR.

bsakaguchi commented

2026-10-31 00:37:09 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 20, 2026):

TL;DR: This looks fixed on main. Setup no longer lists Kuna when its cache check fails. Closing is the maintainers' call.

I checked main 1629266e3 (Linux, Node 24.18.0). The fix is f5d1012fa.

I used a fake Kuna version script and a regular file as the cache folder. The Kuna scan still says available: true. But the cache check says ok: false with open_options_invalid. Setup now lists no providers, and the "What you can do now" screen has no "Deep analysis" line. With an empty folder as the cache, setup lists Kuna and shows "Deep analysis: Kuna".

Not run

The real rea setup command. It has no provider flag.
A real Kuna install.
The Hopper part of the same list.

Thanks, coygeek, for the clear report.

Commands

tsx probe.mts   # real Kuna scan, real runSetup, real setup renderer, fake setup host

Exit 0. Blocked cache: {"available":true,"checks":[{"name":"installation","ok":true},{"name":"cache","ok":false,"code":"open_options_invalid"}],"status":"ready","availableProviders":[]}

Ready cache: {"available":true,"checks":[{"name":"installation","ok":true},{"name":"cache","ok":true}],"status":"ready","availableProviders":["kuna"]}

Test setup

Box: Nobara 44 (Fedora 44 base), Linux 7.2.11
CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
RAM: 32 GB DDR4-3600
Node: 24.18.0
Head: 1629266e3

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 20, 2026): **TL;DR:** This looks fixed on main. Setup no longer lists Kuna when its cache check fails. Closing is the maintainers' call. I checked main 1629266e3 (Linux, Node 24.18.0). The fix is f5d1012fa. I used a fake Kuna version script and a regular file as the cache folder. The Kuna scan still says `available: true`. But the cache check says `ok: false` with `open_options_invalid`. Setup now lists no providers, and the "What you can do now" screen has no "Deep analysis" line. With an empty folder as the cache, setup lists Kuna and shows "Deep analysis: Kuna". ### Not run - The real `rea setup` command. It has no provider flag. - A real Kuna install. - The Hopper part of the same list. Thanks, coygeek, for the clear report. <details> <summary>Commands</summary> ```sh tsx probe.mts # real Kuna scan, real runSetup, real setup renderer, fake setup host ``` Exit 0. Blocked cache: `{"available":true,"checks":[{"name":"installation","ok":true},{"name":"cache","ok":false,"code":"open_options_invalid"}],"status":"ready","availableProviders":[]}` Ready cache: `{"available":true,"checks":[{"name":"installation","ok":true},{"name":"cache","ok":true}],"status":"ready","availableProviders":["kuna"]}` </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.11 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - RAM: 32 GB DDR4-3600 - Node: 24.18.0 - Head: 1629266e3 </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

bsakaguchi commented

2026-10-31 00:37:09 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 21, 2026):

Thanks for the verification on main. This matches the intended fix direction: setup now requires the cache/readiness check to pass (available && checks.every(ok)), not just availability, so the "What you can do now" screen no longer promises Kuna deep analysis when the cache root is unusable. Closing as completed is right — the projection and the doctor now agree on the unhealthy state.

@XinwangTao commented on GitHub (Oct 21, 2026): Thanks for the verification on main. This matches the intended fix direction: setup now requires the cache/readiness check to pass (available && checks.every(ok)), not just availability, so the "What you can do now" screen no longer promises Kuna deep analysis when the cache root is unusable. Closing as completed is right — the projection and the doctor now agree on the unhealthy state.

bsakaguchi commented

2026-10-31 00:37:10 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 21, 2026):

@XinwangTao commented on GitHub (Oct 21, 2026): Thanks for the verification on main. This matches the intended fix direction: setup now requires the cache/readiness check to pass (available && checks.every(ok)), not just availability, so the "What you can do now" screen no longer promises Kuna deep analysis when the cache root is unusable. Closing as completed is right — the projection and the doctor now agree on the unhealthy state.

bsakaguchi referenced this issue

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

[PR #3142] [MERGED] ci(ghidra): compile packaged bridge sources before merge #5639

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

No description provided.

Rows
Columns