BuildPositionToLineMap correctly increments position and updates maxPositions when it encounters a @@ hunk-header line, but it does not insert an entry into pm.files[currentFile][position]. The GitHub diff-position spec — and issue #79 explicitly — defines the @@ line as position 1 (or the continuing counter for subsequent hunks), and it is a valid target for inline comments. Because no map entry is written for @@ positions, Translate() falls into the !ok branch and returns a hard error ("position N out of range for file"), rather than falling back to the nearest non-deletion line below the header.
Deletion lines already get this fallback treatment (they are stored as -1 and Translate follows the chain). Hunk-header positions should receive the same: map them to 0 (or a sentinel) and let Translate fall through to the nearest context/addition line below. The current asymmetry means any LLM comment positioned at a @@ line will cause PostReview to abort for that file's comments entirely.
In BuildPositionToLineMap, when a @@ hunk-header line is encountered, store the position with a sentinel value (e.g., 0) in pm.files[currentFile]: pm.files[currentFile][position] = 0.
In Translate(), add a branch for lineNum == 0 that applies the same "nearest non-deletion line below" fallback used for deletion lines (lineNum == -1).
Add test cases to position_test.go that call Translate(file, 1) (single-hunk) and the continuing @@ position in a multi-hunk diff, verifying they return the first new-file line of the hunk rather than an error.
Acceptance criteria
Translate(file, hunkHeaderPosition) returns the line number of the first context/addition line in the hunk, not an error
Tests added for single-hunk and multi-hunk @@ positions
## What was missed
`BuildPositionToLineMap` correctly increments `position` and updates `maxPositions` when it encounters a `@@` hunk-header line, but it does **not** insert an entry into `pm.files[currentFile][position]`. The GitHub diff-position spec — and issue #79 explicitly — defines the `@@` line as **position 1** (or the continuing counter for subsequent hunks), and it is a valid target for inline comments. Because no map entry is written for `@@` positions, `Translate()` falls into the `!ok` branch and returns a hard error (`"position N out of range for file"`), rather than falling back to the nearest non-deletion line below the header.
Deletion lines already get this fallback treatment (they are stored as `-1` and Translate follows the chain). Hunk-header positions should receive the same: map them to `0` (or a sentinel) and let Translate fall through to the nearest context/addition line below. The current asymmetry means any LLM comment positioned at a `@@` line will cause `PostReview` to abort for that file's comments entirely.
## Source
- PR: #90 — feat(vcs): Gitea adapter with diff-position translation (Phase 2)
- Linked issue: #79 — feat(vcs): Gitea adapter with diff-position translation (Phase 2)
- Code quality rule: Diff-position spec compliance
- File: `gitea/position.go`, hunk-header handling block
## What needs to happen
1. In `BuildPositionToLineMap`, when a `@@` hunk-header line is encountered, store the position with a sentinel value (e.g., `0`) in `pm.files[currentFile]`: `pm.files[currentFile][position] = 0`.
2. In `Translate()`, add a branch for `lineNum == 0` that applies the same "nearest non-deletion line below" fallback used for deletion lines (`lineNum == -1`).
3. Add test cases to `position_test.go` that call `Translate(file, 1)` (single-hunk) and the continuing `@@` position in a multi-hunk diff, verifying they return the first new-file line of the hunk rather than an error.
## Acceptance criteria
- `Translate(file, hunkHeaderPosition)` returns the line number of the first context/addition line in the hunk, not an error
- Tests added for single-hunk and multi-hunk `@@` positions
- All existing tests continue to pass
## References
- [PR #90](https://gitea.weiker.me/rodin/review-bot/pulls/90)
- [Issue #79](https://gitea.weiker.me/rodin/review-bot/issues/79)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What was missed
BuildPositionToLineMapcorrectly incrementspositionand updatesmaxPositionswhen it encounters a@@hunk-header line, but it does not insert an entry intopm.files[currentFile][position]. The GitHub diff-position spec — and issue #79 explicitly — defines the@@line as position 1 (or the continuing counter for subsequent hunks), and it is a valid target for inline comments. Because no map entry is written for@@positions,Translate()falls into the!okbranch and returns a hard error ("position N out of range for file"), rather than falling back to the nearest non-deletion line below the header.Deletion lines already get this fallback treatment (they are stored as
-1and Translate follows the chain). Hunk-header positions should receive the same: map them to0(or a sentinel) and let Translate fall through to the nearest context/addition line below. The current asymmetry means any LLM comment positioned at a@@line will causePostReviewto abort for that file's comments entirely.Source
gitea/position.go, hunk-header handling blockWhat needs to happen
BuildPositionToLineMap, when a@@hunk-header line is encountered, store the position with a sentinel value (e.g.,0) inpm.files[currentFile]:pm.files[currentFile][position] = 0.Translate(), add a branch forlineNum == 0that applies the same "nearest non-deletion line below" fallback used for deletion lines (lineNum == -1).position_test.gothat callTranslate(file, 1)(single-hunk) and the continuing@@position in a multi-hunk diff, verifying they return the first new-file line of the hunk rather than an error.Acceptance criteria
Translate(file, hunkHeaderPosition)returns the line number of the first context/addition line in the hunk, not an error@@positionsReferences