From review of #460 (r3615872544). Confirmed still valid at the end-of-train tip. Target: videre-macros / videre-sdk (L2) and cow-venue (L3).
A venue's registered id has two unenforced sources:
shepherd/crates/cow-venue/module.toml declares [module] name = "cow", and its own comment states "The manifest name is the venue id the registry installs". #[videre_sdk::venue] reads this manifest.
shepherd/crates/cow-venue/src/client.rs hand-types the same id: impl Venue for CowVenue { const ID: VenueId = VenueId::from_static("cow"); }.
Nothing ties the two. Rename [module] name, or register a second deployment under a different id, and CowVenue::ID still compiles while routing to an id that no longer resolves. The failure is a runtime routing fault, not a compile error. The Venue trait doc already states ID is "the id the venue's adapter registers under", so the invariant is documented but unenforced.
Accuracy note on the review's framing: at the tip both sources live in the same crate (shepherd/crates/cow-venue/), in adjacent files, not "a completely separate crate". That narrows the drift window but does not close it, because there is still no compile-time link.
Options
- Cheapest, keeps the current API: have
#[videre_sdk::venue] emit a compile-time assertion that the crate's Venue::ID equals the manifest-derived name. Drift becomes a compile error and Venue::ID stays explicit and greppable.
- Stronger: have the macro emit the id const (or a marker type) that the keeper side imports, so the manifest is the single source and nothing is hand-typed.
Timing
Prefer pre-cleave. The fix spans videre-macros/videre-sdk (L2) and cow-venue (L3), so it is one monorepo PR now versus a coordinated cross-repo change after the split.
Acceptance criteria
- A mismatch between a venue adapter's
[module] name and its crate's Venue::ID fails at compile time, or Venue::ID is generated from the manifest.
- No hand-typed venue id can silently diverge from the id its adapter registers under.
A venue's registered id has two unenforced sources:
shepherd/crates/cow-venue/module.tomldeclares[module] name = "cow", and its own comment states "The manifest name is the venue id the registry installs".#[videre_sdk::venue]reads this manifest.shepherd/crates/cow-venue/src/client.rshand-types the same id:impl Venue for CowVenue { const ID: VenueId = VenueId::from_static("cow"); }.Nothing ties the two. Rename
[module] name, or register a second deployment under a different id, andCowVenue::IDstill compiles while routing to an id that no longer resolves. The failure is a runtime routing fault, not a compile error. TheVenuetrait doc already statesIDis "the id the venue's adapter registers under", so the invariant is documented but unenforced.Accuracy note on the review's framing: at the tip both sources live in the same crate (
shepherd/crates/cow-venue/), in adjacent files, not "a completely separate crate". That narrows the drift window but does not close it, because there is still no compile-time link.Options
#[videre_sdk::venue]emit a compile-time assertion that the crate'sVenue::IDequals the manifest-derived name. Drift becomes a compile error andVenue::IDstays explicit and greppable.Timing
Prefer pre-cleave. The fix spans
videre-macros/videre-sdk(L2) andcow-venue(L3), so it is one monorepo PR now versus a coordinated cross-repo change after the split.Acceptance criteria
[module] nameand its crate'sVenue::IDfails at compile time, orVenue::IDis generated from the manifest.