@outbuild-company/schedule-core 1.0.0

package/dist/index.d.cts

@@ -0,0 +1,2122 @@
+/**
+ * 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$2 = string;
+type LinkId$1 = string;
+type CalendarId$2 = 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";
+};
+/**
+ * RAW DHTMLX row as the scheduler engine and `ScheduleState` see it:
+ * snake_case fields, `parent` with the numeric-0 root sentinel,
+ * `$source`/`$target` link id arrays, `duration` in HOURS, ids
+ * `string | number`. Dates are real Date objects (not ISO strings);
+ * serialization for JSON fixtures happens in the recording layer.
+ * Sibling shapes: persisted `Activity` (`src/types.ts`) and the
+ * pipelines' camelCase `ActivitySnapshot` (`src/columns/types.ts`) —
+ * see the `Activity` docblock for the full map.
+ */
+interface EngineActivitySnapshot {
+    id: ActivityId$2;
+    start_date: Date;
+    end_date: Date;
+    duration: number;
+    type: ActivityType;
+    parent: ActivityId$2 | 0;
+    constraint_type: ConstraintType | null;
+    constraint_date: Date | null;
+    progress: number;
+    auto_scheduling: boolean;
+    calendar_id: CalendarId$2 | null;
+    /** Outgoing link ids (this activity is the link source) */
+    $source: LinkId$1[];
+    /** Incoming link ids (this activity is the link target) */
+    $target: LinkId$1[];
+    /** Mirrors `Activity.is_critical` (`CriticalFlag`): boolean fresh from the
+     * backend, `'Si'`/`'No'` after the critical-path pass. */
+    is_critical?: boolean | 'Si' | 'No';
+    dragged?: boolean;
+    /**
+     * Display/domain fields carried at runtime via the activityToSnapshot `...a`
+     * spread; declared so state-ports reads them typed instead of casting.
+     */
+    text?: string;
+    description?: string;
+    cost?: number;
+    used_cost?: number;
+    real_cost?: number;
+    hhWorkTime?: number;
+    real_work?: number;
+    ponderator?: number;
+    tasks?: unknown[];
+    real_constraint_type?: ConstraintType | null;
+    last_constraint?: ConstraintType | null;
+    last_constraint_date?: Date | null;
+    last_start_date?: Date | null;
+    date_origin?: Date | null;
+    /**
+     * Backend DB row id (distinct from `id` which is `unique_id`). Optional
+     * because activities created in-session have no backend row yet.
+     */
+    proplannerId?: number;
+    /** Sequential display index used as a short human-readable activity label.
+     * `| undefined` is explicit: rollback before-images assign the prior value,
+     * which is `undefined` for an activity that had no correlative_id yet. */
+    correlative_id?: number | undefined;
+    /**
+     * Project-scoped unique identifier string, user-visible (e.g. "A-0001").
+     * Null for activities that have not been assigned one yet.
+     */
+    custom_id?: string | null;
+    /**
+     * UUID-like correlative assigned by Outbuild. May be string or number
+     * depending on the backend version; absent on in-session-created activities.
+     */
+    unique_correlative_id?: string | number | null;
+    /**
+     * Working-hours mirror of `duration` used by the Duration column renderer to
+     * avoid re-computing hours from days on every render. Stamped by
+     * `parseFromBackend`, `activityCreationPipeline`, and parent-bounds.
+     */
+    for_disable_milestone_duration?: number;
+    /**
+     * View-model visibility bit (UI filters); ex `should_be_showed` of the
+     * DHTMLX task. `visible !== false` = visible; default true.
+     */
+    visible?: boolean;
+    /** Checkbox-selection bit owned by the selection pipeline. */
+    checked?: boolean;
+    /** Visible (UI-layer) checkbox state, kept in sync with `checked`. */
+    visibleChecked?: boolean;
+    /** Signal to the bridge that `visibleChecked` was set this dispatch. */
+    mustApplyVisibleChecked?: boolean;
+    /**
+     * Pending Schedule Impact Requests freezing this activity (id-only
+     * reduction; non-empty ⇒ frozen). Carried verbatim from the backend payload.
+     * Only for dynamic setActivityField writes + arbitrary backend passthrough;
+     * all known fields are declared above.
+     */
+    pendingRequests?: PendingRequest[];
+    earlyStart?: Date | null;
+    earlyFinish?: Date | null;
+    lateStart?: Date | null;
+    lateFinish?: Date | null;
+    totalSlack?: number | null;
+    freeSlack?: number | null;
+    /** Expected-progress baseline output, written by the expected-progress pass. */
+    expected_progress?: number;
+    /** Lookahead membership; the core derives it in promote/demote (R4). */
+    is_lookahead?: boolean;
+    /** Client-side "new, unsaved" marker (not persisted as such). */
+    isNewActivity?: true | null;
+    /** Descendant new-activity id bookkeeping (R15, temporal). */
+    newActivitiesArray?: ActivityId$2[];
+    /** `newActivitiesArray.length > 0` mirror (R15, temporal). */
+    hasNewActivities?: boolean;
+    /** Activity modification log carried from the backend. */
+    activityModifications?: unknown[];
+    /** Load-derived: the activity fell back to the default calendar. */
+    assignedDefaultCalendar?: boolean;
+    /** Backend flag: has persisted children. */
+    has_childs?: boolean;
+    /** Backend flag: ponderator set manually (not auto-distributed). */
+    hasCustomPonderator?: boolean;
+    /** Backend aggregate: recursive duration sum. */
+    sumOfDurationRecursively?: number;
+    /** Backend row ids (distinct from the domain `id`). */
+    ganttId?: number;
+    sectorId?: number;
+    companyId?: number;
+    /** Subcontract column id + its raw backend object. */
+    subcontractId?: number | null;
+    subcontract?: unknown;
+    /** Responsibility / tag columns (arrays of backend rows). */
+    responsables?: unknown[];
+    tags?: unknown[];
+    /** Active baseline points overlaid at load. */
+    baseline_points?: BaselinePoint[];
+    /** Backend timestamps. */
+    createdAt?: string;
+    updatedAt?: string;
+    old_progress_registered?: number;
+    old_duration_registered?: number;
+    old_cost_registered?: number;
+    old_used_cost_registered?: number;
+    old_real_cost_registered?: number;
+    old_hhWorkTime_registered?: number;
+    /** Mirror of the constraint before the last change (constraint cluster). */
+    constraint_type_old?: ConstraintType | null;
+    /** `type === 'milestone'` cache flipped by the duration pipeline. */
+    is_milestone?: boolean;
+    /** DHTMLX markers consumed by the bridge / render layer. */
+    $keep_constraints?: boolean;
+    $rendered_type?: ActivityType;
+    $no_start?: boolean;
+    $no_end?: boolean;
+    status?: 'Waiting' | 'Doing' | 'Done';
+    progressSolidColor?: string;
+    color?: string;
+    /** Flags a recursive complete/uncomplete from the action-button flow. */
+    progressChangedByActionButton?: boolean;
+    custom_predecessors?: string;
+    /** Backend typo preserved (single 'c'). */
+    custom_sucessors?: string;
+    start_base?: Date;
+    end_base?: Date;
+    duration_base?: number;
+    cost_base?: number;
+    work_base?: number;
+    expected_progress_base?: number;
+}
+interface LinkSnapshot {
+    id: LinkId$1;
+    source: ActivityId$2;
+    target: ActivityId$2;
+    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`. Computed ONCE at expansion time
+     * (`parent-link-expansion.ts`), never per scheduling tick.
+     *
+     * All three must be set together (or none): a half-populated link would mix
+     * precomputed and derived components. Only the FF/SF-into-summary path emits
+     * them; every other link leaves them undefined and hits the fast path.
+     */
+    _sourceLag?: number;
+    _targetLag?: number;
+    _trueLag?: number;
+    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: {
+    readonly ASAP: "asap";
+    readonly ALAP: "alap";
+    readonly SNET: "snet";
+    readonly SNLT: "snlt";
+    readonly FNET: "fnet";
+    readonly FNLT: "fnlt";
+    readonly MSO: "mso";
+    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$1 = string;
+type LinkId = string;
+type CalendarId$1 = string;
+type ActivityType = 'project' | 'task' | 'milestone';
+
+/** DHTMLX link kinds: 0 = FS, 1 = SS, 2 = FF, 3 = SF. */
+type LinkType = '0' | '1' | '2' | '3';
+/**
+ * Critical-path output flag. Carries two historical shapes: `parseFromBackend`
+ * stores a boolean, and the critical-path pass (`initial-passes.ts`) overwrites
+ * it with the DHTMLX string `'Si'`/`'No'`. Both are observed at runtime (the
+ * CP / paste tests assert against `'Si'`/`'No'`; `parseFromBackend` against
+ * boolean), so the type unions all three rather than lying with a bare boolean.
+ */
+type CriticalFlag = boolean | 'Si' | 'No';
+/** 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 (or to
+ * `ACTIVITY_PASSTHROUGH_FIELDS` in `parseFromBackend.ts` and here).
+ *
+ * Companion type for runtime mutations: see `ActivityRuntime` below,
+ * which extends this with `DhtmlxHeritageFields`.
+ */
+/**
+ * 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;
+}
+/**
+ * PUBLIC persisted domain model — what `core.getActivityView()` returns and
+ * what the backend payload parses into. Fields are snake_case (backend +
+ * DHTMLX convention); `duration` is in DAYS at this boundary.
+ *
+ * The package has three activity shapes — one per layer:
+ * - `Activity` (this): public, persisted, snake_case.
+ * - `ActivitySnapshot` (`src/columns/types.ts`): camelCase + derived
+ *   fields (hasChildren, isMilestone…); what column pipelines read.
+ *   Built per-read by `state-ports.ts`; never persisted.
+ * - `EngineActivitySnapshot` (`src/autoscheduler/types.ts`): raw DHTMLX
+ *   row (snake_case + `parent`/`$source`/`$target`, hours-based
+ *   duration); what `ScheduleState` stores and the scheduler engine
+ *   consumes. Translation Activity ↔ engine: `src/dispatch/conversion.ts`.
+ */
+interface Activity {
+    id: ActivityId$1;
+    /** Parent's `id`, or `'0'` when the activity is a root. */
+    parent: ActivityId$1 | '0';
+    text: string;
+    description: string;
+    type: ActivityType;
+    start_date: Date;
+    end_date: Date;
+    duration: number;
+    constraint_type: ConstraintType | null;
+    constraint_date: Date | null;
+    auto_scheduling: boolean;
+    calendar_id: CalendarId$1 | null;
+    /**
+     * True when the activity had no valid calendar of its own and inherited the
+     * project default at load (its backend `calendarId` was null/undefined or a
+     * dangling reference). Set by `parseFromBackend` when `resolveCalendarId`
+     * falls back. The legacy DHTMLX worker computed this; the core owns calendar
+     * assignment now, so it owns the flag. The UI uses it to surface
+     * default-assigned activities. See `CALENDARS.md`.
+     */
+    assignedDefaultCalendar?: boolean;
+    progress: number;
+    cost: number;
+    used_cost: number;
+    real_cost: number;
+    hhWorkTime: number;
+    real_work: number;
+    ponderator: number;
+    correlative_id: number;
+    is_lookahead: boolean;
+    /**
+     * Bit de visibilidad del view-model (filtros de UI); ex `should_be_showed`
+     * del task DHTMLX. `visible !== false` = visible; default true. Escrito por
+     * el intent `visibility-set` (prop-only) y por `parseFromBackend` al load.
+     */
+    visible?: boolean;
+    newActivitiesArray: ActivityId$1[];
+    activityModifications: unknown[];
+    /**
+     * Backend DB row id (distinct from the core `id`, which is `unique_id`).
+     * Captured from `a.id` in `parseActivity`; `undefined` for activities
+     * created in-session (no backend id yet). Used by save dirty-detection to
+     * tell persisted activities from new ones. Mirrors `Link.proplannerId`.
+     */
+    proplannerId?: number;
+    unique_correlative_id: string;
+    ganttId: number;
+    sectorId: number;
+    companyId: number;
+    subcontractId: number | null;
+    subcontract: unknown;
+    custom_id: string | null;
+    hasCustomPonderator: boolean;
+    has_childs: boolean;
+    sumOfDurationRecursively: number;
+    /**
+     * Critical-path outputs (poblados cuando corre el CP: en background tras la
+     * carga vía `criticalPathReady`, o tras cada dispatch). `undefined` si el CP
+     * aún no corrió. `is_critical` es string DHTMLX (`'Si'`/`'No'`) post-CP,
+     * boolean recién parseado del backend — ver `CriticalFlag`.
+     */
+    earlyStart?: Date | null;
+    earlyFinish?: Date | null;
+    lateStart?: Date | null;
+    lateFinish?: Date | null;
+    totalSlack?: number | null;
+    freeSlack: number | null;
+    is_critical: CriticalFlag;
+    hasNewActivities: boolean;
+    isNewActivity: true | null;
+    /**
+     * Active-baseline snapshots for this activity (backend
+     * `sectorbaselinepoint[]`). Passthrough — carried verbatim so the
+     * frontend baseline columns and the ponderator computation can read the
+     * ACTIVE point via `getActiveBaseline`. `undefined` when the activity has
+     * no baseline (e.g. created in-session after the snapshot).
+     */
+    baseline_points?: BaselinePoint[];
+    tasks: unknown[];
+    responsables: unknown[];
+    tags: unknown[];
+    /**
+     * Pending Schedule Impact Requests (SIRs) freezing this activity. The
+     * schedule load path (`sector.controller.js`) already filters to
+     * `state==='pending'` and sends `{ id }` only, so the core stores just the
+     * id — enough to name the SIR when emitting a `sir-auto-reject` effect.
+     * Non-empty ⇒ the activity is frozen (`isFrozen`). The full SIR record lives
+     * in the front's Redux, not here. See `SIR_MAP.md`.
+     */
+    pendingRequests: PendingRequest[];
+    createdAt: string;
+    updatedAt: string;
+}
+interface Link {
+    id: LinkId;
+    source: ActivityId$1;
+    target: ActivityId$1;
+    type: LinkType;
+    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 working day ALWAYS carries its resolved windows (the parser resolves
+     * the default-hours fallback at parse time). 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 working day's
+     * windows.
+     */
+    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: `BackendCalendar.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$1;
+    /** 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;
+    hoursPerDay: number;
+    hoursPerWeek: number;
+    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';
+    fields?: Record<string, {
+        before: unknown;
+        after: unknown;
+    }> | undefined;
+    after: Readonly<T> | null;
+}
+
+/**
+ * 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).
+ */
+type LinksBatchOperation = {
+    kind: 'create';
+    source: ActivityId$1;
+    target: ActivityId$1;
+    type: LinkType;
+    lag?: number;
+    linkId?: LinkId;
+} | {
+    kind: 'update';
+    linkId: LinkId;
+    type?: LinkType;
+    lag?: number;
+} | {
+    kind: 'delete';
+    linkId: LinkId;
+};
+
+type DispatchAction = {
+    kind: 'inline-edit';
+    activityId: ActivityId$1;
+    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$1;
+        column: 'start_date' | 'end_date';
+        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$1;
+        column: string;
+        newValue: unknown;
+    }>;
+    eventSource?: string;
+} | {
+    kind: 'link-create';
+    source: ActivityId$1;
+    target: ActivityId$1;
+    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';
+    linkId: LinkId;
+} | {
+    kind: 'links-batch';
+    operations: ReadonlyArray<LinksBatchOperation>;
+} | {
+    kind: 'activity-create';
+    /** Where to put the new activity. Use `'0'` for root. */
+    parentId: ActivityId$1 | '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$1 | 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$1 | undefined;
+    /**
+     * Optional field overrides applied on top of the defaults built by
+     * the creation pipeline. Common cases: `text`, `duration`,
+     * `start_date`, `constraint_type`, `constraint_date`, `calendar_id`.
+     *
+     * Only keys that name a real model field are honored — the pipeline
+     * drops any incidental non-model key (dhtmlx runtime junk, lightbox UI
+     * state) so it can never phantom onto the created activity. `name` is
+     * accepted as an alias for `text` (mapped, then dropped as a raw key).
+     * See `isDroppableOverrideKey` in `creation/defaults.ts`.
+     */
+    overrides?: Partial<Activity>;
+    /**
+     * 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$1;
+    /**
+     * 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$1>;
+    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$1;
+    /** Destination parent. Same as current parent = reorder within. */
+    parentId: ActivityId$1 | '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.
+     */
+    afterSiblingId?: ActivityId$1;
+    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$1>;
+    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$1>;
+    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$1;
+    /** 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$1;
+    /** 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$1>;
+    /**
+     * 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$1>;
+    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$1>;
+    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: 'sir-sync';
+    activityId: ActivityId$1;
+    pendingRequests: ReadonlyArray<PendingRequest>;
+    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$1 | '0';
+        index: number;
+    } | {
+        afterSiblingId: ActivityId$1;
+    };
+    /**
+     * 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$1;
+    /**
+     * 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.
+     */
+    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$1;
+    readonly originalParentId: ActivityId$1 | '0';
+    readonly overrides: Partial<Activity>;
+}
+interface PastedLinkInput {
+    readonly source: ActivityId$1;
+    readonly target: ActivityId$1;
+    readonly type: LinkType;
+    /** Lag in DAYS (public boundary unit; converted to working hours inside). */
+    readonly lag: number;
+}
+/** Unit of duration/lag at the public boundary. Default 'days'. */
+type OutputUnit = 'days' | 'hours';
+interface DispatchOptions {
+    /** Skip the autoscheduler pass after the mutation. Default: false. */
+    skipAutoSchedule?: boolean;
+    /** Skip the CP recompute after the mutation. Default: false. */
+    skipCriticalPath?: boolean;
+    /** 'days' default; the DHTMLX bridge passes 'hours' to skip conversion. */
+    outputUnit?: OutputUnit;
+    /**
+     * 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?: OutputUnit;
+}
+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>;
+    /**
+     * 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, EngineActivitySnapshot>;
+    /**
+     * 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;
+    alertKey?: string | undefined;
+};
+type DatesBatchVerdict = {
+    activityId: string;
+    ok: true;
+} | {
+    activityId: string;
+    ok: false;
+    reason: string;
+    alertKey?: string | undefined;
+};
+
+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$1;
+    /** 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$1;
+    constraintType: ConstraintType;
+    constraintDate: Date;
+    /** The projected date that violated (start or end, per constraint type). */
+    projectedDate: Date;
+    messageKey: string;
+}
+interface ChangeSet {
+    source: DispatchAction | {
+        kind: 'init';
+    } | {
+        kind: 'undo';
+    } | {
+        kind: 'redo';
+    };
+    activities: ReadonlyArray<EntityChange<Activity>>;
+    links: ReadonlyArray<EntityChange<Link>>;
+    calendars: ReadonlyArray<EntityChange<Calendar>>;
+    trackingEvents: ReadonlyArray<TrackingEvent>;
+    /**
+     * 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).
+     */
+    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;
+}
+
+/**
+ * Backend payload shapes — exactly as the Outbuild server returns.
+ *
+ * The core accepts these directly in the constructor and parses them into
+ * normalized internal types.  Keeping these as the public input type means
+ * any consumer of the schedule API (frontend, node_server, future) speaks
+ * the same contract.
+ *
+ * Validated against the real mocks in
+ * `packages/schedule-core/src/testing/projects/startDate/`.
+ */
+/** Calendar shift definition — one shift per day, CSV-encoded strings. */
+interface BackendShift {
+    id: number;
+    /**
+     * Encoded shift string for the week:
+     * `false,8:00,8:00,8:00,8:00,8:00,false-false,16:00,...,false`
+     * left side = starts, right side = ends, each CSV is Sun..Sat.
+     * `false` means non-working day.
+     */
+    shift_string: string;
+    correlative_id: number;
+    createdAt: string;
+    updatedAt: string;
+    calendarId: number;
+    calendarexceptiondayId: number | null;
+}
+/** Backend calendar exception (per-date override). */
+interface BackendCalendarException {
+    id: number;
+    date: string;
+    /** Optional shifts for this specific exception. */
+    shifts?: BackendShift[];
+    [key: string]: unknown;
+}
+/** Calendar as returned by the server. */
+interface BackendCalendar {
+    id: number;
+    name: string;
+    unique_id: number;
+    is_default: boolean;
+    /** CSV of Sun..Sat: `"0,1,1,1,1,1,0"` (0 = non-working, 1 = working). */
+    working_days: string;
+    /** CSV of shift starts per day: `"false,8:00,8:00,8:00,8:00,8:00,false"`. */
+    shift_start: string;
+    /** CSV of shift ends per day: `"false,16:00,...,false"`. */
+    shift_end: string;
+    exceptiondays: BackendCalendarException[];
+    shifts: BackendShift[];
+    status: boolean;
+    companyId: number;
+    ganttId: number | null;
+    userId: number;
+    sectorId: number;
+    createdAt: string;
+    updatedAt: string;
+    [key: string]: unknown;
+}
+/**
+ * Activity exactly as the Outbuild server returns it — the raw, untrusted
+ * input boundary. Dates are strings, `duration` is in backend DAYS, and field
+ * names are the backend's (snake_case, `unique_id`, `parent_id`, `name`).
+ *
+ * `parseFromBackend` is the only place that consumes it: it validates and
+ * normalizes each row into the internal model. Nothing else in the core should
+ * read a `BackendActivityInput` after parse.
+ */
+interface BackendActivityInput {
+    /** Database row id. Distinct from `unique_id`. */
+    id: number;
+    /** Canonical schedule id (used by links and DHTMLX). String-encoded number. */
+    unique_id: string;
+    /** Parent's `unique_id`, or `"0"` for root. */
+    parent_id: string;
+    unique_correlative_id: string;
+    correlative_id: number;
+    name: string;
+    description: string;
+    type: 'project' | 'task' | 'milestone';
+    /** Format: `"YYYY/MM/DD H:MM"` (server local, see dateFormat in sector). */
+    start_date: string;
+    end_date: string;
+    duration: number;
+    /**
+     * Constraint label in plain English: `"As soon As Possible"`,
+     * `"Start no earlier than"`, etc.  Mapped to internal `ConstraintType`.
+     */
+    constraint: string;
+    /** Optional constraint date — server uses ISO 8601 or null. */
+    constraint_date?: string | null;
+    progress: number;
+    cost: number;
+    used_cost: number;
+    real_cost: number;
+    hhWorkTime: number;
+    real_work: number;
+    ponderator: number;
+    hasCustomPonderator: boolean;
+    has_childs: boolean;
+    isOnLookahead: boolean;
+    sumOfDurationRecursively: number;
+    freeSlack: number | null;
+    is_critical: boolean;
+    newActivitiesArray: string;
+    hasNewActivities: boolean;
+    isNewActivity: true | null;
+    custom_id: string | null;
+    ganttId: number;
+    sectorId: number;
+    companyId: number;
+    calendarId: number;
+    subcontractId: number | null;
+    /**
+     * Visibility bit of the legacy view-model. Historically NEVER sent by the
+     * backend (0 of ~105k activities across the captured seeds carry it) — the
+     * legacy client hardcoded `should_be_showed: true` at parse. Declared so
+     * `parseActivity` can map it to `visible` if it ever arrives; absent/null
+     * defaults to visible.
+     */
+    should_be_showed?: boolean;
+    tasks: unknown[];
+    responsables: unknown[];
+    tags: unknown[];
+    activitymodifications: unknown[];
+    /** Pending SIRs for this activity — schedule load sends `{ id }` only. */
+    pendingRequests: ReadonlyArray<{
+        id: number | string;
+    }>;
+    subcontract: unknown;
+    createdAt: string;
+    updatedAt: string;
+    /** Custom fields the backend may include — passed through opaquely. */
+    [key: string]: unknown;
+}
+/** Link as returned by the server. */
+interface BackendLink {
+    id: number | string;
+    source: number | string;
+    target: number | string;
+    /** DHTMLX kind: `"0"` FS, `"1"` SS, `"2"` FF, `"3"` SF. */
+    type: '0' | '1' | '2' | '3';
+    lag: number;
+    [key: string]: unknown;
+}
+/** Sector metadata — project-level config from the server. */
+interface BackendSector {
+    id: number;
+    name: string;
+    description: string | null;
+    status: boolean;
+    set_current: boolean;
+    visible: boolean;
+    order: number;
+    productive: boolean;
+    hoursPerDay: number;
+    hoursPerWeek: number;
+    accumulatedDuration: number;
+    /** Date format string used by the backend, e.g. `"DD/MM/YY hh:mm"`. */
+    dateFormat: string;
+    didCloseWeek: string | null;
+    currentClosedWeek: string | null;
+    expectedProgress: number;
+    /**
+     * Legacy Primavera-import flag. When true, the stored `duration` of each
+     * activity may not match the calendar (Primavera stores end-driven
+     * durations); the core recomputes duration from start/end at load. ~218
+     * production sectors carry it (active). See `Obsidian:newPlanSchedule/CALENDARS.md`.
+     */
+    update_duration_for_primavera_for_end_date?: boolean | null;
+    companyId: number;
+    projectId: number;
+    version: string;
+    createdAt: string;
+    updatedAt: string;
+    /** Calendars nested inside sector when the sector-fetch endpoint is used. */
+    calendars?: BackendCalendar[];
+    [key: string]: unknown;
+}
+/** Optional sibling payloads the API often returns alongside the sector. */
+interface BackendScheduleImpactRequests {
+    pending: unknown[];
+    approved: unknown[];
+    rejected: unknown[];
+}
+/** Complete server payload accepted by `ScheduleCore`. */
+interface BackendInput {
+    sector: BackendSector;
+    activities: BackendActivityInput[];
+    links: BackendLink[];
+    /**
+     * Calendars come either inside `sector.calendars` or as a sibling array.
+     * If both are present, the sibling array wins.
+     */
+    calendars?: BackendCalendar[] | undefined;
+    /**
+     * Baseline calendars, RAW from the backend's `showBaseCalendar` endpoint
+     * (exceptions under `baseexceptiondays`, `is_default`, no `-base` suffix).
+     * Parsed into a separate `ParsedInput.baseCalendars` collection — never
+     * mixed into the scheduling calendars. The core owns their reshape /
+     * differentiation (previously done by the frontend `refreshCalendarsRewrite`).
+     */
+    baseCalendars?: BackendCalendar[] | undefined;
+}
+
+declare const COLUMN: {
+    readonly REAL_WORK: "real_work";
+    readonly REAL_COST: "real_cost";
+    readonly EXPECTED_PROGRESS: "expected_progress";
+    readonly EXPECTED_PROGRESS_BASE: "expected_progress_base";
+    readonly START_BASE: "start_base";
+    readonly END_BASE: "end_base";
+    readonly DURATION_BASE: "duration_base";
+    readonly COST_BASE: "cost_base";
+    readonly WORK_BASE: "work_base";
+    readonly CALENDAR_DURATION: "calendarDuration";
+    readonly IS_CRITICAL: "is_critical";
+    readonly EARLY_START: "earlyStart";
+    readonly EARLY_FINISH: "earlyFinish";
+    readonly LATE_START: "lateStart";
+    readonly LATE_FINISH: "lateFinish";
+    readonly FREE_SLACK: "freeSlack";
+    readonly TOTAL_SLACK: "totalSlack";
+    readonly CORRELATIVE_ID: "correlative_id";
+    readonly UNIQUE_CORRELATIVE_ID: "unique_correlative_id";
+    readonly PONDERATOR: "ponderator";
+    readonly STATUS: "status";
+    readonly TEXT: "text";
+    readonly DESCRIPTION: "description";
+    readonly DURATION: "duration";
+    readonly PROGRESS: "progress";
+    readonly COST: "cost";
+    readonly USED_COST: "used_cost";
+    readonly HH_WORK_TIME: "hhWorkTime";
+    readonly START_DATE: "start_date";
+    readonly END_DATE: "end_date";
+    readonly CONSTRAINT_TYPE: "constraint_type";
+    readonly CONSTRAINT_DATE: "constraint_date";
+    readonly CALENDAR_ID: "calendar_id";
+    readonly CUSTOM_ID: "custom_id";
+    readonly SUBCONTRACT_ID: "subcontractId";
+    readonly RESPONSABLES: "responsables";
+    readonly TAGS: "tags";
+    readonly CUSTOM_PREDECESSORS: "custom_predecessors";
+    readonly CUSTOM_SUCESSORS: "custom_sucessors";
+};
+type ColumnName = (typeof COLUMN)[keyof typeof COLUMN];
+
+type ActivityId = string;
+type CalendarId = string;
+
+/**
+ * Role interfaces (Interface Segregation).
+ *
+ * Consumers receive the smallest role they need instead of the whole
+ * `ScheduleState`. A pure-read consumer takes `ActivityReader`; a
+ * read+write consumer takes `ActivityWriter`; a consumer that drives the
+ * per-dispatch write journal takes `WriteJournal`. `ScheduleState`
+ * implements all of them, so passing it anywhere a role is expected is
+ * still valid — the role just narrows what the callee is allowed to touch.
+ *
+ * Signatures here are copied verbatim from `ScheduleState`; the class is
+ * the source of truth. If the class changes a member, change the role to
+ * match (not the other way around).
+ */
+
+/** READ surface over the activity/link store and the hierarchy index. */
+interface ActivityReader {
+    getActivity(activityId: ActivityId$2): EngineActivitySnapshot | null;
+    getAllActivities(): ReadonlyArray<EngineActivitySnapshot>;
+    getAllLinks(): LinkSnapshot[];
+    getLink(linkId: LinkId$1): LinkSnapshot | null;
+    activityExists(activityId: ActivityId$2): boolean;
+    getChildren(parentId: ActivityId$2): ActivityId$2[];
+    getParent(activityId: ActivityId$2): EngineActivitySnapshot | null;
+    getParentId(activityId: ActivityId$2): ActivityId$2 | 0;
+    isChildOf(childId: ActivityId$2, parentId: ActivityId$2): boolean;
+    getAllIds(): readonly ActivityId$2[];
+    activityCount(): number;
+    forEachActivity(visit: (activity: EngineActivitySnapshot, id: ActivityId$2) => void): void;
+}
+/** READ + WRITE surface over the store. */
+interface ActivityWriter extends ActivityReader {
+    setActivityField<Field extends keyof EngineActivitySnapshot>(activityId: ActivityId$2, field: Field, value: EngineActivitySnapshot[Field]): void;
+    /** Bulk write of several fields of one activity in a single getActivity +
+     * write-capture note (vs N setActivityField calls). */
+    setActivityFields(activityId: ActivityId$2, fields: Partial<EngineActivitySnapshot>): void;
+    addLink(link: LinkSnapshot): void;
+    removeLink(linkId: LinkId$1): void;
+    setLinkField<Field extends keyof LinkSnapshot>(linkId: LinkId$1, field: Field, value: LinkSnapshot[Field]): void;
+    addActivity(activity: EngineActivitySnapshot): void;
+    removeActivity(activityId: ActivityId$2): void;
+}
+
+/**
+ * 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 BackendInput {
+    /**
+     * 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;
+}
+
+declare class ScheduleCore {
+    private _status;
+    /** True while an async dispatch is suspended inside the write-capture window.
+     * A sync facade mutation running in that gap would corrupt the in-flight
+     * journal, so sync mutators refuse to run while it is set. */
+    private _dispatchInFlight;
+    private readonly coreRuntime;
+    private readonly _undo;
+    private _opQueue;
+    private _mutationEpoch;
+    private _cpComputedEpoch;
+    constructor(input: ScheduleCoreInput);
+    get ready(): Promise<void>;
+    get criticalPathReady(): Promise<{
+        changes: ChangeSet;
+    }>;
+    get status(): ScheduleCoreStatus;
+    getSector(): Readonly<SectorMetadata>;
+    getActivityView(id: ActivityId$1, unit?: OutputUnit): Readonly<Activity> | null;
+    getAllActivitiesView(unit?: OutputUnit): ReadonlyArray<Readonly<Activity>>;
+    getChildrenView(parentId: ActivityId$1 | '0', unit?: OutputUnit): ReadonlyArray<Readonly<Activity>>;
+    getLinkView(id: LinkId, unit?: OutputUnit): Readonly<Link> | null;
+    getAllLinksView(unit?: OutputUnit): ReadonlyArray<Readonly<Link>>;
+    getProperty<Property extends keyof Activity>(activityId: ActivityId$1, property: Property, options?: {
+        unit?: OutputUnit;
+    }): Activity[Property] | null;
+    getAllIds(): readonly string[];
+    forEachActivityId(visit: (id: string) => void): void;
+    getChildrenIds(parentId: ActivityId$1 | '0'): ReadonlyArray<ActivityId$1>;
+    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).
+     */
+    getVisualOrderIds(): ReadonlyArray<ActivityId$1>;
+    hasChild(parentId: ActivityId$1 | '0'): boolean;
+    getCalendar(id: CalendarId$1): Readonly<Calendar> | null;
+    getAllCalendars(): ReadonlyArray<Readonly<Calendar>>;
+    getBaseCalendars(): ReadonlyArray<Readonly<Calendar>>;
+    isCustomIdInUse(customId: string, currentCustomId?: string | null): boolean;
+    getProjectWorkHours(): ProjectWorkHours | null;
+    getModifiedLinks(): ReadonlyArray<Readonly<Link>>;
+    markLinksPersisted(): void;
+    getModifiedActivities(): ReadonlyArray<Readonly<Activity>>;
+    markActivitiesPersisted(): void;
+    applyBaselines(points: readonly BaselinePoint[]): ReadonlyArray<Readonly<Activity>>;
+    /**
+     * Whole-tree ponderator recompute (zeroes, then redistributes 100 within
+     * each parent from its children's active baselines, weighted by `criterion`).
+     * Returns the activities whose `ponderator` changed, for a prop-only repaint.
+     * The base rollup (`applyBaselines`) depends on fresh ponderators, so callers
+     * run this before it on a criterion change or baseline save.
+     */
+    recomputeAllPonderators(criterion: ActivityCreter): ReadonlyArray<Readonly<Activity>>;
+    /**
+     * Recompute the weighted-progress rollup of every parent, bottom-up.
+     * Returns the activities whose `progress` changed, for a prop-only repaint.
+     */
+    recomputeAllProgressRollup(): ReadonlyArray<Readonly<Activity>>;
+    /**
+     * Set the project's status criterion (the Baseline↔Actual toggle) and
+     * recompute every activity's `status` against it. Stores the criterion so
+     * future dispatches keep deriving status with it. Returns the activities
+     * whose `status` changed, for a prop-only repaint.
+     */
+    setStatusCriteria(criteria: StatusCriteria): ReadonlyArray<Readonly<Activity>>;
+    allocateActivityId(): ActivityId$1;
+    createActivity(input: Omit<Extract<DispatchAction, {
+        kind: 'activity-create';
+    }>, 'kind'>, outputUnit?: OutputUnit): {
+        ok: true;
+        activity: Readonly<Activity>;
+        changes: ChangeSet;
+    } | {
+        ok: false;
+        reason: string;
+    };
+    private _enqueue;
+    dispatch(action: DispatchAction, options?: DispatchOptions): Promise<DispatchResult>;
+    private _dispatchInner;
+    /**
+     * Recompute the critical path OUT of band and return a repaintable ChangeSet
+     * of the 7 CP fields, or null when the CP is already fresh for the current
+     * state (coalesced). Enqueued on `_opQueue` so it runs serialized against
+     * dispatches — it reads/writes the live tree only when no mutation is in
+     * flight.
+     *
+     * Deferred-CP flow: dispatch with `{ skipCriticalPath: true }` (paints
+     * without the heavy CP pass), then call this after the paint. Bursts
+     * coalesce: only the first enqueued recompute after the last mutation does
+     * the work; later ones see `_cpComputedEpoch === _mutationEpoch` and no-op.
+     */
+    recomputeCriticalPath(): Promise<{
+        changes: ChangeSet;
+    } | null>;
+    private _recomputeCriticalPathIfStale;
+    private _runCriticalPathAndCapture;
+    undo(options?: {
+        outputUnit?: OutputUnit;
+    }): Promise<ChangeSet | null>;
+    redo(options?: {
+        outputUnit?: OutputUnit;
+    }): Promise<ChangeSet | null>;
+    clearHistory(): void;
+    canUndo(): boolean;
+    canRedo(): boolean;
+    undoDepth(): number;
+    private _resyncCustomIdTrackerFromModel;
+    destroy(): void;
+    private readonly _initPromise;
+    private readonly _criticalPathReady;
+    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;
+}
+
+/**
+ * Parse the raw backend payload into the core's normalized internal model.
+ *
+ * Pure function. No side effects, no state. Throws on structural errors
+ * (missing required fields, broken references) per Q4 in SCHEDULE_CORE_API.md.
+ *
+ * Public from the package — consumers can use this to pre-validate before
+ * instantiating ScheduleCore, or to round-trip data through tests.
+ */
+
+interface ParsedInput {
+    sector: SectorMetadata;
+    activities: Activity[];
+    links: Link[];
+    calendars: Calendar[];
+    /**
+     * Baseline calendars, kept SEPARATE from the scheduling `calendars`. They
+     * are never used to resolve an activity's calendar — only for the baseline
+     * render. Parsed from the raw `baseCalendars` input (the backend's
+     * `showBaseCalendar`); reshaped here (id+'-base', baseDefault, exceptions
+     * from `baseexceptiondays`) so the core owns the differentiation instead of
+     * the frontend `refreshCalendarsRewrite`.
+     */
+    baseCalendars: Calendar[];
+}
+declare function parseFromBackend(input: BackendInput, 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: {
+    baseline_points?: unknown;
+} | null | undefined): BaselinePoint | null;
+
+/**
+ * Surface this function needs from ScheduleState — kept structural so the
+ * function is unit-testable with a plain in-memory adapter.
+ */
+interface BaselineApplyAdapter {
+    forEachActivity(visit: (a: Record<string, unknown>, id: string) => void): void;
+    getActivity(id: string): Record<string, unknown> | null;
+    setActivityField(id: string, field: string, value: unknown): void;
+}
+/**
+ * Overlay baseline points onto activities, matching `point.activityId`
+ * (backend DB id) against `activity.proplannerId`. Writes the full group of
+ * points (all versions) onto `baseline_points`; the active one is selected
+ * downstream by `getActiveBaseline`. Activities absent from the new set get
+ * `baseline_points` reset to `[]`. Returns the ids of activities whose
+ * `baseline_points` changed (so the caller can repaint just those).
+ */
+declare function applyBaselinePoints(adapter: BaselineApplyAdapter, points: readonly BaselinePoint[]): string[];
+
+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[];
+
+/**
+ * Recompute the `ponderator` of EVERY activity in the schedule, in bulk.
+ *
+ * Faithful port of `goCalculatePonderators` in
+ * `react_client/src/views/ganttContainer/gantt/index.js:2008-2038` (the
+ * ponderator part — the progress rollup and save are separate concerns the
+ * caller wires). Two passes, mirroring the legacy:
+ *   1. Zero EVERY activity's ponderator.
+ *   2. For each parent (activity with children), redistribute 100 among its
+ *      children via `recomputePonderatorsForParent` (baseline-only).
+ *
+ * IMPORTANT — this is the ONLY ponderator recompute the schedule performs.
+ * Verified against the legacy (2026-06-04): the masterplan does NOT recompute
+ * ponderators on add / delete / move / inline-edit. `goCalculatePonderators`
+ * runs ONLY on two events (see index.js:395/443/625):
+ *   - the project criterion (`activity_creter`) changed
+ *     (`sectorObject.update_ponderators_masterplan`), or
+ *   - a baseline was created / saved.
+ * Both events otherwise reload the schedule. So there is intentionally NO
+ * per-mutation cascade and NO dispatch hook — adding one would diverge from
+ * production (a baselined child's siblings stay as the backend computed them
+ * until the next of those two events). See
+ * [[PONDERATOR_BASELINE_MIGRATION_PLAN]].
+ *
+ * Order-independent: a project child's weight derives from descendant
+ * BASELINES (`getDurationRecursively`), never from other ponderators, so the
+ * order parents are visited in does not affect the result.
+ */
+
+declare function recomputeAllPonderators(criterion: ActivityCreter, adapter: ActivityWriter): void;
+
+/**
+ * Recompute the weighted-progress rollup of EVERY parent in the schedule,
+ * bottom-up. `parent.progress = Σ(child.progress × child.ponderator / 100)`.
+ *
+ * Faithful port of legacy `check_progress` (editing-flow.js:154-197) — the
+ * second half of `goCalculatePonderators`. After a ponderator recompute
+ * (baseline create/save, see `recomputeAllPonderators`), parent progress is
+ * stale w.r.t. the new weights; this repropagates it.
+ *
+ * PROGRESS-ONLY by design: unlike the dispatch post-processor
+ * `recomputeParentFromChildren` (post-processors/parent-bounds.ts), this does NOT
+ * touch parent start/end/duration — only `progress` and the milestone mirror
+ * `for_disable_milestone_duration`. That keeps it testable in isolation
+ * (no calendars/dates needed) and matches what `check_progress` actually did.
+ *
+ * Order is load-bearing (unlike ponderators, which are order-independent): a
+ * grandparent's rollup consumes its children-parents' ALREADY rolled-up
+ * progress, so parents are visited deepest-first.
+ *
+ * Parity rules:
+ *   - child with no/zero ponderator does not contribute;
+ *   - a parent whose children contribute nothing keeps its progress frozen;
+ *   - `progress` is kept a NUMBER but rounded per level to 2 decimals
+ *     (`roundProgressPerLevel`) — legacy `check_progress` recurses on
+ *     `toFixed(2)`, so each ancestor consumes its children's 2-decimal value
+ *     (MORNING_QUEUE.md — JUN-02).
+ */
+
+declare function recomputeAllProgressRollup(adapter: ActivityWriter): void;
+
+/**
+ * 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.
+ */
+
+/**
+ * Shape of the task object AFTER the pipeline configures it.
+ *
+ * Mirrors the canonical `Activity` interface (from `../../types.ts`) plus
+ * a handful of Outbuild-specific fields (responsables, tags, subcontractId,
+ * real_constraint_type) and legacy lifecycle flags (new_task, isNewActivity,
+ * $source, $target) that downstream consumers still read.
+ *
+ * Every field in `Activity` is present here. The defaults for the
+ * non-runtime-computed ones live in `NEW_ACTIVITY_DEFAULTS`.
+ */
+interface NewActivityFields {
+    text: string;
+    description: string;
+    type: 'task' | 'milestone' | 'project';
+    start_date: Date;
+    end_date: Date;
+    duration: number;
+    progress: number;
+    constraint_type: ConstraintType | null;
+    constraint_date: Date | null;
+    calendar_id: CalendarId;
+    /** Parent id (string) or `'0'` for root. Always string — no number drift. */
+    parent: ActivityId | '0';
+    auto_scheduling: boolean;
+    hhWorkTime: number;
+    cost: number;
+    used_cost: number;
+    /**
+     * Earned cost: `(progress/100) × activeBaseline.cost`. A fresh activity has
+     * progress 0 and no active baseline, so it starts at 0 — matching what the
+     * load-path `emitRealCost` would compute for a new leaf. Seeded explicitly so
+     * the field is never `undefined` (which surfaced as `NaN` downstream).
+     */
+    real_cost: number;
+    /** Real worked hours; aggregated from progress submittals. Starts at 0. */
+    real_work: number;
+    /**
+     * Baseline-derived weighting factor used by the parent.progress rollup.
+     * Starts at 0 (no baseline yet); set by the backend on baseline import.
+     * Not editable from the schedule UI — see `project_ponderator_not_editable`.
+     */
+    ponderator: number;
+    responsables: unknown[];
+    tags: unknown[];
+    subcontractId: string | number | null;
+    real_constraint_type: ConstraintType | null;
+    should_be_showed: boolean;
+    /** View-model visibility bit (`visible !== false` = visible). */
+    visible: boolean;
+    activityModifications: unknown[];
+    pendingRequests: unknown[];
+    /** String form, matches Sequelize BIGINT serialization. */
+    unique_correlative_id: string;
+    start_date_backup: string;
+    new_task: true;
+    isNewActivity: true;
+    /**
+     * Tracks outgoing link ids (this activity is the link source).
+     * Initialized empty; mutated by link-create / link-delete to keep the
+     * index consistent. The snapshot reads it directly, so it must always
+     * exist (not undefined) — see D1 in DIVERGENCES_activity_create.md.
+     */
+    $source: string[];
+    /** Same as $source for incoming links (this activity is the target). */
+    $target: string[];
+    /** Pass-through bucket for any extra fields the caller provides. */
+    [key: string]: unknown;
+}
+
+/**
+ * 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;
+
+/**
+ * Defaults for newly-created activities — the **canonical template** that
+ * `buildNewActivity` spreads before applying caller-provided overrides.
+ *
+ * Single source of truth: any documentation that says "a new activity
+ * starts as X" must reference this constant, never inline literals.
+ *
+ * The shape produced by spreading this constant + the runtime-computed
+ * fields below is a complete Activity (every field in the `Activity`
+ * interface from `../../types.ts` is accounted for).
+ *
+ * Fields NOT in this constant are computed at runtime because they depend
+ * on input or context:
+ *   - `id`                       → allocated by `ActivityIdGenerator.next()`
+ *   - `parent`                   → from `DispatchAction.parentId` (or `'0'`)
+ *   - `start_date`               → inherited from parent or `fallbackStartDate`,
+ *                                  then snapped to the calendar's next
+ *                                  working-time boundary
+ *   - `end_date`                 → calendar-aware via `adapter.calculateEndDate`
+ *   - `duration`                 → override > `sector.hoursPerDay` > `8`
+ *   - `calendar_id`              → override > `sector.defaultCalendar`
+ *   - `unique_correlative_id`    → allocated by `UniqueCorrelativeIdGenerator.next()`
+ *   - `custom_id`                → allocated by `customIdTracker`
+ *   - `text`                     → `'New Master Plan'` when this is the very
+ *                                  first activity of the sector, `'New Activity'`
+ *                                  otherwise (override beats both)
+ *   - `correlative_id`           → assigned by `recomputeCorrelativeIds` after
+ *                                  the new activity has been inserted in the
+ *                                  parent's children list
+ *
+ * The `real_constraint_type` field is set AFTER the spread of overrides so
+ * it always mirrors the (possibly overridden) `constraint_type`.
+ */
+
+declare const NEW_ACTIVITY_DEFAULTS: Readonly<Omit<NewActivityFields, 'id' | 'parent' | 'start_date' | 'end_date' | 'duration' | 'calendar_id' | 'unique_correlative_id' | 'text' | 'start_date_backup'>>;
+
+/**
+ * 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 any scheduling change, and is left STALE for prop-only
+ * intents, the structural reparents (indent/outdent), and edits that touch only
+ * non-scheduling columns.
+ */
+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";
+    readonly ff: "2";
+    readonly sf: "3";
+};
+
+/**
+ * Inverse boundary maps (domain → backend vocabulary).
+ *
+ * The forward translations live in `parseFromBackend.ts`
+ * (`CONSTRAINT_LABEL_MAP`, `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>;
+
+/**
+ * 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 INLINE_EDIT: "inline-edit";
+    readonly DATES_BATCH: "dates-batch";
+    readonly BULK_EDIT: "bulk-edit";
+    readonly LINK_CREATE: "link-create";
+    readonly LINK_UPDATE: "link-update";
+    readonly LINK_DELETE: "link-delete";
+    readonly LINKS_BATCH: "links-batch";
+    readonly ACTIVITY_CREATE: "activity-create";
+    readonly ACTIVITY_DELETE: "activity-delete";
+    readonly ACTIVITY_MOVE: "activity-move";
+    readonly ACTIVITY_INDENT: "activity-indent";
+    readonly ACTIVITY_OUTDENT: "activity-outdent";
+    readonly ACTIVITY_SET_PROGRESS: "activity-set-progress";
+    readonly ACTIVITY_PASTE: "activity-paste";
+    readonly SELECTION_TOGGLE: "selection-toggle";
+    readonly SELECTION_REPLACE: "selection-replace";
+    readonly VISIBILITY_SET: "visibility-set";
+    readonly SIR_SYNC: "sir-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";
+    readonly LINE: "line";
+    readonly ROOT: "root";
+};
+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";
+    readonly INVALID: "invalid";
+    readonly CUSTOM_ID_DUPLICATE: "custom_id_duplicate";
+    readonly INVALID_LINK_TYPE: "invalid_link_type";
+    readonly INVALID_LINK_LAG: "invalid_link_lag";
+    readonly INVALID_VALUE: "invalid_value";
+    readonly NO_PIPELINE_FOR_COLUMN: "no_pipeline_for_column";
+    readonly ACTIVITY_NOT_FOUND: "activity_not_found";
+    readonly PARENT_NOT_FOUND: "parent_not_found";
+    readonly ACTIVITY_IDS_EMPTY: "activity_ids_empty";
+    readonly ANCHOR_SIBLING_CONFLICT: "anchor_sibling_conflict";
+    readonly ANCHOR_SIBLING_NOT_FOUND: "anchor_sibling_not_found";
+    readonly ANCHOR_SIBLING_WRONG_PARENT: "anchor_sibling_wrong_parent";
+    readonly PARENT_FROZEN_BY_SIR: "parent_frozen_by_sir";
+    readonly CANNOT_MOVE_INTO_OWN_DESCENDANT: "cannot_move_into_own_descendant";
+    readonly INDENT_NO_ELIGIBLE_SIBLING: "indent_no_eligible_sibling";
+    readonly OUTDENT_ROOT_LEVEL_NOT_EDITABLE: "outdent_root_level_not_editable";
+    readonly INVALID_PROGRESS_VALUE: "invalid_progress_value_must_be_0_or_100";
+};
+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";
+    readonly ACTIVITY_MOVE: "schedule_activity_move";
+    readonly ACTIVITY_INDENT: "schedule_activity_indent";
+    readonly ACTIVITY_OUTDENT: "schedule_activity_outdent";
+};
+type DispatchTrackEvent = (typeof DISPATCH_TRACK_EVENT)[keyof typeof DISPATCH_TRACK_EVENT];
+
+export { ACTIVITY_TYPE, type Activity, type ActivityCreter, type ActivityId$1 as ActivityId, type ActivityType, type BackendActivityInput, type BackendCalendar, type BackendCalendarException, type BackendInput, type BackendLink, type BackendScheduleImpactRequests, type BackendSector, type BackendShift, type BaselinePoint, type BaselineVersion, CALENDAR_UNIT, COLUMN, CONSTRAINT_TYPE, CONSTRAINT_TYPE_TO_LABEL, CREATION_KIND, type Calendar, type CalendarId$1 as CalendarId, type CalendarUnit, type CalendarWorktime, type ChangeSet, type ColumnName, type ConstraintType, type ConstraintWarning, 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 OutputUnit, type ParsedInput, type PastedActivityInput, type PastedLinkInput, type PendingRequest, 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, applyBaselinePoints, checkNoUpdatedLinks, computeExpectedProgress, expectedProgressFromBaseline, getActiveBaseline, getUnsavedActivities, isRootParent, normalizeParentKey, parseFromBackend, recomputeAllPonderators, recomputeAllProgressRollup, willRunCriticalPath, yieldToBrowser };