fix(launch): bring two comment blocks back under the cap #289

Merged

coilysiren merged 1 commit from aos/claude/xu59-comment-caps into main

2026-08-16 04:21:16 +00:00

coilyco-ops commented

2026-08-16 04:19:33 +00:00

Member

main is red. Both violations are mine.

What broke

Run 243, the push that merged #287:

FAIL: cmd/agent-compose/main.go:1063: comment block of 3 lines starting at 1061
FAIL: internal/launch/launch.go:19: comment block of 3 lines starting at 17

Two three-line comment blocks against a two-line cap. Trimmed, no behaviour touched.

Why it got through

I validated #287 with gofmt, go build, go vet, and the full go test ./..., and never ran pre-commit run --all-files. The Go toolchain has no opinion about comment length. The hook suite does, and it is the thing I skipped.

The clone did not catch it either: I had not run pre-commit install in it at that point, so the commit hook was absent. I installed it later while working on #288, which is why that one was gated and this was not.

Both halves of the miss are mine and neither is subtle.

Verified properly this time

ward exec test, the entire command CI runs, exits 0 locally. That covers go test ./..., release-impact, packaging, palette, context budget, evalkit-check, and pre-commit run --all-files.

The bit worth reading

#288 would have caught this. Its pull_request run on its own branch passed (run 244), so the workflow is live and working. It simply did not exist when #287 was open.

So this is precisely the failure #288 was built to prevent, arriving one merge too early to be prevented by it. This is also the first change in this repository that a pull-request check will gate before it lands.

Also corrects something I told Kai: I said a workflow added by a pull request cannot run on that pull request. Run 244 shows Forgejo does run it. I was wrong.

🤖 Generated with Claude Code

**main is red. Both violations are mine.** ## What broke Run 243, the push that merged #287: ``` FAIL: cmd/agent-compose/main.go:1063: comment block of 3 lines starting at 1061 FAIL: internal/launch/launch.go:19: comment block of 3 lines starting at 17 ``` Two three-line comment blocks against a two-line cap. Trimmed, no behaviour touched. ## Why it got through I validated #287 with `gofmt`, `go build`, `go vet`, and the full `go test ./...`, and **never ran `pre-commit run --all-files`**. The Go toolchain has no opinion about comment length. The hook suite does, and it is the thing I skipped. The clone did not catch it either: I had not run `pre-commit install` in it at that point, so the commit hook was absent. I installed it later while working on #288, which is why that one was gated and this was not. Both halves of the miss are mine and neither is subtle. ## Verified properly this time `ward exec test`, the entire command CI runs, **exits 0** locally. That covers `go test ./...`, release-impact, packaging, palette, context budget, evalkit-check, and `pre-commit run --all-files`. ## The bit worth reading **#288 would have caught this.** Its `pull_request` run on its own branch passed (run 244), so the workflow is live and working. It simply did not exist when #287 was open. So this is precisely the failure #288 was built to prevent, arriving one merge too early to be prevented by it. This is also the first change in this repository that a pull-request check will gate before it lands. Also corrects something I told Kai: I said a workflow added by a pull request cannot run on that pull request. Run 244 shows Forgejo does run it. I was wrong. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

coilyco-ops added 1 commit

2026-08-16 04:19:33 +00:00

fix(launch): bring two comment blocks back under the cap

ci / test (pull_request) Successful in 43s

Details

4498ff8d5a

main is red at 3d1bc50c. Both violations are mine, from #287:
cmd/agent-compose/main.go:1061 and internal/launch/launch.go:17 are
three-line comment blocks against a two-line cap.

They landed because I validated that branch with go build, go vet, and
go test and never ran the repository's own hook suite, and the clone had
no hooks installed to catch it either. The Go toolchain has no opinion
about comment length; the thing that does is exactly the thing I skipped.

Verified the way it should have been the first time: `ward exec test`,
the whole command CI runs, exits 0 locally.

Worth noting that #288 would have caught this. Its pull_request run on
its own branch passed, so the workflow works; it simply did not exist
when #287 was open. This is the failure it was built for, arriving one
merge too early to be stopped by it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>