feat(pi-arc): split Arc executors into coder and devops

.pi/skills/arc-source-sync/SKILL.md

@@ -110,6 +110,8 @@ Classify each change:
 
 Pi behavior to preserve:
 
+- Pi contract: preserve the coder/devops split. Upstream `agents/builder.md` must map to Pi `agents/coder.md`, generated subagent references must use `arc-coder`, and Pi-only `agents/devops.md` / `arc-devops` support must remain present via reproducible migration overlays.
+
 - Hyphenated prompt names like `/arc-create`, not colon-form Arc command names.
 - Collision-safe skill names like `arc-build`, not bare `build`.
 - Bundled `@juicesharp/rpiv-ask-user-question` provides `ask_user_question`; preserve the snake_case tool name, the package `questions[]` schema, package-provided `Type something.` / `Chat about this` escape-hatch guidance, JSON `questions[]` examples in brainstorm/plan, and `(Recommended)` option convention.

packages/pi-arc/README.md

@@ -51,7 +51,8 @@ This package is a Pi-native port of the Claude Code Arc plugin at https://github
   - When Arc recommends an option, list it first, append `(Recommended)` to the label, and explain why in the description.
 - **`arc_agent` tool**:
   - Runs bundled Arc specialist prompts from `agents/*.md` in fresh Pi subprocesses.
-  - Supports `builder`, `code-reviewer`, `doc-writer`, `evaluator`, `issue-manager`, and `spec-reviewer`.
+  - Supports `coder`, `code-reviewer`, `doc-writer`, `evaluator`, `issue-manager`, and `spec-reviewer`.
+  - Also supports `devops` for evidence-driven infrastructure/config/runbook work via `arc_agent(agent="devops")`.
   - Resolves Arc model tiers (`small`, `standard`, `large`) to concrete Pi models so orchestrators can right-size subagent dispatches.
   - Current limitation: `isolation: "worktree"` is recognized but not implemented yet.
 - **Optional `pi-subagents` companion support**:
