CI: chain to the lowest open task above the merged one; T30 note for the closed PR #120

.github/workflows/claude-pipeline.yml

@@ -238,11 +238,15 @@ jobs:
             gh workflow run claude-triage.yml || true
             exit 0
           fi
-          next=$(printf 'T%02d' $((10#${task#T} + 1)))
+          # next task: the lowest open TNN issue above the merged one. Usually T(NN+1); when
+          # that id is already closed (a task done out of order, or tasks renumbered), the
+          # chain continues with the next open id instead of stopping.
           issue=$(gh issue list --state open --label task --limit 100 --json number,title,labels \
-            --jq '[.[] | select(.title | startswith("'"$next"' — "))][0]')
-          if [ -z "$issue" ] || [ "$issue" = "null" ]; then echo "No open task issue for $next."; exit 0; fi
+            --jq --argjson nn "$((10#${task#T}))" \
+            '[.[] | select(.title | test("^T[0-9]{2} — ")) | . + {id: (.title[1:3] | tonumber)} | select(.id > $nn)] | sort_by(.id) | .[0]')
+          if [ -z "$issue" ] || [ "$issue" = "null" ]; then echo "No open task issue after $task."; exit 0; fi
           n=$(jq -r .number <<<"$issue")
+          next=$(printf 'T%02d' "$(jq -r .id <<<"$issue")")
           if jq -e '.labels | map(.name) | index("on-hold") or index("external")' <<<"$issue" >/dev/null; then
             echo "Issue #$n ($next) is on-hold or external; not chaining."; exit 0
           fi

STATE.md

@@ -178,3 +178,11 @@ kernels; the §5 item 5 recommendation is withdrawn). GitHub: issues #22–#27
 renamed to the new titles, #22 loses `on-hold`, new task issues for T28–T31;
 #96, #108–#110 and #112 labelled `triaged` (#108 → T22, #109/#110 → T26,
 #112 → T31). The chain resumes with T22 once PR #113 (T23) has merged.
+
+What happened instead: the issues were renamed before #114 reached `main`,
+and the pipeline chains `T(NN+1)` from the merged PR's title, so #113 (T23)
+started T24 with the old task text (PR #120, closed; branch kept, note under
+T30). The pipeline now continues with the lowest open task id above the
+merged one, so T22 → T24 works once T23 is closed; T22 itself has no
+predecessor merge to chain from and is started by labelling #22
+`claude:implement`.

TASKS.md

@@ -3187,6 +3187,13 @@ feature, not a performance one. The ordering cache (analysis under a stored
 permutation ran in 3.6 s against 12 s for a fresh METIS analysis) is the part
 MadNLP benefits from.
 
+**Owner note (PR #120)**: a pipeline run chained after T23 implemented this
+task under its former number before the renumbering reached `main`; the PR
+was closed, but its branch `task/T24-nd-tree-ordering-cache` holds twenty
+minutes of work (`src/symbolic/ndtree.jl` with the tree export/import and a
+canonical supernode postorder, `test/test_ndtree.jl`), unreviewed and without
+CI. Start from it or from scratch; it was not checked against this text.
+
 ### T31 — oneAPI and Metal extensions, allocation-free KA dense fallbacks (issues #112, #53)   `[ ]`
 
 The remainder of T23, split off by owner decision when PR #113 delivered the