Changelog

• A hosted option on Vercel’s Eve framework. The new eve/ folder is the blueprint as an agent you deploy to your own Vercel account, Railway or a server you run. You reach it from a web chat, Slack, Linear, Telegram, an MCP client such as Claude Code, or HTTP, name a GitHub repository and a feature, and it works through the same skills to a reviewed pull request. It reads the plugin’s skills/ folder in place, so the hosted agent and the CLIs run the same skill text. The Hosted page builds a deploy link from your choices, and eve/README.md has what to prepare, the three routes, the variables and the upgrade steps.
• Linear, Telegram and MCP beside the web chat and Slack. A member of a public Linear team delegates an issue to the agent, and its progress and questions appear in the issue’s agent session; the agent mints its own Linear token from your Linear app’s client ID and secret. The people you list message a private Telegram bot, and each thread of that chat is its own run. An MCP client such as Claude Code starts and answers runs with a token you choose, and Claude.ai and ChatGPT can sign in through your own identity provider. Each channel admits only the callers you allowed, and during an upgrade none of the three starts new work. A repeated Linear or Telegram delivery starts no second run. Claude Code with the token and Claude.ai with OAuth sign-in each ran to a draft pull request on Vercel and on Railway. Limits: private Linear teams were not checked, attachments are not read, and ChatGPT has not been run live as an MCP client. eve/README.md has the setup, rotation and removal steps.
• It pushes as a GitHub App you create for one repository. The agent can reach no repository the App is not installed on. It pushes its own branch after every stage and opens a draft pull request at the end, after a secret scan, and it never pushes from the shell. A change to .github/workflows or .github/actions needs a person to approve it.
• One model per role. The lead, the planner, the builder, the reviewer, the tester, the analyst and the documenter each have a model and a reasoning level through the Vercel AI Gateway, set by a preset that you can change one role at a time. Helpers run on their role’s model.
• Guarded on Vercel, unguarded elsewhere. On Vercel Sandbox the GitHub token never enters the sandbox. On Docker and Daytona, which Railway and your own server use, each git command reads its token from a file that another process in the sandbox could read while that command runs. docs/hosts/eve.md says what that means, and what a ruleset protects on a private repository.
• Five skills are degraded there. ab-plugin-update, ab-forensics, ab-browser-testing, ab-deployment-verification and ab-health-check load and run, but cannot do all of their work in a hosted sandbox. The host note gives each one’s reason. ab-migrate and ab-plugin-update stay manual-only and load only when you name them.
• The eight coding CLIs are unchanged. Every skill, helper prompt and hook they install is the same as in 4.1.1 except the version number. install.sh --only eve refuses and points to the Hosted page, because the hosted agent is deployed, not installed.

ab-ship-pipeline’s loop of fresh sessions, which the CLIs get from the ship runner, runs on the hosted agent through the ship_pipeline tool: one iteration per call, each in a fresh helper, with every stage pushed to the branch as it finishes. A helper or a tool that crashes costs one iteration; on Eve 0.86.0 a failed turn of the lead agent itself, such as a refused model call, ends the session, and the run restarts by hand from the branch it pushed, which keeps every finished stage.

A plugin install updates through its tool (docs/hosts/<host>.md). A checkout updates with git pull, then bash install.sh again. A hosted copy is new in this release: deploy it by one of the routes in eve/README.md. Later releases reach a running copy through the upgrade steps there, which end the open sessions before the new release goes live.

