The heading depth logic has potential overflow/underflow issues when the shift amount is larger than expected:

1. In shift_left (line 2346-2347): If shift_amount >= heading.depth, the depth could underflow (though u8 subtraction would wrap). The condition should be >= not <, and when the shift is larger than depth, it should set depth to 1 (the minimum).

2. In shift_right (line 2380-2381): The addition could overflow u8. If heading.depth + shift_amount > 6, it correctly caps at 6, but if shift_amount is very large (e.g., 250), the addition heading.depth + shift_amount could overflow u8 and wrap around, making the condition false when it should be true.

Use checked arithmetic or explicitly handle large shift amounts to avoid these edge cases.

Missing test coverage for important edge cases:

1. Negative numbers: shift_left(-1, 1), shift_right(-1, 1)
2. Non-integer numbers: shift_left(1.5, 1), shift_right(2.7, 1)
3. Large shift amounts on headings that could cause overflow: shift_right(h6, 250), shift_left(h1, 250)
4. Shift amount of 0: shift_left(value, 0), shift_right(value, 0)

These edge cases should be tested to verify the behavior is correct and doesn't cause panics or unexpected results.

String indexing using byte positions v[shift_amount..] and v[..v.len() - shift_amount] is unsafe for UTF-8 strings and will panic if the shift amount falls in the middle of a multi-byte character.

For example, shift_left("😀ab", 1) would panic because the emoji is 4 bytes and indexing at byte 1 is not a valid character boundary.

Use character-based indexing instead:

let chars: Vec<char> = v.chars().collect();
if shift_amount >= chars.len() {
    Ok(RuntimeValue::String(String::new()))
} else {
    Ok(RuntimeValue::String(chars[shift_amount..].iter().collect()))
}

Or use methods like v.chars().skip(shift_amount).collect() for better performance.

The to_int() method uses a simple as u64 cast which truncates negative floats to 0 and can produce incorrect results for values outside the u64 range. For bitwise shift operations, you should either:

1. Explicitly handle negative numbers and return an error
2. Use as i64 instead and handle the signed case
3. Document that only non-negative integers are supported and validate the input

Consider what happens with shift_left(-1, 1) or shift_left(1.5, 1) - the cast will produce unexpected results.

The to_int() conversion on line 30-31 performs an unchecked as u64 cast from f64, which can produce unexpected results for negative numbers or floating-point values. For example, -1.0 as u64 produces a very large number (due to two's complement), and 1.5 as u64 truncates to 1. Consider validating that the number is non-negative and integral before the conversion, or using value().max(0.0) as u64 to ensure non-negative results.

String slicing with v[..v.len() - shift_amount] may panic if the slice boundary falls in the middle of a multi-byte UTF-8 character. Consider using character-based operations like v.chars().take(v.chars().count() - shift_amount).collect::<String>() to properly handle UTF-8, or add validation that the slice boundary is valid.

Duplicate test case names: both lines 2046 and 2053 use shift_right_header_level_h1, and both lines 2067 and 2074 use shift_left_header_level_h2. The operator syntax tests should have distinct names like shift_right_header_level_h1_operator to differentiate them from the function call syntax tests.

The conversion from Number to u8 for heading depth may overflow. A large shift amount like shift_right(heading, 1000) would convert 1000.0 to u8, which wraps to 232 (1000 % 256). This could produce unexpected results. Consider adding validation to ensure the shift amount is reasonable for heading depth operations (e.g., <= 6 for shift_right, or <= heading.depth for shift_left).

String slicing with v[shift_amount..] may panic if the shift_amount falls in the middle of a multi-byte UTF-8 character. Consider using v.chars().skip(shift_amount).collect::<String>() or v.char_indices() to properly handle UTF-8 boundaries, or add validation that shift_amount is a valid character boundary.

SHIFT_RIGHT returns RuntimeValue::NONE for unsupported operand types (_ => Ok(RuntimeValue::NONE)). For a fixed-arity builtin used as a binary operator, this is inconsistent with operators like add/sub which return Error::InvalidTypes, and it can silently hide programming mistakes. Consider returning InvalidTypes for [a, b] mismatches (while still handling None explicitly if desired).

Several rstest cases reuse the same case name (e.g. case::shift_left_number / case::shift_right_number). rstest uses these names to generate test identifiers, so duplicates can cause compile-time name collisions. Give each case a unique name (e.g. suffix _fn vs _op).

SHIFT_RIGHT on strings uses byte slicing (v[..v.len() - shift_amount]), which can panic for non-ASCII UTF-8 (invalid slice boundary) and also treats the shift amount as bytes instead of characters. Use a character-safe approach (e.g., operate on chars() like SLICE does) so shifting works correctly for Unicode and can’t panic.

SHIFT_LEFT returns RuntimeValue::NONE for unsupported operand types (_ => Ok(RuntimeValue::NONE)). For a fixed-arity builtin used as a binary operator, this is inconsistent with operators like add/sub which return Error::InvalidTypes, and it can silently hide programming mistakes. Consider returning InvalidTypes for [a, b] mismatches (while still handling None explicitly if desired).

Duplicate test case name 'shift_left_header_level_h2'. The test case on line 2067 already uses this name. Consider renaming this test to 'shift_left_header_level_h2_via_binding' to match the pattern used in similar tests (e.g., line 2053 uses 'shift_right_header_level_h1_operator').

The implementation doesn't handle negative shift amounts. When n.value() is cast to u32 on line 2360, a negative value will wrap around to a very large unsigned value, likely causing the checked_shr to return None and produce a "Shift amount is too large" error. Consider adding explicit handling for negative values, either by returning an error with a clearer message or by treating negative shifts as shifts in the opposite direction.

The implementation doesn't handle negative shift amounts. When n.value() is cast to u32 on line 2331, a negative value will wrap around to a very large unsigned value, likely causing the checked_shl to return None and produce a "Shift amount is too large" error. Consider adding explicit handling for negative values, either by returning an error with a clearer message or by treating negative shifts as shifts in the opposite direction.

Current tests cover basic heading shifting and the depth bounds at 1 and 6, but they don't cover shifting a heading by an amount that would exceed depth 6 (or very large amounts) to ensure the implementation clamps/saturates and never panics. Adding a case like shifting an h2 by 10 (and/or 1000) would prevent regressions once the SHIFT_RIGHT overflow/clamping logic is fixed.

increase_header_level is marked as backward compatible, but implementing it via increase_header_depth -> shift_right(node, 1) changes behavior for non-heading inputs (e.g. numbers/strings will now be shifted/sliced instead of being returned unchanged, as the previous builtins did). To preserve compatibility, consider only applying the shift when is_h(node) (or similar) and otherwise returning node unchanged.

Similarly, decrease_header_level is marked as backward compatible, but delegating to shift_left(node, 1) will modify non-heading inputs (e.g. strings get truncated) rather than passing them through unchanged. Consider guarding so only Markdown headings are affected, returning node unchanged otherwise.