[kyle-sexton]

Refs: #7901

Summary

ci-workflows#946 (merged as c41e345) gives class=max-turns its own sizing-stop message in report-lane-outcome, in place of the infrastructure-error text. This repository pinned that action at 2476d5d (2026-10-29), so the new message never ran here. This is #7901's ci-workflows fix item 1, made live.

Fix

• All 57 report-lane-outcome@ pins in six workflows move to c41e3457e01c9ff6ca2c3d10e5bf470551383e11 # c41e345 2026-11-01. The action has no later change on ci-workflows main.
• The other 97 ci-workflows pins at 2476d5d (run-claude-cli and the rest) are unchanged, so no unrelated action change comes in.
• pr-verify/workflow.test.mjs's one-commit pin test now requires one SHA for every other ci-workflows action, and one for report-lane-outcome.

Verification

• Grep counts: report-lane-outcome at 2476d5d 57 → 0, at c41e345 0 → 57; other pins at 2476d5d 97 → 97.
• node --test: resolve-config/callers.test.mjs 218 pass; pr-review-main/workflow.test.mjs 39 pass; pr-verify/workflow.test.mjs 31 pass (it failed before the test update); report-check-run/lane-record.test.mjs 7 pass.

Pin choice

c41e345 is the ci-workflows main commit that merged #946. No ci-workflows tag contains it yet: git tag --contains c41e345 is empty, and the newest tag is v0.67.2. The pins it replaces, 2476d5d, are also an untagged main commit after v0.67.2. So pinning report-lane-outcome to a main commit follows this repository's existing ci-workflows pin practice. All 57 report-lane-outcome pins in the repository move: a grep of the head finds none left at 2476d5d.

Remaining

#7901 stays open for its item 4: find out, from the Claude Code CLI or SDK source, what num_turns counts against --max-turns, which explains a run reporting 140 turns under --max-turns 75. The issue's 2026-11-01 host-run comment says that answer is still owed. This PR delivers ci-workflows item 1 together with ci-workflows#946.

Related

• fix(report-lane-outcome): report max-turns as a sizing stop, not an infrastructure error ci-workflows#946

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-01T15:58:10.515880Z	0b00593	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

claude-security-review needs no new review of 0d651c0483aefca54d460046ab0a4e5f7a96da7e: no file of this pull request changed since the review of 0b00593.

Security review: PR #11964, report-lane-outcome repinned to c41e345

No security issues found. I read every hunk in all 7 changed files.

What changed

• In six workflows, every melodic-software/ci-workflows/.github/actions/report-lane-outcome pin moves from 2476d5dde8979eab34374150b7e4b0a2b99f4e88 to c41e3457e01c9ff6ca2c3d10e5bf470551383e11. The six are maintenance-audit-lane-runs.yml, post-merge-test-mutation.yml, pr-review-main.yml, pr-run-activity-read.yml, pr-run-activity-write.yml and pr-verify.yml. Each changed line is a whole-line swap of the SHA and its trailing comment.
• In the changed hunks, no step's if:, with: inputs, continue-on-error or permissions: changes. No new step or new input carries a token or untrusted text.
• .github/scripts/pr-verify/workflow.test.mjs splits the one-pin test into two groups. Every ci-workflows action other than report-lane-outcome must still share one SHA, and report-lane-outcome must share its own. Every ref must still be a 40-hex SHA with a comment.

Trust-control checks

• Trusted-trigger check, lane token, kill switch, signer: none of these files changes (check-trusted-trigger, request-lane-token, check-kill-switch, resolve-config, pr-pipeline.yaml). The pin swap leaves who is trusted and what any token may do unchanged.
• Merge holds: no merge-hold script or pr-merge.yml / pr-require-checks.yml step changes.
• Supply chain: the new ref is a full commit SHA in the owner's own melodic-software/ci-workflows repository, so it is not a floating tag or an outside source. Under the owner's throughput-phase threat model, a repin is a named friction ceremony, not a finding. Pin hygiene otherwise belongs to zizmor's lane.
• Pin test: the test now allows a second SHA. It is a consistency check, not a security gate, and it still rejects any non-SHA ref.

Limits of this review: I could not read the action's contents at c41e345 from here (no network access). The PR says it changes only the class=max-turns stop message, and I did not verify that. The changed workflow lines pass this action no new input.

Spend: none. The change adds no lane runs, turns or billed resources.

critical-findings: 0

[github-actions]

claude-review needs no new review of 0d651c0483aefca54d460046ab0a4e5f7a96da7e: no file of this pull request changed since the review of 0b00593.

