canon-ai 3.13.0 → 3.15.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +32 -0
- package/README.md +16 -6
- package/dist/cli/index.js +1012 -422
- package/dist/orchestrator/run-task.js +808 -532
- package/package.json +1 -1
- package/templates/.claude/skills/canon-pipeline/SKILL.md +3 -3
- package/templates/.claude/skills/canon-pipeline/recovery.md +14 -2
- package/templates/docs/pipeline-orchestrator.md +40 -24
- package/templates/docs/task-quality-log.md +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,38 @@
|
|
|
4
4
|
|
|
5
5
|
## [Unreleased]
|
|
6
6
|
|
|
7
|
+
## [3.15.0] — 2026-10-27
|
|
8
|
+
|
|
9
|
+
### Changed
|
|
10
|
+
|
|
11
|
+
- **Codex implementation runs at higher reasoning effort, and the full Codex model defaults to GPT-6.1 Sol.** Extra-small and small tasks now implement with the mini model at `xhigh` effort (was `medium`), and medium and large tasks at `max` (was `high`). Extra-large and delicate tasks stay on the full model at `high`, so `delicate` now means a stronger model rather than more effort. The full-model default moves from `gpt-6-sol` to `gpt-6.1-sol`; set `CODEX_MODEL_FULL=gpt-6-sol` to keep the old one. Effort has no environment override, so restoring the old effort settings means installing the previous release. `max` needs a Codex CLI and mini model that accept it; the pipeline guide names the verified pair and what to do if Codex rejects it.
|
|
12
|
+
- **QA defaults to Claude Haiku 5.5 instead of Sonnet.** The QA step runs `claude-haiku-5-5` at medium effort at every task size, including delicate tasks; spec, plan, and code review keep their models. QA no longer follows the light-tier model, so `CLAUDE_MODEL_LIGHT` stops reaching it: if you set only `CLAUDE_MODEL_LIGHT`, QA moves to Haiku, and if you also set `CLAUDE_MODEL`, QA uses that value. `CLAUDE_MODEL_QA` still wins over both. To keep your previous QA model, set `CLAUDE_MODEL_QA` to it (`sonnet` if you set nothing).
|
|
13
|
+
|
|
14
|
+
### Fixed
|
|
15
|
+
|
|
16
|
+
- **`canon run --interactive` applies the selected reasoning effort.** Interactive Codex sessions used to ignore it and run at your Codex config's or the model's default effort, even though canon logged the selected value.
|
|
17
|
+
|
|
18
|
+
## [3.14.0] — 2026-10-25
|
|
19
|
+
|
|
20
|
+
### Added
|
|
21
|
+
|
|
22
|
+
- **`canon completion` prints a shell completion script for bash, zsh, fish, and tcsh.** Add the line shown by `canon completion --help` to your shell startup file, and Tab completes commands, `task` subcommands, flags, phase names, review verdicts, task sizes, and task ids. Task ids complete from any directory in the repo, including a linked worktree, and completion never offers a flag canon would reject.
|
|
23
|
+
- **Every canon command answers `--help` in any position.** `canon run foo --help`, `canon task phase --help`, and the rest print that command's own usage to stdout and exit 0 without running anything; `canon task --help` lists all nine subcommands. Help wins over other argument errors.
|
|
24
|
+
|
|
25
|
+
### Changed
|
|
26
|
+
|
|
27
|
+
- **`canon run --reroute` works once implementation has begun.** A task can now be rerouted while implement is in progress or blocked, while code review is blocked at the loop limit, or after a review round or pre-flight rejection in the current loop. A task at implement with no review activity is still refused. In a bundle, a task at implement with no review activity is admitted alongside a qualifying task on the same branch, and a reroute that names only part of a shared-branch bundle is refused before anything changes, with the full command to run. The reroute prompts treat the prior round as possibly partial and pick up unfinished work along with the amendment, and the loop-limit message names the amend-and-reroute path.
|
|
28
|
+
- **`--pr` and `--push` push canon's own scaffold commits to the base branch.** A PR no longer stops at the base-divergence check until you push the base by hand. canon pushes only commits made of task scaffolds and pipeline telemetry, all or nothing; any other unpushed base commit still blocks. A base branch that exists only locally is created on origin only when every commit on it is canon's own.
|
|
29
|
+
- **`canon --help` is a short summary, and unknown flags are rejected on every command.** The summary lists one line per command and points to `canon <command> --help`. An unknown flag names itself and points to that command's help; `init`, `doctor`, and `stop` used to ignore unknown flags and now exit 1. `canon update` and `canon upgrade` reject stray words.
|
|
30
|
+
- **`canon task` requires a git repository.** Outside one, every `canon task` subcommand exits 1 with a single error naming the requirement and creates nothing. Before, `canon task new` succeeded outside git and later commands failed.
|
|
31
|
+
- **QA's "Human reroute?" quality-log column counts a human reroute at any phase**, not only a rejection at human review. Existing projects keep their old column description in `docs/task-quality-log.md`; edit that line if you want it to match.
|
|
32
|
+
|
|
33
|
+
### Fixed
|
|
34
|
+
|
|
35
|
+
- **`canon task` and `canon doctor` work from any subdirectory of a repository.** They read `tasks/` and `.canon/templates` from the repository root instead of the current directory, so `canon task list` in a subdirectory no longer prints "No tasks found." `canon task new` run inside a task's worktree creates the task in the main checkout, based on the main checkout's branch. `canon task list` no longer shows directories under `tasks/` whose names aren't valid task ids.
|
|
36
|
+
- **A rejected base push names the cause.** When origin's base has moved ahead, the message tells you to rebase the local base instead of suggesting branch protection. `--full-send` warns and skips the base push on a fetch failure instead of stopping.
|
|
37
|
+
- **`canon upgrade` with a bad argument prints a one-line error** instead of a stack trace, and `canon watch --help` prints its usage on separate lines.
|
|
38
|
+
|
|
7
39
|
## [3.13.0] — 2026-10-23
|
|
8
40
|
|
|
9
41
|
### Added
|
package/README.md
CHANGED
|
@@ -62,7 +62,7 @@ Canon is what happens when you treat those failure modes as engineering problems
|
|
|
62
62
|
| Agent forgets a past mistake | **`docs/lessons-learned.md`** — distilled cross-task wisdom that promotes into permanent rules over time |
|
|
63
63
|
| Reviews loop forever on the same disagreement | **Auto-block on runaway review loops** — per-size caps (see `pipeline-policy.ts`), escalation to human after the cap |
|
|
64
64
|
| Spec drift between conversation and pipeline | **File-based handoff protocol** — every artifact lives in `tasks/<id>/`, no copy-pasting |
|
|
65
|
-
| Sensitive surfaces (auth, payments) get refactored on theoretical grounds | **`delicate: true` flag** that
|
|
65
|
+
| Sensitive surfaces (auth, payments) get refactored on theoretical grounds | **`delicate: true` flag** that moves Codex spec review and implementation to the full model and triggers extra review discipline |
|
|
66
66
|
|
|
67
67
|
## How it works
|
|
68
68
|
|
|
@@ -79,14 +79,14 @@ The orchestrator drives this. For each task:
|
|
|
79
79
|
spec → spec_review → plan → implement → code_review → qa → human_review
|
|
80
80
|
```
|
|
81
81
|
|
|
82
|
-
The human gates between `spec_review` and `plan` — they approve the spec before the pipeline advances to implementation. Within the chain: automatic loops on `changes_requested` verdicts, model
|
|
82
|
+
The human gates between `spec_review` and `plan` — they approve the spec before the pipeline advances to implementation. Within the chain: automatic loops on `changes_requested` verdicts, model selection by task size, optional git-worktree isolation, session resumption across phases, and auto-block on runaway loops. See `docs/pipeline-orchestrator.md` for the full mechanics.
|
|
83
83
|
|
|
84
84
|
The pipeline supports two tiers:
|
|
85
85
|
|
|
86
86
|
- **Fast tier** (XS tasks): spec + plan in one Claude session, skip Codex spec review, human gate replaces it.
|
|
87
87
|
- **Full tier** (S / M / L / XL / delicate tasks): every phase runs separately, Codex reviews specs before they reach the human.
|
|
88
88
|
|
|
89
|
-
`delicate: true` (set in `status.json` at task creation) promotes any task to full tier and upgrades the model and effort for spec, plan, and code review, plus Codex spec review and implementation; QA and the cold-Codex review lens stay on their regular cells. Use it for sensitive surfaces — auth, payments, persistent storage, anything where a regression has unbounded blast radius.
|
|
89
|
+
`delicate: true` (set in `status.json` at task creation) promotes any task to full tier and upgrades the model and effort for spec, plan, and code review, plus moves Codex spec review and implementation to the full model; QA and the cold-Codex review lens stay on their regular cells. Use it for sensitive surfaces — auth, payments, persistent storage, anything where a regression has unbounded blast radius.
|
|
90
90
|
|
|
91
91
|
A single command runs a task end-to-end:
|
|
92
92
|
|
|
@@ -94,7 +94,7 @@ A single command runs a task end-to-end:
|
|
|
94
94
|
canon run <task-id>
|
|
95
95
|
```
|
|
96
96
|
|
|
97
|
-
`--step --expect <phase>` runs one phase with a phase-mismatch guard. `--pr` pushes and opens a draft PR at `human_review`. `--ship` runs *after* PR approval — it squash-merges the PR, deletes the branch, tears down the worktree, archives the task, and pulls the base branch (don't merge the PR manually first). `--reroute` resets a task
|
|
97
|
+
`--step --expect <phase>` runs one phase with a phase-mismatch guard. `--pr` pushes and opens a draft PR at `human_review`. `--ship` runs *after* PR approval — it squash-merges the PR, deletes the branch, tears down the worktree, archives the task, and pulls the base branch (don't merge the PR manually first). `--reroute` resets a task once implementation has begun: current phase `code_review`, `qa`, or `human_review` (any status or verdict), or `implement` when implement is in progress or blocked, code review is blocked, or code review already ran in the current loop (a review round or a pre-flight rejection). In a bundle, a sibling at implement pending with no current-loop activity is admitted alongside a task that qualifies when both belong to the same non-empty task branch. Full-tier tasks (S/M/L/XL or delicate) re-enter at `spec_review`, fast-tier tasks (XS) re-enter at `implement`. `--full-send` skips the spec gate and auto-opens a draft PR on clean QA. `--dry-run` prints planned phases without spawning agents.
|
|
98
98
|
|
|
99
99
|
Multiple task IDs in one invocation activates **bundle mode** — `canon run id1 id2 id3` runs all tasks together per phase under a single review loop with one commit history and one PR. Any full-tier task in the bundle promotes the entire bundle to full tier.
|
|
100
100
|
|
|
@@ -124,6 +124,15 @@ npm install -g --install-links github:tstraub89/canon-ai
|
|
|
124
124
|
|
|
125
125
|
> **Updating.** Once installed, use `canon update` rather than re-running `npm install` by hand — it resolves the exact install this binary is running from and installs the latest release from the npm registry by default. Use `--channel main` or `--ref <ref|sha>` for a GitHub development commit; each update records what it installed in `provenance.json` under `.canon` for future tooling to read. A project-local update pins the exact version (`--save-exact`); a global update has no manifest to pin.
|
|
126
126
|
|
|
127
|
+
### Shell completion
|
|
128
|
+
|
|
129
|
+
Add the line for your shell to its startup file. For zsh, put the line after `compinit`.
|
|
130
|
+
|
|
131
|
+
- bash (`~/.bashrc`): `eval "$(canon completion bash)"`
|
|
132
|
+
- zsh (`~/.zshrc`, after `compinit`): `eval "$(canon completion zsh)"`
|
|
133
|
+
- fish (`~/.config/fish/config.fish`): `canon completion fish | source`
|
|
134
|
+
- tcsh: run `canon completion tcsh > ~/.canon-completion.tcsh` once, then add `source ~/.canon-completion.tcsh` to `~/.tcshrc`. A multi-line script does not survive backtick `eval`.
|
|
135
|
+
|
|
127
136
|
### Set up in a repo
|
|
128
137
|
|
|
129
138
|
```bash
|
|
@@ -257,7 +266,7 @@ Pipeline sessions are headless, so nobody is at the keyboard to answer a permiss
|
|
|
257
266
|
- **Worktrees separate branch state by convention, not by enforcement.** Each task, or each bundle when you pass several task ids together, gets its own worktree and branch, and the pipeline's dirty-tree gates inspect the active worktree at phase boundaries. But Claude sessions are also given the main checkout via `--add-dir` and run with permissions skipped, so nothing stops a session from writing there, and an unrelated file dropped into the main checkout is not something those gates look for; tasks with `worktree: false` run in the main checkout outright. Validation commands run with your normal privileges.
|
|
258
267
|
- **Budget caps bound cost, not access.** Each headless Claude phase runs with `--max-budget-usd`; hitting the cap stops the session. It does not narrow what the session may do beforehand, and interactive sessions (`--interactive`) run uncapped.
|
|
259
268
|
- **Your code goes to the model providers.** Each agent phase sends prompts and repository context to the provider running it, Anthropic for Claude phases and OpenAI for Codex phases, with `code_review` using both, all through the Claude Code and Codex CLIs under whatever data terms your accounts have. Treat a `canon run` like any other agent session in that respect.
|
|
260
|
-
- **Git side effects need a flag.** The pipeline never pushes, opens PRs, merges, or publishes on its own. `--pr` pushes the task branch and opens a draft PR, stopping at `human_review`. `--ship` squash-merges that PR; it checks the task's phase, not whether anyone approved, so PR approval is your prerequisite (or your branch protection's), not something canon enforces. `--full-send` skips the human spec gate and opens the draft PR on clean QA, still stopping before merge
|
|
269
|
+
- **Git side effects need a flag.** The pipeline never pushes, opens PRs, merges, or publishes on its own. `--pr` pushes the task branch and opens a draft PR, stopping at `human_review`. `--ship` squash-merges that PR; it checks the task's phase, not whether anyone approved, so PR approval is your prerequisite (or your branch protection's), not something canon enforces. `--full-send` skips the human spec gate and opens the draft PR on clean QA, still stopping before merge. `--pr`, `--push` and full-send first push canon's own unpushed scaffold and telemetry commits on the base, creating it on origin if missing when every local-only commit is canon-safe or already published. Other unpushed base commits block unless `--allow-divergent-base` is set; that escape does not apply to a missing remote base. On a `delicate` task, `--full-send` refuses without `--force`.
|
|
261
270
|
|
|
262
271
|
Run canon on repositories where you would be comfortable running your test suite unattended. If that is not your situation, keep it to a machine or container scoped for the purpose. Replacing the blanket permission skip with a narrower confinement is on the roadmap; the constraint to solve is that adopter validation commands legitimately need network and system access the sandbox would block. Security reports go through [SECURITY.md](SECURITY.md).
|
|
263
272
|
|
|
@@ -267,6 +276,7 @@ Run canon on repositories where you would be comfortable running your test suite
|
|
|
267
276
|
|---|---|
|
|
268
277
|
| `canon init` | Install canon into the current repo. Refuses symlinks at destination files or parent directories; replace them with regular files/directories first. |
|
|
269
278
|
| `canon doctor` | Verify environment and canon setup — Node/git versions, Claude Code (≥ 2.1.72) and Codex CLI presence, codex project trust, recommended-permission coverage in `.claude/settings.json`, and that any local settings file is gitignored. |
|
|
279
|
+
| `canon completion <shell>` | Print a completion script for bash, zsh, fish, or tcsh; see Shell completion. |
|
|
270
280
|
| `canon task new <id> "Title"` | Scaffold a new task from templates |
|
|
271
281
|
| `canon task list` | Show all tasks and their pipeline phase |
|
|
272
282
|
| `canon task phase <id> <phase> <status>` | Advance a task phase manually |
|
|
@@ -275,7 +285,7 @@ Run canon on repositories where you would be comfortable running your test suite
|
|
|
275
285
|
| `canon run <id> --step --expect <phase>` | Run one phase then stop, with a phase-mismatch guard |
|
|
276
286
|
| `canon run <id> --pr` | Push branch and open a draft PR (at `human_review`) |
|
|
277
287
|
| `canon run <id> --push` | Push branch only, no PR |
|
|
278
|
-
| `canon run <id> --reroute` | Reset a task
|
|
288
|
+
| `canon run <id> --reroute` | Reset a task once implementation has begun: current phase `code_review`, `qa`, or `human_review` (any status or verdict), or `implement` when implement is in progress or blocked, code review is blocked, or code review already ran in the current loop (a review round or a pre-flight rejection). In a bundle, a sibling at implement pending with no current-loop activity is admitted alongside a task that qualifies when both belong to the same non-empty task branch. Requires the next amendment section (`## Amendment`, then `## Amendment Round N`) appended to `spec.md` first; full-tier re-enters at `spec_review`, fast-tier at `implement`. |
|
|
279
289
|
| `canon run <id> --full-send` | Skip the spec gate and auto-open a draft PR after clean QA |
|
|
280
290
|
| `canon run <id> --ship` | After PR approval: squash-merge, delete branch, tear down worktree, archive the task, pull base branch. Don't merge the PR manually first. |
|
|
281
291
|
| `canon run <id> --dry-run` | Print each planned phase and exit without spawning any agent |
|