Please address the comments from this code review:

## Overall Comments
- In `joinFilteredOCRText`, consider replacing the manual O(n²) nested-loop sort with `sort.Slice` for clearer intent and better scalability when `Filtered` contains many fragments.
- The English developer doc (`docs/en_us/developers/quantized-sliding.md`) has a truncated bullet point ending with '`- The maximum value is less than or equal to `'—please complete or remove this line to avoid confusing readers.

## Individual Comments

### Comment 1
<location path="agent/go-service/quantizedsliding/ocr.go" line_range="26-27" />
<code_context>
-		if ocr, ok := recognitionDetail.Results.Best.AsOCR(); ok {
-			return []int{ocr.Box.X(), ocr.Box.Y(), ocr.Box.Width(), ocr.Box.Height()}, true
-		}
+	if len(detail.Box) >= 4 {
+		return []int{detail.Box[0], detail.Box[1], detail.Box[2], detail.Box[3]}, true
 	}

</code_context>
<issue_to_address>
**issue (bug_risk):** Potentially using the wrong hit box when a named child detail is found but has only a Box

In `readHitBox`, after preferring `candidate := findRecognitionDetailByName(detail, nodeQuantizedSlidingSwipeButton)`, you fall back directly to `detail.Box` when `readTemplateMatchBestBox(candidate)` fails. This skips `candidate.Box` entirely when `candidate != detail`, even if `candidate` has a valid box and `detail` does not, so you can end up returning the wrong (or empty) box. To preserve priority for the swipe button node, the fallback should first check `candidate.Box`, then fall back to `detail.Box` only if `candidate != detail` and `detail.Box` is valid.
</issue_to_address>

