Files
cc-ci-orchestrator/cc-ci-plan/upstream
autonomic-bot 3307bdb0fe advisory-scan: separate benign source absence from real failures; fix pgautoupgrade URLs
Two refinements found by running the scan across all 14 recipes of the 2026-08-07 run:

1. A repo with no advisory feed returns HTTP 404 on /security-advisories (e.g. the
   pgautoupgrade sidecar image). That is a BENIGN ABSENCE, not a failed check.
   Likewise registry entries that are TEMPLATE urls for humans
   (…/changelog/v<VERSION>/, …/<vX.Y.Z>/…) are documentation, not fetchable.
   Counting either as a failure pushed most recipes to '?', which would make the
   unknown-vs-clean distinction meaningless again — the exact signal the ? exists to
   preserve. Both are now recorded in sources_benign; only genuine errors (rate
   limit, network, 5xx, wrong URL) land in sources_failed.

2. upstream/*.md pointed at github.com/pgautoupgrade/pgautoupgrade, which 404s —
   the repo is pgautoupgrade/docker-pgautoupgrade. Corrected in n8n, lasuite-docs,
   lasuite-drive, lasuite-meet. A 404ing registry URL means we were not scanning a
   source we believed we were.

Effect on the 2026-08-07 data: recipes with genuine failed sources 5 -> 3 (the
remainder are really unreachable vendor pages). CVE counts unchanged where they
were already sound: discourse 130, gitea 2, plausible 1.
2026-08-10 18:45:45 +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.