## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work.
> - Every master merge publishes an npm canary, and downstream managed
deployments consume the matching `sha-<short>-cloud` Docker image.
> - The canary image relies on the master-push `docker.yml` run, whose
single pending concurrency slot is superseded by every newer push.
> - On a busy day the image build never survives: five consecutive
canaries shipped npm packages with no cloud image on 2026-09-06, and
downstream deploys starved for ~18 hours while master kept moving.
> - The nightly and beta lanes already solve exactly this by dispatching
`docker.yml` at their tag ref after pushing it.
> - This pull request wires the canary lane into the same mechanism, so
every canary tag gets an image build no master push can supersede.
> - The benefit is that a published canary always has its images, and
downstream release resolution stops walking back to day-old builds
during busy merge windows.
## Linked Issues or Issue Description
Refs #12769 / #12855 (the earlier image-publishing incident in the same
pipeline, different failure mode).
**What happened?**
`docker.yml` serialises per ref with one pending slot (`concurrency:
docker-${{ github.ref }}`, `cancel-in-progress: false`). Master pushes
arriving faster than the ~50-minute build supersede the pending build
indefinitely. On 2026-09-06, canaries `2026.906.0-canary.1` through `.3`
(and the commits between) published to npm with no `sha-<short>-cloud`
image on GHCR — the Docker run list shows `cancelled, cancelled,
cancelled` for their commits. Downstream managed rollouts correctly
refused to deploy image-less canaries and pinned at `canary.0` for ~18
hours.
**Expected behavior**
Every published canary has its Docker images. A busy merge window must
not be able to prevent image publication for tagged releases.
**Steps to reproduce**
1. Merge to master more often than the Docker build takes to complete,
for several hours.
2. Observe npm canaries advancing while every `Docker` run for their
commits completes `cancelled`.
3. Observe `ghcr.io/paperclipai/paperclip:sha-<short>-cloud` returning
404 for each of those canaries.
**Paperclip version or commit**
Master at `83987210` (diagnosis time); the starved canaries were
`2026.906.0-canary.1`–`.3`.
**Deployment mode**
GitHub Actions release + image pipeline; consumed by managed cloud
deployments.
## What Changed
- `.github/workflows/release.yml`, `publish_canary` job:
- New step after "Push canary tag": dispatch `docker.yml` at
`refs/tags/canary/v<version>` — identical to the nightly and beta lanes'
existing step, including the step-summary note. The dispatched run keys
its concurrency off the tag ref, so master pushes cannot supersede it,
and `docker.yml`'s `type=sha` mapping publishes `sha-<short>` /
`sha-<short>-cloud` for any ref.
- The job gains `actions: write`, mirroring `publish_nightly`.
- No `docker.yml` changes: it already accepts `workflow_dispatch` for
exactly this pattern.
- No dry-run guard needed: `publish_canary` runs only on `push` events,
so the `dry_run` dispatch input cannot reach it.
## Verification
- YAML lints clean; the step is a line-for-line mirror of the proven
nightly-lane step (tag source swapped for the job's existing
`canary_tag` output).
- The concurrency claim is docker.yml's own documented behavior: groups
are per-ref, and a tag ref is distinct from `refs/heads/master`.
- Not run: a live canary publish — the next master merge after this
lands exercises it end to end; the worst case (double build for a canary
whose master-push run also survives) is benign, since both runs push
identical content-addressed tags.
## Risks
- Low. Roughly one additional Docker build per canary on busy days (on
quiet days the master-push run and the dispatched run both execute —
duplicate work, identical images, no conflict since the sha tags are
content-equivalent for the same commit).
- `actions: write` on `publish_canary` matches the grant
`publish_nightly` already carries for the same purpose.
> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.
## Model Used
Claude Fable 5 (Anthropic, model id `claude-fable-5`), extended
thinking, agentic tool use in Claude Code: GHCR manifest probing,
Actions run-list forensics, and workflow-lane comparison.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass (workflow-only change; YAML
linted; no test harness targets release.yml)
- [x] I have added or updated tests where applicable (not applicable —
CI wiring mirroring an existing proven lane)
- [x] I have updated relevant documentation to reflect my changes (the
step's inline comment documents the invariant)
- [x] I have considered and documented the risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge
8f099c3f83