The guided installer asks how ECC hooks should run, but that consent
lived only in the wizard path. Running install-apply directly with a
profile that includes hooks-runtime still materialized the hook runtime
with no disclosure and no decision.
Gate the apply layer instead, so every entry point is covered:
- disclose the six hook capability groups when a plan would materialize
the hook runtime, and refuse to apply until the caller decides
- --enable-hooks confirms the hook runtime; --no-hooks installs the rest
of the selection without it and records the reduced module closure in
install-state
- surface the pending decision as a dry-run warning
- show the same capability disclosure in the guided installer's plan
preview, so the wizard's hook question states what it is asking about
Plans that never materialize hooks (Kimi, --profile minimal,
--without baseline:hooks) are unaffected and need no flag. Repair and
uninstall operate on already-recorded state and stay unchanged.
The capability taxonomy and the held-materialization behavior come from
Samarjeet Singh Tomar's PR #2634, reworked to fit the single-decision
consent model that shipped with the guided installer in #2649.
Co-Authored-By: Samarjeet Singh Tomar <samar_tomar@hotmail.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Following the hermes/openclaw (#2433) and kimi (#2441) adapter recipe.
What's included (adal-project adapter, project kind, ./.adal root, same
shape as kimi-project/joycode-project):
- scripts/lib/install-targets/adal-project.js — 10-line project-kind
adapter targeting ./.adal
- Registry + helpers platform-ownership wiring
- adal target on the 5 shared modules (rules-core, agents-core,
commands-core, platform-configs, workflow-quality) +
SUPPORTED_INSTALL_TARGETS + legacy-compat module
- .adal in platform-configs paths
- Both schema enums (install-modules, ecc-install-config), npm files
allowlist, installer help text, .adal/README.md stub
AdaL (adalagent.ai) is a terminal-based AI coding agent (by SylphAI)
built on AdalFlow, with native MCP support and project-scoped config
under ./.adal/ (skills, custom tools, memory) plus a root-level
AGENTS.md instructions file — matching the shape ECC already installs
into other AGENTS.md-based harnesses (Codex, OpenCode, Kimi).
Verified: full suite matches main's baseline (3334 passed, same
pre-existing failures unrelated to this change — OpenCode build/npm-pack
surface tests requiring build tooling not present in this sandbox);
catalog check passes (67 agents / 94 commands / 281 skills); dry-run
resolves Target: adal / Adapter: adal-project / root ./.adal with all 5
modules planned; doctor reports OK after a real install; uninstall
cleanly reverses all 458 operations.
Co-Authored-By: AdaL <adal@sylph.ai>
Add a local-first, cross-harness memory vault with CLI and MCP surfaces, bounded search and storage, harness-scoped visibility, setup guidance, and comprehensive tests.
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/)
The Claude Code plugin validator rejects the "agents" field entirely.
Remove it from the manifest, schema, and tests. Update schema notes
to document this as a known constraint alongside the hooks field.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat: add SQLite state store and ECC status CLI
* fix: replace better-sqlite3 with sql.js to eliminate native module CI failures
better-sqlite3 requires native C++ compilation (node-gyp, prebuild-install)
which fails in CI across npm/pnpm on all platforms:
- npm ci: lock file out of sync with native transitive deps
- pnpm: native bindings not found at runtime
- Windows: native compilation fails entirely
sql.js is a pure JavaScript/WASM SQLite implementation with zero native
dependencies. The adapter in index.js wraps the sql.js API to match the
better-sqlite3 interface used by migrations.js and queries.js.
Key implementation detail: sql.js db.export() implicitly ends active
transactions, so the adapter defers disk writes (saveToDisk) until
after transaction commit via an inTransaction guard flag.
createStateStore is now async (sql.js requires async WASM init).
Updated status.js, sessions-cli.js, and tests accordingly.
- hooks.schema.json: add async (boolean) and timeout (number) properties
to hookItem definition, matching fields used in hooks.json
- validate-hooks.js: validate async and timeout types when present
- hooks.test.js: add SessionEnd to required event types check
- Wrap JSON.parse in try-catch for all 6 inline hooks in hooks.json
(dev-server blocker, tmux reminder, git-push reminder, doc blocker,
PR create logger, build analysis) — previously unguarded JSON.parse
would crash on empty/malformed stdin, preventing data passthrough
- Add config parse error logging to evaluate-session.js
- Fix plugin.schema.json: author can be string or {name,url} object,
add version (semver pattern), homepage, keywords, skills, agents
- Fix package-manager.schema.json: add setAt (date-time) field and
make packageManager required to match actual code behavior
