@outbuild-company/schedule-core 1.9.0 → 1.9.2

package/dist/index.d.cts

@@ -134,13 +134,6 @@ interface CoreActivity {
     recursiveDurationHours: number;
     isCritical: boolean;
     freeSlackHours: number | null;
-    /**
-     * Días de calendario crudos entre start y end (incluye no laborables). Es una
-     * columna del grid, así que la posee el core (decisión del owner 2026-08-03):
-     * estado derivado que el core mantiene al nacer la actividad y al escribir
-     * start/end/type (`internal/state/calendar-duration.ts`), y que por eso fluye
-     * solo por vistas, ChangeSets y undo. Milestone → 0; fechas inválidas → null.
-     */
     calendarDuration?: number | null;
     expectedProgress: number | null;
     expectedProgressBaseline: number | null;
@@ -203,7 +196,6 @@ interface SectorMetadata {
     updateDurationForPrimaveraEndDate?: boolean;
     activityCreter?: ActivityCreter;
     statusCriteria: StatusCriteria;
-    /** Declared by the loader input; never derived from the backend payload. */
     ganttId: number | null;
 }
 interface EntityChange<T> {
@@ -318,28 +310,12 @@ interface FilterState {
 }
 
 interface OrderRule {
-    /**
-     * Deliberately FilterField, not an alias of it: the columns a user can sort by
-     * are the columns a user can filter by, and the filter's registry already
-     * resolves units, baseline snapshots and critical-path values for all of them.
-     * A second field vocabulary would drift from this one on the first new column.
-     */
     readonly field: FilterField;
     readonly direction: 'asc' | 'desc';
 }
-/**
- * The active ordering, as an ordered list of keys: rule 0 decides, rule 1 breaks
- * its ties, and so on. An empty list means "no user ordering", which is stored
- * as null rather than an empty state (mirroring isEmptyFilter).
- */
 interface OrderState {
     readonly rules: ReadonlyArray<OrderRule>;
 }
-/**
- * One resequenced sibling group. Ordering is hierarchical: an activity only ever
- * competes with its own siblings, so a change is expressed per parent rather
- * than as a flat sequence over the whole schedule.
- */
 interface BranchOrderChange {
     readonly parentId: string;
     readonly childIds: ReadonlyArray<string>;
@@ -412,12 +388,6 @@ type DispatchAction = {
     kind: 'persistence-acknowledge';
     activities?: ReadonlyArray<PersistedEntityIdentity>;
     links?: ReadonlyArray<PersistedEntityIdentity>;
-    /**
-     * CP19 (ISSUE-070): valores que el backend normalizo al guardar (hoy solo
-     * progress). El motor los reconcilia — aplica los que difieren, ignora
-     * los iguales — para que el core refleje lo persistido. Sin undo: el
-     * acuse es clear-on-success y el tracker snapshotea despues.
-     */
     reconciledProgress?: ReadonlyArray<ReconciledActivityProgress>;
 } | {
     kind: 'baseline-apply';
@@ -497,14 +467,6 @@ type DispatchAction = {
     kind: 'activity-set-progress';
     activityId: ActivityId;
     newValue: 0 | 100;
-    /**
-     * CP15 (ISSUE-066): el origen se DECLARA, no se adivina. 'action-button'
-     * es el unico origen con salvoconducto
-     * de negocio para actividades en Lookahead (espejo del flag
-     * progressChangedByActionButton que consume parseToUpdate en el
-     * backend; guia agents/progreso-lookahead.md). Sin origen declarado
-     * aplica el canEdit completo del pipeline.
-     */
     origin?: 'action-button';
     eventSource?: string;
 } | {
@@ -627,14 +589,6 @@ interface ChangeSet {
     calendars: ReadonlyArray<EntityChange<Calendar>>;
     trackingEvents: ReadonlyArray<TrackingEvent>;
     viewState?: ReadonlyArray<ViewStateChange>;
-    /**
-     * Sibling groups whose display sequence changed, each already in final order.
-     * Carried per branch rather than as a flat sequence because ordering never
-     * reparents: the renderer assigns each array and repaints once.
-     *
-     * Absent when nothing resequenced. Never a partial answer: a branch listed
-     * here holds all of its children.
-     */
     order?: ReadonlyArray<BranchOrderChange>;
     effects?: ReadonlyArray<ScheduleEffect>;
     warnings?: ReadonlyArray<ConstraintWarning>;
@@ -667,15 +621,6 @@ interface BackendCalendarInput {
     baseexceptiondays?: BackendCalendarExceptionInput[];
 }
 interface BackendActivityInput {
-    /**
-     * Persisted backend identity.
-     *
-     * Synthetic activities that have not been persisted yet use `null`.
-     * `unique_id` remains their stable local identity.
-     *
-     * A numeric zero is intentionally preserved as a numeric backend identity
-     * for compatibility with the certified proplanner-id/002 scenario.
-     */
     id: number | null;
     unique_id: string;
     parent_id: string;
@@ -814,29 +759,6 @@ declare class ScheduleCore {
     private readonly _undo;
     private _opQueue;
     private _scheduleRevision;
-    /**
-     * Revision counting mutations that have been ADMITTED, whether or not they
-     * have changed anything yet. `_scheduleRevision` counts the ones that
-     * actually did.
-     *
-     * INVARIANT: `_pendingScheduleRevision >= _scheduleRevision`, and equality
-     * means no mutation is in flight.
-     *
-     * The two exist separately because the useful instant and the knowable
-     * instant are not the same one. A critical-path calculation becomes garbage
-     * the moment the next mutation is admitted, but whether that mutation is
-     * substantive is only knowable once its ChangeSet exists, which is hundreds
-     * of milliseconds later at project scale. Measured live on a 12268-activity
-     * project: the cancellation flag flipped 929 ms into a 930 ms calculation,
-     * 812 into 812 and 785 into 785, because the job's apply block queues behind
-     * the very dispatch whose completion cancels it. Cancellation and job end
-     * were the same event, so every discarded job ran the whole calculation.
-     *
-     * Splitting the counter buys the early signal without moving the meaning of
-     * `_scheduleRevision`, whose three readers (`isCriticalPathSettled`,
-     * `createDateGesturePreview` and the job's own `isCurrent`) are all written
-     * against "the state actually changed".
-     */
     private _pendingScheduleRevision;
     private _criticalPathRevision;
     private _activeCriticalPath;
@@ -851,13 +773,6 @@ declare class ScheduleCore {
     getActivityView(id: ActivityId): Readonly<CoreActivity> | null;
     createDateGesturePreview(gesture: DateGesture): DateGesturePreview;
     getAllActivitiesView(): ReadonlyArray<Readonly<CoreActivity>>;
-    /**
-     * Read del plan de indent (ISSUE-080): los padres destino DISTINTOS bajo los
-     * que quedarían las actividades si se indentaran ahora. Es exactamente la
-     * planificación que ejecuta el handler (`planIndentMoves`, autoridad única),
-     * expuesta para que la frontera pueda correr el protocolo de conversión a
-     * madre (chequeo backend + modal) ANTES de despachar. Solo lecturas.
-     */
     getIndentTargetParentIds(activityIds: ReadonlyArray<ActivityId | string>): readonly string[];
     getChildrenView(parentId: ActivityId | '0'): ReadonlyArray<Readonly<CoreActivity>>;
     getLinkView(id: LinkId): Readonly<Link> | null;
@@ -884,53 +799,14 @@ declare class ScheduleCore {
     getModifiedActivities(): ReadonlyArray<Readonly<CoreActivity>>;
     getNewActivities(): ReadonlyArray<Readonly<CoreActivity>>;
     hasUnsavedChanges(): boolean;
-    /** Read-only revision; moves once per substantive mutation. */
     getScheduleRevision(): number;
     getCanonicalDigest(): string;
     createProjectionChangeSetFrom(source: ScheduleCore): ChangeSet;
     getDeletedActivitiesSinceLastSave(): ReadonlyArray<Readonly<DeletedActivitySnapshot>>;
     getDeletedLinksSinceLastSave(): ReadonlyArray<Readonly<DeletedLinkSnapshot>>;
     private _enqueue;
-    /**
-     * Marks a mutation as admitted and invalidates the calculation in flight.
-     *
-     * Called BEFORE `_enqueue`, which is the point of the whole thing: the wait
-     * in the operation queue is part of the window a running calculation wastes,
-     * and it is the longest part of it when several mutations are already
-     * queued.
-     *
-     * `dispatchChangesSchedulingState` is a pure function of the action, so this
-     * decision needs no state and cannot be wrong about the action's nature. What
-     * it cannot know yet is whether the mutation will produce anything, which is
-     * what `_settleScheduleMutation` reconciles afterwards.
-     */
     private _beginScheduleMutation;
-    /** Undo and redo have no action to classify: reaching them IS the mutation. */
     private _admitScheduleMutation;
-    /**
-     * Closes a mutation admitted by `_beginScheduleMutation`, on EVERY exit path.
-     *
-     * `changedState` false means the mutation was admitted and produced nothing
-     * (rejected, non-substantive, or rolled back). The pending revision walks
-     * back so the invariant holds and `isCriticalPathSettled` keeps telling the
-     * truth, and the calculation this mutation killed for nothing is re-armed.
-     *
-     * The re-arm goes through the queue and that is not incidental. Started
-     * outside it, the calculation would run immediately while the next queued
-     * mutation is still waiting, and that mutation would kill it again on
-     * admission: a cancel-and-restart treadmill burning a fresh project-wide deep
-     * copy per lap. Inside the queue the restart cannot happen until the queue
-     * drains, so at most one calculation is armed per settled mutation. The burst
-     * scenario will NOT catch a regression here, because there every dispatch
-     * succeeds and this path is never taken.
-     *
-     * It re-arms through `recomputeCriticalPath` rather than enqueueing the job
-     * directly, because the queue slot must NOT await the job: the job's own
-     * apply block needs a later slot on this same queue, so awaiting it from
-     * inside a slot deadlocks the core. `recomputeCriticalPath` already has the
-     * shape that returns the job's promise out of the slot instead of awaiting
-     * it, and it keeps `_criticalPathReady` pointing at the live calculation.
-     */
     private _settleScheduleMutation;
     dispatch(action: DispatchAction, options?: DispatchOptions): Promise<DispatchResult>;
     applyActivityBatch(action: ActivityBatchAction, options?: DispatchOptions): Promise<DispatchResult>;
@@ -942,51 +818,8 @@ declare class ScheduleCore {
     isCriticalPathSettled(): boolean;
     whenCriticalPathSettled(): Promise<void>;
     private _withReappliedViewState;
-    private _recordRelativePlacementPin;
-    /**
-     * The single place the two view-state passes are chained. Dispatch, undo and
-     * redo all route through here: when this existed only inside the dispatch
-     * path, undo and redo reapplied the filter and forgot the order, so an edit
-     * that moved a row and was then undone left the row in its new position.
-     *
-     * The sequence between the passes is indifferent. Filter and order are
-     * orthogonal projections over the same tree — the filter decides which rows
-     * exist on screen and never reads the order; the order sequences every
-     * sibling group from the hierarchy index and never reads visibility. Either
-     * sequence produces the same ChangeSet.
-     *
-     * Both passes answer null while their state is inactive, so an unfiltered,
-     * unsorted schedule pays two property reads.
-     */
     private _reapplyViewState;
-    /**
-     * Emits `order` for the branches this mutation resequenced, when no user order
-     * is active.
-     *
-     * The contract is that `order` reports a CHANGED SEQUENCE, not the presence of
-     * a sort. Tying emission to the cause instead of the effect is what produced
-     * the undo bug and, later, the reparent ones: without an active order a move,
-     * an indent, an outdent or the undo of any of them rearranged rows and said
-     * nothing, so an incremental consumer kept the old sequence. The undo of a
-     * reparent was the worst of them — it carried neither `order` nor a single
-     * correlativeId, so the position was not recoverable by any consumer.
-     *
-     * The touched branches are derived from the ChangeSet rather than accumulated
-     * in the state: an entity whose parentId or correlativeId moved, plus the
-     * parents of created and deleted rows, is exactly the set of branches whose
-     * sequence can differ. That keeps this linear in the blast radius, adds
-     * nothing to the write path, and cannot leak across dispatches.
-     */
     private _emitTouchedBranchOrder;
-    /**
-     * Re-sequences the grid after any mutation that could have changed a value the
-     * active order sorts by. Ordering is a view over the data, so an edit that
-     * moves a row past its sibling must move the row, exactly as the filter makes
-     * a no-longer-matching row disappear.
-     *
-     * Production only re-sorts after a bar drag; diverging from that is a
-     * deliberate product decision, not an oversight.
-     */
     private _reapplyActiveOrder;
     private _reapplyActiveFilter;
     private _recordScheduleMutation;

package/dist/index.d.ts

@@ -134,13 +134,6 @@ interface CoreActivity {
     recursiveDurationHours: number;
     isCritical: boolean;
     freeSlackHours: number | null;
-    /**
-     * Días de calendario crudos entre start y end (incluye no laborables). Es una
-     * columna del grid, así que la posee el core (decisión del owner 2026-08-03):
-     * estado derivado que el core mantiene al nacer la actividad y al escribir
-     * start/end/type (`internal/state/calendar-duration.ts`), y que por eso fluye
-     * solo por vistas, ChangeSets y undo. Milestone → 0; fechas inválidas → null.
-     */
     calendarDuration?: number | null;
     expectedProgress: number | null;
     expectedProgressBaseline: number | null;
@@ -203,7 +196,6 @@ interface SectorMetadata {
     updateDurationForPrimaveraEndDate?: boolean;
     activityCreter?: ActivityCreter;
     statusCriteria: StatusCriteria;
-    /** Declared by the loader input; never derived from the backend payload. */
     ganttId: number | null;
 }
 interface EntityChange<T> {
@@ -318,28 +310,12 @@ interface FilterState {
 }
 
 interface OrderRule {
-    /**
-     * Deliberately FilterField, not an alias of it: the columns a user can sort by
-     * are the columns a user can filter by, and the filter's registry already
-     * resolves units, baseline snapshots and critical-path values for all of them.
-     * A second field vocabulary would drift from this one on the first new column.
-     */
     readonly field: FilterField;
     readonly direction: 'asc' | 'desc';
 }
-/**
- * The active ordering, as an ordered list of keys: rule 0 decides, rule 1 breaks
- * its ties, and so on. An empty list means "no user ordering", which is stored
- * as null rather than an empty state (mirroring isEmptyFilter).
- */
 interface OrderState {
     readonly rules: ReadonlyArray<OrderRule>;
 }
-/**
- * One resequenced sibling group. Ordering is hierarchical: an activity only ever
- * competes with its own siblings, so a change is expressed per parent rather
- * than as a flat sequence over the whole schedule.
- */
 interface BranchOrderChange {
     readonly parentId: string;
     readonly childIds: ReadonlyArray<string>;
@@ -412,12 +388,6 @@ type DispatchAction = {
     kind: 'persistence-acknowledge';
     activities?: ReadonlyArray<PersistedEntityIdentity>;
     links?: ReadonlyArray<PersistedEntityIdentity>;
-    /**
-     * CP19 (ISSUE-070): valores que el backend normalizo al guardar (hoy solo
-     * progress). El motor los reconcilia — aplica los que difieren, ignora
-     * los iguales — para que el core refleje lo persistido. Sin undo: el
-     * acuse es clear-on-success y el tracker snapshotea despues.
-     */
     reconciledProgress?: ReadonlyArray<ReconciledActivityProgress>;
 } | {
     kind: 'baseline-apply';
@@ -497,14 +467,6 @@ type DispatchAction = {
     kind: 'activity-set-progress';
     activityId: ActivityId;
     newValue: 0 | 100;
-    /**
-     * CP15 (ISSUE-066): el origen se DECLARA, no se adivina. 'action-button'
-     * es el unico origen con salvoconducto
-     * de negocio para actividades en Lookahead (espejo del flag
-     * progressChangedByActionButton que consume parseToUpdate en el
-     * backend; guia agents/progreso-lookahead.md). Sin origen declarado
-     * aplica el canEdit completo del pipeline.
-     */
     origin?: 'action-button';
     eventSource?: string;
 } | {
@@ -627,14 +589,6 @@ interface ChangeSet {
     calendars: ReadonlyArray<EntityChange<Calendar>>;
     trackingEvents: ReadonlyArray<TrackingEvent>;
     viewState?: ReadonlyArray<ViewStateChange>;
-    /**
-     * Sibling groups whose display sequence changed, each already in final order.
-     * Carried per branch rather than as a flat sequence because ordering never
-     * reparents: the renderer assigns each array and repaints once.
-     *
-     * Absent when nothing resequenced. Never a partial answer: a branch listed
-     * here holds all of its children.
-     */
     order?: ReadonlyArray<BranchOrderChange>;
     effects?: ReadonlyArray<ScheduleEffect>;
     warnings?: ReadonlyArray<ConstraintWarning>;
@@ -667,15 +621,6 @@ interface BackendCalendarInput {
     baseexceptiondays?: BackendCalendarExceptionInput[];
 }
 interface BackendActivityInput {
-    /**
-     * Persisted backend identity.
-     *
-     * Synthetic activities that have not been persisted yet use `null`.
-     * `unique_id` remains their stable local identity.
-     *
-     * A numeric zero is intentionally preserved as a numeric backend identity
-     * for compatibility with the certified proplanner-id/002 scenario.
-     */
     id: number | null;
     unique_id: string;
     parent_id: string;
@@ -814,29 +759,6 @@ declare class ScheduleCore {
     private readonly _undo;
     private _opQueue;
     private _scheduleRevision;
-    /**
-     * Revision counting mutations that have been ADMITTED, whether or not they
-     * have changed anything yet. `_scheduleRevision` counts the ones that
-     * actually did.
-     *
-     * INVARIANT: `_pendingScheduleRevision >= _scheduleRevision`, and equality
-     * means no mutation is in flight.
-     *
-     * The two exist separately because the useful instant and the knowable
-     * instant are not the same one. A critical-path calculation becomes garbage
-     * the moment the next mutation is admitted, but whether that mutation is
-     * substantive is only knowable once its ChangeSet exists, which is hundreds
-     * of milliseconds later at project scale. Measured live on a 12268-activity
-     * project: the cancellation flag flipped 929 ms into a 930 ms calculation,
-     * 812 into 812 and 785 into 785, because the job's apply block queues behind
-     * the very dispatch whose completion cancels it. Cancellation and job end
-     * were the same event, so every discarded job ran the whole calculation.
-     *
-     * Splitting the counter buys the early signal without moving the meaning of
-     * `_scheduleRevision`, whose three readers (`isCriticalPathSettled`,
-     * `createDateGesturePreview` and the job's own `isCurrent`) are all written
-     * against "the state actually changed".
-     */
     private _pendingScheduleRevision;
     private _criticalPathRevision;
     private _activeCriticalPath;
@@ -851,13 +773,6 @@ declare class ScheduleCore {
     getActivityView(id: ActivityId): Readonly<CoreActivity> | null;
     createDateGesturePreview(gesture: DateGesture): DateGesturePreview;
     getAllActivitiesView(): ReadonlyArray<Readonly<CoreActivity>>;
-    /**
-     * Read del plan de indent (ISSUE-080): los padres destino DISTINTOS bajo los
-     * que quedarían las actividades si se indentaran ahora. Es exactamente la
-     * planificación que ejecuta el handler (`planIndentMoves`, autoridad única),
-     * expuesta para que la frontera pueda correr el protocolo de conversión a
-     * madre (chequeo backend + modal) ANTES de despachar. Solo lecturas.
-     */
     getIndentTargetParentIds(activityIds: ReadonlyArray<ActivityId | string>): readonly string[];
     getChildrenView(parentId: ActivityId | '0'): ReadonlyArray<Readonly<CoreActivity>>;
     getLinkView(id: LinkId): Readonly<Link> | null;
@@ -884,53 +799,14 @@ declare class ScheduleCore {
     getModifiedActivities(): ReadonlyArray<Readonly<CoreActivity>>;
     getNewActivities(): ReadonlyArray<Readonly<CoreActivity>>;
     hasUnsavedChanges(): boolean;
-    /** Read-only revision; moves once per substantive mutation. */
     getScheduleRevision(): number;
     getCanonicalDigest(): string;
     createProjectionChangeSetFrom(source: ScheduleCore): ChangeSet;
     getDeletedActivitiesSinceLastSave(): ReadonlyArray<Readonly<DeletedActivitySnapshot>>;
     getDeletedLinksSinceLastSave(): ReadonlyArray<Readonly<DeletedLinkSnapshot>>;
     private _enqueue;
-    /**
-     * Marks a mutation as admitted and invalidates the calculation in flight.
-     *
-     * Called BEFORE `_enqueue`, which is the point of the whole thing: the wait
-     * in the operation queue is part of the window a running calculation wastes,
-     * and it is the longest part of it when several mutations are already
-     * queued.
-     *
-     * `dispatchChangesSchedulingState` is a pure function of the action, so this
-     * decision needs no state and cannot be wrong about the action's nature. What
-     * it cannot know yet is whether the mutation will produce anything, which is
-     * what `_settleScheduleMutation` reconciles afterwards.
-     */
     private _beginScheduleMutation;
-    /** Undo and redo have no action to classify: reaching them IS the mutation. */
     private _admitScheduleMutation;
-    /**
-     * Closes a mutation admitted by `_beginScheduleMutation`, on EVERY exit path.
-     *
-     * `changedState` false means the mutation was admitted and produced nothing
-     * (rejected, non-substantive, or rolled back). The pending revision walks
-     * back so the invariant holds and `isCriticalPathSettled` keeps telling the
-     * truth, and the calculation this mutation killed for nothing is re-armed.
-     *
-     * The re-arm goes through the queue and that is not incidental. Started
-     * outside it, the calculation would run immediately while the next queued
-     * mutation is still waiting, and that mutation would kill it again on
-     * admission: a cancel-and-restart treadmill burning a fresh project-wide deep
-     * copy per lap. Inside the queue the restart cannot happen until the queue
-     * drains, so at most one calculation is armed per settled mutation. The burst
-     * scenario will NOT catch a regression here, because there every dispatch
-     * succeeds and this path is never taken.
-     *
-     * It re-arms through `recomputeCriticalPath` rather than enqueueing the job
-     * directly, because the queue slot must NOT await the job: the job's own
-     * apply block needs a later slot on this same queue, so awaiting it from
-     * inside a slot deadlocks the core. `recomputeCriticalPath` already has the
-     * shape that returns the job's promise out of the slot instead of awaiting
-     * it, and it keeps `_criticalPathReady` pointing at the live calculation.
-     */
     private _settleScheduleMutation;
     dispatch(action: DispatchAction, options?: DispatchOptions): Promise<DispatchResult>;
     applyActivityBatch(action: ActivityBatchAction, options?: DispatchOptions): Promise<DispatchResult>;
@@ -942,51 +818,8 @@ declare class ScheduleCore {
     isCriticalPathSettled(): boolean;
     whenCriticalPathSettled(): Promise<void>;
     private _withReappliedViewState;
-    private _recordRelativePlacementPin;
-    /**
-     * The single place the two view-state passes are chained. Dispatch, undo and
-     * redo all route through here: when this existed only inside the dispatch
-     * path, undo and redo reapplied the filter and forgot the order, so an edit
-     * that moved a row and was then undone left the row in its new position.
-     *
-     * The sequence between the passes is indifferent. Filter and order are
-     * orthogonal projections over the same tree — the filter decides which rows
-     * exist on screen and never reads the order; the order sequences every
-     * sibling group from the hierarchy index and never reads visibility. Either
-     * sequence produces the same ChangeSet.
-     *
-     * Both passes answer null while their state is inactive, so an unfiltered,
-     * unsorted schedule pays two property reads.
-     */
     private _reapplyViewState;
-    /**
-     * Emits `order` for the branches this mutation resequenced, when no user order
-     * is active.
-     *
-     * The contract is that `order` reports a CHANGED SEQUENCE, not the presence of
-     * a sort. Tying emission to the cause instead of the effect is what produced
-     * the undo bug and, later, the reparent ones: without an active order a move,
-     * an indent, an outdent or the undo of any of them rearranged rows and said
-     * nothing, so an incremental consumer kept the old sequence. The undo of a
-     * reparent was the worst of them — it carried neither `order` nor a single
-     * correlativeId, so the position was not recoverable by any consumer.
-     *
-     * The touched branches are derived from the ChangeSet rather than accumulated
-     * in the state: an entity whose parentId or correlativeId moved, plus the
-     * parents of created and deleted rows, is exactly the set of branches whose
-     * sequence can differ. That keeps this linear in the blast radius, adds
-     * nothing to the write path, and cannot leak across dispatches.
-     */
     private _emitTouchedBranchOrder;
-    /**
-     * Re-sequences the grid after any mutation that could have changed a value the
-     * active order sorts by. Ordering is a view over the data, so an edit that
-     * moves a row past its sibling must move the row, exactly as the filter makes
-     * a no-longer-matching row disappear.
-     *
-     * Production only re-sorts after a bar drag; diverging from that is a
-     * deliberate product decision, not an oversight.
-     */
     private _reapplyActiveOrder;
     private _reapplyActiveFilter;
     private _recordScheduleMutation;