@cxi-lmai/ci-agent-platform 3.2.3 → 5.0.0

package/LICENSE

@@ -1,21 +1,75 @@
-MIT License
-
-Copyright (c) 2026 Technical University of Liberec
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+Required Notice: Copyright 2026 Technical University of Liberec (https://www.tul.cz)
+
+# PolyForm Noncommercial License 1.0.0
+
+<https://polyformproject.org/licenses/noncommercial/1.0.0>
+
+## Acceptance
+
+In order to get any license under these terms, you must agree to them as both strict obligations and conditions to all your licenses.
+
+## Copyright License
+
+The licensor grants you a copyright license for the software to do everything you might do with the software that would otherwise infringe the licensor's copyright in it for any permitted purpose.  However, you may only distribute the software according to [Distribution License](#distribution-license) and make changes or new works based on the software according to [Changes and New Works License](#changes-and-new-works-license).
+
+## Distribution License
+
+The licensor grants you an additional copyright license to distribute copies of the software.  Your license to distribute covers distributing the software with changes and new works permitted by [Changes and New Works License](#changes-and-new-works-license).
+
+## Notices
+
+You must ensure that anyone who gets a copy of any part of the software from you also gets a copy of these terms or the URL for them above, as well as copies of any plain-text lines beginning with `Required Notice:` that the licensor provided with the software.  For example:
+
+> Required Notice: Copyright Yoyodyne, Inc. (http://example.com)
+
+## Changes and New Works License
+
+The licensor grants you an additional copyright license to make changes and new works based on the software for any permitted purpose.
+
+## Patent License
+
+The licensor grants you a patent license for the software that covers patent claims the licensor can license, or becomes able to license, that you would infringe by using the software.
+
+## Noncommercial Purposes
+
+Any noncommercial purpose is a permitted purpose.
+
+## Personal Uses
+
+Personal use for research, experiment, and testing for the benefit of public knowledge, personal study, private entertainment, hobby projects, amateur pursuits, or religious observance, without any anticipated commercial application, is use for a permitted purpose.
+
+## Noncommercial Organizations
+
+Use by any charitable organization, educational institution, public research organization, public safety or health organization, environmental protection organization, or government institution is use for a permitted purpose regardless of the source of funding or obligations resulting from the funding.
+
+## Fair Use
+
+You may have "fair use" rights for the software under the law. These terms do not limit them.
+
+## No Other Rights
+
+These terms do not allow you to sublicense or transfer any of your licenses to anyone else, or prevent the licensor from granting licenses to anyone else.  These terms do not imply any other licenses.
+
+## Patent Defense
+
+If you make any written claim that the software infringes or contributes to infringement of any patent, your patent license for the software granted under these terms ends immediately. If your company makes such a claim, your patent license ends immediately for work on behalf of your company.
+
+## Violations
+
+The first time you are notified in writing that you have violated any of these terms, or done anything with the software not covered by your licenses, your licenses can nonetheless continue if you come into full compliance with these terms, and take practical steps to correct past violations, within 32 days of receiving notice.  Otherwise, all your licenses end immediately.
+
+## No Liability
+
+***As far as the law allows, the software comes as is, without any warranty or condition, and the licensor will not be liable to you for any damages arising out of these terms or the use or nature of the software, under any kind of legal claim.***
+
+## Definitions
+
+The **licensor** is the individual or entity offering these terms, and the **software** is the software the licensor makes available under these terms.
+
+**You** refers to the individual or entity agreeing to these terms.
+
+**Your company** is any legal entity, sole proprietorship, or other kind of organization that you work for, plus all organizations that have control over, are under the control of, or are under common control with that organization.  **Control** means ownership of substantially all the assets of an entity, or the power to direct its management and policies by vote, contract, or otherwise.  Control can be direct or indirect.
+
+**Your licenses** are all the licenses granted to you for the software under these terms.
+
+**Use** means anything you do with the software requiring one of your licenses.

package/README.md

@@ -42,7 +42,7 @@ checks the result. The input is a spec, the output is code. Details in
 - [The full cycle](#the-full-cycle)
 - [Repository layout](#repository-layout)
 - [Install](#install)
-  - [Harness: Claude Code or omp + OpenRouter](#harness-claude-code-or-omp-openrouter)
+  - [Harness and model provider](#harness-and-model-provider)
   - [What it costs](#what-it-costs)
   - [Upgrading and removing](#upgrading-and-removing)
 - [The issue-to-code loop (details)](https://gitlab.com/cxi-lmai/ci-agent-platform/-/blob/main/docs/issue-to-code.md)
@@ -66,7 +66,7 @@ untouched file from one the project has edited.
 
 ```
 .
-├── LICENSE                               # MIT
+├── LICENSE                               # PolyForm Noncommercial 1.0.0
 ├── README.md                             # this file, and the npm front page
 ├── package.json                          # bin: ci-agent-platform
 ├── bin/init.mjs                          # phase 0: deterministic, no model
@@ -104,9 +104,10 @@ Two things are worth having before you start, though neither blocks the install.
 A `CLAUDE.md` at the repository root: most agents read it as the project's
 rulebook, and without one the reviewers work from `pipeline-config.md` alone. And
 CI credentials for whichever platform you use, which the wizard walks you
-through at the end. Any one of `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN` or
-`CLAUDE_CODE_OAUTH_TOKEN` authenticates the agents, so a Claude subscription
-works without buying API credit.
+through at the end. By default one `OPENROUTER_API_KEY` authenticates every
+agent. With `PIPE_PROVIDER=anthropic`, any one of `ANTHROPIC_API_KEY`,
+`ANTHROPIC_AUTH_TOKEN` or `CLAUDE_CODE_OAUTH_TOKEN` does instead, so a Claude
+subscription works without buying API credit.
 
 The first command is plain Node with no model in it. It refuses to run outside
 a git repository, detects your platform from the git remote (without ever
@@ -131,18 +132,33 @@ rest:
 > `--experimental-github` to answer that in advance, or `--force` to proceed
 > past a prior install it cannot account for.
 
-### Harness: Claude Code or omp + OpenRouter
-
-The pipeline runs on Claude Code by default (`PIPE_HARNESS=claude`, the
-`claude` CLI, authenticated with `ANTHROPIC_API_KEY`). Set
-`PIPE_HARNESS=omp` to run on [Oh My Pi](https://openrouter.ai/apps/oh-my-pi)
-through [OpenRouter](https://openrouter.ai) instead: one `OPENROUTER_API_KEY`
-authenticates every job, and `PIPE_MODEL_TRIAGE`/`_CODE`/`_REVIEW` accept any
-OpenRouter model id, not just Anthropic's. The two are mutually exclusive per
-project. Set the credential and the `PIPE_HARNESS` value for the harness you
-picked, not both. Claude-harness model usage is billed by Anthropic, while
-omp-harness model usage is billed by OpenRouter. GitLab only for now; GitHub
-Actions omp support is not shipped yet.
+### Harness and model provider
+
+The pipeline runs on Claude Code (`PIPE_HARNESS=claude`, the `claude` CLI)
+with its model calls routed through [OpenRouter](https://openrouter.ai)
+(`PIPE_PROVIDER=openrouter`): one `OPENROUTER_API_KEY` authenticates every
+job, and usage is billed by OpenRouter. The runner points Claude Code's
+`ANTHROPIC_BASE_URL` at OpenRouter's Anthropic-compatible endpoint, so nothing
+in the agents or skills changes. Set `PIPE_PROVIDER=anthropic` to call
+Anthropic directly with `ANTHROPIC_API_KEY` instead. Set the credential for the
+provider you picked, not both.
+
+| Role | Variable | Default model |
+|---|---|---|
+| coding (coder, test-fix, test writers) | `PIPE_MODEL_CODE`, agent tier `opus` | Claude Opus 5.5 |
+| review, docs, planning | `PIPE_MODEL_REVIEW`, agent tier `sonnet` | Claude Sonnet 5.5 |
+| triage, postmortem | `PIPE_MODEL_TRIAGE`, agent tier `haiku` | Claude Haiku 4.5 |
+
+Subagents name a tier in their frontmatter, and the runner maps each tier to
+the provider's model id through `ANTHROPIC_DEFAULT_OPUS_MODEL`,
+`_SONNET_MODEL` and `_HAIKU_MODEL`. Set any of those, or a `PIPE_MODEL_*`
+variable, as a CI variable to pick another model. On OpenRouter that can be
+any OpenRouter model id, not just Anthropic's.
+
+The older [Oh My Pi](https://openrouter.ai/apps/oh-my-pi) harness
+(`PIPE_HARNESS=omp`, OpenRouter only, GitLab only) is still shipped for
+projects that already run it, but it is no longer what the install wizard
+offers.
 
 `omp` is a Bun program, so the GitLab template's `before_script` installs
 `bun` next to it (`npm install -g bun`) — the default `node:22-bookworm` image
@@ -251,3 +267,11 @@ emits a marker file for the runner.
 > agent reads them. A custom agent is for a new capability, not for one
 > repository's specifics. The `agent-architect` agent can propose improvements to
 > the existing agents.
+
+## License
+
+[PolyForm Noncommercial License 1.0.0](LICENSE). Free for noncommercial use,
+including research, teaching and use by public research and educational
+institutions; commercial use needs a separate licence from the Technical
+University of Liberec. Releases up to and including 4.0.0 were published under
+MIT, and those copies remain available under MIT.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cxi-lmai/ci-agent-platform",
-  "version": "3.2.3",
+  "version": "5.0.0",
   "description": "Autonomous dev pipeline on plain GitLab CI or GitHub Actions, driven by Claude Code. A labeled issue goes in, an open merge request comes out.",
   "keywords": [
     "claude",
@@ -20,7 +20,7 @@
     "type": "git",
     "url": "git+https://gitlab.com/cxi-lmai/ci-agent-platform.git"
   },
-  "license": "MIT",
+  "license": "PolyForm-Noncommercial-1.0.0",
   "author": "Technical University of Liberec",
   "type": "module",
   "bin": {

package/payload/agents/agent-architect.md

@@ -2,7 +2,7 @@
 name: agent-architect
 description: Weekly agent-improvement lab. Reads recently merged MRs/PRs, review comments, and stuck-MR postmortems, then proposes improvements to .claude/agents/*.md files as actionable platform issues (auto-filed with the pipeline's ready label). Output is a structured markdown report consumed by the CI script. Never auto-applies changes to CLAUDE.md or .claude/settings.json.
 tools: Glob, Grep, LS, Read
-model: claude-sonnet-5
+model: sonnet
 ---
 
 You are the Agent Lab for this project's autonomous development pipeline.

package/payload/agents/code-reviewer.md

@@ -2,7 +2,7 @@
 name: code-reviewer
 description: Reviews code for bugs, logic errors, security vulnerabilities, code quality issues, and adherence to project conventions, using confidence-based filtering to report only high-priority issues that truly matter
 tools: Glob, Grep, LS, Read, Write, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
-model: claude-sonnet-5
+model: sonnet
 color: red
 ---
 

package/payload/agents/codebase-auditor.md

@@ -2,7 +2,7 @@
 name: codebase-auditor
 description: Periodic codebase auditor. Reads project conventions and docs, reads recently merged MR/PR file changes, and produces a focused report of critical convention violations and genuinely new undocumented patterns. Uses confidence-based filtering to report only issues that truly matter.
 tools: Glob, Grep, LS, Read
-model: claude-sonnet-5
+model: sonnet
 ---
 
 You are the codebase auditor. You produce a periodic report of critical convention violations and genuinely new, reusable patterns worth documenting.

package/payload/agents/coder.md

@@ -2,7 +2,7 @@
 name: coder
 description: Autonomous implementation agent. Given an issue description, explores existing patterns, implements the feature or fix, writes tests, runs the build in a self-correcting loop (up to 3 retries), and commits. Never pushes.
 tools: Agent, Bash, Edit, Glob, Grep, LS, MultiEdit, NotebookRead, Read, TodoWrite, WebFetch, WebSearch, Write, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
-model: claude-sonnet-5
+model: opus
 ---
 
 You are the autonomous coder agent for this project.

package/payload/agents/decomposer.md

@@ -1,7 +1,7 @@
 ---
 name: decomposer
 description: Decomposes a too-large issue into a dependency-ordered chain of spec-compliant sub-issues. Returns structured JSON with confidence verdict, reason, and fully authored sub-issue bodies ready for creation on the project platform.
-model: claude-sonnet-5
+model: sonnet
 ---
 
 You are the decomposer for the autonomous development pipeline.

package/payload/agents/docs-sync.md

@@ -2,7 +2,7 @@
 name: docs-sync
 description: Checks whether MR/PR code changes require updates to project docs, CLAUDE.md, or .claude/memory/. On autonomous MRs it applies the updates directly; on human MRs it reports the gaps for a comment.
 tools: Glob, Grep, LS, Read, Write, Edit
-model: claude-sonnet-5
+model: sonnet
 color: blue
 ---
 

package/payload/agents/e2e-test-writer.md

@@ -1,7 +1,7 @@
 ---
 name: e2e-test-writer
 description: Generates a single end-to-end (E2E) test spec file for a frontend issue, following the project's configured E2E framework, test directory, fixtures, test-data prefix, cleanup rules, and tags
-model: claude-sonnet-5
+model: opus
 ---
 
 You are an end-to-end (E2E) test writer. Given an issue, you produce one E2E test spec file that follows the project's configured E2E framework and conventions.

package/payload/agents/orchestrator.md

@@ -14,7 +14,7 @@ Your task: analyze an issue and classify it for autonomous implementation by the
 
 ## Scope Constraint
 
-A single coder agent session handles approximately **15 files / 600 lines of change** (default, see Capacities in the pipeline config). The coder uses the Sonnet model. Issues that touch many unrelated subsystems or require large architectural refactors exceed this limit and must be decomposed.
+A single coder agent session handles approximately **15 files / 600 lines of change** (default, see Capacities in the pipeline config). The coder uses the Opus model. Issues that touch many unrelated subsystems or require large architectural refactors exceed this limit and must be decomposed.
 
 ## Decision Criteria
 

package/payload/agents/performance-reviewer.md

@@ -2,7 +2,7 @@
 name: performance-reviewer
 description: Reviews changed data-access and hot-path code for confirmed scalability regressions such as repeated I/O, unbounded work, excessive loading, and missing batching or pagination
 tools: Glob, Grep, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput
-model: claude-sonnet-5
+model: sonnet
 color: yellow
 ---
 

package/payload/agents/release-mr.md

@@ -2,7 +2,7 @@
 name: release-mr
 description: Creates a release MR/PR from the integration branch to the production branch with a structured description listing changes, migrations, env changes, and a deploy checklist. Use when the user wants to prepare a release or merge the integration branch into production.
 tools: Bash, Glob, Grep, Read, TodoWrite
-model: claude-sonnet-5
+model: sonnet
 ---
 
 You are the release MR/PR agent. Your job is to analyze everything that changed on the integration branch since the last release to the production branch, then create (or update) a well-structured release request.

package/payload/agents/security-reviewer.md

@@ -2,7 +2,7 @@
 name: security-reviewer
 description: Reviews code for security vulnerabilities (authentication bypass, authorization flaws, injection, tenant/data isolation leaks, CSRF misconfiguration, sensitive data exposure) using confidence-based filtering to report only confirmed issues
 tools: Glob, Grep, LS, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput
-model: claude-sonnet-5
+model: sonnet
 color: red
 ---
 

package/payload/agents/test-fix.md

@@ -2,7 +2,7 @@
 name: test-fix
 description: Fixes failing tests in pipeline merge requests. Reads failing test files and their production source classes, determines root cause, fixes implementation or test as needed, verifies compilation, and commits. Never pushes.
 tools: Agent, Bash, Edit, Glob, Grep, LS, MultiEdit, NotebookRead, Read, TodoWrite, Write
-model: claude-sonnet-5
+model: opus
 ---
 
 You are the test-fix agent. Your job is to fix failing tests in a merge request, not to rewrite features.

package/payload/agents/test-writer.md

@@ -2,7 +2,7 @@
 name: test-writer
 description: Generates integration and unit tests that increase coverage for new or changed code, following the project's documented testing patterns, with a self-correcting compilation loop
 tools: Agent, Bash, Edit, Glob, Grep, LS, MultiEdit, NotebookRead, Read, TodoWrite, Write
-model: claude-sonnet-5
+model: opus
 color: green
 ---
 

package/payload/agents-omp/agent-architect.md

@@ -2,7 +2,7 @@
 name: agent-architect
 description: Weekly agent-improvement lab. Reads recently merged MRs/PRs, review comments, and stuck-MR postmortems, then proposes improvements to .claude/agents/*.md files as actionable platform issues (auto-filed with the pipeline's ready label). Output is a structured markdown report consumed by the CI script. Never auto-applies changes to CLAUDE.md or .claude/settings.json.
 tools: glob, grep, read
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the Agent Lab for this project's autonomous development pipeline.

package/payload/agents-omp/code-reviewer.md

@@ -2,7 +2,7 @@
 name: code-reviewer
 description: Reviews code for bugs, logic errors, security vulnerabilities, code quality issues, and adherence to project conventions, using confidence-based filtering to report only high-priority issues that truly matter
 tools: glob, grep, read, write, todo, web_search, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are an expert code reviewer specializing in modern software development across multiple languages and frameworks. Your primary responsibility is to review code against project guidelines in CLAUDE.md with high precision to minimize false positives.

package/payload/agents-omp/codebase-auditor.md

@@ -2,7 +2,7 @@
 name: codebase-auditor
 description: Periodic codebase auditor. Reads project conventions and docs, reads recently merged MR/PR file changes, and produces a focused report of critical convention violations and genuinely new undocumented patterns. Uses confidence-based filtering to report only issues that truly matter.
 tools: glob, grep, read
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the codebase auditor. You produce a periodic report of critical convention violations and genuinely new, reusable patterns worth documenting.

package/payload/agents-omp/coder.md

@@ -3,7 +3,7 @@ name: coder
 description: Autonomous implementation agent. Given an issue description, explores existing patterns, implements the feature or fix, writes tests, runs the build in a self-correcting loop (up to 3 retries), and commits. Never pushes.
 tools: task, bash, edit, glob, grep, read, todo, web_search, write, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
 spawns: test-writer, docs-sync
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-opus-5.5
 ---
 
 You are the autonomous coder agent for this project.

package/payload/agents-omp/decomposer.md

@@ -1,7 +1,7 @@
 ---
 name: decomposer
 description: Decomposes a too-large issue into a dependency-ordered chain of spec-compliant sub-issues. Returns structured JSON with confidence verdict, reason, and fully authored sub-issue bodies ready for creation on the project platform.
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the decomposer for the autonomous development pipeline.

package/payload/agents-omp/docs-sync.md

@@ -2,7 +2,7 @@
 name: docs-sync
 description: Checks whether MR/PR code changes require updates to project docs, CLAUDE.md, or .claude/memory/. On autonomous MRs it applies the updates directly; on human MRs it reports the gaps for a comment.
 tools: glob, grep, read, write, edit
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the documentation sync agent.

package/payload/agents-omp/e2e-test-writer.md

@@ -1,7 +1,7 @@
 ---
 name: e2e-test-writer
 description: Generates a single end-to-end (E2E) test spec file for a frontend issue, following the project's configured E2E framework, test directory, fixtures, test-data prefix, cleanup rules, and tags
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-opus-5.5
 ---
 
 You are an end-to-end (E2E) test writer. Given an issue, you produce one E2E test spec file that follows the project's configured E2E framework and conventions.

package/payload/agents-omp/orchestrator.md

@@ -14,7 +14,7 @@ Your task: analyze an issue and classify it for autonomous implementation by the
 
 ## Scope Constraint
 
-A single coder agent session handles approximately **15 files / 600 lines of change** (default, see Capacities in the pipeline config). The coder uses the Sonnet model. Issues that touch many unrelated subsystems or require large architectural refactors exceed this limit and must be decomposed.
+A single coder agent session handles approximately **15 files / 600 lines of change** (default, see Capacities in the pipeline config). The coder uses the Opus model. Issues that touch many unrelated subsystems or require large architectural refactors exceed this limit and must be decomposed.
 
 ## Decision Criteria
 

package/payload/agents-omp/performance-reviewer.md

@@ -2,7 +2,7 @@
 name: performance-reviewer
 description: Reviews changed data-access and hot-path code for confirmed scalability regressions such as repeated I/O, unbounded work, excessive loading, and missing batching or pagination
 tools: glob, grep, read, todo, web_search
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are a performance reviewer. Work with the language, framework, storage

package/payload/agents-omp/release-mr.md

@@ -2,7 +2,7 @@
 name: release-mr
 description: Creates a release MR/PR from the integration branch to the production branch with a structured description listing changes, migrations, env changes, and a deploy checklist. Use when the user wants to prepare a release or merge the integration branch into production.
 tools: bash, glob, grep, read, todo
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the release MR/PR agent. Your job is to analyze everything that changed on the integration branch since the last release to the production branch, then create (or update) a well-structured release request.

package/payload/agents-omp/security-reviewer.md

@@ -2,7 +2,7 @@
 name: security-reviewer
 description: Reviews code for security vulnerabilities (authentication bypass, authorization flaws, injection, tenant/data isolation leaks, CSRF misconfiguration, sensitive data exposure) using confidence-based filtering to report only confirmed issues
 tools: glob, grep, read, todo, web_search
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are an expert security reviewer. Your primary responsibility is to identify security vulnerabilities with high precision. False positives waste developer time and erode trust in the review process.

package/payload/agents-omp/test-fix.md

@@ -2,7 +2,7 @@
 name: test-fix
 description: Fixes failing tests in pipeline merge requests. Reads failing test files and their production source classes, determines root cause, fixes implementation or test as needed, verifies compilation, and commits. Never pushes.
 tools: task, bash, edit, glob, grep, read, todo, write
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-opus-5.5
 ---
 
 You are the test-fix agent. Your job is to fix failing tests in a merge request, not to rewrite features.

package/payload/agents-omp/test-writer.md

@@ -2,7 +2,7 @@
 name: test-writer
 description: Generates integration and unit tests that increase coverage for new or changed code, following the project's documented testing patterns, with a self-correcting compilation loop
 tools: task, bash, edit, glob, grep, read, todo, write
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-opus-5.5
 ---
 
 You are the test-writer agent. Your job is to write tests that increase coverage for new or changed code.

package/payload/ci-templates/claude-pipeline.gitlab-ci.yml

@@ -16,8 +16,9 @@
 # This template only reads its results (see the test-fix job's `needs:`).
 #
 # Override any PIPE_ variable in your own variables: block. Secrets
-# (ANTHROPIC_API_KEY, PIPE_BOT_TOKEN) are set as masked CI variables, never
-# here. Do NOT re-declare a secret in a job's variables: block as a same-name
+# (OPENROUTER_API_KEY, or ANTHROPIC_API_KEY with PIPE_PROVIDER=anthropic, and
+# PIPE_BOT_TOKEN) are set as masked CI variables, never here. Do NOT
+# re-declare a secret in a job's variables: block as a same-name
 # self-reference (FOO: "$FOO"): on GitLab it resolves to an empty string and
 # shadows the real project variable (pilot 2 finding, P6). Project variables
 # reach every job automatically. The GitHub workflows are different: there the
@@ -50,6 +51,7 @@ variables:
   # It is kept here as an explicit, harmless override.
   PIPE_PLATFORM: "gitlab"
   PIPE_HARNESS: "claude"                # "claude" (default, Claude Code CLI) or "omp" (Oh My Pi + OpenRouter)
+  PIPE_PROVIDER: "openrouter"           # Claude Code model provider: "openrouter" (default, OPENROUTER_API_KEY) or "anthropic" (ANTHROPIC_API_KEY)
   PIPE_CONFIG_PATH: ".claude/pipeline-config.md"
   PIPE_CONTEXT_DIR: "build/pipeline"
 
@@ -167,8 +169,11 @@ variables:
   # --- Caps + models ---------------------------------------------------------
   PIPE_FIX_LOOP_CAP: "2"
   # Main-loop models are passed as --model by the active harness. Defaults live
-  # in `pipeline-common.sh` under `scripts/lib/`. Users may explicitly set any
-  # PIPE_MODEL_* project CI variable. Subagents retain their frontmatter models.
+  # in `pipeline-common.sh` under `scripts/lib/` and follow PIPE_HARNESS and
+  # PIPE_PROVIDER (Opus 5.5 codes, Sonnet 5.5 reviews, Haiku 4.5 triages).
+  # Users may explicitly set any PIPE_MODEL_* project CI variable. Subagents
+  # retain their frontmatter tiers (opus/sonnet/haiku), which Claude Code
+  # resolves through ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU}_MODEL.
   PIPE_AGENT_ENV_ALLOWLIST: ""          # credential-like env names the agent-run build must receive (comma-separated; prefer empty)
 
   # --- Result files (defaults live under PIPE_CONTEXT_DIR) --------------------

package/payload/ci-templates/github/README.md

@@ -40,7 +40,7 @@ few names differ. The runner scripts in `../scripts/` are shared: they read
       - uses: actions/checkout@v4
         with: { ref: ${{ github.event.pull_request.head.ref }}, fetch-depth: 0, token: ${{ secrets.PIPE_BOT_TOKEN }} }
       - run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
-      - env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}, GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN }} }
+      - env: { OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}, ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}, GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN }} }
         run: bash "$PIPE_SCRIPTS_DIR/test-fix.sh"
   ```
 - **Fork PRs.** `workflow_run.pull_requests` is empty for PRs from forks (a

package/payload/ci-templates/github/claude-issue-pipeline.yml

@@ -21,7 +21,8 @@
 # Configuration:
 #   - Repository/org VARIABLES: PIPE_TARGET_BRANCH, PIPE_LABEL_* , PIPE_CODER_CAP,
 #     PIPE_SPEC_TEMPLATE_PATH, PIPE_GIT_NAME, PIPE_GIT_EMAIL, etc.
-#   - SECRETS: ANTHROPIC_API_KEY, PIPE_BOT_TOKEN (a bot PAT with issues +
+#   - SECRETS: OPENROUTER_API_KEY (or ANTHROPIC_API_KEY with the PIPE_PROVIDER
+#     variable set to anthropic), PIPE_BOT_TOKEN (a bot PAT with issues +
 #     contents + pull-requests + actions write). The bot PAT is required so the
 #     coder's push and the orchestrate -> code dispatch re-trigger workflows;
 #     the default GITHUB_TOKEN cannot.
@@ -73,8 +74,9 @@ env:
   PIPE_SPEC_TEMPLATE_PATH: ${{ vars.PIPE_SPEC_TEMPLATE_PATH || '.github/ISSUE_TEMPLATE/spec.md' }}
   PIPE_GIT_NAME: ${{ vars.PIPE_GIT_NAME || 'Pipeline Bot' }}
   PIPE_GIT_EMAIL: ${{ vars.PIPE_GIT_EMAIL || 'bot@pipeline.ci' }}
-  PIPE_MODEL_TRIAGE: ${{ vars.PIPE_MODEL_TRIAGE || 'haiku' }}
-  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE || 'claude-sonnet-5' }}
+  PIPE_PROVIDER: ${{ vars.PIPE_PROVIDER || 'openrouter' }}
+  PIPE_MODEL_TRIAGE: ${{ vars.PIPE_MODEL_TRIAGE }}
+  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE }}
   PIPE_AGENT_ENV_ALLOWLIST: ${{ vars.PIPE_AGENT_ENV_ALLOWLIST || '' }}
   # Runtime mapping onto the PIPE_ names the scripts read.
   PIPE_REPO: ${{ github.repository }}
@@ -99,6 +101,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run orchestrate
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN }}
         run: bash "$PIPE_SCRIPTS_DIR/orchestrate.sh"
@@ -127,6 +130,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run code
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN }}
           CODER_ISSUE: ${{ github.event.inputs.coder_issue }}

package/payload/ci-templates/github/claude-pipeline.yml

@@ -9,7 +9,8 @@
 #   - Repository/org VARIABLES (Settings > Variables): PIPE_TARGET_BRANCH,
 #     PIPE_LABEL_WIP, PIPE_LABEL_STUCK, PIPE_BOT_USER, PIPE_VERIFY_CMD, etc.
 #     Any PIPE_ variable overrides the defaults baked into the scripts.
-#   - SECRETS (Settings > Secrets): ANTHROPIC_API_KEY, and PIPE_BOT_TOKEN
+#   - SECRETS (Settings > Secrets): OPENROUTER_API_KEY (or ANTHROPIC_API_KEY
+#     with the PIPE_PROVIDER variable set to anthropic), and PIPE_BOT_TOKEN
 #     (a bot Personal Access Token). The default GITHUB_TOKEN cannot re-trigger
 #     workflows on its own push, so the fix loop needs a PAT to re-run review.
 #   - Vendor the ci-agent-platform repository's ci-templates/scripts/ into your
@@ -44,8 +45,9 @@ env:
   PIPE_COMMIT_REVIEWFIX: ${{ vars.PIPE_COMMIT_REVIEWFIX || 'Fix review findings' }}
   PIPE_GIT_NAME: ${{ vars.PIPE_GIT_NAME || 'Pipeline Bot' }}
   PIPE_GIT_EMAIL: ${{ vars.PIPE_GIT_EMAIL || 'bot@pipeline.ci' }}
-  PIPE_MODEL_REVIEW: ${{ vars.PIPE_MODEL_REVIEW || 'claude-sonnet-5' }}
-  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE || 'claude-sonnet-5' }}
+  PIPE_PROVIDER: ${{ vars.PIPE_PROVIDER || 'openrouter' }}
+  PIPE_MODEL_REVIEW: ${{ vars.PIPE_MODEL_REVIEW }}
+  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE }}
   PIPE_AGENT_ENV_ALLOWLIST: ${{ vars.PIPE_AGENT_ENV_ALLOWLIST || '' }}
   # Runtime mapping onto the PIPE_ names the scripts read.
   PIPE_REPO: ${{ github.repository }}
