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