code-workspace-zhuiyi 1.0.0-beta.1 → 1.0.0-beta.3

package/README.md

@@ -10,23 +10,26 @@ Code Workspace is a local multi-project registry and safety layer for Claude Cod
 ## Install
 
 ```bash
-npm install -g @icebearx-ai/code-workspace
+npm install -g code-workspace-zhuiyi@latest
 ```
 
 The package provides the `code-workspace` command and the shorter `codew` alias. The legacy `code-w` alias remains available for compatibility.
 
 ## Initialize
 
+
 Interactive initialization:
 
 ```bash
-code-workspace init .
+codew init .code-workspace
 ```
+ 
+`.code-workspace` is the directory name and can be determined by yourself.
 
 Non-interactive initialization:
 
 ```bash
-code-workspace init . \
+codew init .code-workspace \
   --tools claude,codex \
   --extensions none \
   --language en-US \
@@ -45,23 +48,16 @@ Initialization writes only Workspace-owned state and integrations:
 
 It does not create `openspec/`, install native `/opsx` commands, or install native `openspec-*` skills.
 
-### Experimental built-in extensions
+### Experimental extensions
 
-`init` can install integrations from the versioned `extensions/` repository shipped inside this npm package. Select extension names interactively, or pass a comma-separated name list non-interactively. The dedicated install command accepts one or more names; without names it opens the built-in extension multiselect with no extensions selected, where each choice shows its name and a short description. ESC exits without changes:
+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`:
 
 ```bash
-codew init . --extensions zhuiyi-jira-mcp --yes
-codew init . --extensions zhuiyi-opensvn-mcp --yes
+codew init . --extensions monitor --yes
 codew init . --extensions none --yes
 codew extension install
-codew extension install zhuiyi-jira-mcp --yes
-codew extension install zhuiyi-opensvn-mcp --yes
-codew extension install zhuiyi-jira-prd-analysis --yes
-codew extension install zhuiyi-jira-task-breakdown --yes
-codew extension install zhuiyi-jira-issue-fix-summary --yes
-codew extension install zhuiyi-guangda-coding-spec --yes
-codew extension uninstall zhuiyi-jira-mcp --yes
-codew extension uninstall zhuiyi-jira-prd-analysis --yes
+codew extension install monitor --yes
+codew extension uninstall monitor --yes
 codew extension search jira --json
 codew extension info zhuiyi-jira-mcp --json
 codew extension install zhuiyi-jira-mcp --version 1.1.0 --yes
@@ -71,47 +67,66 @@ codew extension upgrade zhuiyi-jira-mcp --yes
 
 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.
 
-Users select names, not `name@version` positions. A default install resolves the highest compatible stable, non-deprecated version across the built-in catalog, the configured `@codew-ext` Nexus Registry, and the verified local Store. 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. `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.
+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.
 
-`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 the Registry is configured and a default resolution cannot obtain the remote metadata, installation fails before Workspace writes instead of silently using an older built-in package.
+`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.
 
-`extension search` and `extension info` are Workspace-independent Registry reads. `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.
+### User-level extension Registry configuration
 
-`extension pack` creates a Nexus/npm-ready `codew-ext-<extension-id>-<version>.tgz` from an extension package directory:
+Extension connection settings are user-level, apply to every Workspace, and can be managed without entering a Workspace, similar to `npm config`:
 
 ```bash
-code-workspace extension pack extensions/zhuiyi-jira-mcp/1.1.0 --output dist/extensions --json
+codew config list
+codew config get extensions.registry
+codew config set extensions.registry https://pkg.in.wezhuiyi.com/repository/codew-extensions/
+codew config set extensions.scope @codew-ext
+codew config set extensions.auth-type legacy
+codew config delete extensions.registry
 ```
 
-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`.
+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:
+
+| Key | Default |
+| --- | --- |
+| `extensions.registry` | `https://pkg.in.wezhuiyi.com/repository/codew-extensions/` |
+| `extensions.scope` | `@codew-ext` |
+| `extensions.auth-type` | `legacy` |
+
+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.
+
+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.
 
-The bundled `zhuiyi-jira-mcp` and `zhuiyi-opensvn-mcp` extensions configure the Jira and OpenSVN MCP services for the selected Agent tools. They do not create an `openspec/` directory or install native OpenSpec commands.
+`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.
 
-The bundled `zhuiyi-jira-prd-analysis`, `zhuiyi-jira-task-breakdown`, and `zhuiyi-jira-issue-fix-summary` extensions install optional Codex and Claude Code skill files. They are independent extensions, are not installed by core `init` or `update`, and can be uninstalled separately. Install `zhuiyi-jira-mcp` separately when they need Jira access.
+`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.
 
