Launched LoopEngine Ability System

Giving an agent a new capability was never just "add a tool." A tool without a skill teaching the agent when to reach for it is a function the model may never call correctly. A tool without an actauth rule sits behind `default_decision` and quietly does nothing the first time it's invoked. In practice, one real capability was always three separate, hand-authored artifacts — a tool file, a `SKILL.md`, and a permission rule — and nothing tied them together as one thing. Every agent that wanted the same capability re-derived all three from scratch.

A LoopEngine ability is that unit made real: a bundle of tool files, skill directories, and actauth rules, installed with one command — `loopengine add-ability <spec> --agent <name>`. `<spec>` is anything `npm pack` already understands: a public or private npm package, a scoped package on a private registry, or a plain git repo with no registry involved at all. Point it at any of those and the tools land in the agent's own `tools/` directory, the skill lands in `skills/`, and the actauth rules get appended to `actauth.yml` — all three, together, or none of them: every collision is checked before a single file is written.

That last detail — real files, written into the agent's own tree — is a deliberate choice, not an implementation shortcut. An ability doesn't get `npm install`ed as a dependency and imported at runtime. It's copied in, the same way the Admin UI's own HTTP tool builder already generates "the same class of artifact a human would have written by hand." A tool that arrived as an opaque import is a tool nobody reviewed; a tool sitting in the repo as a real `.ts` file goes through the same code review, the same diff, the same actauth governance as anything hand-written. That's the tradeoff an ability system built for agents that take consequential actions has to make differently than a plugin system built for, say, a text editor.

Copying instead of importing raises the obvious next question: what happens when the upstream ability ships a fix? `loopengine upgrade-ability` answers it with a real three-way merge — the same technique a version-control merge already uses, applied per file. If a tool's been hand-edited since install, the merge keeps the edit; if the upstream change lands on a different part of the file, both changes survive; if the same line changed on both sides, the file gets real conflict markers to resolve by hand instead of a silent overwrite in either direction. actauth rules get the same care in spirit, resolved per rule rather than as one file: a rule untouched since install updates cleanly, a rule an operator has since tightened by hand is left alone and reported, never clobbered. `remove-ability` mirrors this — a file that still matches what was installed comes out cleanly; a file that's been modified since is refused unless you say `--force`.

Abilities carry more than code, too. An ability can declare the environment variables its tools actually need — an API token, a bearer key — and once installed, those show up in the Admin UI's own Environment tab: which variables are needed, by which ability, and whether a value is set, never the value itself once it's there. Setting one updates the project's `.env` and the running process's own environment in the same step, so a tool that reads its credential fresh on every call — the same pattern the HTTP tool builder's own generated code already follows — picks it up on its very next invocation.

None of this is a new kind of trust an operator has to extend. It's the same actauth-gated, review-everything posture LoopEngine already has for a hand-written tool, just no longer something every agent has to rebuild alone. The gap an agent hits — a missing integration, a capability another team already built — closes by installing something real and reviewable, not by importing something opaque.