loopengine 0.1.22 → 0.1.27

package/dist/bin/cli.js

@@ -13,7 +13,7 @@ import { access, mkdir, readFile, writeFile } from 'node:fs/promises';
 import { spawn } from 'node:child_process';
 import path from 'node:path';
 import { fileURLToPath } from 'node:url';
-import { installPackage, upgradePackage, removePackage } from './package-manager.js';
+import { installAbility, upgradeAbility, removeAbility } from './ability-manager.js';
 const NAME_PATTERN = /^[a-z0-9]+(-[a-z0-9]+)*$/;
 export class AgentNameError extends Error {
 }
@@ -231,7 +231,7 @@ async function requireAdapterFile(relPath) {
     process.exitCode = 1;
     return false;
 }
-// Shared by add-package/upgrade-package/remove-package below — pulls a
+// Shared by add-ability/upgrade-ability/remove-ability below — pulls a
 // `--flag value` pair out of argv, same inline style `run`'s own
 // `--input` handling already uses, factored out only because three
 // commands need the identical `--agent <name>` extraction (a single use
@@ -301,22 +301,22 @@ async function main() {
         console.log(`Run the top-level agent: npx tsx adapters/cli.ts --agent ${parent.split('/')[0]} "hello"`);
         return;
     }
-    // Installs a loopengine package (see PACKAGES.md) — a bundle of tool
+    // Installs a loopengine ability (see ABILITIES.md) — a bundle of tool
     // files, skill directories, and actauth rules published as an ordinary
     // npm package (public, private-registry, git, or a local file: path),
     // copied into the target agent's own tree rather than added as a
-    // node_modules import (see package-manager.ts's own header comment for
+    // node_modules import (see ability-manager.ts's own header comment for
     // why). <spec> is whatever `npm pack` itself accepts.