-The bundled `zhuiyi-guangda-coding-spec` extension installs a Codex and Claude Code skill that applies the China Everbright Bank research, security, testing, and release rules to Guangda customer projects. It is independent of core `init` and `update`, can be uninstalled separately, and requires no MCP service.
+`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:
 
-The MCP runtime packages are not copied into the Workspace. Only their configuration is stored there; a launcher prepares and caches each package on demand in the user-level Extension Store.
+```bash
+codew extension pack /path/to/extension/1.0.0 --output dist/extensions --json
+```
+
+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`.
 
-`zhuiyi-opensvn-mcp` accesses OpenSVN static resources through `opssvn.in.wezhuiyi.com`. Its bundled configuration sets `SVN_OUTPUT_DIR` to `.mcp-cache-opensvn`, requires `SVN_AUTHORIZATION`, and defaults `SVN_MAX_RESOURCES` to `200`; credentials are not stored in the extension package and should be supplied through local configuration or the runtime environment.
+The system-managed `codew-workspace-guard` extension is installed or upgraded automatically by `init`; it is hidden from ordinary extension selection and cannot be installed, upgraded, or uninstalled manually. Ordinary extension packages are downloaded from Nexus, verified, and cached in the user-level Extension Store.
 
 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.
 
 Extensions may own complete files or declare Host-managed abstract Hooks. Codex and Claude
-adaptors render those declarations into each provider's native configuration and dynamically plug
+adapters render those declarations into each provider's native configuration and dynamically plug
 or unplug them during extension install, upgrade, and uninstall. Shared targets are composed and
 verified by Code Workspace; extensions never patch the real Workspace directly. Uninstall uses
 recorded installed state and does not execute extension code. Unknown changes to extension-owned
 files or contributions stop the operation instead of being overwritten.
 
-This is fault isolation, not a malicious-code security sandbox. The experimental release trusts extension code shipped with Code Workspace or downloaded from the configured 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`.
+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`.
 
 ## Register projects
 
 Inspecting a repository is read-only:
 
 ```bash
-code-workspace project inspect /absolute/path/to/project --json
+codew project inspect /absolute/path/to/project --json
 ```
 
 Claude Code users can invoke:
@@ -123,7 +138,7 @@ Claude Code users can invoke:
 Codex users can invoke `$codew-add-projects` with the same explicit paths. For low-level automation, pass complete project records through stdin:
 
 ```bash
-cat projects.json | code-workspace project add --stdin --yes --json
+cat projects.json | codew project add --stdin --yes --json
 ```
 
 `--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.
@@ -159,16 +174,16 @@ For example, `ref: team-projects.yaml` makes the project registry `.codew/team-p
 ## Daily commands
 
 ```bash
-code-workspace project list --json
-code-workspace project show payments --json
-code-workspace project verify payments --json
-code-workspace project branch inspect payments --json
-code-workspace project branch verify payments --json
-code-workspace project branch use-registered payments --yes --json
-code-workspace project branch accept-actual payments --yes --json
-code-workspace project branch update-latest payments --json
-code-workspace permissions apply --yes --json
-code-workspace doctor --json
+codew project list --json
+codew project show payments --json
+codew project verify payments --json
+codew project branch inspect payments --json
+codew project branch verify payments --json
+codew project branch use-registered payments --yes --json
+codew project branch accept-actual payments --yes --json
+codew project branch update-latest payments --json
+codew permissions apply --yes --json
+codew doctor --json
 ```
 
 `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.
@@ -202,27 +217,27 @@ AI/Agent must not directly edit this file. They may read the policy and invoke t
 ## Update and language
 
 ```bash
-code-workspace update --json
-code-workspace update --language zh-CN --json
-code-workspace language --json
+codew update --json
+codew update --language zh-CN --json
+codew language --json
 ```
 
 `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.
 
 ## Monitor
 
-Monitor ships as the built-in `monitor` extension. Install it into a workspace and run its dashboard through the generic extension runtime:
+Monitor is an ordinary Nexus extension. Install it into a workspace and run its dashboard through the generic extension runtime:
 
 ```bash
-code-workspace extension install monitor --yes
-code-workspace ext monitor serve --port 3211
+codew extension install monitor --yes
+codew ext monitor serve --port 3211
 ```
 
 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.
 
 ```bash
-code-workspace completion --shell zsh
-code-workspace completion --shell bash
+codew completion --shell zsh
+codew completion --shell bash
 ```
 
 `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

@@ -10,7 +10,7 @@ Code Workspace 是面向 Claude Code 与 Codex 的本地多项目注册表和安
 ## 安装
 
 ```bash
