SlothOps：睡眠期間持續運作的自主 AI 程式碼維護系統

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

What I Built

SlothOps is an autonomous software-maintenance system that takes repetitive GitHub issue-to-PR work off a developer's hands. Instead of manually investigating every issue, tracing dependencies, implementing fixes, running tests, and writing PR descriptions, you queue up eligible issues and let the factory work through them.

The goal is simple: wake up to investigated issues, isolated code changes, test results, and draft pull requests ready for human review. This is not another chatbot suggesting code snippets. It is a persistent engineering workflow that carries tasks across multiple steps, recovers from failures, and preserves progress without requiring a human to supervise every tool call.

The project is deliberately conservative about irreversible actions. It prepares code and draft PRs, but it does not merge its own work. Reliability and verifiability matter more than PR volume.

Demo

Working project under active development. The current development target is Recon-OS, a repository with multiple issues involving data loaders and document ingestion. The factory has been used to prepare feature PRs for plain text, Markdown, JSON, HTML, CSV, and remote URL ingestion.

Live end-to-end demonstration with real workers and review feedback is the next milestone. Recent smoke tests encountered provider timeouts and free-tier limits, which is exactly the kind of failure the orchestration layer is designed to handle gracefully.

Code

agent-factory

How I Built It

Architecture

• Python orchestrator and SQLite: Python acts as the control plane. SQLite stores durable task state and supports recovery, retry tracking, and reconciliation. The model is not the source of truth for whether a task completed—that status must come from recorded state and verifiable outcomes.
• Multiple AI workers: The system uses different workers for reasoning, implementation, and review. The current setup has explored OmniRush, Antigravity, and the OpenCode CLI, with different models and availability constraints. Worker selection and fallback distinguish successful execution from errors, timeouts, unavailable services, and situations requiring human intervention.
• Git and GitHub integration: Git worktrees provide task isolation—concurrent or unfinished tasks cannot contaminate one another. GitHub is used to retrieve issues, communicate progress, push branches, and create or update draft PRs. The factory reconciles remote state before retrying operations, so an interruption after a successful GitHub action does not produce duplicate comments or PRs.

The Reliability Problems I Am Trying to Solve

Building the happy path is only part of the project. Much of the engineering effort goes into the failure cases:

• Long-running subprocesses: Workers may stall or fail without useful messages. The orchestrator needs real deadlines, non-blocking supervision, bounded output collection, and process cleanup. A silent log is not proof that a process is stuck.
• Worker availability and fallback: AI services run out of capacity, hit usage limits, or become unavailable. The system classifies failures, applies bounded retries with backoff, and preserves work instead of endlessly launching new attempts. Fallback is not permission to weaken the review policy.
• Idempotent GitHub operations: An operation can succeed remotely even if the local process crashes before recording the result. The factory reconciles GitHub comments and PR state with SQLite records before retrying.
• Changes across multiple PRs: Several PRs may modify related interfaces. The system detects stale branches, resolves conflicts carefully, reruns checks, and obtains fresh reviews when code changes.

Quality and Safety Gates

The factory is designed around deliberate constraints:

• No automatic merging or automatic merge enablement.
• Required reviewers must approve the exact same final commit SHA.
• Changes made after review require fresh review.
• Failed or unavailable reviewers do not count as approvals.
• Repair attempts are bounded.
• Uncertain or unsafe situations are marked as blocked instead of being silently treated as success.

An autonomous coding system should be allowed to do repetitive work, but it should not be allowed to redefine success just because it ran out of time or model capacity.

Why Does Open Innovation Matter?

The broader goal is to make autonomous coding workflows inspectable, adaptable, and less dependent on a single proprietary service. Open-source agent tooling and open-weight models make it possible to:

1. Inspect and customize the execution harness: A developer should understand and change how the automation works, rather than accepting an opaque agent's decisions.
2. Swap models or providers when availability, cost, or quality changes.
3. Run suitable models locally or on infrastructure under the developer's control.
4. Keep repository code and task data within a chosen environment when the deployment supports it.
5. Reproduce and improve the workflow without depending entirely on a closed, fixed implementation.

Note on the current implementation: The orchestration layer is Python and SQLite, but some workers rely on hosted AI services. The current system should not be described as fully offline, fully local, or entirely powered by open-weight models. Those are deployment possibilities to investigate and demonstrate, not claims to make without evidence.

The open-source approach matters because the developer should be able to understand and change how the automation works. A closed API would make the workflow a black box—you could submit issues and hope for PRs, but you could not inspect the review logic, modify the safety gates, or run the entire pipeline on your own hardware.

My Agent Session

DevRelay session coming soon. This project was built in an extended pair-programming session exploring orchestration architecture, failure classification, and worktree isolation.

The Lazy Payoff

SlothOps is designed to reward a developer for doing less repetitive work without lowering the quality bar.

Software maintenance involves a surprising amount of tedious work. Even a small issue can require reading unfamiliar code, tracing dependencies, reproducing a bug, implementing a fix, running the correct checks, preparing a PR, and responding to feedback. That is a 15–25 minute context-rebuild tax before any real engineering starts—per issue.

With SlothOps, you queue an eligible issue and return to review the evidence and proposed changes. The factory handles the investigation and implementation workflow. You spend your attention on architecture, difficult decisions, and the changes that actually require human judgment.

The central idea: Laziness and engineering discipline do not have to conflict. Good automation handles the repetitive work while preserving the checks that make the result trustworthy.

Prize Categories

Categories pending final review of partner requirements. Primary fit:

• Best Use of Open-Source AI — SlothOps is built around the principle that autonomous coding workflows should be inspectable, adaptable, and not locked to a single provider. The orchestration layer and safety gates are fully open, and the architecture explicitly supports swapping models and providers.

SlothOps is a work in progress. The goal is to establish that the factory can reliably complete a task, not merely that it can start one. The strongest demonstration would begin with a real, appropriately scoped issue and end with a draft PR that includes a clear explanation, an isolated reviewable implementation, reproducible test results, independent review against the final commit, natural GitHub communication, a recoverable task history, and no hidden bypasses when a worker fails.