codebyplan 1.13.0 → 1.13.3

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "codebyplan",
3
- "version": "1.13.0",
3
+ "version": "1.13.3",
4
4
  "description": "CLI for CodeByPlan — AI-powered development planning and tracking",
5
5
  "type": "module",
6
6
  "bin": {
@@ -33,7 +33,7 @@
33
33
  "homepage": "https://codebyplan.com",
34
34
  "repository": {
35
35
  "type": "git",
36
- "url": "https://github.com/codebyplan/codebyplan.git",
36
+ "url": "https://github.com/midevyou/codebyplan.git",
37
37
  "directory": "packages/codebyplan-package"
38
38
  },
39
39
  "license": "MIT",
@@ -0,0 +1,207 @@
1
+ # Generated by: codebyplan scaffold-publish-workflow
2
+ #
3
+ # This workflow publishes the codebyplan npm package on every merge to main
4
+ # where the committed package.json version exceeds the version currently on npm.
5
+ # No release PR, no conventional-commit parsing — the version committed in the
6
+ # feat branch is the version that ships.
7
+ #
8
+ # Two values a consuming repo must adjust:
9
+ # 1. paths: — set to the package directory whose package.json drives versioning
10
+ # (current value: 'packages/codebyplan-package/**')
11
+ # 2. npm view <package-name> — replace `codebyplan` with the actual package name
12
+ # in the "Check version vs published" step
13
+ #
14
+ # Everything else (OIDC auth, pnpm 10.12.4, Node 20, build:npm → publish) is
15
+ # intentionally generic and works as-is for any single-package npm publish.
16
+
17
+ name: Publish codebyplan to npm
18
+
19
+ on:
20
+ push:
21
+ branches:
22
+ - main
23
+ paths:
24
+ - "packages/codebyplan-package/**"
25
+ workflow_dispatch:
26
+ inputs:
27
+ dry_run:
28
+ description: "Print what would be published without actually publishing"
29
+ type: boolean
30
+ default: false
31
+
32
+ permissions:
33
+ contents: write
34
+ id-token: write
35
+
36
+ jobs:
37
+ check-version:
38
+ name: Check if publish needed
39
+ runs-on: ubuntu-latest
40
+ outputs:
41
+ should_publish: ${{ steps.check.outputs.should_publish }}
42
+ version: ${{ steps.check.outputs.version }}
43
+ steps:
44
+ - name: Checkout
45
+ uses: actions/checkout@v4
46
+
47
+ - name: Check version vs published
48
+ id: check
49
+ run: |
50
+ VERSION=$(jq -r '.version' packages/codebyplan-package/package.json)
51
+ if [ -z "$VERSION" ] || [ "$VERSION" = "null" ]; then
52
+ echo "ERROR: could not read .version from packages/codebyplan-package/package.json"
53
+ exit 1
54
+ fi
55
+ echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
56
+
57
+ # Pre-release versions (e.g. 1.2.3-beta.1) must never auto-publish to the
58
+ # 'latest' dist-tag — sort -V is not semver-aware for pre-release suffixes,
59
+ # and this workflow always publishes to latest. Publish pre-releases
60
+ # manually with `npm publish --tag <pre-id>`. The version core (X.Y.Z) has
61
+ # no hyphen, so any '-' marks a pre-release.
62
+ case "$VERSION" in
63
+ *-*)
64
+ echo "VERSION=${VERSION} is a pre-release — skipping auto-publish."
65
+ echo "should_publish=false" >> "$GITHUB_OUTPUT"
66
+ exit 0
67
+ ;;
68
+ esac
69
+
70
+ # Manual dispatch: always publish (recovery / forced re-publish path).
71
+ if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
72
+ echo "Manual dispatch — skipping gt check, will publish."
73
+ echo "should_publish=true" >> "$GITHUB_OUTPUT"
74
+ exit 0
75
+ fi
76
+
77
+ # Push path: compare committed version against the npm registry.
78
+ # Distinguish "never published" (E404 → first publish) from a transient
79
+ # registry/network error (abort rather than blindly publish).
80
+ NPM_OUT=$(npm view codebyplan version 2>&1)
81
+ NPM_EXIT=$?
82
+ if [ "$NPM_EXIT" -ne 0 ]; then
83
+ if echo "$NPM_OUT" | grep -q "E404"; then
84
+ echo "Package not yet published — first publish."
85
+ echo "should_publish=true" >> "$GITHUB_OUTPUT"
86
+ exit 0
87
+ fi
88
+ echo "ERROR: npm view failed (exit ${NPM_EXIT}): ${NPM_OUT}"
89
+ exit 1
90
+ fi
91
+ PUBLISHED="$NPM_OUT"
92
+
93
+ # sort -V: version-aware sort. If VERSION sorts AFTER PUBLISHED, it is greater.
94
+ GREATER=$(printf '%s\n%s\n' "$PUBLISHED" "$VERSION" | sort -V | tail -n1)
95
+ if [ "$GREATER" = "$VERSION" ] && [ "$VERSION" != "$PUBLISHED" ]; then
96
+ echo "VERSION=${VERSION} > PUBLISHED=${PUBLISHED} — will publish."
97
+ echo "should_publish=true" >> "$GITHUB_OUTPUT"
98
+ else
99
+ echo "VERSION=${VERSION} <= PUBLISHED=${PUBLISHED} — skipping publish."
100
+ echo "should_publish=false" >> "$GITHUB_OUTPUT"
101
+ fi
102
+
103
+ publish-codebyplan:
104
+ name: Publish to npm (OIDC)
105
+ needs: check-version
106
+ if: needs.check-version.outputs.should_publish == 'true'
107
+ runs-on: ubuntu-latest
108
+ permissions:
109
+ # OIDC token for npm Trusted Publishing — no long-lived NPM_TOKEN needed.
110
+ id-token: write
111
+ contents: read
112
+ steps:
113
+ - uses: actions/checkout@v4
114
+
115
+ - name: Setup pnpm
116
+ uses: pnpm/action-setup@v4
117
+ with:
118
+ version: 10.12.4
119
+
120
+ # Deliberately NO registry-url: actions/setup-node would write an
121
+ # `_authToken=${NODE_AUTH_TOKEN}` line into .npmrc, and that (empty) token
122
+ # shadows OIDC trusted publishing — npm uses the token path and gets E404
123
+ # instead of doing the OIDC exchange. publishConfig.registry handles the
124
+ # target registry for `npm publish`.
125
+ - name: Setup Node
126
+ uses: actions/setup-node@v4
127
+ with:
128
+ node-version: 20
129
+ cache: pnpm
130
+
131
+ - name: Install dependencies
132
+ run: pnpm install --frozen-lockfile
133
+
134
+ - name: Build packages/codebyplan-package
135
+ working-directory: packages/codebyplan-package
136
+ run: pnpm build:npm
137
+
138
+ # npm Trusted Publishing (OIDC) requires npm >= 11.5.1; Node 20 ships npm 10.x.
139
+ - name: Upgrade npm for trusted publishing
140
+ run: |
141
+ npm install -g npm@latest
142
+ npm --version
143
+ echo "OIDC token request URL present: ${ACTIONS_ID_TOKEN_REQUEST_URL:+yes}"
144
+
145
+ - name: Dry-run check
146
+ if: ${{ github.event_name == 'workflow_dispatch' && inputs.dry_run == true }}
147
+ working-directory: packages/codebyplan-package
148
+ run: |
149
+ echo "dry_run=true — skipping actual publish."
150
+ echo "Would publish: codebyplan@${{ needs.check-version.outputs.version }}"
151
+
152
+ # No NODE_AUTH_TOKEN: npm >= 11.5.1 exchanges the GitHub OIDC token for a
153
+ # short-lived publish token. Requires a Trusted Publisher configured for
154
+ # this repo + workflow on npmjs.com.
155
+ #
156
+ # NO --provenance by default: npm provenance attestation only supports
157
+ # PUBLIC source repositories (the registry returns E422 "Unsupported
158
+ # source repository visibility: private" otherwise). This works for both
159
+ # public and private repos. If your source repo is PUBLIC and you want
160
+ # supply-chain attestation, add `--provenance` to the command below.
161
+ - name: Publish to npm
162
+ if: ${{ github.event_name != 'workflow_dispatch' || inputs.dry_run != true }}
163
+ working-directory: packages/codebyplan-package
164
+ run: npm publish --access public
165
+
166
+ tag-and-release:
167
+ name: Tag + GitHub release
168
+ needs: [check-version, publish-codebyplan]
169
+ if: |
170
+ needs.check-version.outputs.should_publish == 'true' &&
171
+ needs.publish-codebyplan.result == 'success' &&
172
+ !(github.event_name == 'workflow_dispatch' && inputs.dry_run == true)
173
+ runs-on: ubuntu-latest
174
+ permissions:
175
+ contents: write
176
+ steps:
177
+ - name: Checkout
178
+ uses: actions/checkout@v4
179
+
180
+ - name: Create tag and release (idempotent)
181
+ env:
182
+ GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
183
+ VERSION: ${{ needs.check-version.outputs.version }}
184
+ run: |
185
+ TAG="v${VERSION}"
186
+
187
+ # Idempotent: skip tag creation if it already exists.
188
+ if git ls-remote --tags origin "refs/tags/${TAG}" | grep -q "${TAG}"; then
189
+ echo "Tag ${TAG} already exists — skipping tag creation."
190
+ else
191
+ git config user.name "github-actions[bot]"
192
+ git config user.email "github-actions[bot]@users.noreply.github.com"
193
+ git tag "${TAG}"
194
+ git push origin "${TAG}"
195
+ echo "Created and pushed tag ${TAG}."
196
+ fi
197
+
198
+ # Create GitHub release (idempotent: gh release create fails if exists; check first).
199
+ if gh release view "${TAG}" > /dev/null 2>&1; then
200
+ echo "GitHub release ${TAG} already exists — skipping."
201
+ else
202
+ gh release create "${TAG}" \
203
+ --title "codebyplan v${VERSION}" \
204
+ --notes "codebyplan v${VERSION} — published to npm: https://www.npmjs.com/package/codebyplan/v/${VERSION} (install: npm install -g codebyplan@${VERSION})" \
205
+ --latest
206
+ echo "Created GitHub release ${TAG}."
207
+ fi
@@ -13,7 +13,9 @@
13
13
  "spinnerTipsEnabled": true,
