loopengine 0.1.13 → 0.1.15

package/dist/bin/package-manager.d.ts

@@ -29,6 +29,14 @@ export interface PackageManifest {
  * same role .create-loopengine.json already plays for template files. */
 export interface InstalledPackageRecord {
     version: string;
+    /** The exact spec (bare registry name, "name@version", a git+ssh/
+     * git+https URL with a #committish, a file: path, ...) last used to
+     * successfully install or upgrade this package — see
+     * oldContentSpec's own doc comment for why upgradePackage needs this
+     * stored verbatim rather than reconstructed from `packageName`.
+     * Optional only because a package installed before this field existed
+     * has no recorded value — see oldContentSpec's own fallback. */
+    spec?: string;
     tools: string[];
     skills: string[];
     actauthRules: string[];
@@ -99,14 +107,14 @@ export interface UpgradeFileResult {
  * to `packageName`, i.e. "latest") currently resolves to. Tool and skill
  * files get a real three-way merge (mine = current file, possibly
  * hand-edited since install; base = the version recorded at
- * install/last-upgrade, refetched via `<spec>@<oldVersion>`; theirs =
- * newly fetched) — identical technique to `create-loopengine upgrade`,
- * just applied to package-managed files instead of template files.
- * actauth rules upgrade per-rule instead: the target actauth.yml holds
- * rules from other packages and hand-written ones too, so there's no
- * coherent "whole file" base/theirs to merge — a rule unchanged since
- * install updates cleanly; a hand-edited one is left alone and reported
- * as a conflict rather than overwritten. */
+ * install/last-upgrade, refetched via oldContentSpec; theirs = newly
+ * fetched) — identical technique to `create-loopengine upgrade`, just
+ * applied to package-managed files instead of template files. actauth
+ * rules upgrade per-rule instead: the target actauth.yml holds rules
+ * from other packages and hand-written ones too, so there's no coherent
+ * "whole file" base/theirs to merge — a rule unchanged since install
+ * updates cleanly; a hand-edited one is left alone and reported as a
+ * conflict rather than overwritten. */
 export declare function upgradePackage(agentName: string, packageName: string, options?: FetchOptions & {
     spec?: string;
 }): Promise<{

package/dist/bin/package-manager.js

@@ -24,7 +24,7 @@ import { tmpdir } from 'node:os';
 import { parse as parseYaml } from 'yaml';
 import semver from 'semver';
 import { agentDir } from '../core/gateway-tools.js';
-import { addToolToIndex, toCamelCase } from '../web/http-tool-admin.js';
+import { addToolToIndex, removeToolFromIndex, toCamelCase } from '../web/http-tool-admin.js';
 import { addActauthRule, updateActauthRule, removeActauthRule, readActauthConfig } from '../web/actauth-admin.js';
 export class PackageManifestError extends Error {
 }
@@ -283,6 +283,7 @@ export async function installPackage(agentName, spec, options = {}) {
     }
     provenance[manifest.name] = {
         version: manifest.version,
+        spec,
         tools: toolNames,
         skills: skillIds,
         actauthRules: rules.map((r) => r.name),
@@ -321,18 +322,53 @@ function mergeFile(mine, base, theirs) {
     rmSync(scratchDir, { recursive: true, force: true });
     return { merged, conflicted };
 }
+// A git+ssh/git+https/git: URL, a plain https: tarball URL, or a local
+// file:/relative/absolute path all already pin to exact, immutable
+// content on their own (a #committish, or the file/tarball's own
+// content) — appending "@version" to one of these doesn't select an
+// older version the way it does for a registry specifier, it corrupts
+// the spec. Confirmed live: `npm pack 'git+file://...#v1.0.0@1.0.0'`
+// fails outright ("The git reference could not be found... pathspec
+// 'v1.0.0@1.0.0'"), it doesn't fall back to resolving just the tag.
+const PINNED_SPEC = /^(git\+|git:|https?:|file:|\.\.?\/|\/)/;
+/** What to fetch to reconstruct the exact content that was installed or
+ * last upgraded to, for use as the three-way merge's `base` — as
+ * distinct from `spec`, which is what the *new* content resolves to.
+ * A plain registry specifier (bare or scoped name, with or without its
+ * own "@version") is repinned to `version` — the manifest's own
+ * declared version at that install/upgrade, which is what actually got
+ * written to disk, regardless of whether the range originally given
+ * would still resolve there today. A git/file/URL spec is returned
+ * as-is — see PINNED_SPEC's own doc comment for why appending "@version"
+ * to one of those breaks instead of pinning. `recordedSpec` is only
+ * absent for a package installed before InstalledPackageRecord.spec
+ * existed; falling back to `packageName` there reproduces this
+ * function's own old (buggy for a git/file install) behavior exactly —
+ * no worse than before, and only for a package that hasn't upgraded
+ * since. */
+function oldContentSpec(recordedSpec, packageName, version) {
+    const base = recordedSpec ?? packageName;
+    if (PINNED_SPEC.test(base))
+        return base;
+    // Strip any version/tag the spec already carries (a scoped name's own
+    // leading '@' isn't this — only a second '@' after the name is) before
+    // repinning, so re-upgrading an already-version-pinned install doesn't
+    // produce a doubled-up "name@1.0.0@1.0.0".
+    const bareName = base.startsWith('@') ? `@${base.slice(1).split('@')[0]}` : base.split('@')[0];
+    return `${bareName}@${version}`;
+}
 /** Upgrades an already-installed package to whatever `spec` (defaulting
  * to `packageName`, i.e. "latest") currently resolves to. Tool and skill
  * files get a real three-way merge (mine = current file, possibly
  * hand-edited since install; base = the version recorded at
- * install/last-upgrade, refetched via `<spec>@<oldVersion>`; theirs =
- * newly fetched) — identical technique to `create-loopengine upgrade`,
- * just applied to package-managed files instead of template files.
- * actauth rules upgrade per-rule instead: the target actauth.yml holds
- * rules from other packages and hand-written ones too, so there's no
- * coherent "whole file" base/theirs to merge — a rule unchanged since
- * install updates cleanly; a hand-edited one is left alone and reported
- * as a conflict rather than overwritten. */
+ * install/last-upgrade, refetched via oldContentSpec; theirs = newly
+ * fetched) — identical technique to `create-loopengine upgrade`, just
+ * applied to package-managed files instead of template files. actauth
+ * rules upgrade per-rule instead: the target actauth.yml holds rules
+ * from other packages and hand-written ones too, so there's no coherent
+ * "whole file" base/theirs to merge — a rule unchanged since install
+ * updates cleanly; a hand-edited one is left alone and reported as a
+ * conflict rather than overwritten. */
 export async function upgradePackage(agentName, packageName, options = {}) {
     const fetch = options.fetchPackageDir ?? fetchPackageDir;
     const provenance = readProvenance(agentName);
@@ -341,7 +377,7 @@ export async function upgradePackage(agentName, packageName, options = {}) {
         throw new PackageNotInstalledError(`Package '${packageName}' isn't installed for '${agentName}'.`);
     }
     const spec = options.spec ?? packageName;
-    const oldDir = fetch(`${spec}@${record.version}`);
+    const oldDir = fetch(oldContentSpec(record.spec, packageName, record.version));
     const newDir = fetch(spec);
     const oldManifest = readManifest(oldDir);
     const newManifest = readManifest(newDir);
@@ -416,7 +452,7 @@ export async function upgradePackage(agentName, packageName, options = {}) {
         updateActauthRule(agentName, ruleName, { scope: newRule.scope, tool: newRule.tool, decision: newRule.decision });
         results.push({ path, status: 'updated' });
     }
-    provenance[packageName] = { ...record, version: newManifest.version, contentHashes: newContentHashes, env: newManifest.env ?? record.env };
+    provenance[packageName] = { ...record, version: newManifest.version, spec, contentHashes: newContentHashes, env: newManifest.env ?? record.env };
     writeProvenance(agentName, provenance);
     return { files: results };
 }
@@ -448,6 +484,7 @@ export function removePackage(agentName, packageName, force = false) {
     const refused = [];
     const remainingTools = [];
     const remainingSkills = [];
+    const toolsIndexPath = join(agentDir(agentName), 'tools', 'index.ts');
     for (const toolName of record.tools) {
         const relPath = `tools/${toolName}.ts`;
         const fullPath = join(agentDir(agentName), relPath);
@@ -457,6 +494,14 @@ export function removePackage(agentName, packageName, force = false) {
             continue;
         }
         rmSync(fullPath, { force: true });
+        // Undoes installPackage's own addToolToIndex call — without this, a
+        // deleted tool's import survives in tools/index.ts, and either fails
+        // the next build (a dangling import to a file that no longer exists)
+        // or, worse, silently duplicates on a later add-package of the same
+        // tool (addToolToIndex used to have no idempotence check at all —
+        // now it does, but this is the actual fix: the stale entry shouldn't
+        // be there to begin with).
+        removeToolFromIndex(toolsIndexPath, toolName, toCamelCase(toolName));
         removed.push(relPath);
     }
     for (const skillId of record.skills) {

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

@@ -38,6 +38,17 @@ export interface HttpToolSpec {
 }
 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;
 /** 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

@@ -191,15 +191,52 @@ export function addToolToIndex(toolsIndexPath, toolFileName, exportName) {
     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
+    // 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
+    // identifier"), not just a harmless extra line.
+    const arrayEntries = arrayMatch[1]
+        .split(',')
+        .map((e) => e.trim())
+        .filter(Boolean);
+    if (arrayEntries.includes(exportName))
+        return;
     const importLine = `import { ${exportName} } 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 existingEntries = arrayMatch[1].trim();
-    const newEntries = existingEntries ? `${existingEntries}, ${exportName}` : exportName;
+    const newEntries = [...arrayEntries, exportName].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) {
+    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\[\] = \[([^\]]*)\]/);
+    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(', ')}]`);
+    writeFileSync(toolsIndexPath, withEntry);
+}
 // The spec is persisted alongside the generated .ts file, under the same
 // name — this is what lets the Tools tab's Edit button repopulate the
 // form later without reverse-parsing generated code back into a spec,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "loopengine",
-  "version": "0.1.13",
+  "version": "0.1.15",
   "type": "module",
   "description": "Runtime for tool-using AI agents with a transparent ReAct loop.",
   "license": "MIT",