docs(agent): let a scheduled run merge behind an independent review #202

2026-08-22T05:58:33Z

logan commented

2026-08-22 05:58:33 +00:00

The nightly runs produced five green PRs and no way to land them without a person at the keyboard. This adds the missing half: a merge gate, run by a reviewer that did not write the branch.

Why a review rather than just CI. The author writes the tests, so a green run proves the least interesting thing. Last night's reviews caught two guards that left the entire suite green when deleted (#178's desktop timer gate, #182's breakpoint listener), a sweep that named one file while its hook fired on a glob, and an overlay that covered the artwork it was editing on every touch device. None of that is visible to CI.

Why it is safe to automate here. A push to main publishes nothing: release.yml is workflow_dispatch only and all four publishers key on v* tags. So the cost of a wrong merge is a revert, not a package that cannot be unpublished. The section says this explicitly and says it is void if that ever changes.

The gate is seven conditions, all required: an independent MERGE / MERGE WITH NITS verdict; both (pull_request) CI contexts green on the current head (the (push) ones are skipped by design, which Gitea folds into a permanently pending combined state); mergeable and rebased; touches none of the release, packaging, schema or dependency paths; is not a Kind/Feature; is under ~600 lines and ~15 files; and does not claim device evidence no tier here can produce.

Nits merge and become issues rather than being fixed on the branch — a second author pass with no second review is the thing this exists to prevent.

Verification: make skill-check, plus the pre-commit and pre-push suites.

The nightly runs produced five green PRs and no way to land them without a person at the keyboard. This adds the missing half: a merge gate, run by a reviewer that did not write the branch. **Why a review rather than just CI.** The author writes the tests, so a green run proves the least interesting thing. Last night's reviews caught two guards that left the entire suite green when deleted (#178's desktop timer gate, #182's breakpoint listener), a sweep that named one file while its hook fired on a glob, and an overlay that covered the artwork it was editing on every touch device. None of that is visible to CI. **Why it is safe to automate here.** A push to `main` publishes nothing: `release.yml` is `workflow_dispatch` only and all four publishers key on `v*` tags. So the cost of a wrong merge is a revert, not a package that cannot be unpublished. The section says this explicitly and says it is void if that ever changes. **The gate is seven conditions**, all required: an independent MERGE / MERGE WITH NITS verdict; both `(pull_request)` CI contexts green on the current head (the `(push)` ones are `skipped` by design, which Gitea folds into a permanently `pending` combined state); mergeable and rebased; touches none of the release, packaging, schema or dependency paths; is not a `Kind/Feature`; is under ~600 lines and ~15 files; and does not claim device evidence no tier here can produce. Nits merge and become issues rather than being fixed on the branch — a second author pass with no second review is the thing this exists to prevent. Verification: `make skill-check`, plus the pre-commit and pre-push suites.

logan added 1 commit 2026-08-22 05:58:33 +00:00

docs(agent): let a scheduled run merge behind an independent review

CI / e2e (push) Skipped

CI / check (push) Skipped

CI / check (pull_request) Failing after 35s

Details

CI / e2e (pull_request) Skipped

Details

e62e12f6c6

The runs produced five green PRs and no way to land them without a person. What makes that safe to automate is not CI — the author writes the tests — but a reviewer in a fresh context: last night's caught two guards that left the whole suite green when deleted, an over-narrow sweep, and an overlay covering the artwork it was editing.

So the gate is seven conditions, and a Kind/Feature is never one of them. It can exist at all because a push to main publishes nothing here: release.yml is workflow_dispatch and the four publishers key on v* tags, so a wrong merge costs a revert rather than a package nobody can unpublish. The section says so, and says it is void if that changes.

logan added 1 commit 2026-08-22 05:58:35 +00:00

docs(agent): let a scheduled run merge behind an independent review

CI / e2e (push) Skipped

CI / check (push) Skipped

CI / check (pull_request) Failing after 35s

Details

CI / e2e (pull_request) Skipped

Details

e62e12f6c6

The runs produced five green PRs and no way to land them without a person. What makes that safe to automate is not CI — the author writes the tests — but a reviewer in a fresh context: last night's caught two guards that left the whole suite green when deleted, an over-narrow sweep, and an overlay covering the artwork it was editing.

So the gate is seven conditions, and a Kind/Feature is never one of them. It can exist at all because a push to main publishes nothing here: release.yml is workflow_dispatch and the four publishers key on v* tags, so a wrong merge costs a revert rather than a package nobody can unpublish. The section says so, and says it is void if that changes.

logan closed this pull request

2026-08-22 05:59:50 +00:00

logan commented

2026-08-22 06:00:17 +00:00

Closing unmerged: the approach was not wanted. The runs stay as they were — a PR per issue, merged by a person. Nothing on main changed.

Closing unmerged: the approach was not wanted. The runs stay as they were — a PR per issue, merged by a person. Nothing on `main` changed.

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#202