Rebuild of #2154 on current main, following the hermes/openclaw (#2433)
adapter recipe: 10-line kimi-project adapter (project kind, ./.kimi root),
registry + helpers ownership, SUPPORTED_INSTALL_TARGETS + legacy-compat
modules, kimi target on the 5 shared modules + .kimi in platform-configs
paths, both schema enums, npm files allowlist, help text, README stub.
Credit to @MoYiC6 for the original adapter design in #2154.
* feat: add Hermes and OpenClaw harness install targets
- Add scripts/lib/install-targets/hermes-home.js and openclaw-home.js
- Register new adapters in registry.js and helpers.js
- Add hermes/openclaw to SUPPORTED_INSTALL_TARGETS, schema enum, and install help text
- Add .hermes/ and .openclaw/ platform source directories with READMEs
- Update install-modules.json so rules/agents/commands/platform-configs cover the new targets
Verification:
- npx ecc doctor reports all 13 targets OK (including hermes-home and openclaw-home)
- install-targets regression guard passes for new targets
- Catalog check passes
* fix(install): register hermes/openclaw in install-modules schema enum + npm files allowlist
---------
Co-authored-by: Lxcardoza993 <265670745+Lxcardoza993@users.noreply.github.com>
Co-authored-by: Affaan Mustafa <me@affaanmustafa.com>
Completes the install-target matrix for Claude Code. Until now, ECC's
Claude support was home-scope only (~/.claude/) via the `claude` target.
This adds a project-scope counterpart (./.claude/) via a new
`claude-project` target so teams can install ECC per-repo without
contaminating ~/.claude/ — matching the existing project-scope adapters
for Cursor, Antigravity, Gemini, CodeBuddy, Joycode, and Zed.
Symmetric with `claude`:
- Same namespace under rules/ecc and skills/ecc
- Same docs/<locale> handling for --locale
- Same hooks placeholder substitution for hooks.json
- Reuses claude-home's destination-mapping logic 1:1
Use cases:
- Monorepos with multiple Flow-managed projects
- Teams that want ECC scoped per-project without touching ~/.claude/
- Per-project skill/rule isolation when global install isn't desirable
No breaking change: existing --target claude continues to route to
claude-home (user-scope) unchanged. New target is opt-in.
Tests
-----
- 4 new tests in tests/lib/install-targets.test.js
(root resolution, lookup-by-id, plan parity with claude, foreign-path filtering)
- All install-target regression guards (schema enum / SUPPORTED_INSTALL_TARGETS)
still pass
- End-to-end smoke: `--target claude-project --profile minimal --dry-run`
emits 359 ops with destinations rooted at <projectRoot>/.claude/ (parity
with --target claude which emits 359 ops rooted at ~/.claude/)
Adds `--locale <code>` support to the ECC installer so users can install
localized reference docs (agents, commands, skills, rules) into
`~/.claude/docs/<locale>/` alongside the existing English installation.
Changes:
- manifests/install-modules.json: add 8 locale doc modules (docs-ja-JP,
docs-zh-CN, docs-ko-KR, docs-pt-BR, docs-ru, docs-tr, docs-vi-VN,
docs-zh-TW), each with kind="docs" and defaultInstall=false
- manifests/install-components.json: add 8 locale: components mapping to
the new modules
- scripts/lib/install-manifests.js: add locale: family prefix,
SUPPORTED_LOCALES, LOCALE_ALIAS_TO_COMPONENT_ID (with aliases like
ja=ja-JP, zh=zh-CN, ko=ko-KR), and listSupportedLocales()
- scripts/lib/install/request.js: add --locale flag to parseInstallArgs(),
resolve locale alias → component ID in normalizeInstallRequest(), throw
on unsupported locale codes
- scripts/lib/install-targets/claude-home.js: map docs/<locale>/ source
paths to ~/.claude/docs/<locale>/ destination (side-by-side, no overwrite
of English files)
- scripts/install-apply.js: import listSupportedLocales, add --locale
usage line and available locales list to --help output
Usage examples:
./install.sh --locale ja # Japanese docs only
./install.sh --profile core --locale zh-CN # core profile + zh-CN docs
./install.sh typescript --locale ja # legacy + locale (errors)
Extracted help text into getHelpText() and write both the error message
and usage help to stderr via process.stderr.write(). This ensures that
when output is redirected (e.g. 2>errors.txt), both the error and the
guidance appear in the same stream.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Running install.ps1/install.sh with no arguments gave a cryptic error
with no guidance. Now the usage help is printed after the error so users
know what arguments to pass.
Also added --profile full as the recommended install option in the README
quick-start section, which was previously undocumented.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
On Windows (native cmd/PowerShell), process.env.HOME is undefined.
Seven CLI entry points and two library files pass process.env.HOME
directly as homeDir without a cross-platform fallback, causing all
path resolutions to silently fail (resolving to "undefined/.claude/...").
Node.js os.homedir() correctly handles all platforms (HOME on Unix,
USERPROFILE on Windows, OS-level fallback). The project already uses
this pattern in scripts/lib/state-store/index.js and has a getHomeDir()
utility in scripts/lib/utils.js, but it was not applied consistently.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Lidang-Jiang <lidangjiang@gmail.com>
