Pick an option on each card and press Done; your answer goes straight
back to the session. The raiser's pick is marked. "I'm not sure" is a real answer.
1
In plain terms. Who should apply the new time limit to the live morning job, and when? The morning job (7am Central) runs its steps one after another, and one step, the code-map rebuild, just got a bigger time budget. The job's overall limit lives on the scheduler itself, so merging the code does not change it. Applying it means re-registering the schedule, which pauses the job for a few seconds until it is unpaused again. Until it is applied, a slow rebuild night could cut off the last steps of the morning job, including the one that starts the day's PR drives.
The full question, as raised
agent-smith PR #684 raises morning_queue._GRAPHIFY_TIMEOUT 130→160 (workflow code, live on deploy) and register_morning_queue_schedule execution_timeout 210→360 (server-side Schedule, live only on re-register). Live describe 2026-09-30: morning-queue paused=False execution_timeout=3:30:00. _create_or_update sends state=paused=True wholesale, so the rollout is: uv run python -m scripts.register_morning_queue_schedule && uv run python -m scripts.register_morning_queue_schedule --unpause (new --unpause mode in the PR), then a describe() receipt execution_timeout=6:00:00 paused=False. Run it off the 07:00 CT fire. Failure mode if the second half does not land: queue silently paused → --unpause + a line in #alerts. Until applied: 81 (pre-graphify ceilings) + 160 = 241 > 210, so a graphify night that uses its budget ends the queue mid-graphify and nightly-packet never starts the PR drives (main already sits at 211 > 210 at ceilings).
Why, and what was tried
The session raising this recommends: Smith runs it right after the merge Two commands, seconds of pause, reversible, and Smith owns the alert that led here. Tried first, unsuccessfully: Read the live schedule (210 min, unpaused) instead of assuming the code value was live. Considered a state-preserving update so the re-register would not pause the queue, but that changes update semantics all 16 registrars share, so added a --unpause mode (existing precedent) to make the rollout one line. Policy says no production action from a PR-drive wake after a merge without a human ok, so this is raised rather than run.