census: priority-sort pipeline breaks on milestone-assigned issues — stray 'milestone' output, wrong ordering, daemon ticks die to action=none (loop idle since 2026-07-21)

[robercano-ghbot]

Observed (2026-07-24)

Since #173's census refactor merged (11d4ac2, 2026-07-21 ~13:52Z), the daemon has dispatched ZERO drivers — every tick records action=none cadence=WATCH with empty reason — while an interactive census reports open_prs=0, planned_issues=9, advance_ready=87.

Three linked symptoms, all appearing with milestone-assigned planned issues (the v0.3.0 milestone was populated 2026-07-21, same day):

1. Stray bare milestone lines in census stdout (three of them, matching the number of… something — reproduce with GATES_FILE=.claude/self/gates.json bash .claude/scripts/loop-census.sh).
2. Priority ordering wrong: priority:critical /orchestrator:sync v2 — one sanctioned migration path to bring consumer repos current #141 should be advance_ready ahead of priority:high Go-public checklist: README with cockpit demo, LICENSE, contribution notes, publishing story #87; census emits advance_ready=87.
3. Daemon-context census apparently fails/degrades harder than interactive (ticks show WATCH which is also the loop-daemon default when the cadence line is missing — consistent with the census erroring out mid-run under set -euo pipefail in the systemd env).

Suspected mechanism

The #173 pipeline builds a TSV from gh issue list --json number,title,labels + awk rank + sort. gh 2.4.0's JSON/template output for issues WITH a milestone may inject an unexpected field/row shape, corrupting the TSV: corrupted rows drop or misparse (→ #141 skipped, stray 'milestone' tokens printed), and under some env the parse kills the script.

Fix expectations

• Reproduce interactively first (the stray lines reproduce reliably); identify the actual gh output shape difference; make the TSV construction robust to it (explicit field extraction, no positional assumptions).
• Restore correct (priority rank, number) ordering incl. milestone-assigned issues; add a loop-census.test.sh fixture where planned issues carry milestones (the Backlog priority: priority:* labels drive census ordering #173 tests clearly lack one).
• Ensure census cannot die mid-run into a silent action=none: any gh/parse failure must surface a visible census_error line (cockpit-visible) rather than an empty-reason none-tick.
• Verify the daemon path: after merge, the next real tick must dispatch (ledger line) — document in the PR how this was validated.

Related: #173 (introduced), #174 (milestone-scoped census will build on this same parsing — fix must land first), the 07-21→24 idle gap.

🤖 Generated with Claude Code

[robercano-ghbot]

Issue #187's feat/issue-187-* branch has stalled and already been resumed 2 times without landing a PR. The loop will not retry it automatically -- labeling needs-human. Address it by hand, then either close it out or clear its entry in .claude/state/loop-resume-attempts.json to let the loop resume.