[GH-ISSUE #7091] [Bug] doctor classifies an unreadable skill copy as config drift #4272

Closed
opened 2026-10-31 00:48:21 +00:00 by bsakaguchi · 3 comments
Owner

Originally created by @Adolanium on GitHub (Oct 25, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7091

Before submitting

  • I searched the open and closed issues for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

rea doctor --json with a skill copy that cannot be read reports identity.skill.state: "unknown", but its skill:identity check has classification: "config_drift", as if the copy had drifted.

Reproduction

Ran on Linux (WSL Ubuntu, Node 24.22.1) at upstream/main 80673b22a, through runDoctor in a test with an installed skill identity carrying one unreadable path issue: the skill state is unknown and the check classification is config_drift.

Expected behavior

classification: "unknown", matching the skill state and the registration checks, which already classify unknown state as unknown.

Impact and scope

Agents and users following doctor output are told to repair drift when the real problem is that the skill files could not be read.

REA version

6.7.0, revision 80673b22a

Runtime and platform

Linux (WSL Ubuntu), Node 24.22.1

Target and artifact context

No target; doctor with a fixture host.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Root cause and fix are in #7090, with the regression test.

Typed outcome or recovery expected

No new error.

Analysis or suspected cause

Root cause and fix are in #7090.

Additional context

Fixed by #7090.

Originally created by @Adolanium on GitHub (Oct 25, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7091 ### 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 Setup, packaging, or upgrade ### Observed behavior `rea doctor --json` with a skill copy that cannot be read reports `identity.skill.state: "unknown"`, but its `skill:identity` check has `classification: "config_drift"`, as if the copy had drifted. ### Reproduction Ran on Linux (WSL Ubuntu, Node 24.22.1) at upstream/main 80673b22a, through `runDoctor` in a test with an installed skill identity carrying one `unreadable` path issue: the skill state is `unknown` and the check classification is `config_drift`. ### Expected behavior `classification: "unknown"`, matching the skill state and the registration checks, which already classify unknown state as `unknown`. ### Impact and scope Agents and users following doctor output are told to repair drift when the real problem is that the skill files could not be read. ### REA version 6.7.0, revision `80673b22a` ### Runtime and platform Linux (WSL Ubuntu), Node 24.22.1 ### Target and artifact context No target; doctor with a fixture host. ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Root cause and fix are in #7090, with the regression test. ### Typed outcome or recovery expected No new error. ### Analysis or suspected cause Root cause and fix are in #7090. ### Additional context Fixed by #7090.
Author
Owner

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

这个不一致确实容易误导人:skill 状态明明是 unknown,doctor 却输出 config_drift,用户会沿着"配置漂移"的方向去排查,结果真正原因只是文件不可读,白白浪费时间。让 classification 与 state 及注册检查保持一致(unknown)更符合直觉,也避免错误引导。感谢修复,回归测试也很有价值。

<!-- gh-comment-id:6395570728 --> @XinwangTao commented on GitHub (Oct 25, 2026): 这个不一致确实容易误导人:skill 状态明明是 unknown,doctor 却输出 config_drift,用户会沿着"配置漂移"的方向去排查,结果真正原因只是文件不可读,白白浪费时间。让 classification 与 state 及注册检查保持一致(unknown)更符合直觉,也避免错误引导。感谢修复,回归测试也很有价值。
Author
Owner

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

Agreed — classifying an unreadable copy as config_drift conflates 'cannot inspect' with 'content differs', which misleads users into thinking a diff exists when there may simply be a permission/IO problem. The state field already says unknown, so the classification should be consistent with it (e.g. a distinct 'unreadable' category or at least unknown), and the doctor report should surface the underlying read error so the user knows to check permissions rather than restore from source. Suggest a regression test where the copy is unreadable (chmod 000) and asserting classification stays out of config_drift.

<!-- gh-comment-id:6399727329 --> @XinwangTao commented on GitHub (Oct 25, 2026): Agreed — classifying an unreadable copy as config_drift conflates 'cannot inspect' with 'content differs', which misleads users into thinking a diff exists when there may simply be a permission/IO problem. The state field already says unknown, so the classification should be consistent with it (e.g. a distinct 'unreadable' category or at least unknown), and the doctor report should surface the underlying read error so the user knows to check permissions rather than restore from source. Suggest a regression test where the copy is unreadable (chmod 000) and asserting classification stays out of config_drift.
Author
Owner

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

Thanks. #7090 classifies the check as unknown (the existing classification the registration checks use), and the check detail still names the unreadable path from the skill identity issue, so the permission problem stays visible. The regression test uses an unreadable path issue through runDoctor rather than a real chmod 000, which would not behave the same on every host.

<!-- gh-comment-id:6399768552 --> @Adolanium commented on GitHub (Oct 25, 2026): Thanks. #7090 classifies the check as `unknown` (the existing classification the registration checks use), and the check detail still names the unreadable path from the skill identity issue, so the permission problem stays visible. The regression test uses an `unreadable` path issue through `runDoctor` rather than a real `chmod 000`, which would not behave the same on every host.
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#4272
No description provided.