sluice: baixar versions anteriors

**A one-line fix for a diagnostic regression v0.137.0 introduced.** If you run MySQL sync behind Vitess or PlanetScale, ProxySQL, or a tracing-instrumented client, a `SLUICE-E-CDC-STATEMENT-DML` refusal from v0.137.0 may have quoted your SQL comment instead of your statement — naming neither the verb nor the table. Values were never at risk. Plus the correction of a compatibility claim v0.137.0 over-stated. Drop-in from v0.137.0.

## Fixed

**A comment-prefixed statement keeps its diagnostic in the STATEMENT-DML refusal.** v0.137.0 taught the refusal's redaction to skip a leading SQL comment, and moved the *end* of the quoted fragment without moving its *start* — so the comment was still echoed, and a long one crowded out everything worth reading. An sqlcommenter or `traceparent` prefix runs to about 110 bytes against an 80-byte cap, so the entire quoted fragment could be comment text with no verb and no table：exactly the diagnostic loss v0.137.0 set out to fix, one step further along.

Short comments still showed a verb, which is why v0.137.0's own tests passed it — "the verb survives" and "the comment is echoed" are both true for a short comment, so a test asserting only the first cannot tell them apart. The test now asserts the comment text is *absent* too, and exercises a real sqlcommenter prefix rather than a short contrived one.

**Values were never at risk through that defect, in either version.** The comment skip only ever moved the cut earlier, never later, so no literal could reach the refusal through it. What was lost was the ability to tell which statement tripped it.

**A `/*!` versioned comment carrying a quote no longer leaks a value fragment.** Separately, and found while reviewing the above：MySQL lexes a `/*! … */` *executable* comment's contents as SQL, so a `*/` inside a string literal does **not** terminate it — unlike a plain `/* … */`, where MySQL is quote-blind exactly as sluice's scan is. A versioned comment carrying `*/` inside a quoted value therefore stopped the scan mid-value, and the remainder of that value was echoed into a refusal whose own text promises values are withheld. Ground-truthed against real MySQL 8.0.46. Such a comment is now not trusted as a comment at all: the refusal falls back to quoting nothing, which costs a diagnostic and never a value. Quote-free versioned comments — what `mysqldump` and Vitess actually emit — are unaffected.

The matching *detection* path is deliberately left alone, and the asymmetry is recorded in the code：the same mis-lex can make a healthy ROW-logged DDL look like a DML verb and raise this refusal on a working configuration, which is loud and recoverable, whereas "fixing" it would make a genuinely statement-logged write lex as nothing at all and be dropped **silently**. A false refusal outranks a silent miss.

## Changed

**v0.137.0's compatibility note is corrected in place.** It said that until `sluice trigger setup` is re-run, every existing pgtrigger install opens with a `STALE-CAPTURE-FUNCTION` warning. It does not. That warning fires only when an install's capture-function definitions **differ** from what the running binary renders — so an install whose definitions are already byte-identical, such as one created by v0.136.0, opens silent with no prompt at all.

Those installs are not broken and capture correctly. The residual, now stated rather than implied, is that without a recorded provenance digest a later hand-edit of a capture function can only be *warned* about there, never *refused*. Re-running `trigger setup` once records the digest and closes that gap, and v0.134.1's `INSECURE-CAPTURE-FUNCTION` warning already steers most affected installs to the same single re-run. A fresh install on v0.137.0 or later records the digest at setup and is unaffected.

Whether that silent case should warn is recorded as a deliberate open decision rather than changed quietly：warning there would mean a new warning firing on every stream open for every existing i

The consistency-and-hygiene release. The headline is a deliberate behavior change：a mid-sync `timestamp ⇄ timestamptz` column swap now **refuses** under the default `--schema-changes=forward` instead of silently forwarding — the rewritten values depend on the source ALTER session's `TimeZone`, which the replication wire does not carry, so the target's identical cast can silently diverge. Its sibling (`time ⇄ timetz`) already refused; the session-TZ-cast class now has one posture. Plus seven audit-filed hygiene items, all mutation-verified.

## Changed

**`timestamp ⇄ timestamptz` mid-stream swaps refuse under forward mode** (`cdc_relations.go`, the `sessionTZSwapPair` predicate, both directions, refusal naming the source-vs-target session-TimeZone mechanism and the drained-model remedy). Precision-only temporal changes (`timestamp(6)→(3)` etc.) forward and converge exactly as before — pinned. sluice's applier does not pin a session TimeZone, and a target-side pin could not close the hazard anyway (the source ALTER session's zone is not on the wire) — recorded in ADR-0091. Honest residuals filed, not fixed：the ARRAY variants (`time[] ⇄ timetz[]`, `timestamp[] ⇄ timestamptz[]`) still forward with the same per-element hazard, and MySQL's `timestamp ⇄ datetime` MODIFY is the other lane's class analogue — both are design-scoped follow-ups.

## Fixed

**`timetz` columns now project `WithTimeZone` in CDC relation state** (registry parity with the schema reader), removing a live phantom-alter every timetz column previously produced at classifier boundaries. The fix's naive form would have silently flipped `time ⇄ timetz` swaps from refuse to forward — caught by mutation before landing; the refusal is preserved with an honest session-TZ message. **The `SLUICE-E-CDC-STATEMENT-DML` tripwire now enumerates `WITH` (CTE-DML)** — previously a documented residue, a statement-format `WITH x AS (…) UPDATE` was silently dropped; it now refuses like the other DML verbs. **`LocalStore` crash-orphaned temp files** are invisible to `List` and swept (age-guarded, best-effort) by the next same-key write.

## Internal

The CDC roster gates refuse alias references of their guarded preflights (closing the invoke-through-a-variable evasion, with self-tests; name-based residual stated); honest comment corrections (`splitDBList`'s per-arm asymmetry; the probe round-trip count claim); dependency bumps (otel v1.46.0 family; kong 1.16.1 via Dependabot).

## Compatibility

Drop-in from v0.133.1 with one deliberate posture change：a `timestamp ⇄ timestamptz` ALTER mid-sync now stops the stream loudly where every prior release forwarded it. If both your ALTER session and the apply path ran UTC, the old forwarding converged and nothing was lost; if they differed, prior releases silently diverged pre-existing rows — run `sluice verify` on any table that crossed that ALTER historically. The refusal's remedy is the standard drained-model apply.

## Install

```
# Homebrew
brew upgrade sluice

# Scoop (Windows)
scoop update sluice

# Go
go install sluicesync.dev/sluice/cmd/sluice@v0.134.0
```

Container images：`ghcr.io/sluicesync/sluice:0.134.0` (multi-arch; the image tag carries no `v` prefix).

**Full changelog:** https://github.com/sluicesync/sluice/blob/main/CHANGELOG.md