[kyle-sexton]

No related issue: owner decision Q22 (2026-10-22)

Summary

This gives the lanes new unattended power. pr-unblock's fix-ci will now run a model on PRs that a person opened, not only on lanes App PRs, and push fix commits to those branches. Without anyone asking, it picks up a non-draft PR from an account listed in the new top-level adoption.owner-ids (this repository lists kyle-sexton, user id 153232337) when all of these hold:

• the PR is a same-repository PR into main;
• it has no do-not-merge, needs-human or tracker human-gated label (config.role_labels["human-gated"] in the base .work-item-tracker.json) and no body line starting Hold:;
• its updatedAt and its head commit's committer date are both at least adoption.idle-hours (24) old;
• its ci-status failed.

This is the fix-ci half of Q22. The pr-merge half reads the same adoption section and lands separately.

docs/conventions/pr-pipeline.yaml is a lane-power file, so a human merges this PR.

Fix

• fix-ci-dispatch.mjs:
  • LIST_QUERY also selects ... on User { databaseId }, updatedAt, body, and the head commit's committedDate. pushedDate is not used: GitHub deprecated it and it is mostly null.
  • skipReason admits an adoption.ownerIds author once both dates are idleHours old. A missing or unreadable date counts as not idle.
  • For owner PRs only, skipReason also skips a body line starting Hold:. Lanes App PRs carry Hold: a human merges this (report-outcome.mjs:99), which holds the merge, not a CI fix, so their rules are unchanged.
  • Default ownerIds is [], so nothing is adopted when the section is absent.
• dispatch.mjs: main takes an injectable loadAdoption (default loadBaseAdoption) and passes adoption and now to dispatchCiFixes.
• The tracker's human-gated label (read by baseHumanGatedLabel, the way pr-merge resolves it):
  • It is read only while adoption.owner-ids lists anyone. While it is read, it is added to the hold labels for every fix-ci candidate, so it also holds a lanes App PR that carries it. This is intended: the human-gated label holds any PR. With owner-ids empty the file is not read and lanes App PRs keep the hold labels they had (do-not-merge, needs-human).
  • A base .work-item-tracker.json that is not JSON holds only the adopted owner PRs: each is skipped with "base tracker config unreadable, so its human-gated label is unknown" (adoption.held in skipReason). Lanes App PRs still get fix-ci, and the dispatcher run fails so the broken file shows.
• resolve-config.mjs: adds adoptionFromBase, built like redMainFromBase. This file is not in BROKER_PATHS, and resolve.mjs is unchanged.
• Schema: adds the adoption object (idle-hours integer from 1 to 720, default 24; owner-ids unique positive integers, default []). pr-pipeline.yaml sets the section.
• Docs:
  • The README gets a new ## Adoption section and an updated fix-ci scope paragraph.
  • The fix-ci comment in pr-run-activity.md and two comments in pr-unblock-dispatch.yml now name the new scope.
  • Adds a changelog fragment.

Downstream checks (none refuses an owner-authored head):

• check-trusted-trigger.mjs:812 and the broker's authorize.mjs:184 require only that the author is on the trusted-actor list, and kyle-sexton is listed.
• The broker's dispatcher.mjs checkDispatcher has no author key on the dispatch path.
• The fix-ci and apply-patch applies-when checks only labels and draft state.
• apply-patch.mjs TARGETS.pr checks for a same-repository head, draft state, and hold labels. It has no author check.
• fix-ci-context.mjs countFixRounds counts only the App's trailer commits, so an owner PR with zero App commits starts at 0 rounds. The existing stranger-commit test covers this.
• The broker reads the schema from the tip of main along with the config (binding.mjs TRUST_FILES), so a new top-level key needs no pin bump. No file in BROKER_PATHS changed, so the body names no broker pin.

A consequence to know: fix-ci's own push restarts the idle clock, so an owner PR gets at most one fix round per idle window.

Verification