14
14
  "terminalProgressBarEnabled": true,
15
15
  "viewMode": "default",
16
- "worktree": { "baseRef": "fresh" },
16
+ "worktree": {
17
+ "baseRef": "fresh"
18
+ },
17
19
  "autoScrollEnabled": true,
18
20
  "cleanupPeriodDays": 30,
19
21
  "includeGitInstructions": true,
@@ -45,10 +47,159 @@
45
47
  "Bash(pnpm install:*)",
46
48
  "Bash(npm install:*)",
47
49
  "Bash(npm i:*)",
48
- "Bash(npx add:*)"
50
+ "Bash(npx add:*)",
51
+ "Skill(cbp-checkpoint-end)",
52
+ "Skill(cbp-ship)",
53
+ "Skill(cbp-ship-main)",
54
+ "mcp__codebyplan__accept_invite",
55
+ "mcp__codebyplan__change_role",
56
+ "mcp__codebyplan__create_launch",
57
+ "mcp__codebyplan__update_launch",
58
+ "mcp__codebyplan__delete_launch",
59
+ "mcp__codebyplan__create_repo",
60
+ "mcp__codebyplan__delete_session_log",
61
+ "mcp__codebyplan__delete_worktree",
62
+ "mcp__codebyplan__invite_member",
63
+ "mcp__codebyplan__remove_member",
64
+ "mcp__codebyplan__revoke_invite",
65
+ "mcp__codebyplan__release_assignment",
66
+ "Bash(codebyplan setup:*)",
67
+ "Bash(npx codebyplan setup:*)",
68
+ "Bash(codebyplan login:*)",
69
+ "Bash(npx codebyplan login:*)",
70
+ "Bash(codebyplan logout:*)",
71
+ "Bash(npx codebyplan logout:*)",
72
+ "Bash(codebyplan upgrade-auth:*)",
73
+ "Bash(npx codebyplan upgrade-auth:*)",
74
+ "Bash(codebyplan config:*)",
75
+ "Bash(npx codebyplan config:*)",
76
+ "Bash(codebyplan branch:*)",
77
+ "Bash(npx codebyplan branch:*)",
78
+ "Bash(codebyplan ship:*)",
79
+ "Bash(npx codebyplan ship:*)",
80
+ "Bash(codebyplan claude:*)",
81
+ "Bash(npx codebyplan claude:*)"
82
+ ],
83
+ "allow": [
84
+ "Skill(cbp-build-cc-agent)",
85
+ "Skill(cbp-build-cc-claude-file)",
86
+ "Skill(cbp-build-cc-memory)",
87
+ "Skill(cbp-build-cc-mode)",
88
+ "Skill(cbp-build-cc-rule)",
89
+ "Skill(cbp-build-cc-settings)",
90
+ "Skill(cbp-build-cc-skill)",
91
+ "Skill(cbp-checkpoint-check)",
92
+ "Skill(cbp-checkpoint-complete)",
93
+ "Skill(cbp-checkpoint-create)",
94
+ "Skill(cbp-checkpoint-plan)",
95
+ "Skill(cbp-checkpoint-start)",
96
+ "Skill(cbp-checkpoint-update)",
97
+ "Skill(cbp-frontend-a11y)",
98
+ "Skill(cbp-frontend-design)",
99
+ "Skill(cbp-frontend-ui)",
100
+ "Skill(cbp-frontend-ux)",
101
+ "Skill(cbp-git-branch-feat-create)",
102
+ "Skill(cbp-git-commit)",
103
+ "Skill(cbp-git-worktree-create)",
104
+ "Skill(cbp-git-worktree-remove)",
105
+ "Skill(cbp-merge-main)",
106
+ "Skill(cbp-refresh-infra)",
107
+ "Skill(cbp-round-check)",
108
+ "Skill(cbp-round-end)",
109
+ "Skill(cbp-round-execute)",
110
+ "Skill(cbp-round-input)",
111
+ "Skill(cbp-round-start)",
112
+ "Skill(cbp-round-update)",
113
+ "Skill(cbp-session-end)",
114
+ "Skill(cbp-session-start)",
115
+ "Skill(cbp-setup-e2e)",
116
+ "Skill(cbp-setup-eslint)",
117
+ "Skill(cbp-ship-configure)",
118
+ "Skill(cbp-supabase-branch-check)",
119
+ "Skill(cbp-supabase-migrate)",
120
+ "Skill(cbp-supabase-setup)",
121
+ "Skill(cbp-task-check)",
122
+ "Skill(cbp-task-complete)",
123
+ "Skill(cbp-task-create)",
124
+ "Skill(cbp-task-start)",
125
+ "Skill(cbp-task-testing)",
126
+ "Skill(cbp-todo)",
127
+ "mcp__codebyplan__get_checkpoints",
128
+ "mcp__codebyplan__get_current_task",
129
+ "mcp__codebyplan__get_eslint_presets",
130
+ "mcp__codebyplan__get_eslint_repo_config",
131
+ "mcp__codebyplan__get_file_changes",
132
+ "mcp__codebyplan__get_launch",
133
+ "mcp__codebyplan__get_launches",
134
+ "mcp__codebyplan__get_library_doc_job",
135
+ "mcp__codebyplan__get_next_action",
136
+ "mcp__codebyplan__get_repos",
137
+ "mcp__codebyplan__get_rounds",
138
+ "mcp__codebyplan__get_server_config",
139
+ "mcp__codebyplan__get_session_log",
140
+ "mcp__codebyplan__get_session_logs",
141
+ "mcp__codebyplan__get_session_state",
142
+ "mcp__codebyplan__get_task_template",
143
+ "mcp__codebyplan__get_task_templates",
144
+ "mcp__codebyplan__get_tasks",
145
+ "mcp__codebyplan__get_todos",
146
+ "mcp__codebyplan__get_work_plan",
147
+ "mcp__codebyplan__get_worktrees",
148
+ "mcp__codebyplan__list_tech_stack_sync_sessions",
149
+ "mcp__codebyplan__get_chunk",
150
+ "mcp__codebyplan__list_migrations",
151
+ "mcp__codebyplan__lookup_symbol",
152
+ "mcp__codebyplan__resolve_library_id",
153
+ "mcp__codebyplan__search_chunks",
154
+ "mcp__codebyplan__health_check",
155
+ "mcp__codebyplan__add_library",
156
+ "mcp__codebyplan__add_round",
157
+ "mcp__codebyplan__complete_round",
158
+ "mcp__codebyplan__update_round",
159
+ "mcp__codebyplan__complete_checkpoint",
160
+ "mcp__codebyplan__create_checkpoint",
161
+ "mcp__codebyplan__update_checkpoint",
162
+ "mcp__codebyplan__complete_task",
163
+ "mcp__codebyplan__create_task",
164
+ "mcp__codebyplan__update_task",
165
+ "mcp__codebyplan__create_session_log",
166
+ "mcp__codebyplan__update_session_log",
167
+ "mcp__codebyplan__update_session_state",
168
+ "mcp__codebyplan__create_worktree",
169
+ "mcp__codebyplan__flag_stale_chunk",
170
+ "mcp__codebyplan__list_invites",
171
+ "mcp__codebyplan__list_members",
172
+ "mcp__codebyplan__update_eslint_repo_config",
173
+ "mcp__codebyplan__update_server_config",
174
+ "mcp__codebyplan__update_task_template",
175
+ "Bash(codebyplan whoami:*)",
176
+ "Bash(npx codebyplan whoami:*)",
177
+ "Bash(codebyplan resolve-worktree:*)",
178
+ "Bash(npx codebyplan resolve-worktree:*)",
179
+ "Bash(codebyplan statusline:*)",
180
+ "Bash(npx codebyplan statusline:*)",
181
+ "Bash(codebyplan ports:*)",
182
+ "Bash(npx codebyplan ports:*)",
183
+ "Bash(codebyplan tech-stack:*)",
184
+ "Bash(npx codebyplan tech-stack:*)",
185
+ "Bash(codebyplan eslint:*)",
186
+ "Bash(npx codebyplan eslint:*)",
187
+ "Bash(codebyplan round:*)",
188
+ "Bash(npx codebyplan round:*)",
189
+ "Bash(codebyplan help:*)",
190
+ "Bash(npx codebyplan help:*)",
191
+ "Bash(codebyplan --version:*)",
192
+ "Bash(npx codebyplan --version:*)",
193
+ "Bash(codebyplan bump:*)",
194
+ "Bash(npx codebyplan bump:*)",
195
+ "Bash(codebyplan scaffold-publish-workflow:*)",
196
+ "Bash(npx codebyplan scaffold-publish-workflow:*)"
49
197
  ]
