Automate CI workflows and fix documentation

.github/workflows/review-response.yml

@@ -35,8 +35,10 @@ jobs:
 
       - name: Install OpenCode CLI
         run: |
-          curl -fsSL https://opencode.ai/install.sh | sh
-          echo "$HOME/.local/bin" >> "$GITHUB_PATH"
+          npm install -g opencode
+          NPM_PREFIX="$(npm config get prefix)"
+          echo "${NPM_PREFIX}/bin" >> "$GITHUB_PATH"
+          opencode --version
 
       - name: Prepare review context
         id: context

docs/development/ci.md

@@ -36,14 +36,14 @@ API key for calling Opencode's Responses endpoint with the `opencode/gpt-5-nano`
 opencode auth token create --label "ci-release" --scopes responses.create
 # Copy the token and store it as the OPENCODE_API_KEY secret
 ```
-If you run a self-hosted Opencode endpoint, also add `OPENCODE_API_URL` (optional) to override the default `https://api.openai.com/v1/responses` base URL.
+If you run a self-hosted Opencode endpoint, also add `OPENCODE_API_URL` (optional) to override the default `https://opencode.ai/zen/v1/responses` base URL.
 
 ### Optional overrides
 - `RELEASE_BASE_REF`: force the analyzer to diff from a specific tag/commit (useful when backporting release branches).
 
 ## Branch protection
 - `main` requires pull requests for all changes; direct pushes and force pushes are disabled.
-- Required status checks: `lint`, `test (node-version: 20.x)`, and `test (node-version: 22.x)` must pass before the merge button unlocks. (Type checking runs inside the `lint` job.)
+- Required status checks: `Lint & Typecheck`, `Test (20.x)`, and `Test (22.x)` must pass before the merge button unlocks. These names mirror the workflow job `name` fields, so keep them in sync whenever CI definitions change. (Type checking runs inside the `Lint & Typecheck` job.)
 - No human approvals are required right now—the PR gate exists for automated reviewers and CI visibility.
 - Branches must be up to date with `main` before merging because strict status checks are enabled.
 

scripts/detect-release-type.mjs

