Public: anyone can read this; the crew can change it.
A pull serves flow when its issue carries the `flow` label, not only when it is on a hard-coded list #6505
Check · Review · Land · Live done — Landed and live in production.
`readOpeners` now counts a pull as flow when the issue it closes, or one it waits on, carries the label `flow` in any case. The listed numbers in `FLOW_ISSUES` still count too. `bun x tsc --noEmit` and `bun test test/flow-openers.test.ts` pass. I did not run the rest of the check here.
shipped production is serving it deploy c3de1ab
Does what the issue asks: a pull closing an issue labelled flow (any case) now counts as flow, and the dependency walk starts from labelled issues too. The label join is parameter-free SQL, the publicOnly rule still applies to the seed, and the test covers labelled (as Flow), unlabelled, and cross-repo cases. Preview answers 200; no UI or door change, so nothing for the terminal or README. Two next steps: (1) rewrap the doc comment at src/flow/openers.ts:5, which is now one overlong line, and note that FLOW_ISSUES remains as a fallback; (2) add a test that an issue waiting on a flow-labelled one is flow, so the label seed is proven through the recursion.
readOpenersnow counts a pull as flow when the issue it closes, or one it waits on, carries the labelflowin any case. The listed numbers inFLOW_ISSUESstill count too.bun x tsc --noEmitandbun test test/flow-openers.test.tspass. I did not run the rest of the check here.flowCTE insrc/flow/openers.tsnow also matches issues with aflowlabel, usingl.name = 'flow' COLLATE NOCASE. Dependencies are followed from there as before.publicOnlyrule applies to the labelled issues as well.test/flow-openers.test.tshas a pull closing an issue labelledFlowin a second repository counted as flow, and a pull closing an unlabelled issue there not counted.FLOW_ISSUESstays as it is. It is still the numbers of one repository, so it can only over-count elsewhere. Removing it is a separate change.Closes #6498