Resolve the registrationActivation conflict by combining upstream's
dialect-based ZCode check with shared-registration coverage, and defer
shared-registration maintenance to an applicable client covering the
same file so one shared row is refreshed once.
Resolve native-versus-fallback precedence once at the parsed configuration owner. Status and maintenance consume the selected dialect and path, including invalid and disabled fallback registrations.
Validation: 28 ZCode boundary and 26 maintenance tests pass. No configuration writes introduced.
Based on #3123.
Co-authored-by: IvenKooLab <276572622@qq.com>
Uninstall.ts declared systemUninstallHost twice, preventing module load,
with the exported copy returning only clients and the second copy missing
clientWriteBlocker. Merge into one exported host carrying both blockers.
hasOwnershipEvidence used access() existence, so an unrelated malformed
~/.agents/mcp.json established ownership and blocked every removal.
Ownership now requires a readable, recognizable REA-owned row via the
injected filesystem, so unrelated shared data stays retained.
Also cover ZCode discoveryPaths in its path test.
* feat(clients): register ZCode during setup
- SupportedClients: zcode definition (~/.zcode/cli/config.json, format
zcode, personal skills at ~/.zcode/skills)
- ClientConfigurationDocument: zcode dialect reads/writes the nested
mcp.servers table; withClientServers now tolerates a missing outer
table for fresh documents
- docs: add ZCode to the supported-clients table with configuration notes
- tests: zcodeClientConfiguration.test.ts (path resolution, nested
upsert, fresh/empty configs, uninstall)
Verified: tsc --noEmit clean; vitest run
tests/boundary/filesystem/zcodeClientConfiguration.test.ts 6/6.
* fix(clients): preserve ZCode fallback servers and honor enable flag
Review follow-up (#1564), two integration gaps:
- ZCode reads the user-scope ~/.agents/mcp.json fallback only while the
native .zcode config defines no servers at all, with no merging. Setup
now copies the fallback's mcpServers entries into the native table when
writing the first native server, so registrations that only live in
the fallback keep loading; the fallback file is left untouched. A
malformed fallback fails setup closed (configure and preflight)
instead of being silently suppressed.
- ZCode disables a server with "enable": false on its entry, which the
generic status parsing (disabled/enabled) did not recognize: doctor
reported such a registration as aligned although ZCode never starts
it. The ZCode dialect now treats enable: false as disabled (state
stale) and setup rewrites the entry on rerun.
Docs describe both behaviors; the bundled REA skill's supported client
list includes zcode.
Verified: tsc --noEmit clean; vitest run
tests/boundary/filesystem/zcodeClientConfiguration.test.ts 10/10;
npm run check:fast green; npm run verify:test-discovery 733 files.
* fix(clients): reject non-regular ZCode fallback files before reading
Resolve the fallback through the client-config transaction path and the
regular-file admission before parsing it, so a FIFO or other non-regular
file at ~/.agents/mcp.json fails setup closed instead of blocking the
read indefinitely. Directory and FIFO fallback cases are covered in
tests, and the preflight remediation names unreadable fallbacks too.
---------
Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
0xLLVEL