- Branch creation, commit push, bot attribution all verified (run #198)
- 1 bug found: prompt template used quick_pull=1 instead of expand=1
- Fix committed in f08b1b4, validates after merge to main
Progress: 87% complete — M7 (docs update) remaining
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
E2E test confirmed: Claude correctly responds to @claude mentions in
PR review comments on Forgejo (run #12075, PR #15). Three bugs were
found and fixed during validation:
1. Missing comment object in Forgejo webhook payload
2. Event name mismatch (pull_request_comment vs pull_request_review_comment)
3. MCP server routing updates to wrong API (critical — silently dropped responses)
Progress: 3/8 milestones complete (37.5%)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Root cause was mock.module cross-file pollution in Bun's test runner,
not Linux-specific mock tracking bugs as previously theorized.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
DI fix passes locally in grunt-runner Docker but still fails on
actual Forgejo runner. Adding diagnostic tests to isolate whether
mock() tracking itself is broken, or something else in the runner
environment causes it.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
mock.module("fs/promises") on Linux Bun poisons the entire mock
tracking system — not just fs mocks, but ALL mock/spy assertions
(octokit mocks, spyOn(global, "fetch"), etc.) stop recording calls.
Replace with dependency injection: downloadCommentImages() now accepts
an optional fsDeps parameter. Tests pass mock mkdir/writeFile directly.
Production callers omit it and get real fs. No mock.module anywhere.
Fixes 18 test failures blocking CI on Forgejo Linux runners.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- PRD #5: Dedicated Forgejo user for Claude bot (dedicated identity, scoped token)
- PRD #6: E2E test all 5 untested Forgejo trigger scenarios
- PRD #7: Senior developer review of all Forgejo platform support code
- Defined 5, 7, and 6 milestones respectively
- All three can be parallelized (#7 is read-only, runs alongside #5)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
