[GH-ISSUE #6914] [Feature] Clarify rea doctor health when optional components are unconfigured #4236

Open
opened 2026-10-31 00:47:57 +00:00 by bsakaguchi · 3 comments
Owner

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

Before submitting

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

Area

CLI

Current limitation

Running rea doctor after configuring only Codex and Ghidra reports healthy: false because other detected but unconfigured clients/providers are also included in the audit. This can make a healthy configured workflow look broken.

Use cases

No response

Desired outcome and success criteria

I suggest making the CLI clearly distinguish audit-wide health from the health of the configured workflow, especially when failures come only from optional or unconfigured components.

Expected interaction with targets

No target interaction (documentation or usability only)

Target and scope details (optional)

No response

Verification available so far

I have a prototype or observed results

Verification details (optional)

No response

Alternatives considered

No response

Possible direction

No response

References

No response

Originally created by @Innerloop17 on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6914 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area CLI ### Current limitation Running `rea doctor` after configuring only Codex and Ghidra reports `healthy: false` because other detected but unconfigured clients/providers are also included in the audit. This can make a healthy configured workflow look broken. ### Use cases _No response_ ### Desired outcome and success criteria I suggest making the CLI clearly distinguish audit-wide health from the health of the configured workflow, especially when failures come only from optional or unconfigured components. ### Expected interaction with targets No target interaction (documentation or usability only) ### Target and scope details (optional) _No response_ ### Verification available so far I have a prototype or observed results ### Verification details (optional) _No response_ ### Alternatives considered _No response_ ### Possible direction _No response_ ### References _No response_
Author
Owner

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

Agree — a healthy configured workflow shouldn't look broken just because optional components are unconfigured. Suggest reporting unconfigured/optional clients as a separate status category (e.g. skipped/unconfigured) instead of folding them into healthy:false, and printing two summaries: overall audit health and configured-workflow health. A --scope configured flag to audit only what the user has actually set up would also make this actionable.

<!-- gh-comment-id:6378707293 --> @XinwangTao commented on GitHub (Oct 24, 2026): Agree — a healthy configured workflow shouldn't look broken just because optional components are unconfigured. Suggest reporting unconfigured/optional clients as a separate status category (e.g. skipped/unconfigured) instead of folding them into healthy:false, and printing two summaries: overall audit health and configured-workflow health. A --scope configured flag to audit only what the user has actually set up would also make this actionable.
Author
Owner

@akshatgg commented on GitHub (Oct 24, 2026):

I ran into this too and opened #7004 as a draft.

It keeps healthy and the exit status exactly as they are, so the audit-wide result stays authoritative. In audit-wide mode the report also gets a configured_scope section:

  • the registered clients (any registration state except missing or manual, so stale registrations still count against it), the configured or discovered providers, and the installed skill;
  • their healthy, computed with the existing explicit-scope rules rather than a new definition;
  • the exact command that reports only that scope, e.g. rea doctor --client cursor --provider ghidra --skill.

That is close to the two-summary idea above, without a new flag, since --client/--provider/--skill already scope the check. Happy to adjust the field name or add a short human-readable line if that fits better.

<!-- gh-comment-id:6384251432 --> @akshatgg commented on GitHub (Oct 24, 2026): I ran into this too and opened #7004 as a draft. It keeps `healthy` and the exit status exactly as they are, so the audit-wide result stays authoritative. In audit-wide mode the report also gets a `configured_scope` section: - the registered clients (any registration state except missing or manual, so stale registrations still count against it), the configured or discovered providers, and the installed skill; - their `healthy`, computed with the existing explicit-scope rules rather than a new definition; - the exact command that reports only that scope, e.g. `rea doctor --client cursor --provider ghidra --skill`. That is close to the two-summary idea above, without a new flag, since `--client`/`--provider`/`--skill` already scope the check. Happy to adjust the field name or add a short human-readable line if that fits better.
Author
Owner

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

Thanks for opening #7004 — reusing --client/--provider/--skill instead of a new flag keeps the CLI surface small, and keeping healthy/exit status authoritative for the audit-wide result makes sense. One suggestion: in the configured_scope section, also list the detected-but-unconfigured components as skipped, so users can see at a glance that the gap is expected rather than a misconfiguration. A short human-readable line like "workflow healthy; N optional components unconfigured" would make the summary easier to read in terminal output.

<!-- gh-comment-id:6391950072 --> @XinwangTao commented on GitHub (Oct 25, 2026): Thanks for opening #7004 — reusing --client/--provider/--skill instead of a new flag keeps the CLI surface small, and keeping healthy/exit status authoritative for the audit-wide result makes sense. One suggestion: in the configured_scope section, also list the detected-but-unconfigured components as skipped, so users can see at a glance that the gap is expected rather than a misconfiguration. A short human-readable line like "workflow healthy; N optional components unconfigured" would make the summary easier to read in terminal output.
Sign in to join this conversation.
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#4236
No description provided.