Why: gitea 1.27.1 fixed CVE-2026-60004 + CVE-2026-59774 (both CVSS 9.8). The
2026-08-03 report printed gitea's CVE count as '1', the 2026-08-07 report as
'none'. Cause chain: the upgrade subagent read the GitHub release notes, which
name NEITHER cve (they are announced only in the vendor blog's security section),
so it recorded one unrelated minor item; the report then derived security content
from those notes plus model knowledge, and the model's training predates the CVEs.
Nothing in the pipeline ever queried an advisory source.
cc-ci-plan/advisory-scan.py — deterministic, per recipe, per upgrade window:
1. GitHub Security Advisories API for every source repo in the upstream registry.
PRIMARY: CVE + GHSA + severity + vulnerable/patched ranges, so 'fixed by THIS
upgrade' is computed. Needs no new per-recipe config (134 registry URLs are
already github.com).
2. Vendor release/security pages — every registry URL, fetched + regex-scanned.
This is the source that actually had the gitea CVEs.
3. OSV where a package mapping exists — supplementary.
Each source reports its own status so 'checked, none found' is never confused with
'not checked'. Source selection was measured, not assumed: for these two CVEs OSV
404'd and NVD's API had them by neither CPE, id, nor keyword — advisory DBs lag the
vendor, hence 1+2 lead.
Wiring is strictly ADDITIVE:
- /recipe-upgrade gains step 2a: run the scan, paste the block into the per-recipe
log, and report the UNION of it and the existing release-note reading. The scan
may never lower a count established by reading.
- /recipe-report treats the block as a FURTHER source, prefers its advisory ids /
severities / fixed-in versions for citation, and must render '?' (not 'none')
when a scan is absent or has failed sources — the false-clean 'none' is exactly
what happened on 2026-08-07.
- upstream/gitea.md records blog.gitea.com as the security-announcement URL.
Verified on the real regression: 1.27.0 -> 1.27.1 now yields exactly the 2 missed
criticals with their GHSA ids; the wider 1.26.2 -> 1.27.1 window yields 62.
cc-ci-orchestrator
Orchestrator workspace for building the cc-ci Co-op Cloud recipe CI server. The plan, launch
tooling, and loop prompts live in cc-ci-plan/; see AGENTS.md for the
roles and operating model. Secrets (.testenv) are gitignored — never commit them.
Run the orchestrator in tmux (survives disconnects + closing your laptop)
Keep this supervising session alive on the host with tmux, and use --remote-control so you can
watch/steer it from claude.ai/code (or the mobile app).
# 0. Exit any running orchestrator session first — a conversation can't be resumed while it's live:
# /exit (inside Claude) or Ctrl-D
# 1. Start a detachable tmux session on this host
tmux new -s orchestrator
# 2. Inside tmux, resume the orchestrator conversation WITH remote control:
claude --resume autonomous-orchestrator \
--remote-control "autonomous-orchestrator" \
--dangerously-skip-permissions
# - If name-resume opens a picker instead of resuming directly, choose "autonomous-orchestrator".
# - Or resume by the stable session id (more deterministic in a fresh pane):
# claude --resume 34a80a99-b37e-4809-b8da-ccc9fafe785e \
# --remote-control "autonomous-orchestrator" --dangerously-skip-permissions
# 3. Detach — the process keeps running: press Ctrl-b, then d
Reconnect later
- On this host:
tmux attach -t orchestrator - From anywhere: claude.ai/code → the
autonomous-orchestratorsession
Why it survives: tmux keeps the claude process alive across SSH disconnects and your laptop
closing; remote-control runs outbound from this host to Anthropic, so it stays connected
regardless of the viewer. After a host reboot, re-run steps 1–2.
Two different "names":
--resume <name|id>selects the conversation to restore (shown in the/resumepicker); the--remote-control "<name>"value is only the web display label and resumes nothing. Resuming reuses the same session id each time (stays34a8…) — don't pass--fork-sessionunless you intend to branch a new conversation.Already inside a live session and just want the web surface? Run
/remote-control— no exit/resume.
Kick off / supervise the loops
cd /srv/cc-ci/cc-ci-plan
./launch.sh start # Builder + Adversary loops (interactive --remote-control in tmux) + watchdog
./launch.sh status # session + DONE state
./launch.sh logs builder|adversary|watchdog
./launch.sh stop
Full supervision guide, credential map, and the Incus VM fallback are in
cc-ci-plan/kickoff.md and cc-ci-plan/plan.md §1.5.