In guidance_constants.py, we currently have two StrEnum classes with identical members:
class GuidanceType(StrEnum):
FK_STEERING = "fk_steering"
PURE_GUIDANCE = "pure_guidance"
LATENT_OPT = "latent_opt"
class TrajectoryScalers(StrEnum):
PURE_GUIDANCE = "pure_guidance"
FK_STEERING = "fk_steering"
LATENT_OPT = "latent_opt"These appear to represent the same concept. We should investigate:
Where each enum is used across the codebase (CLI, run_guidance(), TOML configs, tests, etc.)
Whether there is a meaningful semantic distinction between "guidance type" and "trajectory scaler" that justifies keeping both
If no meaningful distinction exists, consolidate to a single enum (likely GuidanceType, since it is more general) and update all references
The goal is to remove the redundancy and prevent future divergence if new trajectory scalers are added and GuidanceType is not updated (or vice versa).
In guidance_constants.py, we currently have two StrEnum classes with identical members:
These appear to represent the same concept. We should investigate:
Where each enum is used across the codebase (CLI, run_guidance(), TOML configs, tests, etc.)
Whether there is a meaningful semantic distinction between "guidance type" and "trajectory scaler" that justifies keeping both
If no meaningful distinction exists, consolidate to a single enum (likely GuidanceType, since it is more general) and update all references
The goal is to remove the redundancy and prevent future divergence if new trajectory scalers are added and GuidanceType is not updated (or vice versa).