{"slug": "i-taught-my-release-checklist-to-wait-for-me", "title": "I taught my release checklist to wait for me", "summary": "A developer built Miilo Release Caretaker, an open-source release-review workflow that runs parallel release, package and link checks through Mastra, uses Gemma to investigate the gathered evidence, and suspends at a human-review step so the run can be resumed later from SQLite-persisted snapshots. The project's release checks currently rely on labeled sample facts, with automatic GitHub, Homebrew and documentation-site inspection described as future adapters rather than a claimed capability.", "body_md": "*This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady](https://dev.to/challenges/hacktoberfest-week3-2026-10-19).*\n\nI shipped a CLI release. Homebrew was still installing an older version.\n\nThat 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.\n\nFor 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.\n\nI wanted to stop carrying that context around.\n\n**Miilo Release Caretaker is a release-review workflow that gathers evidence, explains what needs attention, and waits for a person to return.**\n\nMastra runs the workflow and preserves its state. Gemma investigates the evidence. Miilo can display the resulting work and attention through an optional local integration.\n\nThe 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.\n\nThis 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?\n\nNo voiceover required. This captioned GIF condenses three excerpts from the same verified Linux recording:\n\nThe 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.\n\nFinally, 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.\n\n[**Miilo Release Caretaker on GitHub**](https://github.com/miilo-ai/miilo-release-caretaker) · Apache-2.0\n\nThe base workflow runs independently of an installed Miilo CLI. With Node.js 22.13 or later:\n\n```\ngit clone https://github.com/miilo-ai/miilo-release-caretaker.git\ncd miilo-release-caretaker\nnpm ci --ignore-scripts\nnpm run check\nnpm test\nnpm run journey -- start stale-package\n```\n\nThat 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.\n\nThe [model configuration guide](https://github.com/miilo-ai/miilo-release-caretaker/blob/main/docs/model-investigation.md) explains endpoint, model and credential-file configuration. The [optional Miilo bridge](https://github.com/miilo-ai/miilo-release-caretaker/tree/main/integration/miilo) requires the matching local SDK/CLI changes. Those changes are not yet a published Miilo feature.\n\nRelease Caretaker is the new Week 3 project. The broader Miilo observer project predates this challenge.\n\nA checklist script can report a mismatch. I needed the review itself to survive after the command exits.\n\nThe 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:\n\n```\n.parallel([\n  checkStep(\"release\", checks),\n  checkStep(\"package\", checks),\n  checkStep(\"links\", checks),\n])\n  .then(aggregate)\n  .then(investigationStep(investigator))\n  .then(reviewStep())\n  .then(verificationStep(checks))\n  .commit();\n```\n\nMastra 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.\n\nA 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.\n\nReview 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.\n\nThat 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.”\n\nThe version comparison does not need an LLM. Explaining a collection of findings and proposing a useful next step is where I wanted model assistance.\n\nI 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:\n\n`list_evidence`: list findings in the current report.` read_evidence`: inspect one finding by its identifier.\nIt 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.\n\nThe 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.\n\nIn 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.\n\nCitation 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.\n\nI tested reopening a saved review in another process. Then I killed a worker during an active parallel check.\n\nThe 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.\n\nThe 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.\n\nThis 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.\n\nMastra 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.\n\nThe 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.\n\nThe 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.\n\nThe two partner technologies doing the work here are **Mastra and Gemma**. SQLite stores state, TypeScript implements the application, and Miilo supplies observation.\n\nMastra 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.\n\nThis 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.\n\nMore 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.\n\n**I want to stop remembering the release checklist without surrendering the release decision.**\n\nThe 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.\n\nI have not measured hours saved or deployed automatic monitoring of real releases. What I have verified is concrete:\n\nThe repository documents dependency-review and deployment limits. This is a local prototype, not a qualified public service.\n\nFor 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.\n\nTwo community discussions help explain the boundaries tested here:\n\n*AI assistance was used for implementation, testing and drafting. I review the project and submission before publication.*", "url": "https://wpnews.pro/news/i-taught-my-release-checklist-to-wait-for-me", "canonical_source": "https://dev.to/edyvision/i-taught-my-release-checklist-to-wait-for-me-5bm0", "published_at": "2026-10-23 04:01:48+00:00", "updated_at": "2026-10-23 04:12:00.879172+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "mlops", "ai-products"], "entities": ["Miilo Release Caretaker", "Mastra", "Gemma", "Miilo", "GitHub", "Homebrew", "SQLite", "Node.js"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/i-taught-my-release-checklist-to-wait-for-me", "markdown": "https://wpnews.pro/news/i-taught-my-release-checklist-to-wait-for-me.md", "text": "https://wpnews.pro/news/i-taught-my-release-checklist-to-wait-for-me.txt", "jsonld": "https://wpnews.pro/news/i-taught-my-release-checklist-to-wait-for-me.jsonld"}}