Summary
agentic:provider-canary and agentic:rollout-canary are AI provider/model rollout canaries
— they canary a model change across lanes. They have nothing to do with release canaries,
which publish a pre-release package to JSR to smoke-test a cut.
Two unrelated concepts, one word, in the same deno task agentic:* namespace.
Why this is worth fixing now rather than later
It has been survivable so far because release canaries had no cadence and no tooling of their own
— there was nothing to collide with. The milestone/canary release system changes that: it
introduces canary trigger points, canary labels on issues and PRs, and canary steps inside a
milestone run. At that point an orchestrator reading agentic:provider-canary in a task list has
a genuine reason to believe it is the release canary command.
The cost of the collision lands on exactly the reader least equipped to catch it: a fresh
orchestrator agent, working from task names, mid-milestone.
Proposal
Rename the AI-rollout pair to say what they actually canary:
| Today |
Proposed |
agentic:provider-canary |
agentic:model-rollout-canary |
agentic:rollout-canary |
agentic:model-rollout-verify (name to be settled against its real behaviour) |
Reserve the bare word canary in the agentic: namespace for release canaries, matching
.agents/skills/netscript-release, which is where a reader will expect it.
Check before renaming: whether either task name appears in .llm/harness/, .agents/skills/,
CI workflows, or generated docs, and alias rather than break if any external reference exists.
Acceptance
Provenance
Raised by the 0.0.4 orchestrator while scoping the milestone/canary release system, and confirmed
during wave-four orchestration. Filed separately because it is a rename with its own blast radius
and should not be buried inside the release-system work.
Summary
agentic:provider-canaryandagentic:rollout-canaryare AI provider/model rollout canaries— they canary a model change across lanes. They have nothing to do with release canaries,
which publish a pre-release package to JSR to smoke-test a cut.
Two unrelated concepts, one word, in the same
deno task agentic:*namespace.Why this is worth fixing now rather than later
It has been survivable so far because release canaries had no cadence and no tooling of their own
— there was nothing to collide with. The milestone/canary release system changes that: it
introduces canary trigger points, canary labels on issues and PRs, and canary steps inside a
milestone run. At that point an orchestrator reading
agentic:provider-canaryin a task list hasa genuine reason to believe it is the release canary command.
The cost of the collision lands on exactly the reader least equipped to catch it: a fresh
orchestrator agent, working from task names, mid-milestone.
Proposal
Rename the AI-rollout pair to say what they actually canary:
agentic:provider-canaryagentic:model-rollout-canaryagentic:rollout-canaryagentic:model-rollout-verify(name to be settled against its real behaviour)Reserve the bare word canary in the
agentic:namespace for release canaries, matching.agents/skills/netscript-release, which is where a reader will expect it.Check before renaming: whether either task name appears in
.llm/harness/,.agents/skills/,CI workflows, or generated docs, and alias rather than break if any external reference exists.
Acceptance
canary
.llm/tools/agentic/README.mdand the harness tooling index state which is which, in oneline each
Provenance
Raised by the 0.0.4 orchestrator while scoping the milestone/canary release system, and confirmed
during wave-four orchestration. Filed separately because it is a rename with its own blast radius
and should not be buried inside the release-system work.