PATTERN Cited by 1 source

Issue labels as workflow state machine¶

Intent¶

Use the tracker’s native labels as named states for an automated workflow, while retaining workflow evidence and recovery context in the issue timeline. Workers derive the next action from the visible issue instead of from an independent orchestrator database.

Structure¶

issue created
  → label: triage needed
  → automated investigation and proposed repair
  → preview distributed; evidence posted as comments
  → reporter validation
  → label: fix verified
  → automated linked pull request

Astro’s workflow deliberately keeps no separate state beyond those label transitions and the comments it can reread. (Source: sources/2026-08-04-cloudflare-astro-issue-triage)

Required controls¶

Define a small, documented label vocabulary and allowed transitions.
Make every worker idempotent against the current label and prior comments.
Use issue comments or immutable artifacts to record stage output and action provenance.
Restrict sensitive transitions and automated write credentials.
Serialize competing workers or detect transition conflicts; labels alone do not provide concurrency control.

Trade-offs¶

Benefit	Cost
Workflow state is visible to humans and users	Labels can become an underspecified or overloaded state schema
Recovery needs no second database	High-volume workflows can exceed tracker API rate limits
Human override is straightforward	Concurrent actors require explicit idempotency and conflict policy
Native search and reporting work immediately	Detailed stage data must live in comments or linked artifacts

Seen in¶

sources/2026-08-04-cloudflare-astro-issue-triage — Astro uses triage needed and fix verified labels with issue comments as workflow state.