morluto/rea

Fork 0

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

[PR #1376] [MERGED] feat(setup): add native Pi client support #2838

New issue

Closed

opened 2026-10-17 21:10:51 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-17 21:10:51 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1376
Author: @rasatpetabit
Created: 10/9/2026
Status: ✅ Merged
Merged: 10/10/2026
Merged by: @morluto

Base: main ← Head: feat/pi-client-support

📝 Commits (5)

cc1f35b feat(setup): add native Pi client support
baeadd5 fix(setup): isolate invalid Pi agent directory overrides
c0713c8 fix(setup): parse Pi configuration as strict JSON
d335cff Merge remote-tracking branch 'origin/main' into codex/fix-pi-review
43c526f merge: resolve Pi client conflicts with Hermes support

📊 Changes

11 files changed (+763 additions, -12 deletions)

View changed files

📝 docs/installation.md (+28 -0)
📝 src/application/ClientConfigurationDocument.ts (+5 -0)
📝 src/application/ClientRegistrationStatus.ts (+13 -3)
📝 src/application/SetupClientConfiguration.ts (+5 -0)
📝 src/application/SetupHost.ts (+1 -0)
📝 src/application/SupportedClients.ts (+71 -8)
📝 src/application/Uninstall.ts (+2 -0)
➕ tests/boundary/cli/piClientSetup.test.ts (+301 -0)
📝 tests/boundary/filesystem/clientConfigurationDialects.test.ts (+3 -1)
📝 tests/boundary/filesystem/clientLifecycle.test.ts (+1 -0)
➕ tests/boundary/filesystem/piClientConfiguration.test.ts (+333 -0)

📄 Description

Summary

Add first-class native Pi support to REA's existing client setup, doctor, and uninstall flows.

Pi users can already run REA's stdio MCP server by hand, but REA has no pi client, so rea setup cannot discover or register Pi and rea doctor cannot diagnose a Pi registration. This adds --client pi as a distinct client. It is not an alias of OMP (oh-my-pi), which uses a different directory, profiles, and server allow/deny lists.

No Pi-specific issue or PR was found in this repository. This is a focused extension of the existing client-adapter system, alongside the separate OMP integration (#1301).

Problem and expected behavior

Pi reads user MCP registrations from ~/.pi/agent/mcp.json, or from the agent directory selected by PI_CODING_AGENT_DIR (MCP docs, agent-directory resolver). Reusing OMP's behavior would select the wrong file and misread Pi's enabled: false.

Expected behavior: a scoped, additive registration that preserves unrelated configuration, installs REA's bundled skill where Pi already discovers skills, and works with the existing dry-run/approval, doctor, and owned-only uninstall flows:

rea setup --client pi --dry-run --json
rea setup --client pi --yes --json
rea doctor --client pi --json

Change and scope

Add the client identifier / display name / dialect pi / Pi / pi.
Resolve the config path with Pi's agent-directory semantics: unset or empty selects the default; ~ expansion; absolute paths; file URLs; relative paths resolved against the working directory (never silently replaced by the default); Windows native, ~\, and Git Bash/MSYS, Cygwin, and WSL drive paths.
Parse existing Pi config files as strict JSON, matching Pi's loader (JSON.parse). Comments, trailing commas, a byte-order mark, and empty files are reported as invalid and never rewritten. A missing file is created as valid JSON. Other clients keep their existing JSONC/BOM/empty-file tolerance.
Write an ordinary stdio registration. Doctor accepts omitted or explicit stdio, reports other transports as invalid, and treats enabled: false as disabled.
Keep OMP profiles and enabledServers/disabledServers handling OMP-only.
Keep a malformed PI_CODING_AGENT_DIR from breaking other clients. Previously, an invalid value (for example file:///agent%2fdir) threw during client enumeration, so even rea setup --client codex failed. The error now stays on Pi's entry: scoped setup/doctor for other clients succeeds, and selecting Pi fails closed with remediation and no filesystem access to a fallback directory.
Reuse the existing bundled-skill installation to ~/.agents/skills, which Pi discovers.
Document user scope, strict JSON, trusted-project .pi/mcp.json overrides, /mcp replacement extensions, and /reload.

Not included: project-scope setup, installing Pi or analysis providers, provider/native-analysis changes, or MCP tool changes. Generated catalogs and skills/ are not committed.

Contract and boundary impact

Semantic owner and earliest changed stage: supported-client registry and client configuration-path resolution (SupportedClients.ts), then configuration parsing (ClientConfigurationDocument.ts).
CLI and MCP/tool-catalog contract: additive pi value for the existing --client option on setup, doctor, and uninstall; no MCP tool or result-schema change.
Provider, bridge, target-format, or platform compatibility: none for providers. Pi path resolution is platform-aware.
Evidence, artifact, provenance, or reconstruction contract: none.
Process execution, authorization, cleanup, or containment impact: uses the existing dry-run/approval, ownership, backup, readback, and uninstall machinery. A malformed Pi config or override fails closed without mutation.
Generated metadata (docs/public/product-catalog.json), package, or installation impact: supported-client metadata derives from the registry through existing generators; no build outputs committed.

Evidence and regression coverage

Tests added or updated:
- tests/boundary/filesystem/piClientConfiguration.test.ts (new): path resolution across override forms and platforms, OMP isolation, preservation, idempotency, owned-only uninstall, transport/enabled doctor states, and a strict-JSON matrix (comment, trailing comma, BOM-prefixed, empty, whitespace-only, BOM-only): parse rejected, setup fails before writing, doctor invalid, uninstall preserves bytes, no backup created. It also covers missing-file initialization and confirms another JSON client still accepts the same inputs.
- tests/boundary/cli/piClientSetup.test.ts (new): public CLI in an isolated temporary home covering plan → approval → apply → doctor → repeat → uninstall; malformed PI_CODING_AGENT_DIR with scoped Codex setup/doctor; missing-file creation; and malformed-file needs_human with no planned or applied actions.
- clientConfigurationDialects.test.ts, clientLifecycle.test.ts: Pi added to the shared dialect and lifecycle tables.
Base reproduction or other evidence: the new tests were written first and failed before each production change: missing pi client (38 failed), strict-JSON parsing (7 failed), and the malformed-override case through the real CLI.
Consumer check: a separate probe packed this branch, ran its packaged CLI in an isolated home, and then loaded the result with Pi v1.1.0's own modules (loadMcpConfig, McpServerConnection, the skill loader). It confirmed:
- Pi connected over stdio and discovered 139 tools.
- Pi automatically discovered the shared skill.
- A trusted-project enabled: false override was honored.
- Pi rejects the malformed files that REA now refuses.
- The missing-file path initializes a config Pi loads.
No Pi CLI, LLM, or interactive session was launched.

User-visible CLI/MCP output (trimmed, temporary home shown as ~):

// rea setup --client pi --dry-run --json  (existing mcp.json with an unrelated server)
{ "status": "planned",
  "plannedActions": [
    { "id": "configure_client:pi", "target": "~/.pi/agent/mcp.json", "operation": "update",
      "detail": "Add the REA MCP registration for Pi; preserve unrelated configuration. …",
      "backupPath": "~/.pi/agent/mcp.json.rea.backup" },
    { "id": "install_skill", "target": "~/.agents/skills/reverse-engineer-anything", … } ],
  "appliedActions": [] }

// rea setup --client pi --yes --json
{ "status": "ready", "appliedActions": ["configured_pi", "installed_skill"],
  "clients": { "pi": { "status": "configured", "backupPath": "~/.pi/agent/mcp.json.rea.backup" } } }

// rea doctor --client pi --json
{ "healthy": true,
  "scope_checks": [ …, { "name": "registration:pi", "ok": true, "detail": "~/.pi/agent/mcp.json" } ] }

// rea setup --client pi --dry-run --json  (mcp.json containing a // comment; exit 1)
{ "status": "needs_human", "plannedActions": [], "appliedActions": [],
  "remediation": "Pi: The existing configuration is malformed. Repair it before setup applies any other changes." }

Remaining proof gaps: Windows path handling is covered by unit tests on Linux, not a native Windows Pi run. The Pi check exercises Pi's real loaders, not a full interactive session. Non-default PI_CODING_AGENT_DIR forms are tested against Pi's resolver semantics, not through the live loader.

For evidence-bearing changes:

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

On c0713c8 rebased onto main at a9f5dad, with Node.js 24.18.0 / npm 11.16.0 (the repository pins):

npm run test:focused -- with the 10 client/configuration test files (Pi, OMP, dialects, lifecycle, Pi CLI, registration status, setup skill, transactions, BOM, update maintenance) — passed, 184 tests
npm run verify:test-discovery — passed, 698 files discovered exactly once
npm run check — passed, including verify:architecture-guards; only existing lint warnings remain
npm run docs:check — passed
npm run verify:package — passed
npm pack --dry-run — passed, 1,052 files
Packaged REA → Pi v1.1.0 loader probe described above — passed
npm test — 6,098 passed, 8 failed, 89 skipped. All 8 failures are in firmware tests this PR does not touch, and they also fail on unmodified main on this host:
- firmwareIntegration.test.ts (7 cases) and firmwareMcp.test.ts (1 case) fail with Unsupported tool version 26.6.4; accepted releases are Binwalk 3.1.x.
- On this Ubuntu 26.04 host, realpath('/usr/bin/true') is /usr/bin/gnutrue. The firmware test fixture detects its fake engine by a /true path suffix, so it misidentifies the engine and reports the wrong version. It is a fixture/host interaction, not a Binwalk installation issue; I can file it separately if useful.
An earlier full run, before rebasing onto current main, also had three timing failures in unchanged process tests (localToolContracts.test.ts, processCaptureNormalization.test.ts). Those passed in this run and when run alone.

Compatibility, safety, and release

Breaking changes or migration steps: none. Existing clients are unchanged, including their parsing tolerance. Running Pi sessions need /reload to pick up a new registration.
Real Hopper/Ghidra, browser, or OS coverage: Linux only, using Pi's real config/skill/MCP loaders. No provider behavior changed, so no Hopper/Ghidra/IDA run. Windows paths are covered by unit tests only.
Package or release metadata impact: additive supported-client metadata through existing generators; no version bump.
Security, privacy, process, or containment review: the focus is selecting the right destination file, isolating other clients from a malformed Pi override, preserving unrelated configuration, and failing closed on malformed or disabled registrations. No credentials are stored and nothing new is executed.

Review checklist

This PR addresses a concrete problem or an agreed enhancement.
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.
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.

Maintainer validation after updating main

Updated the contributor branch to current main with merge commit d335cff69, resolving the path-import conflict with the merged Qwen home fix without rewriting contributor commits. Review found no additional Pi-specific behavior correction needed beyond that integration conflict.

On macOS with Node 24.18.0 / npm 11.16.0, 102 tests passed across Pi filesystem configuration, Pi public CLI setup, shared client lifecycle, and Qwen path coverage. npm run check, npm run docs:check, npm run verify:package, and npm pack --dry-run passed. The package verifier discovered 139 MCP tools and verified the bundled skill and Skills 1.7.2 repository discovery. This maintainer pass did not repeat the contributor's native Pi loader probe or run a Windows/interactive Pi session.

_{🔄 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/1376 **Author:** [@rasatpetabit](https://github.com/rasatpetabit) **Created:** 10/9/2026 **Status:** ✅ Merged **Merged:** 10/10/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `feat/pi-client-support` --- ### 📝 Commits (5) - [`cc1f35b`](https://github.com/morluto/rea/commit/cc1f35baa16f253962a4f6f4571a18e2675720b9) feat(setup): add native Pi client support - [`baeadd5`](https://github.com/morluto/rea/commit/baeadd5ce77afafb506c16d45f2090625b040999) fix(setup): isolate invalid Pi agent directory overrides - [`c0713c8`](https://github.com/morluto/rea/commit/c0713c8f36dff4121c5e0f796aca64c34f391d74) fix(setup): parse Pi configuration as strict JSON - [`d335cff`](https://github.com/morluto/rea/commit/d335cff69dc5509ba337364893bc6c332ce97033) Merge remote-tracking branch 'origin/main' into codex/fix-pi-review - [`43c526f`](https://github.com/morluto/rea/commit/43c526f03f0760e99779ba7942a2f89f5ecdb19a) merge: resolve Pi client conflicts with Hermes support ### 📊 Changes **11 files changed** (+763 additions, -12 deletions) <details> <summary>View changed files</summary> 📝 `docs/installation.md` (+28 -0) 📝 `src/application/ClientConfigurationDocument.ts` (+5 -0) 📝 `src/application/ClientRegistrationStatus.ts` (+13 -3) 📝 `src/application/SetupClientConfiguration.ts` (+5 -0) 📝 `src/application/SetupHost.ts` (+1 -0) 📝 `src/application/SupportedClients.ts` (+71 -8) 📝 `src/application/Uninstall.ts` (+2 -0) ➕ `tests/boundary/cli/piClientSetup.test.ts` (+301 -0) 📝 `tests/boundary/filesystem/clientConfigurationDialects.test.ts` (+3 -1) 📝 `tests/boundary/filesystem/clientLifecycle.test.ts` (+1 -0) ➕ `tests/boundary/filesystem/piClientConfiguration.test.ts` (+333 -0) </details> ### 📄 Description ## Summary Add first-class native [Pi](https://github.com/earendil-works/pi) support to REA's existing client setup, doctor, and uninstall flows. Pi users can already run REA's stdio MCP server by hand, but REA has no `pi` client, so `rea setup` cannot discover or register Pi and `rea doctor` cannot diagnose a Pi registration. This adds `--client pi` as a distinct client. It is not an alias of OMP (oh-my-pi), which uses a different directory, profiles, and server allow/deny lists. No Pi-specific issue or PR was found in this repository. This is a focused extension of the existing client-adapter system, alongside the separate OMP integration (#1301). ## Problem and expected behavior Pi reads user MCP registrations from `~/.pi/agent/mcp.json`, or from the agent directory selected by `PI_CODING_AGENT_DIR` ([MCP docs](https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/mcp.md), [agent-directory resolver](https://github.com/earendil-works/pi/blob/main/packages/coding-agent/src/config.ts)). Reusing OMP's behavior would select the wrong file and misread Pi's `enabled: false`. Expected behavior: a scoped, additive registration that preserves unrelated configuration, installs REA's bundled skill where Pi already discovers skills, and works with the existing dry-run/approval, doctor, and owned-only uninstall flows: ```sh rea setup --client pi --dry-run --json rea setup --client pi --yes --json rea doctor --client pi --json ``` ## Change and scope - Add the client identifier / display name / dialect `pi` / `Pi` / `pi`. - Resolve the config path with Pi's agent-directory semantics: unset or empty selects the default; `~` expansion; absolute paths; file URLs; relative paths resolved against the working directory (never silently replaced by the default); Windows native, `~\`, and Git Bash/MSYS, Cygwin, and WSL drive paths. - Parse existing Pi config files as strict JSON, matching Pi's loader (`JSON.parse`). Comments, trailing commas, a byte-order mark, and empty files are reported as invalid and never rewritten. A missing file is created as valid JSON. Other clients keep their existing JSONC/BOM/empty-file tolerance. - Write an ordinary stdio registration. Doctor accepts omitted or explicit `stdio`, reports other transports as invalid, and treats `enabled: false` as disabled. - Keep OMP profiles and `enabledServers`/`disabledServers` handling OMP-only. - Keep a malformed `PI_CODING_AGENT_DIR` from breaking other clients. Previously, an invalid value (for example `file:///agent%2fdir`) threw during client enumeration, so even `rea setup --client codex` failed. The error now stays on Pi's entry: scoped setup/doctor for other clients succeeds, and selecting Pi fails closed with remediation and no filesystem access to a fallback directory. - Reuse the existing bundled-skill installation to `~/.agents/skills`, which Pi discovers. - Document user scope, strict JSON, trusted-project `.pi/mcp.json` overrides, `/mcp` replacement extensions, and `/reload`. Not included: project-scope setup, installing Pi or analysis providers, provider/native-analysis changes, or MCP tool changes. Generated catalogs and `skills/` are not committed. ## Contract and boundary impact - Semantic owner and earliest changed stage: supported-client registry and client configuration-path resolution (`SupportedClients.ts`), then configuration parsing (`ClientConfigurationDocument.ts`). - CLI and MCP/tool-catalog contract: additive `pi` value for the existing `--client` option on setup, doctor, and uninstall; no MCP tool or result-schema change. - Provider, bridge, target-format, or platform compatibility: none for providers. Pi path resolution is platform-aware. - Evidence, artifact, provenance, or reconstruction contract: none. - Process execution, authorization, cleanup, or containment impact: uses the existing dry-run/approval, ownership, backup, readback, and uninstall machinery. A malformed Pi config or override fails closed without mutation. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: supported-client metadata derives from the registry through existing generators; no build outputs committed. ## Evidence and regression coverage - Tests added or updated: - `tests/boundary/filesystem/piClientConfiguration.test.ts` (new): path resolution across override forms and platforms, OMP isolation, preservation, idempotency, owned-only uninstall, transport/`enabled` doctor states, and a strict-JSON matrix (comment, trailing comma, BOM-prefixed, empty, whitespace-only, BOM-only): parse rejected, setup fails before writing, doctor `invalid`, uninstall preserves bytes, no backup created. It also covers missing-file initialization and confirms another JSON client still accepts the same inputs. - `tests/boundary/cli/piClientSetup.test.ts` (new): public CLI in an isolated temporary home covering plan → approval → apply → doctor → repeat → uninstall; malformed `PI_CODING_AGENT_DIR` with scoped Codex setup/doctor; missing-file creation; and malformed-file `needs_human` with no planned or applied actions. - `clientConfigurationDialects.test.ts`, `clientLifecycle.test.ts`: Pi added to the shared dialect and lifecycle tables. - Base reproduction or other evidence: the new tests were written first and failed before each production change: missing `pi` client (38 failed), strict-JSON parsing (7 failed), and the malformed-override case through the real CLI. - Consumer check: a separate probe packed this branch, ran its packaged CLI in an isolated home, and then loaded the result with Pi v1.1.0's own modules (`loadMcpConfig`, `McpServerConnection`, the skill loader). It confirmed: - Pi connected over stdio and discovered 139 tools. - Pi automatically discovered the shared skill. - A trusted-project `enabled: false` override was honored. - Pi rejects the malformed files that REA now refuses. - The missing-file path initializes a config Pi loads. No Pi CLI, LLM, or interactive session was launched. - User-visible CLI/MCP output (trimmed, temporary home shown as `~`): ```jsonc // rea setup --client pi --dry-run --json (existing mcp.json with an unrelated server) { "status": "planned", "plannedActions": [ { "id": "configure_client:pi", "target": "~/.pi/agent/mcp.json", "operation": "update", "detail": "Add the REA MCP registration for Pi; preserve unrelated configuration. …", "backupPath": "~/.pi/agent/mcp.json.rea.backup" }, { "id": "install_skill", "target": "~/.agents/skills/reverse-engineer-anything", … } ], "appliedActions": [] } // rea setup --client pi --yes --json { "status": "ready", "appliedActions": ["configured_pi", "installed_skill"], "clients": { "pi": { "status": "configured", "backupPath": "~/.pi/agent/mcp.json.rea.backup" } } } // rea doctor --client pi --json { "healthy": true, "scope_checks": [ …, { "name": "registration:pi", "ok": true, "detail": "~/.pi/agent/mcp.json" } ] } // rea setup --client pi --dry-run --json (mcp.json containing a // comment; exit 1) { "status": "needs_human", "plannedActions": [], "appliedActions": [], "remediation": "Pi: The existing configuration is malformed. Repair it before setup applies any other changes." } ``` - Remaining proof gaps: Windows path handling is covered by unit tests on Linux, not a native Windows Pi run. The Pi check exercises Pi's real loaders, not a full interactive session. Non-default `PI_CODING_AGENT_DIR` forms are tested against Pi's resolver semantics, not through the live loader. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed On `c0713c8` rebased onto `main` at `a9f5dad`, with Node.js 24.18.0 / npm 11.16.0 (the repository pins): - `npm run test:focused --` with the 10 client/configuration test files (Pi, OMP, dialects, lifecycle, Pi CLI, registration status, setup skill, transactions, BOM, update maintenance) — passed, 184 tests - `npm run verify:test-discovery` — passed, 698 files discovered exactly once - `npm run check` — passed, including `verify:architecture-guards`; only existing lint warnings remain - `npm run docs:check` — passed - `npm run verify:package` — passed - `npm pack --dry-run` — passed, 1,052 files - Packaged REA → Pi v1.1.0 loader probe described above — passed - `npm test` — **6,098 passed, 8 failed, 89 skipped.** All 8 failures are in firmware tests this PR does not touch, and they also fail on unmodified `main` on this host: - `firmwareIntegration.test.ts` (7 cases) and `firmwareMcp.test.ts` (1 case) fail with `Unsupported tool version 26.6.4; accepted releases are Binwalk 3.1.x`. - On this Ubuntu 26.04 host, `realpath('/usr/bin/true')` is `/usr/bin/gnutrue`. The firmware test fixture detects its fake engine by a `/true` path suffix, so it misidentifies the engine and reports the wrong version. It is a fixture/host interaction, not a Binwalk installation issue; I can file it separately if useful. An earlier full run, before rebasing onto current `main`, also had three timing failures in unchanged process tests (`localToolContracts.test.ts`, `processCaptureNormalization.test.ts`). Those passed in this run and when run alone. ## Compatibility, safety, and release - Breaking changes or migration steps: none. Existing clients are unchanged, including their parsing tolerance. Running Pi sessions need `/reload` to pick up a new registration. - Real Hopper/Ghidra, browser, or OS coverage: Linux only, using Pi's real config/skill/MCP loaders. No provider behavior changed, so no Hopper/Ghidra/IDA run. Windows paths are covered by unit tests only. - Package or release metadata impact: additive supported-client metadata through existing generators; no version bump. - Security, privacy, process, or containment review: the focus is selecting the right destination file, isolating other clients from a malformed Pi override, preserving unrelated configuration, and failing closed on malformed or disabled registrations. No credentials are stored and nothing new is executed. ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [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. - [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. ## Maintainer validation after updating main Updated the contributor branch to current main with merge commit `d335cff69`, resolving the path-import conflict with the merged Qwen home fix without rewriting contributor commits. Review found no additional Pi-specific behavior correction needed beyond that integration conflict. On macOS with Node 24.18.0 / npm 11.16.0, 102 tests passed across Pi filesystem configuration, Pi public CLI setup, shared client lifecycle, and Qwen path coverage. `npm run check`, `npm run docs:check`, `npm run verify:package`, and `npm pack --dry-run` passed. The package verifier discovered 139 MCP tools and verified the bundled skill and Skills 1.7.2 repository discovery. This maintainer pass did not repeat the contributor's native Pi loader probe or run a Windows/interactive Pi session. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-17 21:10:51 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-10-31 01:06:33 +00:00

[PR #2838] [MERGED] fix(apple): exclude AppleDouble sidecars from IPA components #5427

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

No description provided.

Rows
Columns