@@ -86,6 +88,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run review
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN || secrets.GITHUB_TOKEN }}
           PIPE_NO_GATE: "1"            # the gate step below owns the exit code
@@ -128,6 +131,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run review-fix
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN || secrets.GITHUB_TOKEN }}
           REVIEW_HAS_BUGS: "true"

package/payload/ci-templates/github/claude-test-fix.yml

@@ -49,7 +49,8 @@ env:
   PIPE_COMMIT_COVERAGE: ${{ vars.PIPE_COMMIT_COVERAGE || 'Add coverage tests' }}
   PIPE_GIT_NAME: ${{ vars.PIPE_GIT_NAME || 'Pipeline Bot' }}
   PIPE_GIT_EMAIL: ${{ vars.PIPE_GIT_EMAIL || 'bot@pipeline.ci' }}
-  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE || 'claude-sonnet-5' }}
+  PIPE_PROVIDER: ${{ vars.PIPE_PROVIDER || 'openrouter' }}
+  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE }}
   PIPE_AGENT_ENV_ALLOWLIST: ${{ vars.PIPE_AGENT_ENV_ALLOWLIST || '' }}
   PIPE_TEST_ARTIFACT: ${{ vars.PIPE_TEST_ARTIFACT || 'test-reports' }}
   PIPE_REPO: ${{ github.repository }}
