morluto/rea

Fork 0

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

[PR #3041] [MERGED] feat(setup): add WorkBuddy client support #5575

New issue

Closed

opened 2026-10-31 01:07:41 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:07:41 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/3041
Author: @cainiao1992
Created: 10/13/2026
Status: ✅ Merged
Merged: 10/14/2026
Merged by: @morluto

Base: main ← Head: feat/workbuddy-setup-clients

📝 Commits (2)

4e94217 feat(setup): add WorkBuddy client support
3b28a99 docs(setup): record verified WorkBuddy tool calls

📊 Changes

5 files changed (+186 additions, -2 deletions)

View changed files

📝 docs/client-configuration.md (+15 -0)
📝 docs/installation.md (+3 -2)
📝 src/application/SupportedClients.ts (+8 -0)
📝 tests/boundary/filesystem/clientLifecycle.test.ts (+1 -0)
➕ tests/boundary/filesystem/workbuddyClientConfiguration.test.ts (+159 -0)

📄 Description

Summary

Adds WorkBuddy as a supported setup client. rea setup --client workbuddy (and auto-detection when ~/.workbuddy exists) now registers REA's local MCP server in the global ~/.workbuddy/mcp.json and installs the bundled skill under ~/.workbuddy/skills. WorkBuddy AI shares this configuration file, so the single client covers both names. Closes #3040; also addresses the request raised in a comment on #2490.

Problem and expected behavior

WorkBuddy reads a standard mcpServers JSON file at ~/.workbuddy/mcp.json, but it was absent from SUPPORTED_CLIENT_DEFINITIONS, so WorkBuddy users had to hand-edit that file and rea setup/doctor/uninstall could not manage the registration. Expected behavior now: setup upserts mcpServers.rea (stdio command) while preserving unrelated servers and top-level keys; client detection uses the ~/.workbuddy directory as its marker; uninstall removes only the rea entry.

Change and scope

New workbuddy entry in SUPPORTED_CLIENT_DEFINITIONS (placed after trae, which also keeps it clear of the pending #2492 insertion point): configPath: [".workbuddy", "mcp.json"], markerPath: [".workbuddy"], skillPath: [".workbuddy", "skills"], format: "json". The --client allowlist, detection, registration, uninstall, and the generated product catalog all derive from this array, so no CLI or registration-logic changes were needed.
Docs: supported-agents table row and unreleased-client note in docs/installation.md (mirroring how #2744 handled kimi); a WorkBuddy section in docs/client-configuration.md.
Tests: new tests/boundary/filesystem/workbuddyClientConfiguration.test.ts mirroring the Trae/CodeBuddy client tests; detection list in clientLifecycle.test.ts extended.

Configuration facts are sourced from the official WorkBuddy MCP guide (user-level ~/.workbuddy/mcp.json, standard mcpServers JSON with stdio command/args/env) and WorkBuddy skill authoring guides (personal skills at ~/.workbuddy/skills, %userprofile%\.workbuddy\skills on Windows).

Follow the contribution scope: not applicable — an ordinary setup-client addition within existing boundaries; no new provider and no capability involving target execution, injection, mutation, or protection recovery.

Contract and boundary impact

Semantic owner and earliest changed stage: setup / client registration (application layer).
Contribution scope fit and linked maintainer decision: not applicable (ordinary setup-client addition; feature request #3040 linked).
CLI and MCP/tool-catalog contract: new accepted --client workbuddy value; docs/public/product-catalog.json setup_clients gains workbuddy (generated and CI-validated; not committed).
Provider, bridge, target-format, or platform compatibility: none.
Evidence, artifact, provenance, or reconstruction contract: none.
Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable.
Generated metadata (docs/public/product-catalog.json), package, or installation impact: regenerated locally to validate (node scripts/generate-product-catalog.mjs); the file is gitignored and CI-generated.

Expected effects (check known effects; use documentation-only on its own).

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

Setup itself writes only the user's local WorkBuddy configuration file on explicit request; no analyzed-target interaction is introduced.

Evidence and regression coverage

Tests added or updated: tests/boundary/filesystem/workbuddyClientConfiguration.test.ts (new; 7 tests — per-platform path resolution, json format, personal skill directory, upsert preserving unrelated servers, registration into an existing config without servers, registration into an empty file, uninstall removing only rea); tests/boundary/filesystem/clientLifecycle.test.ts detection list extended with workbuddy.
Base reproduction or other evidence: before the change, supportedClients(home) returned no workbuddy client and --client workbuddy failed CLI validation.

User-visible CLI/MCP output: end-to-end run against an isolated HOME with node scripts/rea.mjs setup --client workbuddy --skill-client workbuddy --yes:

plannedActions[2]:
  configure_client:workbuddy — target: <home>/.workbuddy/mcp.json
  install_skill:workbuddy    — target: <home>/.workbuddy/skills/reverse-engineer-anything
appliedActions[2]: configured_workbuddy, installed_skill
clients:
  workbuddy:
    status: configured

resulting <home>/.workbuddy/mcp.json (the registered command reflects the entrypoint that launched setup — the local checkout in this run, npx -y rea-agents@latest mcp from a published install):

{
  "mcpServers": {
    "rea": { "command": "<rea entrypoint>", "args": ["mcp"] }
  }
}

Remaining proof gaps: none known. Verified by the author in the real WorkBuddy client: the registration loads and real REA tool calls execute through the registered server (recorded in docs/client-configuration.md, commit 3b28a99f9).

For evidence-bearing changes: not applicable — this change produces no analysis evidence or artifacts.

Validation performed

npm run build:cached — build succeeded
node scripts/generate-product-catalog.mjs and node scripts/generate-product-catalog.mjs --check — regenerated and validated against source definitions
npm run typecheck — passed
npx vitest run tests/boundary/filesystem/clientLifecycle.test.ts tests/boundary/filesystem/workbuddyClientConfiguration.test.ts tests/boundary/filesystem/productCatalog.test.ts — 72/72 tests passed
node scripts/check-doc-facts.mjs — no issues
npx oxfmt --check on the five changed files — all formatted
npx oxlint on the changed source/test files — no new findings (pre-existing max-lines warning in SupportedClients.ts unchanged)
Isolated-HOME setup --client workbuddy --skill-client workbuddy --yes run configured the client and installed the skill as shown above
Real-client verification by the author: WorkBuddy loaded the registration and real REA tool calls ran successfully (3b28a99f9)

Compatibility, safety, and release

Breaking changes or migration steps: none.
Real Hopper/Ghidra, browser, or OS coverage: not applicable.
Package or release metadata impact: none beyond the generated (gitignored) product catalog gaining the workbuddy setup client; documentation updated, including the unreleased-client note (dsh, kimi, and workbuddy require a release containing them).
Security, privacy, process, or containment review: no target-facing behavior; setup writes only the local WorkBuddy configuration file when requested.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. (Not applicable: ordinary setup-client addition; no new provider or target-interacting capability.)
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above. (#3040; also requested in a comment on #2490)
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 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/3041 **Author:** [@cainiao1992](https://github.com/cainiao1992) **Created:** 10/13/2026 **Status:** ✅ Merged **Merged:** 10/14/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `feat/workbuddy-setup-clients` --- ### 📝 Commits (2) - [`4e94217`](https://github.com/morluto/rea/commit/4e9421707cda186b2168eb1f565b0fa0b37ae0bf) feat(setup): add WorkBuddy client support - [`3b28a99`](https://github.com/morluto/rea/commit/3b28a99f96777ef68364f6b6fc8d042c1695a012) docs(setup): record verified WorkBuddy tool calls ### 📊 Changes **5 files changed** (+186 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `docs/client-configuration.md` (+15 -0) 📝 `docs/installation.md` (+3 -2) 📝 `src/application/SupportedClients.ts` (+8 -0) 📝 `tests/boundary/filesystem/clientLifecycle.test.ts` (+1 -0) ➕ `tests/boundary/filesystem/workbuddyClientConfiguration.test.ts` (+159 -0) </details> ### 📄 Description ## Summary Adds WorkBuddy as a supported setup client. `rea setup --client workbuddy` (and auto-detection when `~/.workbuddy` exists) now registers REA's local MCP server in the global `~/.workbuddy/mcp.json` and installs the bundled skill under `~/.workbuddy/skills`. WorkBuddy AI shares this configuration file, so the single client covers both names. Closes #3040; also addresses the request raised in a comment on #2490. ## Problem and expected behavior WorkBuddy reads a standard `mcpServers` JSON file at `~/.workbuddy/mcp.json`, but it was absent from `SUPPORTED_CLIENT_DEFINITIONS`, so WorkBuddy users had to hand-edit that file and `rea setup`/`doctor`/`uninstall` could not manage the registration. Expected behavior now: setup upserts `mcpServers.rea` (stdio command) while preserving unrelated servers and top-level keys; client detection uses the `~/.workbuddy` directory as its marker; uninstall removes only the `rea` entry. ## Change and scope - New `workbuddy` entry in `SUPPORTED_CLIENT_DEFINITIONS` (placed after `trae`, which also keeps it clear of the pending #2492 insertion point): `configPath: [".workbuddy", "mcp.json"]`, `markerPath: [".workbuddy"]`, `skillPath: [".workbuddy", "skills"]`, `format: "json"`. The `--client` allowlist, detection, registration, uninstall, and the generated product catalog all derive from this array, so no CLI or registration-logic changes were needed. - Docs: supported-agents table row and unreleased-client note in `docs/installation.md` (mirroring how #2744 handled `kimi`); a WorkBuddy section in `docs/client-configuration.md`. - Tests: new `tests/boundary/filesystem/workbuddyClientConfiguration.test.ts` mirroring the Trae/CodeBuddy client tests; detection list in `clientLifecycle.test.ts` extended. Configuration facts are sourced from the official WorkBuddy MCP guide (user-level `~/.workbuddy/mcp.json`, standard `mcpServers` JSON with stdio `command`/`args`/`env`) and WorkBuddy skill authoring guides (personal skills at `~/.workbuddy/skills`, `%userprofile%\.workbuddy\skills` on Windows). Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope): not applicable — an ordinary setup-client addition within existing boundaries; no new provider and no capability involving target execution, injection, mutation, or protection recovery. ## Contract and boundary impact - Semantic owner and earliest changed stage: setup / client registration (application layer). - Contribution scope fit and linked maintainer decision: not applicable (ordinary setup-client addition; feature request #3040 linked). - CLI and MCP/tool-catalog contract: new accepted `--client workbuddy` value; `docs/public/product-catalog.json` `setup_clients` gains `workbuddy` (generated and CI-validated; not committed). - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: none. - Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: regenerated locally to validate (`node scripts/generate-product-catalog.mjs`); the file is gitignored and CI-generated. Expected effects (check known effects; use documentation-only on its own). - [ ] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [x] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. Setup itself writes only the user's local WorkBuddy configuration file on explicit request; no analyzed-target interaction is introduced. ## Evidence and regression coverage - Tests added or updated: `tests/boundary/filesystem/workbuddyClientConfiguration.test.ts` (new; 7 tests — per-platform path resolution, `json` format, personal skill directory, upsert preserving unrelated servers, registration into an existing config without servers, registration into an empty file, uninstall removing only `rea`); `tests/boundary/filesystem/clientLifecycle.test.ts` detection list extended with `workbuddy`. - Base reproduction or other evidence: before the change, `supportedClients(home)` returned no `workbuddy` client and `--client workbuddy` failed CLI validation. - User-visible CLI/MCP output: end-to-end run against an isolated HOME with `node scripts/rea.mjs setup --client workbuddy --skill-client workbuddy --yes`: ``` plannedActions[2]: configure_client:workbuddy — target: <home>/.workbuddy/mcp.json install_skill:workbuddy — target: <home>/.workbuddy/skills/reverse-engineer-anything appliedActions[2]: configured_workbuddy, installed_skill clients: workbuddy: status: configured ``` resulting `<home>/.workbuddy/mcp.json` (the registered `command` reflects the entrypoint that launched setup — the local checkout in this run, `npx -y rea-agents@latest mcp` from a published install): ```json { "mcpServers": { "rea": { "command": "<rea entrypoint>", "args": ["mcp"] } } } ``` - Remaining proof gaps: none known. Verified by the author in the real WorkBuddy client: the registration loads and real REA tool calls execute through the registered server (recorded in `docs/client-configuration.md`, commit 3b28a99f9). For evidence-bearing changes: not applicable — this change produces no analysis evidence or artifacts. ## Validation performed - `npm run build:cached` — build succeeded - `node scripts/generate-product-catalog.mjs` and `node scripts/generate-product-catalog.mjs --check` — regenerated and validated against source definitions - `npm run typecheck` — passed - `npx vitest run tests/boundary/filesystem/clientLifecycle.test.ts tests/boundary/filesystem/workbuddyClientConfiguration.test.ts tests/boundary/filesystem/productCatalog.test.ts` — 72/72 tests passed - `node scripts/check-doc-facts.mjs` — no issues - `npx oxfmt --check` on the five changed files — all formatted - `npx oxlint` on the changed source/test files — no new findings (pre-existing `max-lines` warning in `SupportedClients.ts` unchanged) - Isolated-HOME `setup --client workbuddy --skill-client workbuddy --yes` run configured the client and installed the skill as shown above - Real-client verification by the author: WorkBuddy loaded the registration and real REA tool calls ran successfully (3b28a99f9) ## Compatibility, safety, and release - Breaking changes or migration steps: none. - Real Hopper/Ghidra, browser, or OS coverage: not applicable. - Package or release metadata impact: none beyond the generated (gitignored) product catalog gaining the `workbuddy` setup client; documentation updated, including the unreleased-client note (`dsh`, `kimi`, and `workbuddy` require a release containing them). - Security, privacy, process, or containment review: no target-facing behavior; setup writes only the local WorkBuddy configuration file when requested. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. (Not applicable: ordinary setup-client addition; no new provider or target-interacting capability.) - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. (#3040; also requested in a comment on #2490) - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:07:41 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-11-01 21:44:25 +00:00

[PR #5575] [CLOSED] fix(swift): keep nested types with undecoded identifiers unclassified #6974

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

No description provided.

Rows
Columns