-npm install -g @icebearx-ai/code-workspace
+npm install -g code-workspace-zhuiyi@latest
 ```
 
 软件包提供 `code-workspace` 命令及短别名 `codew`。为保持兼容，旧别名 `code-w` 仍然可用。
@@ -20,13 +20,15 @@ npm install -g @icebearx-ai/code-workspace
 交互式初始化：
 
 ```bash
-code-workspace init .
+codew init .code-workspace
 ```
 
+`.code-workspace` 是目录名，可以自定义。
+
 非交互式初始化：
 
 ```bash
-code-workspace init . \
+codew init . \
   --tools claude,codex \
   --extensions none \
   --language zh-CN \
@@ -45,23 +47,16 @@ code-workspace init . \
 
 它不会创建 `openspec/`，不会安装原生 `/opsx` 命令，也不会安装原生 `openspec-*` Skill。
 
-### 试验性内置扩展
+### 试验性扩展
 
-`init` 可以从 npm 包内随附的版本化 `extensions/` 仓库安装集成。交互模式按扩展名多选；非交互模式传入逗号分隔的扩展名。独立安装命令接受一个或多个扩展名；不传名称时打开内置扩展多选，每个选项显示名称和简短描述，且默认不勾选任何扩展，按 ESC 可无修改退出：
+普通扩展发布到配置的扩展 scope 和 Nexus Registry（默认 scope 为 `@codew-ext`，Registry 为公司 Registry），并安装到经过验证的本地 Extension Store。`init` 和独立安装命令使用基于 `@clack/prompts` 的 Nexus 选择器：先提交搜索词，再在当前页多选扩展，然后通过页面操作菜单执行上一页、下一页、重新搜索、完成、重试或取消；npm 包内的 `extensions/` 目录只保留系统扩展 `codew-workspace-guard`。交互选择按 ESC 可无修改退出：
 
 ```bash
-codew init . --extensions zhuiyi-jira-mcp --yes
-codew init . --extensions zhuiyi-opensvn-mcp --yes
+codew init . --extensions monitor --yes
 codew init . --extensions none --yes
 codew extension install
-codew extension install zhuiyi-jira-mcp --yes
-codew extension install zhuiyi-opensvn-mcp --yes
-codew extension install zhuiyi-jira-prd-analysis --yes
-codew extension install zhuiyi-jira-task-breakdown --yes
-codew extension install zhuiyi-jira-issue-fix-summary --yes
-codew extension install zhuiyi-guangda-coding-spec --yes
-codew extension uninstall zhuiyi-jira-mcp --yes
-codew extension uninstall zhuiyi-jira-prd-analysis --yes
+codew extension install monitor --yes
+codew extension uninstall monitor --yes
 codew extension search jira --json
 codew extension info zhuiyi-jira-mcp --json
 codew extension install zhuiyi-jira-mcp --version 1.1.0 --yes
@@ -71,45 +66,64 @@ codew extension upgrade zhuiyi-jira-mcp --yes
 
 `init`、扩展安装和扩展卸载共享的 Workspace 操作锁配置在 Code Workspace 项目自身的 `.env` 中（不在目标 Workspace 中）。`CODE_WORKSPACE_INIT_LOCK_UPDATE_MS` 默认值为 `5000`，`CODE_WORKSPACE_INIT_LOCK_STALE_MS` 默认值为 `30000`；进程环境变量优先于 `.env`。配置项名称见 `.env.example`。
 
-用户选择扩展名，不使用 `name@version` 位置语法。默认安装会在内置目录、已配置的 `@codew-ext` Nexus Registry 和已验证本地 Store 中选择最高的兼容、稳定、非 deprecated 版本。单目标安装可用 `--version` 指定精确 SemVer； prerelease 必须通过精确版本请求，deprecated 版本还必须加 `--allow-deprecated`。`--offline` 禁止 Registry 访问，只基于本地事实解析。`codew-workspace-guard` 是包含 Workspace Guard、`codew-add-projects` 和 `codew-resolve-branch` 的系统扩展，由 `init` 自动安装或升级，不出现在扩展选择列表中，也不能通过 `extension install/uninstall/upgrade` 手动管理。新 Workspace 非交互初始化时，未传 `--extensions` 就不安装普通扩展；`init` 不会隐式查询 Nexus。`none` 只跳过本次普通扩展初始化，不会卸载已有制品，也不会取消系统扩展处理。
+用户选择扩展名，不使用 `name@version` 位置语法。默认安装会从配置的 Registry 和已验证本地 Store 中选择最高的兼容、稳定、未标记为 deprecated（已弃用）的版本。新用户无需先执行 `npm config set` 才能发现扩展；如果 Nexus 要求认证，仍需使用用户级 npm token 或支持的环境变量。单目标安装可用 `--version` 指定精确 SemVer；预发布版本（prerelease）必须通过精确版本请求，已弃用版本还必须加 `--allow-deprecated`。`--offline` 禁止 Registry 访问，只基于本地事实解析。
 
-`extension install` 不会重新执行 Workspace 核心初始化。在 JSON、非 TTY 或 `--yes` 模式下，必须至少提供一个扩展名。多个名称按顺序安装，只确认一次且各自使用独立事务；任一扩展失败会使安装命令失败，但后续扩展仍会继续执行。Registry 已配置且默认解析无法取得远端 metadata 时，安装会在 Workspace 写入前失败，不会静默选择旧内置包。
+`codew-workspace-guard` 是包含 Workspace Guard、`codew-add-projects` 和 `codew-resolve-branch` 的系统扩展，由 `init` 自动安装或升级，不出现在扩展选择列表中，也不能通过 `extension install/uninstall/upgrade` 手动管理。新 Workspace 非交互初始化时，未传 `--extensions` 就不安装普通扩展；`init` 不会隐式查询 Nexus。`none` 只跳过本次普通扩展初始化，不会卸载已有制品，也不会取消系统扩展处理。
 
-`extension search` 和 `extension info` 是与 Workspace 无关的 Registry 读取命令。`extension upgrade` 接受一个或多个已安装普通扩展，逐个冻结默认目标，统一确认后复用安装的逐扩展事务和回滚；已是当前版本的目标返回 skipped。
+### 用户级扩展 Registry 配置
 
-`extension pack` 可以从扩展包目录生成可交给 Nexus/npm 的 `codew-ext-<extension-id>-<version>.tgz`：
+扩展连接配置保存在用户级配置中，对所有 Workspace 生效，不依赖当前 Workspace，使用方式类似 `npm config`：
 
 ```bash
