autonomic-bot 5775fe23f8 security: deterministic advisory scan as an ADDITIVE pre-step
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.
2026-08-10 18:25:58 +00:00

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-orchestrator session

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 12.

Two different "names": --resume <name|id> selects the conversation to restore (shown in the /resume picker); the --remote-control "<name>" value is only the web display label and resumes nothing. Resuming reuses the same session id each time (stays 34a8…) — don't pass --fork-session unless 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.

S
Description
Autonomous orchestrator: planning, launch, and setup for the cc-ci Co-op Cloud recipe CI server
Readme
1.9 MiB
Languages
Python 78.7%
Shell 12.1%
Nix 8.5%
HCL 0.7%