I taught my release checklist to wait for me

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

I shipped a CLI release. Homebrew was still installing an older version.

That is a particularly annoying kind of failure. The release exists, the build has finished, and you are ready to tell people to try it. Then you discover that “published” and “installable” are two different things.

For a small open-source project, the release checklist tends to live in the maintainer's head. Check the tag. Check the assets. Check the package version. Check the links. Remember what failed. Come back later and remember why.

I wanted to stop carrying that context around.

Miilo Release Caretaker is a release-review workflow that gathers evidence, explains what needs attention, and waits for a person to return.

Mastra runs the workflow and preserves its state. Gemma investigates the evidence. Miilo can display the resulting work and attention through an optional local integration.

The important boundary: the current release checks use labeled sample facts. The Mastra execution, SQLite persistence, live Gemma inference, evidence tools and local native CLI bridge are real. Automatic GitHub, Homebrew and documentation-site inspection are the next adapters, not a capability I am claiming today.

This week's project establishes the part I need to trust before attaching it to real releases: can the workflow pause, survive interruption, explain its findings and preserve the evidence when I return?

Demo

No voiceover required. This captioned GIF condenses three excerpts from the same verified Linux recording:

The journey starts with a sample package at 1.1.0 when the release expects 1.2.0. Gemma reads the evidence, explains the mismatch and the workflow waits for review. A separate process then reopens the saved run and exports its observation to Miilo.

Finally, an explicit recheck switches the sample source to corrected facts. Current attention clears; the original failed evidence remains. The command does not edit a real formula or publish a release.

Code

Miilo Release Caretaker on GitHub · Apache-2.0

The base workflow runs independently of an installed Miilo CLI. With Node.js 22.13 or later:

git clone https://github.com/miilo-ai/miilo-release-caretaker.git
cd miilo-release-caretaker
npm ci --ignore-scripts
npm run check
npm test
npm run journey -- start stale-package

That last command creates a persisted sample review. Live model investigation is explicit opt-in through an owner-only configuration file; ordinary tests never call my model endpoint or yours.

The model configuration guide explains endpoint, model and credential-file configuration. The optional Miilo bridge requires the matching local SDK/CLI changes. Those changes are not yet a published Miilo feature.

Release Caretaker is the new Week 3 project. The broader Miilo observer project predates this challenge.

How I Built It

Mastra gives the work a lifecycle

A checklist script can report a mismatch. I needed the review itself to survive after the command exits.

The workflow runs three parallel check groups: release, package and links. They join into one report, pass through investigation, and reach a human-review step. This is the actual composition from the repository:

.parallel([
  checkStep("release", checks),
  checkStep("package", checks),
  checkStep("links", checks),
])
  .then(aggregate)
  .then(investigationStep(investigator))
  .then(reviewStep())
  .then(verificationStep(checks))
  .commit();

Mastra supplies execution, agent tools and suspension/resumption, with its LibSQL storage adapter backing saved workflow snapshots. The application adds report revisions, deterministic verdicts and the rules for what a review means.

A failed check remains evidence with expected and actual values. A source throwing an error exercises bounded retries. These are different events: finishing the workflow does not make its release checks pass.

Review is tied to a SHA-256 revision of the report. If the submitted revision does not match, the workflow suspends again. Acknowledging a finding preserves its failed verdict. Requesting verification reads the source again and produces a separate verification report.

That distinction matters when I return after a break. My review should describe the evidence I actually saw, and “I looked at it” should never mean “the problem is fixed.”

Gemma makes the evidence easier to act on

The version comparison does not need an LLM. Explaining a collection of findings and proposing a useful next step is where I wanted model assistance.

I used Gemma 3 12B, served on hardware I already own through a configurable OpenAI-compatible endpoint. A Mastra Agent receives the report's evidence identifiers and can use only two tools:

• list_evidence: list findings in the current report.
• read_evidence: inspect one finding by its identifier.

It cannot run shell commands, install a package, browse arbitrary URLs or change a repository. The final explanation must cite evidence the agent actually read through a tool. Knowing an identifier exists is insufficient.