-code-workspace extension pack extensions/zhuiyi-jira-mcp/1.1.0 --output dist/extensions --json
+codew config list
+codew config get extensions.registry
+codew config set extensions.registry https://pkg.in.wezhuiyi.com/repository/codew-extensions/
+codew config set extensions.scope @codew-ext
+codew config set extensions.auth-type legacy
+codew config delete extensions.registry
 ```
 
-该命令与 Workspace 无关，会在输出目录缺失时递归创建，不执行扩展入口或任何 npm 生命周期脚本；生成 tarball 后会重新读取并验证 npm envelope、manifest、入口摘要和未变化的 `packageSha256`，再原子提交。目标文件已存在时拒绝覆盖。命令本身不发布、不保存 Registry 凭证；CI 可将已验证的 tarball 交给 `npm publish --registry`。
+配置文件默认保存到用户 Home 目录下的 `~/.code-workspace/config.json`；Windows 为 `%USERPROFILE%\.code-workspace\config.json`。也可以通过 `CODE_WORKSPACE_CONFIG` 指定路径。支持的配置项和内置默认值如下：
+
+| 配置项 | 默认值 |
+| --- | --- |
+| `extensions.registry` | `https://pkg.in.wezhuiyi.com/repository/codew-extensions/` |
+| `extensions.scope` | `@codew-ext` |
+| `extensions.auth-type` | `legacy` |
+
+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 配置。
+
+兼容旧配置时，`@codew-ext:registry` 可作为 `extensions.registry` 的别名。`config list` 和 `config get` 展示的是 Code Workspace 自身的用户配置；只有在用户配置缺失时，安装流程才会使用 npm scope Registry 作为回退。
 
-当前随包提供的内置扩展包括 `zhuiyi-jira-mcp` 和 `zhuiyi-opensvn-mcp`，分别用于为选中的 Agent 工具配置 Jira MCP 与 OpenSVN MCP 服务；它们不会创建 `openspec/` 目录，也不会安装 OpenSpec 原生命令。
+`extension install` 不会重新执行 Workspace 核心初始化。在 JSON、非 TTY 或 `--yes` 模式下，必须至少提供一个扩展名。多个名称按顺序安装，只确认一次且各自使用独立事务；任一扩展失败会使安装命令失败，但后续扩展仍会继续执行。默认解析无法取得远端 Registry 元数据（metadata）时，安装会在 Workspace 写入前失败，不会静默选择旧包。
 
