@ainova-systems/intelligence 0.11.0-rc.4 → 0.11.0-rc.6

package/engine/docs/ADAPTERS.md

@@ -110,7 +110,8 @@ The engine ships artifacts of its own — the `intelligence-authoring` rule and
 | Token | Expands to |
 |---|---|
 | `<umbrella>` | repo-relative umbrella dir (e.g. `Intelligence`) |
-| `<module>` | repo-relative engine module (e.g. `Intelligence/sync`; CLI setup: `.intelligence/engine`) |
+| `<module>` | repo-relative engine module (e.g. `Intelligence/sync`; CLI setup: `.intelligence/packages/@ainova-systems/sync`) |
+| `<manifest>` | the project's config file name — vendored: `config.yaml`, CLI setup: `intelligence.yaml` (`IS_MANIFEST_NAME`) |
 | `<sync-cmd>` | the sync invocation — vendored: `bash <module>/scripts/sync.sh`, CLI setup: `intelligence sync` (`IS_SYNC_CMD`) |
 
 Values are exported by `sync.sh` (`IS_UMBRELLA_REL`, `IS_MODULE_REL`; `IS_SYNC_CMD` comes from the CLI in CLI mode), derived from the detected layout. Expansion covers frontmatter and body, so `paths: ["<umbrella>/**"]` reaches Claude's `paths:`, Cursor's `globs:` and Copilot's `applyTo:` carrying the project's real folder name. A file written without `finalize_output_file` ships a literal `<umbrella>` into an IDE — CI fails the build if any generated output still contains a token.

package/engine/docs/CLI.md

@@ -16,37 +16,35 @@ project/
 ├── intelligence.yaml      # manifest, at the repo root (like package.json)
 ├── intelligence.lock      # resolved package state — commit it
 ├── intelligence/          # the project's own rules/ agents/ skills/
-├── .intelligence/         # gitignored store: packages/<name>/, engine/, backup/
+├── .intelligence/         # gitignored store: packages/<name>/, backup/
 ├── .claude/ .cursor/ …    # generated by sync
 └── AGENTS.md
 ```
 
-No engine code lives in the project. The engine ships inside the npm package; its own rules, agents, meta-skills and docs are staged into `.intelligence/engine/` (re-staged whenever the bundled engine version changes) and reach the outputs as ordinary sources. After a fresh clone, `intelligence install` restores the whole store from the lock.
+No engine code lives in the project. The engine's *scripts* ship inside the npm package; the engine's *content* — the authoring rule, both engine agents, every `intelligence-*` meta-skill and the docs — is the package **`@ainova-systems/sync`**: auto-added by `init` (opt out with `--bare`), visible in `list`/`search`, pinned exactly to the bundled engine version, and materialized from the npm bundle without network whenever the pin matches (only a cross-version install reaches git). `intelligence update` never moves it — `intelligence upgrade` does, together with the schema stamp. Removing it (`remove @ainova-systems/sync --force`) drops the meta-content from the outputs while the sync engine itself keeps working. After a fresh clone, `intelligence install` restores the whole store from the lock.
 
 ## Commands
 
 | Command | Does |
 |---|---|
-| `init [--targets a,b] [--no-sync]` | Detect tools by their marker dirs, write a minimal root manifest, `.gitignore` the store, skeleton `intelligence/`, first sync. `agents` + `claude` are always on. |
+| `init [--targets a,b] [--dir d] [--bare] [--no-sync]` | Enable `agents` (the tool-neutral AGENTS.md) plus every tool DETECTED by repo markers (`.claude`/`CLAUDE.md`, `.cursor`, `.codex`, `.pi`, `.opencode`, `.github/instructions`) or named via `--targets` — a tool is never invented. Writes a minimal self-documenting root manifest, `.gitignore`s the store, installs `@ainova-systems/sync` (unless `--bare`), first sync. No dirs are created. |
 | `add <spec> [--name @s/n] [--no-sync]` | Resolve → fetch → wire sources → manifest entry → lock → sync. Specs: `@scope/name[@range]`, `github:org/repo[#path]`, `git+<url>[@ref][#path]`. |
-| `remove <name>` | Inverse of add: manifest, sources, lock, store. |
+| `remove <name> [--force]` | Inverse of add: manifest, sources, lock, store. |
 | `install [--frozen] [--force]` | Restore the store exactly from the lock; resolve manifest packages the lock lacks (`--frozen` refuses instead, and fails on sha drift). |
 | `update [name]` | Re-resolve ranges, refetch what moved, rewrite the lock. `ref:`-pinned packages never move here. |
-| `upgrade` | Bring the project to this CLI's engine: restage engine content, apply v2 schema migrations, restamp `sync_version`, sync. |
+| `upgrade` | Bring the project to this CLI's engine: apply v2 schema migrations, move the `@ainova-systems/sync` pin to the bundled version and reinstall it, restamp `sync_version`, sync. |
 | `sync [target]` | Run the bundled engine against the manifest. In a vendored (v1) project it delegates to that project's own engine. |
 | `list` / `status` / `doctor` | Inspect; doctor exits 1 on inconsistencies (unlocked packages, missing store, stale stamp, dead sources). |
-| `registry <list\|add @scope <url>\|remove @scope>` | Bind a scope to a registry repo — rare, once per organization. |
+| `registry <list\|add <url> [--force]\|remove <url>>` | Manage the trust list of registries — rare, once per organization. `add` fails closed on a URL with no `index.yaml` (`--force` records it anyway). |
 | `migrate [--dry-run] [--force]` | Convert a vendored setup to the CLI setup. Transactional; see below. |
 
 ## Packages
 
 **A package's name is its identity everywhere**: the `packages:` key in the manifest, the store directory (`.intelligence/packages/@scope/name/` — npm's nesting), and the lock key. What a package provides is a convention: whichever of `rules/`, `agents/`, `skills/` exist at its top level get wired into the matching `sources:` sections by `add`.
 
