[issue-95] fix(ci): make the review gate runnable, re-verify main weekly

[vinicq]

Closes #95. Fourth repo carrying this file, and the same two problems as falsegreen-js#98.

The gate cannot report

codex-review-gate.yml: 89 failing runs, 1 success, failures with zero jobs. That is GitHub refusing to validate the file, not a check that fails. on: declared pull_request_review_thread, a real webhook event that Actions does not accept as a trigger.

Repo	State
falsegreen	deleted the workflow (65482f0, "never ran on PR, only produced phantom push failures")
falsegreen-skill	repaired; the gate then ran for the first time and immediately failed on unresolved Codex threads, as designed
falsegreen-js	repaired, falsegreen-js#98
robotframework-falsegreen	this PR

I repaired rather than deleted, which diverges from falsegreen. The gate does real work once it runs, and falsegreen-skill demonstrated that within the hour of being fixed. The two approaches should converge, and that is a call worth making deliberately rather than by whichever repo was touched last.

main is never re-verified

ci.yml ran on push to main and on pull_request only, so no push means no run and the badge keeps showing the last green result however stale.

falsegreen paid for this concretely: ruff 0.16 widened its default rule set, main went to 106 lint findings with no commit involved, and it surfaced weeks later on an unrelated Dependabot PR where it read as that PR's fault. A weekly schedule caps that window at 7 days.

Honest limitation, now in the header

The old comment promised the gate "clears as soon as a thread is resolved". Actions observes no event when a thread is resolved, and reaching for pull_request_review_thread to get that behaviour is exactly what broke the file. The header now states what happens: after resolving, the gate clears on the next push or a manual re-run.

Verification

• Both workflows validate against the Actions schema: 0 errors, from 1 before.
• No step branches on github.event_name or github.event.pull_request, so a scheduled run needs no adaptation.
• The real proof is this PR: if the file is valid, gate shows up as a check and runs. If I got it wrong, it stays absent.

Rollback

Clean revert of one commit: one YAML line, a comment, three lines of trigger. Reverting restores a workflow that never ran, so nothing is at risk either way.

[vinicq]

Scope grew by one commit, and the reason is worth recording rather than quietly folding in.

Opening this PR made the gate runnable, which meant CI got far enough to run Lint for the first time in a while, and Lint failed with 67 findings on a PR that touches only workflow YAML. Not this PR's fault: pyproject.toml had no [tool.ruff] section at all and declared ruff>=0.5 with no ceiling, so the lint surface was whatever ruff defaulted to. ruff 0.16 widened that set, and CI installs 0.16.2.

Proved by removal on this tree with the version CI uses:

State	ruff check src tests
with the new select block	clean
stash it	67 errors: UP031, E402, BLE001, I001, SIM114, RUF100

None of those are new code. They are rules that were never selected and now are.

select = ["E4", "E7", "E9", "F"] declares what the repo was already being held to, rather than capping ruff. A cap freezes the tool and leaves the surface implicit, so the same break returns the day someone lifts it. Same call as vinicq/falsegreen#148, where the identical drift left main with 106 findings.

Adopting the wider rule set is worth doing on its own merits, with the findings triaged in a dedicated PR.

Worth noting what this sequence demonstrates: a broken gate hid a broken lint. Repairing the reporting surface is what surfaced the real defect, which is the argument for fixing checks that cannot report even when they look like noise.

Full suite verified in a clean venv with pip install -e ".[dev]": 257 passed. An earlier local run showing failures was my own environment, PYTHONPATH=src without an editable install, not the repo.

[vinicq]

Superseded, and by my own reasoning being overturned rather than by anything new breaking.

This PR repaired the gate. The architect verdict is to delete it instead: it is a hand-rolled reimplementation of required_conversation_resolution, with a lag its own header confesses and an assumption about Codex re-posting that was never guaranteed. Repairing it was choosing the more complex and slower version of the same control. The repair still earned its keep as a diagnostic, because it is what proved the gate catches real threads, and without that the comparison would have been a guess.

Split three ways:

• fix(ci): declare the lint surface so a ruff default change cannot break main #97: the ruff select fix alone. main is red right now and that had no business waiting behind a CI-hygiene discussion.
• [issue-95] ci: drop the codex-review-gate, re-verify main weekly #98: delete the gate, keep the weekly schedule.
• Branch protection with required_conversation_resolution: a settings change, not a commit.

Branch fix/gate-trigger-and-cron stays undeleted for now: it holds the repaired workflow, so the deletion is recoverable if it turns out to be the wrong call.