Autonomous Maintenance

RoboCo can keep itself and your projects healthy on their own schedule: it can watch each opted-in project's CI and open a fix task when it goes red, it can periodically check whether a dependency upgrade would change a project's lockfiles and open an "update dependencies" task when it would, and — for RoboCo's own repository specifically — it can assess its own release readiness and propose a release for you to approve. All three are off by default, and none of them ever auto-merges or auto-publishes — every task or proposal they open rides the normal dev → QA → PR review → CEO merge pipeline (or, for a release, your explicit approve/reject), exactly like work you'd start yourself.

The first two engines generalize the self-healing CI loop, which watches only RoboCo's own repository. Multi-repo CI-watch and the dependency-update bot extend the same idea to any project you opt in; the release manager stays single-repo by nature — it's proposing RoboCo's own version, not a project's.

Multi-repo CI-watch

CI-watch assesses each opted-in project's CI on its default branch. On a red conclusion it opens one fix task into that project and notifies that project's cell PM. It never starts that task, never merges it, and never deploys.

What it does

On each pass (ROBOCO_CI_WATCH_INTERVAL_SECONDS, default 1800s) the engine checks each opted-in project's latest CI conclusion on its default branch. On a red conclusion it opens one fix task into that project and notifies the project's cell PM. The pass is resilient by construction:

A missing CI signal is treated as "unknown", never a false green — an absent run never masks a real failure.
One repo's GitHub error never aborts the sweep — the engine moves on to the next project.
Origination is bounded and deduped per repo: a monorepo's cell-projects share one fix task, and the caps below stop a flapping CI from flooding the backlog.

Mermaid diagram source: flowchart TD A[Interval tick] --> B{For each opted-in project} B --> C{CI conclusion on default branch} C -->|green| B C -->|unknown / missing| B C -->|red| D[Open ONE fix task · notify the cell PM] D -.never auto.-> E[never merges · never deploys]

It never merges or deploys

A CI-watch fix task is an ordinary task. It flows through the normal delivery lifecycle — QA, the in-path PR-review gate, and your merge — exactly like work you create yourself. The engine never approves, merges, or deploys on its own.

Bounds on origination

Setting	Default	Meaning
`ROBOCO_CI_WATCH_MAX_PER_CYCLE`	`1`	Most fix tasks the sweep may open in one cycle.
`ROBOCO_CI_WATCH_MAX_OPEN_TASKS`	`3`	Rolling cap on concurrently-open CI-watch fix tasks per repo; the engine originates nothing more while this many are still open.

Enable it

Settings → Feature Flags carries the global "Multi-repo CI-watch" toggle. Then opt each project in from its settings page → Budget & Ops card: turn on ci_watch_enabled and optionally set ci_watch_workflow (the workflow file to scope the CI signal to, default ci.yml).

Takes effect on the next backend restart

The feature flag persists in the settings store and applies on the next backend restart. The per-project fields apply on the next sweep.

Dependency-update bot

The dependency-update bot periodically checks whether a dependency upgrade would change a project's lockfiles and, if so, opens one "update dependencies" task into that project. Detection is read-only: nothing in the real repo is ever mutated.

What it does

On each pass (ROBOCO_DEP_UPDATE_INTERVAL_SECONDS, default 604800s — weekly) the bot runs the project's dep_update_command (e.g. uv lock --upgrade / pnpm update) in a throwaway clone and diffs the lockfiles. If the lockfiles would change it opens one "update dependencies" task; otherwise it opens nothing.

Detection is read-only: the command runs in a throwaway clone and only the lockfiles are diffed. The real repo is never mutated — nothing is committed or pushed.
It is fail-safe: a null dep_update_command or a command that fails opens nothing.
Origination is bounded and deduped per repo, with the caps below.

Mermaid diagram source: flowchart TD A[Interval tick] --> B{For each opted-in project} B --> C[Run dep_update_command in a throwaway clone] C --> D{lockfiles change?} D -->|no / null / fails| B D -->|yes| E[Open ONE update-dependencies task] E -.never auto.-> F[never merges · never deploys]

It never merges or deploys

The update-dependencies task is an ordinary task — QA, the in-path PR-review gate, and your merge all apply. The bot only ever detects and opens; it never commits, pushes, merges, or deploys.

Bounds on origination

Setting	Default	Meaning
`ROBOCO_DEP_UPDATE_MAX_PER_CYCLE`	`1`	Most update-dependencies tasks the bot may open in one cycle.
`ROBOCO_DEP_UPDATE_MAX_OPEN_TASKS`	`3`	Rolling cap on concurrently-open update-dependencies tasks per repo.

Enable it

Settings → Feature Flags carries the global "Dependency-update bot" toggle. Then opt each project in from its settings page → Budget & Ops card: set dep_update_command (e.g. uv lock --upgrade / pnpm update) and optionally dep_update_paths (comma-separated lockfile paths to watch; defaults to inferring uv.lock / pnpm-lock.yaml).

Takes effect on the next backend restart

The feature flag persists in the settings store and applies on the next backend restart. The per-project fields apply on the next sweep.

Gated release manager

Unlike the two engines above, this one isn't per-project — it watches RoboCo's own repository and proposes RoboCo's own releases. It automates cutting a release right up to the decision: a background loop runs the same deterministic readiness sweep a human would (diff since the last tag, conventional-commit classification, semver bump, version-reference completeness, CHANGELOG completeness, a docs-drift check, migration single-head, and the quality gate's state) and, once the change set clears a threshold with a green gate, opens one release proposal and holds it for you.

