autonomic-bot
b0bdce2c15
/cve-check answers 'what are we exposed to that an upgrade would fix?' without running an upgrade: per-recipe, resolve the available window for EVERY image (sidecars included), run the advisory scan over it, adjudicate whatever pass 1 could not decide, publish a report. Read-only — no PRs, no CI, no merges. /cve-check-and-upgrade does that sweep, then runs /recipe-upgrade only on the recipes whose upgrade actually closes a CVE, worst severity first, and reports on both. --min-severity high for just the urgent ones; --dry-run prints the queue and stops. Never merges. Deliberate choices, each written into the skills: - externals are SWEPT but never upgraded here — a security sweep that skipped deployed software would misreport exposure, but we don't maintain them. - an unknown count never justifies an upgrade AND is never treated as clean; it goes to the Addendum. - no upgrade available means 0 CVEs, not '?'. - subagents are told which CVEs justify their upgrade, so the PR says why it exists — a PR naming the RCE it closes gets reviewed sooner. recipe-report.py grows a page kind: 'cve' files as cve-DATE.html so a sweep can't overwrite a weekly edition, while BOTH appear in the same archive index, suffixed 'full report' / 'CVE check'. /help and /cc-ci-status updated to route to them.
104 lines
6.2 KiB
Markdown
104 lines
6.2 KiB
Markdown
---
|
|
name: help
|
|
description: Operator orientation - lists every skill available on this orchestrator with what it does and when to reach for it, grouped by purpose (status, weekly maintenance, host updates, tests, enrollment, recovery, reporting), plus a "what do you want to do?" guide for common situations. Read-only. Invoke as /help.
|
|
---
|
|
|
|
# help
|
|
|
|
Orient the operator: what this orchestrator can do, via which skill, and what's sensible next.
|
|
|
|
**First, enumerate the live roster** (skills get added — don't trust this file's list blindly):
|
|
```
|
|
ls /srv/cc-ci-orch/.opencode/skills/ # canonical definitions (one dir per skill)
|
|
```
|
|
For any skill not described below, read its `SKILL.md` frontmatter description and include it.
|
|
Then present the roster grouped as follows, and close with the situation guide.
|
|
|
|
## The roster (curated descriptions — merge with the live listing)
|
|
|
|
**Status & orientation**
|
|
- **/cc-ci-status** — the comprehensive read-only health/status check: weekly-run outcomes,
|
|
report publishing, stale tests, CVE-PR aging, host update recency, service health, bridge
|
|
`!testme` path. Ends `ALL HEALTHY` or prioritized findings each mapped to a skill. **Start
|
|
here when unsure.**
|
|
- **/help** — this orientation.
|
|
|
|
**Weekly maintenance (recipes)**
|
|
- **/upgrade-all** — the weekly sweep: survey every `weekly` recipe, open verified upgrade PRs,
|
|
write the summary + report. Runs on a timer (`cc-ci-upgrade-all.timer`, Fri 02:00 UTC);
|
|
invoke manually to run it now.
|
|
- **/recipe-upgrade <recipe>** — the same pipeline for ONE recipe (plan → bump → verify green →
|
|
PR). `--with-tests` also fixes that recipe's stale test.
|
|
- **/recipe-report** — (re)generate the weekly report page for report.ci.commoninternet.net.
|
|
|
|
**Security (CVEs)**
|
|
- **/cve-check** — fleet-wide CVE sweep with **no upgrading**: for every recipe, work out what
|
|
upgrade is available (per image, sidecars included), scan it for CVEs, and publish a CVE report.
|
|
Read-only and quick — the "what are we exposed to?" answer without an upgrade run.
|
|
- **/cve-check-and-upgrade** — the same sweep, then open verified PRs **only** for the recipes whose
|
|
upgrade actually fixes a CVE, worst severity first. `--min-severity high` for just the urgent ones.
|
|
Never merges.
|
|
|
|
**Tests**
|
|
- **/cc-ci-tests-update** — fleet-wide stale-test cleanup: find tests broken by legitimate
|
|
upstream changes, fix without weakening, verify, merge the test PRs.
|
|
- **/ci-test-review** — diagnose a specific red CI run: classify recipe bug vs stale test vs
|
|
CI-server bug, then fix on the right side.
|
|
|
|
**cc-ci itself**
|
|
- **/cc-ci-server-update** — bump the CI **server** host's nixpkgs/sops-nix, deploy with
|
|
build → `nixos-rebuild test` → switch + health gate, PR merged on green.
|
|
- **/cc-ci-orchestrator-update** — same for **this** orchestrator host (self-update caveats).
|
|
- **/cc-ci-update** — both of the above plus /cc-ci-tests-update in one pass.
|
|
- **/ci-dev-workflow** — harness/CI-server development discipline (changing cc-ci itself).
|
|
|
|
**Enrollment**
|
|
- **/recipe-enroll <recipe>** — add a NEW recipe to the maintained set end-to-end: mirror,
|
|
test suite, bridge + inventory enrollment, full-suite-green verification, bridge deploy.
|
|
|
|
**Recovery**
|
|
- **hetzner-server-recovery** — when a Hetzner host is unreachable over SSH/tailscale: API
|
|
reboot, rescue mode, GRUB generation selection (submenu ids are `1>N`), console access.
|
|
|
|
**Recipe-maintainer toolkit (`/cctest-*` — the ARM sandbox + cctest test server, NOT cc-ci)**
|
|
The full autonomic-recipe-maintainer skill set, vendored as a pinned submodule
|
|
(`references/recipe-maintainer`) and exposed with the `cctest-` prefix — ~30 skills for
|
|
hands-on recipe work against the recipe-maintainer **cctest** test server and local abra
|
|
sandbox: `/cctest-intro` (start here), `/cctest-recipe-overview`, `/cctest-recipe-init`,
|
|
`/cctest-recipe-deploy`, `/cctest-recipe-test*`, `/cctest-recipe-upgrade-plan|apply|full`,
|
|
`/cctest-new-recipe-guide`, sandbox/instance management (`/cctest-setup-sandbox`,
|
|
`/cctest-t1cc-start|stop`), and more — enumerate with `ls .opencode/skills | grep ^cctest-`.
|
|
**Rule of thumb:** verifying/shipping against the CI pipeline → the cc-ci skills above;
|
|
exploratory or hands-on recipe development on a test instance → `/cctest-*`. Policy is
|
|
unified: recipe PRs are never agent-merged on either side (operator reviews + merges), and
|
|
ARM skills never touch cc-ci infra. After a submodule bump run `scripts/gen-cctest-skills.py`.
|
|
|
|
## "What do you want to do?"
|
|
|
|
| Situation | Do this |
|
|
|---|---|
|
|
| "How is everything?" | `/cc-ci-status` |
|
|
| "Run the weekly upgrades now" | `/upgrade-all` (or `systemctl start cc-ci-upgrade-all.service`) |
|
|
| "Upgrade just <recipe>" | `/recipe-upgrade <recipe>` |
|
|
| "The report site is stale/missing a week" | `/recipe-report` |
|
|
| "What CVEs are we exposed to right now?" | `/cve-check` (read-only, no PRs) |
|
|
| "A CVE just dropped — check and patch it" | `/cve-check-and-upgrade` (add `--min-severity high` to skip the noise) |
|
|
| "Is <recipe> vulnerable?" | `/cve-check <recipe>` |
|
|
| "Tests are red because upstream changed" | `/cc-ci-tests-update` (fleet) or `/recipe-upgrade <r> --with-tests` |
|
|
| "A CI run failed and I don't know why" | `/ci-test-review` |
|
|
| "Update the CI server OS/deps" | `/cc-ci-server-update` |
|
|
| "Update this orchestrator's OS/deps" | `/cc-ci-orchestrator-update` |
|
|
| "Add <recipe> to what we maintain" | `/recipe-enroll <recipe>` |
|
|
| "A host is unreachable" | `hetzner-server-recovery` |
|
|
| "Hack on / bootstrap a recipe in a sandbox" | `/cctest-recipe-init`, `/cctest-recipe-deploy`, `/cctest-recipe-test` |
|
|
| "New to recipe work, where do I start?" | `/cctest-intro` |
|
|
| "What needs my review?" | `/cc-ci-status` → its open-PR section lists CVE-urgent + ready-to-merge PRs |
|
|
|
|
**Standing conventions** (all skills follow these): PRs are opened for visibility and merged
|
|
directly once verified (invocation = authorization) — except recipe upgrade PRs, which stay
|
|
operator-merged; `nixos-rebuild test` before any `switch`; never weaken a test; single-writer
|
|
branches; serialize deploy-heavy work on the shared swarm.
|
|
|
|
If several things need doing, run `/cc-ci-status` first — its findings come pre-prioritized
|
|
with the skill to invoke for each.
|