Files
cc-ci-orchestrator/cc-ci-plan
autonomic-bot 1daf0fa616 advisory-scan: stop cross-image and cross-scheme miscounting (discourse's false 133)
Operator disbelieved discourse's '133 CVEs fixed' — correctly. Two defects made it
confidently wrong:

1. ONE WINDOW APPLIED TO EVERY IMAGE. The scan queries all source repos in the
   recipe's registry (app + redis/postgres/nginx sidecars) but judged them all with
   the APP's version window. 34 of the 133 were redis advisories, including
   CVE-2021-21309 — patched in redis 6.0.11 back in 2021 — scored as 'fixed by this
   upgrade' purely because 6.0.11 sits numerically inside discourse's 3.5.3 ->
   2026.7.1 range. Only the PRIMARY app repo is now classified; other sources are
   reported as unclassified so they stay visible without inflating the count.

2. VERSION-SCHEME CHANGES BREAK ORDERING. discourse moved semver -> calver
   (3.5.3 -> 2026.7.1), so 2025.12.2 compares 'newer' than 3.5.3 while shipping
   earlier. Numeric comparison cannot order that. The scan now detects a leading-
   component jump >= 100, refuses to classify, and says so in the block: the count
   is '0 by refusal, not by evidence — read the vendor's release notes'.

Refusing to answer beats answering wrongly: a fabricated 133 in a public security
report is worse than an explicit 'cannot determine'.

Verified after the fix: discourse 133 -> 0 (with the refusal caveat), gitea still
exactly 2 (both criticals, patched 1.27.1), keycloak 7 all genuinely from
keycloak/keycloak patched in 26.7.1, plausible 1. No other count changed.
2026-08-10 20:44:27 +00:00
..

cc-ci-plan

Self-contained handoff package for building the cc-ci Co-op Cloud recipe CI server with two autonomous Claude loops (a Builder and an adversarial Reviewer) running over days.

Start here

  1. Read plan.md — the full plan and single source of truth (mission, Definition of Done, architecture, milestones, the two-agent coordination protocol, loop discipline).
  2. Read kickoff.md — how to launch and supervise the loops.
  3. Run ./launch.sh start to bring up both loops + the watchdog.

Files

File Purpose
plan.md The Phase-1 plan (build the CI server). Agents treat it as their single source of truth.
plan-phase1c-full-reproducibility.md Phase 1c (runs first): make the VM fully reproducible from git (all secrets incl. the wildcard cert in sops, in a separate private cc-ci-secrets repo as a flake input; base stays well-parameterized) and do the genuine throwaway-VM live rebuild to close D8 honestly (the "infeasible by design" was overstated).
plan-phase1b-review-lint.md Phase 1b (after 1c): deterministic linting/formatting in CI + a white-box review checklist (real tests, DRY harness, idempotent Nix, no footguns/secrets), ending in a full cold re-verification of all D1D10 — now covering 1c's refactor.
plan-phase1d-generic-test-suite.md Phase 1d (after 1b, before 2): a generic install/upgrade/backup/restore suite that runs on any recipe with zero config, with a recipe's own test_<op>.py overriding or extending the generic (Builder's call) and reusing the generic's deployment — no redeploy, plus optional custom install-steps; recipes needing special setup fail the generic form gracefully. The test-architecture foundation Phase 2 builds on.
plan-phase1e-harness-corrections.md Phase 1e (after 1d, before 2): three operator-review corrections to the shared generic harness — (HC1) upgrade goes previous-release → PR head via deploy --chaos; (HC2) repo-local PR code runs only for approved recipes (default = cc-ci overlays + generic only); (HC3) the generic runs by default alongside an overlay, skipped only via explicit opt-out.
plan-phase2-recipe-tests.md Phase 2 (after Phase 1e): build on the corrected generic suite — author the recipe overlays (port recipe-maintainer tests as test_*.py) + define custom install steps where a recipe fails generically.
plan-phase2b-test-performance.md Phase 2b (after Phase 2, before Phase 3): empirically measure where test time goes and reduce it (image cache, readiness tuning, dedup deploys, warm infra, concurrency) — no weakened tests.
plan-phase3-results-ux.md Phase 3 (after Phase 2b): beautiful YunoHost-style results — per-run level, image-forward PR comment (badge + summary card + app screenshot), polished dashboard.
IDEAS.md Deferred/future ideas, parked out of current scope.
brief.md The original one-page brief (context only; plan.md supersedes it).
kickoff.md Launch & supervision guide.
launch.sh Starts both loops + a watchdog; restarts dead loops; stops on ## DONE.
prompts/builder.md Builder loop prompt (fed to claude by the script).
prompts/adversary.md Adversary loop prompt.

Before launching

  • Set the org in plan.md (git.autonomic.zone/recipe-maintainers/cc-ci) and lock the six proof recipes (§8).
  • Ensure the launching shell has: SSH+sudo to cc-ci, the Gitea token, git.autonomic.zone access.
  • Preconfigure test-app DNS + TLS (plan §4.0): point a wildcard *.ci.commoninternet.net record at a gateway that TLS-passthroughs to cc-ci, and pre-issue the wildcard cert (*.ci.commoninternet.net + ci.commoninternet.net, via Gandi DNS-01) into /var/lib/ci-certs/live/ on cc-ci. The agent handles everything else on cc-ci (Traefik file provider → that cert, swarm, routing) and does no ACME; renewal (~90 days) is an out-of-band operator task, so the DNS token never goes to the agent.
  • export CC_CI_REPO=https://git.autonomic.zone/recipe-maintainers/cc-ci.git so the watchdog can detect ## DONE.

What "done" means

The loops stop only when all of plan.md §2 (D1D10) hold and the Adversary has independently re-verified each within 24h. The watchdog then tears the loops down automatically.