What it does

The proposal is an ordinary task — owned by the Secretary, held (never dispatched, never started by anyone) — that surfaces in the panel for you to approve or reject with changes. Nothing publishes without that explicit approval.

Mermaid diagram source: flowchart TD A[Interval tick] --> B{Readiness sweep:<br/>commits · gate · docs · migrations} B -->|below threshold or red gate| A B -->|ready| C[Hold ONE release proposal for the CEO] C -->|reject| D[CANCELLED — frees the slot<br/>for a fresh proposal next cycle] C -->|approve| E[ReleaseExecutor: fail-closed] E --> F{Environment ladder set?} F -->|yes| G[Promote head→…→prod<br/>before bumping] F -->|no| H[Bump on the default branch] G --> I[Version bumps + CHANGELOG] H --> I I --> J{Head rung CI verdict green?} J -->|no| K[Abort — nothing committed] J -->|yes| L[Commit + push chore release] L --> M{Release-commit CI green?} M -->|no| K M -->|yes| N[Publish via GitHub REST]

Rejecting frees the slot. A rejected proposal moves to CANCELLED, which the one-open-proposal dedup excludes — so the next readiness pass can originate a fresh proposal instead of the loop deadlocking behind a proposal you already turned down.
Approval runs the fail-closed executor. ReleaseExecutor writes the version bumps across the canonical file set (derived from the previous chore(release): commit) plus the CHANGELOG entry, verifies the head rung's CI verdict (it does not re-run make quality inside the production container), and aborts before committing anything on red. It then commits chore(release): X.Y.Z and pushes, waits for that commit's own CI to go green, and publishes the release through the GitHub REST API rather than the gh CLI. An already-published version is a no-op — approving twice never double-releases.
The release commit uses a configurable bot identity. By default the commit is authored as RoboCo Release Manager <release-manager@roboco.local>; set ROBOCO_RELEASE_GIT_NAME and ROBOCO_RELEASE_GIT_EMAIL to use your own identity. Commit signing is opt-in via ROBOCO_RELEASE_SIGN_COMMITS — when enabled the executor signs the release commit; when unset the commit is unsigned.
The curated [Unreleased] CHANGELOG body is preferred. If the CHANGELOG contains a curated [Unreleased] section, the executor uses that body for the release entry and empties the section after stamping it into the new version. When no [Unreleased] body is present, it falls back to the existing auto-generated conventional-commit summary.
With an environment ladder set, it promotes the full chain first. If RoboCo's own project record has declared an environment ladder (ordered rungs from a head/dev branch down to prod, rather than one default_branch), the executor merges every rung above prod into the prod checkout — head→…→just-below-prod — before bumping versions, so the release commits the fully-promoted state rather than whatever prod happened to already contain. Without a declared ladder, it's the same single-branch behavior as before; there's nothing to promote.
The panel shows real progress, not a silent wait. The execute step runs in the background for as long as the CI wait takes (tens of minutes is normal). The proposal card shows a running badge while it's in flight, and on a failure — a red head-rung CI verdict, red release-commit CI, or an unexpected error — it shows the failure reason inline with a Retry approve & publish action, instead of leaving you watching a card that never updates.

Bounds on origination

Variable	Default	Purpose
`ROBOCO_RELEASE_MANAGER_ENABLED`	`false`	Master switch. When off the loop never runs and no release is proposed. Even on, it only proposes — you approve before anything publishes.
`ROBOCO_RELEASE_MIN_COMMITS`	`8`	Minimum unreleased commits since the last tag before a release is proposed (any feat/security commit also qualifies on its own).
`ROBOCO_RELEASE_MANAGER_INTERVAL_SECONDS`	`3600`	Seconds between release-readiness assessment passes.
`ROBOCO_RELEASE_GIT_NAME`	`RoboCo Release Manager`	Committer name on the release commit.
`ROBOCO_RELEASE_GIT_EMAIL`	`release-manager@roboco.local`	Committer email on the release commit.
`ROBOCO_RELEASE_SIGN_COMMITS`	`false`	Set `true` to GPG-sign the release commit.

Enable it

Settings → Feature Flags carries the global "Gated release manager" toggle. There's no per-project opt-in — it always targets RoboCo's own repository.

Takes effect on the next backend restart

The feature flag persists in the settings store and applies on the next backend restart.

What changes when each is on

With CI-watch on, a background sweep polls each opted-in project's CI on the configured interval; on a red conclusion a fix task appears in that project's backlog (bounded by the caps above) and its cell PM is notified. With the global flag off, nothing polls.
With the dependency-update bot on, a background sweep checks each opted-in project's lockfiles on the configured interval; when an upgrade would change them, an update-dependencies task appears. With the global flag off, nothing runs and no throwaway clone is made.
With the release manager on, a background sweep assesses RoboCo's own release readiness on the configured interval; past the commit threshold with a green gate, one held proposal appears for you to approve or reject. With the global flag off, nothing is ever proposed.

→ Self-healing CI for the single-repo loop CI-watch generalizes · Environment ladders for declaring the head→prod branch chain the release executor promotes · Task lifecycle for what an opened task does once you start it · Environment reference for the full env list · back to Optional subsystems.

llms.txt

Autonomous Maintenance

Multi-repo CI-watch

What it does

Bounds on origination

Enable it

Dependency-update bot

What it does

Bounds on origination

Enable it

Gated release manager

What it does

Bounds on origination

Enable it

What changes when each is on

Next