Handle coordination-backend activation for in-flight PR batches

[justin808]

Why

In-flight batches can start under coordination_backend: n/a and later refresh onto a private backend. The preflight now reconciles that seam explicitly instead of inventing a retroactive backend history.

What changed

• Added a focused transition replay fixture that captures the issue's original n/a workflow revision and later private-backend revision.
• Taught completed-batch-publication-preflight to either authenticate a no-backend -> active-backend reconciliation into an explicit transition snapshot, or stop early with one precise activation blocker.
• Preserved the original no-backend terminal handoff inside the transition record so the result cannot masquerade as native private-backend history.
• Added a coordination-backend seam doc note and a contract-test assertion for the trusted-base refresh transition rule.

How to verify

• ruby skills/post-merge-audit/bin/completed-batch-publication-preflight-test.rb -n '/test_trusted_base_refresh_/'
• ruby skills/pr-batch/bin/goal-completion-contract-test.rb -n '/coordination_backend_doc_requires_explicit_transition_handoff_on_trusted_base_refresh/'
• git diff --check
• .agents/bin/lint (passes rubocop and markdownlint; stops because yamllint is not installed in this workspace)

Fixes #455

deferred_to_update_changelog

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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

[claude]

These two early return blocked_result(...) calls break the fail-closed-with-full-detail pattern used everywhere else in assess. Every other failure path (invalid batch_id, invalid expected_targets, coordination drift, etc.) keeps accumulating into the shared blockers array and lets the method fall through to build a complete snapshot, so a blocked receipt still reports batch_id, coordination_backend, and every blocker that was found.

Here, if no_backend_evidence or authenticated_status resolution fails, the method instead returns a bare blocked_result, which:

• Discards any blockers already pushed earlier in this call (e.g. "publication batch id is invalid", "configured coordination backend is unavailable", or validated_target_set errors on expected_targets), replacing them with only the single new message.
• Hardcodes batch_id/coordination_backend to nil in the returned receipt even though both were already resolved successfully at this point (batch_id on line 71-72, backend on line 68), so an auditor looking at this blocked receipt can't tell which batch/backend it was even for.

Since this is fail-closed either way (eligible stays false), it's not exploitable, but it does make this one failure mode uniquely opaque compared to every other blocked outcome in this file, and could hide unrelated pre-existing validation problems in the same request. Consider passing the already-resolved batch_id: / coordination_backend: backend into blocked_result, and/or accumulating this new blocker into blockers and letting the method continue instead of returning early.

[claude]

Review summary

Reviewed the new no-backend → active-backend transition handling in completed-batch-publication-preflight, its tests/fixtures, and the doc/contract-test additions.

Overall: the design is sound and fails closed — a batch that started under coordination_backend: n/a and later observes an active backend either produces an authenticated transition snapshot that preserves the original no-backend terminal handoff, or blocks with one precise repair action. valid_receipt? and reassessed_receipt_valid? are extended consistently to validate the new transition field, and the doc/contract-test additions keep the prose and code in sync.

One correctness/quality issue (left as an inline comment): the two new early return blocked_result(...) calls in the elsif transitioning_from_no_backend branch (lines 95–105) discard any blockers already accumulated earlier in the same assess call (e.g. invalid batch_id, invalid expected_targets) and hardcode batch_id/coordination_backend to nil in the returned receipt, even though both were already resolved. Every other failure path in this method instead keeps building the full snapshot and blockers list, so this makes the two new failure modes uniquely opaque compared to the rest of the file's audit receipts. Not exploitable (verdict stays BLOCKED either way), but worth aligning with the established pattern.

No other correctness, security, or performance concerns found. Nice test coverage for both the happy-path transition and the fail-closed case.