@@ -129,7 +129,7 @@ async function callOpencodeModel(systemPrompt, userPrompt) {
 	if (!apiKey) {
 		throw new Error("OPENCODE_API_KEY is not configured");
 	}
-	const url = process.env.OPENCODE_API_URL || "https://api.openai.com/v1/responses";
+	const url = process.env.OPENCODE_API_URL || "https://opencode.ai/zen/v1/responses";
 	const schema = {
 		name: "release_version",
 		schema: {

spec/branch-protection.md

@@ -8,9 +8,9 @@
 1. Enable protection rules via GitHub REST API (or `gh api`) targeting `main` branch.
 2. Require pull request reviews before merging (enforce at least 1 approval, disallow bypass via force push/direct push).
 3. Require status checks for:
-   - `lint` job (covers `pnpm lint` + `pnpm typecheck`).
-   - `test (node-version: 20.x)` job.
-   - `test (node-version: 22.x)` job.
+   - `Lint & Typecheck` job (covers `pnpm lint` + `pnpm typecheck`).
+   - `Test (20.x)` job.
+   - `Test (22.x)` job.
 4. Allow admins to bypass? (Default: include administrators so even admins must follow rules.)
 5. Document the rule in `docs/development/ci.md` or similar so contributors know PRs + green checks are mandatory.
 
@@ -24,3 +24,18 @@
 
 ### Phase 3 – Documentation
 - Update `docs/development/ci.md` (or README) with short section describing required checks + PR requirement.
+
+## Follow-Up: Wrong Job Contexts (2025-11-15)
+- Prior to this fix the protection settings required contexts `lint`, `test (node-version: 20.x)`, `test (node-version: 22.x)`.
+- Actual GitHub check names (from `gh run view 19381469238 --json jobs`) are `Lint & Typecheck`, `Test (20.x)`, `Test (22.x)`.
+- Result: branch protection never saw matching checks, so merges into `main` could proceed without real gating.
+
+### Remediation Steps
+1. Update branch protection via `gh api` (PUT) so `required_status_checks.checks` includes:
+   - `{ context: "Lint & Typecheck" }`
+   - `{ context: "Test (20.x)" }`
+   - `{ context: "Test (22.x)" }`
+2. Keep `strict: true` and `enforce_admins: true`.
+3. Document the exact job names in `docs/development/ci.md` and CONTRIBUTING so maintainers know which checks must stay in sync with workflow `name` fields.
+4. Optionally add a CI test (or script) that fails if branch protection contexts drift from workflow job names (e.g., script hitting REST API + parsing `.github/workflows/ci.yml`).
+

spec/ci-release-automation.md

@@ -3,7 +3,7 @@
 ## Summary
 - Expand `.github/workflows/ci.yml:1-59` so testing and linting jobs run on every push (any branch) and every PR, add a dedicated mutation-testing job for PRs to `main`, and gate a release job so it only executes after successful pushes to `main`.
 - Introduce a lint workflow powered by Biome (add `@biomejs/biome` + `"lint": "biome check ."` in `package.json:30-38` and a project-level `biome.json` config) so the GitHub Action can run `pnpm lint` deterministically.
-- Create an `opencode`-powered release analysis tool (`scripts/detect-release-type.mjs`) that summarizes commits since the last tag, calls `https://api.openai.com/v1/responses` with `model: "opencode/gpt-5-nano"`, and emits structured JSON describing breaking changes + release type so the workflow can pick `major|minor|patch` intelligently.
+- Create an `opencode`-powered release analysis tool (`scripts/detect-release-type.mjs`) that summarizes commits since the last tag, calls `https://opencode.ai/zen/v1/responses` with `model: "opencode/gpt-5-nano"`, and emits structured JSON describing breaking changes + release type so the workflow can pick `major|minor|patch` intelligently.
 - Build a release job that (1) runs the analyzer, (2) bumps the version via `pnpm version <next>` (letting Git create a tag), (3) publishes to npm using `NPM_TOKEN`, and (4) creates a GitHub Release whose notes embed the analyzer’s output.
 - Document CI secrets and npm token setup in a new `docs/development/ci.md`, covering how to set `NPM_TOKEN`, `OPENCODE_API_KEY`, and any optional overrides for the analyzer.
 
@@ -20,7 +20,7 @@
 - Create `biome.json` with project conventions for lint + formatting.
 - Author `scripts/detect-release-type.mjs` that:
   - Discovers the previous tag (fallback: root commit) and collects `git log --no-merges` plus `git diff --stat` summaries.
-  - Builds a structured prompt and calls `https://api.openai.com/v1/responses` with `model: "opencode/gpt-5-nano"` using `OPENCODE_API_KEY`.
+  - Builds a structured prompt and calls `https://opencode.ai/zen/v1/responses` with `model: "opencode/gpt-5-nano"` using `OPENCODE_API_KEY`.
   - Parses the assistant message (JSON block), falls back to `patch` if parsing fails, computes the next semver, and writes `{ releaseType, nextVersion, summary, breakingChanges }` to stdout/file.
 
 ### Phase 2 – Workflow Updates

spec/opencode-zen-endpoint.md

@@ -0,0 +1,25 @@
+# Spec: Default OpenCode Release Analyzer Endpoint
+
+## Context
+Issue #9 reports that `scripts/detect-release-type.mjs` incorrectly defaults to the OpenAI responses endpoint. The release analyzer must target the Zen API (`https://opencode.ai/zen/v1/responses`) so that authenticated CI calls reach the managed Opencode service. Current docs (`docs/development/ci.md:33-40`) also describe the wrong default, leading contributors to configure the release workflow incorrectly.
+
+## References
+- Issue: [#9](https://github.com/open-hax/codex/issues/9)
+- Workflow docs: `docs/development/ci.md:33-44`
+- Analyzer: `scripts/detect-release-type.mjs:127-187`
+- Related spec: `spec/ci-release-automation.md`
+
+## Requirements / Definition of Done
+1. `scripts/detect-release-type.mjs` must default `OPENCODE_API_URL` to `https://opencode.ai/zen/v1/responses` when the env var is unset.
+2. `docs/development/ci.md` needs updated prose indicating the Zen endpoint is the automatic default, noting that `OPENCODE_API_URL` is optional for overriding the base URL.
+3. Confirm no other files reference the old `https://api.openai.com/v1/responses` default; update if discovered (grep before/after).
+4. Document the change in this spec (change log) and summarize in the final response.
+
+## Plan
+1. Inspect analyzer script to confirm only the `url` constant needs adjusting (line ~132). Update string and retain env override support.
+2. Update CI documentation to describe the Zen default and clarify overriding instructions.
+3. Run `rg "api.openai.com/v1/responses"` to ensure no stray references remain.
+4. Update this spec with a change log entry.
+
+## Change Log
+- 2025-11-15: Switched analyzer default endpoint to `https://opencode.ai/zen/v1/responses` and updated CI docs to describe the Zen base URL.

spec/pr-2-conflict-analysis.md

@@ -0,0 +1,24 @@
+# PR #2 Conflict Analysis
+
+## Context
+- Local work was done on `feature/review-automation`, then `git fetch && git merge main` was executed from that branch.
+- `main` in the local worktree had not been updated since before commit `f3dd0e160cddbd2f08aa4294bd5b007d6b79d18b` ("Automate CI and review workflows"), so merging it brought in no new changes.
+- `git checkout main` now shows `Your branch is behind 'origin/main' by 1 commit`, confirming that the local `main` is stale relative to `origin/main`.
+- PR #2 (`bug-fix/compaction` → `main`) must merge into `origin/main`, which already contains the CI automation changes above; because `feature/review-automation` has not incorporated that commit, GitHub still flags conflicts.
+
+## Code References
+- `.github/workflows/ci.yml:1` – workflow rewritten in commit `f3dd0e1`; PR #2 still has the previous structure.
+- `scripts/detect-release-type.mjs:1` – new script created in the same commit that the feature branch is missing.
+- `pnpm-lock.yaml:1` – lockfile introduced in `origin/main`; branch still tracks the removed `bun.lock` / `package-lock.json`, so GitHub reports conflicts in those files.
+
+## Existing Issues / PRs
+- PR #2 "this is a thing" (head: `bug-fix/compaction`, base: `main`).
+
+## Definition of Done
+- Explain why GitHub reports conflicts even though `git merge main` on the feature branch says "Already up to date".
+- Provide concrete steps to sync the branch with the true base (`origin/main`) so that the PR no longer conflicts.
+
+## Requirements
+1. Update local `main` with `git checkout main && git pull --ff-only origin main`.
+2. Rebase or merge `origin/main` into `feature/review-automation` (or `bug-fix/compaction`, depending on the PR head) so that commit `f3dd0e1` and its files are present locally.
+3. Resolve resulting conflicts locally (expect them in `.github/workflows/ci.yml`, `package-lock.json`, `.gitignore`, etc.), run tests, and push the updated branch.

spec/review-response-automation.md

@@ -37,7 +37,7 @@
   - Checkout PR head (fetch-depth 0).
   - Setup Node 22.
   - Install pnpm + dependencies if needed? (only Node + script).
-  - Install OpenCode CLI via official install script.
+  - Install OpenCode CLI via `npm install -g opencode` (and add the npm global bin dir to `PATH`).
   - Run context script; capture outputs.
   - Execute `opencode run --agent review-response --model opencode/big-pickle --file review-context.md "Follow the instructions in review-context.md"` with env `OPENCODE_API_KEY` and `GITHUB_TOKEN`.
   - If git diff exists, create branch `review/comment-${{ steps.context.outputs.comment_id }}` (append timestamp if collision), commit with message referencing comment + PR, push, and `gh pr create --base base_ref --head branch --title ... --body ...` (GH_TOKEN env). Ensure job gracefully exits if no changes.

spec/review-response-cli-fix.md

@@ -0,0 +1,13 @@
+# Review Response CLI Installation Fix
+
+## Context
+- The review-response workflow (`.github/workflows/review-response.yml:36-40`) installs the OpenCode CLI via `curl -fsSL https://opencode.ai/install.sh | sh`. That install script now returns HTTP 404, leaving the runner without the `opencode` binary and causing downstream steps to fail (`opencode run ...` in lines 52-60 cannot execute).
+- User request: "do a global node module install" so that the automation can rely on npm to fetch the CLI instead of a missing shell script.
+- Affected documentation: `spec/review-response-automation.md:35-44` still states "Install OpenCode CLI via official install script".
+
+## Definition of Done
+1. Update `.github/workflows/review-response.yml` so the "Install OpenCode CLI" step installs the CLI via a global Node module (`npm install -g opencode`) and guarantees the binary path is added to `$PATH` (`$GITHUB_PATH`).
+2. Ensure the workflow still sets up Node 22 first, then installs the CLI, and that the rest of the job uses the same binary.
+3. Update `spec/review-response-automation.md` (and any other docs referencing the old install script) to mention the npm global install method.
+4. Optionally add a quick sanity check (e.g., `opencode --version`) in the workflow step to surface install issues early.
+5. Confirm no other files still reference the defunct install script URL.