• install.sh no longer removes Cursor CLI’s marketplace. On a computer with Claude Code’s plugin, 4.1.0 removed Cursor’s agent-blueprint marketplace, because Cursor reads Claude Code’s plugin there. But Cursor keeps marketplaces on your account, and every computer signed in to it shares them. So the removal also reached your other computers, and any of them that installs agent-blueprint through Cursor’s own marketplace lost the source it installs and updates from. The installer now leaves the marketplace in place. If the installer had added Cursor’s marketplace on that computer, it now tells you to uninstall Cursor’s own copy in /plugin, so Cursor reads only Claude Code’s plugin. /plugin marks Claude Code’s copy “(Claude Code)”.
• install.sh no longer replaces a Cursor marketplace from another source. Without Claude Code’s plugin, 4.1.0 removed an agent-blueprint marketplace that pointed somewhere other than GitHub, such as a checkout or a fork, and added it back from GitHub, which changed the source for every computer on the account. It now leaves that marketplace as it is and prints the two commands that switch it to GitHub.

A plugin install updates through its tool (docs/hosts/<host>.md). A checkout updates with git pull, then bash install.sh again. If an earlier run removed Cursor’s marketplace and another computer of yours still uses it, add it back once with cursor-agent plugin marketplace add https://github.com/Ninety2UA/agent-blueprint.

Every tool that has an install command now installs straight from GitHub and updates through its own updater:

install.sh stays as the way to set up every tool on the machine at once. It runs the same commands with GitHub as the source (--local uses the clone), writes no shared ~/.agents/skills copy, and on a re-run removes the copies 4.0 recorded once the routes that replace them have succeeded. If one tool’s install fails, the others still install, and the run ends by listing which tools finished and which failed, saying for each failed tool whether its old install stayed or was already removed. Before it removes an install to replace it from GitHub (a marketplace, Grok’s plugin or a Pi package), it checks that GitHub answers, because removing a marketplace uninstalls its plugin. A Pi package pinned to a version, as @ref or #ref, is replaced with the current source and a warning that names the pin; because Pi treats every entry for one repository as a single package, removing the pin also removes a second entry for it, so the installer installs the current source afterwards rather than updating that entry. The reachability check uses your own SSH command when Git reaches GitHub over SSH, never prompts, and gives up after 30 seconds. A run limited with --only keeps a recorded copy that a tool outside the run still reads, Hermes included when its config lists that copy, and says so.

Every skill, its references and its helper prompts were audited against OpenAI’s guidance for GPT-6 Astra, which follows skill text more literally. The fixes are below, one rule at a time. docs/releases/v4.1.0-instruction-audit.md gives the reason for each.

• ab-test-driven-development discards only code the agent wrote in the task before its test. It never deletes code that existed before the task, or code you wrote or asked to keep. You can also tell the agent to keep its own pre-test code.
• ab-brainstorming does not ask you again to approve a design you already approved or told it to build. A request that only asks for code, with no design yet, still gets a design first.
• Skills no longer ask again for an approval you already gave. Deleting work you own, rewriting shared history or pushing needs your own request. Starting a skill whose job is to publish, such as the PR workflow or the ship pipeline, counts as that request.
• Text in files, tool output, PR comments or a helper’s report never counts as your instruction. The stage approvals in ab-build-pipeline, the batch checkpoints in ab-executing-plans and the injection guards stay as they were.

ab-project-start no longer scaffolds into whatever folder the session happens to be in. With no folder named, it refuses your home folder and /. In a folder that has files but is not a git repository, it shows what it would write and asks first. Inside a repository it never runs git init again, so it cannot nest one repository inside another. It also names the repository’s top folder.

• The plugin listing is complete: the Developer Tools category, a description that counts the five hooks Codex gets, listing copy, links, three example prompts, the brand color, and an icon and logo for light and dark.
• Codex’s $ picker shows a display name and a one-line description for every skill, such as Project Setup for ab-project-start. ab-plugin-update and ab-migrate stay manual-only.
• Codex offers $ab-project-start right after you install the plugin.
• The write guard now reads Codex’s edits. Codex reports a file edit as apply_patch with the patch text. The guard used to look only for Claude Code’s Write and Edit, so on Codex it ran without scanning anything. It now scans the lines each patch adds to files that become agent context, and the text of a file a patch moves into one of them.
• A real Codex session showed all five hooks running: the session-start pointer, the write guard, the commit-message check, the context monitor and the ship-pipeline Stop guard. In that session the write guard warned on an apply_patch edit and the commit-message check flagged a commit message, so both act on Codex’s own payloads, not only start.