-随包还提供 `zhuiyi-jira-prd-analysis`、`zhuiyi-jira-task-breakdown` 和 `zhuiyi-jira-issue-fix-summary` 三个 Skill 扩展，用于安装可选的 Codex 与 Claude Code Skill 文件。它们不随核心 `init` 或 `update` 安装，可以独立安装和卸载；需要 Jira 访问时另行安装 `zhuiyi-jira-mcp`。
+`extension info` 仍是与 Workspace 无关的 Registry 读取命令。在 TTY 中，`extension search` 会打开与 `init` 相同的分页扩展选择器；选择未安装扩展会执行安装，选择已安装但过期的扩展会执行更新。系统扩展不会出现在列表中，已是最新版的扩展不可选择。JSON、非 TTY 或使用 `--yes` 时，search 保持只读并返回 Registry 结果封装（envelope）。`extension upgrade` 接受一个或多个已安装普通扩展，逐个冻结默认目标，统一确认后复用安装的逐扩展事务和回滚；已是当前版本的目标返回 skipped（跳过）。
 
-随包还提供 `zhuiyi-guangda-coding-spec` Skill 扩展，用于在光大客户项目按风险域落实研发、安全、测试与投产规范。它同样不随核心 `init` 或 `update` 安装，可以独立安装和卸载，且不依赖任何 MCP 服务。
+`extension pack` 可以从扩展包目录生成可交给 Nexus/npm 的 tarball。使用默认 scope 时，文件名为 `codew-ext-<extension-id>-<version>.tgz`；自定义 scope 后，文件名前缀也会相应变化：
 
-两个 MCP 的运行包不会复制到 Workspace；Workspace 只保存 MCP 配置，运行包由用户级 Extension Store 中的 launcher 按需缓存。
+```bash
+codew extension pack /path/to/extension/1.0.0 --output dist/extensions --json
+```
+
+该命令与 Workspace 无关，会在输出目录缺失时递归创建，不执行扩展入口或任何 npm 生命周期脚本；生成 tarball 后会重新读取并验证 npm envelope、manifest、入口摘要和未变化的 `packageSha256`，再原子提交。目标文件已存在时拒绝覆盖。命令本身不发布、不保存 Registry 凭证；CI 可将已验证的 tarball 交给 `npm publish --registry`。
 
-`zhuiyi-opensvn-mcp` 使用 `opssvn.in.wezhuiyi.com` 访问 OpenSVN 静态资源。内置配置将 `SVN_OUTPUT_DIR` 设为 `.mcp-cache-opensvn`，运行时必须提供 `SVN_AUTHORIZATION`，`SVN_MAX_RESOURCES` 默认为 `200`；认证信息不会写入扩展包，应通过本地配置或运行环境注入。
+系统管理的 `codew-workspace-guard` 由 `init` 自动安装或升级，不出现在普通扩展选择列表中，也不能手动安装、升级或卸载。普通扩展包从 Nexus 下载、验证，并缓存到用户级 Extension Store。
 
 扩展入口在独立 Node 进程中运行，只向临时 staging 目录生成文件。Host 会在事务安装前拒绝未声明、缺失、符号链接、非文件、路径逃逸、目标冲突和 hash 不匹配的制品。Workspace 状态存放在 `.codew/ext-manifest.json`。扩展失败以 warning 报告，不回滚已成功的核心初始化，也不阻止后续扩展；升级失败会恢复并保留旧的已安装版本。
 
-扩展可以独占完整文件，也可以声明由 Host 管理的抽象 Hook。Host 通过 Codex/Claude adaptor
+扩展可以独占完整文件，也可以声明由 Host 管理的抽象 Hook。Host 通过 Codex/Claude 适配器（adapter）
 把声明转换为各自的原生配置，并在扩展安装、升级和卸载时动态插拔；共享目标由 Code
 Workspace 合成和验证，扩展不会直接 patch 真实 Workspace。卸载只使用已安装状态，不执行
 扩展代码；扩展所有的文件或贡献存在未知修改时会拒绝覆盖或删除。
 
