@ainova-systems/intelligence 0.11.0-rc.7 → 0.11.0-rc.9

package/packages/sync/skills/intelligence-learn-from-repository/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: intelligence-learn-from-repository
+description: "Tailor Intelligence to an initialized repository"
+---
+
+# Learn from Repository
+
+Use after `intelligence init` creates or converts a project. The CLI owns the
+mechanical setup; this skill adds only repository-specific judgement.
+
+## Analyze
+
+1. Run `intelligence status --check`. If setup is missing or incomplete, stop
+   and ask the user to run `intelligence init`; do not reproduce CLI mechanics.
+2. Read `<manifest>` and resolve `<content-dir>` and the configured source
+   directories. Load `<module>/references/conventions.md` and the bundled
+   `intelligence-add-rule`, `intelligence-add-skill`, and
+   `intelligence-add-agent` skills before proposing authored content.
+3. Inspect repository evidence: its README and contributor instructions,
+   language and package manifests, build and test entry points, source layout,
+   CI, existing agent instructions, and existing project-owned rules, agents,
+   and skills. Treat documentation as a claim and verify important behavior in
+   code or executable configuration.
+4. Inventory what initialization already preserved or installed. Do not
+   recreate package-owned content, duplicate existing instructions, or convert
+   generated target output into source content.
+5. Propose the smallest useful project-owned layer. Prefer updating an existing
+   artifact over creating a sibling. Each proposal must state:
+   - `CREATE`, `UPDATE`, or `KEEP`;
+   - the source path;
+   - the repository evidence supporting it;
+   - the concise content or responsibility it would add.
+
+Analysis is read-only. Present the proposal and request approval per change.
+It is valid to recommend no new artifacts when the repository already explains
+itself well.
+
+## Apply after approval
+
+6. Apply only accepted proposals. Delegate new artifacts to
+   `intelligence-add-rule`, `intelligence-add-skill`, or
+   `intelligence-add-agent`; update an existing project-owned artifact directly
+   when that is the smaller change. Never edit installed package content or
+   generated tool output.
+7. Run `intelligence sync`, then `intelligence status --check`. Completion
+   requires `IS_STATUS=ok` and a clean consistency check.
+8. Report what was created, updated, or deliberately left unchanged. Remind the
+   user to review and commit generated and source changes according to project
+   policy.
+
+## Related skill
+
+Use `intelligence-learn-from-context` later to preserve a lesson learned during
+a working session. This skill learns the repository's existing structure and
+workflow during onboarding.

package/packages/sync/skills/intelligence-review-skills/SKILL.md

@@ -9,15 +9,15 @@ agent: intelligence-architect
 
 Read-only audit of the project's rules, agents and skills, ending in a punch-list. This skill owns the **generic** audit — everything true of any repository. A project that adds laws of its own layers a thin project audit on top and invokes this one; it never re-implements these checks.
 
-Name reflects the umbrella usage of "skills" for all AI artifacts (rules + agents + skills).
+The name uses "skills" as shorthand for all AI artifacts (rules, agents, and skills).
 
 ## Scope: what to read, and what to leave alone
 
-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.
+1. **Resolve the layout — never assume folder names.** `<content-dir>/` is the project content directory, `<module>/` the installed sync package, `<manifest>` the root manifest — all localized to this project at sync time. Read authoring conventions from `<module>/references/conventions.md` and the `intelligence-authoring` rule.
 
-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.
+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, they may be nested, and installed packages live under `.intelligence/packages/`. Take the list from the manifest; 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: 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.
+3. **Skip installed package sources.** Sources under `<module>/` (`<module>/rules`, `<module>/agents`, `<module>/skills/intelligence-*`) are package-owned and restored by CLI lifecycle operations, so a local "fix" is not durable. Never propose a project-local edit to them. If one is wrong, make an upstream proposal instead.
 
 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.
 
