Improver limits and records

For: tenant administrators and plugin users.

Look up its boundaries, retained evidence and agent names.

What it never does

• Change Orchestrator Zero, or anything outside the target plugin's repository. Its instructions keep it inside the target's folder, and the reviewer sees every changed path.
• Change another publisher's plugin, signed or not. For a plugin you install from someone else, hide a skill for your tenant and send its publisher feedback with the failing case instead.
• Change itself.
• Approve, merge, apply or install anything. Every changeset waits for a person; review: policy is not used.
• Weaken what judges a plugin: a change to its evals, rubrics, outcome checks, policy files, CODEOWNERS or CI waits for a second person with the governance permission.
• Run in a shadow run beyond its reads: its session's tools answer from stubs there, as every write does, and so do its flows' oz.report_outcome and oz.propose_update.
• Run the repository's code outside a session's sandbox: its sessions run their shell at tier 1 (or where an admin opted a node out, at tier 0, which the job says), under the tenant's command rules; the pinned check runs the target's tests there too.
• Start a coding session from a routine's fire: a fire never holds a shell and a write.
• Claim that a plugin got better. Its answer says what it changed and which tests cover it; whether that helps is what your review, the evals and the rollout's gates show.

Limits

• One plugin, one change, one job. A job proposes at most one changeset, to the plugin it was started for.
• A forge. Pull requests go to GitHub, through ai.oz0/github. A plugin kept elsewhere is not a target yet.
• Targets installed from Git. The candidate check and the update after a merge need the target installed from its repository. One installed from a hub listing of your own publisher is checked by its listing's custody, and its update after a merge is a person's own oz0 plugin update.
• The candidate check needs a node labelled candidates=allow with sandbox tier 1 that is not the job's own node, and evals for the changed agents; without them it says so on the approval. Its cost is bounded by the job's budget and counted on the comparison's own runs.
• Sessions need the session's harness installed on the node, and a tier-1 node (or one an admin opted out of the tier) for every session, whoever started the job. A session that runs over its limits (40 turns, 30 minutes, $3) fails the job.
• Tests in the pinned check run offline only: a Go module's dependencies must be in the repository or the node's cache, a Node.js project's node_modules in the repository.
• Evidence. OpenCode and goose sessions are offered oz.evidence for the targets you granted; a Claude Agent SDK session is not offered it yet, and works from the evidence IDs its input cites and the target's files.
• Restarts. A lost improver session starts again by itself only in tier 1 with no egress; OpenCode's and goose's ask a person first.
• Routine fires do not start coding sessions or propose changesets. An explicitly configured after-merge flow may call oz.propose_update to file a plugin_update request for a person to review; see Routines.

What it leaves on record

Each change the improver proposes leaves the platform's record of it: the changeset with its diff and its decisions (who approved, who approved a protected path), what its candidate check found (the comparisons by ID, in the audit log as candidate_check.requested, .started and .finished), where it came from (job, agent, plugin version, model, target, evidence), the commit's OZ- trailers, the pull request's body, the result reported on its job after the pull request closed, the update's change request with who approved it, and, after an install from that commit, the plugin version's provenance. Each counts against the target's change budget.

The record says what happened; what it means for your obligations about the systems you build with your plugins is a question for your own advice.

Names

The plugin's name is plugin-improver in its manifest and ai.oz0/plugin-improver on the hub; its agents are improver, improver-opencode and improver-goose, its tool oz0_plugin_improver, and its flows improve-plugin, improver-notice and improver-after-merge.