german/houseplan-card
1
0
Fork 0
mirror of https://github.com/Matysh/houseplan-card synced 2026-09-29 03:09:36 +00:00
Code Issues Actions 6 Packages Projects Releases Wiki Activity

docs: state the invariant the pipeline was missing

Browse Source 
A review run always moves the label. The rule is written down because its absence
cost a real stall: a green code review whose merge conflicted left the label alone,
the waiting author polled thirty times and reported the limit as exhausted, and a
verdict that existed reached nobody.

Both documents now say what S6-in-progress means when the verdict was green and
only the merge failed — rebase, not rework, and the verdict still stands. They also
say that a label which did not change means the run failed rather than the work, so
the answer is logs and the owner, not more polling. Cycles are counted per stage.

Issue: #114
User-Visible: no
This commit is contained in:
Matysh
2026-08-13 17:13:54 +03:00
parent 1e9952db35
commit dbe12f1a54
2 changed files with 39 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+20 -6
View File
@@ -126,8 +126,14 @@ nothing to users and does not touch the integration branch, so it needs no comma
**Do not merge into `dev` by hand.** On a green code review the pipeline rebases
the task branch onto `dev`, pushes it, and only then sets `S8-merged` — the label
asserts the code is in `dev`, so the merge has to happen first or the label lies
in between. If the rebase conflicts, the pipeline says so in the issue and leaves
the task in `S7-code-review`; resolving the conflict is the author's job.
in between.
If the rebase conflicts the pipeline says so in the issue and sends the task back
to `S6-in-progress`. The verdict still stands: nothing needs reviewing again, the
remaining work is the rebase. Resolve it, push the branch, re-apply
`S7-code-review`. The second review run is not a formality — after a rebase onto a
moved `dev` this is different code, and accepting it unchecked is how regressions
arrive. Cycles are counted per stage, so a code review spends its own budget.
Everything else still requires the owner's explicit command: pushing `main`,
creating tags, publishing betas and releases, closing issues.
@@ -171,10 +177,18 @@ the comment only explains it. Do not wait at all while `blocked` is set — the
is waiting on the owner, not on the reviewer. On exhausting the attempts, stop and
tell the owner: a failed run leaves the label where it was, forever.
What the new label means: `S5-ready` — write the code; `S3-spec` — read the verdict
and revise the spec, then re-apply `S4-spec-review`; `S6-in-progress` — revise the
code, then re-apply `S7-code-review`; `S8-merged` — accepted and already in `dev`,
nothing left to do; `review-4` — the cycle limit is spent, stop and wait for the owner.
What the new label means:
| Now reads | What happened | What you do |
|---|---|---|
| `S5-ready` | the spec is accepted | write the code |
| `S3-spec` | the spec came back | read the verdict, revise, re-apply `S4-spec-review` |
| `S6-in-progress` | the code came back | revise, re-apply `S7-code-review` — **or**, if the verdict was green and only the merge conflicted, just rebase and re-apply. The comment says which |
| `S8-merged` | accepted and already in `dev` | nothing |
| `review-4` | the cycle limit is spent | stop, the owner decides |
**After a review run the label always changes.** If it did not, the run itself
failed rather than the work — say so to the owner instead of polling on.
The exchange happens in **issue comments** — there is no local message bus. Verdict
format: