@outbuild-company/schedule-core 1.2.0 → 1.4.0

package/dist/index.d.cts

@@ -1,95 +1,9 @@
-/**
- * Shared types for the custom AutoScheduler and its satellite packages
- * (recording, replay, shadow, discovery).
- *
- * This file is the single seam between all components.  All scheduler code
- * depends ONLY on these types — never on the DHTMLX gantt object directly.
- */
-type ActivityId$1 = string;
-type LinkId$1 = string;
-/** Value constants for link types.  Matches `gantt.config.links`. */
 declare const LINK_TYPE: {
     readonly FINISH_TO_START: "0";
     readonly START_TO_START: "1";
     readonly FINISH_TO_FINISH: "2";
     readonly START_TO_FINISH: "3";
 };
-interface LinkSnapshot {
-    id: LinkId$1;
-    source: ActivityId$1;
-    target: ActivityId$1;
-    type: LinkType;
-    lag: number;
-    /**
-     * Precomputed lag components for a VIRTUAL summary-expanded link. When
-     * present, the link calculator uses them verbatim instead of deriving the
-     * components from leaf durations (the normal `normalize` switch).
-     *
-     * These exist so an FF/SF link INTO a summary can carry the SUMMARY's
-     * duration (`_targetLag = -summary.duration`) and the per-leaf offset from
-     * the summary's start (`_trueLag = userLag + off_tgt(leaf)`), matching legacy
-     * `_getImplicitLinks`/`_convertToFinishToStartLink` under
-     * `auto_scheduling_move_projects`. `_targetLag`/`_trueLag` are computed once
-     * at expansion time, matching legacy relations frozen per run, and the
-     * per-leaf offset in `_trueLag` applies only to leaves with no incoming
-     * links (legacy `!c.$target.length` — a leaf with its own driver keeps
-     * offset 0, otherwise the frozen offset compounds on every settle).
-     * `_sourceLag` is the expansion-time fallback: when `_summarySourceId` is
-     * present (SS/SF out of a summary), the ASAP calculator re-derives it at
-     * evaluation time from the summary's CURRENT derived bounds so the virtual
-     * constraint stays anchored at the summary start even after the anchor leaf
-     * moves within the same run.
-     *
-     * `_summaryTargetId` marks a virtual link whose `_trueLag` bakes a NON-ZERO
-     * leaf offset measured from the target summary's expansion-time bounds: the
-     * ASAP pass refuses to pull the leaf back through such a link unless the
-     * predecessor itself moved in the run (a stale frozen offset must never
-     * drag its own leaf earlier — that is the summary-link drift bug).
-     *
-     * The three lag components must be set together (or none): a half-populated
-     * link would mix precomputed and derived components. Every non-virtual link
-     * leaves them undefined and hits the fast path.
-     */
-    _sourceLag?: number;
-    _targetLag?: number;
-    _trueLag?: number;
-    _summarySourceId?: ActivityId$1;
-    _summaryTargetId?: ActivityId$1;
-    ganttId?: number;
-    sectorId?: number;
-    /** BE row id (distinct from the schedule-level `id`). */
-    proplannerId?: number;
-}
-
-/**
- * Constraint Rules — single source of truth.
- *
- * This module owns the definition of constraint types and the rules that
- * govern them. Both the autoscheduler and the manual scheduling pipelines
- * (column edits, drag, bulk) consume the same primitives from here.
- *
- * Two surfaces:
- *
- *   (a) Manual scheduling — pipelines call `checkConstraintViolation()` after
- *       a user types a new value, to decide whether to emit a warning.
- *       Surface: scalar Date inputs, no adapter needed.
- *
- *   (b) Autoscheduler — `computeConstraintBounds()` derives the four date
- *       boundaries (earliest/latest × start/end) an activity's constraint
- *       imposes. `isStartWithinBounds()` and `isEndWithinBounds()` are used
- *       by `limitPlanDates()` to decide whether a candidate date (from a
- *       link) respects the constraint.
- *
- * Domain invariant the autoscheduler must respect:
- *   The autoscheduler never moves an activity to a date that violates that
- *   activity's own constraint. If a cascade via a link would push the
- *   activity outside its constraint bounds, the activity stays put.
- *
- * Manual scheduling does NOT enforce this — a user is allowed to type a
- * value that violates their own constraint. The pipeline applies the edit
- * and emits a warning; the UI decides what to do with the warning (typically
- * shows a "constraint violation detected" modal and offers to revert).
- */
 
 type ConstraintType = 'asap' | 'alap' | 'snet' | 'snlt' | 'fnet' | 'fnlt' | 'mso' | 'mfo';
 declare const CONSTRAINT_TYPE: {
@@ -103,104 +17,44 @@ declare const CONSTRAINT_TYPE: {
     readonly MFO: "mfo";
 };
 
-/**
- * Public internal model types — the normalized form the core works with
- * after parsing the backend payload.
- *
- * Field naming follows snake_case for entity fields (matches backend +
- * DHTMLX convention) and camelCase for everything else, per Q14 in
- * SCHEDULE_CORE_API.md.
- */
 type ActivityId = string;
 type LinkId = string;
 type CalendarId = string;
 type ActivityType = 'project' | 'task' | 'milestone';
 
-/** DHTMLX link kinds: 0 = FS, 1 = SS, 2 = FF, 3 = SF. */
 type LinkType = '0' | '1' | '2' | '3';
-/** Direction for closest-work-time snapping. */
 type WorkTimeDirection = 'future' | 'past';
 declare const WORK_TIME_DIRECTION: {
     readonly FUTURE: "future";
     readonly PAST: "past";
 };
-/** Calendar query granularity (the engine boundary adds 'minute'/'any'). */
 type CalendarUnit = 'hour' | 'day';
 declare const CALENDAR_UNIT: {
     readonly HOUR: "hour";
     readonly DAY: "day";
 };
-/**
- * Project-level criterion used to redistribute `ponderator` (weight) among
- * sibling activities. Backend stores it lowercase on `projects.activity_creter`
- * (`'duration' | 'cost' | 'hh'`, default `'duration'`); the core normalizes
- * to uppercase. See `getActiveBaseline` / `recomputePonderatorsForParent`.
- */
 type ActivityCreter = 'DURATION' | 'COST' | 'HH';
-/** Criterion for the `status` column: compare progress against baseline or live expected. */
 type StatusCriteria = 'Baseline' | 'Actual';
-/**
- * A versioned container of baseline points for a sector
- * (backend `sectorbaselineversion` model). Exactly one version per sector
- * has `active: true` — that is the one the ponderator computation and the
- * baseline columns read.
- */
 interface BaselineVersion {
     id?: number;
     name?: string | null;
-    /** Marks the live baseline. Exactly one active version per sector. */
     active?: boolean;
     visible?: boolean;
-    /** Backend extras passed through opaquely. */
     [key: string]: unknown;
 }
-/**
- * A single baseline data point for an activity, as stored by the backend
- * (`sectorbaselinepoint` model) and carried verbatim through the core.
- * Snapshots the activity's planned start/end/duration/cost/work at the
- * moment a baseline version was saved. The schedule reads the ACTIVE point
- * (see `getActiveBaseline`) to derive `ponderator` (baseline-only, no
- * fallback — see memory `project_ponderator_baseline_fix`).
- *
- * Casing note: the frontend baseline columns (`startBaseCol` …
- * `durationBaseCol`) read these fields directly off the activity, so the
- * core preserves the backend snake_case exactly (passthrough, not parsed).
- *
- * Unit trap: `duration` is in DAYS (backend unit), unlike the activity's
- * `duration` which the core models in working hours — convert with the
- * sector's hours-per-day before arithmetic (legacy `transformDaysToHours`).
- */
 interface BaselinePoint {
-    /** Planned start, backend date string `"YYYY/MM/DD H:MM"` or ISO. */
     start_date: string;
-    /** Planned end (inclusive). */
     end_date: string;
-    /** Planned duration in DAYS (backend unit). */
     duration: number;
-    /** Planned cost. May arrive as a numeric string. */
     cost: number | string;
-    /** Planned work hours (HH). May arrive as a numeric string. */
     hh_work: number | string;
-    /** The version this point belongs to; `.active` selects the live one. */
     sectorbaselineversion?: BaselineVersion;
     sectorbaselineversionId?: number;
     baseCalendarId?: number;
     hoursPerDay?: number;
     hoursPerWeek?: number;
-    /** Backend extras passed through opaquely. */
     [key: string]: unknown;
 }
-/**
- * Pure-domain activity model produced by `parseFromBackend`. Snake_case
- * matches the backend convention. No index signature — every field is
- * explicit. New backend fields must be added here and preserved by
- * `normalize-activity.ts`.
- */
-/**
- * A pending SIR freezing an activity, reduced to the only field the core
- * needs: its id (equal to the backend SIR id and the front's Redux item id).
- * The schedule load already filters to pending, so presence ⇒ pending.
- */
 interface PendingRequest {
     id: string;
 }
@@ -234,7 +88,6 @@ interface CoreBaselinePoint {
     workHours: number;
     versionId: number | null;
     isActiveVersion: boolean;
-    /** Whether this version is the one selected for visual comparison. */
     isVisibleVersion: boolean;
     baseCalendarId: CalendarId | null;
     hoursPerDay: number | null;
@@ -294,79 +147,25 @@ interface Link {
     lag: number;
     ganttId?: number;
     sectorId?: number;
-    /** BE row id (distinct from the schedule-level `id`/`unique_id`). */
     proplannerId?: number;
 }
 interface CalendarWorktime {
-    /**
-     * Per-weekday working hours, length 7 — index 0 = Sunday.
-     *
-     *   - `false`     → non-working day
-     *   - `string[]`  → working day with these `"HH:MM-HH:MM"` windows
-     *                   (supports per-day variation, e.g. a short Friday,
-     *                    and multi-shift split days like `["8-12","13-17"]`)
-     *
-     * Single source of truth: this is exactly what `parseFromBackend` emits. A
-     * usable working day carries its resolved windows; `[]` is reserved for a
-     * catalog calendar that declares the day as working but provides no usable
-     * shift anywhere. Those catalog-only calendars remain selectable/persistable
-     * but are deliberately not registered as arithmetic calendars. The vendored
-     * work-calendar engine natively also accepts a boolean `true` per day (DHTMLX
-     * contract), but that form never appears in the domain `Calendar`; it is
-     * reserved for the engine-facing internals (`SnapshotWorktime`,
-     * synthetic replay fixtures).
-     *
-     * The work-calendar engine consumes each weekday independently, so
-     * different days can carry different windows.
-     */
     days: Array<false | string[]>;
-    /**
-     * Default working-hour windows (`"HH:MM-HH:MM"`). Used as the engine's
-     * global fallback. `parseFromBackend` sets it to the first usable working
-     * day's windows, or `[]` when the calendar has no usable shift.
-     */
     hours: string[];
-    /**
-     * Per-date exceptions: holidays (non-working) and date-level shift
-     * overrides. Keys are `Date.UTC(year, month, day)` (UTC midnight epoch
-     * ms) stringified — this matches the lookup the work-calendar engine
-     * performs internally at `calendar.dates[dateValue]`.
-     *
-     * Value semantics:
-     *   - `false`              → the day is non-working
-     *   - `string[]`           → use these `"HH:MM-HH:MM"` windows instead
-     *                            of the default `hours`
-     *
-     * Source: `BackendCalendarInput.exceptiondays[]` after the adapter expands
-     * `from_date`/`to_date` ranges into individual UTC days.
-     */
     dates?: Record<string, false | string[]>;
-    /** Optional per-week overrides for advanced calendars. */
     customWeeks?: Record<string, unknown>;
 }
 interface Calendar {
     id: CalendarId;
-    /** Display name. Used by the DHTMLX calendar-selector column. */
     name: string;
     worktime: CalendarWorktime;
     is_default: boolean;
-    /**
-     * True for "base" calendars (baseline comparison). The backend ships
-     * these with an `id` suffixed `-base` and `baseDefault` instead of
-     * `is_default`. The bridge uses this to set `gantt.defaultBaseCalendar`
-     * and to keep base calendars out of the selector dropdown.
-     */
     baseDefault?: boolean;
-    /**
-     * Date-keyed map of exceptions (holidays, working overrides).
-     * Keys are `YYYY-MM-DD` UTC.
-     */
     exceptions?: Record<string, {
         working: boolean;
         hours?: string[];
     }>;
 }
-/** Sector metadata the core respects from the backend. */
 interface SectorMetadata {
     id: string;
     name: string;
@@ -375,48 +174,12 @@ interface SectorMetadata {
     dateFormat: string;
     projectId: number;
     companyId: number;
-    /**
-     * Project's `custom_id_prefix` (Outbuild project setting). Used by the
-     * CustomIdTracker to generate ids for new activities. Falls back to
-     * `'A'` if not provided.
-     */
     customIdPrefix?: string;
-    /**
-     * Project's `custom_id_increment` (Outbuild project setting), as a
-     * string so leading zeros are preserved. Used by the CustomIdTracker
-     * to choose the next suffix step. Falls back to `'10'` if not provided.
-     */
     customIdIncrement?: string;
-    /**
-     * Legacy Primavera-import flag. When true, the core recomputes each
-     * activity's `duration` from its start/end against its calendar at load
-     * (Primavera stores end-driven durations that may not match the
-     * calendar). Mirrors the legacy `fixPrimaveraDurations`. See CALENDARS.md.
-     */
     updateDurationForPrimaveraEndDate?: boolean;
-    /**
-     * Project's `activity_creter` — criterion for ponderator redistribution
-     * (`'DURATION' | 'COST' | 'HH'`). Lives at the project level; arrives via
-     * the sector payload's pass-through bucket. `parseSector` always sets it,
-     * defaulting to `'DURATION'` (the backend default) when absent/unknown.
-     */
     activityCreter?: ActivityCreter;
-    /**
-     * Project's status criterion for the `status` column — `'Baseline'` compares
-     * `progress` against `expected_progress_base`, `'Actual'` against
-     * `expected_progress`. Mutable at runtime via `ScheduleCore.setStatusCriteria`
-     * (the Baseline↔Actual toggle). Not a backend field (client-only session
-     * setting); a complete sector always carries it — `parseSector` sets the
-     * default and `resolveStatusCriteria` normalizes the client override at init.
-     * See `docs/domain/columns/COLUMN_status.md`.
-     */
     statusCriteria: StatusCriteria;
 }
-/**
- * A single entity mutation record emitted by a dispatch ChangeSet.
- * Layer-neutral: contains no dispatch-specific dependencies and is used
- * both by `dispatch/` and by `internal/tracking/`.
- */
 interface EntityChange<T> {
     id: string;
     kind: 'created' | 'updated' | 'deleted';
@@ -470,45 +233,61 @@ declare const COLUMN: {
 };
 type ColumnName = (typeof COLUMN)[keyof typeof COLUMN];
 
-/**
- * Task creation pipeline — types.
- *
- * Ports the pure parts of `src/assets/js/custom_actions/createTask/` into a
- * functional pipeline that replay tests (and eventually prod) can invoke
- * against an adapter instead of the live gantt.
- */
-
-/**
- * Closed, canonical contract for create/paste overrides: camelCase, working
- * hours, limited to the fields a caller may seed on a new activity. Identity
- * and structure (`id`/`parentId`/`correlativeId`/`uniqueCorrelativeId`),
- * derived/CP/baseline outputs and view-state are NOT overridable. PP2 adapts
- * its own vocabulary to this contract in step 9.
- */
 declare const CREATION_OVERRIDE_FIELD_LIST: readonly ["name", "description", "type", "startDate", "durationHours", "constraintType", "constraintDate", "calendarId", "assignedDefaultCalendar", "autoScheduling", "progress", "cost", "usedCost", "realCost", "workHours", "realWorkHours", "ponderator", "hasCustomPonderator", "customId", "subcontractId", "responsableIds", "tagIds", "isLookahead"];
 type CreationOverrideField = (typeof CREATION_OVERRIDE_FIELD_LIST)[number];
 type CreationOverrides = Partial<Pick<CoreActivity, CreationOverrideField>>;
 
+type StringOperator = 'includes' | 'notIncludes' | 'is' | 'isNot';
+type NumberOperator = 'equals' | 'notEquals' | 'greaterThan' | 'lessThan' | 'greaterOrEqual' | 'lessOrEqual';
+type DateOperator = 'after' | 'before';
+type MembershipOperator = 'someOf' | 'notSomeOf';
+type FilterOperator = StringOperator | NumberOperator | DateOperator | MembershipOperator;
+type FilterField = 'name' | 'description' | 'customId' | 'correlativeId' | 'uniqueCorrelativeId' | 'progress' | 'durationDays' | 'calendarDuration' | 'cost' | 'usedCost' | 'realCost' | 'workHours' | 'realWorkHours' | 'ponderator' | 'freeSlackDays' | 'totalSlackDays' | 'expectedProgressBaseline' | 'baselineDurationDays' | 'baselineCost' | 'baselineWorkHours' | 'startDate' | 'endDate' | 'constraintDate' | 'baselineStartDate' | 'baselineEndDate' | 'earlyStart' | 'earlyFinish' | 'lateStart' | 'lateFinish' | 'responsableIds' | 'tagIds' | 'status' | 'constraintType' | 'calendarId' | 'subcontractId' | 'isCritical';
+type FilterScalarValue = string | number | Date;
+type FilterCriterionValue = FilterScalarValue | ReadonlyArray<string | number>;
+interface FilterCriterion {
+    readonly field: FilterField;
+    readonly operator: FilterOperator;
+    readonly value: FilterCriterionValue;
+}
+interface FilterDateRange {
+    readonly start: Date;
+    readonly end: Date;
+}
+interface FilterState {
+    readonly criteria: ReadonlyArray<FilterCriterion>;
+    readonly logic: 'and' | 'or';
+    readonly dateRange?: FilterDateRange;
+}
+
+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>;
+}
 /**
- * Public dispatch types — see Q8/Q9/Q10 in SCHEDULE_CORE_API.md.
- *
- * Supported kinds:
- *   - `inline-edit`        — edit a single column on an activity.
- *   - `link-create`        — add a link between two activities.
- *   - `link-update`        — change the lag and/or type of an existing link.
- *   - `link-delete`        — remove a link by id.
- *   - `activity-create`    — create a new activity (root, child, or sibling).
- *   - `activity-delete`    — cascade-delete activities + incident links.
- *   - `activity-move`      — reorder among siblings or move to a different parent.
- *   - `activity-indent`    — multi-select indent (children of previous non-selected sibling).
- *   - `activity-outdent`   — multi-select outdent (move to grandparent level).
- *   - `activity-set-progress` — complete/uncomplete (0/100) with cascade.
- *   - `selection-toggle` / `selection-replace` — checkbox selection (prop-only).
- *   - `activity-paste`     — bulk paste (N activities + M links, one atomic ChangeSet).
- *   - `dates-batch`        — K date edits as one unit of work (multi-drag).
- *   - `bulk-edit`          — K edits on any pipeline column as one unit of work (bulk editors).
- *   - `links-batch`        — K link create/update/delete as one atomic unit (mass link/unlink buttons).
+ * 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>;
+}
+
 type LinksBatchOperation = {
     kind: 'create';
     source: ActivityId;
@@ -549,13 +328,6 @@ type DispatchAction = {
     column: string;
     newValue: unknown;
 } | {
-    /**
-     * K ediciones de fecha como UNA unidad de trabajo (multi-drag): cada
-     * edit corre su pipeline individual (verdict por barra), pero el
-     * post-mutation (autoscheduler → bounds → CP) corre UNA sola vez y
-     * sale UN ChangeSet. Patrón hermano de `activity-paste` /
-     * `dispatchInlineEditLinks`. Track onAfterTaskDrag F2.2.
-     */
     kind: 'dates-batch';
     edits: ReadonlyArray<{
         activityId: ActivityId;
@@ -563,21 +335,6 @@ type DispatchAction = {
         newValue: unknown;
     }>;
 } | {
-    /**
-     * K edits on ANY pipeline column as ONE unit of work — the
-     * generalization of `dates-batch` to the 16 registry columns
-     * (schedule bulk editors / modals; PLAN_convergencia_wiring §4.1).
-     * Each edit resolves its pipeline via `findPipelineForColumn` and
-     * runs phases 1-4 with an individual verdict (a rejected edit does
-     * NOT abort the others — paste semantics). A column without a
-     * pipeline (e.g. the link columns `custom_predecessors` /
-     * `custom_sucessors`, which mutate the link graph and dispatch as
-     * link intents) rejects ONLY that edit. The post-mutation pass
-     * (autoscheduler → parent bounds → CP) runs ONCE at the end and a
-     * single ChangeSet comes out = ONE undo step (never coalesces).
-     * Supports both shapes: K activities × same column, and 1 activity
-     * × several columns (atomic multi-field edit).
-     */
     kind: 'bulk-edit';
     edits: ReadonlyArray<{
         activityId: ActivityId;
@@ -590,16 +347,12 @@ type DispatchAction = {
     source: ActivityId;
     target: ActivityId;
     type: LinkType;
-    /** Lag in DAYS (public boundary unit; converted to working hours inside). */
     lag: number;
-    /** Optional explicit id (tests pass deterministic ids). */
     linkId?: LinkId;
 } | {
     kind: 'link-update';
     linkId: LinkId;
-    /** New type. Omit to preserve. */
     type?: LinkType;
-    /** New lag in DAYS (public boundary unit). Omit to preserve. */
     lag?: number;
 } | {
     kind: 'link-delete';
@@ -609,254 +362,88 @@ type DispatchAction = {
     operations: ReadonlyArray<LinksBatchOperation>;
 } | {
     kind: 'activity-create';
-    /** Where to put the new activity. Use `'0'` for root. */
     parentId: ActivityId | '0';
-    /**
-     * Optional — insert the new activity immediately AFTER this sibling.
-     * If omitted (and `beforeSiblingId` also omitted), the new activity
-     * is appended as the last child of `parentId`. The sibling must
-     * currently be a child of `parentId`, otherwise the dispatch is
-     * rejected. Mutually exclusive with `beforeSiblingId`.
-     */
     afterSiblingId?: ActivityId | undefined;
-    /**
-     * Optional — insert the new activity immediately BEFORE this sibling.
-     * Use case: "insert as first child" (`beforeSiblingId = currentFirstChild`)
-     * or "insert at position N" (`beforeSiblingId = children[N]`).
-     * The sibling must currently be a child of `parentId`, otherwise the
-     * dispatch is rejected. Mutually exclusive with `afterSiblingId`.
-     */
     beforeSiblingId?: ActivityId | undefined;
-    /**
-     * Canonical field overrides applied on top of the creation defaults —
-     * camelCase, working hours, limited to creation-writable fields
-     * (`CreationOverrides`). Identity/structure and derived outputs are not
-     * overridable.
-     */
     overrides?: CreationOverrides;
-    /**
-     * Deterministic activity id — used by tests and by replay flows
-     * (paste, undo) that need to assign a specific id. If omitted, the
-     * core's internal id generator allocates one.
-     */
     activityId?: ActivityId;
-    /**
-     * Where this create originated from — passed through to the
-     * `schedule_activity_creation` Amplitude event. Free-form string
-     * (matches legacy `INSERT_EVENT_SOURCES`).
-     */
     eventSource?: string | undefined;
 } | {
     kind: 'activity-delete';
-    /**
-     * IDs to delete. Each id triggers a cascade delete of its entire
-     * subtree. Links incident to any deleted activity are removed too.
-     * Operation is atomic — if any id is missing, the whole dispatch is
-     * rejected before mutating anything.
-     */
     activityIds: ReadonlyArray<ActivityId>;
     eventSource?: string;
 } | {
     kind: 'activity-move';
-    /**
-     * The activity to move. Single-id only — for batch reorder use
-     * multiple dispatches (each one observes the post-previous state).
-     */
     activityId: ActivityId;
-    /** Destination parent. Same as current parent = reorder within. */
     parentId: ActivityId | '0';
-    /**
-     * Optional — position the moved activity immediately below this
-     * sibling. If omitted, appended as the last child of `parentId`.
-     * The sibling must currently be a child of `parentId`; otherwise
-     * the dispatch is rejected. Mutually exclusive with `beforeSiblingId`.
-     */
     afterSiblingId?: ActivityId;
     beforeSiblingId?: ActivityId;
     eventSource?: string;
 } | {
     kind: 'activity-indent';
-    /**
-     * IDs to indent. Multi-select honors chain semantics: each id is
-     * moved under its closest previous sibling that is NOT in the
-     * selected set, so consecutive selected siblings all land under the
-     * same anchor (matches legacy `findPreviousNonSelectedSibling`).
-     */
     activityIds: ReadonlyArray<ActivityId>;
     eventSource?: string;
 } | {
     kind: 'activity-outdent';
-    /**
-     * IDs to outdent. Multi-select preserves relative order among the
-     * selected siblings via initial-index capture (matches legacy
-     * `initialFirstSiblings` + `initialTaskIndexes` pre-loop setup).
-     */
     activityIds: ReadonlyArray<ActivityId>;
     eventSource?: string;
 } | {
-    /**
-     * Set progress to 0 or 100 with recursive cascade semantics.
-     *
-     * Triggered by the schedule's "complete" / "uncomplete" buttons.
-     * **Distinct intent from `inline-edit`** — bypasses the
-     * `isSummaryActivity` gate of `progressPipeline.canEdit` because
-     * the user is explicitly invoking the recursive operation
-     * ("complete this parent and all its descendants"), not editing
-     * a single cell.
-     *
-     * Inline edits on the progress column still use `inline-edit` with
-     * full `canEdit`/`validate` gating (which blocks summary activities
-     * by design). See [[complete activity business rules]] R8 and the
-     * bifurcation rationale.
-     *
-     * Internally reuses the `progressPipeline.transform` so cascade,
-     * rollup, tracking and visualization are identical to inline-edit
-     * with newValue=0 or newValue=100.
-     */
     kind: 'activity-set-progress';
     activityId: ActivityId;
-    /** Strictly 0 (uncomplete) or 100 (complete). */
     newValue: 0 | 100;
     eventSource?: string;
 } | {
-    /**
-     * Checkbox selection toggle (2026-06-06). The core is the
-     * authority of the check state (`checked` / `visibleChecked` /
-     * `mustApplyVisibleChecked` written as a single bit): it runs the
-     * full propagation (descendants cascade, frozen partition with
-     * parent blocking, unified upward pass — see
-     * `internal/selection/compute-selection-update.ts`) and emits a
-     * prop-only ChangeSet the bridge applies in bulk to DHTMLX
-     * (silent store write + viewport repaint). No autoscheduler, no
-     * critical path.
-     */
     kind: 'selection-toggle';
     activityId: ActivityId;
-    /** Checkbox state AFTER the user click. */
     isChecked: boolean;
-    /**
-     * Ids frozen by pending SIRs, computed by the caller from the
-     * runtime (DHTMLX task props — the core's own `pendingRequests`
-     * is load-time-stale until TODO #10). When omitted, the core
-     * falls back to its own snapshots.
-     */
     frozenIds?: ReadonlyArray<ActivityId>;
-    /**
-     * Enable the upward auto-check of ancestors when all their
-     * checkable children become selected. Mirrors the (inverted)
-     * CHECKBOX_NOT_AUTOMATIC_PARENT_SELECTION flag. Default: false.
-     */
     autoCheckParents?: boolean;
     eventSource?: string;
 } | {
-    /**
-     * Replace the whole selection with an exact id set — no
-     * propagation. Used by clear / block-selection / external sync.
-     * Unknown ids are ignored. Same prop-only ChangeSet contract as
-     * `selection-toggle`.
-     */
     kind: 'selection-replace';
     activityIds: ReadonlyArray<ActivityId>;
     eventSource?: string;
 } | {
-    /**
-     * View-model visibility set (Fase 1, 2026-07-04). ABSOLUTE set: the
-     * UI sends the COMPLETE list of ids visible after its filters run;
-     * the core diffs against the current `visible` bits (an id changes
-     * when `(visible !== false) !== willBeVisible`) and emits a
-     * prop-only ChangeSet carrying ONLY the `visible` field for the
-     * activities that changed. Unknown ids are ignored. Same prop-only
-     * contract as `selection-replace`: no autoscheduler, no critical
-     * path, no undo step. Idempotent.
-     */
     kind: 'visibility-set';
     visibleIds: ReadonlyArray<ActivityId>;
     eventSource?: string;
 } | {
-    /**
-     * Sync the pending-SIR set for one activity into the core
-     * (2026-06-08). ABSOLUTE set: the bridge sends the activity's current
-     * pending requests whenever a SIR is created/resolved in the front,
-     * so the core's freeze bit stays fresh (closes TODO #10) and is the
-     * standalone authority for selection gating + auto-reject. Prop-only
-     * ChangeSet; no autoscheduler, no CP. Idempotent.
-     */
+    kind: 'filter-set';
+    criteria: ReadonlyArray<FilterCriterion>;
+    logic: 'and' | 'or';
+    dateRange?: FilterDateRange;
+    eventSource?: string;
+} | {
+    kind: 'sort-set';
+    rules: ReadonlyArray<OrderRule>;
+    eventSource?: string;
+} | {
     kind: 'sir-sync';
     activityId: ActivityId;
     pendingRequests: ReadonlyArray<PendingRequest>;
     eventSource?: string;
 } | {
-    /**
-     * Synchronize the schedule-side flags owned by Lookahead task
-     * creation/deletion. The Lookahead records remain at the application
-     * boundary; the core owns these flags because they affect schedule
-     * editing rules and the public activity view.
-     */
     kind: 'activity-lookahead-sync';
     activityIds: ReadonlyArray<ActivityId>;
     isLookahead: boolean;
     hasLookaheadTasks: boolean;
     eventSource?: string;
 } | {
-    /**
-     * Bulk paste (2026-06-08). Creates N activities (preserving the
-     * copied subtree hierarchy) plus M internal links in a SINGLE
-     * atomic ChangeSet — the future unit of undo. Replaces the
-     * DHTMLX-side paste that bypassed the core via `gantt.isPasting`.
-     *
-     * The caller (bridge) supplies, per activity, the field
-     * `overrides` already shaped by the paste prepare step (resets +
-     * validated catalogs). The core allocates ids/uids, re-hangs the
-     * hierarchy via `originalId → newId`, promotes parents, runs the
-     * hh/cost cascade + correlative sweep + autoscheduler ONCE at the
-     * end of the batch (not per activity).
-     *
-     * See [[COPY_PASTE_CORE_MIGRATION_DESIGN]].
-     */
     kind: 'activity-paste';
-    /**
-     * Where the pasted roots land. `{ parentId, index }` pastes INSIDE
-     * the reference (index 0 = first child). `{ afterSiblingId }`
-     * pastes as a sibling immediately below the reference; the parent
-     * is derived from the sibling.
-     */
     destination: {
         parentId: ActivityId | '0';
         index: number;
     } | {
         afterSiblingId: ActivityId;
     };
-    /**
-     * The activity the paste is anchored to (the single selected row).
-     * Used as the custom_id reference for pasted children. Replaces
-     * the legacy `gantt.pasteReferenceActivity` instance flag.
-     */
     referenceActivityId: ActivityId;
-    /**
-     * Activities to create, in tree order (parents before children).
-     * `originalId` / `originalParentId` are the ids from the copied
-     * payload; the core remaps them to freshly allocated ids and uses
-     * the remap to re-hang the hierarchy and the links. A pasted activity
-     * may carry its visible baseline snapshot, but it is not enrolled in an
-     * already-created historical baseline.
-     */
     activities: ReadonlyArray<PastedActivityInput>;
-    /**
-     * Internal links to recreate. `source`/`target` reference the
-     * ORIGINAL (copied) ids; links with an endpoint outside the
-     * pasted set are dropped (dangling).
-     */
     links: ReadonlyArray<PastedLinkInput>;
     eventSource?: string;
 };
 interface PastedActivityInput {
     readonly originalId: ActivityId;
     readonly originalParentId: ActivityId | '0';
-    /**
-     * Optional explicit destination id. Production normally omits it and lets
-     * the adapter allocate; recorder replay supplies MAIN's observed id so the
-     * whole-tree oracle can compare identity without an invented id remap.
-     */
     readonly activityId?: ActivityId;
     readonly overrides: CreationOverrides;
     readonly baselineSnapshot?: ActivityBaselineSnapshot | null;
@@ -865,51 +452,20 @@ interface PastedLinkInput {
     readonly source: ActivityId;
     readonly target: ActivityId;
     readonly type: LinkType;
-    /** Lag in DAYS (public boundary unit; converted to working hours inside). */
     readonly lag: number;
     readonly linkId?: LinkId;
 }
 interface DispatchOptions {
-    /** Skip the autoscheduler pass after the mutation. Default: false. */
     skipAutoSchedule?: boolean;
-    /** Skip the CP recompute after the mutation. Default: false. */
     skipCriticalPath?: boolean;
-    /**
-     * Unit of the INPUT `newValue` for unit-bearing inline-edit columns (today:
-     * duration). Default 'days' (public contract; card + tests send days). The
-     * DHTMLX grid editor produces the store unit (HOURS via formatter.parse), so
-     * the bridge passes 'hours' for those edits → the pipeline skips the days→hours
-     * conversion instead of double-converting.
-     */
     inputUnit?: 'days' | 'hours';
 }
 type DispatchResult = {
     ok: true;
     changes: ChangeSet;
-    /**
-     * Solo los intents batch (`dates-batch` / `bulk-edit`): resultado
-     * POR EDIT, en el orden de `edits`. Un edit rechazado no aborta a
-     * los demás (semántica paste); el bridge re-proyecta solo los
-     * rechazados.
-     */
     verdicts?: ReadonlyArray<DatesBatchVerdict>;
     activityVerdicts?: ReadonlyArray<DatesBatchVerdict>;
     linkVerdicts?: ReadonlyArray<LinkBatchVerdict>;
-    /**
-     * INTERNAL (undo / B4). Full pre-mutation snapshot of every
-     * deleted/structurally-removed activity row, keyed by STRING id. The
-     * ChangeSet emits deleted rows as `{ kind:'deleted', after:null }` with no
-     * `before`, so resurrection on undo needs this. Populated by structural
-     * handlers (delete/move/paste); stripped before the result reaches the
-     * bridge in the Wave-3 integration.
-     */
-    __beforeSnap?: ReadonlyMap<string, CoreActivity>;
-    /**
-     * INTERNAL (undo / B4). Incident links of deleted activities, keyed by
-     * STRING id (EntityChange link ids are String()-normalized). Carries the
-     * engine `LinkSnapshot` (lag in working hours) for unit-correct re-add.
-     */
-    __beforeLinks?: ReadonlyMap<string, LinkSnapshot>;
 } | {
     ok: false;
     reason: string;
@@ -940,34 +496,17 @@ interface TrackingEvent {
     name: string;
     properties: Record<string, unknown>;
 }
-/**
- * Side effects a dispatch emits that are NOT entity-field changes and NOT
- * Amplitude tracking — commands the bridge must act on. Today: SIR
- * auto-reject (a frozen activity's dates changed or it was deleted, so its
- * pending SIR must be rejected). The core owns the rule; the bridge consumes
- * the effect (Redux REJECTED; durable persistence rides the activity save).
- * See `SIR_MAP.md` §10.
- */
 type ScheduleEffect = {
     kind: 'sir-auto-reject';
     activityId: ActivityId;
-    /** Backend SIR id == the front Redux item id (see parseFromBackend A1). */
     sirId: string;
     reason: 'date_changed' | 'activity_deleted';
 };
-/**
- * A direct user edit violated the activity's own (pre-edit) constraint. Per
- * the canonical model (PRD constraint violations, R2/R3): the edit APPLIES
- * anyway — the warning is data for the UI (constraint validation modal),
- * never a rejection, and it is only emitted from direct edits (the
- * autoscheduler never violates, R1). Decision D-A 2026-07-04.
- */
 interface ConstraintWarning {
     kind: 'constraint_violation';
     activityId: ActivityId;
     constraintType: ConstraintType;
     constraintDate: Date;
-    /** The projected date that violated (start or end, per constraint type). */
     projectedDate: Date;
     messageKey: string;
 }
@@ -994,22 +533,20 @@ interface ChangeSet {
     trackingEvents: ReadonlyArray<TrackingEvent>;
     viewState?: ReadonlyArray<ViewStateChange>;
     /**
-     * Optional — present only when the dispatch produced side effects. Builders
-     * that emit none omit it; consumers read `changeSet.effects ?? []`. Kept
-     * optional to avoid churning every ChangeSet construction site. SIR (A4).
+     * 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>;
-    /**
-     * Optional — present only when a direct edit violated a constraint (see
-     * `ConstraintWarning`). Consumers read `changeSet.warnings ?? []`.
-     */
     warnings?: ReadonlyArray<ConstraintWarning>;
 }
 
 interface ProjectWorkHours {
-    /** Earliest start of the working day across the week, `"HH:MM"`. */
     startHour: string;
-    /** Latest end of the working day across the week, `"HH:MM"`. */
     endHour: string;
 }
 
@@ -1118,102 +655,18 @@ interface BackendScheduleInput {
     baseCalendars?: BackendCalendarInput[] | undefined;
 }
 
-/**
- * Injected reporting port. The core is UI-agnostic: it cannot `console.*`,
- * show UI, or know about Sentry. When it hits a recoverable data-quality
- * issue (`warn`) or a failure it could not complete (`error`), it calls this
- * port; the consumer (react_client) implements it and decides the outcome
- * (Sentry, toast, nothing). Same injected-port pattern as `AutoSchedulerPort`.
- */
 interface ScheduleCoreReporter {
-    /** Recoverable data-quality issue; the core continues with its fallback. */
     warn(message: string, context?: unknown): void;
-    /** A real failure the core could not complete. */
     error(message: string, cause?: unknown): void;
 }
 
-/**
- * initialize-core — the construction + load-pass orchestration extracted from
- * the `ScheduleCore` constructor. `initializeCore(input)` performs the entire
- * load sequence (parse → snapshot → state → demote → id generators →
- * custom-id tracker → optional baseline block → initial passes) and returns
- * the assembled internals (`CoreInternals`) for the facade to assign. The
- * facade constructor is assignment-only.
- *
- * The load-pass ORDER here is a CONTRACT — see `CURSOR.md`
- * §"Flujo de core.dispatch paso a paso" and the inline comments below. Do not
- * reorder, merge, or drop any step.
- *
- * The public types (`ScheduleCoreStatus`, `ScheduleCoreInput`) live here so
- * `initialize-core.ts` never imports from `scheduleCore.ts` (which imports
- * `initializeCore`), avoiding an import cycle. `scheduleCore.ts` re-exports the
- * two public types
- * so `src/index.ts`'s existing `export type { ... } from './init/schedule-core.js'`
- * keeps resolving unchanged.
- */
-
 type ScheduleCoreStatus = 'ready' | 'destroyed' | 'poisoned';
 interface ScheduleCoreInput extends BackendScheduleInput {
-    /**
-     * Skip the full autoscheduler pass that normally runs from the
-     * constructor (`runInitialPasses`).
-     *
-     * Backend data already ships with `start_date` / `end_date` / `duration`
-     * scheduled — running the full ASAP+ALAP graph at load is redundant and
-     * extremely slow on large schedules (thousands of activities + links).
-     *
-     * When `true`, the constructor still runs the lightweight bottom-up
-     * post-processors (`updateParentBoundsFromChildren`) so parent bounds
-     * and progress rollup are consistent. The autoscheduler runs lazily on
-     * the first `dispatch(...)` call.
-     *
-     * Default: `false` (preserve existing behaviour). The bridge in
-     * `react_client/` sets this to `true` for production loads.
-     */
     skipInitialAutoSchedule?: boolean;
-    /**
-     * Baseline points (backend `sectorbaselinepoint[]`, the `activityponts`
-     * endpoint payload) to overlay at load. Each point maps to an activity by
-     * `point.activityId` → `activity.proplannerId`. When present, the constructor
-     * overlays them so the baseline columns + `expected_progress_base` can read the
-     * ACTIVE point. NB: ponderators are NOT recomputed at load (backend ships the
-     * value prod renders verbatim — recomputing diverges); `goCalculatePonderators`
-     * is a save-time op. Omit (or pass `[]`) for projects with no baseline.
-     */
     baselinePoints?: readonly BaselinePoint[];
-    /**
-     * Clock port for time-dependent columns (`expected_progress*`). A FUNCTION
-     * (not a frozen instant): the core calls it FRESH each time it needs "today"
-     * (load + every dispatch that recomputes expected_progress), so the value
-     * tracks the real day even on a long-lived session — never congelado.
-     *
-     * Opt-in (no default): omit it → the core does NOT compute `expected_progress`
-     * (preserves the legacy path; keeps the test suite deterministic). Production
-     * injects `() => new Date()`; tests inject `() => fixedDate` for reproducibility.
-     * The core never calls `new Date()` itself — this port is the only time source.
-     */
     clock?: () => Date;
-    /**
-     * Critical-path mode at LOAD. The CP is ALWAYS computed; this flag only
-     * decides WHEN `core.ready` is considered settled:
-     * - `false` (default — front): `core.ready` resolves WITHOUT the CP (fast
-     *   load); the CP runs async and is delivered via `core.criticalPathReady`.
-     * - `true` (backend, no front): `core.ready` WAITS for the CP — it is part of
-     *   the load (blocking). The caller does a single `await core.ready` and has
-     *   the dates + CP fields ready.
-     */
     criticalPathOnLoad?: boolean;
-    /**
-     * Initial status criterion (`'Baseline' | 'Actual'`) for the `status` column.
-     * Not a backend field (client-only view pref); the client passes the current
-     * value, defaulting to `'Baseline'`. Overrides the sector default when present.
-     * Changed at runtime via `ScheduleCore.setStatusCriteria`.
-     */
     statusCriteria?: StatusCriteria;
-    /**
-     * Optional injected port for data-quality warnings and scheduling errors.
-     * Defaults to a no-op when absent (the core never touches console/Sentry).
-     */
     reporter?: ScheduleCoreReporter;
 }
 
@@ -1242,13 +695,9 @@ declare class ScheduleCore {
     forEachActivityId(visit: (id: string) => void): void;
     getChildrenIds(parentId: ActivityId | '0'): ReadonlyArray<ActivityId>;
     getSelectedActivityIds(): string[];
-    /**
-     * Every activity id in canonical DFS visual order (pre-order from roots,
-     * siblings by `correlative_id` ASC) — ALL activities; filtering by
-     * `visible` is the consumer's job. Memoized in the state and invalidated
-     * on any structural mutation (add/remove/reparent/renumber), so repeated
-     * reads between mutations are O(1).
-     */
+    getHiddenActivityIds(): string[];
+    getActiveFilter(): Readonly<FilterState> | null;
+    getActiveOrder(): Readonly<OrderState> | null;
     getVisualOrderIds(): ReadonlyArray<ActivityId>;
     hasChild(parentId: ActivityId | '0'): boolean;
     getCalendar(id: CalendarId): Readonly<Calendar> | null;
@@ -1261,36 +710,66 @@ declare class ScheduleCore {
     private _enqueue;
     dispatch(action: DispatchAction, options?: DispatchOptions): Promise<DispatchResult>;
     private _dispatchInner;
-    /**
-     * Starts or joins the Critical Path calculation for the current schedule
-     * revision. Snapshot capture and the final commit are serialized with user
-     * mutations, but the expensive calculation runs outside `_opQueue` against
-     * an isolated state. A newer revision aborts this job and makes its result
-     * ineligible to commit.
-     */
     recomputeCriticalPath(): Promise<{
         changes: ChangeSet;
     } | null>;
     isCriticalPathSettled(): boolean;
     whenCriticalPathSettled(): Promise<void>;
+    private _withReappliedViewState;
+    /**
+     * 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;
     private _startCriticalPathForCurrentRevision;
     private _runCriticalPathAndCapture;
-    /**
-     * Undo/Redo restores the user's historical mutation while retaining current
-     * non-historical truth (for example a refreshed baseline). Re-derive every
-     * value that depends on both so the restored model is immediately coherent.
-     */
     private _recomputeAfterHistoryRestore;
     undo(): Promise<ChangeSet | null>;
     redo(): Promise<ChangeSet | null>;
     canUndo(): boolean;
     canRedo(): boolean;
-    /**
-     * Establishes a new persistence boundary without mutating schedule state.
-     * Completed saves call this synchronously so neither prior undo entries nor
-     * their redo branch can cross the persisted boundary.
-     */
     clearHistory(): void;
     undoDepth(): number;
     private _resyncCustomIdTrackerFromModel;
@@ -1300,13 +779,6 @@ declare class ScheduleCore {
     private readonly _ready;
     private readonly _saveTracker;
     private assertReady;
-    /**
-     * Revert the current dispatch's mutations from the write-capture journal. If
-     * the restore ITSELF throws, the state may be a third, partially-inverted
-     * state — worse than either endpoint — so poison the core: refuse all further
-     * dispatches and surface the fault so the host reloads from backend. A failed
-     * rollback is never swallowed.
-     */
     private _rollback;
 }
 
@@ -1323,25 +795,6 @@ interface ParsedInput {
 }
 declare function parseFromBackend(input: BackendScheduleInput, reporter?: ScheduleCoreReporter): ParsedInput;
 
-/**
- * Returns the ACTIVE baseline point of an activity, or null.
- *
- * Ported verbatim from the legacy selector used across the schedule
- * (`react_client/src/views/ganttContainer/gantt/gantt.helper.js`
- * calculatePonderators / getDurationRecursively, and the baseline columns
- * `startBaseCol`…`durationBaseCol`):
- *
- *   activity.baseline_points.find(b => b.sectorbaselineversion?.active)
- *
- * Exactly one version per sector is active. Returns null when the activity
- * has no `baseline_points`, an empty array, or no point whose version is
- * active — matching the legacy behavior where such activities get
- * `ponderator = 0` (baseline-only, no fallback to real values; see memory
- * `project_ponderator_baseline_fix`).
- *
- * The `active` flag is treated as truthy (not strictly `=== true`) to match
- * the legacy `if (base.sectorbaselineversion.active)` check.
- */
 declare function getActiveBaseline(activity: {
     baselinePoints?: readonly CoreBaselinePoint[];
 } | null | undefined): CoreBaselinePoint | null;
@@ -1349,135 +802,48 @@ declare function getActiveBaseline(activity: {
 interface CalendarLike {
     calculateDuration(start: Date, end: Date): number;
 }
-/**
- * Expected % a baseline-planned activity should have completed by `now`,
- * measured in working time against its baseline calendar. Faithful port of
- * legacy `calculateExpected` (lookahead-common.js): edge rules first, else the
- * working-time ratio. Returns 0..100. `now` should already be the comparison
- * instant the caller wants (e.g. end-of-day).
- *
- * Shared by the `expected_progress` (live) and `expected_progress_base` columns
- * (column-owns-everything: the formula is the one piece both columns share).
- */
 declare function expectedProgressFromBaseline(start: Date, end: Date, now: Date, calendar: CalendarLike): number;
 
 interface ExpectedProgressAdapter {
     getChildrenIds(parentId: string | 0): readonly string[];
     getActivity(id: string): Record<string, unknown> | null;
     setActivityField(id: string, field: string, value: unknown): void;
-    /** Resolve a baseline calendar by its engine id (`${baseCalendarId}-base`). */
     getBaseCalendar(engineId: string): CalendarLike | null;
 }
-/**
- * Walks the tree from `rootIds`, writing `expected_progress_base` on every
- * activity: leaves from their baseline calendar, parents as
- * `Σ(childBase × child.ponderator) / 100` (faithful port of engine.ts
- * aggregateHierarchy). Returns the ids whose value changed.
- */
 declare function computeExpectedProgress(rootIds: readonly string[], now: Date, adapter: ExpectedProgressAdapter, defaultBaseCalendarId?: string | null): string[];
 
 type StaticActivityDefaults = Omit<CoreActivity, 'id' | 'parentId' | 'name' | 'startDate' | 'endDate' | 'durationHours' | 'calendarId' | 'uniqueCorrelativeId'>;
 declare const NEW_ACTIVITY_DEFAULTS: Readonly<StaticActivityDefaults>;
 
-/**
- * Schedule-core equivalent of the legacy frontend `checkNoUpdatedLinks`.
- *
- * Returns the CURRENT links that were MODIFIED relative to a `baseline` (the
- * last loaded/saved link state). A link is "modified" iff its `lag` or `type`
- * differs from its baseline counterpart (matched by `id`).
- *
- * Why only lag/type: empirically those are the only mutable fields of a link —
- * `source`/`target` are identity, and the rest are backend/derived. The core
- * `link-update` intent (`dispatch/types.ts`) changes exactly "lag and/or type",
- * so this comparison is complete.
- *
- * New links (absent from baseline) and deleted links (present only in baseline)
- * are NOT "modified" — those belong to the unsaved / deleted buckets. The
- * baseline is supplied by the caller (the save flow's reference snapshot); per
- * interface discipline this is a pure helper, not a method on the core/port.
- */
 declare function checkNoUpdatedLinks(baseline: readonly Link[], current: readonly Link[]): Link[];
 
-/**
- * Schedule-core equivalent of the legacy frontend `checkNoSavedActivities` /
- * `checkNoSavedLinks`: an entity is "unsaved" when it has no backend id
- * (`proplannerId`) — i.e. it was created in-session and not yet persisted.
- *
- * Pure helper (same `!proplannerId` criterion as legacy, so 0/null/undefined
- * all count as unsaved). Works on `core.getAllActivitiesView()` / `getAllLinks()`
- * or on `gantt.serialize().data` — both carry `proplannerId`. Per interface
- * discipline this is a helper, not a method on the core/port.
- */
 interface WithProplannerId {
     proplannerId?: number | null;
     [key: string]: unknown;
 }
 declare const getUnsavedActivities: <T extends WithProplannerId>(activities?: readonly T[]) => T[];
 
-/**
- * Returns a microtask-priority yield. Resolves on the next event-loop
- * tick — the browser is free to paint, handle input, or process other
- * tasks in between.
- */
 declare function yieldToBrowser(): Promise<void>;
 
-/**
- * Does this dispatch recompute the critical path? The single authority for the
- * question, shared by the dispatch gate (`resolveDerivedPasses`) and the
- * bridge, which reads it to defer the CP out of the paint. Mirrors legacy: the
- * CP re-derives on every scheduling change. Prop-only/administrative intents
- * and edits that touch only non-scheduling columns leave the current CP
- * revision intact; structural reparents are never exempt.
- */
 declare function willRunCriticalPath(action: DispatchAction): boolean;
 
-/** Activity types */
 declare const ACTIVITY_TYPE: {
     readonly TASK: "task";
     readonly PROJECT: "project";
     readonly MILESTONE: "milestone";
 };
 
-/**
- * Root-parent sentinel — single source of truth.
- *
- * Root-level activities have meant "root" under several shapes across the
- * codebase and the recorded data: string `'0'` (post-parse domain model),
- * numeric `0` (DHTMLX / engine seam), and nullish. `isRootParent` accepts
- * all of them; `normalizeParentKey` collapses them to the canonical `'0'`.
- *
- * NOTE: `'0'` is overloaded elsewhere in the domain (FS link-type code,
- * correlative ids). These constants are ONLY for the parent axis.
- */
-/** Canonical root-parent id in the post-parse domain model. */
 declare const ROOT_PARENT_ID: "0";
-/** True when `parent` denotes the root level, under any historical shape. */
 declare function isRootParent(parent: unknown): boolean;
-/** Collapse any root shape to the canonical `'0'`; stringify the rest. */
 declare function normalizeParentKey(parent: unknown): string;
 
-/**
- * Canonical bidirectional map between DHTMLX link kinds ('0'-'3') and the
- * backend/display two-letter codes (fs/ss/ff/sf), plus the predecessor
- * display-string vocabulary.
- *
- * Single source of truth — replaces the hand-maintained copies that lived in
- * parse-predecessor-string (code→number), apply-link-operation
- * (number→code), boundary/backend parseFromBackend (code→number) and
- * inverses (number→code). The mutual `satisfies Record<…>` constraints make
- * omitting or typo'ing a key on either side a compile error.
- */
-
-/** Backend/display two-letter link codes. */
 type LinkTypeCode = 'fs' | 'ss' | 'ff' | 'sf';
-/** DHTMLX numeric kind → backend/display code. */
 declare const LINK_TYPE_CODE: {
     readonly "0": "fs";
     readonly "1": "ss";
     readonly "2": "ff";
     readonly "3": "sf";
 };
-/** Backend/display code → DHTMLX numeric kind (inverse of LINK_TYPE_CODE). */
 declare const LINK_CODE_TO_TYPE: {
     readonly fs: "0";
     readonly ss: "1";
@@ -1485,49 +851,10 @@ declare const LINK_CODE_TO_TYPE: {
     readonly sf: "3";
 };
 
-/**
- * Inverse boundary maps (domain → backend vocabulary).
- *
- * The forward translations live in `constants.ts` (`CONSTRAINT_LABEL_MAP`)
- * and `link-display.ts` (`LINK_CODE_TO_NUMBER`). The *serialization*
- * core → backend is intentionally NOT owned by this package today — it
- * lives in the consumer bridge (`react_client/gantt.helper.js`,
- * `from_number_to_code` / `GanttConstraint` reverse lookup) because the
- * bridge is the source of truth for what the server expects on save.
- *
- * These inverses exist so the mapping is documented and testable next to
- * its forward counterpart, and so a future `core → backend` layer doesn't
- * re-derive them by hand. **Internal only — not exported in `src/index.ts`.**
- * See Obsidian `BOUNDARY_TRANSLATIONS.md` §"Mapeos inversos".
- */
-
-/** Inverse of `CONSTRAINT_LABEL_MAP` — internal code → backend label. */
 declare const CONSTRAINT_TYPE_TO_LABEL: Record<ConstraintType, string>;
 
-/**
- * Working-day vocabulary — genuine cross-component primitive (creation
- * defaults, internal/state context fallbacks, link lag display). The value
- * is the FALLBACK only; a sector- or calendar-provided hoursPerDay always
- * takes precedence at every consumer.
- */
 declare const DEFAULT_HOURS_PER_DAY = 8;
 
-/**
- * Canonical catalog of `DispatchAction` kinds.
- *
- * The discriminated union in `types.ts` remains the source of truth; this
- * module exposes it as RUNTIME vocabulary so `.js` consumers (bridge
- * entry-points, guard tests) stop retyping the wire strings. Exhaustiveness
- * is compile-checked HERE (not in the guard test — `tsconfig.json` excludes
- * `*.test.ts` from `tsc --noEmit` and vitest does not typecheck):
- *   - `satisfies Record<string, DispatchActionKind>` rejects any entry whose
- *     value is not a union member (catalog ⊆ union);
- *   - `KIND_CATALOG_COVERS_UNION: Record<DispatchActionKind, true>` requires
- *     one entry per union member (union ⊆ catalog) — adding a kind to
- *     `DispatchAction` without updating this module breaks the build.
- * The string VALUES are a frozen contract (see `constants.guard.test.ts`).
- */
-
 type DispatchActionKind = DispatchAction['kind'];
 declare const DISPATCH_ACTION_KIND: {
     readonly PERSISTENCE_ACKNOWLEDGE: "persistence-acknowledge";
@@ -1551,28 +878,13 @@ declare const DISPATCH_ACTION_KIND: {
     readonly SELECTION_TOGGLE: "selection-toggle";
     readonly SELECTION_REPLACE: "selection-replace";
     readonly VISIBILITY_SET: "visibility-set";
+    readonly FILTER_SET: "filter-set";
+    readonly SORT_SET: "sort-set";
     readonly SIR_SYNC: "sir-sync";
     readonly ACTIVITY_LOOKAHEAD_SYNC: "activity-lookahead-sync";
 };
 declare const DISPATCH_ACTION_KINDS: ReadonlyArray<DispatchActionKind>;
 
-/**
- * Canonical vocabulary of activity-creation triggers.
- *
- * The engine's `activity-create` intent does NOT carry this field — these
- * kinds name the USER trigger the consumer's creation hub routes on before
- * dispatching (`requestActivityCreation` / `CreateActivityIntent` in
- * `react_client` core path). The engine owns the vocabulary so the client
- * and the bridge import ONE canonical source instead of retyping the
- * literals (CONSTANTES_DECISIONES paso 1). The string VALUES are a frozen
- * contract — verified verbatim against the client union
- * (`core/features/createActivity/intents.ts`) on 2026-07-02.
- *
- *   - `CHILD`           — per-row "+" button (runs the lookahead guard).
- *   - `CHILD_CONFIRMED`  — lookahead-cleanup modal confirm (guard already passed).
- *   - `LINE`            — green bar "add-task-by-line".
- *   - `ROOT`            — generic "+" (header / create), no guard.
- */
 declare const CREATION_KIND: {
     readonly CHILD: "child";
     readonly CHILD_CONFIRMED: "child-confirmed";
@@ -1581,16 +893,6 @@ declare const CREATION_KIND: {
 };
 type CreationKind = (typeof CREATION_KIND)[keyof typeof CREATION_KIND];
 
-/**
- * Canonical catalog of dispatch rejection reasons.
- *
- * `DispatchResult.reason` stays `string` on purpose: it is the cross-domain
- * bag that also carries pipeline gate codes (`ParseErrorCode`,
- * `ValidationReason`, `EditDenialReason`) and the link-engine rejected
- * verdicts. This module covers the reasons DISPATCH ITSELF produces, so
- * producers and tests share one compile-checked source. The string VALUES
- * are a frozen contract — the bridge matches on them.
- */
 declare const REJECTION_REASON: {
     readonly CANNOT_EDIT: "cannot_edit";
     readonly PARSE_ERROR: "parse_error";
@@ -1614,11 +916,6 @@ declare const REJECTION_REASON: {
 };
 type DispatchRejectReason = (typeof REJECTION_REASON)[keyof typeof REJECTION_REASON];
 
-/**
- * Amplitude event names emitted by the dispatch layer (structure mutations).
- * Analytics CONTRACT — values must stay byte-identical to production.
- * Column-level entry events live in `columns/shared/trackingEvents.ts`.
- */
 declare const DISPATCH_TRACK_EVENT: {
     readonly ACTIVITY_CREATION: "schedule_activity_creation";
     readonly ACTIVITY_DELETION: "schedule_activity_deletion";
@@ -1628,4 +925,4 @@ declare const DISPATCH_TRACK_EVENT: {
 };
 type DispatchTrackEvent = (typeof DISPATCH_TRACK_EVENT)[keyof typeof DISPATCH_TRACK_EVENT];
 
-export { ACTIVITY_TYPE, type ActivityCreter, type ActivityId, type ActivityType, type BackendActivityInput, type BackendCalendarInput, type BackendLinkInput, type BackendScheduleInput, type BackendSectorInput, type BaselinePoint, type BaselineVersion, CALENDAR_UNIT, COLUMN, CONSTRAINT_TYPE, CONSTRAINT_TYPE_TO_LABEL, CREATION_KIND, type Calendar, type CalendarId, type CalendarUnit, type CalendarWorktime, type ChangeSet, type ColumnName, type ConstraintType, type ConstraintWarning, type CoreActivity, type CreationKind, DEFAULT_HOURS_PER_DAY, DISPATCH_ACTION_KIND, DISPATCH_ACTION_KINDS, DISPATCH_TRACK_EVENT, type DispatchAction, type DispatchActionKind, type DispatchOptions, type DispatchRejectReason, type DispatchResult, type DispatchTrackEvent, type EntityChange, LINK_CODE_TO_TYPE, LINK_TYPE, LINK_TYPE_CODE, type Link, type LinkId, type LinkType, type LinkTypeCode, type LinksBatchOperation, NEW_ACTIVITY_DEFAULTS, type ParsedInput, type PastedActivityInput, type PastedLinkInput, type PendingRequest, type PersistedEntityIdentity, REJECTION_REASON, ROOT_PARENT_ID, ScheduleCore, type ScheduleCoreInput, type ScheduleCoreReporter, type ScheduleCoreStatus, type ScheduleEffect, type SectorMetadata, type StatusCriteria, type TrackingEvent, WORK_TIME_DIRECTION, type WorkTimeDirection, checkNoUpdatedLinks, computeExpectedProgress, expectedProgressFromBaseline, getActiveBaseline, getUnsavedActivities, isRootParent, normalizeParentKey, parseFromBackend, willRunCriticalPath, yieldToBrowser };
+export { ACTIVITY_TYPE, type ActivityCreter, type ActivityId, type ActivityType, type BackendActivityInput, type BackendCalendarInput, type BackendLinkInput, type BackendScheduleInput, type BackendSectorInput, type BaselinePoint, type BaselineVersion, type BranchOrderChange, CALENDAR_UNIT, COLUMN, CONSTRAINT_TYPE, CONSTRAINT_TYPE_TO_LABEL, CREATION_KIND, type Calendar, type CalendarId, type CalendarUnit, type CalendarWorktime, type ChangeSet, type ColumnName, type ConstraintType, type ConstraintWarning, type CoreActivity, type CreationKind, DEFAULT_HOURS_PER_DAY, DISPATCH_ACTION_KIND, DISPATCH_ACTION_KINDS, DISPATCH_TRACK_EVENT, type DispatchAction, type DispatchActionKind, type DispatchOptions, type DispatchRejectReason, type DispatchResult, type DispatchTrackEvent, type EntityChange, type FilterCriterion, type FilterDateRange, type FilterField, type FilterState, LINK_CODE_TO_TYPE, LINK_TYPE, LINK_TYPE_CODE, type Link, type LinkId, type LinkType, type LinkTypeCode, type LinksBatchOperation, NEW_ACTIVITY_DEFAULTS, type OrderRule, type OrderState, type ParsedInput, type PastedActivityInput, type PastedLinkInput, type PendingRequest, type PersistedEntityIdentity, REJECTION_REASON, ROOT_PARENT_ID, ScheduleCore, type ScheduleCoreInput, type ScheduleCoreReporter, type ScheduleCoreStatus, type ScheduleEffect, type SectorMetadata, type StatusCriteria, type TrackingEvent, WORK_TIME_DIRECTION, type WorkTimeDirection, checkNoUpdatedLinks, computeExpectedProgress, expectedProgressFromBaseline, getActiveBaseline, getUnsavedActivities, isRootParent, normalizeParentKey, parseFromBackend, willRunCriticalPath, yieldToBrowser };