Ankita v2.7.0: undo for destructive actions — and skill permissions that advise, not enforce

Ankita is my open-source personal AI companion for the desktop — a little companion, a lot more possible. It runs locally, it uses your models, and it does real things on your machine: editing files, moving them, deleting them. That last part is why v2.7.0, released today, is built around one question I keep coming back to: when your companion deletes a file, what should save you — a permission prompt beforehand, or an undo afterwards?

v2.7.0's answer is both, but deliberately uneven. And the uneven part is the decision I want to argue about.

Undo first: destructive actions get a way back

Before this release, a delete was a delete. Now destructive actions keep an undo copy under .ankita_backups, and a restore_file tool brings the original back. move_file keeps an undo copy of the source too, so a move gone wrong is reversible on both ends. Delete and move previews are size-aware, so you see what you're about to lose before you lose it.

There is also an append-only audit log at .ankita_backups/audit.jsonl, owner-only, with entries scrubbed by the same secret scrubber that keeps credentials out of session files. Every destructive action leaves a receipt you can read later. The whole batch is verified by test/tools/trust-safety.test.mjs (11 tests).

One fix inside this batch deserves a mention: backups used to share filename prefixes, so foo could list, restore, or prune foo.txt's backups. Each original path now gets its own backup directory.

The design stance here is simple: prompts fail. People click through them, and a prompt shown at the wrong moment teaches the user to approve without reading. An undo copy, on the other hand, works even after the mistake. I would rather my companion be forgiving than strict.

The part I am less sure about: advisory skill manifests

Skills in Ankita are markdown files with a permission manifest declaring allowed-tools and touches — which tools a skill may use, and which parts of your world it touches. v2.7.0 parses, validates, and shows these manifests in the skill catalogue.

But they are advisory. They are not enforced. Tool approvals remain the only enforcement boundary: a skill that declares it touches nothing can still be asked to do something, and the approval gate — not the manifest — decides whether it happens.

Here is why I kept it that way, and why I am not fully comfortable with it. A manifest that is enforced without a sandbox is theatre: the model can always phrase the same action through a different tool, and an enforced-but-leaky boundary teaches users a false sense of safety. An advisory manifest, by contrast, is honest about what it is — a readable promise from the skill author, shown to the user before they enable it, backed by the approval gate that actually fires.

The counter-argument writes itself: if the manifest is never enforced, why parse and validate it at all? My answer today is that a validated, visible promise changes behaviour — authors write tighter skills when the manifest is displayed, and users can spot a skill that claims touches: [] while obviously needing your inbox. But I admit that is a social mechanism, not a technical one, and social mechanisms fail quietly.

So here is the design question, stated plainly: should a skill's permission manifest be enforced — blocking any tool or surface it did not declare — even though a model can route around it, or is advisory-plus-approval the honest design, and enforcement just security theatre? I genuinely want to hear the case for enforcement, because "advisory" still feels like a word I chose to avoid a harder engineering problem.

The rest of v2.7.0, briefly

This release also ships Ankita's first community contribution, and it is a good one: the codebase-tour skill by Pradyumna Parida, merged from PR #69. It explains an unfamiliar repository verification-first — inspect the real top-level layout, find docs and manifests with targeted globs, read only the files needed, then report entry points, build/run/test commands, and component relationships with repository-relative paths, separating observed facts from inferences. It stays inside an eight-step budget and never modifies or runs the project. It ships with its README, permission manifest, and golden fixtures, and it passed the skill checks clean.

Projects now maintain themselves: a session started inside a registered project folder attaches to that project without changing the global active project, nested folders resolve to the longest match, and after a turn that changes files or tasks, Ankita appends one bounded work-log line and syncs up to five open todos, each tagged with its session — so /project undo removes exactly that session's automatic entries, nothing else.

There is a managed ChatGPT browser mode (a built-in compact Electron window with saved sign-in, or the existing Chrome companion with automatic local discovery instead of a copied pairing link), sub-agents via delegate_task (explore, reviewer, or worker children, isolated from memory, browser, MCP, skills, and scheduling), skill discovery inside find_tools, interactive desktop slash commands, and a round of desktop UI polish.

Ankita is open source (MIT) at https://github.com/akyourowngames/A.N.K.I.T.A, and the full v2.7.0 release notes are at https://github.com/akyourowngames/A.N.K.I.T.A/releases/tag/v2.7.0. If you have a view on advisory versus enforced skill manifests — or you have broken an undo system in a way I have not thought of — I would really like to hear it in the comments.