Files
cc-ci-orchestrator/cc-ci-plan/upstream
autonomic-bot 318d09bdab advisory-scan: eliminate spurious '?' — url punctuation, stale URL, and ? semantics
The 2026-08-07 regeneration rendered '?' for 5 of 21 recipes. '?' is meant to be a
rare 'we tried and could not tell'; at that rate it is indistinguishable from noise
and hides the real unknowns. Three causes, none of them genuine uncertainty:

1. URL EXTRACTION BUG (mine). The registry is markdown, so urls appear inside
   `backticks` and 'quotes'. The extractor captured the trailing punctuation, so
   it fetched https://docs.n8n.io/release-notes/` and https://git.autonomic.zone'`
   — both 404 on the malformed url, both 200 when clean. Trailing markdown
   punctuation is now stripped. Fixed immich + n8n.
2. STALE REGISTRY URL. mattermost-lts pointed at
   docs.mattermost.com/about/mattermost-changelog.html, which 404s; the page moved
   to /deploy/. Corrected (same class as the pgautoupgrade fix).
3. WRONG SEMANTICS FOR 'NO UPGRADE'. lasuite-docs and custom-html-tiny were
   up-to-date this run, so no scan block existed and the report fell back to '?'.
   But a recipe with no upgrade has nothing an upgrade could have fixed — that is
   0, not unknown. The report skill now says so explicitly, restricts '?' to scans
   that RAN and reported genuinely failed sources, states that benign notes
   (no-advisories-published / template URL) never trigger '?', and instructs that
   many '?' is itself a bug to raise in the Addendum.

Result across all 16 scanned recipes of that run: 0 failed sources (was 5).
Counts also improved with the classifier fix: discourse 130->133, keycloak ->7.
2026-08-10 20:23:10 +00:00
..

Upstream release-notes registry

Per-recipe maps of where each image's release notes / changelog live. This is the cc-ci analog of recipe-maintainer's recipe-info/<recipe>/upstream.md: the /recipe-upgrade skill reads cc-ci-plan/upstream/<recipe>.md so it doesn't have to rediscover the upstream source for every image on every weekly run — discover once, persist, reuse.

How /recipe-upgrade uses it (step 1)

  1. Read cc-ci-plan/upstream/<recipe>.md.
  2. If it's missing, or an image in the recipe's compose.yml isn't covered (new/renamed service), discover the upstream project + releases page for each uncovered image (WebSearch the image → its GitHub/source repo → its releases/changelog page), then write/update this file and commit it (git -C /srv/cc-ci-orch add cc-ci-plan/upstream/<recipe>.md && commit && push).
  3. Fetch the release notes from these URLs between the current → target version of each service.

Format (one file per recipe)

# Upstream sources — <recipe>

| service | image | source repo | releases / changelog |
|---------|-------|-------------|----------------------|
| app     | cryptpad/cryptpad | https://github.com/cryptpad/cryptpad | https://github.com/cryptpad/cryptpad/releases |
| web     | nginx             | https://github.com/nginx/nginx       | https://nginx.org/en/CHANGES |

## Standing notes
- <recipe-specific upgrade gotchas worth remembering between runs, e.g. "n8n: postgres volume path
  changed from /var/lib/postgresql/data to /var/lib/postgresql in 2.2x">

Keep URLs canonical (the project's own releases/CHANGES page, not a mirror). Add a Standing notes section for migration gotchas you only want to learn once.