@@ -91,6 +92,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run test-fix
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN || secrets.GITHUB_TOKEN }}
           PIPE_MR_IID: ${{ steps.pr.outputs.number }}

package/payload/ci-templates/scripts/lib/pipeline-common.sh

@@ -33,16 +33,24 @@ pipe_defaults() {
   : "${PIPE_CODER_CAP:=3}"
   : "${PIPE_ISSUE_SCAN:=20}"
   : "${PIPE_HARNESS:=claude}"
-  # Model defaults track the active harness. Each PIPE_MODEL_* variable remains
-  # explicitly overridable.
+  # Where the Claude Code harness sends its model calls: OpenRouter (default,
+  # one OPENROUTER_API_KEY) or Anthropic directly. omp always uses OpenRouter.
+  : "${PIPE_PROVIDER:=openrouter}"
+  # Model defaults track the active harness and provider: Opus codes, Sonnet
+  # reviews, Haiku triages. Each PIPE_MODEL_* variable remains explicitly
+  # overridable.
   if [ "$PIPE_HARNESS" = "omp" ]; then
     : "${PIPE_MODEL_TRIAGE:=openrouter/anthropic/claude-haiku-4.5}"
-    : "${PIPE_MODEL_CODE:=openrouter/anthropic/claude-sonnet-5}"
-    : "${PIPE_MODEL_REVIEW:=openrouter/anthropic/claude-sonnet-5}"
+    : "${PIPE_MODEL_CODE:=openrouter/anthropic/claude-opus-5.5}"
+    : "${PIPE_MODEL_REVIEW:=openrouter/anthropic/claude-sonnet-5.5}"
+  elif [ "$PIPE_PROVIDER" = "anthropic" ]; then
+    : "${PIPE_MODEL_TRIAGE:=claude-haiku-4-5}"
+    : "${PIPE_MODEL_CODE:=claude-opus-5-5}"
+    : "${PIPE_MODEL_REVIEW:=claude-sonnet-5-5}"
   else
-    : "${PIPE_MODEL_TRIAGE:=haiku}"
-    : "${PIPE_MODEL_CODE:=claude-sonnet-5}"
-    : "${PIPE_MODEL_REVIEW:=claude-sonnet-5}"
+    : "${PIPE_MODEL_TRIAGE:=anthropic/claude-haiku-4.5}"
+    : "${PIPE_MODEL_CODE:=anthropic/claude-opus-5.5}"
+    : "${PIPE_MODEL_REVIEW:=anthropic/claude-sonnet-5.5}"
   fi
   : "${PIPE_COMMIT_TESTFIX:=Fix test errors}"
   : "${PIPE_COMMIT_REVIEWFIX:=Fix review findings}"
@@ -135,7 +143,7 @@ pipe_defaults() {
     PIPE_METRICS_COMMIT_REPO PIPE_METRICS_REVIEW_AGENTS PIPE_METRICS_DEFECT_REVERT \
     PIPE_METRICS_DEFECT_REGRESSION PIPE_METRICS_DEFECT_REINTRODUCE \
     PIPE_METRICS_SNAPSHOT_DATE PIPE_METRICS_RAW_DIR PIPE_METRICS_MRS_FILE \
-    PIPE_HARNESS PIPE_MODEL_TRIAGE PIPE_MODEL_CODE PIPE_MODEL_REVIEW
+    PIPE_HARNESS PIPE_PROVIDER PIPE_MODEL_TRIAGE PIPE_MODEL_CODE PIPE_MODEL_REVIEW
 }
 
 pipe_log() { echo "[pipeline] $*"; }
@@ -222,14 +230,23 @@ pipe_agent_secret_var() {
   allow=" ${allow//,/ } "
   # Preserve only the active harness's built-in model credentials. Credentials
   # for the inactive harness fall through to the generic secret-name check.
+  # Claude Code on OpenRouter authenticates through ANTHROPIC_AUTH_TOKEN, which
+  # pipe_claude_provider_env copies from OPENROUTER_API_KEY, so the original
+  # (and any Anthropic OAuth token that could outrank it) is scrubbed.
   case "${PIPE_HARNESS:-claude}" in
     omp)
       [ "$name" = "OPENROUTER_API_KEY" ] && return 1
       ;;
     *)