-这是故障隔离，不是恶意代码安全沙箱。试验版本只信任随 Code Workspace 发布的扩展代码，或从已配置公司 Nexus 下载并通过归档、身份、manifest、入口、runtime 和 package digest 验证的扩展包。外部扩展目录、扩展依赖、任意 patch、强制卸载、禁用命令和通过 `codew update` 自动更新扩展仍不支持。开发契约见 `docs/extensions.zh-CN.md`；从目录结构到打包发布的完整流程见 `docs/extension-development/extension-development-guide.zh-CN.md`。
+这是故障隔离，不是恶意代码安全沙箱。试验版本信任随 Code Workspace 发布的系统扩展代码，以及从公司 Nexus 下载并通过归档、身份、manifest、入口、runtime 和 package digest 验证的普通扩展包。外部扩展目录、扩展依赖、任意 patch、强制卸载、禁用命令和通过 `codew update` 自动更新扩展仍不支持。开发契约见 `docs/extensions.zh-CN.md`；从目录结构到打包发布的完整流程见 `docs/extension-development/extension-development-guide.zh-CN.md`。
 
 ## 注册项目
 
 项目检查是只读操作：
 
 ```bash
-code-workspace project inspect /absolute/path/to/project --json
+codew project inspect /absolute/path/to/project --json
 ```
 
 Claude Code 用户可显式调用：
@@ -121,7 +135,7 @@ Claude Code 用户可显式调用：
 Codex 用户可对相同的显式路径调用 `$codew-add-projects`。底层自动化可通过 stdin 一次传入完整项目记录：
 
 ```bash
-cat projects.json | code-workspace project add --stdin --yes --json
+cat projects.json | codew project add --stdin --yes --json
 ```
 
 `--stdin` 接受 `{ "schemaVersion": 1, "projects": [...] }` 形式且与 `--projects-file` 相同语义的 JSON，必须与 `--yes` 一起使用，并在输入为空、无效或超过 1 MiB 时于写入前失败。`--stdin`、`--project-file`、`--projects-file` 与位置路径只能选择一个。
@@ -157,16 +171,16 @@ projects:
 ## 日常命令
 
 ```bash
-code-workspace project list --json
-code-workspace project show payments --json
-code-workspace project verify payments --json
-code-workspace project branch inspect payments --json
-code-workspace project branch verify payments --json
-code-workspace project branch use-registered payments --yes --json
-code-workspace project branch accept-actual payments --yes --json
-code-workspace project branch update-latest payments --json
-code-workspace permissions apply --yes --json
-code-workspace doctor --json
+codew project list --json
+codew project show payments --json
+codew project verify payments --json
+codew project branch inspect payments --json
+codew project branch verify payments --json
+codew project branch use-registered payments --yes --json
+codew project branch accept-actual payments --yes --json
+codew project branch update-latest payments --json
+codew permissions apply --yes --json
+codew doctor --json
 ```
 
 `project branch inspect` 只检查命名项目，返回 `registeredBranch`、`actualBranch`、是否一致、worktree 是否干净、注册分支是否在本地存在以及远程跟踪候选。`project branch verify` 是协调后的窄范围断言，只检查注册分支和实际分支是否一致，不执行项目整体健康校验。`PROJECT_BRANCH_MISMATCH` 诊断使用 `registeredBranch`、`actualBranch` 和 `location`；使用旧分支诊断或结果字段的调用方必须迁移到这套规范状态合同。
@@ -200,20 +214,20 @@ AI/Agent 不得直接编辑该文件；可以读取策略并调用已注册的 C
 ## 更新与语言
 
 ```bash
-code-workspace update --json
-code-workspace update --language en-US --json
-code-workspace language --json
+codew update --json
+codew update --language en-US --json
+codew language --json
 ```
 
 `update` 只刷新 Workspace 自有托管资产，绝不会修改 Agent 目录授权。遇到未知本地修改时，会在任何写入前终止批次；请先审查修改，或显式传入 `--force`。
 
 ## 监控
 
-监控以内置 `monitor` 扩展的形式提供。先在 Workspace 中安装扩展，再通过通用扩展运行时启动面板：
+监控以 Nexus 中的 `monitor` 扩展提供。先在 Workspace 中安装扩展，再通过通用扩展运行时启动面板：
 
 ```bash
-code-workspace extension install monitor --yes
-code-workspace ext monitor serve --port 3211
+codew extension install monitor --yes
+codew ext monitor serve --port 3211
 ```
 
 监控服务仅绑定 loopback，可汇总多个已初始化工作区的事件；hook 上报（`codew ext monitor report`）失败不会阻断 Agent。依赖监控前，请在 Codex 中检查并信任项目 hook。
