[mfrna]

Add ZCode as a STABLE, detected client surface with a three-layer integration: MCP server registration in the nested mcp.servers object, durable instructions, and the codebase-memory skill.

Schema (agent_clients.h):
New CBM_AGENT_CLIENT_ZCODE enum value, positioned before COUNT.

Profile (agent_clients.c):

• stability: CBM_AGENT_STABLE (auto-detected, auto-installed)
• capabilities: MCP | INSTRUCTIONS | SKILL. No HOOK: config-file hooks require a global hooks.enabled opt-in that the installer must not flip on the user's behalf, and no documented context-output consumption contract exists. No AGENT: subagents are plugin/UI-managed with no documented user-scope config-file custom-agent directory; the surface is not approximated (same fail-closed treatment as Cursor).
• detection: ~/.zcode marker, the resolved config file, or the zcode command
• resolve_path: ~/.zcode/cli/config.json (documented user config; the same-scope .agents/mcp.json fallback is read-only and never written)
• json section: mcp.servers — the registry's first two-level section path. agent_json_section() becomes agent_json_section_path() returning (path, depth), agent_json_find_entry() walks nested sections, and the ownership-preserving editor already supported multi-level object paths.
• canonical entry: explicit "type": "stdio" because ZCode's strict schema silently drops servers carrying unknown keys

Install/uninstall (cli.c):

• install_zcode_durable_context: managed block in ~/.zcode/AGENTS.md plus skill at ~/.zcode/skills/codebase-memory/SKILL.md
• uninstall_zcode_durable_context removes both
• Wired into install_agent_client_registry and uninstall_agent_client_registry

Contracts (main.c, README.md, pkg/npm/README.md, docs/llms.txt, docs/index.html): 45 -> 46 surfaces, 39 -> 40 detected; ZCode added to the matrix, help list, and landing-page lists.

Test coverage:

• test_agent_clients.c: zcode in stable_ids (20 entries) and the capabilities array, the documented resolve path, ~/.zcode marker detection, a json_schemas case, nested foreign-entry preservation, and a dedicated lifecycle test (fresh nested-path creation, idempotent reinstall, sibling-server preservation on install and removal, canonical-only removal, foreign rejection byte-identically)
• test_cli.c: required_agents updated to 46; all 45/39 doc contracts updated

Verified: scripts/build.sh passes; scripts/test.sh --suites agent_clients (39 passed) and --suites cli (353 passed); scripts/security-audit.sh passes; end-to-end install/uninstall round-trip checked in an isolated HOME (sibling MCP servers preserved both ways). The full lint leg could not run locally (clang-tidy, cppcheck, clang-format not installed on this machine); the change compiles clean under -Wall -Wextra -Werror and adds no system()/popen()/fork()/network calls.

Written with the ZCode AI coding agent on behalf of Mohamed Nasr.

What does this PR do?

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

Closes #2565

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.