# Label Velocity - **Command:** `lore label-flow ` - **Confidence:** 78% - **Tier:** 3 - **Status:** proposed - **Effort:** medium — self-join on resource_label_events, percentile computation ## What For a given label pair (e.g., "needs-review" to "approved"), compute median and P90 transition times using `resource_label_events`. Shows how fast work moves through your process labels. Also supports: single label dwell time (how long does "in-progress" stay applied?). ## Why Process bottlenecks become quantifiable. "Our code review takes a median of 3 days" is actionable data for retrospectives and process improvement. ## Data Required All exists today: - `resource_label_events` (label_name, action, created_at, issue_id, merge_request_id) ## Implementation Sketch ```sql -- Label A → Label B transition time WITH add_a AS ( SELECT issue_id, merge_request_id, MIN(created_at) as added_at FROM resource_label_events WHERE label_name = ?1 AND action = 'add' GROUP BY issue_id, merge_request_id ), add_b AS ( SELECT issue_id, merge_request_id, MIN(created_at) as added_at FROM resource_label_events WHERE label_name = ?2 AND action = 'add' GROUP BY issue_id, merge_request_id ) SELECT (b.added_at - a.added_at) / 3600000.0 as hours_transition FROM add_a a JOIN add_b b ON a.issue_id = b.issue_id OR a.merge_request_id = b.merge_request_id WHERE b.added_at > a.added_at; ``` Then compute percentiles in Rust (median, P75, P90). ## Human Output ``` Label Flow: "needs-review" → "approved" Transitions: 42 issues/MRs in last 90 days Median: 18.5 hours P75: 36.2 hours P90: 72.8 hours Slowest: !234 Refactor auth (168 hours) ``` ## Downsides - Only works if teams use label-based workflows consistently - Labels may be applied out of order or skipped - Self-join performance could be slow with many events ## Extensions - `lore label-flow --dwell "in-progress"` — how long does a label stay? - `lore label-flow --all` — auto-discover common transitions from event data - Visualization: label state machine with median transition times on edges