### Comment 2
<location path="docs/en_us/developers/quantized-sliding.md" line_range="336" />
<code_context>
-- Too many fine-tuning attempts still do not converge.
-
-The current implementation clamps a single fine-tuning branch to the range `0 ~ 30`, and `QuantizedSlidingCheckQuantity` has `max_hit = 4`. If those limits are exhausted and the target value is still not reached, the flow fails and enters `QuantizedSlidingFail`.
+- The maximum value is less than or equal to `

 ## Why fine-tuning buttons are still needed
</code_context>
<issue_to_address>
**issue:** This failure-condition bullet point appears truncated and incomplete, likely dropping important explanatory text.

The bullet `- The maximum value is less than or equal to `` is syntactically incomplete (unclosed backtick, missing condition) and no longer describes this failure mode. The previous explanatory text about fine-tuning limits and `QuantizedSlidingFail` also seems to have been removed. Please restore the full condition (including closing the inline code span) and reintroduce the explanation so this failure case remains clear to readers.
</issue_to_address>

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="agent/go-service/quantizedsliding/ocr.go" line_range="141-150" />
<code_context>
+func joinFilteredOCRText(results *maa.RecognitionResults) string {
</code_context>
<issue_to_address>
**issue (bug_risk):** Dropping fragment de-duplication may cause repeated OCR fragments in the concatenated quantity text.

The previous flow (`collectOCRFragments` + `uniqueOCRFragments`) removed duplicate fragments (by position/size) before joining. `joinFilteredOCRText` now concatenates all filtered fragments in order, without de-duplication and with less positional data. If the recognizer can emit overlapping or duplicate fragments at the same coordinates, this can produce repeated digits (e.g., `"1110"` vs `"110"`). If that case occurs in your pipelines, please add a lightweight de-dup step (e.g., keyed by `(x, y, text)`) to retain the prior behavior under the new API.
</issue_to_address>

### Comment 2
<location path="docs/en_us/developers/quantized-sliding.md" line_range="104" />
<code_context>
+| `ConcatAllFilteredDigits` | `bool`                  | No       | Quantity parse strategy switch. `false` (default): read only `Results.Best` OCR text. `true`: read all `Results.Filtered` OCR fragments, sort by y then x, concatenate, then parse.     |
</code_context>
<issue_to_address>
**nitpick (typo):** Consider changing “Quantity parse strategy switch” to “Quantity parsing strategy switch” for more natural phrasing.

Minor grammar improvement for consistency with how parsing is described elsewhere in the docs.

```suggestion
| `ConcatAllFilteredDigits` | `bool`                  | No       | Quantity parsing strategy switch. `false` (default): read only `Results.Best` OCR text. `true`: read all `Results.Filtered` OCR fragments, sort by y then x, concatenate, then parse.   |
```
</issue_to_address>

### Comment 3
<location path="docs/en_us/developers/quantized-sliding.md" line_range="216" />
<code_context>

 If either of these prerequisites is not met, more accurate proportional calculations will not help.

+The current Go-side recognition read rules are intentionally narrow:
+
+- The slider hit box is read from `QuantizedSlidingSwipeButton` and prefers `Results.Best.AsTemplateMatch()`.
</code_context>
<issue_to_address>
**suggestion (typo):** “recognition read rules” sounds a bit awkward; consider “recognition reading rules”.

For example, you could write: “The current Go-side recognition reading rules are intentionally narrow:” which reads a bit more naturally.

```suggestion
The current Go-side recognition reading rules are intentionally narrow:
```
</issue_to_address>

### Comment 4
<location path="docs/en_us/developers/quantized-sliding.md" line_range="28" />
<code_context>
 | `handlers.go`  | `Run()` dispatch, per-stage handlers, and state reset                  |
 | `overrides.go` | Pipeline override construction                                         |
-| `ocr.go`       | OCR text extraction and recognition box parsing                        |
+| `ocr.go`       | Typed-first recognition helpers for hit-box and quantity reads         |
 | `normalize.go` | Button parameter normalization and basic calculation helpers           |
 | `register.go`  | Registers the `QuantizedSliding` action into go-service                |
</code_context>
<issue_to_address>
**nitpick (typo):** Hyphenation of “hit box” is inconsistent between “hit-box” and “hit box”.

Here this entry uses “hit-box” while a later bullet uses “hit box”. Please standardize on one spelling (e.g., “hit box”) across both.

```suggestion
| `ocr.go`       | Typed-first recognition helpers for hit box and quantity reads         |
```
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- The new `readHitBox` fallback chain is a bit hard to follow and currently checks `detail.Box` twice; consider simplifying the precedence (SwipeButton Best → SwipeButton.Box → root.Box) into a clearly ordered set of guards without duplicated conditions so the behavior is easier to reason about.
- `readQuantityText` always prefers typed paths but silently returns an empty string on all failures; if quantity text is unexpectedly missing (e.g., `Results` is nil or Best is non-OCR), consider adding debug logging at the final fallback point so misconfigurations of `QuantizedSlidingGetQuantity` are easier to diagnose.

## Individual Comments

### Comment 1
<location path="agent/go-service/quantizedsliding/ocr.go" line_range="35-37" />
<code_context>
-		if ocr, ok := result.AsOCR(); ok {
-			return []int{ocr.Box.X(), ocr.Box.Y(), ocr.Box.Width(), ocr.Box.Height()}, true
-		}
+	if len(detail.Box) >= 4 {
+		return []int{detail.Box[0], detail.Box[1], detail.Box[2], detail.Box[3]}, true
 	}

</code_context>
<issue_to_address>
**suggestion:** The final `len(detail.Box) >= 4` check in `readHitBox` is redundant and can never change behavior.

Given the earlier branches:
- When `candidate == detail` and `len(detail.Box) >= 4`, the `if len(candidate.Box) >= 4` branch already returns.
- When `candidate != detail` and `len(detail.Box) >= 4`, the `if candidate != detail && len(detail.Box) >= 4` branch already returns.
So the final `if len(detail.Box) >= 4` is unreachable. It can be removed to simplify the control flow and clarify the intended precedence between `candidate` and `detail` boxes.

```suggestion
```
</issue_to_address>