b5f2b10)
Cold-verified redfix-m2-harness@b5f2b10 (parent07fc6d4= the sha the earlier M2 PASS was given against, so the other five fixes are provably untouched by this commit). Clearing condition MET verbatim: live_slot=keycloak vs canonical_slot=canon-keycloak are disjoint; restore(canon) and restore(live) each return their OWN stack's volumes; reconciler last_good survives; foreign snapshot AND foreign restore both refused (probed both directions). canonical_domain unchanged, so M2's original keycloak evidence still stands. Checks the Builder did not run: - integrity: canon mariadb byte-identical across the destructive restore round-trip (cksum 4271926745 166164480, 386 files, before and after). - mutation testing (are the +10 tests vacuous?): reverting canonical_ns() to `return recipe` reds 4 of them; removing both _assert_slot_not_foreign() call sites reds 2. Not vacuous. Suites reproduce exactly: 325 passed @b5f2b10, 315 passed @07fc6d4. - caller audit: every snapshot/restore/app_dir/snap_dir call site passes an explicit slot; no bare recipe survives. - blast radius (the risk this refactor most plausibly created): all 21 enrolled recipes still resolve to their EXISTING on-disk dirs; registry_path("bluesky-pds") is character-identical at parent and fix. The 3 without a registry have no dir at all and never did. No migration. - prune_stale invariant now structural: <recipe>/ never gains a canonical.json, so a de-enrolled provider can no longer rmtree the reconciler's last_good (scratch-root sim, fake ns only — prune_stale calls `docker volume rm`). Enrollment retained (WARM_CANONICAL=True), no silent de-enrollment. Both false "can never touch each other" comments removed. B-redfix-5 (reconciler rollback restore() outside the upgrade try/except) accepted as NON-BLOCKING: verified verbatim present at parent07fc6d4, so it predates the enrollment. F-redfix-4 made it reachable; that path is now closed. Correctly filed, not silently fixed. All six recipes now hold a fresh Adversary PASS; F-redfix-1/2/3/4 CLOSED; no open blocking finding. Builder may re-assert ## DONE. Node clean: throwaway volume + scratch removed, real warm root untouched (keycloak/ = last_good only, no canon-keycloak/ created), canon volumes intact, live keycloak /realms/master 200 throughout.
cc-ci — Co-op Cloud recipe CI server
Comment !testme on a PR in an enrolled Co-op Cloud recipe repo and cc-ci deploys the recipe
at that commit onto a real single-node Docker Swarm, runs install / upgrade / backup-restore tests
(Python + Playwright) end-to-end, and reports a live, tail-able run with pass/fail back to the PR.
This repo declares the entire server as a NixOS flake and holds the test harness, the per-recipe test trees, and the docs to enroll a recipe or rebuild the box from scratch.
Status: under active autonomous construction. See
machine-docs/STATUS.mdfor the live phase andplan.md-driven milestones inmachine-docs/BACKLOG.md. Definition of Done is D1–D10 (see the build plan).
Layout
flake.nix NixOS entry point + devshells (`#cc-ci` = live Hetzner host, `#cc-ci-incus` = legacy Incus host)
nix/hosts/cc-ci/ legacy Incus VM host config (fallback / historical)
nix/hosts/cc-ci-hetzner/ live Hetzner host config
nix/modules/ drone, comment-bridge, swarm, dashboard, secrets (Nix modules)
secrets/ sops-encrypted infra secrets (cc-ci-secrets submodule)
bridge/ !testme webhook listener source
runner/ run_recipe_ci.py + shared pytest harness
dashboard/ results overview generator
tests/<recipe>/ per-recipe install/upgrade/backup tests + custom/
docs/ install, enroll-recipe, secrets, architecture, runbook, baseline
All .nix code lives under nix/; flake.nix/flake.lock stay at the repo root. Host targets are:
#cc-ci= canonical live Hetzner server#cc-ci-hetzner= explicit alias for the same live Hetzner server#cc-ci-incus= legacy Incus VM definition only; do not use on Hetzner
Docs
docs/install.md— rebuild the server from scratch (D8)docs/testing.md— test architecture: generic lifecycle suite + layered recipe overlays (override/extend, discovery precedence, custom install-steps hook)docs/enroll-recipe.md— add a recipe under CI (D5)docs/secrets.md— secret model + rotation (D6)docs/architecture.md,docs/runbook.md— design + debugging failed runsdocs/baseline.md— bootstrap snapshot / rollback reference
Linting & formatting
The codebase is kept formatted + lint-clean by a single entrypoint, run from the pinned lint
devshell so local and CI use identical tool versions:
nix develop .#lint --command bash scripts/lint.sh # check-only (what CI runs)
nix develop .#lint --command bash scripts/lint.sh --fix # auto-format + apply fixes
Covers Nix (nixpkgs-fmt · statix · deadnix), Python (ruff lint+format), Shell
(shellcheck · shfmt), and YAML (yamllint). Config lives in ruff.toml / .yamllint.yaml;
tool/strictness choices are in machine-docs/DECISIONS.md. CI enforces it: the lint step in the
.drone.yml push pipeline runs the same command and fails the build on any unclean file, so
keep commits clean (--fix before pushing).
Loop state (autonomous build)
The multi-agent loop state lives under machine-docs/: STATUS.md (phase/blockers),
BACKLOG.md (work + adversary findings), REVIEW.md (independent verification), JOURNAL.md
(build log), DECISIONS.md (architecture choices) — plus the phase-namespaced *-1b.md / *-1c.md
variants. See the build plan for the two-loop Builder/Adversary protocol.