fix(workflow-runner): run_execute silently no-ops — the run issue is invisible to it

[chronoai-shining]

Background

First production run that reached the pod. Schedule #5917 dispatched correctly and run issue #5919 was created with the right label and assignee; the dev loop correctly declined it (#5916 working). The runner then did nothing and the schedule was never released.

Pod a086e8a8-1bf3-4926-a3be-d49bf1098635-0:

04:51:59  raiser=workflow-runner.run_start interval_s=86400   cron raiser starting
04:52:11  spawned run_execute/main.lua
04:53:11  dept=workflow-runner.run_execute elapsed_ms=59590   MSG=framework ok
04:53:11  delivery acked

It ran for 59s, exited cleanly, acked, and raised no scheduled_run_result — so run_report never fired and no fkst-cron-run:v1 record was posted. #5919 is still open; #5917 is still fkst-cron-running and will sit there until its watchdog.

That is act_run taking its "not a scheduled run, clean no-op" path: select_run_issue returned nil despite #5919 existing, being open, carrying fkst-cron-dispatch:v1, and being assigned solely to the session creator.

Three defects, in priority order

1. The run issue is very likely invisible to the listing (root cause)

run_execute calls github.issue_list_intake(identity.repo, 50, 30) — the dev-intake listing helper. A run issue carries fkst-workflow-run-*, deliberately not the devloop family (#5893/#5894). If that helper scopes to the intake work-label family, the runner can never see a run issue at all.

This is an error in run_execute: it reuses an intake-shaped helper for a queue that is deliberately not dev intake. Fix by listing on the runner's own label family, or by fetching the run issue directly — the dispatch event already identifies it.

Rule out first, cheaply: confirm what issue_list_intake filters on.

2. The no-op path is silent (why this needed pod logs at all)

select_run_issue returning nil logs nothing. "Looked and found no run" and "never looked" are indistinguishable from outside, which is the expose-don't-swallow rule being violated. The no-op is legitimate — most sessions have no schedules — but it must say so: log the repo, the creator it matched on, and how many candidates it considered.

3. The raiser fires once per day

interval_s=86400. It fires at boot and then daily, so a run issue arriving after boot waits up to 24h. Wrong for a wake-on-run-issue design: the pod exists because a run issue woke it, but the raiser may already have fired before the issue is visible. A boot-once raiser is only correct if the run issue is guaranteed visible at boot — it is not.

Verification Checklist

• run_execute finds a run issue carrying only fkst-workflow-run-*
• Test: a run issue with the runner's label and no devloop label is selected
• The no-op path logs why it found nothing
• A run issue appearing after boot is still serviced
• [scheduled] cron-acceptance — one-time engine proof #5917 completes with a terminal record

Definition of Done

A dispatched run executes and reports, and a run that cannot be found says so.

Blocks #5846
Related to #5719

[chronoai-shining]

Fixed in #5929 — but the root cause in "Three defects, in priority order" §1 was wrong, so recording the correction here rather than leaving a misleading diagnosis in the issue.

§1 was not the cause

run_execute calls github.issue_list_intake(...) — the dev-intake listing helper. […] If that helper scopes to the intake work-label family, the runner can never see a run issue at all.

The issue said to "rule this out first, cheaply: confirm what issue_list_intake filters on." It filters on nothing:

gh issue list --repo <repo> --state open --limit N
  --json number,title,body,updatedAt,labels,assignees,author

libraries/forge/github/entities.lua:388 → issue_list_cli(repo, "open", limit, …). No --label, no --search. And the pod's own child log for the 04:52 tick shows that exact command returning 317157 bytes whose first record is #5919. The run issue was fetched and looked at.

What actually happened

It was rejected one line later, in select_run_issue:

local routed = #assignees == 1
  and creator_login ~= nil
  and tostring(assignees[1]):lower() == tostring(creator_login):lower()

gh returns assignees as objects — {"id":"U_kgDODuiITQ","login":"chronoai-shining","name":"Shining"} — so tostring(assignees[1]) is "table: 0x…", which never equals a login. Every dispatched run was declined as "not routed", for every session, always.

runner_test.lua could not catch it: its fixtures pass assignees = { "alice" }, a bare-string shape the real listing never produces. The helper was green against input it is never given — the same failure mode as #5926, where the test pinned the queue name the department already raised instead of one a consumer listens on.

§2 and §3 were both right

• §2 (silent no-op) — exactly right, and the reason this needed pod logs at all. Now logs repo, creator, and candidate/dispatched counts.
• §3 (daily raiser) — right, and worse than "up to 24h": the boot-once argument holds only for a pod whose only work is the run that woke it. The default manifest watches five work-label families, so the pod stays alive and the next run issue meets a raiser that fired hours ago. Now 5m, which is under FKST_CRON_MIN_INTERVAL_SECS (900s) so detection latency cannot make a run miss its own next slot.

Still open

The last checklist item — "#5917 completes with a terminal record" — needs a session pod running this catalog revision. Nothing in #5929 has been exercised against live GitHub.