@@ -36,9 +36,9 @@ Name reflects the umbrella usage of "skills" for all AI artifacts (rules + agent
    | **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 `<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, which replaces or removes everything under it on update |
+   | **Reserved prefix** | A project artifact named `intelligence-*` | `RENAME` — the prefix belongs to the sync package and collides in generated output |
    | **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/` |
+   | **Stale** | No edits in 6+ months and nothing cross-references it | `ARCHIVE` — move to `<content-dir>/_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 |
    | **Unbacked reason** | A rule asserts a *why* — a number, a measurement, a tool's behaviour — that nothing in the repo or in that tool's documentation supports | `FLAG` — an invented reason is worse than none: it sounds like evidence. Surface it with a draft; never rewrite the meaning yourself |
    | **Always-on rule that should be scoped** | A concern that only matters in one area, loaded into every session and inlined into `AGENTS.md` | `SCOPE` — add `paths:`, or justify the cost out loud |

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

@@ -1,16 +1,20 @@
 ---
 name: intelligence-sync
-description: "Sync intelligence to enabled IDE targets"
+description: "Sync intelligence to enabled adapters"
 agent: intelligence-operator
 context: fork
 ---
 
-Run the sync engine to transform rules, agents, and skills from the intelligence sources to each enabled IDE's native format.
+# Sync intelligence
 
-> **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 `<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>`.
+1. Run `intelligence sync` (or `intelligence sync <adapter>` when one adapter
+   was requested). For v2, this command first aligns project schema/content
+   with the installed CLI and restores a missing package store strictly from
+   `intelligence.lock`.
+2. Require final `IS_STATUS=ok`; relay per-adapter counts and any model-drift
+   or unsynced-source warnings.
+3. In CI, a required tracked project upgrade is intentionally refused. Report
+   the instruction to run `intelligence init --apply` locally, review and
+   commit its diff; never bypass the gate. A frozen restore refusal means the
+   manifest and lock disagree or a pinned ref moved—report it without
+   hand-copying package content.

package/packages/sync/skills/intelligence-uninstall-adapter/SKILL.md

@@ -1,42 +1,24 @@
 ---
 name: intelligence-uninstall-adapter
-description: "Disable IDE adapter and clean up output"
-argument-hint: <target-name>
+description: "Disable an adapter and assess its generated output"
+argument-hint: <adapter-name>
 agent: intelligence-operator
 ---
 
-# Uninstall Adapter
-
-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 `<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.
-
-   | Target | Remove | Keep (never adapter-owned) |
-   |---|---|---|
-   | `claude` | `.claude/rules/`, `.claude/agents/`, skill subdirs in `.claude/skills/` | `.claude/` itself, `settings.json`, `settings.local.json`, `commands/` |
-   | `cursor` | `.cursor/rules/`, `.cursor/agents/`, `.cursor/skills/` | `.cursor/` itself, `settings.json` |
-   | `copilot` | `.github/instructions/`, `.github/prompts/`, `.github/agents/`, skill subdirs in `.github/skills/` | `.github/` itself, `workflows/`, `ISSUE_TEMPLATE/`, a hand-authored `copilot-instructions.md` |
-   | `codex` | `.codex/agents/` | `.codex/` itself |
-   | `pi` | `.pi/intelligence-sync/`, `.pi/extensions/intelligence-sync-rules.ts`, `.pi/prompts/intelligence-agent-*.md` | `.pi/settings.json`, any other extension or prompt |
-   | `opencode` | `.opencode/agents/`, and only the files in `.opencode/commands/` carrying the `<!-- Generated by intelligence-sync. Do not edit manually. -->` marker | `.opencode/opencode.json`, hand-authored commands |
-   | `agents` | `AGENTS.md` — only if the user confirms; it is a committed project doc | — |
-
-   `.agents/skills/` is **shared** by `codex`, `pi` and `opencode`. Remove it only when none of those three remains enabled.
-
-   For an adapter not in this table (a project adapter under `<umbrella>/adapters/`), read its `sync_to_<name>()` cleanup block: whatever it deletes on every re-sync is exactly what it owns.
-
-3. Remove the adapter's paths from `.gitignore` if nothing else needs them.
-
-4. Run `/intelligence-sync` to regenerate the remaining targets.
-
-5. **Verify** — an uninstall that removed the wrong thing must not pass quietly:
-   - sync reports `IS_STATUS=ok`;
-   - every path listed under *Remove* for this target is gone;
-   - every path listed under *Keep* still exists, with its content intact (`.github/workflows/`, `.claude/settings.json`, `.opencode/opencode.json`, hand-authored commands);
-   - the other enabled targets still produce their output.
-
-6. Report: adapter disabled, which paths were removed, which were deliberately kept, and the verification result.
+# Uninstall an adapter
+
+1. Run `intelligence adapter list`, then
+   `intelligence adapter disable $ARGUMENTS`. Disabling changes target state
+   and deliberately keeps generated output.
+2. If generated files should also be removed, inspect the adapter's cleanup
+   block to identify exactly what it owns. Show that list and obtain approval
+   before deleting it; never delete a shared output root.
+3. For a project adapter that should be deleted, run
+   `intelligence adapter remove $ARGUMENTS` after it is disabled. This prompts
+   by default (`--apply` is the explicit non-interactive form) and also keeps
+   generated output. Built-in adapter source cannot be removed.
+4. Remove obsolete `.gitignore` entries only when no remaining adapter needs
+   them. Sync the remaining enabled adapters when any exist.
+5. Verify with `intelligence adapter list` and `intelligence status --check`:
+   the adapter is disabled or removed as requested, retained files are intact,
+   and only approved adapter-owned output was deleted.

package/packages/sync/skills/intelligence-update/SKILL.md

@@ -1,165 +1,43 @@
 ---
 name: intelligence-update
-description: "Update or migrate intelligence-sync: discover engine, read changelog, run migration chain, verify"
-argument-hint: "[--yes]"
+description: "Interpret an update plan and verify breaking post-conditions"
+argument-hint: "[@scope/name]"
 agent: intelligence-operator
 ---
 
-# Update intelligence-sync
+# Update intelligence
 
-You are the **intelligent driver** of an update. The bash engine is
-deterministic and fail-closed — it never guesses; on any state it cannot
-resolve it prints `IS_STATUS=<code>` and stops. Your job: discover the engine,
-understand what is changing (read the CHANGELOG across the version gap), run
-the migration chain, branch on the status, and **verify afterward**. Ask the
-user only when genuinely ambiguous.
-
-Trigger: the user says something like *"update / migrate intelligence-sync"*.
-They never run shell commands by hand — you do.
-
-## Key facts
-
-- **Umbrella** = whatever directory holds `config.yaml` (`intelligence/`,
-  `Intelligence/`, …). Never assume the name — find it.
-- **Engine = a module discovered by ROLE, not by name**: a directory under
-  the umbrella whose `scripts/sync.sh` **and** `scripts/VERSION` both exist
-  (conventionally `sync/`, but never assume the folder name).
-- **Applied schema version** is the frozen contract key
-  `sync_version` in `config.yaml` (a permanent top-level scalar;
-  absent ⇒ pre-0.3.1). **Engine version** is `<module>/scripts/VERSION`.
-  The gap between them is the set of breaking changes to apply.
-- Pre-0.3.1 projects have the engine flat at `<umbrella>/scripts/` and **no**
-  `sync_version` key. Their frozen `update.sh` fails closed
-  against the modular upstream (changes nothing) — you bootstrap the first hop.
-- The `intelligence-` skill prefix is **reserved** for upstream meta-skills.
+The CLI owns planning and application. This skill interprets the plan, reads
+the changelog across an engine-version gap, obtains approval, and verifies the
+result.
 
 ## 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
-`<M>/scripts/sync.sh` and `<M>/scripts/VERSION`.
-
-- Several candidates → pick the one with the highest `scripts/VERSION`.
-- A module engine exists → use it; **never** fall back to a flat
-  `<umbrella>/scripts/` even if present (that's stale legacy).
-- No module engine, only flat `<umbrella>/scripts/` (or nothing) → this is a
-  pre-0.3.1 / un-bootstrapped project; go to step 2's bootstrap.
-- No `config.yaml` at all → not bootstrapped; point the user at upstream
-  `INIT.md` and stop.
-
-### 2. Fetch upstream (read-only) — do NOT write into the project yet
-Clone upstream into a temp dir (default
-`https://github.com/ainova-systems/intelligence-sync`, or the user's
-`REPO_URL`/fork). The upstream module is always `intelligence/sync/`.
-
-```
-git clone --depth=1 <repo> <tmp>
-```
-
-**Make no changes to the project before step 3's confirmation.** In
-particular do not copy anything into `<umbrella>/sync` yet — that would
-modify (and could downgrade) an already-modular project even if the user then
-declines. The temp clone is only for reading the CHANGELOG and as the source
-for the eventual write.
-
-### 3. Understand what is changing (changelog-aware)
-Determine the project's current version = the `sync_version`
-value in `config.yaml`, or `0.0.0` if the key is absent (pre-0.3.1). The
-engine version = `<tmp>/intelligence/sync/scripts/VERSION`.
-
-Read `<tmp>/CHANGELOG.md`. For every release in the range
-**`current < release <= engine`** (inclusive of the target release — its
-entry holds the destination's breaking post-conditions), read its entry. Pay
-special attention to any **`### Breaking`** subsection (the
-machine-distinguishable marker). Build a short list of breaking items, new
-migrations, and anything to verify afterward. Surface it to the user; without
-`--yes`, let them confirm before any write.
-
-### 3a. Ensure the engine to run (only now, post-confirmation)
-- **Modular project** (a module engine was discovered in step 1): run *its*
-  `update.sh` — at the discovered module dir, whatever its name. `update.sh`
-  re-clones upstream internally, shows the diff, and is authoritative; do not
-  hand-copy over the module.
-- **No module engine** (pre-0.3.1 flat or un-bootstrapped): only here create
-  the module from the temp clone, and only after confirmation:
-  ```
-  mkdir -p <umbrella>/sync
-  cp -r <tmp>/intelligence/sync/. <umbrella>/sync/
-  ```
-  then run `<umbrella>/sync/scripts/update.sh`.
-
-### 4. Run the engine
-Run the `update.sh` of the engine determined in 3a — the **discovered module
-dir** for a modular project (whatever its name), or the just-created
-`<umbrella>/sync` for the legacy bootstrap path:
-
-```
-bash <engine-module>/scripts/update.sh --yes   # omit --yes to confirm the diff
-```
-Capture stdout; find the last `IS_STATUS=<code> [IS_DETAIL=...]` line.
-
-### 5. Branch on `IS_STATUS`
-
-| Code | Meaning | Action |
-|---|---|---|
-| `ok` | Already current | Go to step 6. |
-| `migrated` | Migration chain applied | Go to step 6; note the relocation/changes. |
-| `aborted-incomplete` | Staged module incomplete; legacy intact (safe) | Re-run step 2–4 once (clone hiccup). Persists → show output, stop, don't hand-fix. |
-| `ahead-of-engine` | Project schema newer than this engine | Do **not** downgrade. Point `REPO_URL` at the correct/newer upstream, or accept it's already ahead. Stop. |
-| `needs-update` | Pending breaking changes (sync refused) | Expected pre-migration; proceed — `update.sh` is the migrator. If it persists *after* update, investigate. |
-| `config-missing` | No `config.yaml` | Not bootstrapped — direct user to `<umbrella>/sync/INIT.md`. Stop. |
-| `error` | Engine couldn't proceed | Show message; check `REPO_URL`. Stop. |
-| *(no status)* | Engine crashed before contract | Show full output; don't modify the tree. Stop. |
-
-On any failure code, first re-read the upstream `CHANGELOG.md` entries for `current < release <= engine` (esp. `### Breaking`) — the breaking change usually explains the error and what the user must do — before retrying or escalating.
-
-Genuinely **ambiguous** tree (e.g. both a legacy flat `<umbrella>/scripts/`
-and a populated module, no clear `sync_version`): inspect both,
-summarize the difference, ask the user which is authoritative, apply their
-choice. Never guess.
-
-### 6. Verify (always, after `ok`/`migrated`)
-
-Structural — always:
-- No `intelligence-*` directory directly under `<umbrella>/skills/`
-  (meta-skills live only in the module's `skills/`).
-- Project content intact: `<umbrella>/{rules,agents}/` and any
-  non-`intelligence-` skills untouched.
-- `config.yaml` has `sync_version` equal to the engine
-  `scripts/VERSION`, and `sources.skills` includes the module skills path
-  exactly once.
-
-Changelog-driven — per release crossed:
-- For each **`### Breaking`** item in the crossed range, verify its stated
-  post-condition actually holds (e.g. a removed/renamed file is gone, a
-  config-schema change is reflected). If a breaking item has no verifiable
-  post-condition, state that you could not auto-verify it.
-
-Then regenerate IDE outputs:
-```
-bash <umbrella>/sync/scripts/sync.sh
-```
-Relay any model-drift report. Finally summarize: versions before→after, the
-breaking changes applied, verification result, anything the user must act on.
-Clean up the temp clone.
-
-## Notes
-
-- Everything is **idempotent**. Re-running on a current project is a safe
-  no-op (`IS_STATUS=ok`).
-- Correctness rests on the engine's idempotent structural preconditions, not
-  on the version stamp — a missing/wrong `sync_version` cannot
-  cause a needed migration to be skipped; it only weakens the
-  `ahead-of-engine` guard until re-stamped.
-- Never touch `config.yaml` beyond what the engine does (the idempotent
-  `sources.skills` line and the `sync_version` key). Never
-  move/delete project skills, rules, or agents.
-- Sibling modules beside the engine module are independent — only operate on
-  the discovered engine module.
+1. Run `intelligence update --preview` (or
+   `intelligence update $ARGUMENTS --preview` for one named package). Use its
+   CLI, project, and package sections as the complete plan; do not re-resolve
+   versions independently.
+
+2. If the CLI or project engine version would change, read the authoritative
+   `CHANGELOG.md` at `https://github.com/ainova-systems/intelligence` for every
+   release in **`current < release <= target`**. If it is unavailable, stop
+   before changing versions. Turn every crossed `### Breaking` item into a
+   post-condition to verify.
+
+3. Show the plan and breaking checklist to the user. The command without a
+   mode also shows the plan and prompts; after approval, use `--apply` for an
+   unambiguous non-interactive execution.
+
+4. If the plan reports a newer global CLI, run exactly the npm command it
+   prints after approval, then rerun `intelligence update --preview` with the
+   new executable. Apply the resulting plan with `intelligence update --apply`,
+   or `intelligence update $ARGUMENTS --apply` when one package was requested.
+
+5. An applied update that renders must finish with `IS_STATUS=ok`; preserve and
+   stop on any other status. Then run `intelligence status --check`. Do not run
+   a duplicate sync after `update --apply`. Verify every crossed breaking
+   post-condition directly and report any item that cannot be machine-verified.
+
+Report versions before and after, the applied plan, post-condition results,
+and any remaining action. On a refusal, preserve the full error and stop
+instead of invoking hidden lifecycle operations.

package/cli/commands/upgrade.sh

@@ -1,68 +0,0 @@
-#!/bin/bash
-# intelligence upgrade — bring the project to this CLI's engine: apply v2
-# schema migrations, align the engine-content package to the bundled version,
-# restamp sync_version, sync.
-set -euo pipefail
-source "$CLI_DIR/lib/cli-common.sh"
-
-require_v2
-manifest="$IP_ROOT/intelligence.yaml"
-
-stamp="$(read_engine_stamp "$manifest")"
-eng="$(bundled_engine_version)"
-if [ -n "$stamp" ] && _ver_gt "$stamp" "$eng"; then
-    die "manifest schema $stamp is newer than this CLI's engine $eng — update the CLI first: npm i -g @ainova-systems/intelligence@latest"
-fi
-
-# --- v2 schema migrations -------------------------------------------------
-# The engine's own chain owns vendored layouts; this one owns the manifest.
-# Same discipline: ascending, append-only, each migration self-detects and
-# no-ops when already applied.
-
-# v2 migration 1: staged engine content -> the @ainova-systems/sync package.
-# Pre-package manifests listed `.intelligence/engine/{rules,agents,skills}`
-# as sources fed by a CLI-staged copy; that copy is now an ordinary package
-# entry seeded from the bundle. Post-condition: no `.intelligence/engine`
-# source entries, the package present in manifest+lock+store, stale dir gone.
-migrated=0
-for section in rules agents skills; do
-    while IFS= read -r src; do
-        case "$src" in
-            .intelligence/engine/*)
-                sources_remove_entry "$manifest" "$section" "$src"
-                migrated=1
-                ;;
-        esac
-    done < <(read_yaml_list "$manifest" "$section")
-done
-if [ "$migrated" -eq 1 ]; then
-    echo "  migrating: staged engine content -> $SYNC_PKG_NAME package"
-    rm -rf "$IP_ROOT/.intelligence/engine"
-    sync_pkg_entry "$manifest"
-    sync_pkg_install "$IP_ROOT"
-fi
-
-# --- steady state ---------------------------------------------------------
-# Align the engine-content package with the bundled engine. Only a manifest
-# that HAS the entry is touched — a --bare project opted out, and upgrade
-# respects that.
-have_pkg=0
-while IFS= read -r name; do
-    [ "$name" = "$SYNC_PKG_NAME" ] && have_pkg=1
-done < <(qmap_keys "$manifest" "packages")
-if [ "$have_pkg" -eq 1 ] && [ "$migrated" -eq 0 ]; then
-    pinned="$(qmap_field "$manifest" "packages" "$SYNC_PKG_NAME" "version")"
-    if [ "$pinned" != "$eng" ]; then
-        echo "  $SYNC_PKG_NAME: $pinned -> $eng"
-    fi
-    sync_pkg_entry "$manifest"
-    sync_pkg_install "$IP_ROOT"
-fi
-if [ "$have_pkg" -eq 0 ] && [ "$migrated" -eq 0 ]; then
-    echo "  NOTE: $SYNC_PKG_NAME is not in this manifest (bare setup) — engine meta-skills stay uninstalled; 'intelligence add $SYNC_PKG_NAME' opts back in." >&2
-fi
-
-stamp_version "$manifest" "$eng"
-echo "  sync_version -> $eng"
-
-exec bash "$CLI_DIR/commands/sync.sh"