docs(next): point drive runs at #174 instead of human-blocked work

[kjgbot]

ops/NEXT.md currently points at the review-swarm credential. I wrote that package, and it has produced a loop.

Four consecutive drive runs have read it, correctly concluded they are blocked, and each written a NEEDS_HUMAN saying so — #199, #202, #207, #208. Minting a Cloud credential and storing an Actions secret are not agent-permitted, and the Lead additionally may not edit the gate that judges its work. So every run turns into a report about being unable to run.

That is four cycles spent re-deriving one fact, and it is my fault for aiming the package at work no agent can finish.

What this points at instead

#174 — llm::sigkill_sweep_covers_before_and_between_the_rung_b_steps hangs intermittently, reopened today with fresh evidence:

main, cloud-runtime-artifact.yml, last 8 runs: 7 success, 1 failure
panicked at relayflowd/tests/crash_resume/llm.rs:121:27

No credential, no gate access, kernel-only. And it reproduces at roughly one in eight, so it is tractable by repetition rather than by insight.

The package carries the trap that made this look like a regression earlier today: the failure rate did not change when seven commits landed within ten minutes — the sample size did. A shell-only commit failed while the very next commit passed with identical kernel code. Without that context a run would spend its cycle bisecting a regression that does not exist.

Definition of done requires proving a fix by repetition (30 consecutive runs), and explicitly permits stopping if it cannot be reproduced, because a hang nobody reproduced is not fixed by a change nobody can test.

Collision note

ops/NEXT.md is also rewritten by #208, and ops/NEEDS_HUMAN.md by both #207 and #208. Those two disagree with each other on the credential design, so they need reconciling regardless; this PR changes only NEXT.md and takes no position on that argument.

The credential decision is still open and still the thing blocking gate 3 — this just stops drive runs from rediscovering that four more times while it waits.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 41807889-49c2-453d-ad54-b2418af1dead

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="ops/NEXT.md">

<violation number="1" location="ops/NEXT.md:32">
P3: The prose says "Line 121 is the `no step.dispatch after resume` path", but at current head the `panic!` emitting that message is on line 122 (`llm.rs:122`), and line 121 is the `Ok(dispatch) => dispatch,` success branch. The quoted stack trace (`llm.rs:121:27`) is from a past run and is fine as quoted evidence, but the present-tense instruction will point an agent at the wrong branch. Drop the hard-coded line number (or fix it to 122) so the dock-up line and the actual panic site agree.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: The prose says "Line 121 is the no step.dispatch after resume path", but at current head the panic! emitting that message is on line 122 (llm.rs:122), and line 121 is the Ok(dispatch) => dispatch, success branch. The quoted stack trace (llm.rs:121:27) is from a past run and is fine as quoted evidence, but the present-tense instruction will point an agent at the wrong branch. Drop the hard-coded line number (or fix it to 122) so the dock-up line and the actual panic site agree.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At ops/NEXT.md, line 32:

<comment>The prose says "Line 121 is the `no step.dispatch after resume` path", but at current head the `panic!` emitting that message is on line 122 (`llm.rs:122`), and line 121 is the `Ok(dispatch) => dispatch,` success branch. The quoted stack trace (`llm.rs:121:27`) is from a past run and is fine as quoted evidence, but the present-tense instruction will point an agent at the wrong branch. Drop the hard-coded line number (or fix it to 122) so the dock-up line and the actual panic site agree.</comment>

<file context>
@@ -1,85 +1,84 @@
 
-Also landed: #203 (whole-line verdict matching, `jq -er` on the poll response),
-#202 (a missing reviews directory yields `MISSING` rather than a `find` error).
+Line 121 is the `no step.dispatch after resume` path — the worker never receives
+a dispatch after the daemon is SIGKILLed and resumed. The comment above it
+already attributes this to #174 and captures a daemon-state dump precisely
</file context>

Suggested change

	Line 121 is the `no step.dispatch after resume` path — the worker never receives
	The `no step.dispatch after resume` path is the panic that the comment above it attributes to #174 — the worker never receives