-**Name → repo resolution**, first hit wins:
+**Names are global.** The name is the trust anchor a developer reasons with — the same `@scope/name` means the same package in every project, every lock and every conversation. A registry never renames anything, and two versions of one name cannot coexist in a project: intelligence artifacts land in each tool's flat namespace (`.claude/skills/<name>/`, the `AGENTS.md` tables), so duplicates would collide file-by-file. Need pieces of two versions? That is a different package — fork it under a different name. Need to override one artifact? Put a same-named file in your own content dir; project sources are listed after package sources.
 
-1. `registries:` in the manifest — a scope bound to a *registry repo*: any git repo holding an `index.yaml`. Private registries are therefore just private repos; git auth covers access.
-2. The bundled default index (`registry/index.yaml`) — needed exactly when a name is not a repo (monorepos: `@ainova-systems/core` → `intelligence-dev-packs` at `packs/core`).
-3. Convention: `@org/name` → `https://github.com/org/name.git`, content at the repo root. Zero infrastructure: any repo with the three dirs is already a package.
+**Name → repo resolution: the trust list is the ONLY resolver.** `registries:` in the manifest holds registry repos (git repos with an `index.yaml`), consulted in order — the first to declare the name wins. There is deliberately **no built-in catalog and no `@org/name` → github guessing**: the CLI core knows no vendor, and a name nobody explicitly trusted never turns into an install from an invented URL. A name no trusted registry declares is refused with suggestions. Installs without a registry are always **explicit sources**: `github:org/repo`, `git+<url>[@ref][#path]`. Vendor defaults exist only as lines `init` seeds into the manifest — visible, reviewable, deletable (`doctor` still flags a name whose current resolution url no longer matches the lock).
 
 **Versions are git tags.** Ranges (`^1.2.0`, `~1.2.0`, exact, `latest`) match stable `x.y.z` tags (optional `v` prefix) listed via `git ls-remote` — no clone to resolve. `add` without a range picks the highest stable tag and records `^that`. A branch or commit pin is `ref:`, the escape hatch that ranges never touch. Prerelease-suffixed tags are invisible to ranges by design.
 
@@ -61,7 +59,7 @@ packages:
   "@ainova-systems/core":
     version: "^0.3.0"        # or: ref: main  /  url: + path: (direct git specs)
 registries:
