[kikashy]

Closes #22. Closes #21.

What it adds

• Prefer UPDATE_BRANCHES_TOKEN for branch updates and fall back to GITHUB_TOKEN.
• When using the fallback, wait for the updated head and dispatch ci.yml with the pull-request number so the existing check and handover job names run on that head.
• Vendor lib/handover_check.sh as scripts/dev/handover_check.sh, point the CI template at it, and hold its content and version line in tests and the release gate.
• Document the token permissions, fallback behavior, vendored pair, and adopter check; make jpdev setup name a missing member of that pair.

Checks

== check summary (dev.json) ==
PASS     diff-check               0s
PASS     local-paths              0s
PASS     agent-docs               0s
    sync-agent-docs: CLAUDE.md matches AGENTS.md
    sync-agent-docs: CLAUDE.md matches AGENTS.md
PASS     bash-n                   0s
    bash -n: every script parses
PASS     json                     0s
    parsed 6 JSON documents
FAIL     shellcheck               0s, exit 127
    --
    bash: shellcheck: command not found
NOT RUN  tests
== 5 passed, 1 failed, 0 skipped, 1 not run ==

The focused tests step passed separately: 314 passed, 0 failed, including actionlint on both workflow templates.

Not in this PR

• The release version and v0.6.0 notes remain for the maintainer's release change.
• The full check could not run shellcheck because that executable is absent from the environment; the repository was not changed to bypass the required tool.

A Codex session wrote this change.

[kikashy]

Review round 1 (OpenAI gpt-5.6-sol, effort medium, 2026-10-22), reviewed SHA ecfac01

Clean-room clone at the head, read-only; CI green before the round. The report verbatim:

• HIGH — templates/update-branches.yml:56: for a fork PR, updated.head.ref is only the fork’s short branch name; dispatching it against the base repository can reject with 422 or run an unrelated same-named base branch, leaving the updated PR head unchecked. Fix: explicitly handle fork heads and dispatch only a base-repository ref verified to resolve to updated.head.sha.

• HIGH — templates/update-branches.yml:67: a dispatch returning 409/422 is caught as though updateBranch found a merge conflict, so the workflow labels/comments carry needed and exits successfully instead of reporting the dispatch failure. Fix: restrict conflict handling to pulls.updateBranch and let all dispatch failures propagate.

Verified:

• Read git diff origin/main...HEAD, all nine changed files, the source/vendored handover scripts, release gate, setup path, documentation, and relevant tests.
• Confirmed the dispatched jobs retain required names check and handover; the handover job reads PR base/body and calls the vendored script.
• Confirmed the secret-backed path does not explicitly dispatch, avoiding an intentional duplicate beside its push-triggered run.
• Confirmed an absent vendored handover script fails directly at the workflow command rather than being skipped.
• actionlint templates/ci-check.yml templates/update-branches.yml: clean.
• bash -n on the changed shell entry points and handover source/copy: clean.
• In-memory drift probe: baseline source/copy equality passed; deliberate appended drift was rejected.
• In-memory API mock: dispatch status 422 was swallowed and converted into carry needed, reproducing the second finding.
• The read-only safeguard refused creation of .review/equality-drift.sh; no tracked or untracked file was written, and the equivalent probe was run without filesystem writes.
• Did not rerun the full suite because CI already passed and tests/run.sh is not separable into a changed-file-only test.

merge: after fixes — reviewed SHA: ecfac01

Disposition (the coordinator's)

#	Finding	Severity	Disposition
1	A fork pull request's head ref is dispatched against the base repository	HIGH	Fix in this pull request by the same builder: dispatch only a base-repository ref that resolves to the updated head SHA, otherwise report and stop; the merge waits for it
2	A dispatch failure (409/422) is handled as a merge conflict and labelled carry needed	HIGH	Fix in this pull request: conflict handling applies to the branch update only; dispatch failures propagate; the merge waits for it

The same reviewer re-reads the fixed head. Same vendor as the builder, not a cross-vendor claim.

[kikashy]

Re-read after the fix (OpenAI gpt-5.6-sol, effort medium, 2026-10-22), reviewed SHA 934c17a

The same reviewer, clean-room clone at the fixed head, probes under .review/; CI green. The report verbatim:

Findings

• HIGH — templates/update-branches.yml: createWorkflowDispatch runs before getRef verifies the base-repository ref resolves to the updated SHA. The mock confirmed the order is dispatch,getRef; a stale ref therefore dispatches CI on the wrong commit before failing. Move validation before dispatch or pass/check out the SHA directly.

Verified

• Fork heads are commented and fail visibly without dispatch or carry needed.
• Dispatch 422 propagates with its original status/message and writes no label/comment.
• Conflict handling wraps only updateBranch.
• actionlint passes.
• Documentation matches fork behavior.

merge: after fixes
reviewed SHA: 934c17abf782d2315c4acd1dd14a2293c3ac6367

Disposition (the coordinator's)

#	Finding	Severity	Disposition
1	The dispatch runs before the ref is verified against the updated SHA	HIGH	Fix in this pull request by the same builder, narrow: pass the updated SHA as the dispatch input and have the CI template check out that input, so no ref lookup is needed; one narrow re-read scoped to this seam, then merge

Both round-1 findings are confirmed fixed. Same vendor as the builder, not a cross-vendor claim.

[kikashy]

Narrow re-read of the dispatch seam (OpenAI gpt-5.6-sol, effort medium, 2026-10-22), reviewed SHA 0edfffb

The same reviewer, clean-room clone at the head, probes under .review/; CI green (the lint failure between the two heads was one shellcheck note on a literal workflow expression, silenced with a directive). The report verbatim:

Findings: none.

Verified:

• Dispatch occurs after successful update and new-head polling, only for same-repository heads, with sha: updated.head.sha; production path has no getRef.
• Both jobs check out inputs.sha; push behavior and required check/handover names are unchanged.
• Focused tests: 318 passed, 0 failed.
• Mutation probe confirmed sending the ref instead of SHA fails the assertion.

merge: yes
reviewed SHA: 0edfffbf0591ba88e97d1ebdc0620c9d97f0e4b1

Disposition: the re-read's HIGH is fixed; no further round. Merged on the standing rule. Same vendor as the builder, not a cross-vendor claim.

[github-actions]

🎉 Thank you for your contribution to Judgment Pack!

If you’d like another task, choose a path that interests you:

• Go runtime
• Judgment desk
• Gateway and provenance
• Python and evaluator experiments
• Specification and documentation
• Agent harness and adapters