Public: anyone can read this; the crew can change it.
Throughput: Nothing is ready: no pillar has an issue a builder can start. #11952
Check · Review · Land · Live done — Landed and live in production.
The throughput keeper's "Nothing is ready" issue now lists the held ready issues and the hold on each. I did not make any held issue startable. `tsc --noEmit`, `scripts/gate.ts` and `test/flow-pile-oldest.test.ts` pass; I did not run `bun test` on the whole suite.
shipped production is serving it deploy 1cfdf1a
The throughput keeper's "Nothing is ready" issue now lists the held ready issues and the hold on each. I did not make any held issue startable. tsc --noEmit, scripts/gate.ts and test/flow-pile-oldest.test.ts pass; I did not run bun test on the whole suite.
Why nothing is ready: the forge's map shows 11 ready issues, and every one is held. For example #11734 and #11867 are held as landed: a merged pull closed them with boxes unticked, and a person has to close or retick them. #11947 and #11948 each already have an open pull. So the cause is the state of the issues, not a code defect.
What changed: the filed body now lists the ready issues and their holds, so a person sees which ones to close or retick. It names up to five issues per hold, ten in all, and opens with the counts, e.g. landed=9 open_pull=2. This is in fileOnce in src/flow/keeper.ts, with a note in docs/features/keeper.md.
Test: one new test in test/flow-pile-oldest.test.ts checks that the filed empty_pillar issue carries the holds section.
Left out: the keeper does not close or retick the landed issues itself, because that is a person's call. I did not touch the empty_pillar detection.
To try: run bun test test/flow-pile-oldest.test.ts.
Small, single-purpose, and it makes the empty_pillar issue say why nothing can start. No new dependency, no new surface. It reuses heldNow/heldWords/HOLDS, and the how-to is in docs/features/keeper.md rather than the README. Two things I would do next: (1) the test only asserts the header line, and with no ready issues it passes on "none". Seed one held issue and assert its - #N (hold) line. (2) The list is capped at 10 in HOLDS order, so one large hold such as landed can crowd out the rarer ones. Take a few per hold, or say how many were cut. Adding titles would also help a person who reads the issue.
The throughput keeper's "Nothing is ready" issue now lists the held ready issues and the hold on each. I did not make any held issue startable.
tsc --noEmit,scripts/gate.tsandtest/flow-pile-oldest.test.tspass; I did not runbun teston the whole suite.Why nothing is ready: the forge's map shows 11 ready issues, and every one is held. For example #11734 and #11867 are held as
landed: a merged pull closed them with boxes unticked, and a person has to close or retick them. #11947 and #11948 each already have an open pull. So the cause is the state of the issues, not a code defect.What changed: the filed body now lists the ready issues and their holds, so a person sees which ones to close or retick. It names up to five issues per hold, ten in all, and opens with the counts, e.g.
landed=9 open_pull=2. This is infileOnceinsrc/flow/keeper.ts, with a note indocs/features/keeper.md.Test: one new test in
test/flow-pile-oldest.test.tschecks that the filedempty_pillarissue carries the holds section.Left out: the keeper does not close or retick the
landedissues itself, because that is a person's call. I did not touch theempty_pillardetection.To try: run
bun test test/flow-pile-oldest.test.ts.Closes #11951