fix(memos-local-plugin): use POSIX-ERE-compatible pgrep pattern for hermes chat detection

[kiwipaulrob]

Summary

Fixes the Hermes chat process detection regex in the memos-local-plugin. The pattern introduced to fix #1915 used (?:\s+\S+)* — a PCRE non-capturing group — but pgrep -f on Linux compiles patterns with glibc's POSIX ERE, which has no non-capturing groups. Every call failed with:

pgrep: regex error: Invalid preceding regular expression

isHermesChatRunning() swallows the error and returns false, so the daemon-mode bridge viewer was permanently stuck on "disconnected" even when a hermes chat session was attached — exactly the symptom #1915 set out to fix.

Root cause

The unit test for the pattern passes matchesHermesChatCommandLine() through JavaScript's RegExp, which does support (?:…). The comment claimed this was a "faithful proxy" for the pgrep side — but the two engines are not equivalent for non-capturing groups. The proxy was faithful for matching behaviour, not for pattern validity.

Fix

• Replace the non-capturing group with a plain capturing group (\s+\S+)*, which is valid in both POSIX ERE and JavaScript's RegExp and behaves identically for matching.
• Update the doc comment to warn that the pattern must stay within POSIX ERE (no (?:…)), so the constraint is visible at the constant's definition.
• Add a regression test that runs the real pgrep binary with the pattern and asserts it does not exit 2 (regex syntax error), so a PCRE-ism can never silently return again. Verified: the old pattern exits 2 with this test; the fixed pattern passes.

Verification

• vitest run tests/unit/bridge/hermes-process.test.ts — 15/15 tests pass (all existing match cases unchanged, plus the new pgrep regression test).
• Live reproduction on a Linux host: old pattern → pgrep exit 2 + Invalid preceding regular expression; fixed pattern → exit 0/1, no error, and the bridge status upgrades to "connected".

Notes

• dist/ is gitignored, so only the TS source and its test are touched.
• Happy to retarget to a release branch (dev-v2.0.x) if that's preferred for this fix.

[Memtensor-AI]

🤖 Open Code Review

Target: PR #2192
Task: f9818ff9cb0325b2
Base: main
Head: fix/pgrep-ere-regex

✅ OpenCodeReview: No comments generated. Looks good to me.

Generated by cloud-assistant via Open Code Review.

[Memtensor-AI]

⚠️ Automated Test Results: ENV ISSUE

The test environment encountered an issue that requires manual attention.

Details: Environment preparation failed before any gating tests executed. Failed scopes: memos_local_plugin
Branch: fix/pgrep-ere-regex

[kiwipaulrob]

Thanks for running the checks. A quick note on the AutoTest result:

This failure is an environment-preparation issue, not a test failure. The report states "Environment preparation failed before any gating tests executed" — the runner never reached the memos_local_plugin test suite, so there is no test result from this run to act on.

For reference, here's what does validate this change:

• open-code-review: no findings (context open-code-review, success)
• CI sync check: passed
• Unit tests: 15/15 pass locally (vitest run tests/unit/bridge/hermes-process.test.ts), including the new regression test that runs the real pgrep binary
• Independent verification of the core claim: on a Linux host, the old pattern hermes(?:\s+\S+)*\s+chat\b makes pgrep -f exit 2 with regex error: Invalid preceding regular expression; the new pattern hermes(\s+\S+)*\s+chat\b exits 0/1 with no error. The fixed pattern also matches a live hermes process command line.

Could the AutoTest environment be re-run when convenient (or is there a known issue with environment prep for the memos_local_plugin scope)? Happy to help debug the env setup if logs are available.