Regenerate for needs_approval's new signature, and readiness at 6,080

[arpanghoshal]

Pairs with ctrlrun#191, which builds two of SPEC-v0.10 §9.4's three rows. Same branch name on
both sides, so CI here checks against that kernel branch rather than against main.

Replaces ctrlrun-docs#25, whose kernel pair was merged out from under it, the branch it was
named for no longer exists, so its check would fall back to main and fail on a count that is ten
ahead. #25 should be closed rather than merged.

What changed

ctrlrun.adapter.needs_approval now takes task= and hop=:

-def needs_approval(control, action, arguments, *, resource=None) -> bool
+def needs_approval(control, action, arguments, *, resource=None, task=None, hop=None) -> bool

Its API page picks up the signature and the paragraph saying what they are for: without them the
predicate evaluated against the receiver's whole candidate set while execute evaluates against the
hop alone, so it answered "a human is needed" for a call execute then refuses. banner.mdx moves
with it because the two share a source line range.

Readiness 6,070 to 6,080, T128c, T506b, T480 on both sides, T502a and T502b, and the
frozen-name list growing by two rows.

Stacked, and the merge order

Base is tests/t483-t486 (#24), not main, because the count is a measurement of ctrlrun main and
it moves twice:

	kernel	docs	count
1	#189, #190, both merged	#24	6,070
2	#191	this	6,080

#24 → ctrlrun#191 → this. #24 first matches main to main as they stand, so docs main is
never briefly wrong between the two.

And one guard CI was not running

render_readiness.py's docstring calls --check "what CI runs". CI did not run it. That is the
sentence one level up from the comment beside the audit step: a guard CI does not run is prose.

The test count is the one figure on the site that is a measurement rather than a claim, and
nothing in CI re-took it. The pytest check compares the embedded block against the stored
generated/readiness.json, so the page and the state file agreed with each other while both drifted
away from the library. Right now they are four apart: the site says 6,066, ctrlrun main
collects 6,070. That is how today's count drifted through three PRs without anything going red.

It cannot flap between a paired kernel and docs merge, which is why it is safe to add mid-stack
rather than after. The count is a floor: --check fails when the suite has fewer tests than
the page claims and passes when it has more, so a kernel PR that adds tests leaves docs main green
until its docs pair lands. Verified both ways against real checkouts, docs main against kernel
main: 0 drifted; this branch against ctrlrun#191: 0 drifted.

test_ci_runs_the_three_checks_and_the_drift_check reads the workflow, so the list and the job
cannot disagree.

Checked

All seven generators, 19 recipes, 0 drifted, 83 pages, claims re-pointed 0, unresolved 0. The
kernel worktree came back clean after the cookbook write, which is the check that would have
caught the SPDX-stripping defect the release pass found. Whole docs suite green against ctrlrun#191.

Not merging.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: b56a4710-d54d-49be-9de3-f3b3c4b0f68d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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.}