Recent main bumps to golangci-lint 2.12.2 (#20238) + Go 1.26.3 (#20241)
made govet's "inline deprecated constant" check fire on reflect.Ptr
(deprecated alias for reflect.Pointer added in Go 1.18). Main itself
has not re-run CI under the bumped versions yet, so this surfaced
first on PRs landing on top of the bumps. Two pre-existing call sites
needed updating.

No functional change — reflect.Ptr and reflect.Pointer are the same
constant.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(spec): BYT-9367 Oracle splitter trailing `;` leak design

Captures root cause (single-token SEMI lookahead skips hidden-channel
tokens), corrected design intent (channel-aware skip), fix code, test plan
(4 new YAML cases covering every cell of the design gap), audit
confirming bug is one-engine, and risk/rollback notes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(spec): correct PlSqlLexer.g4 line refs in BYT-9367 design

Whitespace SPACES rule is at line 2638; the 2621-2624 range only covers
the three comment rules. Spec now cites both ranges.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(plan): BYT-9367 Oracle splitter trailing ';' leak implementation

Six-task plan: verify starting state, capture buggy YAML snapshot to
demonstrate the leak, apply the channel-aware loop fix at split.go:108-113,
re-record YAML and verify text invariants, lint+build, commit. Three new
test fixtures (BYT-9367 exact, leading inline comment, multi-newline) plus
existing fixtures for cells (a), (e), (f), (g) of the design gap.

Spec: docs/superpowers/specs/2026-05-07-oracle-splitter-trailing-semicolon-leak-design.md

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(spec,plan): expand BYT-9367 to cover Trino + Range bookkeeping

Review surfaced two real issues missed in the original draft:

1. byteOffsetStart bookkeeping: when the channel-aware loop consumes
   tokens, the next statement's Range.Start (and Start.Line/Column)
   stayed at byteOffsetEnd of the previous statement, off by N bytes
   (where N = bytes consumed by the loop). Fix adds a 3-line update
   to advance byteOffsetStart past consumed tokens. Three existing
   plsql fixtures re-record with 1-byte/1-column shifts.

2. Trino splitter has the same bug class at trino/split.go:88-91.
   Single-token SEMI lookahead misses whitespace before ';'. Added
   to scope; same loop fix without bookkeeping (trino's text/range
   model handles it naturally via statement[byteOffsetStart:rangeEnd]).

Spec restructured: §4 design gap split into Invariant A (Text) and
Invariant B (Range alignment). §5 has separate plsql (5.1) and
trino (5.2) fixes. §6 test plan covers cells (b,c,d,f,h) for plsql
and 3 Trino fixtures. §7 audit updated. §8 risk lists which
existing fixtures re-record.

Plan restructured: Task 1 verifies both buggy locations and audits
trino's tokenizer fallback. Task 2 adds all 8 new fixtures with
result: [] placeholders. Task 3 applies both fixes. Task 4 records
once and verifies text invariants + expected existing-fixture shifts.

Pre-fix snapshot ceremony dropped (review feedback: risks accidental
commit, marginal value). allTokens hoist removed from spec but kept
in plsql code (used twice, worth the local).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(spec,plan): BYT-9367 v3 — drop Trino, fix cell (f), tighten bookkeeping

Adversarial review caught two real issues in v2:

1. Trino does NOT have the bug. TrinoParser.g4:38-40 says
   `singleStatement: statement SEMICOLON_` — the `;` is REQUIRED in the
   parse tree. `singleStmt.GetStop()` is the `;` itself, and rangeEnd =
   endToken.GetStop()+1 already extends past it. The 1-token lookahead
   at trino/split.go:89 handles a stray double-`;` (empty statement
   absorption), not the BYT-9367 leak shape. v3 removes Trino from
   scope entirely and updates §7 audit row to explain why.

2. v2's cell (f) input `BEGIN NULL; END\n/` is grammatically invalid:
   anonymous_block requires `END SEMICOLON` (PlSqlParser.g4:5386). v3
   replaces with `BEGIN NULL; END;\nSELECT 1 FROM dual` — anonymous
   block (needSemicolon, stop=`;`) followed by SELECT with only `\n`
   between, exercising the bail-on-default-channel branch with a
   non-`/` token (a SELECT keyword).

Other fixes:
- §6.2 missed 4th re-record fixture: `SELECT statements separated by
  forward slash` (line 120). Stmt 1 is non-needSemicolon SELECT, so the
  bookkeeping fires and shifts stmt 2's range/start.column by 1.
- Bookkeeping uses stop-index arithmetic (`allTokens[prevStop].GetStop()
  - allTokens[loopStart].GetStop()`) instead of materializing the
  consumed text via GetTextFromTokens. Equivalent and cheaper.
- §5.3 (v1→v2 changelog note) dropped — redundant with §4.
- Plan tokenizer-audit step removed (no longer needed without Trino).

Net code change: ~10 lines (loop + 2-line bookkeeping). Five new YAML
fixtures, four existing fixtures re-record with 1-byte/1-column shifts.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(spec,plan): BYT-9367 v4 — fix UTF-8 bookkeeping bug, correct fixture count

Adversarial review caught two real issues in v3:

1. BLOCKER: stop-index arithmetic for bookkeeping is rune-based, not
   byte-based. ANTLR's InputStream uses []rune internally (bytebase/antlr
   v4@v4.0.0/input_stream.go:14), and token Start/Stop are rune indices.
   Go's len(string) is byte length. For ASCII the two coincide, but
   multi-byte UTF-8 inside a hidden token (e.g., a comment with non-ASCII
   characters) would diverge — the bookkeeping would advance byteOffsetStart
   by rune count instead of byte count, drifting Range and line/column.
   Reverted to len(GetTextFromTokens(...)) which is unconditionally
   byte-correct (matches the byte-offset arithmetic at line 82).

