Twinned from https://github.com/cfsh/ninefold/issues/965 by tools/beads/import_github.py's reconcile pass.
Suggestions from ninefold-reviewer's review of #962
Advisory, non-blocking (CONVERGED) — one residual worth a note for whoever next touches this area.
apply()'s #941/#938 fix depends on a fetch that can silently go stale as the repo grows. design_docs/tools/operationalize_design.py, apply(): issues_by_number = {i["number"]: i for i in gh.issue_list(state="all")}, added to look up the real state of a hand-filled, pre-convention Issue cell (the #941/#938 fix). Gh.issue_list (tools/github_live/gh.py) defaults to limit=500, and gh issue list returns newest-first — so once the repo's total issue count grows enough that a referenced pre-convention issue falls outside the newest 500, issues_by_number.get(issue_number) silently misses it and the code falls back to issue_state = "OPEN" — reproducing #941's exact bug for old issues, silently, with no error.
Checked live at review time (2026-08-15): total issue count is 524 (search/issues?q=repo:cfsh/ninefold+type:issue), and gh issue list --state all --limit 500 currently returns down to issue #94 — so today's two fixture cases (#756, #893) are both inside the window. But the margin is already thin (24 issues from truncating), and this is pre-existing behavior shared with tasks.list_task_issues (same gh.issue_list(state="all") call, same default limit), not something #962 introduced — it's just the second call site now leaning on the same fragile default for the same class of correctness guarantee.
Fix, whenever someone's next in this area: either raise issue_list's default limit well past any realistic issue count, or paginate with --search/cursor-based fetch, or (cheaper) add a single-issue lookup path (gh issue view <n> --json state) for the handful of pre-convention cells instead of fetching the whole repo's issue list.
Default ships if unactioned — file for whoever next touches tools/github_live/gh.py or operationalize_design.py's apply path.
None.
No comments.