Code review: PR #11964, pin report-lane-outcome at c41e345

No findings. I read every hunk in all 7 changed files: one test file and six workflows, all on trusted paths.

What changes

• Every report-lane-outcome@ pin in maintenance-audit-lane-runs.yml, post-merge-test-mutation.yml, pr-review-main.yml, pr-run-activity-read.yml, pr-run-activity-write.yml and pr-verify.yml moves from 2476d5dde8979eab34374150b7e4b0a2b99f4e88 to c41e3457e01c9ff6ca2c3d10e5bf470551383e11. Each pin keeps its comment. No with: inputs or if: conditions change, and no other ci-workflows action pin changes.
• In .github/scripts/pr-verify/workflow.test.mjs, the one-commit pin test now splits the matches. Refs ending in /report-lane-outcome must share one SHA, and every other ci-workflows ref must share another. The "every ref is a SHA pin with a comment" count check still applies to every ref.

Checks I ran with the tools I have (I had no shell, so I did not run any tests)

• A grep under .github/ finds no report-lane-outcome@2476d5d left anywhere, so no pin was missed.
• No other test in the repository requires report-lane-outcome to share a SHA with the other ci-workflows actions. resolve-config/callers.test.mjs and pr-review-main/workflow.test.mjs only check that the ref is a 40-character SHA.
• class=max-turns is already in the class list in .github/actions/report-check-run/lane-record.mjs (line 14). So if the new action version emits that class, the output record still keeps it.
• The test's filter action.endsWith("/report-lane-outcome") matches the captured path .github/actions/report-lane-outcome. If report-lane-outcome refs ended up on more than one SHA, the new assertion would fail.

Claims I could not check: the node --test pass counts and the 57 → 0 / 97 → 97 grep counts come from the PR author. Also, the PR says c41e345 has no unrelated report-lane-outcome changes since 2476d5d. That depends on the ci-workflows repository, which I can't read from here.

Closing issue: none. The PR only references #7901 and closes no issue, so there are no acceptance criteria to check.

Spend: this only changes which version of a reporting action the existing lane runs use. It adds no runs and no billed resources, so there is no cost hold.

[github-actions]

The pr-verify verifier failed head 0b00593c4dc7d21b9759a5bee26c2b32c2dbb134. What it wrote, as data:

What it wrote (26 lines)

Summary: Issue #7901 is linked with `Refs:`, so this PR delivers only part of it. The part it
  delivers is the 2026-10-31 decision's criterion 5: every `report-lane-outcome` pin moves to
  ci-workflows c41e345, the commit that merged ci-workflows#946 (the class=max-turns text). The diff
  does this coherently across six workflows. It also updates the pr-verify pin test so
  report-lane-outcome may use its own single SHA. All upstream test jobs succeeded. The PR fails one
  rule: the body never names the work on #7901 that remains after this PR. The last trusted comment
  says the item-4 answer (what `num_turns` counts against `--max-turns`, from the CLI source) is
  still owed, and a partial delivery must name what remains.
- PR body: the body names the part it delivers ("#7901's ci-workflows fix item 1, made live") but no
  remaining work. The rule for a `Refs:` delivery requires both. Fix: add a section such as
  'Remaining for #7901', naming the item-4 check of what `num_turns` counts against `--max-turns` in
  the CLI source. The issue's 2026-11-01 host-run comment says this answer is still owed. Note that
  ci-workflows criterion 4 was delivered in ci-workflows#946. If nothing on #7901 remains, close the
  issue rather than using `Refs:`.
- .github/workflows/pr-verify.yml: the `report-lane-outcome` pins now sit at c41e345 while every
  other ci-workflows action stays at 2476d5d. The body says c41e345 is the merge of ci-workflows#946
  and not a tagged release. The decision asks for a pin to a ci-workflows release that carries the
  text, so a person should confirm that a main-branch commit pin is acceptable.
- .github/scripts/pr-verify/workflow.test.mjs:12: the relaxed test still requires a SHA pin with a
  comment on every ref, and one SHA each for report-lane-outcome and for the other actions. It does
  not check that the report-lane-outcome SHA is c41e345. This is acceptable but does not lock in the
  target.
- The diff covers only six workflows: maintenance-audit-lane-runs, post-merge-test-mutation,
  pr-review-main, pr-run-activity-read, pr-run-activity-write and pr-verify. This matches the body's
  count of 57 pins. Moving every pin in the repository is a criterion, and that can't be confirmed
  from the diff alone.

This pull request leaves the merge queue, and ci-status holds it out while it carries pr-verify-failed. A pr-verify pass at a new commit removes the label.