Tasks grouped by the problem they solve. Each names the trigger that starts its runs, what a run does, and what it triggers next. Most factories start as one of these and grow by chaining the next.
A new lint rule (or a stricter type setting) is switched on, but only some files pass it. The rule enforces on the passing files, and the failing ones sit on an exception list.
Ratchet task
Trigger: a daily clock.
Does: takes one file off the exception list, fixes it until the stricter check passes, and opens a PR.
Triggers: an automated review run. Once the exception list is empty, the ratchet run has nothing to take and the migration is done.
One small PR a day keeps human review cheap, and the check only ever gets stricter.
A monitor (slow queries, error rates) is a ticket source. It files a ticket per problem, and comments on the open ticket instead when it sees the same problem again. After a fix merges, it reopens the ticket if the problem persists.
Does: files the failing log as a ticket, and attempts a fix as a PR when the failure is fixable.
Triggers: an automated review run. A failure in a fix run’s own work triggers nothing, so fixes never chain. Because the fix changes the factory itself, it always gets human review.