# 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)
```markdown
# 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.