2. v3 said "14 existing fixtures (4 change, anonymous-block-with-/ at lines
   55,79,150,172 region unchanged)" but actually there are 15 fixtures and
   line 172 is ALTER TABLE (not an anonymous-block-with-/). v4 spells out
   the full set: 15 fixtures, 4 change, 11 unchanged, with explicit per-
   fixture rationale.

Other v4 cleanups:

- Cell (d) "if 3 unit_statements" hedge was impossible per grammar
  (sql_script: ((unit_statement) SEMICOLON? | SEMICOLON)*), so a bare
  `;` matches the top-level alternative, not a unit_statement, and the
  splitter only iterates IUnit_statementContext children. Cell (d) always
  produces exactly 2 unit_statements; the hedge is removed.
- Spec §4 Invariant B condensed (~10 lines cut) — the §6.2 table now
  carries the concrete numbers.
- Spec §5 Properties list trimmed; fixture-by-fixture behavior moved to
  §6 where it belongs.
- Plan Task 1 Step 1 (sed-check the lookahead block) dropped — the Edit
  tool's exact-match contract subsumes it.
- Plan re-record table now lists exact byte numbers per codex's trace.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(plsql): trailing ';' leak when whitespace/comment separates stop and ';'

BYT-9367. The plsql splitter's "advance past trailing ';'" lookahead
inspected only the token immediately after the parse-tree stop, so any
hidden-channel token (whitespace, comment) between the stop and the ';'
prevented consumption. The ';' then leaked into the next statement's
text. For Oracle this surfaced as ORA-00900 at position 1.

Replace the single-token lookahead with a channel-aware loop that skips
hidden-channel tokens until it finds ';' (consume) or a default-channel
non-';' token (bail). After the loop, advance byteOffsetStart by the byte
length of any consumed tokens so the next statement's Range.Start aligns
with where its leadingContent actually begins in source. This also
quietly fixes a pre-existing 1-byte off-by-one in the immediate-';' case
(visible in 4 existing fixtures).

Tests:
- 5 new YAML fixtures (cells b/c/d/f/h of the design gap).
- 4 existing fixtures re-recorded with 1-byte/1-column Range/Start.Column
  shifts (text unchanged): multiple SELECT statements, multiple statements
  with newlines, SELECT statements separated by forward slash, position
  semantic: multi-statement with leading whitespace.

Trino was investigated and ruled out — TrinoParser.g4 requires ';' in
the singleStatement parse tree, so the leak shape can't occur there.

Spec: docs/superpowers/specs/2026-05-07-oracle-splitter-trailing-semicolon-leak-design.md

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(plsql): mirror BYT-9367 trailing ';' walk in ParsePLSQL AST path

The BYT-9367 fix in SplitSQL (commit ce6470b) cleaned up Statement.Text
for the leak shape. But ParsePLSQL — used by ParseStatements to attach
per-statement ASTs — has its own per-statement loop with the same
"prevStopTokenIndex = stopToken.GetTokenIndex()" pattern and was NOT
fixed, so the reparse substring for the next statement still absorbed
the trailing ';'. The reparsed sub-AST then had a leading bare SEMICOLON
child, which getStatementType()'s "return type of first child" walk
classified as STATEMENT_TYPE_UNSPECIFIED. Statement.Text was clean but
the attached AST was misclassified for any BYT-9367 input.

