@erclx/canon 4.9.1 → 4.10.0

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "4.9.1",
+  "version": "4.10.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/claude-autoship/SKILL.md

@@ -158,13 +158,18 @@ This chain owns the receipt's lifetime, which is what makes the Output block's c
 
 Invoke `canon:git-ship`. That body owns the sequence, being the verify gate, memory capture, both doc syncs, staging, the commit grouping, the branch rename, the pull request, the CI watch, and the scoped memory review, along with the reason each step sits where it does. This step used to restate that list and the two drifted apart with nothing comparing them, so read the order there and never here.
 
-One thing this chain adds. Mark the pull request as a draft as soon as `git-ship`'s pull request step returns, ahead of its CI watch:
+One thing this chain adds. Mark the pull request as a draft as soon as `git-ship`'s pull request step returns, ahead of its CI watch, then read the flag back:
 
 ```bash
-gh pr ready --undo
+gh pr ready --undo <number>
+gh pr view <number> --json isDraft
 ```
 
-Placement is the whole point of naming it. Marking after the watch leaves the pull request ready to merge for as long as CI runs, which is the window an unattended worker's branch is least supervised.
+Name the number `git-ship`'s pull request step returned on both calls rather than leaving either to resolve by branch, since each matches a head ref and ignores state, so a reused branch name reaches a merged namesake. The read is where that costs the most, answering with the wrong record's flag, and the write above it errors rather than mutating one.
+
+Report what the read returned rather than what the command printed, since the exit says the call ran and says nothing about the state. A `true` reports a draft. A `false` reports the pull request as opened ready and unsupervised, and the chain stops there. Never re-issue the undo on a disagreeing read, which fights whoever readied it instead of guarding anything.
+
+Placement is why the call sits ahead of the watch rather than after it. Marking afterwards leaves the pull request unmarked for the whole CI run, which is the stretch an unattended worker's branch is least supervised. What the mark buys is a reader learning the pull request has had no review yet. It buys no bound on that stretch: readying a pull request to merge lifts the mark, GitHub requires it before a merge, and it is the operator's act to take.
 
 `git-ship` verifies again at its own gate, which repeats this chain's Step 3 on the run where nothing stopped. That cost is deliberate: four of the stop points in the table below hand the run straight back to that body, and a gate the chain skips for being redundant is a gate no resumed run ever meets.
 
@@ -173,16 +178,18 @@ Placement is the whole point of naming it. Marking after the watch leaves the pu
 Respond with up to five lines:
 
 ```plaintext
-✅ Autoshipped (draft): <PR url>
+✅ Autoshipped (<state>): <PR url>
 <N minor findings kept in .canon/review/branch/review-<slug>.md>
 <N facts routed to context entries>
 <N memories captured in .canon/memory/>
 <Memory proposal at .canon/review/memory/memory-review-<slug>.md>
 ```
 
+`<state>` is whatever the Step 7 read returned, being `draft` or `ready, unsupervised`, rather than the state the undo asked for. Writing the word `draft` there unconditionally is what this line used to do, and it named a state no step had read.
+
 Omit the second line if there were no minor findings, and the third if nothing routed. Omit the fourth and fifth if `claude-memory-capture` wrote no memory file this session, since an empty pen means no scoped review and no proposal. A run that routes every fact and writes none is the shape to expect, and it reports three lines.
 
-This block replaces the one `git-ship` closes on rather than following it. The two carry the same three trailing lines and differ on the two above them, since the first names the draft state and the second reports the minor findings Step 6 kept, neither of which that body has a counterpart for. Emitting both reports one run twice and buries the draft under a `✅ Shipped` that does not name it.
+This block replaces the one `git-ship` closes on rather than following it. The two carry the same three trailing lines and differ on the two above them, since the first names the state the read returned and the second reports the minor findings Step 6 kept, neither of which that body has a counterpart for. Emitting both reports one run twice and buries the state under a `✅ Shipped` that does not name it.
 
 ## Failure recovery
 

package/claude/skills/claude-orchestrate/SKILL.md

@@ -119,7 +119,7 @@ Write no shape for a correction. A correction is a sentence, and a format for ad
    - Resolve the target at the moment of sending with `canon sessions list --branch`, never from a mapping written down earlier, since names rotate as sessions end and one recorded earlier in a session has failed inside the hour. The runbook read at step 5 routes on the count and the confidence it answers with
    - Open the message with the worktree and branch the sender believes the reader holds, asking to be corrected, whenever that mapping is inferred rather than confirmed
    - Name the skill for the reader to run rather than writing an invocation, which arrives as text