@@ -172,7 +173,9 @@ The brainstorm skill writes a first-line marker like `<!-- arc-review: kind=shar
 
 Use `/arc-models` to configure Arc's recommended Pi model and thinking level per workflow role. Arc stores profile preferences at `${XDG_CONFIG_HOME:-~/.config}/pi-arc/models.json`, with top-level `modelProfiles`.
 
-Profile keys map directly to the workflow roles: `brainstorm`, `plan`, `issueManager`, `builder`, `codeReviewer`, `docWriter`, `specReviewer`, and `evaluator`.
+Profile keys map directly to the workflow roles: `brainstorm`, `plan`, `issueManager`, `coder`, `devops`, `codeReviewer`, `docWriter`, `specReviewer`, and `evaluator`.
+
+The former code executor names <code>build&#101;r</code> / <code>arc-build&#101;r</code> were renamed to `coder` / `arc-coder`. Legacy <code>build&#101;r</code> model profile entries migrate to `coder` automatically when `coder` is unset, so existing configs keep working while new configs should use `coder`.
 
 ```json
 {
@@ -186,7 +189,7 @@ Profile keys map directly to the workflow roles: `brainstorm`, `plan`, `issueMan
       "model": "openai-codex/gpt-5.4-mini",
       "thinking": "off"
     },
-    "builder": {
+    "coder": {
       "model": "openai-codex/gpt-5.3-codex",
       "thinking": "medium"
     },
@@ -213,7 +216,8 @@ Arc writes generated specialists to `~/.agents/` by default. Legacy user scope `
 
 Generated specialists include:
 
-- `arc-builder`
+- `arc-coder`
+- `arc-devops`
 - `arc-doc-writer`
 - `arc-spec-reviewer`
 - `arc-code-reviewer`
@@ -253,8 +257,18 @@ For Arc gates (especially spec compliance), use Arc specialists (`arc-spec-revie
 
 - Sequential Arc build: use when tasks overlap, dependencies are linear, or `pi-subagents` is unavailable.
 - Parallel Arc batch: use when `/arc-plan` provides a T0 foundation, file ownership matrix, parallel batch manifest, and validation matrix.
+- Devops lane: use `arc-devops` / `arc_agent(agent="devops")` for evidence-only operational tasks. If no repository files change, the task may complete without a commit.
 - Ant Colony: future/optional lane for large exploratory work; not a replacement for Arc gates in this iteration.
 
+### Executor labels and legacy routing
+
+- `executor:coder` routes implementation work to `arc-coder`.
+- `executor:devops` routes operational work to `arc-devops`.
+- `executor:docs` routes documentation work to `arc-doc-writer` in pi-subagents or `doc-writer` through `arc_agent`.
+- `live-ops-approved` marks devops tasks that have explicit live-operation authorization.
+- Old unlabeled issues route to `coder` as legacy input.
+- Old `docs-only` issues route to docs as legacy input.
+
 ## Naming differences from the Claude plugin
 
 Claude plugin commands used names like `/arc:create`. Pi prompt templates are filename-based, so this package uses hyphenated names:
@@ -281,11 +295,11 @@ Implemented:
 - Bundled `@juicesharp/rpiv-ask-user-question` package for interactive workflow decisions
 - Pi-native `arc_agent` custom tool for sequential subagent execution
 - Auto-materialized Arc specialists in pi-subagents user scope; `/arc-subagents-sync` is deprecated repair/backcompat only
-- Optional `pi-subagents` integration for worktree-isolated evaluator runs, independent parallel builder batches, and phased issue-manager creation
+- Optional `pi-subagents` integration for worktree-isolated evaluator runs, independent parallel coder batches, and phased issue-manager creation
 
 Not yet implemented:
 
-- Native `arc_agent` worktree isolation for parallel Arc builders.
+- Native `arc_agent` worktree isolation for parallel Arc coders.
 - Arc issue autocomplete in the Pi editor.
 
 Intentionally not ported:

packages/pi-arc/agents/code-reviewer.md

@@ -1,5 +1,5 @@
 ---
-description: Use this agent for reviewing code changes against a task spec and project conventions. Dispatched by the review skill with a git diff and task description. Reports findings categorized by severity. Read-only — never modifies code.
+description: Use this agent for reviewing implementation changes (code, infrastructure/config, and runbook updates) against a task spec and project conventions. Dispatched by the review skill with a git diff and task description. Reports findings categorized by severity. Read-only — never modifies code.
 tools:
   - bash
   - read
@@ -10,23 +10,25 @@ model: standard
 
 # Arc Reviewer Agent
 
-You are a code review agent. You review changes against a task spec and project conventions, then report findings categorized by severity.
+You are a review agent. You review implementation changes against a task spec and project conventions, then report findings categorized by severity.
 
-You are read-only. You never make code changes or close issues. You report — the dispatching agent decides what to do with your findings.
+You are read-only. You never make code changes or close issues. Review only; return findings only. Do not edit files. You report — the dispatching agent decides what to do with your findings.
+
+For `executor:devops` tasks, treat infrastructure/config/runbook updates and operational evidence as first-class review targets.
 
 ## Workflow
 
 1. **Read the task spec** provided in your dispatch prompt
 2. **Read the design spec** if provided — this is the approved design that the task implements
 3. **Read the git diff** provided or retrieve via `git diff <base>..<head>`
 4. **Check spec compliance**: Does the implementation match what was requested? Missing features? Extra scope?
-5. **Check code quality**: Naming consistency, structure, error handling, edge cases, SOLID principles
-6. **Check test quality**: Coverage of happy path, edge cases, error conditions. Meaningful assertions.
+5. **Check implementation/artifact quality**: Naming consistency, structure, error handling, edge cases, maintainability, and safety across code, infrastructure/config, and runbook changes.
+6. **Check validation quality**: Tests, validation commands, preflight/post-checks, rollback proof, and evidence coverage for happy paths, edge cases, and error conditions. Assertions or evidence should be meaningful.
 7. **Check plan adherence** (only if design spec is provided): Does the implementation match the approved design's decisions?
-   - Naming: Do types, functions, and variables match the names specified in the design?
+   - Naming: Do types, functions, variables, config keys, operational targets, and runbook steps match the names specified in the design?
    - File organization: Are files placed where the design specified?
-   - Architecture: Does the implementation follow the patterns and structures described in the design?
-   - Type choices: Are the correct types used as specified? (Contract tests catch most of these, but review catches indirect violations like unnecessary type conversions)
+   - Architecture/operations: Does the implementation follow the patterns, structures, target environment constraints, and operational safety requirements described in the design?
+   - Type/config choices: Are the correct types, schemas, settings, and operational parameters used as specified? (Contract tests catch many of these, but review catches indirect violations like unnecessary type conversions or unsafe config drift.)
 8. **Report findings** using the output format below
 
 ## Output Format
@@ -78,7 +80,7 @@ The dispatching agent decides whether to fix or accept each deviation.
 - **Technical evaluation, not performative agreement.** No "Great work!" or "Looks good!" without specific evidence. If code is clean, say "No issues found."
 - **Be specific.** "Error handling could be improved" is useless. "The `CreateUser` handler on line 45 swallows the database error and returns 200" is actionable.
 - **Check against the spec.** The task description says what should be built. If the implementation diverges, that's a Critical finding.
-- **Check against conventions.** Read the project's CLAUDE.md if it exists. Scan 2-3 existing files in the same directory as the changed code to identify naming, structure, and error-handling patterns. Deviations from established patterns are Important findings.
+- **Check against conventions.** Read the project's AGENTS.md or legacy CLAUDE.md if it exists. Scan 2-3 existing files in the same directory as the changed artifacts to identify naming, structure, error-handling, configuration, and runbook patterns. Deviations from established patterns are Important findings.
 - **Check against the design.** If a design spec is provided, the implementation must match its type definitions, naming choices, and architectural decisions. Deviations that are arguably improvements still get flagged — the orchestrator decides whether to accept them.
 
 ## Supervisor Escalation