# Agent Maintainer — an AI maintainer for an on-chain package that still can't ship on its own

"Give the AI commit access" is where most agent-automation stories quietly
become horror stories. The useful version is narrower and much safer: let the
agent drive the *process* — the tedious, valuable, around-the-clock parts —
while an explicit policy still gates the one irreversible step, the ship.

This realm is that split, made concrete for a versioned on-chain package.

## What the agent may do

- open a version proposal committing to a package artifact hash,
- collect independent reviews,
- record CI test attestations,
- write release notes, keep a compatibility matrix,
- deprecate a version when a vulnerability lands.

## What it cannot do

Deploy on its own say-so. `Approve` is gated by a machine-checked policy, and
it panics with the *first* unmet condition rather than quietly proceeding:

```
tests pass
AND  ≥ MinReviewers (2) independent reviews
AND  every review scores ≥ MinScore (80)
AND  the challenge window has elapsed (height > ChallengeUntil)
```

The render turns that policy into a live checklist:

```
## Policy checklist
- ✅ tests pass
- ✅ ≥2 independent reviews (have 2)
- ❌ every review ≥80          ← one reviewer scored 70
- ✅ challenge window elapsed
```

## The flow

```go
id := maintainer.Propose(cross(cur), "v3", "artifact#H3", 100) // 100-block challenge window
maintainer.AttestTests(cross(cur), id, true)                    // CI attests

maintainer.AddReview(cross(cur), id, 85, "ok")   // reviewer 1 (not the proposer)
maintainer.AddReview(cross(cur), id, 95, "great")// reviewer 2

// ...after the challenge window passes...
maintainer.Approve(cross(cur), id)               // promotes to a release, or panics with the reason

maintainer.LatestVersion()          // "v3"
maintainer.Deprecate(cross(cur), "v3", "CVE-xyz")
maintainer.IsDeprecated("v3")       // true
```

Two independence rules keep the reviews honest: the proposer can't review its
own proposal, and each address reviews at most once.

Note the realm records the *approved release* — the actual package publish
(`addpkg`) is a separate, deliberately human/authority step. The agent
produces a green checklist; it never holds the deploy key.

Browse the release matrix + open proposals at the realm root; each proposal's
policy checklist and reviews are at `:<id>`.

```sh
gno test .
```

## Where it goes next

- Wire `Approve` to actually authorize a downstream deploy via a
  **capability** (see the capwallet demo) instead of a trusted caller — then
  even "approved" can't over-spend or over-deploy.
- Route contested proposals to a **jury** instead of a simple score gate.
- Add a maintainer *budget* so the agent's activity itself is bounded.

Each of those is a different demo in this series clicking into place — which
is the real thesis: agent trust is not one primitive, it's a stack of small,
composable ones.

<!-- BEGIN GNOCONTRACTS FOOTER (generated by `make readmes`; do not edit below) -->

---

Part of **[moul/gno-contracts](https://github.com/moul/gno-contracts)** — moul's versioned gno.land contracts. See the repository for the full catalog, build/test tooling, and usage.

**Dependency graph:**

![gno.land/r/moul/agents/maintainer/v0 dependency graph](https://raw.githubusercontent.com/moul/gno-contracts/main/_assets/gno.land/r/moul/agents/maintainer/v0/deps.png)

> ⚠️ **Disclaimer:** provided as-is, without warranty; not security-audited. Full disclaimer: [DISCLAIMER](https://github.com/moul/gno-contracts/blob/main/DISCLAIMER.md).

<!-- END GNOCONTRACTS FOOTER -->