@@ -221,8 +235,8 @@ code-workspace ext monitor serve --port 3211
 ## 命令补全
 
 ```bash
-code-workspace completion --shell zsh
-code-workspace completion --shell bash
+codew completion --shell zsh
+codew completion --shell bash
 ```
 
 `completion` 会根据完整命令注册表输出脚本，包括子命令和各命令专属选项；它不会安装脚本或修改 Shell 配置。使用 `--json` 时，脚本位于 `data.script`。

package/artifacts/manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 2,
-  "releaseVersion": "1.0.0-beta.1",
+  "releaseVersion": "1.0.0-beta.3",
   "requirements": {
     "node": ">=20.19.0"
   },

package/docs/extension-architecture.zh-CN.md

@@ -30,7 +30,7 @@ Host 不理解 Jira、npm、tar.gz 或某个具体 Agent 的业务含义，但
 
 - 不执行来自任意第三方的不可信扩展。
 - 不提供安全沙箱、容器或操作系统级文件和网络隔离。
-- 不提供扩展市场、动态安装扩展包或远程扩展发现。
+- 普通扩展通过配置的 Nexus Registry 发现和安装；系统扩展仍随 Host 发布。
 - 不提供任意 Workspace 外部副作用及其补偿机制。
 - 不允许扩展自定义卸载脚本。
 - 不负责管理扩展运行后产生的业务数据，例如 Jira 附件。
@@ -62,7 +62,7 @@ Host 是 Code Workspace 中负责扩展生命周期治理的核心实现。Host
 
 ### 4.2 扩展仓库
 
-扩展仓库是 Code Workspace 发布包中用于保存内置扩展的目录集合。基础版不从网络发现或安装扩展定义。
+扩展仓库是 Code Workspace 发布包中用于保存系统扩展的目录集合。普通扩展不从该目录发现，而是通过配置的 Nexus Registry 和已验证 Extension Store 获取。
 
 扩展还可以通过 manifest 的 `hooks` 声明抽象 Workspace Hook。Hook 声明由 Host 通过
 Codex/Claude adaptor 转换为原生配置，并随扩展安装、升级和卸载动态插拔；扩展不得把

package/docs/extension-development/extension-development-guide.zh-CN.md

@@ -35,7 +35,7 @@ Host 负责确认、校验、事务提交、状态记录、升级和卸载。
 
 ## 2. 包目录
 
-内置扩展使用固定版本目录：
+系统扩展使用固定版本目录；普通扩展在独立仓库中维护并发布到 Nexus：
 
 ```text
 extensions/<extension-id>/<version>/
@@ -248,7 +248,7 @@ Host 拒绝：
 
 ## 5. 本地验证与安装测试
 
-在临时 Workspace 安装内置扩展：
+在临时 Workspace 安装已发布扩展：
 
 ```bash
 codew init /tmp/example-workspace --tools codex --extensions example-extension --yes
@@ -292,7 +292,7 @@ codew extension install example-extension --offline --version 1.0.0 --yes
 codew extension upgrade example-extension --yes
 ```
 
-默认安装选择最高的兼容、稳定、非 deprecated 版本；`name@version` 位置语法和 SemVer range 不支持。prerelease 必须通过精确 `--version` 请求；deprecated 版本必须同时使用 `--version` 和 `--allow-deprecated`。`--offline` 禁止网络，只使用内置目录和已验证 Store。`init` 不会隐式查询 Nexus。
+默认安装选择最高的兼容、稳定、非 deprecated 版本；`name@version` 位置语法和 SemVer range 不支持。prerelease 必须通过精确 `--version` 请求；deprecated 版本必须同时使用 `--version` 和 `--allow-deprecated`。`--offline` 禁止网络，只使用已验证 Store。`init` 只在用户明确选择普通扩展时查询 Nexus；系统扩展仍由 Host 自动管理。
 
 ## 6. npm/Nexus 打包
 
@@ -304,7 +304,7 @@ code-workspace extension pack extensions/example-extension/1.0.0 --output dist/e
 
 输出目录缺失时会递归创建。目标文件已存在时命令拒绝覆盖；重复打包前使用新的输出目录，或清理上一次构建产物。
 
-内置扩展可以一次打包并校验全部普通版本：
+扩展仓库可以一次打包并校验全部普通版本（系统扩展会被排除）：
 
 ```bash
 npm run pack:extensions

package/docs/extension-development/nexus-publish.zh-CN.md

@@ -2,7 +2,7 @@
 
 本文面向需要把 Code Workspace 扩展发布到公司 Nexus 的开发者，覆盖从登录、打包、上传到远端验证的完整流程。
 
