Symposium & Dial9: Point the dial9 entry at the crates projects actually depend on

[Fluzko]

Part of symposium-dev/symposium#294.

Depends on: the dial9 release carrying dial9-rs/dial9#917. Landing this first leaves projects at or above the floor with no skills at all.

What happens

A project pinned to dial9-tokio-telemetry 0.3.15 currently receives dial9-viewer 0.5.0's skills, four of which did not exist on the 0.3 line. The entry chains to dial9-viewer, which is not in that project's dependency graph, so Symposium cannot apply the project's pin and resolves to the newest release instead.

The entry needs to point at the crates projects actually declare: one edge per serving crate, each gating on the crate it serves, plus a fallback edge for projects too old to have the skills yet. The three are mutually exclusive, so no skill installs twice.

name = "dial9"
depends-on = ["dial9-tokio-telemetry", "dial9", "dial9-viewer"]

# serving edge
[[plugins]]
predicates = ["depends-on(dial9>=X.Y)"]
source.cargo = "dial9"

# serving edge
[[plugins]]
predicates = ["depends-on(dial9-tokio-telemetry>=X.Y)", "not(depends-on(dial9>=X.Y))"]
source.cargo = "dial9-tokio-telemetry"

# fallback for anything below the floor
[[plugins]]
predicates = ["not(depends-on(dial9>=X.Y))", "not(depends-on(dial9-tokio-telemetry>=X.Y))"]
source.cargo = "dial9-viewer"

X.Y is the first dial9 release carrying the skills; it is not known yet, so it stays a placeholder here until that release is cut. The two serving crates are released in lockstep today, so one floor covers both; if that changes, they need separate floors.

Two things about that shape are load-bearing

The version floor is not decoration. Gating on presence alone means a project pinned below the floor matches a serving edge, lands on a crate that does not carry the skills yet, and receives nothing.

Write the fallback as a negation, never as an upper bound. A >=X / <X pair is not exhaustive: a project on a prerelease satisfies neither side. Measured with the upper-bound form, a project pinned to a prerelease matched no edge and installed zero skills, exiting zero without naming the problem.

How to see it

# needs: cargo-agents, network, and an isolated SYMPOSIUM_HOME. Create the directories
# yourself; nothing below does.
#
# mkdir -p /tmp/iso /tmp/reg/dial9
# /tmp/iso/config.toml: the builtin registries MUST be off, or the upstream dial9
# entry supplies skills too and the result proves nothing:
#
#   [defaults]
#   symposium-recommendations = false
#   user-plugins = false
#
#   [[agent]]
#   name = "claude"
#
#   [[registry]]
#   name = "local"
#   path = "/tmp/reg"
#   auto-update = false
#
# and put the entry above at /tmp/reg/dial9/SYMPOSIUM.toml

# sweep the gate against published versions, naming the crate per row: prerelease
# versions differ between these crates, and dial9-tokio-telemetry has no 0.5.0-rc1.
#   dial9-tokio-telemetry = "=0.3.15"       below the floor  -> fallback edge
#   dial9-tokio-telemetry = "=0.5.0"        at the floor     -> serving edge
#   dial9-tokio-telemetry = "=0.5.0-rc2.1"  prerelease       -> must still get skills
SYMPOSIUM_HOME=/tmp/iso cargo agents sync
SYMPOSIUM_HOME=/tmp/iso cargo agents status
ls .claude/skills | grep -c dial9

Run today, before dial9-rs/dial9#917 ships, the at-the-floor rows install zero skills, because the serving crates do not carry any yet. That is expected, not a broken entry.

Done when

• A project on or above the floor receives skills from the crate it declares.
• A project on a prerelease receives skills rather than nothing.
• No project receives any skill twice.
• Verified for a project declaring dial9, and separately for one declaring only dial9-tokio-telemetry.
• A project pinned below the floor still receives skills through the fallback, and the entry records that those skills are newer than the project's own version. That skew is the accepted cost of not leaving old pins with nothing, and should be a written decision.