Problem
crates/stella-pipeline/src/management_prompt/tests.rs declares
const ALL_ROLES: [ModelCallRole; 15] = [ ... ];
and its own doc comment admits the gap:
Completeness is not compiler-checked here — that job belongs to the
exhaustive match in [management_system_block], which forces a new variant
to declare its prefix posture before this array matters.
That delegation held this time, but only by luck of ordering. When #1778 added
ModelCallRole::Research, the exhaustive match did fail the build (good) —
but the array was a separate edit that nothing would have caught had the
match not been in the same file. An array that is one push out of date makes
the family parity witness (#1855's shared-preamble check) silently test fewer
roles than it claims to, and the failure mode is a passing test, not a
failing one.
The same shape exists in crates/stella-pipeline/src/pipeline/raw_usage.rs
(management_bounds) — there the match IS exhaustive, so it is safe today, but
the pairing of "exhaustive match" + "hand-listed array" is the pattern worth
removing rather than re-auditing.
Fix direction
Make the array derived rather than written. Two options, in preference order:
- A const assertion tying the array length to the enum's variant count.
Cheapest, no new dependency. stella-protocol would expose the count (e.g.
a ModelCallRole::ALL: [Self; N] const beside the enum, which is where it
belongs — the enum's own crate owns its cardinality). The test then iterates
ModelCallRole::ALL and the array disappears entirely.
- A
strum-style derive (EnumIter/VariantArray). Adds a dependency to
stella-protocol, which is deliberately types-only and dependency-light —
so this needs the "sentence justifying a new crate" from AGENTS.md and is
probably not worth it if option 1 works.
Option 1 also serves raw_usage.rs and any future role-family witness, which
is the reason to prefer it over patching this one array.
Files
crates/stella-pipeline/src/management_prompt/tests.rs — ALL_ROLES, and
management_system_block's exhaustive match
crates/stella-pipeline/src/pipeline/raw_usage.rs — management_bounds, the
same pairing
crates/stella-protocol/src/event.rs — where ModelCallRole is defined and
where a ALL/count const would live
Verify
A witness is available and cheap: add a variant to ModelCallRole on a scratch
branch and confirm the family test fails (or the const assertion fails) without
anyone editing an array by hand. Today that edit compiles clean once the match
is updated, while the parity witness quietly stops covering the new role.
Definition of done
ALL_ROLES is gone, or provably cannot drift from the enum.
stella-protocol owns the enumeration of its own variants.
cargo test -p stella-pipeline -p stella-protocol green; make gate green.
Related
Surfaced while unbreaking main in #1975 (ModelCallRole::Research from #1778
broke the exhaustive match). #1855 is the shared-preamble work the parity
witness exists for.
Problem
crates/stella-pipeline/src/management_prompt/tests.rsdeclaresand its own doc comment admits the gap:
That delegation held this time, but only by luck of ordering. When #1778 added
ModelCallRole::Research, the exhaustivematchdid fail the build (good) —but the array was a separate edit that nothing would have caught had the
match not been in the same file. An array that is one
pushout of date makesthe family parity witness (#1855's shared-preamble check) silently test fewer
roles than it claims to, and the failure mode is a passing test, not a
failing one.
The same shape exists in
crates/stella-pipeline/src/pipeline/raw_usage.rs(
management_bounds) — there the match IS exhaustive, so it is safe today, butthe pairing of "exhaustive match" + "hand-listed array" is the pattern worth
removing rather than re-auditing.
Fix direction
Make the array derived rather than written. Two options, in preference order:
Cheapest, no new dependency.
stella-protocolwould expose the count (e.g.a
ModelCallRole::ALL: [Self; N]const beside the enum, which is where itbelongs — the enum's own crate owns its cardinality). The test then iterates
ModelCallRole::ALLand the array disappears entirely.strum-style derive (EnumIter/VariantArray). Adds a dependency tostella-protocol, which is deliberately types-only and dependency-light —so this needs the "sentence justifying a new crate" from AGENTS.md and is
probably not worth it if option 1 works.
Option 1 also serves
raw_usage.rsand any future role-family witness, whichis the reason to prefer it over patching this one array.
Files
crates/stella-pipeline/src/management_prompt/tests.rs—ALL_ROLES, andmanagement_system_block's exhaustive matchcrates/stella-pipeline/src/pipeline/raw_usage.rs—management_bounds, thesame pairing
crates/stella-protocol/src/event.rs— whereModelCallRoleis defined andwhere a
ALL/count const would liveVerify
A witness is available and cheap: add a variant to
ModelCallRoleon a scratchbranch and confirm the family test fails (or the const assertion fails) without
anyone editing an array by hand. Today that edit compiles clean once the match
is updated, while the parity witness quietly stops covering the new role.
Definition of done
ALL_ROLESis gone, or provably cannot drift from the enum.stella-protocolowns the enumeration of its own variants.cargo test -p stella-pipeline -p stella-protocolgreen;make gategreen.Related
Surfaced while unbreaking
mainin #1975 (ModelCallRole::Researchfrom #1778broke the exhaustive match). #1855 is the shared-preamble work the parity
witness exists for.