Maintenance mode

With the Hardening preset, kanman looks after the codebase between stories: dependency updates, vulnerabilities, broken links and drift, as a steady, capped trickle of small stories.

Most teams know their maintenance backlog and never get to it. Maintenance mode is the proactive half of kanman: it scans the repository on a schedule and turns safe, behaviour-preserving findings into small stories, inside the same policy, gate and budget as everything else.

Turning it on

Maintenance mode is part of the Hardening preset: choose it under Settings > Policy on the team. Settings > Maintenance shows whether maintenance is on, its limits and the findings, with a Change in policy link to switch the preset. The settings live in the maintenance policy object:

Field Shown as Meaning Hardening default
enabled Status Maintenance on or off true
dripPerDay New maintenance work per day How many maintenance stories and proposals may be filed, and how many maintenance runs may start, per day 2
maxPerRun At most per scan How many findings one scan may file 1
allowedKinds Filed without asking Which kinds of findings become stories without a decision cve, outdated_dep, unused_dep, lockfile_drift, broken_doc_link

How often the scanners run is set by cadence.scannerDays (every 7 days by default). kanman spreads the scans of different teams over these days. Paused teams are not scanned.

What kanman looks for

kanman reads the repositories in the team’s allowed_repos on GitHub or GitLab without cloning them and without writing to them.

Scanners are deterministic tools, not a model’s opinion:

Kind Finds
cve Dependencies with known vulnerabilities
outdated_dep Outdated dependencies
unused_dep Dependencies nothing imports
license Dependency licenses that need attention
lockfile_drift Lockfiles out of sync with the manifest
broken_doc_link Broken links in documentation
oversized_module Modules that grew too large
stale_flag Feature flags that are always on or always off

The dependency scanners cover npm projects.

Coming in a later release

Scanning for unused dependencies and stale feature flags needs a checkout of the repository and arrives in a later release. Support for package managers other than npm arrives later as well.

Reviewers read without changing anything. Each scan runs one of them, in rotation: post-merge follow-ups, an architecture review, documentation drift and test quality. They look at recent runs and a few files. Their findings are reported and reach you as proposals.

The findings appear under Settings > Maintenance, filtered by Open, Filed, Dismissed, Resolved and Duplicates. A scanner finding that a later scan no longer sees is marked resolved.

Guardrails

  • Allowlisted kinds only. Only behaviour-preserving kinds in allowedKinds become stories directly, and only the five kinds of the Hardening default can ever be allowed. They are filed into the team’s Refining column (Backlog if there is none), so they pass the readiness checks and the acceptance spec like any story. Everything else becomes a maintenance proposal. With intake_scope set to humans_only, even allowlisted findings become proposals, so only stories a person accepts are filed.
  • A cap per scan. maxPerRun keeps each scan’s output small and easy to review.
  • No duplicates. Each finding has a fingerprint, so it is stored once and counted when seen again. kanman checks for similar open stories and proposals before filing, and every Monday it cleans up duplicate findings.
  • A steady drip. dripPerDay limits how many maintenance stories and proposals are filed and how many maintenance runs start per day, so feature work keeps priority.
  • Never starved. Findings gain priority with every day they wait, and a finding older than 21 days is served first.
  • Urgent fixes go first. Critical findings, and vulnerabilities rated high, skip the drip and the cap and are filed as expedite.
  • Same gate, same budget. Maintenance stories go through the outcome gate and count toward the team’s budgets like any other story. Their class of service is maintenance.

Proposals for bigger changes

Findings that are not on the allowlist reach the decision inbox as maintenance proposals with kanman’s recommendation: File as story or Dismiss. A dismissed finding stays dismissed.

With maintenance on, a strategist also reads STRATEGY.md, docs/STRATEGY.md or .kanman/STRATEGY.md in your repository every three days and proposes up to three features, each with the goal it serves, its value, effort, risk and alternatives. Each proposal is a Strategy proposal decision: Start intake turns it into a request on the team’s intake, where it is triaged and drafted like any other; Decline is remembered, so kanman does not propose the same idea again. Teams without a strategy file get no proposals.

Last updated: January 1, 0001

Open kanman