# Follow-up: PR #2639 Post-Merge Finding Status

**Review:** [20260405-232458-pr-2639](20260405-232458-pr-2639.md)
**Checked against:** `upstream/master` at `3b2423e8` (squash-merge of PR #2639) plus `80139ae1` (negative-index fix from `fix-slice-negative-index` branch, merged as PR #2646)

## Addressed

**I2 — Inconsistent index-clamping structure.** Fixed. `sliceStringNode` now calls the shared `clampSliceIndex` helper introduced by PR #2646. Both the string and array paths use identical clamping logic.

**I3 — Missing string edge-case tests.** Partially fixed. The merged PR adds tests for explicit indices, omitted start/end, negative indices, both ends, full slice `[:]`, out-of-bounds clamping, and one Unicode case (`héllo[1:3]`). Still missing: very negative string indices (`.country[-100:]`, `.country[:-100]`), empty string slicing, and non-string scalar slicing.

**S1 — Commit structure.** Fixed. Squash-merged into a single commit.

**S2 — Lexer `openCollect` side-effect on `[: expr]`.** Fixed. The condition now requires `index >= 2` and verifies the preceding token is an operation or close-bracket, so standalone `[: "b"]` no longer silently inserts `0`.

**S3 — "Splice" in doc header.** Fixed. Header changed to "Slice Array or String".

**S4 — ASCII-only documentation examples.** Fixed. Added a Unicode example (`héllo[1:3]`) with a subdescription explaining rune-based indexing.

## Not addressed

**I1 — Byte-vs-rune `length` inconsistency.** `operator_length.go` is unchanged. `"café" | length` still returns 5 (bytes) while slicing treats the same string as 4 characters. Verified on `upstream/master`:

```
$ echo '"café"' | yq '(. | length) as $n | .[($n - 2):]'
é           # wrong — expected "fé"

$ echo '"café"' | yq '.[-2:]'
fé          # correct
```

This is the most impactful remaining issue: any expression that feeds `length` output into a slice bound produces wrong results on multibyte strings.

**I4 — Non-string scalar slicing produces invalid output.** No guard was added before the array fallthrough. `.value[0:2]` on a `!!int` scalar still produces `!!int []`.

**I5 — Slice index expressions evaluated against LHS instead of root context.** `sliceArrayOperator` still receives `lhsContext` for both node iteration and index evaluation. `.a[0:.max]` still fails with "cannot index array with 'max'" instead of resolving `.max` from the document root.

## Summary

Six of nine findings addressed (all four suggestions, I2, and partially I3). The three remaining important issues (I1, I4, I5) are pre-existing gaps that the PR exposed rather than introduced — none are regressions.