morluto/rea

Fork 0

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

[GH-ISSUE #4402] [Design] Choose the skill root REA owns for DeepSeek Harness #1753

New issue

Open

opened 2026-10-16 21:09:51 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:09:51 +00:00

Owner

Originally created by @cainiao1992 on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4402

Before submitting

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

Decision needed

Which skill destination should REA own for DeepSeek Harness: the client's own user root <dshHome>/skills (~/.dsh/skills), or the shared <agentsHome>/skills (~/.agents/skills) that #1929 chose and #2461 kept?

Today rea setup --client dsh installs the bundled skill into the shared agents root, so a dsh-only installation also changes the skill catalog of every other agent that reads that root.

Context and evidence

Source-derived. Harness's local provider resolves user skill roots in this order:

rank	source	root
100	project-dsh	`<projectRoot>/.dsh/skills`
200	project-agents	`<projectRoot>/.agents/skills`
300	custom	`Config.customSkillDirs`
400	user-dsh	`<dshHome>/skills` (its `.system` entry is skipped)
500	user-agents	`<agentsHome>/skills`
600	bundled	`Config.bundledSkillDir` / `DSH_BUNDLED_SKILL_DIR`

<dshHome>/skills is the client's own user root and outranks the shared one. Harness resolves dshHome from DSH_HOME (default ~/.dsh) and agentsHome from DSH_AGENTS_HOME (default ~/.agents); REA already mirrors that resolver, including the blank-is-unset, tilde-expansion and relative-against-cwd rules, so no mapping correction is being proposed here.

Observed on macOS 15 (arm64), REA 6.5.0, Harness desktop 0.2.0-rc.2:

~/.dsh/skills/ exists and is empty; no reverse-engineer-anything entry exists under ~/.agents/skills/.
REA resolves the dsh skill destination to ~/.agents/skills (skillPath for dsh in src/application/SupportedClients.ts), and docs/client-configuration.md documents that destination.

Reachability. REA gives kimi, pi, qwen_code, codex, omp and grok_build no client-specific skillPath, so they resolve to the same shared root. A skill written there is therefore visible to all of them, not only to dsh, which is what makes a dsh-only installation a cross-agent side effect rather than a local choice.

Not claimed. I have not re-run the DeepSeek Harness native verification against <dshHome>/skills, and I have no measurement of the cost difference between the two roots; the only cost I can name from the source is one additional skill destination to install and to keep current for users who also run a shared-root client.

Expected interaction with targets

Read existing files or captured data
Write or change files/configuration

Boundary details

Owner of the decision: the dsh skill destination in src/application/SupportedClients.ts. Setup planning, doctor skill identity and uninstall all derive their destinations from it, so one definition decides all three.
Unchanged by either option: MCP registration in $DSH_HOME/cordis.patch.yml, Harness home resolution, providers, and every other client's root.
Not affected: the explicit --skill-client shared scope, which keeps pointing at ~/.agents/skills either way.

Options and tradeoffs

Install under <dshHome>/skills (rank 400). A dsh-only installation stays out of other agents' catalogs and lands on the client's higher-priority user root. Costs users who also run a shared-root client a second copy to install and maintain, and diverges from the existing convention of reusing the shared root whenever a client discovers it.
Keep <agentsHome>/skills (status quo). One copy serves every agent that reads the shared root, which may be the intended behavior rather than a defect. A user who wants REA available only to dsh cannot install the skill without adding it to the shared catalog.
Keep the shared root as the default and add an explicit opt-in for the client-private root. Note that --skill-client dsh already resolves to the same shared directory today, so this needs a distinct selection rather than reusing the client id.

Verification available so far

I can suggest a sample or manual check

Success criteria and open questions

A decision on which root REA owns for dsh.
If the destination changes: setup's plan, doctor's skill identity and uninstall all report <dshHome>/skills, and the dsh native lane is re-run with the new expected path, or that verification gap is stated explicitly in the change.
Open question: should the shared root stay the default, with the client-private root available only on explicit selection?

References

Harness skills reference, "本地发现优先级": https://deepseek-harness.github.io/deepseek-harness/reference/subsystems/skills
Harness user skill roots: github.com/deepseek-ai/deepseek-harness@86a402200d/packages/skill/skill-filesystem/src/index.ts (L254-L259)
Harness home resolver: github.com/deepseek-ai/deepseek-harness@86a402200d/packages/util/home-paths/src/index.ts (L101-L153)
REA: #1839 (dsh client request), #1929 (dsh setup integration), #2461 (dsh home override resolution)
REA source and docs: src/application/SupportedClients.ts, docs/client-configuration.md (DeepSeek Harness)

Originally created by @cainiao1992 on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4402 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [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 discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Which skill destination should REA own for DeepSeek Harness: the client's own user root `<dshHome>/skills` (`~/.dsh/skills`), or the shared `<agentsHome>/skills` (`~/.agents/skills`) that #1929 chose and #2461 kept? Today `rea setup --client dsh` installs the bundled skill into the shared agents root, so a dsh-only installation also changes the skill catalog of every other agent that reads that root. ### Context and evidence **Source-derived.** Harness's local provider resolves user skill roots in this order: | rank | source | root | | --- | --- | --- | | 100 | project-dsh | `<projectRoot>/.dsh/skills` | | 200 | project-agents | `<projectRoot>/.agents/skills` | | 300 | custom | `Config.customSkillDirs` | | 400 | user-dsh | `<dshHome>/skills` (its `.system` entry is skipped) | | 500 | user-agents | `<agentsHome>/skills` | | 600 | bundled | `Config.bundledSkillDir` / `DSH_BUNDLED_SKILL_DIR` | `<dshHome>/skills` is the client's own user root and outranks the shared one. Harness resolves `dshHome` from `DSH_HOME` (default `~/.dsh`) and `agentsHome` from `DSH_AGENTS_HOME` (default `~/.agents`); REA already mirrors that resolver, including the blank-is-unset, tilde-expansion and relative-against-cwd rules, so no mapping correction is being proposed here. **Observed** on macOS 15 (arm64), REA 6.5.0, Harness desktop 0.2.0-rc.2: - `~/.dsh/skills/` exists and is empty; no `reverse-engineer-anything` entry exists under `~/.agents/skills/`. - REA resolves the dsh skill destination to `~/.agents/skills` (`skillPath` for `dsh` in `src/application/SupportedClients.ts`), and `docs/client-configuration.md` documents that destination. **Reachability.** REA gives kimi, pi, qwen_code, codex, omp and grok_build no client-specific `skillPath`, so they resolve to the same shared root. A skill written there is therefore visible to all of them, not only to dsh, which is what makes a dsh-only installation a cross-agent side effect rather than a local choice. **Not claimed.** I have not re-run the DeepSeek Harness native verification against `<dshHome>/skills`, and I have no measurement of the cost difference between the two roots; the only cost I can name from the source is one additional skill destination to install and to keep current for users who also run a shared-root client. ### Expected interaction with targets - Read existing files or captured data - Write or change files/configuration ### Boundary details - Owner of the decision: the dsh skill destination in `src/application/SupportedClients.ts`. Setup planning, doctor skill identity and uninstall all derive their destinations from it, so one definition decides all three. - Unchanged by either option: MCP registration in `$DSH_HOME/cordis.patch.yml`, Harness home resolution, providers, and every other client's root. - Not affected: the explicit `--skill-client shared` scope, which keeps pointing at `~/.agents/skills` either way. ### Options and tradeoffs 1. **Install under `<dshHome>/skills` (rank 400).** A dsh-only installation stays out of other agents' catalogs and lands on the client's higher-priority user root. Costs users who also run a shared-root client a second copy to install and maintain, and diverges from the existing convention of reusing the shared root whenever a client discovers it. 2. **Keep `<agentsHome>/skills` (status quo).** One copy serves every agent that reads the shared root, which may be the intended behavior rather than a defect. A user who wants REA available only to dsh cannot install the skill without adding it to the shared catalog. 3. **Keep the shared root as the default and add an explicit opt-in for the client-private root.** Note that `--skill-client dsh` already resolves to the same shared directory today, so this needs a distinct selection rather than reusing the client id. ### Verification available so far I can suggest a sample or manual check ### Success criteria and open questions - A decision on which root REA owns for dsh. - If the destination changes: setup's plan, doctor's skill identity and uninstall all report `<dshHome>/skills`, and the dsh native lane is re-run with the new expected path, or that verification gap is stated explicitly in the change. - Open question: should the shared root stay the default, with the client-private root available only on explicit selection? ### References - Harness skills reference, "本地发现优先级": https://deepseek-harness.github.io/deepseek-harness/reference/subsystems/skills - Harness user skill roots: https://github.com/deepseek-ai/deepseek-harness/blob/86a402200d95fecef4529d969836f1fe13c6cb0d/packages/skill/skill-filesystem/src/index.ts#L254-L259 - Harness home resolver: https://github.com/deepseek-ai/deepseek-harness/blob/86a402200d95fecef4529d969836f1fe13c6cb0d/packages/util/home-paths/src/index.ts#L101-L153 - REA: #1839 (dsh client request), #1929 (dsh setup integration), #2461 (dsh home override resolution) - REA source and docs: `src/application/SupportedClients.ts`, `docs/client-configuration.md` (DeepSeek Harness)

bsakaguchi commented

2026-10-16 21:09:52 +00:00

Author

Owner

@cainiao1992 commented on GitHub (Oct 16, 2026):

Implemented option 1 locally and verified it against a real client, in case that helps settle the direction.

Change

The dsh skill destination follows the Harness home: $DSH_HOME/skills (default ~/.dsh/skills), the rank-400 user-dsh root.
REA no longer reads DSH_AGENTS_HOME; that variable describes the shared agents root only.
The previous two-root path helper had one remaining caller, so it is folded into the Harness home resolver.
Visible to JSON consumers: the skill action id in a setup plan becomes install_skill:dsh (was install_skill), because the destination no longer coincides with the shared root. This matches install_skill:claude_code and the other client-specific destinations.

Verified on macOS 15 (arm64), Harness desktop 0.2.0-rc.2 (dsh CLI @deepseek-ai/dsh@0.2.0-rc.2), REA 6.5.0 from a checkout:

setup --client dsh writes $DSH_HOME/cordis.patch.yml and installs the skill into ~/.dsh/skills/reverse-engineer-anything. ~/.agents/skills stays untouched, and doctor reports both the registration and the skill as aligned.
The generated launcher starts over stdio and answers binary_session with the complete 207-tool catalog, so the registration is live rather than merely written.
dsh --profile web --dump-config composes the home patch into the profile tree, confirming the client reads the file REA wrote.
After a Harness restart the client loaded the skill through its own user root and served REA tools; confirmed interactively.
Focused client and setup suites pass with the new destination (258 and 64 tests), including a case that sets DSH_AGENTS_HOME and asserts the dsh destination ignores it. check:fast and docs:check pass.
npm run verify:deepseek-client reaches skillLoaded: true through the new root (dry-run, setup, idempotent setup, scoped doctor, 207-tool catalog). The lane still ends passed: false on a macOS-only /private/var versus /var mismatch in its local_path assertion for the analysis evidence; the unmodified baseline fails identically, so it is unrelated to this change.

Not verified: Windows, live DeepSeek API compatibility, and the complete check:pr gate. Those gaps are stated here rather than implied.

Migration note

Existing installations are not moved. Setup leaves an older ~/.agents/skills/reverse-engineer-anything in place, matching the documented behavior that setup does not touch skill copies in other locations; uninstall still removes that copy through the shared root. A machine that never used the shared root ends up with no trace there, which is the point of the change.

Happy to open a PR if this is the direction you want. If you would rather keep the shared root as the default and offer the client-private root as an explicit selection instead, say so and I will rework it to that shape.

@cainiao1992 commented on GitHub (Oct 16, 2026): Implemented option 1 locally and verified it against a real client, in case that helps settle the direction. **Change** - The dsh skill destination follows the Harness home: `$DSH_HOME/skills` (default `~/.dsh/skills`), the rank-400 `user-dsh` root. - REA no longer reads `DSH_AGENTS_HOME`; that variable describes the shared agents root only. - The previous two-root path helper had one remaining caller, so it is folded into the Harness home resolver. - Visible to JSON consumers: the skill action id in a setup plan becomes `install_skill:dsh` (was `install_skill`), because the destination no longer coincides with the shared root. This matches `install_skill:claude_code` and the other client-specific destinations. **Verified** on macOS 15 (arm64), Harness desktop `0.2.0-rc.2` (dsh CLI `@deepseek-ai/dsh@0.2.0-rc.2`), REA `6.5.0` from a checkout: - `setup --client dsh` writes `$DSH_HOME/cordis.patch.yml` and installs the skill into `~/.dsh/skills/reverse-engineer-anything`. `~/.agents/skills` stays untouched, and doctor reports both the registration and the skill as `aligned`. - The generated launcher starts over stdio and answers `binary_session` with the complete 207-tool catalog, so the registration is live rather than merely written. - `dsh --profile web --dump-config` composes the home patch into the profile tree, confirming the client reads the file REA wrote. - After a Harness restart the client loaded the skill through its own user root and served REA tools; confirmed interactively. - Focused client and setup suites pass with the new destination (258 and 64 tests), including a case that sets `DSH_AGENTS_HOME` and asserts the dsh destination ignores it. `check:fast` and `docs:check` pass. - `npm run verify:deepseek-client` reaches `skillLoaded: true` through the new root (dry-run, setup, idempotent setup, scoped doctor, 207-tool catalog). The lane still ends `passed: false` on a macOS-only `/private/var` versus `/var` mismatch in its `local_path` assertion for the analysis evidence; the unmodified baseline fails identically, so it is unrelated to this change. Not verified: Windows, live DeepSeek API compatibility, and the complete `check:pr` gate. Those gaps are stated here rather than implied. **Migration note** Existing installations are not moved. Setup leaves an older `~/.agents/skills/reverse-engineer-anything` in place, matching the documented behavior that setup does not touch skill copies in other locations; uninstall still removes that copy through the shared root. A machine that never used the shared root ends up with no trace there, which is the point of the change. Happy to open a PR if this is the direction you want. If you would rather keep the shared root as the default and offer the client-private root as an explicit selection instead, say so and I will rework it to that shape.

bsakaguchi referenced this issue

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

[PR #1756] [MERGED] fix(process): aggregate incomplete trace-spec diagnostics #4796

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

No description provided.

Rows
Columns