[MarkRosemaker]

A maintained run now opens a GitHub issue on a repository when its tests fail, whether on main or after one of the run's tasks, and when its coverage slips below its floor. Issues are filed through ghrepo's issue methods (ghrepo#5), and ghrepo is bumped to that main.

Labels. Every issue carries devtool, plus one label for what it's about. A repository that lacks a label gets it created, with a colour and description:

Label	When
coverage	coverage fell below the floor, or a public repository is below its floor
failing on main	build or tests fail before any change (broken or flaky)
dependency update breaks build / tests	the update dependencies task's change breaks the build ([build failed]) or the tests
devtool breaks build / tests	any other task's change (devtool update, go generate, go fix, lint fix, …) breaks the build or the tests

One issue per problem. The body starts with a hidden comment that identifies the problem:

• for failing tests, a hash of the task (empty for main) and the failing tests (packages where no test is named), leaving out timings and seeds;
• for coverage, fell or public.

Before filing, devtool looks for an open devtool-labelled issue holding that comment. If it finds one, it updates that issue with the latest output, commit and time instead of filing another.

What an issue holds (internal/run/issue_tests.md.tmpl, issue_coverage.md.tmpl), written for an agent to act on:

• Failing tests:

  • what broke: main itself, or a task's change that wasn't committed and was discarded;
  • the failing tests, and go test's output with the passing packages left out (gorepo#7);
  • how to reproduce it: a link to main's commit, the Go version, the exact command, the shuffle seed, and make test-race;
  • the task's file and module changes, and any tasks that committed earlier in the run but weren't pushed.

  The title says "Build fails" or "Tests fail", "on main" or after "<task>", then the failing tests.

• Coverage: the old and new figures and the floor; how to measure (make cover uses the same -coverpkg=./..., and a one-liner lists the least-covered functions); and a warning against tests that execute code without checking anything.

• Both: read AGENTS.md, pass make ready, and reference the issue with Fixes in the pull request.

Failing to file is logged and never fails the run. GITHUB_TOKEN needs permission to write issues and labels on the maintained repositories.

Checks

• Tests drive the real engine against a fake repository that keeps issues and labels in memory:
  • tests failing on main over two runs: one issue, refreshed by the second run, labelled devtool and failing on main;
  • devtool breaks tests, and dependency update breaks build, each with its title and change;
  • coverage falling from 85% to 70%;
  • other failures, and success, filing nothing;
  • the identifying comment ignoring timings and seeds.
• The fake repository answers go version itself. Run for real against a temporary HOME, it downloaded a toolchain and wrote Go telemetry after the test ended, which made cleanup fail now and then. Five clean runs in a row since.
• docs/architecture.md describes it.
• make ci passes.

Not in this PR

• The Telegram failure message doesn't link to the issue. That would need devtool-engine's event stream to carry the issue's address.
• devtool doesn't close an issue once the problem is gone. The Fixes reference in the fixing PR closes it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01M6xJuQgmRd19QozaQDD3tk