The endpoint used for the recording supports text chat rather than native function calls. An explicit JSON tool protocol translates Gemma's request into a tool call that Mastra executes. The model does not execute the tool itself. A separate native-tool mode is covered by disposable-server tests.

In the recorded Omarchy run, Gemma inspected the formula evidence and explained the 1.2.0 versus 1.1.0 mismatch using two model requests and one evidence-tool invocation in 11.3 seconds. That is one observed case, not an accuracy benchmark. The endpoint did not report token usage, so token counts and inference cost remain unknown.

Citation checks constrain the explanation; they do not prove the diagnosis is correct. Deterministic code owns the verdict, and a model error leaves that evidence available for human review.

Recovery needed more than a happy-path restart

I tested reopening a saved review in another process. Then I killed a worker during an active parallel check.

The second test exposed a different problem: a branch can finish reading before the parent parallel group commits its state. Restarting can repeat work that appeared complete.

The adapter now checkpoints validated read results by run, scenario, check group and initial/verification stage. Recovery reuses committed results and repeats the unfinished read. A fresh verification cannot quietly reuse the initial stage's facts.

This establishes a tested recovery boundary for the current read-only workflow. It does not establish exactly-once external writes or power-loss durability. A read interrupted before its checkpoint commits may repeat.

Miilo gives the workflow somewhere to be seen

Mastra remains the execution engine. Caretaker normalizes selected saved state into Miilo's workflow observation contract; the native CLI projects it into work items, attention and evidence.

The practical payoff is that a review request can appear alongside other work rather than disappearing into a terminal scrollback. After verification, current attention can clear without deleting the failed evidence that explains the run's history.

The bridge uses owner-only atomic file replacement and explicit enrollment. Tests cover interrupted exports, malformed files, stale sources and isolation between sources. The domain depends on typed ports; framework, storage, model and process details stay outside it.

Why Does Open Innovation Matter?

The two partner technologies doing the work here are Mastra and Gemma. SQLite stores state, TypeScript implements the application, and Miilo supplies observation.

Mastra lets me build on inspectable workflow and agent machinery. Gemma lets me run open-weight inference on existing hardware. Endpoint and model selection are configuration, so the workflow's domain does not require one model vendor or hosted subscription.

This deployment uses a model-serving machine on a private network, so it is not an entirely offline laptop application. It avoids a new public inference service for the demo; existing hardware and electricity still have costs.

More broadly, the checks, review rules and adapter interfaces are open to inspection. Someone can reproduce the sample journey, replace a check source or connect a compatible model without accepting my infrastructure as a dependency.

The Lazy Payoff

I want to stop remembering the release checklist without surrendering the release decision.

The current prototype demonstrates that handoff: findings persist, Gemma explains the evidence, review can wait, and verification preserves history. The next step is to connect bounded read-only GitHub, formula and link adapters so it can review Miilo's actual releases.

I have not measured hours saved or deployed automatic monitoring of real releases. What I have verified is concrete:

• All 28 Caretaker tests passed on macOS, Omarchy and the repository's first Node 22 Linux CI run.
• Seven local SDK/CLI integration tests and 50 native CLI regression tests passed on Omarchy.
• Live Gemma investigation completed from both macOS and Omarchy.
• The recorded journey ended with zero current attention records while retaining historical failed evidence.

The repository documents dependency-review and deployment limits. This is a local prototype, not a qualified public service.

For this week's Slow and Steady theme, the useful part is giving the workflow permission to wait. I can leave the terminal without asking a model to make the final decision or relying on myself to reconstruct the whole story later.

Prize Categories

• Best Use of Mastra: parallel checks, bounded retries, durable review, cross-process resumption and a scoped evidence-tool agent.
• Best Use of Gemma: live, locally served Gemma inference for cited explanations of release evidence.

Further Reading

Two community discussions help explain the boundaries tested here:

• Tie Human Approval to the Exact Version an AI Agent Delivered by @hiroshi_takamura_c851fe71: why a review should identify the version and evidence it covers.
• Function Calling Gives LLMs Type Safety, Not Correctness by @aiexplore369zoho: why validating structured output is not the same as validating its meaning.

AI assistance was used for implementation, testing and drafting. I review the project and submission before publication.