Bryan Helmkamp ac5a60672f refactor(types): stage 6.5 promote v2 types to settings top level ... Stage 6.5 can't flatten the `settings::v2::*` module tree onto `settings::*` files wholesale because the v2 submodules (`project.rs`, `run.rs`, `server.rs`) share filenames with the legacy flat type modules that are still required by the OpenAPI legacy `ServerSettings` response path (Stage 6.3 / 6.6 deletes them). As the feasible piece of Stage 6.5 work: - Re-export the v2 top-level type aliases from `fabro_types::settings` so consumers can write `fabro_types::settings::SettingsFile`, `fabro_types::settings::InterpString`, `fabro_types::settings::Duration`, etc. without the `::v2::` prefix. - The re-export covers the whole public v2 surface: `{CURRENT_VERSION, CliLayer, Duration, FeaturesLayer, InterpString, ModelRef, ParseDurationError, ParseError, ParseModelRefError, ParseSizeError, ProjectLayer, Provenance, ResolveEnvError, Resolved, ResolvedModelRef, RunLayer, SchemaVersion, ServerLayer, SettingsFile, Size, SpliceArray, SpliceArrayError, VersionError, WorkflowLayer, parse_settings_file, validate_version}`. The `v2` module itself stays in place to host the submodule tree (accessors, to_runtime, run::*, cli::*, server::*, interp, etc.) until Stage 6.3 finishes deleting the conflicting legacy files, at which point the v2/ directory can be promoted to replace them. Build, clippy, fmt, and 3756 / 3756 tests pass. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>		2026-04-09 16:33:41 -04:00
..
crates	refactor(types): stage 6.5 promote v2 types to settings top level	2026-04-09 16:33:41 -04:00
packages/fabro-api-client	feat(artifacts): finish object-backed artifact uploads	2026-04-07 16:56:37 -04:00