RevoGrid

Appearance

Scheduler Engine Baseline Behavior ​

This document captures implementation-truth behavior for the scheduler engine modules.

Scheduling Modes ​

  • scheduleFrom: 'project-start' performs a forward (ASAP-style) pass in topological order.
  • scheduleFrom: 'project-finish' performs a backward (ALAP-style) pass in reverse topological order from a finish anchor.

Example:

  • Input: A (2d) -> B (1d) FS, project-start, A.start=2026-04-01, B.start=2026-04-01.
  • Outcome: B.start is shifted to the earliest dependency-valid date after A.end.

Dependency Handling ​

  • Forward mode computes required start dates from incoming dependencies.
  • Backward mode computes latest allowed starts from outgoing dependencies.
  • Lag is normalized to integer days and applied by lag-calendar options.

Example:

  • Input: FS dependency with lagDays: 1 from A to B.
  • Outcome: B cannot start until one extra lag day after A finishes.

Constraint Precedence and Windows ​

  • must-start-on and must-finish-on are hard constraints.
  • Other constraints form earliest/latest windows and can produce typed conflicts when windows do not overlap dependency bounds.
  • Auto dependency warning/clamp behavior follows autoDependencyViolationBehavior.

Example:

  • Input: dependency requires 2026-04-10, task has start-no-later-than: 2026-04-08.
  • Outcome: conflict is emitted because dependency and constraint bounds do not overlap.

Manual Scheduling Diagnostics ​

  • Manual tasks keep authored dates; engine does not auto-shift them for dependency compliance.
  • Violations are diagnostic conflicts controlled by manualDependencyViolationBehavior.
  • In ALAP mode, manual tasks are validated against successor-driven latest-start requirements.

Example:

  • Input: manual predecessor starts after successor-driven latest start in project-finish mode.
  • Outcome: manual-dependency-violation is emitted; date stays authored.

Resource Leveling Behavior and Limits ​

  • Auto leveling runs only for project-start schedules.
  • Leveling shifts scheduler-owned tasks (not manual/actual/must-* constrained) by delay.
  • Capacity checks use cumulative concurrent assignment load (not pairwise only).
  • With resourceLevelingWithinSlack, shifts are limited by total slack.

Example:

  • Input: three overlapping tasks at 40% each on a 100% resource.
  • Outcome: one task is delayed so overlapping load does not exceed 100%.

Critical Path and Slack ​

  • Critical path is computed from late-window propagation from project finish.
  • totalSlackDays = max(0, diffInDays(startDate, lateStartDate)).
  • isCritical is true when totalSlackDays === 0.

Example:

  • Input: single chain with no parallel float.
  • Outcome: all chain tasks have zero slack and are critical.

Split Ranges ​

  • Split ranges extend scheduled finish in forward calculations.
  • Latest-window backward calculations account for split pause ranges.
  • This affects late dates, slack, and critical flags.

Example:

  • Input: durationDays=2, split covering two days in task span.
  • Outcome: scheduled finish and latest-window start/end reflect the split pause.

Known Invariants (Refactor Guardrails) ​

  • Public API remains createSchedulerEngine() and existing scheduler result/conflict contracts.
  • Manual tasks are diagnostic-only for dependency violations (no automatic movement).
  • Auto resource leveling does not run in project-finish mode.
  • Finish-based constraints are validated against resolved end dates.
  • Split-aware date math must be used where late windows are derived from end dates.