-   - Read the pull request's own draft flag rather than the state a worker reports, since two reported a draft that read ready inside ninety seconds
+   - Read the pull request's own draft flag rather than the state a worker reports, since two reported a draft that read ready inside ninety seconds, and report what the read returned and when rather than the state alone. The flag settles the question only once the worker's chain has run its undo, and nothing marks that moment, so a read taken between the pull request opening and that call sees a genuinely ready pull request about to become a draft. That is how a poll on `#1307` told an operator the opposite of what the worker had said.
 
 A session is reachable when it appears in a live listing, which reads what each session registered on disk rather than probing it, and a message carries plain text and no authority. When no live session holds the branch, report the invocation for the human, naming the branch, the pull request, and the skill to run, then stop. Retrying or waiting leaves the loop believing it is open while nothing acts on it. Every dispatch in the trial behind this step found a live session, so this branch stands on reasoning rather than on observation.
 

package/claude/skills/claude-worker/SKILL.md

@@ -25,6 +25,7 @@ running and re-invoking it would restart the build.
 - Resolve `.canon/plans/`, `.canon/tasks/`, `.canon/review/`, and `.canon/memory/` at the main worktree root, never against the linked worktree this session builds in. Those folders are gitignored, so `git worktree add` never creates them and the copy beside the build is absent rather than empty.
 - Report a plan that fails to resolve as unreadable from here, naming the main-root path. Reporting the task as having no plan is true where this session stands and wrong about the world, and a reader with no second tree to check cannot separate the two.
 - Build the plan the launch named. Do not write a second one when the path fails to resolve, since a row that cites a plan already has one and drafting another produces two plans for one row.
+- Report a draft flag reading ready once, and leave it cleared. The ship chain marks the pull request a draft and no step anywhere un-marks, so a flag reading ready afterwards was lifted by a person readying it to merge, which GitHub requires and is theirs to take. Re-drafting fights them, which four sessions did on 2026-08-31 on a belief no surface in the tree states.
 
 ## The board is read-only
 

package/docs/ai-workflow.md

@@ -80,7 +80,7 @@ When features are independent, run them in parallel instead of sequentially. Use
 - Invoke `canon:claude-feature` in each session. Plans land at the main worktree root as `.canon/plans/feature-<slug>.md`, one per feature, no collisions. Small features stay in chat and skip the file.
 - Implement, verify, and review each feature independently. `claude-review` and `claude-ui-test` write per-branch files at the main worktree root (`review/branch/review-<slug>.md`, `review/ui-checklist-<slug>.md`), so parallel sessions do not overwrite each other. The slug is the branch name with any leading type segment dropped, so `feat/jwt-expiration` and the plan at `feature-jwt-expiration.md` meet on one name
 - Ship each worktree separately with `canon:git-ship`
-- For full autonomy per worktree, invoke `canon:claude-autoship` instead of the manual chain. Approve the plan, walk away, come back to draft PRs.
+- For full autonomy per worktree, invoke `canon:claude-autoship` instead of the manual chain. Approve the plan, walk away, come back to a pull request the chain marked as a draft and then read the flag back on. The mark says the work has had no review yet, and it holds no window, since readying a pull request to merge lifts it and is the operator's act.
 
 To run several worktrees as a coordinated flow rather than ad hoc, assert the orchestrator role in one warm session with `canon:claude-orchestrate`. It holds the cross-feature call, plans each feature itself or dispatches a cold planner under `canon:claude-planner` to write the plan, refills the ready queue so a free worker never waits, and reviews each worker's PR with `canon:claude-pr-review`, then tells the session holding that branch to run `canon:claude-address-review` whenever the pass posted a finding at any severity, which is the same threshold `canon:claude-pr-review` states and posts its open heading under. The human launches workers and merges. See [operating model](operating-model.md) for the full loop.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "4.9.1",
+  "version": "4.10.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/scripts/core/install-check.sh

