Consolidate the synthetic walkforward select->optimize dispatch onto the campaign executor #225

New Issue

2026-07-10T03:06:10+02:00

Brummel commented

2026-07-10 03:06:10 +02:00

Surfaced by the #215 cycle-close architect review (2026-07-10). #215 taught the
campaign walk_forward executor to honour a plateau select on the per-window
in-sample winner, with a gate-lattice soundness guard in the campaign preflight
(plateau is refused when a gate precedes the wf stage, because a gate filters
survivors below the full parameter grid). That leaves plateau-in-wf logic with
two live homes:

the campaign executor run_walk_forward_stage → select_sweep_winner
(crates/aura-campaign/src/exec.rs), gated by the campaign preflight;
the synthetic (non---real) walkforward path
blueprint_walkforward_family → select_winner → optimize_plateau
(crates/aura-cli/src/main.rs:740-746), which has accepted plateau since #173
and carries no gate-lattice guard (moot today — the synthetic path has no gate
stages — but it is a second, independent select→optimise dispatch).

Direction (not prescriptive)

Consolidate the synthetic walkforward path onto the one campaign executor (the
dissolved-verb direction, #220), so plateau-in-wf — and its lattice-soundness
guard — has a single home. Until then, a change to the plateau/argmax winner
dispatch must be mirrored in both places or they drift.

depends on: nothing (a consolidation, not a blocker)
context: #215 cycle-close architect debt item [medium]; pre-existing (the
synthetic path predates #215), correctly scoped out of #215.

Surfaced by the #215 cycle-close architect review (2026-07-10). #215 taught the **campaign** walk_forward executor to honour a plateau select on the per-window in-sample winner, with a gate-lattice soundness guard in the campaign preflight (plateau is refused when a gate precedes the wf stage, because a gate filters survivors below the full parameter grid). That leaves plateau-in-wf logic with **two live homes**: - the campaign executor `run_walk_forward_stage` → `select_sweep_winner` (`crates/aura-campaign/src/exec.rs`), gated by the campaign preflight; - the synthetic (non-`--real`) walkforward path `blueprint_walkforward_family` → `select_winner` → `optimize_plateau` (`crates/aura-cli/src/main.rs:740-746`), which has accepted plateau since #173 and carries no gate-lattice guard (moot today — the synthetic path has no gate stages — but it is a second, independent select→optimise dispatch). ## Direction (not prescriptive) Consolidate the synthetic walkforward path onto the one campaign executor (the dissolved-verb direction, #220), so plateau-in-wf — and its lattice-soundness guard — has a single home. Until then, a change to the plateau/argmax winner dispatch must be mirrored in both places or they drift. - depends on: nothing (a consolidation, not a blocker) - context: #215 cycle-close architect debt item [medium]; pre-existing (the synthetic path predates #215), correctly scoped out of #215.

Brummel added the idea label 2026-07-10 03:06:10 +02:00

claude commented

2026-07-21 10:36:40 +02:00

Re-anchoring after cycle #295 (aura-runner/aura-measurement extraction, merged 4ed6455): the synthetic walk-forward path this issue targets moved out of the CLI binary. blueprint_walkforward_family now lives at crates/aura-runner/src/family.rs:514-573, calling select_winner (crates/aura-runner/src/family.rs:293-309, dispatching to optimize_deflated/optimize_plateau). crates/aura-cli/src/main.rs now only calls it as a library function (line 912); the old main.rs:740-746 reference is stale.

The campaign-side home is unchanged: run_walk_forward_stage (crates/aura-campaign/src/exec.rs:990) still calls the private select_sweep_winner (crates/aura-campaign/src/exec.rs:900-937), still gated by the campaign preflight's gate-lattice guard. The duplication this issue flags is still live, and the two dispatch functions have already diverged further: select_sweep_winner takes (SelectRule, deflate: bool, seed: u64) with an Argmax-without-deflation arm, while select_winner takes a Selection enum with no deflate parameter (its Argmax arm always deflates). A change to one no longer trivially mirrors onto the other.

The #295 extraction removes the structural obstacle that made consolidation awkward: the synthetic path is no longer embedded in the aura-cli binary. crates/aura-vocabulary/tests/c28_layering.rs already permits aura-runner to depend on aura-campaign (aura-runner sits in the assembly position directly above aura-campaign), and aura-runner already carries that dependency edge for other reasons. Consolidating select_winner onto aura-campaign's select_sweep_winner (or a shared primitive both call) is now reachable without a new C28 edge. The decided document-first direction (#300) does not bear on this issue -- #225 is internal dispatch de-duplication between two library crates, not CLI flag surface, so it is not absorbed by #300's flag-to-document migration.

Direction stands: consolidate the two select->optimize dispatch homes (crates/aura-runner/src/family.rs::select_winner and crates/aura-campaign/src/exec.rs::select_sweep_winner) so the plateau/argmax winner logic, and the gate-lattice soundness guard, have one home.

Re-anchoring after cycle #295 (aura-runner/aura-measurement extraction, merged 4ed6455): the synthetic walk-forward path this issue targets moved out of the CLI binary. `blueprint_walkforward_family` now lives at `crates/aura-runner/src/family.rs:514-573`, calling `select_winner` (`crates/aura-runner/src/family.rs:293-309`, dispatching to `optimize_deflated`/`optimize_plateau`). `crates/aura-cli/src/main.rs` now only calls it as a library function (line 912); the old `main.rs:740-746` reference is stale. The campaign-side home is unchanged: `run_walk_forward_stage` (`crates/aura-campaign/src/exec.rs:990`) still calls the private `select_sweep_winner` (`crates/aura-campaign/src/exec.rs:900-937`), still gated by the campaign preflight's gate-lattice guard. The duplication this issue flags is still live, and the two dispatch functions have already diverged further: `select_sweep_winner` takes `(SelectRule, deflate: bool, seed: u64)` with an Argmax-without-deflation arm, while `select_winner` takes a `Selection` enum with no deflate parameter (its Argmax arm always deflates). A change to one no longer trivially mirrors onto the other. The #295 extraction removes the structural obstacle that made consolidation awkward: the synthetic path is no longer embedded in the `aura-cli` binary. `crates/aura-vocabulary/tests/c28_layering.rs` already permits `aura-runner` to depend on `aura-campaign` (aura-runner sits in the assembly position directly above aura-campaign), and `aura-runner` already carries that dependency edge for other reasons. Consolidating `select_winner` onto `aura-campaign`'s `select_sweep_winner` (or a shared primitive both call) is now reachable without a new C28 edge. The decided document-first direction (#300) does not bear on this issue -- #225 is internal dispatch de-duplication between two library crates, not CLI flag surface, so it is not absorbed by #300's flag-to-document migration. Direction stands: consolidate the two select->optimize dispatch homes (`crates/aura-runner/src/family.rs::select_winner` and `crates/aura-campaign/src/exec.rs::select_sweep_winner`) so the plateau/argmax winner logic, and the gate-lattice soundness guard, have one home.

claude referenced this issue

2026-07-21 10:53:09 +02:00

Complete the document-first migration: the run quintet's residual flags become document vocabulary #300

claude removed the idea label 2026-07-21 15:11:22 +02:00

claude commented

2026-07-21 15:11:22 +02:00

idea label removed (ratified 2026-07-21, idea-cull round): since #295 removed the structural obstacle (aura-runner may depend on aura-campaign), consolidating select_sweep_winner/select_winner is a concrete reachable task, not a droppable idea.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/Aura#225