Routines

Describe it, dry-run it, leave it

The intended shape: no YAML to author, you write the sentence and Drums schedules it, shows you the plan, and reports what it did. None of that is wired up yet.

$ drums routine "every night, run the test suite five times
  and tell me which tests failed without a code change"

The design: routines would run under the same boundaries as repairs, and one that touches an always-ask path — customer data, billing, permissions, infrastructure — would propose and wait rather than act, with every run reporting what it excluded and why. None of this exists today — there is no scheduler and no drums routine command. What stops Drums today is ctrl-c or SIGTERM on drums watch: it tears the watch down immediately, cleaning up its worktrees and killing any in-flight agent process groups.

Dependency upgrades

Patch-release bumps run against your real test suite, landing as one pull request containing everything that passed.

When to reach for it

• Upgrades you already do by hand every sprint and would rather never think about again.
• You want the failures separated out rather than blocking the whole batch.

Describe it

$ drums routine "every monday, upgrade any dependency with a
  patch release, run the full suite, and open one
  PR with everything that passed"

Try it before it runs

$ drums routine run --dry dependency-upgrades

Flaky test hunt

Reruns the suite overnight, finds tests that fail without a code change, and proposes quarantining them with the evidence attached.

When to reach for it

• A suite people have started re-running instead of trusting.
• You want the flake list to arrive as a proposal, not as a Slack argument.

Describe it

$ drums routine "every night, run the test suite five times and
  tell me which tests failed without a code change
  in between"

Try it before it runs

$ drums routine run --dry flaky-tests

Dead feature flags

Finds flags that have been at 100% or 0% long enough to be decided, and proposes removing the dead branch.

When to reach for it

• A codebase where flags outlived the launches they guarded.
• You want the removals reviewed one at a time, not as a 40-file sweep.

Describe it

$ drums routine "on the first of every month, list feature flags
  that have been fully on or fully off for 60 days
  and open a PR removing the dead branch"

Try it before it runs

$ drums routine run --dry dead-flags

Audit export

Every automated change in the period — its chain, its approvals, its reversions — collected into one signed document.

When to reach for it

• Regulated work where a client or an auditor will ask what changed and who approved it.
• You want the export to fall out of the record instead of being assembled from screenshots.

Describe it

$ drums routine "on the first of every month, export every change
  Drums made last month with its evidence chain and
  approvals"

Try it before it runs

$ drums routine run --dry audit-export