@@ -8,7 +8,8 @@ PROJECT_ROOT="${PROJECT_ROOT:-$(cd "$SCRIPT_DIR/../.." && pwd)}"
 source "$PROJECT_ROOT/scripts/lib/ui.sh"
 
 TMP_ROOT="$PROJECT_ROOT/.canon/tmp/install-check"
-CLONE_DIR="$TMP_ROOT/clone"
+PACK_DIR="$TMP_ROOT/pack"
+EXTRACT_DIR="$TMP_ROOT/extract"
 TARGET_DIR="$TMP_ROOT/target"
 KEEP=0
 
@@ -19,12 +20,13 @@ for arg in "$@"; do
     cat <<HELP
 Usage: scripts/core/install-check.sh [--keep]
 
-Verifies the README install path end to end:
-  1. Clones this repo into .canon/tmp/install-check/clone
-  2. Runs bun install in the clone
-  3. Runs the CLI with --help to confirm it executes
-  4. Scaffolds a fresh project in .canon/tmp/install-check/target
-  5. Runs canon init and asserts a scaffold landed
+Verifies the published install path end to end:
+  1. Packs this repo into a tarball at .canon/tmp/install-check/pack
+  2. Extracts it and asserts scripts/sandbox is absent from the tree
+  3. Runs bun install --production in the extracted tree
+  4. Runs the CLI with --help from the extracted tree to confirm it resolves
+  5. Scaffolds a fresh project in .canon/tmp/install-check/target
+  6. Runs canon init from the extracted package and asserts a scaffold landed
 
 Flags:
   --keep    Keep the tmp tree on exit for inspection
@@ -45,21 +47,31 @@ cleanup() {
 trap cleanup EXIT
 
 rm -rf "$TMP_ROOT"
-mkdir -p "$TMP_ROOT"
+mkdir -p "$PACK_DIR" "$EXTRACT_DIR"
 
 open_timeline "Install verification"
 
-log_step "Clone"
-git clone --quiet "$PROJECT_ROOT" "$CLONE_DIR" 2>&1 | pipe_output || true
-log_info "Cloned to $CLONE_DIR"
+log_step "Pack"
+TARBALL_PATH="$(cd "$PROJECT_ROOT" && bun pm pack --quiet --ignore-scripts --destination "$PACK_DIR" | tail -n 1)"
+log_info "Packed to $TARBALL_PATH"
 
-log_step "Install dependencies"
-(cd "$CLONE_DIR" && bun install --silent 2>&1 | pipe_output) || log_error "bun install failed"
-log_info "Dependencies installed"
+log_step "Extract"
+tar -xzf "$TARBALL_PATH" -C "$EXTRACT_DIR" --strip-components=1
+log_info "Extracted to $EXTRACT_DIR"
+
+log_step "Assert excluded path is absent"
+if [ -e "$EXTRACT_DIR/scripts/sandbox" ]; then
+  log_error "scripts/sandbox shipped in the tarball, and the files field in package.json excludes it"
+fi
+log_info "Absent: scripts/sandbox"
+
+log_step "Install dependencies (production)"
+(cd "$EXTRACT_DIR" && bun install --production --ignore-scripts --silent 2>&1 | pipe_output) || log_error "bun install --production failed"
+log_info "Dependencies installed without devDependencies"
 
 log_step "Confirm CLI runs"
-(cd "$CLONE_DIR" && bun run src/cli.ts --help >/dev/null) || log_error "canon --help failed"
-log_info "canon --help ran clean"
+(cd "$EXTRACT_DIR" && bun run src/cli.ts --help >/dev/null) || log_error "canon --help failed"
+log_info "canon --help ran clean from the extracted package"
 
 log_step "Scaffold fresh project"
 mkdir -p "$TARGET_DIR"
@@ -67,7 +79,7 @@ mkdir -p "$TARGET_DIR"
 log_info "Initialized git in $TARGET_DIR"
 
 log_step "Run canon init"
-(cd "$TARGET_DIR" && CANON_NON_INTERACTIVE=1 bun run "$CLONE_DIR/src/cli.ts" init --stack base 2>&1 | pipe_output) || log_error "canon init failed"
+(cd "$TARGET_DIR" && CANON_NON_INTERACTIVE=1 bun run "$EXTRACT_DIR/src/cli.ts" init --stack base 2>&1 | pipe_output) || log_error "canon init failed"
 log_info "canon init completed"
 
 log_step "Assert scaffold"