Files
werkregie/doc/prs/2026-10-20-PR#97-colleague-prs.md
claude-code 3ba00a1342
werkator build succeeded after 01:03
werkator/deploy build succeeded after 00:29
A colleague's pull request is neither to merge nor stuck for the user (#97)
Co-authored-by: claude-code <claude-code@javagil.de>
2026-10-20 16:44:26 +02:00

5.2 KiB

PR#97: A Colleague's Pull Request Is Neither to Merge Nor Stuck for the User

Version: minor

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

Problem

werkregie knows two kinds of pull requests: the user's own and every other one, which it treats as an agent's. On Hostsharing's Gitea, a colleague's pull request, e.g. by hsh-stefanbegerad, then shows Mergen when it is approved and green, and Festgefahren on RED or after a conflict of 30 min. The colleague merges and rebases it, not the user.

Non-Goals

  • No change for the user's own pull request or for an agent's.
  • No change of "Agent arbeitet" (werkregie PR#96) and of the message to the author session of a stuck pull request: they come from the sessions of the user's agents, not from the author of the pull request.

Specification

Feature: a pull request is the user's own, an agent's, or a colleague's

Scenario#97.01: a colleague's approved and green pull request

… so that the user does not merge what the colleague merges.

  • Given an open pull request by hsh-stefanbegerad, who is not in agents, approved by ai-reviewer and by the user, with all checks green and no conflict
  • When werkregie reads the pull request
  • Then "Du bist dran" shows it not under Mergen, and its marker is Von dir approved
Verified by

Scenario#97.02: a colleague's pull request in conflict or RED

… so that the user does not chase the colleague's work as a stuck agent.

  • Given an open pull request by a colleague, in conflict for 3 h without a new commit, or RED for 2 h
  • When werkregie reads the pull request
  • Then it shows no Festgefahren, and werkregie asks Gitea nothing about since when the conflict waits
Verified by

Scenario#97.03: a colleague's pull request waits for the user's review

… so that the user still reviews the colleague's work.

  • Given an open pull request by a colleague with werkrevisor's YELLOW, or without werkrevisor
  • When werkregie reads the pull request
  • Then "Du bist dran" shows it under Dein Approval, as before
Verified by

Scenario#97.04: an agent with another login

… so that an agent's pull request keeps Mergen on each Gitea instance.

  • Given the Gitea entry with agents: [claude-code, hsh-claude-code]
  • And a pull request by HSH-Claude-Code, approved and with all checks green
  • When werkregie reads the pull request
  • Then "Du bist dran" shows it under Mergen
Verified by

Solution

GiteaConfig gets agents, by default [claude-code], next to reviewBots; the case of a login does not count. GiteaSource tells the user's own pull request (author is the token's user, as before), an agent's (author in agents, ignoring case) and a colleague's (any other author). A colleague's pull request gets only Dein Approval and Von dir approved; no Mergen, no Festgefahren, and so no request for conflictSince.

Authors.working and Authors.attach stay unchanged. attach acts only on Festgefahren, which a colleague's pull request no longer has. working acts on Dein Approval of any pull request, but only where a session of this werkregie wrote on its branch within 10 min; such a session changes the colleague's branch on behalf of the user, so the approval waits for it as for an agent's.

Release Notes

A colleague's pull request no longer shows Mergen or Festgefahren; the colleague merges and rebases it. agents in a Gitea entry names the logins of the coding agents, by default [claude-code].

Open Questions

  • Which login does the coding agent use on dev.hostsharing.net? claude-code, as the user answered; the default fits, and the server's dashboard.yml needs no change.