50
198
  },
51
- "attribution": { "commit": "", "pr": "" },
199
+ "attribution": {
200
+ "commit": "",
201
+ "pr": ""
202
+ },
52
203
  "showClearContextOnPlanAccept": false,
53
204
  "syntaxHighlightingDisabled": false
54
205
  }
@@ -76,6 +76,8 @@ Rules follow `Tool` or `Tool(specifier)`. Evaluated in order: **deny → ask →
76
76
 
77
77
  Full patterns: [reference/permission-rules.md](reference/permission-rules.md).
78
78
 
79
+ CBP-specific policy — which `codebyplan` CLI commands, `mcp__codebyplan__*` tools, and `/cbp-*` skills are pre-categorized `allow` vs `ask`, why, and how `codebyplan claude install/update` auto-populates them: [reference/cbp-permission-policy.md](reference/cbp-permission-policy.md).
80
+
79
81
  Common examples:
80
82
 
81
83
  ```json
@@ -0,0 +1,48 @@
1
+ # CodeByPlan Permission Policy
2
+
3
+ How the CodeByPlan surface — CLI commands, `mcp__codebyplan__*` tools, and `/cbp-*` skills — is pre-categorized into `permissions.allow` / `permissions.ask` in the settings the `codebyplan` package ships. Authored by CHK-157.
4
+
5
+ ## Where it lives + how it propagates
6
+
7
+ The curated arrays live in `templates/settings.project.base.json` inside the `codebyplan` npm package. `codebyplan claude install` and `codebyplan claude update` **union-merge** those `allow` / `ask` / `deny` arrays into the consuming repo's `.claude/settings.json` (the merge engine is `mergeBaseSettingsIntoSettings` in `src/lib/settings-merge.ts`); `codebyplan claude uninstall` strips them back out (`stripBaseSettingsFromSettings`). A user's own permission entries are preserved across all three operations (union on merge, membership-filter on strip).
8
+
9
+ No new plumbing was added — the categorization is **data** in the base template plus the completeness guard described below.
10
+
11
+ ## The interaction with `bypassPermissions`
12
+
13
+ CBP repos ship `permissions.defaultMode: "bypassPermissions"`. Under that mode, routine tool calls are auto-allowed without prompting — so the `allow` list is mostly an **explicit, documented enumeration** (and it takes effect verbatim if a repo ever lowers the mode). The harness still honors `ask` and `deny` under bypass, which is why the base settings have always carried an `ask` list (`git push --force`, `pnpm add`, …). Therefore:
14
+
15
+ - **`ask` is the operative "decide carefully" surface** — the deliberate stop-and-confirm set.
16
+ - **`deny`** is the hard block (dangerous `rm -rf` variants).
17
+ - **`allow`** is the explicit full enumeration of the rest of the CBP surface.
18
+
19
+ Precedence is `deny > ask > allow`; arrays union across scopes (managed/user/project/local).
20
+
21
+ ## The three tiers
22
+
23
+ ### `allow` — the autonomous workflow surface
24
+
25
+ - **All `/cbp-*` skills** except the production-shipment trio below. Invoking a skill is the intended mode of operation; the gated side effects happen inside via the Bash/MCP tools the skill calls, which carry their own tiering.
26
+ - **All `mcp__codebyplan__*` reads** (`get_*`, `list_*`, `search_*`, `health_check`, `lookup_symbol`, `resolve_library_id`, `get_chunk`).
27
+ - **Routine workflow-write MCP tools** the pipeline calls many times per task: create/update/complete checkpoint, task, and round; session log + session-state writes; `create_worktree`, `add_library`, `flag_stale_chunk`, `update_server_config`, `update_eslint_repo_config`, `update_task_template`. Gating these with `ask` would make the autonomous workflow unusable.
28
+ - **Read/safe CLI commands** (both `codebyplan X` and `npx codebyplan X`): `whoami`, `resolve-worktree`, `statusline`, `ports`, `tech-stack`, `eslint`, `round`, `help`, `--version`.
29
+
30
+ ### `ask` — the deliberate confirm-gate
31
+
32
+ - **Production-shipment skills**: `cbp-ship`, `cbp-ship-main`, `cbp-checkpoint-end` — these promote/deploy to production, so they prompt even in an otherwise auto-allowed setup.
33
+ - **Destructive / admin / external MCP tools**: `delete_session_log`, `delete_worktree`, `delete_launch`, `create_repo`, `create_launch`, `update_launch`, `release_assignment`, and the membership tools `invite_member`, `remove_member`, `change_role`, `accept_invite`, `revoke_invite`.
34
+ - **Mutating / external / clobber-risk CLI commands** (both prefixes): `setup`, `login`, `logout`, `upgrade-auth`, `config` (can overwrite committed `.codebyplan/` files), `branch` (rewrites branch config), `ship`, `claude` (`install`/`update`/`uninstall` overwrite `.claude/`).
35
+
36
+ ### `deny` — unchanged
37
+
38
+ The pre-existing dangerous-`rm -rf` blocks. This policy does not alter `deny` semantics.
39
+
40
+ ## Completeness guard (the "decide carefully" guarantee)
41
+
42
+ `src/lib/settings-permissions-completeness.test.ts` re-derives the live surface from source — skill directory names under `templates/skills/`, `registerToolWithAuthz(server, "...")` names in `packages/mcp-tools/src/tools/*.ts`, and `arg === "..."` CLI subcommands in `src/index.ts` — and fails if any item is not in exactly one tier. So a **newly-added skill, MCP tool, or CLI subcommand forces a deliberate allow-vs-ask decision** before the suite goes green; nothing slips in uncategorized. The test also round-trips the curated arrays through the install-merge and uninstall-strip engine.
43
+
44
+ When you add a skill / MCP tool / CLI subcommand, add its matching rule (`Skill(<name>)`, `mcp__codebyplan__<name>`, or `Bash(codebyplan <sub>:*)` + `Bash(npx codebyplan <sub>:*)`) to `allow` or `ask` in `templates/settings.project.base.json` — and mirror it into any dogfooding `.claude/settings.json`.
45
+
46
+ ## Scope
47
+
48
+ `scope: org-shared` — CBP-framework infrastructure that lands identically in every consuming repo via the `codebyplan` package.
@@ -30,6 +30,8 @@ Before any shipment logic, ensure the feat branch is current against main. Shipm
30
30
  2. If the skill exits with failure (offline, unresolved conflicts, user-aborted): surface the failure and STOP `/cbp-checkpoint-end` — shipment is not safe until the branch is reconciled. The user resolves and re-invokes.
31
31
  3. On clean success: continue to Step 1.
32
32
 
33
+ > **Version bumps ride this shipment automatically.** `codebyplan ship` (invoked by `/cbp-ship-main` in Step 5) patch-bumps every changed workspace package and commits `chore(release): bump versions` on the feat branch AFTER this main-sync merge and BEFORE push + PR creation — so the bump rides the same feat→main PR (no separate release PR). No manual bump step is required here; the planned bumps surface in the Step 5 report. See `cbp-ship/reference/versioning.md` (`in-branch-bump` mode).
34
+
33
35
  ### Step 1: Get Active Checkpoint
34
36
 
35
37
  Use MCP `get_current_task` with repo_id. Get the active checkpoint.
@@ -195,6 +197,7 @@ context.shipment: {
195
197
  timestamp: [ISO],
196
198
  branch_config: { base, protected },
197
199
  feat_to_base: { pr_url, merged: true/false },
200
+ version_bumps: [...], // from `codebyplan ship` bumps[] — packages patch-bumped on the feat branch this shipment
198
201
  surfaces: [...], // populated by /cbp-ship — per-surface deploy results
199
202
  skipped: [...], // populated by /cbp-ship — surfaces explicitly skipped
200
203
  stale_branches_cleaned: [list of deleted git branches],
@@ -211,6 +214,10 @@ Present summary:
211
214
  ### Branch Promotion
212
215
  - **feat -> [BASE]**: [PR URL] (merged)
213
216
 
217
+ ### Version Bumps
218
+ - [package]: [currentVersion] → [nextVersion]
219
+ (From `context.shipment.version_bumps[]` — committed as `chore(release): bump versions`; publishes on merge. Omit this section if no packages were bumped.)
220
+
214
221
  ### Runtime Surfaces (via /cbp-ship)
215
222
  | Surface | Variant | Status | URL/ID |
216
223
  | ... | ... | ... | ... |
@@ -2,11 +2,12 @@
2
2
 
3
3
  How `/cbp-ship` decides which version a surface ships at.
4
4
 
5
- ## Three modes (per surface, configured per-package)
5
+ ## Four modes (per surface, configured per-package)
6
6
 
7
7
  | Mode | Trigger | Best for |
8
8
  |---|---|---|
9
9
  | `manual` | User bumps `package.json` / `tauri.conf.json` / `app.json` version themselves before checkpoint shipment | Apps with infrequent releases; small teams |
10
+ | `in-branch-bump` | `codebyplan ship` detects changed workspace packages via `git diff <base>...HEAD`, patch-bumps each one, and commits a `chore(release): bump versions` commit on the feat branch BEFORE push + PR creation — so the bump rides the same feat→main PR | npm/CLI packages in a pnpm monorepo using the codebyplan CLI; never-missed patch bumps |
10
11
  | `release-please` | GH Actions opens version-bump PRs based on conventional commit messages on the watched branch; merge the PR before shipment | npm packages with frequent releases; multi-contributor repos |
11
12
  | `changesets` | Devs add `.changeset/*.md` entries in feature branches; an aggregator PR collects them | Monorepos with many independent packages |
12
13
 
@@ -16,7 +17,7 @@ Mode is set per-surface in `.codebyplan/shipment.json`:
16
17
  {
17
18
  "surfaces": {
18
19
  "npm-package": {
19
- "packages/codebyplan-package": { "versioning": "release-please" }
20
+ "packages/codebyplan-package": { "versioning": "in-branch-bump" }
20
21
  },
21
22
  "tauri-desktop": { "versioning": "manual" },
22
23
  "expo-mobile": { "versioning": "auto-build-number" }
@@ -59,6 +60,32 @@ Conventional Commits are the trigger:
59
60
 
60
61
  The release-please workflow lives at `.github/workflows/release-please.yml` (scaffolded by `/cbp-ship-configure`).
61
62
 
63
+ > **Retired in this repo.** CodeByPlan itself no longer uses release-please — its `release-please.yml`, `release-please-config.json`, and `.release-please-manifest.json` were removed in favour of the **publish-on-main model** (see in-branch-bump conventions below). `package.json` `version` is the sole version-of-record. The release-please workflow + config templates remain available under `templates/skills/cbp-ship/templates/` for consuming repos that prefer the conventional-commit Release-PR flow.
64
+
65
+ ## in-branch-bump conventions
66
+
67
+ `codebyplan ship` (the CLI behind `/cbp-ship-main` and `/cbp-checkpoint-end`) runs the bump engine as part of shipping — no separate release PR, no conventional-commit parsing:
68
+
69
+ 1. **When** — after the main-sync merge (`/cbp-merge-main`) and the clean-tree check, BEFORE `git push` + PR creation. The bump therefore rides the same feat→main PR.
70
+ 2. **What changed** — `git diff <base>...HEAD` (base from `.codebyplan/git.json`, preferring `origin/<base>`) maps changed files to their owning workspace packages via the `pnpm-workspace.yaml` globs.
71
+ 3. **Bump** — every changed package/app is patch-bumped (`x.y.z → x.y.(z+1)`) in its version file (`package.json`, `src-tauri/tauri.conf.json`, Expo `app.json`), and a CHANGELOG entry is prepended where a `CHANGELOG.md` already exists.
72
+ 4. **Commit** — the bumped files are committed as `chore(release): bump versions` on the feat branch.
73
+ 5. **Idempotent** — a package whose working-tree version already exceeds its base version is skipped, so re-running ship never double-bumps.
74
+
75
+ `codebyplan ship` is a non-interactive pipeline (bump → push → PR → checks → merge), so there is no confirm-before-merge prompt. To preview the planned bumps WITHOUT committing, run `codebyplan ship --dry-run` (or `codebyplan bump --dry-run`); opt a single real ship out of bumping with `codebyplan ship --no-bump`. The bumps committed on the feat branch are reported in the ship summary (and in `--json` as `bumps[]`). On merge to the production branch, version-change detection publishes each surface whose committed version now exceeds its published version (retiring the release-please Release-PR trigger).
76
+
77
+ ### publish-on-main model
78
+
79
+ The bump is only half the loop — publishing is the other half. On every push to the production branch, `.github/workflows/publish.yml` closes it:
80
+
81
+ 1. **check-version** — reads the committed `package.json` `version` and compares it to the live `npm view <pkg> version`. Publish proceeds only when the committed version is strictly greater (semver-aware, via `sort -V`); an unchanged or lower version is a no-op. A never-published package is treated as publishable (first release).
82
+ 2. **publish** — builds and runs `npm publish --access public` via OIDC Trusted Publishing (no `NPM_TOKEN`; requires npm ≥ 11.5.1). `workflow_dispatch` keeps a manual recovery path (always publishes the current version) plus a `dry_run` input that prints the decision without publishing.
83
+ 3. **tag + release** — only after a successful publish, creates the `v{version}` git tag + a GitHub release (idempotent — skipped if the tag already exists, so no orphan tags on a failed publish).
84
+
85
+ There is **no separate Release PR** — the version committed in the feat branch is the version that ships, so `package.json` is the sole version-of-record. The desktop surface keeps its own `release-desktop.yml` (tauri version vs `desktop-v{version}` tag), which the in-branch `tauri.conf.json` bump feeds automatically.
86
+
87
+ Other repos inherit this workflow via `codebyplan scaffold-publish-workflow`, which writes `templates/github-workflows/publish.yml` into their `.github/workflows/`. (`.github/` is outside the `codebyplan claude install` target — which only writes under `.claude/` — so the publish workflow has its own scaffold command.)
88
+
62
89
  ## changesets conventions
63
90
 
64
91
  A changeset is a markdown file describing the change:
@@ -98,7 +125,7 @@ When multiple surfaces ship together, bumps may need to coordinate:
98
125
 
99
126
  ## What NOT to do
100
127
 
101
- - Don't manually edit `package.json` version inside `/cbp-ship` — versioning happens before shipment, not during
128
+ - Don't hand-edit `package.json` version mid-shipment in `manual` / `release-please` / `changesets` modes — versioning happens before shipment, not during. (`in-branch-bump` inverts this: `codebyplan ship` bumps + commits automatically, after the main-sync merge and before PR creation, so the bump rides the single feat→main PR.)
102
129
  - Don't auto-bump in `manual` mode without confirmation — the user owns the bump
103
130
  - Don't squash changeset commits — release-please / changesets need each conventional commit visible
104
131
  - Don't tag a Tauri release before the version commit is on PRODUCTION branch — the tag locks the shipped version
@@ -107,6 +134,7 @@ When multiple surfaces ship together, bumps may need to coordinate:
107
134
 
108
135
  | Question | If yes |
109
136
  |---|---|
137
+ | Is this an npm/CLI package in a pnpm monorepo shipped via the codebyplan CLI? | in-branch-bump |
110
138
  | Is this an npm package with multiple authors? | release-please |
111
139
  | Is this a monorepo with 3+ published packages? | changesets |
112
140
  | Is this a single app with infrequent releases? | manual |