cctest: unify merge policy wording — recipe PRs are never agent-merged, both sides

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

@@ -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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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

.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
+exploratory or hands-on recipe development on a test instance → `/cctest-*`. Policy is
-overrides apply (auto-merge-style ARM flows need per-run operator opt-in; never touch cc-ci
+unified: recipe PRs are never agent-merged on either side (operator reviews + merges), and
-infra from an ARM skill). After a submodule bump run `scripts/gen-cctest-skills.py`.
+ARM skills never touch cc-ci infra. After a submodule bump run `scripts/gen-cctest-skills.py`.
 
 ## "What do you want to do?"
 

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):**
+**Unified policy (same as cc-ci — no differences):**
-- Anything that would **merge a recipe PR or push a recipe main without review** requires
+- **Recipe PRs are NEVER merged by an agent.** Every flow ends at an open PR; the operator
-  explicit operator opt-in per run — the cc-ci standing rule is recipe upgrade PRs are
+  reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a
-  operator-merged, and ARM skills that say otherwise (e.g. full-auto upgrade flows) do NOT
+  human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in
-  inherit blanket authorization here.
+  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