Document API: capabilities().tracked is unreliable — tables.insertRow reports tracked:true but applies directly with no tracked change under changeMode:'tracked'

[ohcedar]

Summary

In the Document API, some structural ops report capabilities().operations[op].tracked === true but, when invoked with { changeMode: 'tracked' }, apply the change directly and produce no tracked change — no redline, nothing for a reviewer to accept/reject, and no error. The tracked capability flag is therefore unreliable as a signal of whether an op will actually record a tracked change.

This is distinct from #3592 (ops that legitimately can't be tracked and are flagged tracked:false). Here the capability flag says true but tracking silently no-ops.

Reproduction (v1.38.0, programmatic, Suggesting mode)

const doc = editor.doc;
doc.capabilities().operations['tables.insertRow'].tracked; // => true

// before: table has 4 rows; trackChanges.list({}).items.length === 10
doc.tables.insertRow({ nodeId: '<tableNodeId>' }, { changeMode: 'tracked' });
// after:  table has 5 rows  (row WAS inserted)
//         trackChanges.list({}).items.length === 10  (0 NEW tracked changes)
// no error thrown

Result observed: rowAdded: true, newTrackedChanges: 0, callResult: NO-THROW, with capability.tracked === true.

Expected

One of (in order of preference):

1. The row insertion is recorded as a tracked change (Word records row insert/delete as reviewable revisions), or
2. If structural row/column tracking isn't supported, capabilities() reports tracked:false for these ops (so callers can branch correctly), or
3. At minimum, calling a tracked:false-in-reality op with changeMode:'tracked' errors consistently instead of silently applying directly.

Actual

tables.insertRow reports tracked:true, accepts changeMode:'tracked' without error, and applies directly with zero tracked changes.

Inconsistency across the surface (same version)

Calling with { changeMode: 'tracked' }, three different behaviors occur:

op (example)	capabilities().tracked	behavior with changeMode:'tracked'
format.apply (inline bold/color)	true	tracked — records a tracked change ✅
styles.paragraph.setStyle, format.paragraph.setAlignment	false	throws "... does not support tracked mode"
tables.insertRow	true	silently applies directly, 0 tracked changes ❌

So a caller cannot rely on capabilities().tracked alone, nor on a consistent error contract, to decide how an op will behave under tracked mode.

Impact

For Document-API / AI-assisted review workflows, a tool that calls tables.insertRow (or other structural row/column ops) under tracked mode silently bypasses the review gate: the structural change lands with no redline and no way to accept/reject it, while the API reports the op as track-capable.

Environment

• @harbour-enterprises/superdoc 1.38.0
• Document loaded from .docx; body story; documentMode: 'suggesting'.
• Related: Track Changes: paragraph split (Enter) and paragraph-style changes are applied directly, not recorded as tracked changes #3592 (paragraph split/style not tracked — the tracked:false side of this).

[linear-code]

IT-1138

[vivienne-sd]

Hi @ohcedar , thanks for raising. We're investigating, and I'll have more info to share by EOD day. We'll then follow up early next week with when the fix is expected to land.

[vivienne-sd]

@ohcedar, we reproduced this on our side against the current prerelease and agree this is a bug in the Document API contract. Thank you again for the detailed write-up! The bug is documented, and I'll be in touch early next week as we work toward a fix.