Apply the same channel-aware loop in ParsePLSQL: after stopIdx, walk
hidden-channel tokens looking for ';' (consume) or default-channel
non-';' (bail). No byteOffsetStart bookkeeping is needed in this
function — only prevStopTokenIndex matters for the next iteration's
leadingContent computation.

The audit gap: spec §7 covered splitters across engines but did not
explicitly scan for "duplicate of the splitter loop in a separate
parse path". Both SplitSQL and ParsePLSQL had the bug; only one was
fixed in the previous commit.

Tests:
- New byt9367_repro_test.go: TestBYT9367_ParseStatementsClassification
  covers cells b/c/d (whitespace-, comment-, multi-newline-before-';')
  via base.ParseStatements + GetStatementTypes round-trip. Without the
  fix, statement #2 (or #1 for cell c) classified as UNSPECIFIED.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor(plsql): extract consumeTrailingSemicolon helper, broaden BYT-9367 test

Two convergent review findings from round 2:
- The channel-aware loop was duplicated verbatim between SplitSQL
  (split.go) and ParsePLSQL (plsql.go). The duplication is exactly the
  failure shape that caused BYT-9367's secondary leak — one path was
  fixed, the parallel one was forgotten.
- The regression test (TestBYT9367_ParseStatementsClassification)
  asserted on the deduplicated GetStatementTypes output, which has
  non-deterministic order and only covered cells b/c/d.

Extract consumeTrailingSemicolon(allTokens, stopIdx) into split.go and
call it from both SplitSQL and ParsePLSQL. Drop the TODO(zp) "consolidate
with split logic in ParsePLSQL?" — done. SplitSQL still owns the
byte-offset bookkeeping (no analogue in ParsePLSQL).

Strengthen the regression test:
- Switch to per-AST classification via getStatementType() so a single
  misclassified AST is detected even when other ASTs share its type.
  Order-deterministic.
- Add cell f (no separator, exercises bail-on-default-channel via the
  AST path) and cell h (trailing ';' at EOF, exercises loop bound).

Tests: all 20 splitter subtests pass; all 5 BYT-9367 classification
subtests pass; lint clean; build clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor(plsql): migrate BYT-9367 classification regression to YAML, trim call-site comments

Round-3 review findings:
- byt9367_repro_test.go's cell f assertion `[UNSPECIFIED, UNSPECIFIED]`
  did not distinguish bug-vs-fix because getStatementType doesn't
  classify SELECT either; the AST shape is invariant under the bail
  branch since stmtText is computed from startToken/stopToken regardless
  of prevStopTokenIndex.
- Cell h's single-statement input has no second-stmt classification
  bug to manifest.
- Call-site comments duplicated the helper's godoc.
- File naming (byt9367_repro_test.go) was an outlier vs the package's
  domain-named test files.

Move cells (b)(c)(d) — the cells where ParsePLSQL's reparse text
actually changes between bug and fix states — into
test_statement_type.yaml. The shared TestGetStatementType runner
asserts on the deduplicated GetStatementTypes set; for these inputs
the bug produces [INSERT, UNSPECIFIED] (catches), the fix produces
[INSERT] (passes). Verified empirically by reverting plsql.go's
helper call and observing the YAML test failure.

Drop byt9367_repro_test.go entirely. Cell f / h smoke coverage is
already in test_split.yaml at the SplitSQL layer (where the bail
branch and EOF behavior ARE distinguishing).

Trim call-site block comments — the helper godoc owns the rationale.

Tests: TestGetStatementType, TestPLSQLSplitSQL all pass; lint clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* ci: retrigger CodeQL Analyze (go) after runner cancellation

The CodeQL Go scan on commit 8d6ae7f terminated with 'The runner has
received a shutdown signal' — runner preemption, no code issue. Pushing
an empty commit to retrigger; no functional change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore(lint): replace deprecated reflect.Ptr with reflect.Pointer

Recent main bumps to golangci-lint 2.12.2 (#20238) + Go 1.26.3 (#20241)
made govet's "inline deprecated constant" check fire on reflect.Ptr
(deprecated alias for reflect.Pointer added in Go 1.18). Main itself
has not re-run CI under the bumped versions yet, so this surfaced
first on PRs landing on top of the bumps. Two pre-existing call sites
needed updating.

No functional change — reflect.Ptr and reflect.Pointer are the same
constant.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>