code-workspace-zhuiyi 0.1.0-beta.6 → 0.1.0-beta.7
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 +11 -40
- package/README.zh-CN.md +11 -40
- package/artifacts/manifest.json +6 -17
- package/artifacts/templates/claude/commands/code-workspace/add-projects.md +51 -9
- package/artifacts/templates/codex/skills/code-workspace-add-projects/SKILL.md +48 -11
- package/artifacts/templates/user-guide/en-US.md +1 -1
- package/artifacts/templates/user-guide/zh-CN.md +1 -1
- package/extensions/zhuiyi-jira-mcp/1.0.0/artifacts/claude/server.json +21 -0
- package/extensions/zhuiyi-jira-mcp/1.0.0/artifacts/codex/config.toml +18 -0
- package/extensions/zhuiyi-jira-mcp/1.0.0/artifacts/gitignore +2 -0
- package/extensions/zhuiyi-jira-mcp/1.0.0/init.js +56 -0
- package/extensions/zhuiyi-jira-mcp/1.0.0/lib/archive.js +200 -0
- package/extensions/zhuiyi-jira-mcp/1.0.0/manifest.json +45 -0
- package/extensions/zhuiyi-jira-mcp/1.0.0/release.json +15 -0
- package/extensions/zhuiyi-opensvn-mcp/0.1.0/artifacts/claude/server.json +12 -0
- package/extensions/zhuiyi-opensvn-mcp/0.1.0/artifacts/codex/config.toml +9 -0
- package/extensions/zhuiyi-opensvn-mcp/0.1.0/init.js +53 -0
- package/extensions/zhuiyi-opensvn-mcp/0.1.0/lib/archive.js +200 -0
- package/extensions/zhuiyi-opensvn-mcp/0.1.0/manifest.json +38 -0
- package/extensions/zhuiyi-opensvn-mcp/0.1.0/release.json +15 -0
- package/package.json +2 -3
- package/src/cli/commands/init.js +0 -3
- package/src/cli/commands/project.js +68 -15
- package/src/cli/commands/update.js +3 -30
- package/src/cli/registry.js +3 -19
- package/src/cli.js +0 -2
- package/src/core/doctor.js +3 -22
- package/src/core/init.js +0 -3
- package/src/core/initializer.js +6 -40
- package/src/core/managed-files.js +11 -52
- package/src/hooks/adapters/claude.js +3 -68
- package/src/hooks/adapters/codex.js +3 -67
- package/src/hooks/adapters/common.js +1 -169
- package/src/hooks/adapters/index.js +4 -42
- package/src/hooks/index.js +0 -2
- package/src/index.js +1 -7
- package/artifacts/templates/claude/task-coordination-settings.json +0 -13
- package/artifacts/templates/codex/task-coordination-hooks.json +0 -12
- package/bin/code-workspace-task-hook.js +0 -54
- package/src/cli/commands/task.js +0 -75
- package/src/core/task-coordination-managed.js +0 -179
- package/src/core/task-coordination-protocol.js +0 -213
- package/src/core/task-coordination.js +0 -1077
- package/src/hooks/claude-task-coordination.js +0 -3
- package/src/hooks/codex-task-coordination.js +0 -3
package/README.md
CHANGED
|
@@ -34,7 +34,6 @@ code-workspace init . \
|
|
|
34
34
|
```
|
|
35
35
|
|
|
36
36
|
Use `--tools claude`, `--tools codex`, or `--tools none` to override the default tool selection. Codex monitoring is enabled by default when Codex is selected; use `--no-monitor` to disable it.
|
|
37
|
-
Pass `--coordination` to install the write-coordination Hooks into the selected providers' native configuration.
|
|
38
37
|
|
|
39
38
|
Initialization writes only Workspace-owned state and integrations:
|
|
40
39
|
|
|
@@ -42,7 +41,7 @@ Initialization writes only Workspace-owned state and integrations:
|
|
|
42
41
|
- `USER_GUIDE.md`
|
|
43
42
|
- `CLAUDE.md` and/or `AGENTS.md`
|
|
44
43
|
- Workspace-specific commands and skills whose names start with `code-workspace-` or use the `/code-workspace` namespace
|
|
45
|
-
- `.codex/hooks.json` when monitoring
|
|
44
|
+
- `.codex/hooks.json` when monitoring is enabled
|
|
46
45
|
|
|
47
46
|
It does not create `openspec/`, install native `/opsx` commands, or install native `openspec-*` skills.
|
|
48
47
|
|
|
@@ -52,9 +51,11 @@ It does not create `openspec/`, install native `/opsx` commands, or install nati
|
|
|
52
51
|
|
|
53
52
|
```bash
|
|
54
53
|
code-w init . --extensions zhuiyi-jira-mcp --yes
|
|
54
|
+
code-w init . --extensions zhuiyi-opensvn-mcp --yes
|
|
55
55
|
code-w init . --extensions none --yes
|
|
56
56
|
code-w extension install
|
|
57
57
|
code-w extension install zhuiyi-jira-mcp --yes
|
|
58
|
+
code-w extension install zhuiyi-opensvn-mcp --yes
|
|
58
59
|
code-w extension uninstall zhuiyi-jira-mcp --yes
|
|
59
60
|
```
|
|
60
61
|
|
|
@@ -64,7 +65,9 @@ Users select names, not versions; `zhuiyi-jira-mcp@0.1.0` is intentionally rejec
|
|
|
64
65
|
|
|
65
66
|
`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.
|
|
66
67
|
|
|
67
|
-
The bundled `zhuiyi-jira-mcp`
|
|
68
|
+
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.
|
|
69
|
+
|
|
70
|
+
`zhuiyi-opensvn-mcp` accesses OpenSVN static resources through `opssvn.in.wezhuiyi.com`. Its runtime configuration requires `SVN_AUTHORIZATION` and optionally accepts `SVN_OUTPUT_DIR` and `SVN_MAX_RESOURCES`; credentials are not stored in the extension package and should be supplied through local configuration or the runtime environment.
|
|
68
71
|
|
|
69
72
|
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 `.code-workspace/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.
|
|
70
73
|
|
|
@@ -91,12 +94,14 @@ Claude Code users can invoke:
|
|
|
91
94
|
/code-workspace:add-projects /absolute/path/to/project-a /absolute/path/to/project-b
|
|
92
95
|
```
|
|
93
96
|
|
|
94
|
-
Codex users can invoke `$code-workspace-add-projects` with the same explicit paths. For low-level automation,
|
|
97
|
+
Codex users can invoke `$code-workspace-add-projects` with the same explicit paths. For low-level automation, pass complete project records through stdin:
|
|
95
98
|
|
|
96
99
|
```bash
|
|
97
|
-
code-workspace project add --
|
|
100
|
+
cat projects.json | code-workspace project add --stdin --yes --json
|
|
98
101
|
```
|
|
99
102
|
|
|
103
|
+
`--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.
|
|
104
|
+
|
|
100
105
|
The registry stores each project's name, real location, registered branch, type, and context. The registered branch is the Code Workspace expected state; the actual branch is observed from the selected Git worktree. Workspace never guesses a path from a conversation or automatically decides which branch is authoritative.
|
|
101
106
|
|
|
102
107
|
Project registration is always stored in a separate file in the `.code-workspace` directory. Initialization uses `config-projects.yaml` by default, while `projects.ref` may name any safe regular filename in that directory:
|
|
@@ -121,7 +126,7 @@ projects:
|
|
|
121
126
|
Service ownership and navigation context.
|
|
122
127
|
```
|
|
123
128
|
|
|
124
|
-
`projects.ref` is resolved relative to `config.yaml`. It must be one safe regular filename in the same `.code-workspace` directory; URLs, globs, absolute paths, path traversal, and inline `projects` arrays are not supported.
|
|
129
|
+
`projects.ref` is resolved relative to `config.yaml`. It must be one safe regular filename in the same `.code-workspace` directory; URLs, globs, absolute paths, path traversal, and inline `projects` arrays are not supported. Existing project command arguments and behavior remain compatible, `project add` additionally supports `--stdin`, and project data is still read from and written to the referenced file. The `.code-workspace/` directory is ignored by default, so Git history for this local registry requires an explicit repository policy.
|
|
125
130
|
|
|
126
131
|
For example, `ref: team-projects.yaml` makes the project registry `.code-workspace/team-projects.yaml`; the default remains `config-projects.yaml`.
|
|
127
132
|
|
|
@@ -168,45 +173,11 @@ AI/Agent must not directly edit this file. They may read the policy and invoke t
|
|
|
168
173
|
|
|
169
174
|
`permissions apply` shows the complete authorization plan for the selected Agent tools, requires confirmation when changes are needed, applies and verifies the requested grants, and reports the result per tool. Agent directory access remains a user authorization. The command adds missing registered-project access but does not revoke additional directories; use `project remove` or edit the Agent settings explicitly to revoke access.
|
|
170
175
|
|
|
171
|
-
## Coordinate concurrent Agent writes
|
|
172
|
-
|
|
173
|
-
When trusted Codex or Claude Hooks are installed, Code Workspace keeps the coordination ledger outside the Workspace and reserves write ranges before a supported tool runs. Different files in one project can proceed after an explicit project-parallel approval; overlapping files are denied without a force override.
|
|
174
|
-
|
|
175
|
-
Inspect tasks, claims, and pending recovery decisions:
|
|
176
|
-
|
|
177
|
-
```bash
|
|
178
|
-
code-workspace task list --json
|
|
179
|
-
code-workspace task show <task-id> --json
|
|
180
|
-
code-workspace task lock list --json
|
|
181
|
-
code-workspace task decision show <request-id> --json
|
|
182
|
-
```
|
|
183
|
-
|
|
184
|
-
Resolve a pending decision only after reviewing its evidence. Planned-write commands require confirmation; automation must pass `--yes` and always retry the original Agent operation after a successful decision:
|
|
185
|
-
|
|
186
|
-
```bash
|
|
187
|
-
code-workspace task decision keep <request-id> --yes --json
|
|
188
|
-
code-workspace task decision approve <request-id> --yes --json
|
|
189
|
-
code-workspace task decision release <request-id> --yes --json
|
|
190
|
-
code-workspace task decision abandon <request-id> --yes --json
|
|
191
|
-
```
|
|
192
|
-
|
|
193
|
-
`ACTIVE` file conflicts cannot be overridden. `UNKNOWN` reservations remain protected until the user keeps them or abandons the entire generation; a known live process blocks abandon. The mechanism covers only trusted, enabled, supported Agent Hooks and is not an OS-level sandbox for editors, shells, or external processes.
|
|
194
|
-
|
|
195
|
-
Hook support matrix (schema v1):
|
|
196
|
-
|
|
197
|
-
| Provider | Lifecycle events | Write events | Target handling |
|
|
198
|
-
| --- | --- | --- | --- |
|
|
199
|
-
| Codex | `SessionStart`, `UserPromptSubmit`, `PermissionRequest`, `Stop`, `SessionEnd` | `PreToolUse`, `PostToolUse` and available failure events | Known Edit/Write-style tools use exact files; unknown shell/tools use `PROJECT_WIDE` |
|
|
200
|
-
| Claude | `SessionStart`, `UserPromptSubmit`, `PermissionRequest`, `Stop`, `StopFailure`, `SessionEnd` | `PreToolUse`, `PostToolUse`, `PostToolUseFailure` | Same normalized core decisions and scope rules as Codex |
|
|
201
|
-
|
|
202
|
-
The adapters are versioned fixtures rather than a promise that future Agent releases keep identical native fields. New or unrecognized tools fail closed as possible writes; Hook enforcement does not cover bypassed or disabled Hooks, external editors, or arbitrary OS processes.
|
|
203
|
-
|
|
204
176
|
## Update and language
|
|
205
177
|
|
|
206
178
|
```bash
|
|
207
179
|
code-workspace update --json
|
|
208
180
|
code-workspace update --language zh-CN --json
|
|
209
|
-
code-workspace update --coordination --json
|
|
210
181
|
code-workspace language --json
|
|
211
182
|
```
|
|
212
183
|
|
package/README.zh-CN.md
CHANGED
|
@@ -34,7 +34,6 @@ code-workspace init . \
|
|
|
34
34
|
```
|
|
35
35
|
|
|
36
36
|
可用 `--tools claude`、`--tools codex` 或 `--tools none` 覆盖默认工具选择。选择 Codex 时默认启用监控;可传 `--no-monitor` 关闭。
|
|
37
|
-
传入 `--coordination` 可把与 Monitor 独立的写入协调 Hook 安装到选中工具的原生配置中。
|
|
38
37
|
|
|
39
38
|
初始化只写入 Workspace 自有状态和集成:
|
|
40
39
|
|
|
@@ -42,7 +41,7 @@ code-workspace init . \
|
|
|
42
41
|
- `USER_GUIDE.md`
|
|
43
42
|
- `CLAUDE.md` 和/或 `AGENTS.md`
|
|
44
43
|
- 名称以 `code-workspace-` 开头或使用 `/code-workspace` 命名空间的 Workspace 专用命令与 Skill
|
|
45
|
-
-
|
|
44
|
+
- 启用监控时的 `.codex/hooks.json`
|
|
46
45
|
|
|
47
46
|
它不会创建 `openspec/`,不会安装原生 `/opsx` 命令,也不会安装原生 `openspec-*` Skill。
|
|
48
47
|
|
|
@@ -52,9 +51,11 @@ code-workspace init . \
|
|
|
52
51
|
|
|
53
52
|
```bash
|
|
54
53
|
code-w init . --extensions zhuiyi-jira-mcp --yes
|
|
54
|
+
code-w init . --extensions zhuiyi-opensvn-mcp --yes
|
|
55
55
|
code-w init . --extensions none --yes
|
|
56
56
|
code-w extension install
|
|
57
57
|
code-w extension install zhuiyi-jira-mcp --yes
|
|
58
|
+
code-w extension install zhuiyi-opensvn-mcp --yes
|
|
58
59
|
code-w extension uninstall zhuiyi-jira-mcp --yes
|
|
59
60
|
```
|
|
60
61
|
|
|
@@ -64,7 +65,9 @@ code-w extension uninstall zhuiyi-jira-mcp --yes
|
|
|
64
65
|
|
|
65
66
|
`extension install` 不会重新执行 Workspace 核心初始化。在 JSON、非 TTY 或 `--yes` 模式下,必须至少提供一个扩展名。多个名称按顺序安装,只确认一次且各自使用独立事务;任一扩展失败会使安装命令失败,但后续扩展仍会继续执行。
|
|
66
67
|
|
|
67
|
-
|
|
68
|
+
当前随包提供的内置扩展包括 `zhuiyi-jira-mcp` 和 `zhuiyi-opensvn-mcp`,分别用于为选中的 Agent 工具配置 Jira MCP 与 OpenSVN MCP 服务;它们不会创建 `openspec/` 目录,也不会安装 OpenSpec 原生命令。
|
|
69
|
+
|
|
70
|
+
`zhuiyi-opensvn-mcp` 使用 `opssvn.in.wezhuiyi.com` 访问 OpenSVN 静态资源。运行时必须在对应 Agent 配置中提供 `SVN_AUTHORIZATION`,可选配置 `SVN_OUTPUT_DIR` 和 `SVN_MAX_RESOURCES`;认证信息不会写入扩展包,应通过本地配置或运行环境注入。
|
|
68
71
|
|
|
69
72
|
扩展入口在独立 Node 进程中运行,只向临时 staging 目录生成文件。Host 会在事务安装前拒绝未声明、缺失、符号链接、非文件、路径逃逸、目标冲突和 hash 不匹配的制品。Workspace 状态存放在 `.code-workspace/ext-manifest.json`。扩展失败以 warning 报告,不回滚已成功的核心初始化,也不阻止后续扩展;升级失败会恢复并保留旧的已安装版本。
|
|
70
73
|
|
|
@@ -89,12 +92,14 @@ Claude Code 用户可显式调用:
|
|
|
89
92
|
/code-workspace:add-projects /absolute/path/to/project-a /absolute/path/to/project-b
|
|
90
93
|
```
|
|
91
94
|
|
|
92
|
-
Codex 用户可对相同的显式路径调用 `$code-workspace-add-projects
|
|
95
|
+
Codex 用户可对相同的显式路径调用 `$code-workspace-add-projects`。底层自动化可通过 stdin 一次传入完整项目记录:
|
|
93
96
|
|
|
94
97
|
```bash
|
|
95
|
-
code-workspace project add --
|
|
98
|
+
cat projects.json | code-workspace project add --stdin --yes --json
|
|
96
99
|
```
|
|
97
100
|
|
|
101
|
+
`--stdin` 接受 `{ "schemaVersion": 1, "projects": [...] }` 形式且与 `--projects-file` 相同语义的 JSON,必须与 `--yes` 一起使用,并在输入为空、无效或超过 1 MiB 时于写入前失败。`--stdin`、`--project-file`、`--projects-file` 与位置路径只能选择一个。
|
|
102
|
+
|
|
98
103
|
注册表保存项目名称、真实路径、注册分支、类型和上下文。注册分支是 Code Workspace 的期望状态,实际分支是从选中 Git worktree 观测到的状态。Workspace 不会根据对话猜测路径,也不会自动判断哪一侧分支更权威。
|
|
99
104
|
|
|
100
105
|
项目注册配置始终独立保存于 `.code-workspace` 目录下的单独文件。初始化默认使用 `config-projects.yaml`,但 `projects.ref` 可以引用该目录下任意安全的普通文件名:
|
|
@@ -119,7 +124,7 @@ projects:
|
|
|
119
124
|
服务职责和代码导航上下文。
|
|
120
125
|
```
|
|
121
126
|
|
|
122
|
-
`projects.ref` 相对于 `config.yaml` 解析,必须是同一 `.code-workspace` 目录下的安全普通文件名。不支持 URL、glob、绝对路径、路径逃逸或内联 `projects`
|
|
127
|
+
`projects.ref` 相对于 `config.yaml` 解析,必须是同一 `.code-workspace` 目录下的安全普通文件名。不支持 URL、glob、绝对路径、路径逃逸或内联 `projects` 数组。项目命令的现有参数和行为保持兼容,`project add` 额外支持 `--stdin`;项目数据仍只读取和写入引用文件。`.code-workspace/` 默认被忽略;如需 Git 历史,需要显式制定仓库策略。
|
|
123
128
|
|
|
124
129
|
例如,`ref: team-projects.yaml` 会将项目注册表放在 `.code-workspace/team-projects.yaml`;默认名称仍为 `config-projects.yaml`。
|
|
125
130
|
|
|
@@ -166,45 +171,11 @@ AI/Agent 不得直接编辑该文件;可以读取策略并调用已注册的 C
|
|
|
166
171
|
|
|
167
172
|
`permissions apply` 会展示选中 Agent 工具的完整授权计划,在需要修改时要求确认,实施并验证请求的授权,并按工具报告结果。Agent 目录访问仍属于用户授权。该命令只补齐已注册项目缺失的访问权限,不撤销额外目录;如需撤销,请使用 `project remove` 或显式编辑 Agent 设置。
|
|
168
173
|
|
|
169
|
-
## 协调并行 Agent 写入
|
|
170
|
-
|
|
171
|
-
安装并信任 Codex 或 Claude 协调 Hook 后,Code Workspace 会把协调台账保存在 Workspace 外部,并在受支持工具真正运行前预约写入范围。同一项目写不同文件时,经过一次明确的项目并行确认即可继续;范围重叠时强制拒绝,不提供强制覆盖。
|
|
172
|
-
|
|
173
|
-
查询任务、范围 claim 和待处理裁决:
|
|
174
|
-
|
|
175
|
-
```bash
|
|
176
|
-
code-workspace task list --json
|
|
177
|
-
code-workspace task show <task-id> --json
|
|
178
|
-
code-workspace task lock list --json
|
|
179
|
-
code-workspace task decision show <request-id> --json
|
|
180
|
-
```
|
|
181
|
-
|
|
182
|
-
查看证据后再处理裁决。写入型命令需要确认;自动化场景必须传 `--yes`,裁决成功后始终重新执行原 Agent 操作:
|
|
183
|
-
|
|
184
|
-
```bash
|
|
185
|
-
code-workspace task decision keep <request-id> --yes --json
|
|
186
|
-
code-workspace task decision approve <request-id> --yes --json
|
|
187
|
-
code-workspace task decision release <request-id> --yes --json
|
|
188
|
-
code-workspace task decision abandon <request-id> --yes --json
|
|
189
|
-
```
|
|
190
|
-
|
|
191
|
-
`ACTIVE` 文件冲突不能覆盖。`UNKNOWN` reservation 必须由用户选择保留,或放弃整个 generation;已知旧进程仍存活时不能 abandon。该机制只覆盖已信任、已启用且受支持的 Agent Hook,不是编辑器、Shell 或外部进程的 OS 级沙箱。
|
|
192
|
-
|
|
193
|
-
Hook 支持矩阵(schema v1):
|
|
194
|
-
|
|
195
|
-
| Provider | 生命周期事件 | 写入事件 | 目标处理 |
|
|
196
|
-
| --- | --- | --- | --- |
|
|
197
|
-
| Codex | `SessionStart`、`UserPromptSubmit`、`PermissionRequest`、`Stop`、`SessionEnd` | `PreToolUse`、`PostToolUse` 及可用失败事件 | 已知 Edit/Write 类工具使用 exact 文件;未知 Shell/工具使用 `PROJECT_WIDE` |
|
|
198
|
-
| Claude | `SessionStart`、`UserPromptSubmit`、`PermissionRequest`、`Stop`、`StopFailure`、`SessionEnd` | `PreToolUse`、`PostToolUse`、`PostToolUseFailure` | 与 Codex 使用相同的归一化核心决策和范围规则 |
|
|
199
|
-
|
|
200
|
-
适配器通过版本化 fixture 固化输入,而不是承诺未来 Agent 版本保持相同原生字段。新增或无法识别的工具按可能写入处理并 fail closed;Hook 强制范围不包含被绕过或禁用的 Hook、外部编辑器或任意 OS 进程。
|
|
201
|
-
|
|
202
174
|
## 更新与语言
|
|
203
175
|
|
|
204
176
|
```bash
|
|
205
177
|
code-workspace update --json
|
|
206
178
|
code-workspace update --language en-US --json
|
|
207
|
-
code-workspace update --coordination --json
|
|
208
179
|
code-workspace language --json
|
|
209
180
|
```
|
|
210
181
|
|
package/artifacts/manifest.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 2,
|
|
3
|
-
"releaseVersion": "0.1.0-beta.
|
|
3
|
+
"releaseVersion": "0.1.0-beta.7",
|
|
4
4
|
"requirements": {
|
|
5
5
|
"node": ">=20.19.0"
|
|
6
6
|
},
|
|
@@ -13,26 +13,15 @@
|
|
|
13
13
|
"id": "workspace-user-guide-en-US",
|
|
14
14
|
"kind": "asset",
|
|
15
15
|
"path": "templates/user-guide/en-US.md",
|
|
16
|
-
"sha256": "
|
|
16
|
+
"sha256": "a05c1611df919bcb05843d703a5a08c9d7e312c7dd69d1ac198f8bcfc266ec67"
|
|
17
17
|
},
|
|
18
18
|
{
|
|
19
19
|
"id": "workspace-user-guide-zh-CN",
|
|
20
20
|
"kind": "asset",
|
|
21
21
|
"path": "templates/user-guide/zh-CN.md",
|
|
22
|
-
"sha256": "
|
|
22
|
+
"sha256": "b4fb6dee108832c02fc09e179c051678406d486f341b3174aa5e57b4053d740a"
|
|
23
23
|
}
|
|
24
24
|
],
|
|
25
|
-
"coordinationArtifacts": {
|
|
26
|
-
"schemaVersion": 1,
|
|
27
|
-
"sources": [
|
|
28
|
-
{ "id": "task-coordination-codex-hooks", "path": "templates/codex/task-coordination-hooks.json", "sha256": "68fcefa83f75294fd270713e07eb3ea3f266e63dc9d2be4ba77fe8af7596742f" },
|
|
29
|
-
{ "id": "task-coordination-claude-settings", "path": "templates/claude/task-coordination-settings.json", "sha256": "4faedcc67a78c8e7e61e44dc34571e55d0d3a2ce1ce7aa636222e1813505ca29" }
|
|
30
|
-
],
|
|
31
|
-
"managedFiles": [
|
|
32
|
-
{ "id": "task-coordination-codex-hooks", "target": ".codex/task-coordination-hooks.json", "tool": "codex" },
|
|
33
|
-
{ "id": "task-coordination-claude-settings", "target": ".claude/task-coordination-settings.json", "tool": "claude" }
|
|
34
|
-
]
|
|
35
|
-
},
|
|
36
25
|
"managedFiles": [
|
|
37
26
|
{
|
|
38
27
|
"id": "workspace-user-guide",
|
|
@@ -124,7 +113,7 @@
|
|
|
124
113
|
"allowMissing": true,
|
|
125
114
|
"desired": {
|
|
126
115
|
"source": "templates/claude/commands/code-workspace/add-projects.md",
|
|
127
|
-
"sha256": "
|
|
116
|
+
"sha256": "177fbebf35383e1499c274007a2c577a7cd2f727407bcd0a0ca0511f4666dd6e"
|
|
128
117
|
},
|
|
129
118
|
"provenance": {
|
|
130
119
|
"kind": "template"
|
|
@@ -139,7 +128,7 @@
|
|
|
139
128
|
"allowMissing": true,
|
|
140
129
|
"desired": {
|
|
141
130
|
"source": "templates/codex/skills/code-workspace-add-projects/SKILL.md",
|
|
142
|
-
"sha256": "
|
|
131
|
+
"sha256": "1b3a10870bd748244d85945b9a2562b7b30a8792bcd6163d8d53ed73cd9ef619"
|
|
143
132
|
},
|
|
144
133
|
"provenance": {
|
|
145
134
|
"kind": "template"
|
|
@@ -154,7 +143,7 @@
|
|
|
154
143
|
"allowMissing": true,
|
|
155
144
|
"desired": {
|
|
156
145
|
"source": "templates/codex/skills/code-workspace-add-projects/SKILL.md",
|
|
157
|
-
"sha256": "
|
|
146
|
+
"sha256": "1b3a10870bd748244d85945b9a2562b7b30a8792bcd6163d8d53ed73cd9ef619"
|
|
158
147
|
},
|
|
159
148
|
"provenance": {
|
|
160
149
|
"kind": "template"
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: When explicitly invoked with one or more project paths, inspect Git worktrees read-only, generate concise project context, register the completed
|
|
2
|
+
description: When explicitly invoked with one or more project paths, inspect Git worktrees read-only, generate concise AI project context, register the completed records in one stdin transaction, and apply Agent directory authorization.
|
|
3
3
|
argument-hint: "<project path> [additional project paths]"
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -7,17 +7,59 @@ Run this workflow only when the user explicitly invokes `/code-workspace:add-pro
|
|
|
7
7
|
|
|
8
8
|
Expected invocation: `/code-workspace:add-projects /absolute/path/to/project-a /absolute/path/to/project-b`
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
## Collect evidence once
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
Use one read-only terminal invocation for `code-workspace language --json` and every supplied path. Inspect each path independently and continue after a path-specific failure:
|
|
13
13
|
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
14
|
+
```bash
|
|
15
|
+
code-workspace language --json
|
|
16
|
+
for path in "<path-a>" "<path-b>"; do
|
|
17
|
+
printf '\n__PROJECT__ %s\n' "$path"
|
|
18
|
+
output="$(code-workspace project inspect "$path" --json)"
|
|
19
|
+
status=$?
|
|
20
|
+
printf '%s\n' "$output"
|
|
21
|
+
printf '__STATUS__ %s\n' "$status"
|
|
22
|
+
done
|
|
23
|
+
```
|
|
18
24
|
|
|
19
|
-
|
|
25
|
+
Require the standard envelope fields `schemaVersion`, `ok`, `command`, `data`, and `diagnostics`. Use `data.language` and the labels in `data.projectContext` for every generated project context in this invocation. If the language command fails, stop: the workspace language contract is unavailable.
|
|
20
26
|
|
|
21
|
-
|
|
27
|
+
For each inspection:
|
|
28
|
+
|
|
29
|
+
- When `ok` is true, treat only `data.project.location`, `data.project.branch`, and `data.project.facts` as CLI-verified facts, then inspect the repository read-only.
|
|
30
|
+
- When `ok` is false, retain the path, diagnostic code, message, and remediation. Do not inspect that repository or create a project record for it.
|
|
31
|
+
- Continue collecting the remaining paths. Do not stop at the first failed project.
|
|
32
|
+
|
|
33
|
+
## Prepare records
|
|
34
|
+
|
|
35
|
+
For each valid inspection, read only what is needed to understand the repository, starting with README files, root manifests, and relevant entry points or module directories. Do not modify the project repository.
|
|
36
|
+
|
|
37
|
+
Produce a complete project record with `name`, canonical `location`, current `branch`, a concise semantic `type`, and `context`.
|
|
38
|
+
|
|
39
|
+
Generate `context` as concise, stable project navigation for an AI that has not read the repository. Use exactly four semantic lines in this order: `responsibility`, `technologyStack`, `codeLocations`, and `projectBoundary`. Prefix each line with the corresponding label returned in `data.projectContext`; do not translate or replace those labels yourself. Write descriptions in the returned workspace `data.language`. Keep project names, paths, branches, technology names, identifiers, and code symbols unchanged. Prefer 150-400 Chinese characters or comparable English length. Do not include exhaustive dependencies, volatile command details, filler, or unsupported guesses.
|
|
40
|
+
|
|
41
|
+
## Confirm once
|
|
42
|
+
|
|
43
|
+
Present all valid records and every failed path together. If any path failed, state clearly that only the valid records will be written and do not treat the failed paths as ignored without user confirmation. Ask for one decision:
|
|
44
|
+
|
|
45
|
+
- add the valid records;
|
|
46
|
+
- correct and retry failed paths;
|
|
47
|
+
- cancel.
|
|
48
|
+
|
|
49
|
+
If there are no valid records, stop without writing.
|
|
50
|
+
|
|
51
|
+
## Register through stdin
|
|
52
|
+
|
|
53
|
+
After confirmation, serialize one JSON document with `schemaVersion: 1` and a non-empty `projects` array containing only the confirmed valid records. Send it to `code-workspace project add` over stdin:
|
|
54
|
+
|
|
55
|
+
```bash
|
|
56
|
+
code-workspace project add --stdin --yes --json
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
Use the runtime's native stdin channel when available. Do not create a temporary JSON file and do not place the JSON document in command arguments. If a shell heredoc is the only available transport, use a unique, unpredictable, quoted delimiter and pass the serialized JSON unchanged.
|
|
60
|
+
|
|
61
|
+
Completion requires `ok: true`, the expected registered projects, and every applicable permission result to report `verified: true`. `project add` performs the existing configuration and authorization postcondition verification inside its transaction. Do not run `code-workspace project verify --json` by default; run it only when the user explicitly asks for an independent final check.
|
|
62
|
+
|
|
63
|
+
Do not hand-edit `.code-workspace/config.yaml` or permission files.
|
|
22
64
|
|
|
23
65
|
$ARGUMENTS
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: code-workspace-add-projects
|
|
3
|
-
description: When explicitly invoked with one or more project paths, inspect Git worktrees read-only, generate concise AI project context, register the completed records
|
|
3
|
+
description: When explicitly invoked with one or more project paths, inspect Git worktrees read-only, generate concise AI project context, register the completed records in one stdin transaction, and apply Agent directory authorization.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Add local projects
|
|
@@ -9,20 +9,57 @@ Run this workflow only when the user explicitly invokes `$code-workspace-add-pro
|
|
|
9
9
|
|
|
10
10
|
Expected invocation: `$code-workspace-add-projects /absolute/path/to/project-a /absolute/path/to/project-b`
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
## Collect evidence once
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
Use one read-only terminal invocation for `code-workspace language --json` and every supplied path. Inspect each path independently and continue after a path-specific failure:
|
|
15
15
|
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
16
|
+
```bash
|
|
17
|
+
code-workspace language --json
|
|
18
|
+
for path in "<path-a>" "<path-b>"; do
|
|
19
|
+
printf '\n__PROJECT__ %s\n' "$path"
|
|
20
|
+
output="$(code-workspace project inspect "$path" --json)"
|
|
21
|
+
status=$?
|
|
22
|
+
printf '%s\n' "$output"
|
|
23
|
+
printf '__STATUS__ %s\n' "$status"
|
|
24
|
+
done
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Require the standard envelope fields `schemaVersion`, `ok`, `command`, `data`, and `diagnostics`. Use `data.language` and the labels in `data.projectContext` for every generated project context in this invocation. If the language command fails, stop: the workspace language contract is unavailable.
|
|
28
|
+
|
|
29
|
+
For each inspection:
|
|
30
|
+
|
|
31
|
+
- When `ok` is true, treat only `data.project.location`, `data.project.branch`, and `data.project.facts` as CLI-verified facts, then inspect the repository read-only.
|
|
32
|
+
- When `ok` is false, retain the path, diagnostic code, message, and remediation. Do not inspect that repository or create a project record for it.
|
|
33
|
+
- Continue collecting the remaining paths. Do not stop at the first failed project.
|
|
34
|
+
|
|
35
|
+
## Prepare records
|
|
36
|
+
|
|
37
|
+
For each valid inspection, read only what is needed to understand the repository, starting with README files, root manifests, and relevant entry points or module directories. Do not modify the project repository.
|
|
38
|
+
|
|
39
|
+
Produce a complete project record with `name`, canonical `location`, current `branch`, a concise semantic `type`, and `context`.
|
|
20
40
|
|
|
21
|
-
|
|
41
|
+
Generate `context` as concise, stable project navigation for an AI that has not read the repository. Use exactly four semantic lines in this order: `responsibility`, `technologyStack`, `codeLocations`, and `projectBoundary`. Prefix each line with the corresponding label returned in `data.projectContext`; do not translate or replace those labels yourself. Write descriptions in the returned workspace `data.language`. Keep project names, paths, branches, technology names, identifiers, and code symbols unchanged. Prefer 150-400 Chinese characters or comparable English length. Do not include exhaustive dependencies, volatile command details, filler, or unsupported guesses.
|
|
42
|
+
|
|
43
|
+
## Confirm once
|
|
44
|
+
|
|
45
|
+
Present all valid records and every failed path together. If any path failed, state clearly that only the valid records will be written and do not treat the failed paths as ignored without user confirmation. Ask for one decision:
|
|
46
|
+
|
|
47
|
+
- add the valid records;
|
|
48
|
+
- correct and retry failed paths;
|
|
49
|
+
- cancel.
|
|
50
|
+
|
|
51
|
+
If there are no valid records, stop without writing.
|
|
52
|
+
|
|
53
|
+
## Register through stdin
|
|
54
|
+
|
|
55
|
+
After confirmation, serialize one JSON document with `schemaVersion: 1` and a non-empty `projects` array containing only the confirmed valid records. Send it to `code-workspace project add` over stdin:
|
|
22
56
|
|
|
23
57
|
```bash
|
|
24
|
-
code-workspace project add --
|
|
25
|
-
code-workspace project verify --json
|
|
58
|
+
code-workspace project add --stdin --yes --json
|
|
26
59
|
```
|
|
27
60
|
|
|
28
|
-
Do not
|
|
61
|
+
Use the runtime's native stdin channel when available. Do not create a temporary JSON file and do not place the JSON document in command arguments. If a shell heredoc is the only available transport, use a unique, unpredictable, quoted delimiter and pass the serialized JSON unchanged.
|
|
62
|
+
|
|
63
|
+
Completion requires `ok: true`, the expected registered projects, and every applicable permission result to report `verified: true`. `project add` performs the existing configuration and authorization postcondition verification inside its transaction. Do not run `code-workspace project verify --json` by default; run it only when the user explicitly asks for an independent final check.
|
|
64
|
+
|
|
65
|
+
Do not hand-edit `.code-workspace/config.yaml` or permission files.
|
|
@@ -16,7 +16,7 @@ Claude Code:
|
|
|
16
16
|
/code-workspace:add-projects /absolute/path/to/project-a /absolute/path/to/project-b
|
|
17
17
|
```
|
|
18
18
|
|
|
19
|
-
Review the project records and confirm
|
|
19
|
+
Review the project records and confirm once. The add-projects skill uses one read-only collection to inspect every path independently; a failed project reports its diagnostic without stopping the remaining paths or being silently ignored. After confirmation, all valid records are sent to `project add` through stdin in one operation, with no temporary JSON file and no default second verify.
|
|
20
20
|
|
|
21
21
|
## Upgrade Code Workspace
|
|
22
22
|
|
|
@@ -16,7 +16,7 @@ Claude Code:
|
|
|
16
16
|
/code-workspace:add-projects /absolute/path/to/project-a /absolute/path/to/project-b
|
|
17
17
|
```
|
|
18
18
|
|
|
19
|
-
|
|
19
|
+
根据提示检查项目记录并只确认一次。add-projects skill 会用一次只读采集逐项检查路径;某个项目失败时会报告具体诊断并继续检查其他项目,不会静默忽略失败项。确认后,所有有效记录通过 stdin 一次交给 `project add`,不需要临时 JSON 文件,也不会默认追加第二次 verify。
|
|
20
20
|
|
|
21
21
|
## 升级 Code Workspace
|
|
22
22
|
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
{
|
|
2
|
+
"command": "node",
|
|
3
|
+
"args": [
|
|
4
|
+
".code-workspace/extensions/zhuiyi-jira-mcp/1.0.0/dist/index.js"
|
|
5
|
+
],
|
|
6
|
+
"env": {
|
|
7
|
+
"JIRA_AUTH_TYPE": "cookie",
|
|
8
|
+
"JIRA_COOKIE": "",
|
|
9
|
+
"JIRA_API_VERSION": "latest",
|
|
10
|
+
"JIRA_ALLOWED_HOSTS": "jira.in.wezhuiyi.com",
|
|
11
|
+
"JIRA_CUSTOM_FIELD_MAPPING": "{\"acceptanceCriteria\":\"customfield_10042\",\"storyPoints\":\"customfield_10016\"}",
|
|
12
|
+
"JIRA_SUBTASK_ISSUE_TYPE_ID": "10202",
|
|
13
|
+
"JIRA_CACHE_DIR": ".mcp-cache-jira",
|
|
14
|
+
"JIRA_CACHE_TTL": "15m",
|
|
15
|
+
"JIRA_CACHE_MAX_SNAPSHOTS": "10",
|
|
16
|
+
"JIRA_CACHE_STALE_IF_ERROR": "true",
|
|
17
|
+
"JIRA_REQUEST_TIMEOUT": "30s",
|
|
18
|
+
"JIRA_ATTACHMENT_MAX_SIZE": "20MB",
|
|
19
|
+
"JIRA_ATTACHMENT_ALLOWED_TYPES": "pdf,png,jpg,jpeg,gif,webp,txt,md,csv,json,xml,doc,docx,xls,xlsx,ppt,pptx,html"
|
|
20
|
+
}
|
|
21
|
+
}
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
[mcp_servers.zhuiyi-jira]
|
|
2
|
+
command = "node"
|
|
3
|
+
args = [".code-workspace/extensions/zhuiyi-jira-mcp/1.0.0/dist/index.js"]
|
|
4
|
+
|
|
5
|
+
[mcp_servers.zhuiyi-jira.env]
|
|
6
|
+
JIRA_AUTH_TYPE = "cookie"
|
|
7
|
+
JIRA_COOKIE = ""
|
|
8
|
+
JIRA_API_VERSION = "latest"
|
|
9
|
+
JIRA_ALLOWED_HOSTS = "jira.in.wezhuiyi.com"
|
|
10
|
+
JIRA_CUSTOM_FIELD_MAPPING = '{"acceptanceCriteria":"customfield_10042","storyPoints":"customfield_10016"}'
|
|
11
|
+
JIRA_SUBTASK_ISSUE_TYPE_ID = "10202"
|
|
12
|
+
JIRA_CACHE_DIR = ".mcp-cache-jira"
|
|
13
|
+
JIRA_CACHE_TTL = "15m"
|
|
14
|
+
JIRA_CACHE_MAX_SNAPSHOTS = "10"
|
|
15
|
+
JIRA_CACHE_STALE_IF_ERROR = "true"
|
|
16
|
+
JIRA_REQUEST_TIMEOUT = "30s"
|
|
17
|
+
JIRA_ATTACHMENT_MAX_SIZE = "20MB"
|
|
18
|
+
JIRA_ATTACHMENT_ALLOWED_TYPES = "pdf,png,jpg,jpeg,gif,webp,txt,md,csv,json,xml,doc,docx,xls,xlsx,ppt,pptx,html"
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
const fs = require("node:fs");
|
|
4
|
+
const path = require("node:path");
|
|
5
|
+
|
|
6
|
+
const { prepareRelease } = require("./lib/archive");
|
|
7
|
+
const release = require("./release.json");
|
|
8
|
+
|
|
9
|
+
function option(name) {
|
|
10
|
+
const index = process.argv.indexOf(name);
|
|
11
|
+
return index >= 0 ? process.argv[index + 1] : null;
|
|
12
|
+
}
|
|
13
|
+
|
|
14
|
+
function copyOutput(outputRoot, source, target) {
|
|
15
|
+
const destination = path.join(outputRoot, ...target.split("/"));
|
|
16
|
+
fs.mkdirSync(path.dirname(destination), { recursive: true });
|
|
17
|
+
fs.copyFileSync(path.join(__dirname, ...source.split("/")), destination);
|
|
18
|
+
}
|
|
19
|
+
|
|
20
|
+
async function main() {
|
|
21
|
+
const contextFile = option("--context");
|
|
22
|
+
const outputRoot = option("--output");
|
|
23
|
+
const resultFile = option("--result");
|
|
24
|
+
if (!contextFile || !outputRoot || !resultFile) throw new Error("Usage: init.js --context <file> --output <directory> --result <file>");
|
|
25
|
+
const context = JSON.parse(fs.readFileSync(contextFile, "utf8"));
|
|
26
|
+
if (context.schemaVersion !== 1 || context.extensionSpecVersion !== 1 || context.extension?.id !== "zhuiyi-jira-mcp" || context.extension.version !== "1.0.0" || !Array.isArray(context.tools)) throw new Error("Invalid extension context");
|
|
27
|
+
|
|
28
|
+
const outputs = [];
|
|
29
|
+
const runtime = path.join(outputRoot, "runtime");
|
|
30
|
+
await prepareRelease(release, runtime);
|
|
31
|
+
outputs.push({ id: "runtime", source: "runtime" });
|
|
32
|
+
|
|
33
|
+
copyOutput(outputRoot, "artifacts/gitignore", "gitignore");
|
|
34
|
+
outputs.push({ id: "gitignore", source: "gitignore" });
|
|
35
|
+
|
|
36
|
+
if (context.tools.includes("codex")) {
|
|
37
|
+
copyOutput(outputRoot, "artifacts/codex/config.toml", "codex-config.toml");
|
|
38
|
+
outputs.push({ id: "codex-config", source: "codex-config.toml" });
|
|
39
|
+
}
|
|
40
|
+
if (context.tools.includes("claude")) {
|
|
41
|
+
copyOutput(outputRoot, "artifacts/claude/server.json", "claude-server.json");
|
|
42
|
+
outputs.push({ id: "claude-config", source: "claude-server.json" });
|
|
43
|
+
}
|
|
44
|
+
|
|
45
|
+
fs.writeFileSync(resultFile, `${JSON.stringify({
|
|
46
|
+
schemaVersion: 1,
|
|
47
|
+
extensionSpecVersion: 1,
|
|
48
|
+
extension: { id: "zhuiyi-jira-mcp", version: "1.0.0" },
|
|
49
|
+
outputs,
|
|
50
|
+
}, null, 2)}\n`, { mode: 0o600 });
|
|
51
|
+
}
|
|
52
|
+
|
|
53
|
+
main().catch((error) => {
|
|
54
|
+
process.stderr.write(`${error.code ? `${error.code}: ` : ""}${error.message}\n`);
|
|
55
|
+
process.exitCode = 1;
|
|
56
|
+
});
|