• I wrote the new tests first and watched them fail (not opened by the lanes App, and the missing on User field in the query):
  • fix-ci-dispatch.test.mjs:
    • an owner PR idle 25h with a failed ci-status is dispatched;
    • idle 2h is skipped with the exact reason; 25h/2h and 2h/25h are both skipped;
    • an owner draft, either hold label, a Hold: line, an unlisted user, an unreadable date, or no adoption list means no dispatch;
    • a fresh lanes App PR with Hold: a human merges this is still dispatched.
  • dispatch-limits.test.mjs: the live config adopts the owner PR end to end, and the same config with the adoption section removed does not. A mapped human-gated label holds an adopted PR. Under a malformed tracker file, lanes App PR 63 is dispatched and an idle owner PR is not (exit 1); with no owner-ids the file is not read (exit 0). This test was rewritten first and failed before the fix.
  • fix-ci-dispatch.test.mjs also covers adoption.held, and an adopted owner PR whose ci-status failed on infra only is left to the reconciler, as lanes App PRs are.
• node --test at the current head over .github/scripts/pr-unblock, .github/actions/resolve-config and .github/scripts/branch-cleanup: 1118 pass, 0 fail. Earlier results:
  • .github/scripts/pr-unblock: 445 pass, 0 fail.
  • .github/actions/resolve-config: 552 pass, 0 fail.
  • check-trusted-trigger 298, check-wip-cap 29, report-check-run 99, and pr-merge/refire-refused 22, all pass.
  • scripts/check-convention-yaml.test.sh: 43 pass.
• markdownlint is clean, and the pre-push check-affected passed.
• scripts/read-runner-dispatcher-gate.test.sh fails the same way on main (runner-policy not installed locally).

Related

• Owner decision Q22 (2026-10-22); the pr-merge half is a separate PR that reads the same adoption section.
• ADR 0051

🤖 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-10-22T03:01:11.715715Z	6a27e31	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-review reviewed 5db81aedc745a713dd03fed5a435f9df2766d59d: 0 finding(s), 0 as inline comments.

Code review: PR #8997 (fix-ci adopts idle owner PRs)

I found nothing to flag, so I posted no inline comments. This is a read-through of the diff. I did not run the test suites; the PR body's test counts are author-claimed and unverified by me.

What I checked

• Gate logic in fix-ci-dispatch.mjs:
  • A missing or unparseable date makes Date.parse return NaN, so <= since is false and the PR counts as not idle.
  • The head-commit oid must match headRefOid.
  • A null author is skipped as unlisted. The author id decides, never the login.
  • A lanes App PR keeps its old path: no idle wait, and a Hold: line does not hold it.
• Hold: regex: I compared HOLD_LINE with BODY_MERGE_HOLD_RE in plugins/source-control/skills/babysit-prs/scripts/babysit_merge.py:230. The JS lookbehind form matches the same line starts as Python's (?:^|\r) with re.M. The claim of the same reading holds.
• Human-gated label: baseHumanGatedLabel and humanGatedLabel follow the jq in .github/workflows/pr-merge.yml (label trimmed, needs-human when absent or empty). The base checkout in pr-unblock-dispatch.yml is .base at refs/heads/main, so .base/.work-item-tracker.json is the file read.
• Unreadable tracker config: this holds only adopted owner PRs, fails the run through fixes.failed, and still lets lanes App PRs through. The tests cover it.
• Config wiring: adoptionFromBase follows redMainFromBase. The schema bounds idle-hours (1 to 720) and requires owner-ids to be unique positive integers. The default is no owners, so nothing is adopted when the section is absent.
• Manifests: no plugin.json or marketplace.json changed, so there are no manifest <field> lines. The bump: minor fragment fits an added config section.
• Closing issue: the PR states No related issue: owner decision Q22, so there are no acceptance criteria to check. I did not read any decision record for Q22.
• Embedded text: the PR context holds no directives aimed at the reviewer.

Observations only (not findings)

• The PR and the changelog both state that, while owner-ids is non-empty, the tracker's human-gated label also holds lanes App PRs from fix-ci. That is a behaviour change for existing PRs. It is documented and tested, and the PR labels it as a human-merge lane-power change.
• The committer date is set by whoever makes the commit, so a backdated commit can satisfy the idle test. The adoption list limits this to trusted owner accounts.

[github-actions]

claude-security-review reviewed 5db81aedc745a713dd03fed5a435f9df2766d59d: 0 finding(s), 0 as inline comments.