-      case "$name" in
-        ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN|CLAUDE_CODE_OAUTH_TOKEN) return 1 ;;
-      esac
+      if [ "${PIPE_PROVIDER:-openrouter}" = "anthropic" ]; then
+        case "$name" in
+          ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN|CLAUDE_CODE_OAUTH_TOKEN) return 1 ;;
+        esac
+      else
+        case "$name" in
+          ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN) return 1 ;;
+        esac
+      fi
       ;;
   esac
   [[ "$allow" == *" $name "* ]] && return 1
@@ -272,6 +289,38 @@ pipe_require_harness() {
   fi
 }
 
+# --- Claude Code model provider ---------------------------------------------
+# OpenRouter serves the Anthropic Messages API at https://openrouter.ai/api, so
+# pointing ANTHROPIC_BASE_URL there and passing the OpenRouter key as
+# ANTHROPIC_AUTH_TOKEN routes every Claude Code call, subagents included,
+# through OpenRouter. ANTHROPIC_API_KEY must be present but empty: Claude Code
+# sends a non-empty one as a direct-Anthropic x-api-key.
+#
+# Agent frontmatter names model tiers (opus/sonnet/haiku), never concrete ids,
+# so one agent set serves both providers. ANTHROPIC_DEFAULT_*_MODEL pins each
+# tier to the provider's id for the current model; a project may override any.
+
+pipe_claude_provider_env() {
+  if [ "${PIPE_PROVIDER:-openrouter}" = "anthropic" ]; then
+    : "${ANTHROPIC_DEFAULT_OPUS_MODEL:=claude-opus-5-5}"
+    : "${ANTHROPIC_DEFAULT_SONNET_MODEL:=claude-sonnet-5-5}"
+    : "${ANTHROPIC_DEFAULT_HAIKU_MODEL:=claude-haiku-4-5}"
+  else
+    if [ -z "${OPENROUTER_API_KEY:-}" ]; then
+      pipe_log "FATAL: PIPE_PROVIDER=openrouter needs OPENROUTER_API_KEY as a masked CI variable or secret; set PIPE_PROVIDER=anthropic to run on ANTHROPIC_API_KEY instead"
+      exit 1
+    fi
+    : "${ANTHROPIC_BASE_URL:=https://openrouter.ai/api}"
+    ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY"
+    ANTHROPIC_API_KEY=""
+    : "${ANTHROPIC_DEFAULT_OPUS_MODEL:=anthropic/claude-opus-5.5}"
+    : "${ANTHROPIC_DEFAULT_SONNET_MODEL:=anthropic/claude-sonnet-5.5}"
+    : "${ANTHROPIC_DEFAULT_HAIKU_MODEL:=anthropic/claude-haiku-4.5}"
+    export ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN ANTHROPIC_API_KEY
+  fi
+  export ANTHROPIC_DEFAULT_OPUS_MODEL ANTHROPIC_DEFAULT_SONNET_MODEL ANTHROPIC_DEFAULT_HAIKU_MODEL
+}
+
 pipe_run_claude() {
   # $1 = agent label for metrics, $2 = skill invocation (e.g. "/review-mr"),
   # $3 = allowed tools (optional), $4 = model for the main loop (optional,
@@ -284,6 +333,7 @@ pipe_run_claude() {
   # checks that variable, or calls pipe_require_agent_ran below.
   local label="$1" skill="$2" tools="${3:-Agent,Read,Write,Edit,Glob,Grep,Bash}" model="${4:-}"
   pipe_require_harness claude
+  pipe_claude_provider_env
   local stdin_file; stdin_file=$(mktemp)
   cat > "$stdin_file" || true
   PIPE_AGENT_RC=0

package/payload/ci-templates/scripts/lib/usage-capture.sh

@@ -42,9 +42,11 @@ capture_claude() {
   end_ns=$(date +%s%N)
   local wall_ms=$(( (end_ns - start_ns) / 1000000 ))
 
-  # Extract the result event (last line that begins with {"type":"result")
+  # Extract the last result event. Match on the parsed type, not a line prefix:
+  # Claude Code 2.1 no longer emits "type" as the first key, and a prefix grep
+  # silently recorded every run as zero usage. fromjson? skips non-JSON lines.
   local result_line
-  result_line=$(grep '^{"type":"result"' "$stream_file" | tail -1 || true)
+  result_line=$(jq -cR 'fromjson? | select(.type? == "result")' "$stream_file" 2>/dev/null | tail -1 || true)
 
   local model input output cache_c cache_r cost duration
   if [ -n "$result_line" ]; then
@@ -67,9 +69,8 @@ capture_claude() {
 
   # Recover the user-facing text (concatenate all assistant text blocks) so
   # downstream consumers that read `claude`'s stdout still work.
-  grep '^{"type":"assistant"' "$stream_file" \
-    | jq -r '.message.content[]? | select(.type=="text") | .text' \
-    || true
+  jq -rR 'fromjson? | select(.type? == "assistant") | .message.content[]? | select(.type=="text") | .text' \
+    "$stream_file" 2>/dev/null || true
 
   # Write metrics record
   local record_stamp record_file

package/payload/skills/init-pipeline-config/SKILL.md

@@ -37,7 +37,7 @@ Source paths: `<root>` below means the first candidate that actually contains `t
 
 Do not hand the user a homework list. Walk them through it:
 
-1. Start with one confirmation of the detected basics: "The pipeline will target branch `<detected>` on `<platform>`. Correct?" Detected values are proposals to confirm, never open questions. When the detected platform is GitLab, ask in the same message which harness to run: Claude Code (default, needs `ANTHROPIC_API_KEY`) or omp + OpenRouter (needs `OPENROUTER_API_KEY` and accepts any OpenRouter model). Record the answer as `PIPE_HARNESS` (`claude` or `omp`). When the detected platform is GitHub, record `PIPE_HARNESS=claude`, state that omp and OpenRouter support is not shipped for GitHub yet, and do not offer omp as an option.
+1. Start with one confirmation of the detected basics: "The pipeline will target branch `<detected>` on `<platform>`. Correct?" Detected values are proposals to confirm, never open questions. Ask in the same message where Claude Code gets its models: OpenRouter (default, needs `OPENROUTER_API_KEY`) or Anthropic directly (needs `ANTHROPIC_API_KEY`). Record the answer as `PIPE_PROVIDER` (`openrouter` or `anthropic`) and `PIPE_HARNESS=claude`. Do not offer the omp harness; it stays available on GitLab for a project that asks for it by name (`PIPE_HARNESS=omp`, `OPENROUTER_API_KEY`), and is not shipped for GitHub.
 2. Split the remaining `TODO`s into two groups. **Defaultable:** the repo gives a defensible answer (coverage tooling absent means the policy is `not used`, Domain Check candidates read from the code, standard paths). Apply these without asking and keep them for the summary in step 4. **Genuinely open:** the repo gives no signal at all (a convention nobody wrote down, a check only a human knows about). Only these earn a question. Branch naming is not a question: with no repository convention use `<issue-iid>-<kebab-title>`, which is exactly what the runner accepts.
 3. Ask one scheduling question because frequency is a project policy, not a detectable technical fact: should the issue loop stay manual/disabled, run nightly on selected days, or use a custom cron? Recommend manual/disabled until both smoke tests pass. For a schedule, record days, local time, and time zone. Convert to UTC only for GitHub Actions; GitLab stores the chosen cron time zone. Then ask the other genuinely open items one concrete question at a time, in config order, each with a suggested default when possible. In a typical repo this is one to three questions total. Do not ask for the bot account username: the runner resolves it from the token at runtime (`platform_resolve_bot_user`); the account itself gets created with the token in phase 4. Apply each answer to the config immediately; the user never edits the file by hand during this phase.
 4. Close with one review summary of everything that was set: detected, defaulted, and answered, with the applied Domain Checks listed item by item. Invite the user to add, remove, or change anything; apply the edits. This summary is the safety net that lets steps 2-3 default aggressively.
@@ -50,7 +50,7 @@ Do this yourself; it is mechanical. The human only approves the diff. When the `
 **GitLab** (detected in phase 1):
 
 1. Create `.claude-pipeline/` and copy `<root>/ci-templates/claude-pipeline.gitlab-ci.yml` and `<root>/ci-templates/scripts/` into it.
-2. Edit the project `.gitlab-ci.yml`: ensure the stages the template needs (`orchestrate, code, test, review`), add the `include:` of the vendored template, and add the non-secret `PIPE_*` values from the config that differ from the template defaults (typically `PIPE_VERIFY_CMD`, `PIPE_TEST_REPORT_GLOB`) as top-level `variables:`. Always write `PIPE_TARGET_BRANCH` with the branch detected in phase 1, as a literal: a nested `$CI_DEFAULT_BRANCH` is not expanded inside `rules:` comparisons and would silently disable every MR job (E2E finding N-3). You know the values since phase 1; wiring them now keeps phase 4 free of commits. Do not touch the project's own jobs without asking. When phase 2 chose `omp`, add `PIPE_HARNESS: "omp"` to that same `variables:` block (the template default is `claude`).
+2. Edit the project `.gitlab-ci.yml`: ensure the stages the template needs (`orchestrate, code, test, review`), add the `include:` of the vendored template, and add the non-secret `PIPE_*` values from the config that differ from the template defaults (typically `PIPE_VERIFY_CMD`, `PIPE_TEST_REPORT_GLOB`) as top-level `variables:`. Always write `PIPE_TARGET_BRANCH` with the branch detected in phase 1, as a literal: a nested `$CI_DEFAULT_BRANCH` is not expanded inside `rules:` comparisons and would silently disable every MR job (E2E finding N-3). You know the values since phase 1; wiring them now keeps phase 4 free of commits. Do not touch the project's own jobs without asking. When phase 2 chose `anthropic`, add `PIPE_PROVIDER: "anthropic"` to that same `variables:` block (the template default is `openrouter`). When the project asked for omp, add `PIPE_HARNESS: "omp"` there instead (the template default is `claude`).
 3. Check the project's own test job: when neither its `rules:` nor a `workflow:` block makes it run in `merge_request_event` pipelines, the template's `test-fix` job can never fire (its `needs: test` finds no test job in the MR pipeline, E2E finding N-4). Tell the user and offer a concrete diff that adds the missing rule. Apply it only after they agree.
 4. Copy `<root>/templates/spec-issue.template.md` to `.gitlab/issue_templates/Spec.md` (or the path the user chose in phase 2). When that file already exists, show the diff and ask before replacing it. An issue template is project-owned content, and the ground rule above covers the config and the CI file by name, so this one has to be said explicitly.
 
@@ -75,7 +75,7 @@ Never take the values. And never dump the whole checklist at once: this phase is
 
 The steps, in this order (GitLab has 7, GitHub 6, number the counter accordingly):
 
-1. The model credential for the platform and chosen harness. For GitHub, guide only `ANTHROPIC_API_KEY` (https://console.anthropic.com/settings/keys) as a repository secret. For GitLab with Claude Code, guide `ANTHROPIC_API_KEY` as a masked CI variable. For GitLab with omp, guide `OPENROUTER_API_KEY` (https://openrouter.ai/settings/keys) as a masked CI variable. GitLab model credentials must not be protected when MR pipelines run from unprotected branches.
+1. The model credential for the chosen provider. For OpenRouter (the default, and always for omp), guide `OPENROUTER_API_KEY` (https://openrouter.ai/settings/keys). For `PIPE_PROVIDER=anthropic`, guide `ANTHROPIC_API_KEY` (https://console.anthropic.com/settings/keys), and on GitHub also the repository variable `PIPE_PROVIDER=anthropic`. On GitHub the credential is a repository secret, on GitLab a masked CI variable. GitLab model credentials must not be protected when MR pipelines run from unprotected branches.
 2. `PIPE_BOT_TOKEN`: GitLab project access token with `api` + `write_repository`, masked and hidden but not protected when ordinary unprotected feature branches need MR review/fix jobs; GitHub PAT with issues, contents, pull-requests and Actions write. Explain that protected GitLab variables work only when the project's protected-MR conditions are satisfied.
 3. GitLab only: `PIPE_TRIGGER_TOKEN` (Settings > CI/CD > Pipeline trigger tokens) for the orchestrate-to-code dispatch.
 4. The non-secret `PIPE_*` variables that differ from the defaults: these were already wired into the CI file in phase 3, so this step is normally a one-line "already wired, skipping". Only when something changed during phase 4 edit the CI file again (part of the walkthrough, no extra approval beyond showing the diff).
@@ -91,6 +91,6 @@ The smoke tests are the last step and the wizard drives them. The review smoke r
 
 1. Announce it in one line and prepare it: a branch named by the phase 2 convention, one small harmless change, an MR/PR against the target branch carrying the wip label. Then ask the one question of this phase: confirm the push plus MR/PR creation (ground rule: never push silently). One yes covers both. On GitLab without `glab`, create the MR with git push options (`git push -o merge_request.create -o merge_request.target=<target> -o merge_request.label=<wip label> origin <branch>`), no token or CLI needed. When no `merge_request_event` pipeline appears within about a minute of the MR existing, create it yourself with `POST /projects/:id/merge_requests/:iid/pipelines` (the bot token is set by phase 4). On GitHub without `gh`, push and print the compare URL for the user to open the PR.
 2. Check the run yourself with a single status query (`glab ci status` / `gh run list` for the run), or one short bounded wait, then report. Do not launch a blind polling loop that blocks for many minutes. If the jobs have not started or finished yet, say so and give the user the one command to re-check, rather than waiting them out. Scheduled pipelines and crons are best-effort and can lag by minutes, so an unstarted scheduled run is expected, not a failure. Expect, once it runs: the `review` job runs, a review comment from the bot account appears on the MR/PR, `review.env` and a metrics JSON land in `$PIPE_CONTEXT_DIR`. Report the result with a link to the MR/PR and the bot comment.
-3. On failure, read the job log yourself and say what is wrong and what to change. The common causes are a missing credential for the selected harness (`ANTHROPIC_API_KEY` or `OPENROUTER_API_KEY`), a `PIPE_BOT_TOKEN` without comment/write scope, and an explicitly set `PIPE_BOT_USER` not matching the token's account (leave it unset; the runner resolves it from the token).
+3. On failure, read the job log yourself and say what is wrong and what to change. The common causes are a missing credential for the selected provider (`OPENROUTER_API_KEY`, or `ANTHROPIC_API_KEY` with `PIPE_PROVIDER=anthropic`), a `PIPE_BOT_TOKEN` without comment/write scope, and an explicitly set `PIPE_BOT_USER` not matching the token's account (leave it unset; the runner resolves it from the token).
 4. After the review smoke test passes, offer a separate end-to-end issue-loop smoke test. This is the only test that proves issue -> triage -> code -> MR/PR rather than only the review half, so it is worth running. Run it only after explicit approval, then watch it through MR/PR creation. Steps: create one small issue whose full spec sits in the issue DESCRIPTION following `spec-issue.template.md` (a spec pasted into a comment does not count, the pipeline reads the spec from the description), apply the ready label, then start orchestrate IMMEDIATELY with a manual run rather than a schedule. On GitLab that is Run pipeline on the target branch with variable `PIPE_ORCHESTRATE=1` (pipeline source `web`, which the orchestrate rule already allows), on GitHub the `workflow_dispatch` of the issue pipeline. Do not set up a cron schedule for this test. A cron is only for ongoing autonomy later and adds minutes of best-effort delay, while the manual run starts within seconds. It spends another triage plus coder run, pushes a feature branch, and opens an MR/PR.
 5. Close with the final recap, one table: every setting that matters (target branch, branch convention, labels, verify command, report path, image, caps, models, schedule), its value, and its origin (detected / default / answered). Under the table, state what was committed and pushed, both smoke-test results (or `not run`), and whether the issue schedule is active or manual. End with a clear "done": the user must never have to ask what state the repo is in.