-    if (command === 'add-package') {
+    if (command === 'add-ability') {
         const { value: agent, rest: withoutAgent } = extractFlagValue(rest, '--agent');
         const [spec] = withoutAgent;
         if (!spec || !agent) {
-            console.error('Usage: loopengine add-package <spec> --agent <name>');
+            console.error('Usage: loopengine add-ability <spec> --agent <name>');
             process.exitCode = 1;
             return;
         }
         try {
-            const { installed } = await installPackage(agent, spec);
+            const { installed } = await installAbility(agent, spec);
             console.log(`Installed into agents/${agent}/:`);
             for (const p of installed)
                 console.log(`  ${p}`);
@@ -330,23 +330,23 @@ async function main() {
         }
         return;
     }
-    // Pulls in whatever <packageName> (or --spec, if the package moved)
+    // Pulls in whatever <abilityName> (or --spec, if the ability moved)
     // currently resolves to, three-way-merging each tool/skill file it
     // manages against what changed upstream since install — a hand-edit
     // survives a clean merge; a real conflict leaves <<<<<<< markers to
     // resolve by hand, same as create-loopengine upgrade already does for
     // template files.
-    if (command === 'upgrade-package') {
+    if (command === 'upgrade-ability') {
         const { value: agent, rest: withoutAgent } = extractFlagValue(rest, '--agent');
         const { value: spec, rest: withoutSpec } = extractFlagValue(withoutAgent, '--spec');
-        const [packageName] = withoutSpec;
-        if (!packageName || !agent) {
-            console.error('Usage: loopengine upgrade-package <packageName> --agent <name> [--spec <spec>]');
+        const [abilityName] = withoutSpec;
+        if (!abilityName || !agent) {
+            console.error('Usage: loopengine upgrade-ability <abilityName> --agent <name> [--spec <spec>]');
             process.exitCode = 1;
             return;
         }
         try {
-            const { files } = await upgradePackage(agent, packageName, spec ? { spec } : {});
+            const { files } = await upgradeAbility(agent, abilityName, spec ? { spec } : {});
             for (const f of files)
                 console.log(`  ${f.status.padEnd(9)}${f.path}`);
             const conflicts = files.filter((f) => f.status === 'conflict');
@@ -358,20 +358,20 @@ async function main() {
         }
         return;
     }
-    // Removes a package's tool/skill files and actauth rules — refuses a
+    // Removes an ability's tool/skill files and actauth rules — refuses a
     // file whose content no longer matches what was recorded at
     // install/last-upgrade (a hand-edit since) unless --force is given.
-    if (command === 'remove-package') {
+    if (command === 'remove-ability') {
         const { value: agent, rest: withoutAgent } = extractFlagValue(rest, '--agent');
         const { present: force, rest: withoutForce } = extractFlagPresence(withoutAgent, '--force');
-        const [packageName] = withoutForce;
-        if (!packageName || !agent) {
-            console.error('Usage: loopengine remove-package <packageName> --agent <name> [--force]');
+        const [abilityName] = withoutForce;
+        if (!abilityName || !agent) {
+            console.error('Usage: loopengine remove-ability <abilityName> --agent <name> [--force]');
             process.exitCode = 1;
             return;
         }
         try {
-            const { removed, refused } = removePackage(agent, packageName, force);
+            const { removed, refused } = removeAbility(agent, abilityName, force);
             for (const p of removed)
                 console.log(`  removed  ${p}`);
             for (const p of refused)
@@ -463,9 +463,9 @@ async function main() {
     }
     console.error('Usage: loopengine add-agent <name>');
     console.error('       loopengine add-subagent <parent> <name>');
-    console.error('       loopengine add-package <spec> --agent <name>');
-    console.error('       loopengine upgrade-package <packageName> --agent <name> [--spec <spec>]');
-    console.error('       loopengine remove-package <packageName> --agent <name> [--force]');
+    console.error('       loopengine add-ability <spec> --agent <name>');
+    console.error('       loopengine upgrade-ability <abilityName> --agent <name> [--spec <spec>]');
+    console.error('       loopengine remove-ability <abilityName> --agent <name> [--force]');
     console.error('       loopengine run <agent> [--session <id>] "<message>"');
     console.error('       loopengine serve');
     console.error('       loopengine dev');

package/dist/web/agents-config-page.js

@@ -1110,9 +1110,9 @@ export const agentsConfigPageHtml = `<!doctype html>
       });
   }
 
-  // ---- Environment tab: every env var a package (see PACKAGES.md,
-  // bin/package-manager.ts) declared it needs for this agent, across
-  // every package installed — status only, a value is never shown once
+  // ---- Environment tab: every env var an ability (see ABILITIES.md,
+  // bin/ability-manager.ts) declared it needs for this agent, across
+  // every ability installed — status only, a value is never shown once
   // set, matching env-admin.ts's own never-echo-a-secret rule. Lazily
   // loaded the same way Actauth is, for the same reason (avoid a
   // redundant fetch on every agent switch for a tab that isn't always
@@ -1123,10 +1123,19 @@ export const agentsConfigPageHtml = `<!doctype html>
   }
 
   function renderEnvRow(v) {
+    // More than one ability declaring the same name doesn't get resolved
+    // here — there's one .env per project, so both read whatever single
+    // value ends up set, whether that's actually correct or a coincidence
+    // (see env-admin.ts's own doc comment). Listing every ability instead
+    // of just the first one seen at least makes that visible to whoever's
+    // looking, instead of silently hiding all but one.
+    var sharedNote = v.abilityNames.length > 1
+      ? ' <span class="hint" title="More than one installed ability declares this name — there is only one value for it project-wide, so check whether they actually need the same one.">(shared)</span>'
+      : '';
     return '<tr>' +
       '<td><code>' + escapeHtml(v.name) + '</code></td>' +
       '<td>' + escapeHtml(v.description || '') + '</td>' +
-      '<td class="hint">' + escapeHtml(v.packageName) + '</td>' +
+      '<td class="hint">' + escapeHtml(v.abilityNames.join(', ')) + sharedNote + '</td>' +
       '<td>' + (v.set ? '<span class="hint">set</span>' : '<span class="error">not set</span>') + '</td>' +
       '<td><form class="add-source env-var-form" data-name="' + escapeHtml(v.name) + '">' +
         '<input type="' + (v.secret ? 'password' : 'text') + '" name="value" placeholder="' + (v.set ? 'unchanged unless you type a new value' : 'value') + '" required>' +
@@ -1136,9 +1145,9 @@ export const agentsConfigPageHtml = `<!doctype html>
   }
 
   function renderEnvConfigHtml(vars) {
-    if (!vars.length) return '<p class="hint">No installed package has declared any environment variables for this agent yet.</p>';
+    if (!vars.length) return '<p class="hint">No installed ability has declared any environment variables for this agent yet.</p>';
     var rows = vars.map(renderEnvRow).join('');
-    return '<table><thead><tr><th>Name</th><th>Description</th><th>Package</th><th>Status</th><th>Set value</th></tr></thead><tbody>' + rows + '</tbody></table>';
+    return '<table><thead><tr><th>Name</th><th>Description</th><th>Required by</th><th>Status</th><th>Set value</th></tr></thead><tbody>' + rows + '</tbody></table>';
   }
 
   function envContentEl() {

package/dist/web/env-admin.d.ts

@@ -4,22 +4,41 @@ export interface DeclaredEnvVar {
     name: string;
     description?: string;
     secret: boolean;
-    packageName: string;
+    /** Every ability that declares this name, in install order — usually
+     * one, but see listDeclaredEnvVars's own doc comment for why this is
+     * an array, not a single name. */
+    abilityNames: string[];
     set: boolean;
 }
-/** Every env var any package installed for `agentName` declared it
- * needs, deduplicated by name — PACKAGES.md's own open question on
- * cross-package name collisions applies here too (one .env per
- * *project*, not per agent, so two unrelated packages declaring the
- * same name can't actually be told apart; the first one seen wins the
- * description shown). `set` is read live off `process.env`, not cached,
- * so it reflects whatever the last `setEnvVar` call — or a plain
- * restart picking up `.env` — actually did. */
+/** Every env var any ability installed for `agentName` declared it
+ * needs, merged by name. There's one .env per *project*, not per agent
+ * or per ability, so this can't actually resolve a genuine cross-ability
+ * name collision (two abilities declaring, say, "API_KEY" for two
+ * unrelated services still both read whichever single value ends up
+ * set — there is no per-ability slot to give them) — unlike a tool or
+ * skill name collision (see ability-manager.ts's namespacedToolName/
+ * namespacedSkillId), an env var name is a literal `process.env.X`
+ * reference baked into the ability's own code, not a label loopengine's
+ * own generated glue controls, so there's nothing here to safely rename.
+ * What this *can* do, and used to not: surface every ability that
+ * declares a given name (`abilityNames`, plural) instead of silently
+ * keeping only the first one seen and hiding the rest — turns a
+ * collision from invisible into something a human looking at the
+ * Environment tab can actually notice and judge (a real conflict
+ * needing one ability's own env var renamed, or a coincidence that's
+ * actually fine because both intentionally share one real credential).
+ * `secret` is true if *any* declaring ability marked it secret — the
+ * safer default, since treating a real secret as non-secret because a
+ * different ability's own declaration happened to be checked first
+ * would be the one direction genuinely worth avoiding. `set` is read
+ * live off `process.env`, not cached, so it reflects whatever the last
+ * `setEnvVar` call — or a plain restart picking up `.env` — actually
+ * did. */
 export declare function listDeclaredEnvVars(agentName: string): DeclaredEnvVar[];
 /** Upserts `NAME=VALUE` into the project's `.env` file — preserving
  * every other line (comments, blank lines, unrelated keys) — and
  * applies it to *this* running process immediately via `process.env`,
- * so a newly-installed package's tools work without a restart. Callers
+ * so a newly-installed ability's tools work without a restart. Callers
  * (the PUT route in adapters/http.ts) are responsible for refusing to
  * call this at all when `LOOPENGINE_ADMIN_AUTH` isn't set — this
  * function itself has no notion of HTTP auth, it just writes. */

package/dist/web/env-admin.js

@@ -1,6 +1,6 @@
-// Backs the Admin UI's "Environment" section — every env var a package
-// (see PACKAGES.md, bin/package-manager.ts) declared as required,
-// across every package installed for an agent, with set/not-set status
+// Backs the Admin UI's "Environment" section — every env var an ability
+// (see ABILITIES.md, bin/ability-manager.ts) declared as required,
+// across every ability installed for an agent, with set/not-set status
 // only. A value marked `secret` is never echoed back once set — same
 // never-echo-a-secret rule web/http-tool-admin.ts's own `{{ENV_VAR}}`
 // header handling already establishes for a tool's own secrets.
@@ -13,38 +13,56 @@ export class EnvVarNameError extends Error {
 // validates a {{ENV_VAR}} header reference against.
 const ENV_VAR_NAME_PATTERN = /^[A-Z_][A-Z0-9_]*$/;
 function provenancePath(agentName) {
-    return join(agentDir(agentName), '.loopengine-packages.json');
+    return join(agentDir(agentName), '.loopengine-abilities.json');
 }
-/** Every env var any package installed for `agentName` declared it
- * needs, deduplicated by name — PACKAGES.md's own open question on
- * cross-package name collisions applies here too (one .env per
- * *project*, not per agent, so two unrelated packages declaring the
- * same name can't actually be told apart; the first one seen wins the
- * description shown). `set` is read live off `process.env`, not cached,
- * so it reflects whatever the last `setEnvVar` call — or a plain
- * restart picking up `.env` — actually did. */
+/** Every env var any ability installed for `agentName` declared it
+ * needs, merged by name. There's one .env per *project*, not per agent
+ * or per ability, so this can't actually resolve a genuine cross-ability
+ * name collision (two abilities declaring, say, "API_KEY" for two
+ * unrelated services still both read whichever single value ends up
+ * set — there is no per-ability slot to give them) — unlike a tool or
+ * skill name collision (see ability-manager.ts's namespacedToolName/
+ * namespacedSkillId), an env var name is a literal `process.env.X`
+ * reference baked into the ability's own code, not a label loopengine's
+ * own generated glue controls, so there's nothing here to safely rename.
+ * What this *can* do, and used to not: surface every ability that
+ * declares a given name (`abilityNames`, plural) instead of silently
+ * keeping only the first one seen and hiding the rest — turns a
+ * collision from invisible into something a human looking at the
+ * Environment tab can actually notice and judge (a real conflict
+ * needing one ability's own env var renamed, or a coincidence that's
+ * actually fine because both intentionally share one real credential).
+ * `secret` is true if *any* declaring ability marked it secret — the
+ * safer default, since treating a real secret as non-secret because a
+ * different ability's own declaration happened to be checked first
+ * would be the one direction genuinely worth avoiding. `set` is read
+ * live off `process.env`, not cached, so it reflects whatever the last
+ * `setEnvVar` call — or a plain restart picking up `.env` — actually
+ * did. */
 export function listDeclaredEnvVars(agentName) {
     const path = provenancePath(agentName);
     if (!existsSync(path))
         return [];
     const provenance = JSON.parse(readFileSync(path, 'utf8'));
-    const seen = new Set();
-    const result = [];
-    for (const [packageName, record] of Object.entries(provenance)) {
+    const byName = new Map();
+    for (const [abilityName, record] of Object.entries(provenance)) {
         for (const decl of record.env) {
-            if (seen.has(decl.name))
+            const existing = byName.get(decl.name);
+            if (existing) {
+                existing.abilityNames.push(abilityName);
+                existing.secret = existing.secret || decl.secret === true;
                 continue;
-            seen.add(decl.name);
-            result.push({
+            }
+            byName.set(decl.name, {
                 name: decl.name,
                 description: decl.description,
                 secret: decl.secret === true,
-                packageName,
+                abilityNames: [abilityName],
                 set: process.env[decl.name] !== undefined,
             });
         }
     }
-    return result;
+    return [...byName.values()];
 }
 // process.cwd(), matching exactly where bin/cli.ts's own runTsx passes
 // --env-file-if-exists=.env (Node's own --env-file resolves relative to
@@ -68,7 +86,7 @@ function serializeEnvValue(value) {
 /** Upserts `NAME=VALUE` into the project's `.env` file — preserving
  * every other line (comments, blank lines, unrelated keys) — and
  * applies it to *this* running process immediately via `process.env`,
- * so a newly-installed package's tools work without a restart. Callers
+ * so a newly-installed ability's tools work without a restart. Callers
  * (the PUT route in adapters/http.ts) are responsible for refusing to
  * call this at all when `LOOPENGINE_ADMIN_AUTH` isn't set — this
  * function itself has no notion of HTTP auth, it just writes. */

package/dist/web/http-tool-admin.d.ts

@@ -37,18 +37,29 @@ export interface HttpToolSpec {
     safe?: boolean;
 }
 export declare function toCamelCase(snakeCase: string): string;
-export declare function addToolToIndex(toolsIndexPath: string, toolFileName: string, exportName: string): void;
-/** addToolToIndex's own undo — removes the named tool's import line and
- * array entry. Best-effort, not "refuse rather than guess" like
- * addToolToIndex: this only ever runs against a tool package-manager.ts
- * itself installed (so the exact shape addToolToIndex wrote is known),
- * and the caller (removePackage) has already deleted the tool's .ts
- * file — leaving a stale entry behind, the previous behavior, means a
- * dangling import that fails the next build, which is strictly worse
- * than a no-op here if the file turns out not to match (hand-edited
- * since). No-ops (rather than throwing) when the file is missing
- * entirely, or the expected import/array-entry shape isn't found. */
-export declare function removeToolFromIndex(toolsIndexPath: string, toolFileName: string, exportName: string): void;
+export declare function addToolToIndex(toolsIndexPath: string, toolFileName: string, importSpecifier: string, arrayExpression?: string, preamble?: string): void;
+/** addToolToIndex's own undo — removes the named tool's import line,
+ * wrapper `const` (if a namespaced install added one), and array entry.
+ * Best-effort, not "refuse rather than guess" like addToolToIndex: this
+ * only ever runs against a tool ability-manager.ts itself installed (so
+ * the exact shape addToolToIndex wrote is known), and the caller
+ * (removeAbility) has already deleted the tool's .ts file — leaving a
+ * stale entry behind, the previous behavior, means a dangling import
+ * that fails the next build, which is strictly worse than a no-op here
+ * if the file turns out not to match (hand-edited since). No-ops (rather
+ * than throwing) when the file is missing entirely, or the expected
+ * import/array-entry shape isn't found.
+ *
+ * `arrayExpression` (not the raw import specifier) — same value
+ * addToolToIndex's own `arrayExpression` was called with, since that's
+ * what actually appears in the array literal and (for a namespaced
+ * install) names the wrapper `const` too. The import line is matched by
+ * `toolFileName` alone, not by the exact imported binding: a namespaced
+ * install aliases its import (`X as Y`), so matching on the file path —
+ * which uniquely identifies this one tool either way — is what makes
+ * this work for both shapes without the caller having to say which one
+ * it originally was. */
+export declare function removeToolFromIndex(toolsIndexPath: string, toolFileName: string, arrayExpression: string): void;
 /** Generates agents/<agentName>/tools/<spec.name>.ts, registers it in
  * that agent's tools/index.ts, then imports the file it just wrote and
  * returns the real, callable ToolDefinition object — so the route

package/dist/web/http-tool-admin.js

@@ -179,20 +179,36 @@ ${responseHandling}  },
 // across every real example in this repo (agents/customer-service/
 // tools/index.ts, create-loopengine's own template) — a handful of
 // named imports, then one `export const tools: ToolDefinition[] = [...]`
-// array literal. This patches that exact shape with two small string
-// edits (one new import line, one new array entry) rather than a full
-// TS-AST rewrite; if the file has been hand-edited into something this
-// pattern doesn't recognize, it refuses instead of risking corrupting it
-// — same "refuse rather than guess" discipline agent-file-admin.ts's own
-// doc comment already establishes for index.ts edits.
-export function addToolToIndex(toolsIndexPath, toolFileName, exportName) {
+// array literal. This patches that exact shape with small string edits
+// (one new import line, one new array entry, and — only for a namespaced
+// ability install, see ability-manager.ts's namespacedToolName — one
+// `const` line between them) rather than a full TS-AST rewrite; if the
+// file has been hand-edited into something this pattern doesn't
+// recognize, it refuses instead of risking corrupting it — same "refuse
+// rather than guess" discipline agent-file-admin.ts's own doc comment
+// already establishes for index.ts edits.
+//
+// `importSpecifier` and `arrayExpression` are deliberately separate
+// parameters, not always the same string: the common case (this
+// function's only caller until ability-manager.ts's own namespacing)
+// has them identical (a bare `import { X }`, then bare `X` in the
+// array), but a namespaced tool install needs an *aliased* import (two
+// abilities' own files can both export a same-named top-level `const` —
+// e.g. both literally `webSearch` — which would collide as two
+// identically-named imports in this one file even though the source
+// files differ) feeding into a small wrapper `const` that overrides the
+// object's own `name` field (aliasing the import only renames the JS
+// binding, never the `ToolDefinition.name` string the model actually
+// calls by) — `preamble` is that wrapper line, and `arrayExpression` is
+// its name, not the raw import's.
+export function addToolToIndex(toolsIndexPath, toolFileName, importSpecifier, arrayExpression = importSpecifier, preamble) {
     const source = readFileSync(toolsIndexPath, 'utf8');
     const arrayMatch = source.match(/export const tools: ToolDefinition\[\] = \[([^\]]*)\]/);
     if (!arrayMatch) {
         throw new HttpToolIndexShapeError(`${toolsIndexPath} doesn't match the expected "export const tools: ToolDefinition[] = [...]" shape — add this tool to it by hand instead.`);
     }
-    // Idempotent — a caller that adds the same tool twice (e.g. package-
-    // manager.ts's removePackage not having cleaned up this same file
+    // Idempotent — a caller that adds the same tool twice (e.g. ability-
+    // manager.ts's removeAbility not having cleaned up this same file
     // before a re-add, or simply calling this twice by mistake) gets a
     // no-op the second time instead of a duplicate `import { X }`
     // declaration, which is a TypeScript syntax error ("Duplicate
@@ -201,40 +217,54 @@ export function addToolToIndex(toolsIndexPath, toolFileName, exportName) {
         .split(',')
         .map((e) => e.trim())
         .filter(Boolean);
-    if (arrayEntries.includes(exportName))
+    if (arrayEntries.includes(arrayExpression))
         return;
-    const importLine = `import { ${exportName} } from './${toolFileName}.js'\n`;
+    const importLine = `import { ${importSpecifier} } from './${toolFileName}.js'\n`;
     const lastImportMatch = [...source.matchAll(/^import .+\n/gm)].pop();
     const insertAt = lastImportMatch ? lastImportMatch.index + lastImportMatch[0].length : 0;
-    const withImport = source.slice(0, insertAt) + importLine + source.slice(insertAt);
-    const newEntries = [...arrayEntries, exportName].join(', ');
+    const preambleBlock = preamble ? `${preamble}\n` : '';
+    const withImport = source.slice(0, insertAt) + importLine + preambleBlock + source.slice(insertAt);
+    const newEntries = [...arrayEntries, arrayExpression].join(', ');
     const withEntry = withImport.replace(/export const tools: ToolDefinition\[\] = \[([^\]]*)\]/, `export const tools: ToolDefinition[] = [${newEntries}]`);
     writeFileSync(toolsIndexPath, withEntry);
 }
-/** addToolToIndex's own undo — removes the named tool's import line and
- * array entry. Best-effort, not "refuse rather than guess" like
- * addToolToIndex: this only ever runs against a tool package-manager.ts
- * itself installed (so the exact shape addToolToIndex wrote is known),
- * and the caller (removePackage) has already deleted the tool's .ts
- * file — leaving a stale entry behind, the previous behavior, means a
- * dangling import that fails the next build, which is strictly worse
- * than a no-op here if the file turns out not to match (hand-edited
- * since). No-ops (rather than throwing) when the file is missing
- * entirely, or the expected import/array-entry shape isn't found. */
-export function removeToolFromIndex(toolsIndexPath, toolFileName, exportName) {
+/** addToolToIndex's own undo — removes the named tool's import line,
+ * wrapper `const` (if a namespaced install added one), and array entry.
+ * Best-effort, not "refuse rather than guess" like addToolToIndex: this
+ * only ever runs against a tool ability-manager.ts itself installed (so
+ * the exact shape addToolToIndex wrote is known), and the caller
+ * (removeAbility) has already deleted the tool's .ts file — leaving a
+ * stale entry behind, the previous behavior, means a dangling import
+ * that fails the next build, which is strictly worse than a no-op here
+ * if the file turns out not to match (hand-edited since). No-ops (rather
+ * than throwing) when the file is missing entirely, or the expected
+ * import/array-entry shape isn't found.
+ *
+ * `arrayExpression` (not the raw import specifier) — same value
+ * addToolToIndex's own `arrayExpression` was called with, since that's
+ * what actually appears in the array literal and (for a namespaced
+ * install) names the wrapper `const` too. The import line is matched by
+ * `toolFileName` alone, not by the exact imported binding: a namespaced
+ * install aliases its import (`X as Y`), so matching on the file path —
+ * which uniquely identifies this one tool either way — is what makes
+ * this work for both shapes without the caller having to say which one
+ * it originally was. */
+export function removeToolFromIndex(toolsIndexPath, toolFileName, arrayExpression) {
     if (!existsSync(toolsIndexPath))
         return;
-    const source = readFileSync(toolsIndexPath, 'utf8');
-    const importLineRe = new RegExp(`^import \\{ ${exportName} \\} from '\\./${toolFileName}\\.js'\\n`, 'm');
-    const withoutImport = source.replace(importLineRe, '');
-    const arrayMatch = withoutImport.match(/export const tools: ToolDefinition\[\] = \[([^\]]*)\]/);
+    let source = readFileSync(toolsIndexPath, 'utf8');
+    const importLineRe = new RegExp(`^import \\{ [^}]+ \\} from '\\./${toolFileName}\\.js'\\n`, 'm');
+    source = source.replace(importLineRe, '');
+    const preambleRe = new RegExp(`^const ${arrayExpression}: ToolDefinition = \\{[^\\n]*\\}\\n`, 'm');
+    source = source.replace(preambleRe, '');
+    const arrayMatch = source.match(/export const tools: ToolDefinition\[\] = \[([^\]]*)\]/);
     if (!arrayMatch)
         return;
     const remainingEntries = arrayMatch[1]
         .split(',')
         .map((e) => e.trim())
-        .filter((e) => e && e !== exportName);
-    const withEntry = withoutImport.replace(/export const tools: ToolDefinition\[\] = \[([^\]]*)\]/, `export const tools: ToolDefinition[] = [${remainingEntries.join(', ')}]`);
+        .filter((e) => e && e !== arrayExpression);
+    const withEntry = source.replace(/export const tools: ToolDefinition\[\] = \[([^\]]*)\]/, `export const tools: ToolDefinition[] = [${remainingEntries.join(', ')}]`);
     writeFileSync(toolsIndexPath, withEntry);
 }
 // The spec is persisted alongside the generated .ts file, under the same

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "loopengine",
-  "version": "0.1.22",
+  "version": "0.1.27",
   "type": "module",
   "description": "Runtime for tool-using AI agents with a transparent ReAct loop.",
   "license": "MIT",
@@ -23,8 +23,8 @@
     "dist/index.d.ts",
     "dist/bin/cli.js",
     "dist/bin/cli.d.ts",
-    "dist/bin/package-manager.js",
-    "dist/bin/package-manager.d.ts",
+    "dist/bin/ability-manager.js",
+    "dist/bin/ability-manager.d.ts",
     "dist/core/run-agent.js",
     "dist/core/run-agent.d.ts",
     "dist/core/loop-events.js",