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 refines it into a story, another implements it, verifies it, and opens a pull request, and the merge gate merges it once CI is green and nothing in it is dangerous to merge unseen. 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 -->|"needs-maintainer"| Maintainer["Stays open for a maintainer,<br/>who adds refine to take it on"]
  Triage -->|"block"| Closed(("Closed<br/>with a reason"))
  Ask -.-> Triage
  Maintainer -.-> Pipeline
  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,Maintainer 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 four verdicts. On pass, the issue gets refine and enters the normal pipeline. On needs-info it posts exactly what is missing and waits for a reply, then runs again. On needs-maintainer the request is legitimate but outside what the business may ask for: the issue stays open with review, stops re-triggering triage, and a maintainer takes it on by adding refine. On block it closes the issue with the reason. Only block closes. By the third round needs-info is no longer available, so the agent has to decide.

The fourth verdict exists because out-of-scope work used to be closed too, which lost it: a reproducible authorisation defect that passed nine of the ten checks was closed with every label stripped, indistinguishable from junk. The wrong door is not the same as a bad idea.

The eligibility boundary

This check is the load-bearing one. The scope is business policy, so each repository owns it as PRODUCT_SCOPE in its triage worker. The default it ships with is quoted here in full because paraphrasing it tends to soften it:

In scope: user experience and workflows, branding and content, business rules, and business formulas. The issue must describe the desired product outcome rather than prescribe technical means. Out of scope, and blocked even when clear, small, local or testable: architecture, infrastructure, developer tooling, deployment, security, authentication, authorization, data storage, data models, migrations, APIs, service composition, framework adoption, and solution or project structure.

The clause "even when clear, small, local or testable" is the one that keeps the boundary intact. A technical request does not become eligible for the business door by being small, obvious, or easy to test. It goes to a maintainer 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, in the repository's own issue template, with testable acceptance criteria and a Fibonacci estimate, and asks clarifying questions when something is genuinely ambiguous. A story estimated at 8 points or more is split into children of 3 to 5 points, each of which walks the same path on its own. When the story is complete, refinement hands it straight to implementation; a person who wants to hold it back adds future.

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. Health measures every project daily and is deliberately conservative about what it claims. For this phase, three of its areas matter most:

• Delivery follows the DORA definitions: deployment frequency, change lead time and rework rate. The two metrics that need to know a release caused a problem in production are reported as not collected rather than approximated from red pipelines.
• Agentic shows what share of the bot's merged pull requests the merge gate merged on its own, which is the autonomy this phase promises, and what the agents cost in tokens and time.
• Roadmap splits every issue's open time into agent working, waiting on a person, waiting to merge, and queued, which is where the time actually goes.

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. Inside each repository that is one issue, Needs a human, which the workflows' housekeeping job rewrites every six hours: decisions waiting on someone, pull requests the gate parked, stalled work that has used up its retries, and the merge gate's own auto-merge share. Over time, Health's roadmap shows how long issues waited on a person. Roadmap covers both.

The rule behind the digest is retry a failure, report a decision. A crash or a timeout is retried by itself; a verdict an agent reached on purpose is listed for a person and never re-run, because re-running a decision only reproduces it.

Improving the system

The last part of maintenance mode is the loop that maintains the maintainer. A read-only audit runs weekly against the repository's own guardrails and files one issue of findings, labelled refine, so refinement sizes it and splits it into properly sized issues instead of one pull request that has to fix everything. A companion pass closes an audit report once every issue it references is closed, and marks one nobody actioned as stale after 14 days so it stops blocking the next audit.

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.