3. Maintenance mode

In maintenance mode the people who use the app are the people who ask for changes to it. A department files a bug or a small feature request, an agent picks it up, implements it, verifies it, and opens a pull request that another agent merges once the checks pass. For requests inside the eligible scope, no engineer is involved.

The rest of this page is about what keeps that from being reckless.

Two doors, and access level decides which one

Intake is not gated on job title. It is gated on repository permission, because that is the thing the tooling can actually check.

flowchart TD
  Writer["Write access<br/>engineers, maintainers"] -->|"self-label"| Pipeline
  Outside["Read access<br/>departments, product owners"] --> Triage
  Triage{"Triage agent<br/>10 checks, up to 3 rounds"}
  Triage -->|"pass"| Pipeline["Refine, then implement,<br/>review and merge"]
  Triage -->|"needs-info"| Ask["Questions posted,<br/>author replies, re-triage"]
  Triage -->|"block"| Closed(("Closed<br/>with a reason"))
  Ask -.-> Triage
  classDef door fill:#eef0ff,stroke:#554cff,stroke-width:2px,color:#172033
  classDef gate fill:#fff8e8,stroke:#c75b00,stroke-width:2px,color:#172033
  classDef done fill:#e8f8ec,stroke:#18883c,stroke-width:2px,color:#145a32
  classDef stop fill:#fff0f0,stroke:#ef2929,stroke-width:2px,color:#8b1a1a
  class Writer,Outside door
  class Triage,Ask gate
  class Pipeline done
  class Closed stop

Anyone with write access can label an issue straight into the pipeline, because they are accountable for what they let in. Everyone else, which is how a department user is modelled, goes through triage first. Triage runs ten checks on the issue: whether the template was filled in, whether it mentions secrets or production data, whether it is scoped to one change, whether it touches a dangerous area, whether it duplicates something open, whether it is clear enough to act on, whether a bug has real reproduction steps, whether the acceptance criteria are testable, whether it has cross-cutting impact, and whether it is eligible at all.

It reaches one of three verdicts. On pass, the issue enters the normal pipeline. On needs-info it posts exactly what is missing and waits for a reply, then runs again. On block it closes the issue with the reason. By the third round needs-info is no longer available, so the agent has to decide.

The eligibility boundary

This check is the load-bearing one, and it is quoted here in full because paraphrasing it tends to soften it:

Product-owner intake is limited to user experience and workflows, branding/content, business rules, and business formulas. The issue must describe the desired product outcome, not prescribe technical means. Block requests for architecture, infrastructure, developer tooling, deployment, security/authentication/authorization, data storage/models/migrations, APIs, service composition, framework adoption, solution/project structure, or other technical fundamentals. These require a maintainer-owned technical proposal, even when clear, small, local-only, or testable.

The last clause is the one that keeps the boundary intact. A technical request does not become eligible by being small, obvious, or easy to test. It is refused on category, which means the rule cannot be eroded one reasonable-looking exception at a time.

Note what this makes the intake templates responsible for. The bug report asks for severity, frequency and reproduction steps. The feature request asks for current behaviour, the problem, the proposal, and a scope that has to be Small or Medium. Anything larger is redirected to a planning issue, which is to say back into discovery.

Turning a request into a story

An eligible issue is rarely written the way an implementing agent needs it. A refinement pass rewrites it as a user story grounded in the actual codebase, with testable acceptance criteria, and appends clarifying questions when something is genuinely ambiguous.

That produces a conversation rather than a handoff. The agent asks, the product owner answers in a comment, and the issue is refined again with the answers. It can go round more than once before both sides converge, and only then does implementation start.

Measuring it honestly

Maintenance mode generates a lot of activity, which makes it easy to mistake volume for progress. Project Health collects delivery and agent metrics per project and publishes them, and it is deliberately conservative about what it will claim. The short version is below, and the full treatment is in Analytics with DORA.

• Throughput and stability follow the DORA definitions: deployment frequency, change lead time, and rework rate. Two of the five modern DORA metrics depend on knowing that a release caused a problem in production, which a repository cannot answer, so they are reported as not collected rather than approximated from red pipelines.
• Profiles, not a single grade. The 2025 DORA team profiles are built from throughput, stability and team well-being. Well-being needs a survey, so a project is placed on two axes and reported as the set of profiles consistent with that. Guessing well-being from commit timestamps costs more trust than the number is worth.
• Small samples are refused. Below five releases in a period, the project is not placed on the axes at all. A rate computed from ten events moves too much when the eleventh arrives.
• Agent cost is reported in tokens, not money. Rates change, differ per account, and go stale in a committed file. Tokens are what the agents actually spend.
• Totals are labelled as floors. A run only reports usage if it reached the model and uploaded its artifact, so the site prints "measured N of M" instead of presenting a partial sum as complete.

The governing rule is worth stating on its own: a missing metric is a fact about the data, not a gap to fill with a plausible number.

Human attention is the thing that runs out

Once agents handle implementation, throughput stops being the interesting number. What matters is how much still needs a person, so that gets its own view: the issues labelled as needing human attention and the open pull requests, per project, refreshed hourly.

Bot authorship is counted separately, and that separation is the whole point. Seven open pull requests that are all dependency bumps are not seven things needing a person, and reporting them as one number would make a quiet project look busy.

Improving the system

The last part of maintenance mode is the loop that maintains the maintainer. Read-only audits run on a schedule against the repository's own guardrails, and file their highest-severity findings as ordinary issues that re-enter the same pipeline. A companion pass closes the audit reports whose findings have all been resolved.

Nothing about that is special-cased. An audit finding is a bug report written by an agent, and it goes through refinement and implementation like any other. The system's own defects are worked the same way as the product's.