Security review: PR #8997 at 5db81ae

Findings: 0

PR #8997 lets pr-unblock-dispatch start fix-ci on an idle PR opened by an account listed in a new top-level adoption config section, as well as on lanes App PRs. I read all 12 changed files and the downstream workflows that consume the dispatch.

What I checked

• Owner list. adoption.owner-ids comes from the default-branch config. dispatch.mjs reads it through adoptionFromBase, under BASE_PATH .base. A PR cannot widen the list it is judged against. The list is also schema-validated: integers of at least 1, and idle-hours bounded to 1–720.
• Author match. Matching is by numeric databaseId with strict includes. A string id, a missing author, or an unlisted author all fail closed. An owner-id colliding with the App's id is not plausible, since both are user-id-space values.
• Fork PRs. isCrossRepository !== false is skipped before any owner check, so fork PRs are never adopted.
• Holds. Hold labels still apply to owner PRs. An owner PR's body Hold: line holds the lane off, using a regex that mirrors babysit's. A hold that fails to match could only start a CI fix on the owner's own PR, which stays inside the trust boundary and is not an exploit path.
• Idle gate. An unreadable updatedAt or committedDate gives NaN, and a comparison with NaN is false, so the PR counts as not idle. A head whose last commit is not the head OID is also treated as not idle.
• No extra authority downstream.
  • fix-ci still runs through the same read-only model job and apply-patch.
  • The round cap in fix-ci-context is unchanged.
  • pr-run-activity-read.yml runs check-trusted-trigger with pr-number and the trusted-actors file, which the schema description relies on. Every owner id must also be a trusted actor for the run to proceed. I did not read the action itself to confirm it checks the PR author.
  • The pr-merge candidate listing still selects only app/<slug> and Dependabot authors, so this diff does not make owner PRs mergeable. The README and the adoption comment in pr-pipeline.yaml say pr-merge merges adopted owner PRs, and nothing in this diff changes pr-merge to do so.
• Workflow change. pr-unblock-dispatch.yml has comment-only changes. No triggers, permissions, or expressions changed, so there is nothing for this lane to add on top of zizmor.
• Logging. The new log lines carry only PR numbers, SHAs and run ids. The PR body is read for the Hold: match and never logged.
• Instruction surface. The diff deletes or narrows no standing instruction. I did not consult the instruction exception register, because nothing was removed.

Plugin manifests

• No .claude-plugin/plugin.json or marketplace.json is touched.
• manifest <field>: no field hit, so there are no pass or flag lines.

No security issues found.

[melodic-automation-lanes]

The pr-unblock lane stopped on this pull request and needs a person: the merge stages a change under .github/workflows/, which the lane does not push.

• Reason: workflow-staged
• Resume key: 6a27e3198dcb4522ef0af92b2d93f77d10ed4ab5 (the head the lane stopped on)

To resume, deal with the reason above, remove the needs-human label (and do-not-merge, if set), then dispatch the pr-unblock workflow with pr-number=8997 and activity=resolve-conflicts:

gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=8997 -f activity=resolve-conflicts

[melodic-automation-lanes]

The pr-unblock lane stopped on this pull request and needs a person: the merge stages a change under .github/workflows/, which the lane does not push.

• Reason: workflow-staged
• Resume key: 45448a4642f7891e1158c1e9985d4ae6cc4aa90a (the head the lane stopped on)

To resume, deal with the reason above, remove the needs-human label (and do-not-merge, if set), then dispatch the pr-unblock workflow with pr-number=8997 and activity=resolve-conflicts:

gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=8997 -f activity=resolve-conflicts

[melodic-automation-lanes]

The pr-unblock lane stopped on this pull request and needs a person: the merge stages a change under .github/workflows/, which the lane does not push.

• Reason: workflow-staged
• Resume key: 03ec90057cddfbe2c8cf5c4c0a2ba605412868f7 (the head the lane stopped on)

To resume, deal with the reason above, remove the needs-human label (and do-not-merge, if set), then dispatch the pr-unblock workflow with pr-number=8997 and activity=resolve-conflicts:

gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=8997 -f activity=resolve-conflicts