-本文只描述 **普通扩展** 的发布。系统扩展是否发布由发布策略决定，不要默认上传 `extensions/.system/` 下的包。
+本文只描述 **普通扩展** 的发布。系统扩展由 Host 随包管理，不进入 Nexus 普通扩展发布集合；不要把 `extensions/codew-workspace-guard/` 下的包上传到 Registry。
 
 ## 1. 前置条件
 
@@ -37,9 +37,7 @@ npm config set @codew-ext:registry "$NEXUS"
 登录：
 
 ```bash
-npm login \
-  --auth-type=legacy \
-  --registry="$NEXUS"
+npm login --auth-type=legacy --registry="$NEXUS"
 ```
 
 确认登录状态：

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "code-workspace-zhuiyi",
-  "version": "1.0.0-beta.1",
+  "version": "1.0.0-beta.3",
   "description": "Local multi-project registry and safety layer for AI coding workspaces",
   "author": "icebearx-ai",
   "license": "MIT",

package/src/cli/commands/config.js

@@ -0,0 +1,50 @@
+const {
+  canonicalSettingKey,
+  deleteExtensionSetting,
+  listExtensionSettings,
+  resolveExtensionSettings,
+  setExtensionSetting,
+} = require("../../core/extension-settings");
+const { success } = require("../result");
+
+function settingEntries(options = {}) {
+  const listed = listExtensionSettings(options);
+  return Object.entries(listed.values).map(([key, entry]) => ({ key, value: entry.value, source: entry.source }));
+}
+
+function displayKey(canonical) {
+  return canonical === "authType" ? "extensions.auth-type" : `extensions.${canonical}`;
+}
+
+function executeConfig(invocation) {
+  const action = invocation.definition.path[1];
+  const options = invocation.dependencies || {};
+  if (action === "list") {
+    const entries = settingEntries(options);
+    return success("config.list", { file: listExtensionSettings(options).file, settings: entries }, entries.map((entry) => `${entry.key}=${entry.value} (${entry.source})`).join("\n"));
+  }
+  if (action === "get") {
+    if (!invocation.args[0]) {
+      const entries = settingEntries(options);
+      return success("config.get", { file: listExtensionSettings(options).file, settings: entries }, entries.map((entry) => `${entry.key}=${entry.value} (${entry.source})`).join("\n"));
+    }
+    const key = canonicalSettingKey(invocation.args[0]);
+    const settings = resolveExtensionSettings(options);
+    const field = key === "authType" ? "authType" : key;
+    const value = settings.values[field];
+    const source = settings.configured[field] ? "user" : "default";
+    return success("config.get", { file: settings.file, key: displayKey(key), value, source }, `${value}`);
+  }
+  if (action === "set") {
+    const settings = setExtensionSetting(invocation.args[0], invocation.args[1], options);
+    const canonical = canonicalSettingKey(invocation.args[0]);
+    const key = displayKey(canonical);
+    return success("config.set", { file: settings.file, key, value: settings.values[canonical] }, `Set ${key}=${settings.values[canonical]}`);
+  }
+  const settings = deleteExtensionSetting(invocation.args[0], options);
+  const canonical = canonicalSettingKey(invocation.args[0]);
+  const key = displayKey(canonical);
+  return success("config.delete", { file: settings.file, key, value: settings.values[canonical], source: "default" }, `Reset ${key} to ${settings.values[canonical]}`);
+}
+
+module.exports = { executeConfig };

package/src/cli/commands/ext.js

@@ -1,16 +1,11 @@
 const { commandResult, success } = require("../result");
 const { executeExtensionRuntime } = require("../../core/extension-runtime");
-const { ensureStoredExtensionPackage, defaultExtensionStoreRoot } = require("../../core/extension-store");
-const { discoverExtensions } = require("../../core/extensions");
+const { defaultExtensionStoreRoot } = require("../../core/extension-store");
 
 async function executeExt(invocation) {
   const id = invocation.args[0];
   const argv = invocation.args.slice(1);
   const extensionStoreRoot = invocation.dependencies?.extensionStoreRoot || defaultExtensionStoreRoot();
-  const builtin = discoverExtensions({ tolerant: true }).catalog.find((entry) => entry.id === id)?.latestSupported;
-  if (builtin) {
-    ensureStoredExtensionPackage({ storeRoot: extensionStoreRoot, sourceRoot: builtin.sourceRoot, source: "builtin" });
-  }
   const runtime = await executeExtensionRuntime({
     id,
     argv,