Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1GitHub ruleset 14925316 ('Require CI') on propflowai has require_extra_approval_for_unattributed_changes=true (set 2026-09-13), even though required_approving_review_count=0 — that setting is the ONLY review requirement, and it now fires because our commits carry an unlinked Claude co-author email. The review bot submits APPROVE only on a clean verdict and COMMENT on changes-suggested, so a changes-suggested PR with everything else green cannot merge without an admin override. Trinity hit this on a PR today and merged with --admin rather than touch the ruleset. This also retroactively explains an older, previously-unexplained stuck-merge case logged in docs/dev-tools/required-check-aggregation.md that had the same symptom and was marked 'cause unverified.'
In plain terms. Should we turn off a GitHub setting that's silently blocking merges?
Last week someone added a rule: any pull request built from commits without a verified author now needs an extra human sign-off before it can merge, even though we had already turned off the normal review requirement. Most of our automated commits hit this rule, so pull requests that pass every check still get stuck, and someone has to force them through by hand.
What do you want to do?
The session raising this recommends: Turn the setting off It contradicts our own already-chosen policy of zero required human approvals, so it looks like a leftover rather than an intended gate. Tried first, unsuccessfully: Verified via a live read of the ruleset (gh api .../rulesets/14925316) that require_extra_approval_for_unattributed_changes is true and required_approving_review_count is 0. Cross-checked against docs/dev-tools/required-check-aggregation.md, which flagged the identical stuck-merge symptom weeks ago as unverified-cause -- this confirms the mechanism. Not changing the ruleset myself: branch-protection edits are a standing risky-infra category reserved for a human call.