-  "@acme": "https://github.com/acme/intelligence-registry.git"
+  - "https://github.com/acme/intelligence-registry.git"
 ```
 
 `project.intelligence_dir` names the content dir when it is not `intelligence/`. `sync_version` stays the frozen schema-contract key, stamped by the CLI with the bundled engine version — an npm prerelease suffix never reaches it.
@@ -75,14 +73,15 @@ The engine's CLI mode is an env contract, set by the dispatcher and honored only
 | `CONFIG_FILE` | `<root>/intelligence.yaml` |
 | `REPO_ROOT` | the project root |
 | `IS_UMBRELLA_REL` | content dir (`intelligence`) |
-| `IS_MODULE_REL` | `.intelligence/engine` |
+| `IS_MODULE_REL` | `.intelligence/packages/@ainova-systems/sync` |
+| `IS_MANIFEST_NAME` | `intelligence.yaml` (feeds the `<manifest>` token; vendored default `config.yaml`) |
 | `IS_SYNC_CMD` | `intelligence sync` (expanded for the `<sync-cmd>` token) |
 | `IS_PROTECTED_DIRS` | `<content-dir>:.intelligence` — restores output-path protection for a root manifest |
 | `IS_SUPPRESS_CLI_NOTE` | set to silence the vendored-flow recommendation note |
 
 ## migrate: vendored (v1) → CLI (v2)
 
-Fail-closed preconditions (clean worktree unless `--force`; no half-migrated state; project schema not newer than the engine; an older schema is first brought up by the engine's own migration chain). Then **stage** — the manifest is `config.yaml` transformed comment-preservingly (module sources → `.intelligence/engine/*`, `@pack/sub` references → store paths, `packs:` → `packages:` entries keeping their `ref:` pins), mirrored packs are *copied* from their mirrors (network untouched, sha carried from the `.pack` stamp), transient packs fetched — **verify** (staged sources exist; per-adapter `enabled`/`output` equality against the old config) — **commit**: store and manifest move in, a real sync must report `IS_STATUS=ok`, and only then are the vendored module, `config.yaml` (backed up to `.intelligence/backup/`) and the mirrors removed. Any earlier failure rolls back to an untouched project. `--dry-run` stages, verifies, prints, writes nothing.
+Fail-closed preconditions (clean worktree unless `--force`; no half-migrated state; project schema not newer than the engine; an older schema is first brought up by the engine's own migration chain). Then **stage** — the manifest is `config.yaml` transformed comment-preservingly (module sources → the `@ainova-systems/sync` package store, `@pack/sub` references → store paths, `packs:` → `packages:` entries keeping their `ref:` pins), mirrored packs are *copied* from their mirrors (network untouched, sha carried from the `.pack` stamp), transient packs fetched — **verify** (staged sources exist; per-adapter `enabled`/`output` equality against the old config) — **commit**: store and manifest move in, a real sync must report `IS_STATUS=ok`, and only then are the vendored module, `config.yaml` (backed up to `.intelligence/backup/`) and the mirrors removed. Any earlier failure rolls back to an untouched project. `--dry-run` stages, verifies, prints, writes nothing.
 
 ## Developing and releasing the CLI
 

package/engine/docs/CONVENTIONS.md

@@ -56,7 +56,8 @@ An artifact shipped *by the engine* cannot write the umbrella's name down — th
 | Token | Expands to | Example |
 |---|---|---|
 | `<umbrella>` | repo-relative umbrella dir | `Intelligence` |
-| `<module>` | repo-relative engine module | `Intelligence/sync` (CLI setup: `.intelligence/engine`) |
+| `<module>` | repo-relative engine module | `Intelligence/sync` (CLI setup: `.intelligence/packages/@ainova-systems/sync`) |
+| `<manifest>` | the project's config file, by name | vendored: `config.yaml`; CLI setup: `intelligence.yaml` |
 | `<sync-cmd>` | how a reader re-runs the sync | vendored: `bash Intelligence/sync/scripts/sync.sh`; CLI setup: `intelligence sync` |
 
 Expansion covers frontmatter and body alike, so `paths: ["<umbrella>/**"]` reaches Claude's `paths:`, Cursor's `globs:` and Copilot's `applyTo:` already carrying the project's real folder name. Project-authored artifacts may use the tokens too, but they have no reason to — they can simply name their own folders. `<sync-cmd>` exists because "run a sync" is spelled differently per setup: engine content says the token, and `IS_SYNC_CMD` (set by the CLI) picks the spelling; unset, it reproduces the vendored command string exactly.
@@ -408,12 +409,13 @@ Bash emits `IS_STATUS=<code> [IS_DETAIL=...]` on stdout and exits with the match
 |---|---|
 | `CONFIG_FILE` | `<root>/intelligence.yaml` (the root manifest) |
 | `REPO_ROOT` | project root |
-| `IS_UMBRELLA_REL` / `IS_MODULE_REL` | content dir (default `intelligence`) / `.intelligence/engine` |
+| `IS_UMBRELLA_REL` / `IS_MODULE_REL` | content dir (default `intelligence`) / `.intelligence/packages/@ainova-systems/sync` |
+| `IS_MANIFEST_NAME` | `intelligence.yaml` — feeds the `<manifest>` token (vendored default: `config.yaml`) |
 | `IS_SYNC_CMD` | `intelligence sync` (feeds the `<sync-cmd>` token) |
 | `IS_PROTECTED_DIRS` | colon-separated dirs `validate_output_path` must refuse — restores the source-tree protection a root manifest would otherwise disable |
 | `IS_SUPPRESS_CLI_NOTE` | silences the vendored-flow recommendation NOTE (stderr-only either way) |
 
-In CLI projects the `intelligence-sync` and `intelligence-update` meta-skills are not installed — `intelligence sync` / `intelligence update` replace them; the other meta-skills ship unchanged and reach outputs from `.intelligence/engine/skills`. `sync.sh` in CLI mode still never migrates: an outdated stamp exits `needs-update` and the CLI's own `upgrade` closes the gap. See `docs/CLI.md` for the full CLI surface.
+In CLI projects the engine's content is the `@ainova-systems/sync` package (auto-added by `init`, pinned to the engine version, moved only by `intelligence upgrade`), so **every** meta-skill ships in both modes: `intelligence-sync` runs `<sync-cmd>` wherever it lands, and `intelligence-update` self-redirects to `intelligence upgrade` when it finds a root `intelligence.yaml`. `sync.sh` in CLI mode still never migrates: an outdated stamp exits `needs-update` and the CLI's own `upgrade` closes the gap. See `docs/CLI.md` for the full CLI surface.
 
 ## .gitignore Pattern
 

package/engine/rules/intelligence-authoring.md

@@ -25,9 +25,9 @@ Three ways to shorten, in order of what they are worth:
 
 ## Source of truth
 
-Edit the sources listed in `config.yaml` — the `rules/`, `agents/` and `skills/` directories it names — and `config.yaml` itself. Everything else is derived: `.claude/`, `.cursor/`, `.github/{instructions,agents,skills}/`, `.codex/`, `.agents/skills/`, `.pi/`, `.opencode/` and `AGENTS.md` are **generated output**, and a hand edit there survives exactly until the next sync.
+Edit the sources listed in `<manifest>` — the `rules/`, `agents/` and `skills/` directories it names — and `<manifest>` itself. A source that arrived from the engine or an installed package is not yours to edit either — it is replaced on the next update or install; change it in its own repository. Everything else is derived: `.claude/`, `.cursor/`, `.github/{instructions,agents,skills}/`, `.codex/`, `.agents/skills/`, `.pi/`, `.opencode/` and `AGENTS.md` are **generated output**, and a hand edit there survives exactly until the next sync.
 
-`<module>/` is the vendored engine. It owns its own rules, agents and meta-skills; `update.sh` replaces them wholesale, so a local edit there is lost at the next update. Fix it upstream instead.
+`<module>/` is the engine's own content. It owns its own rules, agents and meta-skills, and every engine update replaces it wholesale, so a local edit there is lost. Fix it upstream instead.
 
 After any change: `<sync-cmd>`. A change that was not synced does not exist for any tool.
 
@@ -84,11 +84,11 @@ The verb just names the action — `add-`, `run-`, `review-`, `extract-`, `plan-
 
 Two verbs are told apart by what already exists. **`add-` puts one new member into a set that is already there** — a field on an existing type, a record among records, a component in the inventory the project keeps — so the noun names the member, and the number of files it takes to land is not the point. **`create-` brings the container itself into existence**, where nothing hosted it before. Neither verb describes how a skill is factored inside, so splitting a skill's internals never renames it.
 
-`intelligence-` is **reserved** for the engine's own artifacts. A project skill carrying that prefix is pruned by the updater — rename it.
+`intelligence-` is **reserved** for the engine's own artifacts. A project skill carrying that prefix collides with engine ownership — everything under the prefix is the engine's to replace or remove on update — rename it.
 
 ### Shape
 
-- **A skill is executed, so it must not hardcode what can move.** Its steps are followed literally: a path, a command or a project name baked into a procedure breaks the moment the layout moves. Resolve them from a rule or from `config.yaml` instead. This does **not** apply to rules and agents — a rule's job is to *describe* the repository, so naming a path in prose is exactly right. Naming a path is description; baking one into a procedure is a defect waiting to fire.
+- **A skill is executed, so it must not hardcode what can move.** Its steps are followed literally: a path, a command or a project name baked into a procedure breaks the moment the layout moves. Resolve them from a rule or from `<manifest>` instead. This does **not** apply to rules and agents — a rule's job is to *describe* the repository, so naming a path in prose is exactly right. Naming a path is description; baking one into a procedure is a defect waiting to fire.
 - **Keep everything the skill needs inside the skill's own folder.** The Agent Skills standard lets a skill ship `scripts/`, `references/` and `assets/` beside `SKILL.md`, and sync copies the whole directory, so a bundled helper travels with the skill to every tool. That is the default.
 - **Promote a helper out of the skill folder only when a second skill needs it** — then it belongs beside the source groups, and every skill resolves it the same way. The dividing line is reuse, not repetition: one skill's helper stays with that skill however often it runs.
 - **A helper is code.** It gets what code gets — a test, and a way to run it that does not assume one person's machine.

package/engine/scripts/ENGINE_SHA

@@ -0,0 +1 @@
+3a5cd174c73bd3918ac0a01df8d54a6f3d98b485

package/engine/scripts/lib/common.sh

@@ -42,13 +42,16 @@ finalize_output_file() {
     # `<sync-cmd>` is how engine content says "run a sync": vendored setups
     # expand it to the script invocation (built from $mod, so it reproduces the
     # exact pre-token string), the CLI overrides it via IS_SYNC_CMD
-    # (`intelligence sync`).
+    # (`intelligence sync`). `<manifest>` names the project's config file the
+    # same way: `config.yaml` vendored, `intelligence.yaml` under the CLI
+    # (IS_MANIFEST_NAME).
     local sc="${IS_SYNC_CMD:-bash $mod/scripts/sync.sh}"
+    local mf="${IS_MANIFEST_NAME:-config.yaml}"
     local tmp_file="$target.tmp"
     # Literal (index-based) substitution, not gsub: a regex replacement would
     # give `&` in a path its special meaning, and POSIX awk has no way to pass a
     # replacement string verbatim.
-    awk -v umb="$umb" -v mod="$mod" -v sc="$sc" '
+    awk -v umb="$umb" -v mod="$mod" -v sc="$sc" -v mf="$mf" '
         function repl(s, from, to,   out, i) {
             out = ""
             while ((i = index(s, from)) > 0) {
@@ -60,6 +63,7 @@ finalize_output_file() {
         {
             sub(/\r$/, "")
             $0 = repl($0, "<sync-cmd>", sc)
+            $0 = repl($0, "<manifest>", mf)
             $0 = repl($0, "<module>", mod)
             $0 = repl($0, "<umbrella>", umb)
             print

package/engine/scripts/sync.sh

@@ -94,7 +94,7 @@ if [ "${IS_CLI:-0}" = "1" ]; then
     # `/d/...`, and prefix comparisons downstream need one spelling.
     CONFIG_FILE="$(cd "$(dirname "$CONFIG_FILE")" && pwd)/$(basename "$CONFIG_FILE")"
     IS_UMBRELLA_REL="${IS_UMBRELLA_REL:-intelligence}"
-    IS_MODULE_REL="${IS_MODULE_REL:-.intelligence/engine}"
+    IS_MODULE_REL="${IS_MODULE_REL:-.intelligence/packages/@ainova-systems/sync}"
     # Project-owned adapters keep their v1 home: <umbrella>/adapters/.
     INTELLIGENCE_DIR="$REPO_ROOT/$IS_UMBRELLA_REL"
 else

package/engine/skills/intelligence-add-agent/SKILL.md

@@ -9,19 +9,19 @@ argument-hint: <domain> [description]
 ## Steps
 
 1. **Determine domain prefix** (the scope is required):
-   - **Reuse the existing domain when one fits**: list `intelligence/agents/` and `intelligence/skills/`. If a domain prefix is already established for the target area (`backend-`, `frontend-`, `devops-`), use it. Introduce a new domain only when the scope is materially different from all existing ones.
+   - **Reuse the existing domain when one fits**: list `<umbrella>/agents/` and `<umbrella>/skills/`. If a domain prefix is already established for the target area (`backend-`, `frontend-`, `devops-`), use it. Introduce a new domain only when the scope is materially different from all existing ones.
    - **When no existing domain fits**, derive from repo structure:
-     - Single / root project → use the project codename from `intelligence/config.yaml` → `project.name`
+     - Single / root project → use the project codename from `<manifest>` → `project.name`
      - Backend service / API component → `backend-`
      - Frontend / web / UI component → `frontend-`
      - Infrastructure, IaC, CI/CD, deployment → `devops-`
      - Shared library / common / cross-cutting code → `core-`
      - Test suites (e2e, integration) → `tests-`
-     - Tool-internal (intelligence-sync itself) → `intelligence-`
+     - Tool-internal (intelligence-sync itself) → `intelligence-` (only inside the intelligence-sync repo — downstream projects must not use this prefix)
    - If the repo is a monorepo with named components (e.g., `apps/billing`, `services/auth`), prefer the component name as the domain (`billing-`, `auth-`).
    - **Every agent needs a domain prefix.** If the scope is unclear, ask the user before proceeding.
 
-2. **Check existing agents**: Read `intelligence/agents/` to avoid duplicates. If an agent for this domain exists, ask user whether to update it instead.
+2. **Check existing agents**: Read `<umbrella>/agents/` to avoid duplicates. If an agent for this domain exists, ask user whether to update it instead.
 
 3. **Determine tier and access**:
    - Developer agents: `tier: heavy`, `access: full`
@@ -36,7 +36,7 @@ argument-hint: <domain> [description]
    - Build and test commands
    - Key conventions and forbidden patterns
 
-5. **Create agent**: Write `intelligence/agents/<domain>-<role>.md` with frontmatter:
+5. **Create agent**: Write `<umbrella>/agents/<domain>-<role>.md` (create the directory if missing) with frontmatter:
    ```yaml
    ---
    name: <domain>-<role>
@@ -52,11 +52,11 @@ argument-hint: <domain> [description]
 
 6. **Write body** with sections: **Expertise** -> **Boundaries** -> **Build & Verify**
    - An agent is **thin**: who it is, where it stops, how it verifies. Everything else already reaches it.
-   - **Do not tell the agent to read the rules.** Rules load on their own: Claude Code loads `.claude/rules/` into every custom subagent's startup context alongside `CLAUDE.md` (*Subagents → What loads at startup*), and Cursor / Copilot / Codex / Pi / opencode receive always-on rules inlined in `AGENTS.md`. A `Read intelligence/rules/<domain>.md before starting` line duplicates content the agent already has — double the tokens, and a second copy that drifts from the rule it copied.
+   - **Do not tell the agent to read the rules.** Rules load on their own: Claude Code loads `.claude/rules/` into every custom subagent's startup context alongside `CLAUDE.md` (*Subagents → What loads at startup*), and Cursor / Copilot / Codex / Pi / opencode receive always-on rules inlined in `AGENTS.md`. A `Read <umbrella>/rules/<domain>.md before starting` line duplicates content the agent already has — double the tokens, and a second copy that drifts from the rule it copied.
    - **Point at a rule, never restate it.** If you want to copy a rule into the agent, the rule is in the wrong place — move it, do not clone it.
    - **Do carry** what is genuinely the agent's own: its boundaries ("if the app is not running, stop — do not hand-write the output"), its verification commands, its definition of done.
    - All content must come from actual codebase analysis.
 
-7. **Link existing skills**: Find skills in `intelligence/skills/` matching this domain prefix and add them to the agent's `skills:` frontmatter.
+7. **Link existing skills**: Find skills in `<umbrella>/skills/` matching this domain prefix and add them to the agent's `skills:` frontmatter.
 
 8. **Run `/intelligence-sync`** to distribute to all enabled IDE targets.

package/engine/skills/intelligence-add-rule/SKILL.md

@@ -9,9 +9,9 @@ argument-hint: <name> [paths-glob]
 ## Steps
 
 1. **Determine rule name from domain** (the scope is required):
-   - **Reuse the existing domain when one fits**: list `intelligence/rules/`. If a rule file covers the target area (e.g., `backend.md`, `frontend.md`), extend it. Introduce a new domain only when the scope is materially different from all existing rules.
+   - **Reuse the existing domain when one fits**: list `<umbrella>/rules/`. If a rule file covers the target area (e.g., `backend.md`, `frontend.md`), extend it. Introduce a new domain only when the scope is materially different from all existing rules.
    - **When no existing rule fits**, derive the filename from repo structure:
-     - Single / root project → use the project codename from `intelligence/config.yaml` → `project.name` (e.g., `<codename>.md`)
+     - Single / root project → use the project codename from `<manifest>` → `project.name` (e.g., `<codename>.md`)
      - Backend service / API component → `backend.md`
      - Frontend / web / UI component → `frontend.md`
      - Infrastructure, IaC, CI/CD, deployment → `devops.md`
@@ -21,7 +21,7 @@ argument-hint: <name> [paths-glob]
    - If the repo is a monorepo with named components (e.g., `apps/billing`, `services/auth`), prefer the component name as the rule name (`billing.md`, `auth.md`).
    - **Rule filenames match the domain used by skills/agents.** If the scope is unclear, ask the user before proceeding.
 
-2. **Check existing rules**: Read `intelligence/rules/` to detect overlapping scope — favor extending an existing rule over creating a new one.
+2. **Check existing rules**: Read `<umbrella>/rules/` to detect overlapping scope — favor extending an existing rule over creating a new one.
 
 3. **Determine scope**:
    - If paths glob provided — scoped rule with `paths:` frontmatter
@@ -34,7 +34,7 @@ argument-hint: <name> [paths-glob]
    - Build and test commands specific to this scope
    - Anti-patterns observed in code, each paired with the positive replacement that should adopt instead
 
-5. **Create rule**: Write `intelligence/rules/<name>.md`:
+5. **Create rule**: Write `<umbrella>/rules/<name>.md` (create the directory if it does not exist — the sources list already covers it):
    ```yaml
    ---
    paths:
@@ -49,6 +49,6 @@ argument-hint: <name> [paths-glob]
    - Examples come from the actual codebase — reference real files
    - Every REQUIRED / Invariant / Pattern is backed by observed code
 
-7. **Update config.yaml** if needed: Add source path to `sources.rules` if rule is in a new directory not yet listed.
+7. **Update `<manifest>` only when needed**: add the path to `sources.rules` only if the rule lives in a directory not already listed there — creating a pre-listed directory is enough.
 
 8. **Run `/intelligence-sync`** to distribute to all enabled IDE targets.

package/engine/skills/intelligence-add-skill/SKILL.md

@@ -9,15 +9,15 @@ argument-hint: <domain> <verb-noun> [description]
 ## Steps
 
 1. **Determine domain prefix** (the scope is required):
-   - **Reuse the existing domain when one fits**: list `intelligence/skills/` and `intelligence/agents/`. If a domain prefix is already established for the target area (`backend-`, `frontend-`, `devops-`), use it. Introduce a new domain only when the scope is materially different from all existing ones.
+   - **Reuse the existing domain when one fits**: list `<umbrella>/skills/` and `<umbrella>/agents/`. If a domain prefix is already established for the target area (`backend-`, `frontend-`, `devops-`), use it. Introduce a new domain only when the scope is materially different from all existing ones.
    - **When no existing domain fits**, derive from repo structure:
-     - Single / root project → use the project codename from `intelligence/config.yaml` → `project.name`
+     - Single / root project → use the project codename from `<manifest>` → `project.name`
      - Backend service / API component → `backend-`
      - Frontend / web / UI component → `frontend-`
      - Infrastructure, IaC, CI/CD, deployment → `devops-`
      - Shared library / common / cross-cutting code → `core-`
      - Test suites (e2e, integration) → `tests-`
-     - Tool-internal (intelligence-sync itself) → `intelligence-`
+     - Tool-internal (intelligence-sync itself) → `intelligence-` (only inside the intelligence-sync repo — downstream projects must not use this prefix)
    - If the repo is a monorepo with named components (e.g., `apps/billing`, `services/auth`), prefer the component name as the domain (`billing-`, `auth-`).
    - **Every skill needs a domain prefix.** If the scope is unclear, ask the user before proceeding.
 
@@ -28,13 +28,13 @@ argument-hint: <domain> <verb-noun> [description]
    - `run-` — executes an operation (tests, build, sync)
    - `review-` — read-only analysis
 
-3. **Check for existing agent**: Find an agent in `intelligence/agents/` matching the domain
+3. **Check for existing agent**: Find an agent in `<umbrella>/agents/` matching the domain
    - If found — this skill will be linked to that agent
    - If not — ask user whether to create a new agent via `/intelligence-add-agent` first
 
 4. **Analyze codebase patterns**: Read existing implementations to extract the repeatable steps this skill should automate. Each step must come from actual code patterns, not generic knowledge.
 
-5. **Create skill**: Write `intelligence/skills/<full-name>/SKILL.md` with frontmatter:
+5. **Create skill**: Write `<umbrella>/skills/<full-name>/SKILL.md` (create the directory if missing — no config edit needed) with frontmatter:
    ```yaml
    ---
    name: <full-name>

package/engine/skills/intelligence-extract-skill/SKILL.md

@@ -26,7 +26,7 @@ Both end at the same artifact format. Extract starts from observed behavior, so
    - Behavioral preference / constraint / pattern to default to → **rule** (use `intelligence-learn-from-context` for single preferences from session)
    - Knowledge area / persona / expertise scope → **agent**
 
-4. **Determine domain prefix** (for skill / agent): reuse the existing domain when one fits — list `intelligence/skills/` and `intelligence/agents/`. Derive from repo structure only when no existing domain matches.
+4. **Determine domain prefix** (for skill / agent): reuse the existing domain when one fits — list `<umbrella>/skills/` and `<umbrella>/agents/`. Derive from repo structure only when no existing domain matches.
 
 5. **Determine naming** (for skill): `<domain>-<verb>-<noun>` with convention verbs — `add-` (one new member of a set that already exists), `create-` (the container itself, where nothing hosted it), `update-` (revise what is there), `run-` (execute), `review-` (read-only analysis).
 
@@ -38,7 +38,7 @@ Both end at the same artifact format. Extract starts from observed behavior, so
 
 ## Authoring guidance
 
-Follow the **Authoring Discipline** section in `docs/CONVENTIONS.md` when writing the artifact body — size budgets (<500 lines for SKILL.md body), imperative form, explain WHY, reserve absolute language for true invariants, lead with positive defaults.
+Follow the **Authoring Discipline** section in `<module>/docs/CONVENTIONS.md` when writing the artifact body — size budgets (<500 lines for SKILL.md body), imperative form, explain WHY, reserve absolute language for true invariants, lead with positive defaults.
 
 ## Related skills
 

package/engine/skills/intelligence-install-adapter/SKILL.md

@@ -7,19 +7,19 @@ agent: intelligence-operator
 
 # Install Adapter
 
-The umbrella is whatever directory holds `config.yaml` (`intelligence/`, `Intelligence/`, a codename — never assume the name or casing); the engine module is the directory under it holding `scripts/sync.sh` (conventionally `sync/`).
+The project's config is `<manifest>`; the content dir is `<umbrella>/` (never assume the name or casing); the engine's own files live under `<module>/` — these paths are localized to this project at sync time.
 
 ## Steps
 
-1. Check whether target `$ARGUMENTS` is already enabled in `config.yaml` — if yes, report and stop.
+1. Check whether target `$ARGUMENTS` is already enabled in `<manifest>` — if yes, report and stop.
 
-2. **Locate the adapter.** `sync.sh` discovers adapters in two places:
-   - **Built-in**: `<module>/scripts/adapters/$ARGUMENTS.sh` — upstream-owned. `update.sh` replaces that whole directory on every engine update.
-   - **Project-owned**: `<umbrella>/adapters/$ARGUMENTS.sh` — `update.sh` never touches it. A project adapter of the same name overrides the built-in.
+2. **Locate the adapter.** The sync discovers adapters in two places:
+   - **Built-in**: `<module>/scripts/adapters/$ARGUMENTS.sh` — upstream-owned. Every engine update replaces that whole directory.
+   - **Project-owned**: `<umbrella>/adapters/$ARGUMENTS.sh` — updates never touch it. A project adapter of the same name overrides the built-in.
 
    If neither exists, research the tool's prompt format (web search for its rules / agents / skills file layout), then copy `<module>/scripts/adapters/_template.sh` to **`<umbrella>/adapters/$ARGUMENTS.sh`** and implement `sync_to_$ARGUMENTS()`. Author it there, never inside the engine's `scripts/adapters/` — a file written there is deleted by the next engine update. Adapter contract: `<module>/docs/ADAPTERS.md`. An adapter that would serve every project is worth contributing upstream.
 
-3. Update `config.yaml`:
+3. Update `<manifest>`:
    - Target exists with `enabled: false` → flip to `enabled: true`.
    - Target missing → add it under `targets:` with its `output:` path.
    - If the target reads always-on rules from `AGENTS.md` (`cursor`, `copilot`, `codex`, `pi`, `opencode`), `targets.agents` must be enabled too — sync fails closed otherwise.

package/engine/skills/intelligence-learn-from-context/SKILL.md

@@ -21,7 +21,7 @@ The original negative pattern stays in the rule body as an illustrative example
 
 ## Phase A — Analyze (read-only)
 
-1. **Read authoring conventions first.** Discover the paths, never assume them: the umbrella is the directory holding `config.yaml` (`intelligence/`, `Intelligence/`, a codename), and the engine module is the directory under it holding both `scripts/sync.sh` and `scripts/VERSION` (conventionally `sync/`). The meta-skills live in `<module>/skills/`, not directly under the umbrella. Load `<module>/skills/intelligence-add-rule/SKILL.md`, `<module>/skills/intelligence-add-skill/SKILL.md`, `<module>/skills/intelligence-add-agent/SKILL.md`, and `<module>/docs/CONVENTIONS.md` (Authoring Discipline section). This skill writes nothing on its own — it delegates to the add-* skills, which carry the authoring conventions.
+1. **Read authoring conventions first.** The paths below are localized to this project at sync time: `<umbrella>/` is the content dir, `<module>/` the engine's own files, `<manifest>` the config. The meta-skills live in `<module>/skills/`, not directly under the umbrella. Load `<module>/skills/intelligence-add-rule/SKILL.md`, `<module>/skills/intelligence-add-skill/SKILL.md`, `<module>/skills/intelligence-add-agent/SKILL.md`, and `<module>/docs/CONVENTIONS.md` (Authoring Discipline section). This skill writes nothing on its own — it delegates to the add-* skills, which carry the authoring conventions.
 
 2. **Capture the lesson** from session context or user input. Strip session-specific detail, keep the underlying pattern.
 

package/engine/skills/intelligence-review-skills/SKILL.md

@@ -13,11 +13,11 @@ Name reflects the umbrella usage of "skills" for all AI artifacts (rules + agent
 
 ## Scope: what to read, and what to leave alone
 
-1. **Resolve the layout — never assume folder names.** The umbrella is the directory holding `config.yaml`; the engine module is the directory under it holding `scripts/sync.sh` and `scripts/VERSION` (conventionally `sync/`). Read authoring conventions from `<module>/docs/CONVENTIONS.md` and the `intelligence-authoring` rule.
+1. **Resolve the layout — never assume folder names.** `<umbrella>/` is the content dir, `<module>/` the engine's own files, `<manifest>` the config — all localized to this project at sync time. Read authoring conventions from `<module>/docs/CONVENTIONS.md` and the `intelligence-authoring` rule.
 
-2. **Enumerate from `config.yaml`, not from a guessed path.** The artifacts are exactly the directories listed under `sources.rules`, `sources.agents` and `sources.skills` — there may be several groups (e.g. a shared one and a project one), they may be nested, and an `@<pack>` (or inline `git+`) entry is a remote pack declared under `packs:`. Take the list from the config; a literal `intelligence/rules/` is wrong in any project that named things differently.
+2. **Enumerate from `<manifest>`, not from a guessed path.** The artifacts are exactly the directories listed under `sources.rules`, `sources.agents` and `sources.skills` — there may be several groups (e.g. a shared one and a project one), they may be nested, and a remote entry is a declared pack (vendored setups, `packs:`) or an installed package (CLI setups, `packages:`, content under `.intelligence/packages/`). Take the list from the config; a literal `intelligence/rules/` is wrong in any project that named things differently.
 
-3. **Skip everything the engine owns.** Sources under `<module>/` (`<module>/rules`, `<module>/agents`, `<module>/skills/intelligence-*`) are upstream-owned: `update.sh` replaces them wholesale, so a local "fix" there is deleted at the next update. Never propose an edit to them. If one of them is genuinely wrong, or a generic check is missing from this skill, that is a **proposal to upstream** — say so in the report rather than patching locally.
+3. **Skip everything the engine owns.** Sources under `<module>/` (`<module>/rules`, `<module>/agents`, `<module>/skills/intelligence-*`) are upstream-owned: every engine update replaces them wholesale, so a local "fix" there is deleted at the next update. Never propose an edit to them. If one of them is genuinely wrong, or a generic check is missing from this skill, that is a **proposal to upstream** — say so in the report rather than patching locally.
 
 4. **Never read or edit generated output** (`.claude/`, `.cursor/`, `.github/`, `.codex/`, `.agents/`, `.pi/`, `.opencode/`, `AGENTS.md`). Sync owns those entirely; the finding always belongs to the source.
 
@@ -34,9 +34,9 @@ Name reflects the umbrella usage of "skills" for all AI artifacts (rules + agent
    | **Over the cap** | `SKILL.md` over 1000 lines, rule over 500, agent over 200 | `SPLIT` — two artifacts, or move detail into `references/<topic>.md` |
    | **Rule links to a rule** | A markdown link from one rule to another (`R1`) | `UNLINK` — name the rule instead: always-on rules are inlined into `AGENTS.md` and the scoped channels carry only scoped rules, so the link is dead in at least one output |
    | **Machine facts in a rule** | OS, shell, editor or a local absolute path (`R2`) | `MOVE` — these belong in a personal, gitignored `CLAUDE.md`; a rule is committed and read by everyone, including whoever is on another platform |
-   | **Literal path or command in a skill** | A path *outside the skill's own folder* baked into a procedure (`R3`) | `PARAMETERIZE` — a skill is *executed*, so a literal path breaks the moment the layout moves; resolve it from a rule or from `config.yaml`. **Exempt:** the skill's own bundle (`references/`, `scripts/`, `assets/` — content is co-located with its skill by default); rules and agents (describing the repository is their job); an example inside an output-format block; the resolution step itself |
+   | **Literal path or command in a skill** | A path *outside the skill's own folder* baked into a procedure (`R3`) | `PARAMETERIZE` — a skill is *executed*, so a literal path breaks the moment the layout moves; resolve it from a rule or from `<manifest>`. **Exempt:** the skill's own bundle (`references/`, `scripts/`, `assets/` — content is co-located with its skill by default); rules and agents (describing the repository is their job); an example inside an output-format block; the resolution step itself |
    | **Skill with no verification** | Nothing at the end proves the procedure worked (`R4`) | `FLAG` — a procedure that proves nothing is a note, or just the work: give it a verification, or delete it |
-   | **Reserved prefix** | A project artifact named `intelligence-*` | `RENAME` — the prefix belongs to the engine, and the updater prunes what matches it |
+   | **Reserved prefix** | A project artifact named `intelligence-*` | `RENAME` — the prefix belongs to the engine, which replaces or removes everything under it on update |
    | **Naming** | A skill that is not `<domain>-<verb>-<noun>`, or a domain invented rather than reused | `RENAME` — or introduce the new domain deliberately |
    | **Stale** | No edits in 6+ months and nothing cross-references it | `ARCHIVE` — move to `<umbrella>/_archive/` |
    | **Negative-framed judgement call** | "Never do X" where a positive default fits, outside safety / security / output-format | `REWRITE` — state the default; reserve NEVER for true must-nots |

package/engine/skills/intelligence-sync/SKILL.md

@@ -5,14 +5,12 @@ agent: intelligence-operator
 context: fork
 ---
 
-Run the sync engine to transform rules, agents, and skills from the intelligence source directory to each enabled IDE's native format.
+Run the sync engine to transform rules, agents, and skills from the intelligence sources to each enabled IDE's native format.
 
-> **Folder name:** `<intel>` is whatever holds your `config.yaml` — typically `intelligence/`, but may have been renamed (e.g. `Intelligence/`). The engine lives in the module subfolder `<intel>/sync/` and is self-locating, so any spelling works as long as you point bash at the right `sync/scripts/sync.sh` path.
->
-> **sync.sh never migrates.** It is a pure synchronizer: on a pre-0.3.1 / non-modular layout or an un-applied schema it **fails closed** with `IS_STATUS=needs-update` (exit 6) and changes nothing. Migration is owned entirely by the `intelligence-update` flow — tell your agent *"Update intelligence-sync"* (or run `<intel>/sync/scripts/update.sh`) first, then re-run sync.
+> **The sync never migrates.** It is a pure synchronizer: across an un-applied schema it **fails closed** with `IS_STATUS=needs-update` (exit 6) and changes nothing. Bringing the project up to the engine is the update flow's job — in a vendored setup tell your agent *"Update intelligence-sync"* (the `intelligence-update` skill); in a CLI setup (root `intelligence.yaml`) run `npm i -g @ainova-systems/intelligence@latest` and `intelligence upgrade` — then re-run sync.
 
 ## Steps
 
-1. Run `bash <intel>/sync/scripts/sync.sh` (where `<intel>` is your intelligence source folder; default `intelligence`).
-2. Review the output — verify rule, agent, and skill counts per target.
-3. If warnings about unsynced directories appear, add the missing paths to `<intel>/config.yaml` under `sources:`.
+1. Run `<sync-cmd>`.
+2. Review the output — verify rule, agent, and skill counts per target, and that it ends with `IS_STATUS=ok`.
+3. If warnings about unsynced directories appear, add the missing paths under `sources:` in `<manifest>`.

package/engine/skills/intelligence-uninstall-adapter/SKILL.md

@@ -7,11 +7,11 @@ agent: intelligence-operator
 
 # Uninstall Adapter
 
-The umbrella is whatever directory holds `config.yaml` (`intelligence/`, `Intelligence/`, a codename — never assume the name or casing); the engine module is the directory under it holding `scripts/sync.sh` (conventionally `sync/`).
+The project's config is `<manifest>`; the content dir is `<umbrella>/` (never assume the name or casing); the engine's own files live under `<module>/` — these paths are localized to this project at sync time.
 
 ## Steps
 
-1. Set `enabled: false` for the target in `config.yaml`.
+1. Set `enabled: false` for the target in `<manifest>`.
 
 2. **Remove only the paths the adapter owns — never the output root.** Several adapters write into a shared root that also holds files nobody generated: `.github/` holds `workflows/`, `.claude/` holds `settings.json`, `.opencode/` holds `opencode.json`. Deleting the root destroys hand-authored work, and no adapter ever does that on re-sync.
 

package/engine/skills/intelligence-update/SKILL.md

@@ -35,6 +35,12 @@ They never run shell commands by hand — you do.
 
 ## Steps
 
+### 0. Vendored setups only
+If the project has a root `intelligence.yaml` (a CLI setup), **stop** — this
+flow is vendored-only. There the engine ships inside the CLI package: run
+`npm i -g @ainova-systems/intelligence@latest`, then `intelligence upgrade`,
+and verify with `intelligence doctor`.
+
 ### 1. Locate the umbrella & discover the engine
 Find the dir containing `config.yaml` → `<umbrella>`. Then find the engine by
 role: search `<umbrella>` (one level deep) for a directory `<M>` with both

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ainova-systems/intelligence",
-  "version": "0.11.0-rc.4",
+  "version": "0.11.0-rc.6",
   "description": "Build, version and distribute AI agent intelligence across your organization — one CLI, versioned Intelligence Packages, and a sync engine for Claude Code, Cursor, Copilot, Codex, Pi and OpenCode.",
   "bin": {
     "intelligence": "bin/intelligence.js"
@@ -8,8 +8,7 @@
   "files": [
     "bin",
     "cli",
-    "engine",
-    "registry"
+    "engine"
   ],
   "engines": {
     "node": ">=18"

package/registry/index.yaml

@@ -1,22 +0,0 @@
-# The default Intelligence Registry index, bundled with the CLI.
-#
-# Maps a package name to the git repo (and path inside it) the package lives
-# in. Needed exactly when a name is not the repo — monorepos like
-# intelligence-dev-packs. A name absent here falls through to the convention:
-# @org/name -> https://github.com/org/name.git, content at the repo root.
-# Organizations override or extend this per scope with `intelligence registry
-# add @scope <registry-repo-url>`.
-#
-# This copy travels inside the CLI package. The same index lives at
-# https://github.com/ainova-systems/intelligence-registry and can be bound
-# explicitly (`intelligence registry add @ainova-systems <url>`) to read the
-# newest entries without waiting for a CLI release.
-packages:
-  "@ainova-systems/core":
-    url: "https://github.com/ainova-systems/intelligence-dev-packs.git"
-    path: "packs/core"
-    description: "Engineering discipline for AI-first development: context engineering, artifact-derived status, review and diagnosis loops."
-  "@ainova-systems/spec":
-    url: "https://github.com/ainova-systems/intelligence-dev-packs.git"
-    path: "packs/spec"
-    description: "Spec-driven delivery: specifications, decision records, sliced execution."