From be7f8bc850c825bf74765fbae95c4b4e2bad72c6 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Tue, 4 Aug 2026 01:40:36 +0000 Subject: [PATCH] =?UTF-8?q?cctest:=20unify=20merge=20policy=20wording=20?= =?UTF-8?q?=E2=80=94=20recipe=20PRs=20are=20never=20agent-merged,=20both?= =?UTF-8?q?=20sides?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Operator decision: no policy difference between cc-ci and recipe-maintainer. On inspection ARM already agrees (recipe-upgrade-cron-all: 'PRs are reviewed and merged manually by a human afterwards... never merges anything'; 'no human review in the middle' = skip the mid-run plan confirmation only). Wrappers previously framed this as a cc-ci override over ARM auto-merge flows — wrong reading; now stated as ONE unified rule. /help conventions updated to match. --- .opencode/skills/cctest-init-instance/SKILL.md | 10 +++++----- .opencode/skills/cctest-intro/SKILL.md | 10 +++++----- .opencode/skills/cctest-new-recipe-guide/SKILL.md | 10 +++++----- .opencode/skills/cctest-opencode-sync/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-check/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-create-pr/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-deploy/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-guidelines/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-init/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-logging/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-new-tag/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-overview/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-review/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-test-all/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-test-backup/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-test-new/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-test-update/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-test/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-upgrade-apply/SKILL.md | 10 +++++----- .../skills/cctest-recipe-upgrade-cron-all/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-upgrade-full/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-upgrade-plan/SKILL.md | 10 +++++----- .opencode/skills/cctest-recipe-upstream/SKILL.md | 10 +++++----- .opencode/skills/cctest-setup-sandbox/SKILL.md | 10 +++++----- .../skills/cctest-switch-default-instance/SKILL.md | 10 +++++----- .opencode/skills/cctest-sync-secrets/SKILL.md | 10 +++++----- .opencode/skills/cctest-t1cc-start/SKILL.md | 10 +++++----- .opencode/skills/cctest-t1cc-stop/SKILL.md | 10 +++++----- .opencode/skills/cctest-test-context-reset/SKILL.md | 10 +++++----- .opencode/skills/cctest-test-setup/SKILL.md | 10 +++++----- .opencode/skills/help/SKILL.md | 6 +++--- scripts/gen-cctest-skills.py | 10 +++++----- 32 files changed, 158 insertions(+), 158 deletions(-) diff --git a/.opencode/skills/cctest-init-instance/SKILL.md b/.opencode/skills/cctest-init-instance/SKILL.md index ea51207..695593d 100644 --- a/.opencode/skills/cctest-init-instance/SKILL.md +++ b/.opencode/skills/cctest-init-instance/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-intro/SKILL.md b/.opencode/skills/cctest-intro/SKILL.md index ffe1ebb..6492306 100644 --- a/.opencode/skills/cctest-intro/SKILL.md +++ b/.opencode/skills/cctest-intro/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-new-recipe-guide/SKILL.md b/.opencode/skills/cctest-new-recipe-guide/SKILL.md index 2a2f32d..b954558 100644 --- a/.opencode/skills/cctest-new-recipe-guide/SKILL.md +++ b/.opencode/skills/cctest-new-recipe-guide/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-opencode-sync/SKILL.md b/.opencode/skills/cctest-opencode-sync/SKILL.md index b2f0109..5a78d3c 100644 --- a/.opencode/skills/cctest-opencode-sync/SKILL.md +++ b/.opencode/skills/cctest-opencode-sync/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-check/SKILL.md b/.opencode/skills/cctest-recipe-check/SKILL.md index 3e404cf..343f065 100644 --- a/.opencode/skills/cctest-recipe-check/SKILL.md +++ b/.opencode/skills/cctest-recipe-check/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-create-pr/SKILL.md b/.opencode/skills/cctest-recipe-create-pr/SKILL.md index b2468b0..57b5f0f 100644 --- a/.opencode/skills/cctest-recipe-create-pr/SKILL.md +++ b/.opencode/skills/cctest-recipe-create-pr/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-deploy/SKILL.md b/.opencode/skills/cctest-recipe-deploy/SKILL.md index 1a94240..985d9c8 100644 --- a/.opencode/skills/cctest-recipe-deploy/SKILL.md +++ b/.opencode/skills/cctest-recipe-deploy/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-guidelines/SKILL.md b/.opencode/skills/cctest-recipe-guidelines/SKILL.md index 682ba27..ec7e417 100644 --- a/.opencode/skills/cctest-recipe-guidelines/SKILL.md +++ b/.opencode/skills/cctest-recipe-guidelines/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-init/SKILL.md b/.opencode/skills/cctest-recipe-init/SKILL.md index 4a02bf9..6058e5f 100644 --- a/.opencode/skills/cctest-recipe-init/SKILL.md +++ b/.opencode/skills/cctest-recipe-init/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-logging/SKILL.md b/.opencode/skills/cctest-recipe-logging/SKILL.md index a1bbc64..487692d 100644 --- a/.opencode/skills/cctest-recipe-logging/SKILL.md +++ b/.opencode/skills/cctest-recipe-logging/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-new-tag/SKILL.md b/.opencode/skills/cctest-recipe-new-tag/SKILL.md index f149c37..c8743bd 100644 --- a/.opencode/skills/cctest-recipe-new-tag/SKILL.md +++ b/.opencode/skills/cctest-recipe-new-tag/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-overview/SKILL.md b/.opencode/skills/cctest-recipe-overview/SKILL.md index 0753366..66d2aff 100644 --- a/.opencode/skills/cctest-recipe-overview/SKILL.md +++ b/.opencode/skills/cctest-recipe-overview/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-review/SKILL.md b/.opencode/skills/cctest-recipe-review/SKILL.md index 3b687c0..40c401f 100644 --- a/.opencode/skills/cctest-recipe-review/SKILL.md +++ b/.opencode/skills/cctest-recipe-review/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-test-all/SKILL.md b/.opencode/skills/cctest-recipe-test-all/SKILL.md index ae55260..e31ba5a 100644 --- a/.opencode/skills/cctest-recipe-test-all/SKILL.md +++ b/.opencode/skills/cctest-recipe-test-all/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-test-backup/SKILL.md b/.opencode/skills/cctest-recipe-test-backup/SKILL.md index dbe3d62..ab7cf64 100644 --- a/.opencode/skills/cctest-recipe-test-backup/SKILL.md +++ b/.opencode/skills/cctest-recipe-test-backup/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-test-new/SKILL.md b/.opencode/skills/cctest-recipe-test-new/SKILL.md index 0fd9181..ac38c17 100644 --- a/.opencode/skills/cctest-recipe-test-new/SKILL.md +++ b/.opencode/skills/cctest-recipe-test-new/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-test-update/SKILL.md b/.opencode/skills/cctest-recipe-test-update/SKILL.md index 2bf5f2e..d63ead7 100644 --- a/.opencode/skills/cctest-recipe-test-update/SKILL.md +++ b/.opencode/skills/cctest-recipe-test-update/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-test/SKILL.md b/.opencode/skills/cctest-recipe-test/SKILL.md index a623895..172f2e9 100644 --- a/.opencode/skills/cctest-recipe-test/SKILL.md +++ b/.opencode/skills/cctest-recipe-test/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-upgrade-apply/SKILL.md b/.opencode/skills/cctest-recipe-upgrade-apply/SKILL.md index 329d5fe..f9366c8 100644 --- a/.opencode/skills/cctest-recipe-upgrade-apply/SKILL.md +++ b/.opencode/skills/cctest-recipe-upgrade-apply/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-upgrade-cron-all/SKILL.md b/.opencode/skills/cctest-recipe-upgrade-cron-all/SKILL.md index c6f21b9..dca27a6 100644 --- a/.opencode/skills/cctest-recipe-upgrade-cron-all/SKILL.md +++ b/.opencode/skills/cctest-recipe-upgrade-cron-all/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-upgrade-full/SKILL.md b/.opencode/skills/cctest-recipe-upgrade-full/SKILL.md index 37423cb..98981ee 100644 --- a/.opencode/skills/cctest-recipe-upgrade-full/SKILL.md +++ b/.opencode/skills/cctest-recipe-upgrade-full/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-upgrade-plan/SKILL.md b/.opencode/skills/cctest-recipe-upgrade-plan/SKILL.md index 49d1e50..e41d981 100644 --- a/.opencode/skills/cctest-recipe-upgrade-plan/SKILL.md +++ b/.opencode/skills/cctest-recipe-upgrade-plan/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-recipe-upstream/SKILL.md b/.opencode/skills/cctest-recipe-upstream/SKILL.md index 817953c..992364b 100644 --- a/.opencode/skills/cctest-recipe-upstream/SKILL.md +++ b/.opencode/skills/cctest-recipe-upstream/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-setup-sandbox/SKILL.md b/.opencode/skills/cctest-setup-sandbox/SKILL.md index 9f9b4b2..9479ba4 100644 --- a/.opencode/skills/cctest-setup-sandbox/SKILL.md +++ b/.opencode/skills/cctest-setup-sandbox/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-switch-default-instance/SKILL.md b/.opencode/skills/cctest-switch-default-instance/SKILL.md index 5649605..f2ae13b 100644 --- a/.opencode/skills/cctest-switch-default-instance/SKILL.md +++ b/.opencode/skills/cctest-switch-default-instance/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-sync-secrets/SKILL.md b/.opencode/skills/cctest-sync-secrets/SKILL.md index e69785e..3678cde 100644 --- a/.opencode/skills/cctest-sync-secrets/SKILL.md +++ b/.opencode/skills/cctest-sync-secrets/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-t1cc-start/SKILL.md b/.opencode/skills/cctest-t1cc-start/SKILL.md index dc9cde9..3131c05 100644 --- a/.opencode/skills/cctest-t1cc-start/SKILL.md +++ b/.opencode/skills/cctest-t1cc-start/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-t1cc-stop/SKILL.md b/.opencode/skills/cctest-t1cc-stop/SKILL.md index 48742eb..07cc509 100644 --- a/.opencode/skills/cctest-t1cc-stop/SKILL.md +++ b/.opencode/skills/cctest-t1cc-stop/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-test-context-reset/SKILL.md b/.opencode/skills/cctest-test-context-reset/SKILL.md index 643d3d4..871a6be 100644 --- a/.opencode/skills/cctest-test-context-reset/SKILL.md +++ b/.opencode/skills/cctest-test-context-reset/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/cctest-test-setup/SKILL.md b/.opencode/skills/cctest-test-setup/SKILL.md index 6bde034..69e1f17 100644 --- a/.opencode/skills/cctest-test-setup/SKILL.md +++ b/.opencode/skills/cctest-test-setup/SKILL.md @@ -15,11 +15,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via diff --git a/.opencode/skills/help/SKILL.md b/.opencode/skills/help/SKILL.md index 3a064f3..519ddfb 100644 --- a/.opencode/skills/help/SKILL.md +++ b/.opencode/skills/help/SKILL.md @@ -61,9 +61,9 @@ sandbox: `/cctest-intro` (start here), `/cctest-recipe-overview`, `/cctest-recip `/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-*`. cc-ci policy -overrides apply (auto-merge-style ARM flows need per-run operator opt-in; never touch cc-ci -infra from an ARM skill). After a submodule bump run `scripts/gen-cctest-skills.py`. +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?" diff --git a/scripts/gen-cctest-skills.py b/scripts/gen-cctest-skills.py index 77a910c..a01d3e7 100644 --- a/scripts/gen-cctest-skills.py +++ b/scripts/gen-cctest-skills.py @@ -39,11 +39,11 @@ its shared swarm. Execute with the submodule as your working directory: configured on this host (`settings.toml` from `settings.toml.example`, sandbox/test instances), run `/cctest-intro` / `/cctest-setup-sandbox` first. -**Policy overrides (cc-ci-orchestrator conventions win):** -- Anything that would **merge a recipe PR or push a recipe main without review** requires - explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are - operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT - inherit blanket authorization here. +**Unified policy (same as cc-ci — no differences):** +- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator + reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a + human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in + the middle" wording refers only to skipping the mid-run plan confirmation, not to merging. - Never touch cc-ci infrastructure (the CI server, its swarm, `/root/*` clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills. - The submodule is **pinned**: don't commit into it from here; upstream ARM changes arrive via