u_schedule/lib.rs
1//! A scheduling framework.
2//!
3//! Provides domain models, constraints, validation, dispatching rules,
4//! and a greedy scheduler for scheduling problems. This crate defines
5//! the scheduling domain language — metaheuristic algorithms (GA, SA, CP)
6//! are provided by `u-metaheur` at a lower layer.
7//!
8//! # Modules
9//!
10//! - **`models`**: Domain types — `Task`, `Activity`, `Resource`, `Schedule`,
11//! `Assignment`, `Calendar`, `Constraint`, `TransitionMatrix`
12//! - **`validation`**: Input integrity checks (duplicate IDs, DAG cycles, resource refs)
13//! - **`dispatching`**: Priority dispatching rules (SPT, EDD, ATC, etc.) and rule engine
14//! - **`scheduler`**: Greedy scheduler and KPI evaluation
15//! - **`ga`**: GA-based scheduling with OSV/MAV encoding
16//! - **`cp`**: CP-based scheduling formulation
17//!
18//! # Architecture
19//!
20//! This crate depends on `u-metaheur` and `u-numflow`, and contains only scheduling
21//! domain logic — no nesting, packing, or manufacturing concepts.
22//!
23//! # Solver enforcement matrix (0.4.0)
24//!
25//! Model expressiveness and solver enforcement are distinct. What each
26//! execution path actually enforces:
27//!
28//! | Feature | `SimpleScheduler` | GA decode | CP builder |
29//! |---|---|---|---|
30//! | Fixed-assignment seeding (pin) [^pin-setup] | ✅ | ❌ | ❌ |
31//! | Multi-requirement simultaneous hold | ✅ | ❌ (single resource per activity) | ❌ (first candidate) |
32//! | Resource calendar | ✅ | ❌ | ❌ |
33//! | Capacity > 1 | ✅ | ❌ | ❌ |
34//! | Setup/teardown duration components | ✅ | ❌ | ❌ |
35//! | `TransitionMatrix` sequence-dependent setup | ✅ | ✅ | ❌ |
36//! | `Constraint::{TimeWindow, Synchronize}` | validated only | validated only | ❌ (skipped) |
37//! | `Constraint::TransitionCost` | ❌ (unsupported) | ❌ | ❌ |
38//!
39//! Every [`scheduler::SimpleScheduler`] result self-annotates via
40//! [`scheduler::check_schedule`], so `Schedule::is_valid()` is
41//! meaningful on that path. Run the checker manually on GA/CP output to
42//! obtain honest violation reports.
43//!
44//! [^pin-setup]: Pins are **opaque reservations** — they never update
45//! `last_category`, so the next `TransitionMatrix`-governed activity
46//! placed on the same resource computes its changeover against the
47//! category that was current *before* the pin, understating the true
48//! setup from the pin's task. See
49//! [`scheduler::SimpleScheduler::with_fixed_assignments`] for the full
50//! writeup. **Known limitation, not yet addressed**:
51//! changeover-aware pin accounting — treat a pin as a `last_category`
52//! update so the following activity's setup reflects a transition *from*
53//! the pinned task's category.
54//!
55//! # References
56//!
57//! - Pinedo (2016), "Scheduling: Theory, Algorithms, and Systems"
58//! - Brucker (2007), "Scheduling Algorithms"
59//! - Blazewicz et al. (2019), "Handbook on Scheduling"
60//! - Haupt (1989), "A Survey of Priority Rule-Based Scheduling"
61//! - Kolisch & Hartmann (1999), "Heuristic algorithms for the RCPSP" (serial SGS)
62
63pub mod cp;
64pub mod dispatching;
65pub mod ga;
66pub mod models;
67pub mod scheduler;
68pub mod validation;
69
70#[cfg(feature = "wasm")]
71pub mod wasm;