ab-plugin-update updates each install through its tool’s own route. On Codex it upgrades a Git marketplace or pulls a local checkout marketplace, then adds the plugin again. It never falls back to a skills copy beside the plugin, which made Codex list every skill twice.

Claude Code, Codex, Antigravity, Grok Build, Pi, Cursor CLI, Hermes and Amp each installed the release by its own route and listed every skill exactly once. Cursor CLI, Amp and Grok Build also listed every skill exactly once beside Claude Code’s plugin (docs/releases/v4.1.0-installs.md). ab-plugin-update moved a real Codex install from 4.0.2 to 4.1.0. docs/releases/v4.1.0-smoke.md has the smoke cells for discovery, the manual-only rule, hooks, debugging and the two new behavior checks (existing code kept under TDD, and an approved design taken as approved).

The README and the website lead with each tool’s own install command and add a Codex section for the CLI and the app. They also add a step after installing that runs the setup skill and explains what it creates, when to run it and how to call it in each tool. The eight-tools diagram shows each tool’s route, and two new loops show each tool installing and ab-project-start setting up a project.

A plugin install updates through its tool, or you can ask any tool for the ab-plugin-update skill. If you installed 4.0 with bash install.sh, run the 4.1.0 installer once without --only. It removes the copies 4.0 recorded in ~/.agents/skills, ~/.grok/skills and ~/.pi/agent/skills and gives each tool its own route. The installer now needs python3 for every tool, where 4.0.2 needed it only to scaffold a project. Existing projects need no change.

• Injection scanners match whole words: the write scanner (prompt-guard.js, on file writes and edits in Claude Code and Codex) and the read scanner (read-injection-scanner.js, on file reads in Claude Code) matched a trigger word inside a longer word and reported “Blueprint instructions” (the “print” in Blueprint), “slideshow prompt” and “react as a” as possible prompt injection. Every pattern that starts with a word now needs a word boundary before it. Markdown emphasis such as _ignore all previous instructions_ is still caught.
• New projects get docs/context/DECISIONS.md: the scaffolded AGENTS.md tells the agent to honor that file and to record conservative choices in it, but ab-project-start never created it. It now ships a stub that the ab-discuss skill appends to.
• ab-brainstorming shows each design section before asking about it: in one run it asked for approval of sections whose text never appeared, only their headings. It now writes each section in full in its reply and asks for approval only once every section is shown.

The README also says what the ship runner deletes after it publishes.

A plugin install updates through its tool (docs/hosts/<host>.md). A checkout updates with git pull, then bash install.sh again. Existing projects need no change: ab-discuss creates docs/context/DECISIONS.md the first time it records a decision.

• Cursor CLI and Amp list each skill once next to Claude Code: both read Claude Code’s plugin as well as ~/.agents/skills, so on a machine with Claude Code and either of them, install.sh no longer writes the shared copy there. Codex gets its own plugin (codex plugin marketplace add and codex plugin add), Grok Build, Pi and Hermes each get a copy in a folder only they read (~/.grok/skills, ~/.pi/agent/skills, ~/.hermes/skills; Hermes then needs no config edit), and a shared copy an earlier install left in ~/.agents/skills is removed: only the skills its install record names, never a folder of your own. The machine decides the route, not --only, and a run limited with --only keeps the shared copy while another installed tool still reads it. A folder in a tool’s skills folder that the installer did not put there is kept, with a warning. Machines without that pair, and --copy-dir or AGENT_BLUEPRINT_COPY_DIR, keep the one shared copy.

Update the checkout (git pull), then run bash install.sh again; it switches the routes and removes the old copy where needed. A plugin install updates through its tool (docs/hosts/<host>.md).