code-workspace-zhuiyi 1.0.0-beta.2 → 1.0.0-beta.4
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/README.md +61 -29
- package/README.zh-CN.md +61 -30
- package/artifacts/manifest.json +1 -1
- package/package.json +1 -1
- package/src/cli/commands/config.js +50 -0
- package/src/cli/commands/extension.js +111 -41
- package/src/cli/commands/init.js +118 -13
- package/src/cli/registry.js +9 -1
- package/src/cli.js +2 -0
- package/src/core/config.js +29 -1
- package/src/core/extension-package.js +20 -9
- package/src/core/extension-registry-lifecycle.js +4 -7
- package/src/core/extension-settings.js +145 -0
- package/src/core/extensions.js +6 -4
- package/src/core/initializer.js +10 -3
- package/src/core/nexus-extension-provider.js +35 -49
- package/src/core/user-config.js +90 -0
- package/src/index.js +4 -0
- package/src/init/clack-extension-picker.js +322 -0
- package/src/init/extension-picker.js +56 -9
- package/src/init/extension-summary.js +51 -0
- package/src/init/plan.js +2 -1
- package/src/init/registry-picker.js +10 -2
- package/src/init/ui.js +15 -2
- package/src/init/wizard.js +34 -11
package/README.md
CHANGED
|
@@ -10,29 +10,34 @@ Code Workspace is a local multi-project registry and safety layer for Claude Cod
|
|
|
10
10
|
## Install
|
|
11
11
|
|
|
12
12
|
```bash
|
|
13
|
-
npm install -g
|
|
13
|
+
npm install -g code-workspace-zhuiyi@latest
|
|
14
14
|
```
|
|
15
15
|
|
|
16
16
|
The package provides the `code-workspace` command and the shorter `codew` alias. The legacy `code-w` alias remains available for compatibility.
|
|
17
17
|
|
|
18
18
|
## Initialize
|
|
19
19
|
|
|
20
|
+
|
|
20
21
|
Interactive initialization:
|
|
21
22
|
|
|
22
23
|
```bash
|
|
23
|
-
|
|
24
|
+
codew init .code-workspace
|
|
24
25
|
```
|
|
26
|
+
|
|
27
|
+
`.code-workspace` is the directory name and can be determined by yourself.
|
|
25
28
|
|
|
26
29
|
Non-interactive initialization:
|
|
27
30
|
|
|
28
31
|
```bash
|
|
29
|
-
|
|
32
|
+
codew init .code-workspace \
|
|
30
33
|
--tools claude,codex \
|
|
31
34
|
--extensions none \
|
|
32
35
|
--language en-US \
|
|
33
36
|
--yes
|
|
34
37
|
```
|
|
35
38
|
|
|
39
|
+
Use `--dev false` for an extension-container Workspace; this skips Workspace dependency installation, disables the system development extension, and omits the project onboarding prompt. Run `codew init .code-workspace --dev true --yes` to enable development mode again. The default for a new Workspace is `true`, and an existing Workspace keeps its saved value when the option is omitted.
|
|
40
|
+
|
|
36
41
|
Use `--tools claude`, `--tools codex`, or `--tools none` to override the default tool selection. Monitoring is not enabled implicitly; install the `monitor` extension with `--extensions monitor` or through the interactive extension picker.
|
|
37
42
|
|
|
38
43
|
Initialization writes only Workspace-owned state and integrations:
|
|
@@ -47,7 +52,7 @@ It does not create `openspec/`, install native `/opsx` commands, or install nati
|
|
|
47
52
|
|
|
48
53
|
### Experimental extensions
|
|
49
54
|
|
|
50
|
-
Ordinary extensions are published to the configured `@codew-ext`
|
|
55
|
+
Ordinary extensions are published to the configured extension scope and Nexus Registry (by default, scope `@codew-ext` and the company Registry) and installed into the verified local Extension Store. Interactive `init` opens the shared Clack-based Nexus picker: submit a search term, use autocomplete multi-select to choose extensions on the current page, then use the page-actions prompt to move to the next/previous page, search again, finish, retry, or cancel. The picker marks installed latest versions as disabled and offers installed older versions as updates. If Nexus is unavailable or a page request fails, the ordinary-extension step can be skipped while core initialization continues. The package-local `extensions/` directory contains only the system-managed `codew-workspace-guard`:
|
|
51
56
|
|
|
52
57
|
```bash
|
|
53
58
|
codew init . --extensions monitor --yes
|
|
@@ -64,16 +69,43 @@ codew extension upgrade zhuiyi-jira-mcp --yes
|
|
|
64
69
|
|
|
65
70
|
The Workspace operation lock shared by init, extension install, and extension uninstall is configured in the Code Workspace project's `.env` (not in the target Workspace). `CODE_WORKSPACE_INIT_LOCK_UPDATE_MS` defaults to `5000`, and `CODE_WORKSPACE_INIT_LOCK_STALE_MS` defaults to `30000`; process environment variables take precedence. See `.env.example` for the project configuration names.
|
|
66
71
|
|
|
67
|
-
Users select names, not `name@version` positions. A default install resolves the highest compatible stable, non-deprecated version from the configured
|
|
72
|
+
Users select names, not `name@version` positions. A default install resolves the highest compatible stable, non-deprecated version from the configured Registry and the verified local Store. Fresh users do not need to run `npm config set` just to discover extensions; authentication, when required by Nexus, still comes from a user-level npm token or the supported environment variables. A single-target install may instead pass an exact SemVer with `--version`; prereleases require that exact form, and a deprecated version additionally requires `--allow-deprecated`. `--offline` disables Registry access and resolves only local facts.
|
|
73
|
+
|
|
74
|
+
`codew-workspace-guard` is the system extension containing the Workspace Guard, `codew-add-projects`, and `codew-resolve-branch`: `init` installs or upgrades it automatically, it is hidden from extension selection, and it cannot be managed through `extension install/uninstall/upgrade`. A new non-interactive Workspace installs no ordinary extensions unless `--extensions` is provided; `init` does not implicitly query Nexus. `none` skips ordinary extension work and does not uninstall existing artifacts or disable system extension processing.
|
|
75
|
+
|
|
76
|
+
### User-level extension Registry configuration
|
|
68
77
|
|
|
69
|
-
|
|
78
|
+
Extension connection settings are user-level, apply to every Workspace, and can be managed without entering a Workspace, similar to `npm config`:
|
|
79
|
+
|
|
80
|
+
```bash
|
|
81
|
+
codew config list
|
|
82
|
+
codew config get extensions.registry
|
|
83
|
+
codew config set extensions.registry https://pkg.in.wezhuiyi.com/repository/codew-extensions/
|
|
84
|
+
codew config set extensions.scope @codew-ext
|
|
85
|
+
codew config set extensions.auth-type legacy
|
|
86
|
+
codew config delete extensions.registry
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
The settings file is stored at `~/.code-workspace/config.json` under the user's home directory. On Windows, it is `%USERPROFILE%\.code-workspace\config.json`. `CODE_WORKSPACE_CONFIG` can override its path. The supported keys and built-in defaults are:
|
|
90
|
+
|
|
91
|
+
| Key | Default |
|
|
92
|
+
| --- | --- |
|
|
93
|
+
| `extensions.registry` | `https://pkg.in.wezhuiyi.com/repository/codew-extensions/` |
|
|
94
|
+
| `extensions.scope` | `@codew-ext` |
|
|
95
|
+
| `extensions.auth-type` | `legacy` |
|
|
96
|
+
|
|
97
|
+
Registry resolution uses `CODE_WORKSPACE_NEXUS_REGISTRY`, then `extensions.registry`, then the matching npm scope registry (for example, `@codew-ext:registry`), and finally the built-in default. Scope and auth type use their environment variable, then the user setting, then the built-in default. The environment variables are `CODE_WORKSPACE_NEXUS_REGISTRY`, `CODE_WORKSPACE_NEXUS_SCOPE`, and `CODE_WORKSPACE_NEXUS_AUTH_TYPE`. The config commands never store tokens; credentials still come from the supported environment variables or the user's npm configuration.
|
|
98
|
+
|
|
99
|
+
The legacy key `@codew-ext:registry` is accepted as an alias for `extensions.registry`. `config list` and `config get` show Code Workspace's own user settings; an npm scope registry is only a fallback when the user setting is absent.
|
|
100
|
+
|
|
101
|
+
`extension install` does not rerun core Workspace initialization. In JSON, non-TTY, or `--yes` mode, at least one extension name is required. Multiple names are installed in order with one confirmation boundary and independent transactions; any failure makes the install command fail while later extensions still run. When remote Registry metadata cannot be obtained during default resolution, installation fails before Workspace writes instead of silently using an older package.
|
|
70
102
|
|
|
71
103
|
`extension info` remains a Workspace-independent Registry read. In a TTY, `extension search` opens the same paged picker as `init`; selecting an uninstalled extension installs it, while selecting an outdated installed extension updates it. The picker hides system extensions and disables installed latest versions. JSON, non-TTY, or `--yes` search remains read-only and returns the Registry result envelope. `extension upgrade` accepts one or more installed ordinary extensions, freezes the default target for each, confirms once, and reuses the same per-extension transaction and rollback as install. An already-current target is skipped.
|
|
72
104
|
|
|
73
|
-
`extension pack` creates a Nexus/npm-ready `codew-ext-<extension-id>-<version>.tgz
|
|
105
|
+
`extension pack` creates a Nexus/npm-ready tarball from an extension package directory. With the default scope, the filename is `codew-ext-<extension-id>-<version>.tgz`; a custom scope changes the filename prefix accordingly:
|
|
74
106
|
|
|
75
107
|
```bash
|
|
76
|
-
|
|
108
|
+
codew extension pack /path/to/extension/1.0.0 --output dist/extensions --json
|
|
77
109
|
```
|
|
78
110
|
|
|
79
111
|
The command is Workspace-independent, creates a missing output directory recursively, never executes extension or npm lifecycle code, and reopens the generated tarball to verify the npm envelope, manifest, entry digest, and unchanged `packageSha256` before atomically committing it. Existing outputs are never overwritten. It does not publish or store Registry credentials; CI can pass the verified tarball to `npm publish --registry`.
|
|
@@ -83,20 +115,20 @@ The system-managed `codew-workspace-guard` extension is installed or upgraded au
|
|
|
83
115
|
Extension entries run in separate Node processes and generate files in temporary staging directories. The host rejects undeclared, missing, symbolic-link, non-file, path-escaping, conflicting, and checksum-mismatched artifacts before transactionally installing them. Per-Workspace state is stored in `.codew/ext-manifest.json`. A failed extension is reported as a warning and does not roll back successful core initialization or stop later extensions; a failed upgrade restores and retains the previous installed version.
|
|
84
116
|
|
|
85
117
|
Extensions may own complete files or declare Host-managed abstract Hooks. Codex and Claude
|
|
86
|
-
|
|
118
|
+
adapters render those declarations into each provider's native configuration and dynamically plug
|
|
87
119
|
or unplug them during extension install, upgrade, and uninstall. Shared targets are composed and
|
|
88
120
|
verified by Code Workspace; extensions never patch the real Workspace directly. Uninstall uses
|
|
89
121
|
recorded installed state and does not execute extension code. Unknown changes to extension-owned
|
|
90
122
|
files or contributions stop the operation instead of being overwritten.
|
|
91
123
|
|
|
92
|
-
This is fault isolation, not a malicious-code security sandbox. The experimental release trusts system extension code shipped with Code Workspace and ordinary extension code downloaded from the
|
|
124
|
+
This is fault isolation, not a malicious-code security sandbox. The experimental release trusts system extension code shipped with Code Workspace and ordinary extension code downloaded from the company Nexus after archive, identity, manifest, entry, runtime, and package-digest verification. External extension directories, dependencies, arbitrary patches, force uninstall, disable commands, and automatic extension updates through `codew update` are not supported. The developer contract is in `docs/extensions.md`; a step-by-step guide is in `docs/extension-development/extension-development-guide.zh-CN.md`.
|
|
93
125
|
|
|
94
126
|
## Register projects
|
|
95
127
|
|
|
96
128
|
Inspecting a repository is read-only:
|
|
97
129
|
|
|
98
130
|
```bash
|
|
99
|
-
|
|
131
|
+
codew project inspect /absolute/path/to/project --json
|
|
100
132
|
```
|
|
101
133
|
|
|
102
134
|
Claude Code users can invoke:
|
|
@@ -108,7 +140,7 @@ Claude Code users can invoke:
|
|
|
108
140
|
Codex users can invoke `$codew-add-projects` with the same explicit paths. For low-level automation, pass complete project records through stdin:
|
|
109
141
|
|
|
110
142
|
```bash
|
|
111
|
-
cat projects.json |
|
|
143
|
+
cat projects.json | codew project add --stdin --yes --json
|
|
112
144
|
```
|
|
113
145
|
|
|
114
146
|
`--stdin` accepts `{ "schemaVersion": 1, "projects": [...] }` JSON with the same semantics as `--projects-file`, requires `--yes`, and fails before writing when input is empty, invalid, or larger than 1 MiB. `--stdin`, `--project-file`, `--projects-file`, and a positional path are mutually exclusive.
|
|
@@ -144,16 +176,16 @@ For example, `ref: team-projects.yaml` makes the project registry `.codew/team-p
|
|
|
144
176
|
## Daily commands
|
|
145
177
|
|
|
146
178
|
```bash
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
179
|
+
codew project list --json
|
|
180
|
+
codew project show payments --json
|
|
181
|
+
codew project verify payments --json
|
|
182
|
+
codew project branch inspect payments --json
|
|
183
|
+
codew project branch verify payments --json
|
|
184
|
+
codew project branch use-registered payments --yes --json
|
|
185
|
+
codew project branch accept-actual payments --yes --json
|
|
186
|
+
codew project branch update-latest payments --json
|
|
187
|
+
codew permissions apply --yes --json
|
|
188
|
+
codew doctor --json
|
|
157
189
|
```
|
|
158
190
|
|
|
159
191
|
`project branch inspect` reports `registeredBranch`, `actualBranch`, whether they match, worktree cleanliness, local registered-branch availability, and remote-tracking candidates for only the named project. `project branch verify` is the narrower assertion used after reconciliation: it checks only whether the registered and actual branches match, without running overall project-health validation. A `PROJECT_BRANCH_MISMATCH` diagnostic uses `registeredBranch`, `actualBranch`, and `location`; consumers of older branch diagnostic/result fields must migrate to this canonical state contract.
|
|
@@ -187,9 +219,9 @@ AI/Agent must not directly edit this file. They may read the policy and invoke t
|
|
|
187
219
|
## Update and language
|
|
188
220
|
|
|
189
221
|
```bash
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
222
|
+
codew update --json
|
|
223
|
+
codew update --language zh-CN --json
|
|
224
|
+
codew language --json
|
|
193
225
|
```
|
|
194
226
|
|
|
195
227
|
`update` refreshes only Workspace-owned managed assets and never changes Agent directory authorization. Unknown local edits stop the batch before writes; review them or pass `--force` explicitly.
|
|
@@ -199,15 +231,15 @@ code-workspace language --json
|
|
|
199
231
|
Monitor is an ordinary Nexus extension. Install it into a workspace and run its dashboard through the generic extension runtime:
|
|
200
232
|
|
|
201
233
|
```bash
|
|
202
|
-
|
|
203
|
-
|
|
234
|
+
codew extension install monitor --yes
|
|
235
|
+
codew ext monitor serve --port 3211
|
|
204
236
|
```
|
|
205
237
|
|
|
206
238
|
The monitor binds to loopback, combines events from multiple initialized workspaces, and keeps hook reporting (`codew ext monitor report`) failure-open. Review and trust project hooks in Codex before relying on reports.
|
|
207
239
|
|
|
208
240
|
```bash
|
|
209
|
-
|
|
210
|
-
|
|
241
|
+
codew completion --shell zsh
|
|
242
|
+
codew completion --shell bash
|
|
211
243
|
```
|
|
212
244
|
|
|
213
245
|
`completion` prints a script generated from the full command registry, including subcommands and command-specific options. It does not install the script or modify shell configuration. With `--json`, the script is returned in `data.script`.
|
package/README.zh-CN.md
CHANGED
|
@@ -10,7 +10,7 @@ Code Workspace 是面向 Claude Code 与 Codex 的本地多项目注册表和安
|
|
|
10
10
|
## 安装
|
|
11
11
|
|
|
12
12
|
```bash
|
|
13
|
-
npm install -g
|
|
13
|
+
npm install -g code-workspace-zhuiyi@latest
|
|
14
14
|
```
|
|
15
15
|
|
|
16
16
|
软件包提供 `code-workspace` 命令及短别名 `codew`。为保持兼容,旧别名 `code-w` 仍然可用。
|
|
@@ -20,19 +20,23 @@ npm install -g @icebearx-ai/code-workspace
|
|
|
20
20
|
交互式初始化:
|
|
21
21
|
|
|
22
22
|
```bash
|
|
23
|
-
|
|
23
|
+
codew init .code-workspace
|
|
24
24
|
```
|
|
25
25
|
|
|
26
|
+
`.code-workspace` 是目录名,可以自定义。
|
|
27
|
+
|
|
26
28
|
非交互式初始化:
|
|
27
29
|
|
|
28
30
|
```bash
|
|
29
|
-
|
|
31
|
+
codew init . \
|
|
30
32
|
--tools claude,codex \
|
|
31
33
|
--extensions none \
|
|
32
34
|
--language zh-CN \
|
|
33
35
|
--yes
|
|
34
36
|
```
|
|
35
37
|
|
|
38
|
+
如果这个 Workspace 主要作为扩展容器使用,可以传 `--dev false`;该模式会跳过 Workspace 依赖安装、停用系统开发扩展并省略项目引导提示。需要恢复开发模式时执行 `codew init . --dev true --yes`。新 Workspace 默认值为 `true`;已有 Workspace 省略该参数时沿用已保存的值。
|
|
39
|
+
|
|
36
40
|
可用 `--tools claude`、`--tools codex` 或 `--tools none` 覆盖默认工具选择。监控不会隐式启用;请通过 `--extensions monitor` 或交互式扩展选择安装 `monitor` 扩展。
|
|
37
41
|
|
|
38
42
|
初始化只写入 Workspace 自有状态和集成:
|
|
@@ -47,7 +51,7 @@ code-workspace init . \
|
|
|
47
51
|
|
|
48
52
|
### 试验性扩展
|
|
49
53
|
|
|
50
|
-
|
|
54
|
+
普通扩展发布到配置的扩展 scope 和 Nexus Registry(默认 scope 为 `@codew-ext`,Registry 为公司 Registry),并安装到经过验证的本地 Extension Store。`init` 和独立安装命令使用基于 `@clack/prompts` 的 Nexus 选择器:先提交搜索词,再在当前页多选扩展,然后通过页面操作菜单执行上一页、下一页、重新搜索、完成、重试或取消;npm 包内的 `extensions/` 目录只保留系统扩展 `codew-workspace-guard`。交互选择按 ESC 可无修改退出:
|
|
51
55
|
|
|
52
56
|
```bash
|
|
53
57
|
codew init . --extensions monitor --yes
|
|
@@ -64,16 +68,43 @@ codew extension upgrade zhuiyi-jira-mcp --yes
|
|
|
64
68
|
|
|
65
69
|
`init`、扩展安装和扩展卸载共享的 Workspace 操作锁配置在 Code Workspace 项目自身的 `.env` 中(不在目标 Workspace 中)。`CODE_WORKSPACE_INIT_LOCK_UPDATE_MS` 默认值为 `5000`,`CODE_WORKSPACE_INIT_LOCK_STALE_MS` 默认值为 `30000`;进程环境变量优先于 `.env`。配置项名称见 `.env.example`。
|
|
66
70
|
|
|
67
|
-
用户选择扩展名,不使用 `name@version`
|
|
71
|
+
用户选择扩展名,不使用 `name@version` 位置语法。默认安装会从配置的 Registry 和已验证本地 Store 中选择最高的兼容、稳定、未标记为 deprecated(已弃用)的版本。新用户无需先执行 `npm config set` 才能发现扩展;如果 Nexus 要求认证,仍需使用用户级 npm token 或支持的环境变量。单目标安装可用 `--version` 指定精确 SemVer;预发布版本(prerelease)必须通过精确版本请求,已弃用版本还必须加 `--allow-deprecated`。`--offline` 禁止 Registry 访问,只基于本地事实解析。
|
|
68
72
|
|
|
69
|
-
`
|
|
73
|
+
`codew-workspace-guard` 是包含 Workspace Guard、`codew-add-projects` 和 `codew-resolve-branch` 的系统扩展,由 `init` 自动安装或升级,不出现在扩展选择列表中,也不能通过 `extension install/uninstall/upgrade` 手动管理。新 Workspace 非交互初始化时,未传 `--extensions` 就不安装普通扩展;`init` 不会隐式查询 Nexus。`none` 只跳过本次普通扩展初始化,不会卸载已有制品,也不会取消系统扩展处理。
|
|
70
74
|
|
|
71
|
-
|
|
75
|
+
### 用户级扩展 Registry 配置
|
|
72
76
|
|
|
73
|
-
|
|
77
|
+
扩展连接配置保存在用户级配置中,对所有 Workspace 生效,不依赖当前 Workspace,使用方式类似 `npm config`:
|
|
74
78
|
|
|
75
79
|
```bash
|
|
76
|
-
|
|
80
|
+
codew config list
|
|
81
|
+
codew config get extensions.registry
|
|
82
|
+
codew config set extensions.registry https://pkg.in.wezhuiyi.com/repository/codew-extensions/
|
|
83
|
+
codew config set extensions.scope @codew-ext
|
|
84
|
+
codew config set extensions.auth-type legacy
|
|
85
|
+
codew config delete extensions.registry
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
配置文件默认保存到用户 Home 目录下的 `~/.code-workspace/config.json`;Windows 为 `%USERPROFILE%\.code-workspace\config.json`。也可以通过 `CODE_WORKSPACE_CONFIG` 指定路径。支持的配置项和内置默认值如下:
|
|
89
|
+
|
|
90
|
+
| 配置项 | 默认值 |
|
|
91
|
+
| --- | --- |
|
|
92
|
+
| `extensions.registry` | `https://pkg.in.wezhuiyi.com/repository/codew-extensions/` |
|
|
93
|
+
| `extensions.scope` | `@codew-ext` |
|
|
94
|
+
| `extensions.auth-type` | `legacy` |
|
|
95
|
+
|
|
96
|
+
Registry 的解析顺序为:`CODE_WORKSPACE_NEXUS_REGISTRY` → `extensions.registry` → 匹配的 npm scope 配置(例如 `@codew-ext:registry`)→ 内置默认值。scope 和 auth-type 的顺序为:对应环境变量 → 用户级配置 → 内置默认值。对应环境变量为 `CODE_WORKSPACE_NEXUS_REGISTRY`、`CODE_WORKSPACE_NEXUS_SCOPE` 和 `CODE_WORKSPACE_NEXUS_AUTH_TYPE`。配置命令永远不会保存 token;认证仍来自支持的环境变量或用户 npm 配置。
|
|
97
|
+
|
|
98
|
+
兼容旧配置时,`@codew-ext:registry` 可作为 `extensions.registry` 的别名。`config list` 和 `config get` 展示的是 Code Workspace 自身的用户配置;只有在用户配置缺失时,安装流程才会使用 npm scope Registry 作为回退。
|
|
99
|
+
|
|
100
|
+
`extension install` 不会重新执行 Workspace 核心初始化。在 JSON、非 TTY 或 `--yes` 模式下,必须至少提供一个扩展名。多个名称按顺序安装,只确认一次且各自使用独立事务;任一扩展失败会使安装命令失败,但后续扩展仍会继续执行。默认解析无法取得远端 Registry 元数据(metadata)时,安装会在 Workspace 写入前失败,不会静默选择旧包。
|
|
101
|
+
|
|
102
|
+
`extension info` 仍是与 Workspace 无关的 Registry 读取命令。在 TTY 中,`extension search` 会打开与 `init` 相同的分页扩展选择器;选择未安装扩展会执行安装,选择已安装但过期的扩展会执行更新。系统扩展不会出现在列表中,已是最新版的扩展不可选择。JSON、非 TTY 或使用 `--yes` 时,search 保持只读并返回 Registry 结果封装(envelope)。`extension upgrade` 接受一个或多个已安装普通扩展,逐个冻结默认目标,统一确认后复用安装的逐扩展事务和回滚;已是当前版本的目标返回 skipped(跳过)。
|
|
103
|
+
|
|
104
|
+
`extension pack` 可以从扩展包目录生成可交给 Nexus/npm 的 tarball。使用默认 scope 时,文件名为 `codew-ext-<extension-id>-<version>.tgz`;自定义 scope 后,文件名前缀也会相应变化:
|
|
105
|
+
|
|
106
|
+
```bash
|
|
107
|
+
codew extension pack /path/to/extension/1.0.0 --output dist/extensions --json
|
|
77
108
|
```
|
|
78
109
|
|
|
79
110
|
该命令与 Workspace 无关,会在输出目录缺失时递归创建,不执行扩展入口或任何 npm 生命周期脚本;生成 tarball 后会重新读取并验证 npm envelope、manifest、入口摘要和未变化的 `packageSha256`,再原子提交。目标文件已存在时拒绝覆盖。命令本身不发布、不保存 Registry 凭证;CI 可将已验证的 tarball 交给 `npm publish --registry`。
|
|
@@ -82,19 +113,19 @@ code-workspace extension pack /path/to/extension/1.1.0 --output dist/extensions
|
|
|
82
113
|
|
|
83
114
|
扩展入口在独立 Node 进程中运行,只向临时 staging 目录生成文件。Host 会在事务安装前拒绝未声明、缺失、符号链接、非文件、路径逃逸、目标冲突和 hash 不匹配的制品。Workspace 状态存放在 `.codew/ext-manifest.json`。扩展失败以 warning 报告,不回滚已成功的核心初始化,也不阻止后续扩展;升级失败会恢复并保留旧的已安装版本。
|
|
84
115
|
|
|
85
|
-
扩展可以独占完整文件,也可以声明由 Host 管理的抽象 Hook。Host 通过 Codex/Claude
|
|
116
|
+
扩展可以独占完整文件,也可以声明由 Host 管理的抽象 Hook。Host 通过 Codex/Claude 适配器(adapter)
|
|
86
117
|
把声明转换为各自的原生配置,并在扩展安装、升级和卸载时动态插拔;共享目标由 Code
|
|
87
118
|
Workspace 合成和验证,扩展不会直接 patch 真实 Workspace。卸载只使用已安装状态,不执行
|
|
88
119
|
扩展代码;扩展所有的文件或贡献存在未知修改时会拒绝覆盖或删除。
|
|
89
120
|
|
|
90
|
-
这是故障隔离,不是恶意代码安全沙箱。试验版本信任随 Code Workspace
|
|
121
|
+
这是故障隔离,不是恶意代码安全沙箱。试验版本信任随 Code Workspace 发布的系统扩展代码,以及从公司 Nexus 下载并通过归档、身份、manifest、入口、runtime 和 package digest 验证的普通扩展包。外部扩展目录、扩展依赖、任意 patch、强制卸载、禁用命令和通过 `codew update` 自动更新扩展仍不支持。开发契约见 `docs/extensions.zh-CN.md`;从目录结构到打包发布的完整流程见 `docs/extension-development/extension-development-guide.zh-CN.md`。
|
|
91
122
|
|
|
92
123
|
## 注册项目
|
|
93
124
|
|
|
94
125
|
项目检查是只读操作:
|
|
95
126
|
|
|
96
127
|
```bash
|
|
97
|
-
|
|
128
|
+
codew project inspect /absolute/path/to/project --json
|
|
98
129
|
```
|
|
99
130
|
|
|
100
131
|
Claude Code 用户可显式调用:
|
|
@@ -106,7 +137,7 @@ Claude Code 用户可显式调用:
|
|
|
106
137
|
Codex 用户可对相同的显式路径调用 `$codew-add-projects`。底层自动化可通过 stdin 一次传入完整项目记录:
|
|
107
138
|
|
|
108
139
|
```bash
|
|
109
|
-
cat projects.json |
|
|
140
|
+
cat projects.json | codew project add --stdin --yes --json
|
|
110
141
|
```
|
|
111
142
|
|
|
112
143
|
`--stdin` 接受 `{ "schemaVersion": 1, "projects": [...] }` 形式且与 `--projects-file` 相同语义的 JSON,必须与 `--yes` 一起使用,并在输入为空、无效或超过 1 MiB 时于写入前失败。`--stdin`、`--project-file`、`--projects-file` 与位置路径只能选择一个。
|
|
@@ -142,16 +173,16 @@ projects:
|
|
|
142
173
|
## 日常命令
|
|
143
174
|
|
|
144
175
|
```bash
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
176
|
+
codew project list --json
|
|
177
|
+
codew project show payments --json
|
|
178
|
+
codew project verify payments --json
|
|
179
|
+
codew project branch inspect payments --json
|
|
180
|
+
codew project branch verify payments --json
|
|
181
|
+
codew project branch use-registered payments --yes --json
|
|
182
|
+
codew project branch accept-actual payments --yes --json
|
|
183
|
+
codew project branch update-latest payments --json
|
|
184
|
+
codew permissions apply --yes --json
|
|
185
|
+
codew doctor --json
|
|
155
186
|
```
|
|
156
187
|
|
|
157
188
|
`project branch inspect` 只检查命名项目,返回 `registeredBranch`、`actualBranch`、是否一致、worktree 是否干净、注册分支是否在本地存在以及远程跟踪候选。`project branch verify` 是协调后的窄范围断言,只检查注册分支和实际分支是否一致,不执行项目整体健康校验。`PROJECT_BRANCH_MISMATCH` 诊断使用 `registeredBranch`、`actualBranch` 和 `location`;使用旧分支诊断或结果字段的调用方必须迁移到这套规范状态合同。
|
|
@@ -185,9 +216,9 @@ AI/Agent 不得直接编辑该文件;可以读取策略并调用已注册的 C
|
|
|
185
216
|
## 更新与语言
|
|
186
217
|
|
|
187
218
|
```bash
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
219
|
+
codew update --json
|
|
220
|
+
codew update --language en-US --json
|
|
221
|
+
codew language --json
|
|
191
222
|
```
|
|
192
223
|
|
|
193
224
|
`update` 只刷新 Workspace 自有托管资产,绝不会修改 Agent 目录授权。遇到未知本地修改时,会在任何写入前终止批次;请先审查修改,或显式传入 `--force`。
|
|
@@ -197,8 +228,8 @@ code-workspace language --json
|
|
|
197
228
|
监控以 Nexus 中的 `monitor` 扩展提供。先在 Workspace 中安装扩展,再通过通用扩展运行时启动面板:
|
|
198
229
|
|
|
199
230
|
```bash
|
|
200
|
-
|
|
201
|
-
|
|
231
|
+
codew extension install monitor --yes
|
|
232
|
+
codew ext monitor serve --port 3211
|
|
202
233
|
```
|
|
203
234
|
|
|
204
235
|
监控服务仅绑定 loopback,可汇总多个已初始化工作区的事件;hook 上报(`codew ext monitor report`)失败不会阻断 Agent。依赖监控前,请在 Codex 中检查并信任项目 hook。
|
|
@@ -206,8 +237,8 @@ code-workspace ext monitor serve --port 3211
|
|
|
206
237
|
## 命令补全
|
|
207
238
|
|
|
208
239
|
```bash
|
|
209
|
-
|
|
210
|
-
|
|
240
|
+
codew completion --shell zsh
|
|
241
|
+
codew completion --shell bash
|
|
211
242
|
```
|
|
212
243
|
|
|
213
244
|
`completion` 会根据完整命令注册表输出脚本,包括子命令和各命令专属选项;它不会安装脚本或修改 Shell 配置。使用 `--json` 时,脚本位于 `data.script`。
|
package/artifacts/manifest.json
CHANGED
package/package.json
CHANGED
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
const {
|
|
2
|
+
canonicalSettingKey,
|
|
3
|
+
deleteExtensionSetting,
|
|
4
|
+
listExtensionSettings,
|
|
5
|
+
resolveExtensionSettings,
|
|
6
|
+
setExtensionSetting,
|
|
7
|
+
} = require("../../core/extension-settings");
|
|
8
|
+
const { success } = require("../result");
|
|
9
|
+
|
|
10
|
+
function settingEntries(options = {}) {
|
|
11
|
+
const listed = listExtensionSettings(options);
|
|
12
|
+
return Object.entries(listed.values).map(([key, entry]) => ({ key, value: entry.value, source: entry.source }));
|
|
13
|
+
}
|
|
14
|
+
|
|
15
|
+
function displayKey(canonical) {
|
|
16
|
+
return canonical === "authType" ? "extensions.auth-type" : `extensions.${canonical}`;
|
|
17
|
+
}
|
|
18
|
+
|
|
19
|
+
function executeConfig(invocation) {
|
|
20
|
+
const action = invocation.definition.path[1];
|
|
21
|
+
const options = invocation.dependencies || {};
|
|
22
|
+
if (action === "list") {
|
|
23
|
+
const entries = settingEntries(options);
|
|
24
|
+
return success("config.list", { file: listExtensionSettings(options).file, settings: entries }, entries.map((entry) => `${entry.key}=${entry.value} (${entry.source})`).join("\n"));
|
|
25
|
+
}
|
|
26
|
+
if (action === "get") {
|
|
27
|
+
if (!invocation.args[0]) {
|
|
28
|
+
const entries = settingEntries(options);
|
|
29
|
+
return success("config.get", { file: listExtensionSettings(options).file, settings: entries }, entries.map((entry) => `${entry.key}=${entry.value} (${entry.source})`).join("\n"));
|
|
30
|
+
}
|
|
31
|
+
const key = canonicalSettingKey(invocation.args[0]);
|
|
32
|
+
const settings = resolveExtensionSettings(options);
|
|
33
|
+
const field = key === "authType" ? "authType" : key;
|
|
34
|
+
const value = settings.values[field];
|
|
35
|
+
const source = settings.configured[field] ? "user" : "default";
|
|
36
|
+
return success("config.get", { file: settings.file, key: displayKey(key), value, source }, `${value}`);
|
|
37
|
+
}
|
|
38
|
+
if (action === "set") {
|
|
39
|
+
const settings = setExtensionSetting(invocation.args[0], invocation.args[1], options);
|
|
40
|
+
const canonical = canonicalSettingKey(invocation.args[0]);
|
|
41
|
+
const key = displayKey(canonical);
|
|
42
|
+
return success("config.set", { file: settings.file, key, value: settings.values[canonical] }, `Set ${key}=${settings.values[canonical]}`);
|
|
43
|
+
}
|
|
44
|
+
const settings = deleteExtensionSetting(invocation.args[0], options);
|
|
45
|
+
const canonical = canonicalSettingKey(invocation.args[0]);
|
|
46
|
+
const key = displayKey(canonical);
|
|
47
|
+
return success("config.delete", { file: settings.file, key, value: settings.values[canonical], source: "default" }, `Reset ${key} to ${settings.values[canonical]}`);
|
|
48
|
+
}
|
|
49
|
+
|
|
50
|
+
module.exports = { executeConfig };
|