@dev-mainsequence/codex-plugin 0.7.10 → 0.7.12
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/.codex-plugin/plugin.json +1 -1
- package/README.md +149 -155
- package/build-info.json +3 -3
- package/dist/hosts/workspace.js +5 -2
- package/dist/panel-server.js +6 -1
- package/dist/vendor/devtools/index.js +2 -1
- package/dist/vendor/devtools/package.json +1 -1
- package/dist/vendor/devtools/shared/projectTools.js +88 -44
- package/docs/agents-tools-panel.md +115 -508
- package/docs/conversational-mcp.md +86 -47
- package/package.json +4 -4
- package/docs/codex-verification.md +0 -161
|
@@ -1,67 +1,106 @@
|
|
|
1
1
|
# Conversational project MCP connections
|
|
2
2
|
|
|
3
|
-
With the
|
|
3
|
+
With the plugin loaded and a usable MainSequence developer session, ask:
|
|
4
4
|
|
|
5
5
|
1. "Which internal MCPs are available?"
|
|
6
6
|
2. "Add metatable-mcp."
|
|
7
7
|
3. "Use it to list my tables."
|
|
8
8
|
|
|
9
|
-
Codex discovers the directory, saves your selection, reads that project's current tools and
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
9
|
+
Codex discovers the directory, saves your selection, reads that project's current tools and
|
|
10
|
+
invokes them through the bundled client. You do not need a slash command, settings edit or
|
|
11
|
+
restart between adding a project and using it. Saved selections work in later
|
|
12
|
+
conversations. When several releases share a name, select the intended release and
|
|
13
|
+
environment.
|
|
14
|
+
|
|
15
|
+
Connections are owned by the plugin. They do not create separate entries in Codex's native
|
|
16
|
+
MCP list. Installing or updating the plugin itself still follows the host's plugin
|
|
17
|
+
lifecycle.
|
|
18
|
+
|
|
19
|
+
Every saved connection's tools are also registered directly as `ms_<tool>_<hash>` tools
|
|
20
|
+
with the project's own schemas, the way the Claude Desktop plugin registers them, so "list
|
|
21
|
+
my contacts" is one tool call with no context or environment argument. The registration
|
|
22
|
+
comes from devtools' shared project-tool catalog (`project-tool-catalog.json` beside
|
|
23
|
+
`mcp-connections.json`, shared with the Claude Desktop plugin), refreshed in the
|
|
24
|
+
background; a connection saved in the current chat is registered from the next chat on,
|
|
25
|
+
and is usable at once through `mainsequence_tools` / `mainsequence_call_tool`. The plugin's
|
|
26
|
+
server allows Codex tool calls 300 seconds, because a cold project MCP can take more than
|
|
27
|
+
the host's 60-second default to answer.
|
|
14
28
|
|
|
15
29
|
## Runner and library
|
|
16
30
|
|
|
17
|
-
The conversational skill prefers native `mainsequence_*` tools, which share a
|
|
31
|
+
The conversational skill prefers the native `mainsequence_*` tools, which share a
|
|
18
32
|
persistent devtools connection cache. It opens account context once, reads saved
|
|
19
|
-
connections, inspects schemas, then calls the selected tool. The bundled runner is
|
|
20
|
-
|
|
33
|
+
connections, inspects schemas, then calls the selected tool. The bundled runner is a
|
|
34
|
+
fallback when native tools are unavailable:
|
|
21
35
|
|
|
22
36
|
| Command | Result |
|
|
23
37
|
| --- | --- |
|
|
24
|
-
| mcp-discover [--search TEXT] [--limit N] [--offset N] | A page from resource_release.mcp_endpoints
|
|
25
|
-
| mcp-add --uid RELEASE_UUID | Verify connection and tool catalog, then remember it. |
|
|
26
|
-
| mcp-list | Saved metadata for the selected backend; no health claim. |
|
|
27
|
-
| mcp-remove --uid RELEASE_UUID | Forget one connection without logging out. |
|
|
28
|
-
| mcp-tools --uid RELEASE_UUID | Read the current tools and their input schemas. |
|
|
29
|
-
| mcp-call --uid RELEASE_UUID --tool NAME [--arguments-file FILE] | Invoke the selected tool once; preserve its structured/content result. |
|
|
30
|
-
|
|
31
|
-
Run commands with node dist/runner.js
|
|
32
|
-
|
|
33
|
-
|
|
38
|
+
| `mcp-discover [--search TEXT] [--limit N] [--offset N]` | A page from `resource_release.mcp_endpoints`; no local mutation. |
|
|
39
|
+
| `mcp-add --uid RELEASE_UUID` | Verify connection and tool catalog, then remember it. |
|
|
40
|
+
| `mcp-list` | Saved metadata for the selected backend; no health claim. |
|
|
41
|
+
| `mcp-remove --uid RELEASE_UUID` | Forget one connection without logging out. |
|
|
42
|
+
| `mcp-tools --uid RELEASE_UUID` | Read the current tools and their input schemas. |
|
|
43
|
+
| `mcp-call --uid RELEASE_UUID --tool NAME [--arguments-file FILE]` | Invoke the selected tool once; preserve its structured/content result. |
|
|
44
|
+
|
|
45
|
+
Run commands with `node dist/runner.js`, or the installed `ms-devtools` command. All accept
|
|
46
|
+
`--backend URL` and `--json`. The JSON argument file contains the tool's argument object;
|
|
47
|
+
omission supplies an empty object. It is limited to 1 MB. No credentials are accepted as
|
|
48
|
+
command arguments.
|
|
49
|
+
|
|
50
|
+
The exported `createDevTools().dispatch()` accepts the same `mcp-*` actions through
|
|
51
|
+
`ActionRequest`; `mcp-call` uses `releaseUid`, `tool` and `arguments`. Hosts can inject
|
|
52
|
+
`mcpConnectionsPath` for their own local metadata location.
|
|
34
53
|
|
|
35
54
|
## Access and saved data
|
|
36
55
|
|
|
37
|
-
The plugin uses the existing developer machine session for central discovery and release
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
56
|
+
The plugin uses the existing developer machine session for central discovery and release
|
|
57
|
+
credential exchange. A short-lived credential for the selected FastAPI release
|
|
58
|
+
authenticates project requests; the platform login token never goes to the project
|
|
59
|
+
endpoint. Credentials are not persisted with connections or exposed in results. The
|
|
60
|
+
machine session renews privately.
|
|
61
|
+
|
|
62
|
+
If no developer session exists, use the MainSequence hosted login (**Settings → Sign in with
|
|
63
|
+
browser**, or `/ms login --backend URL`). A central Codex OAuth connection does not provide
|
|
64
|
+
that session. Browser sign-in may be necessary once; adding further project connections
|
|
65
|
+
reuses the developer session.
|
|
66
|
+
|
|
67
|
+
Connection metadata lives in `mcp-connections.json` beside the MainSequence CLI
|
|
68
|
+
configuration, separated by backend and release UID. The native process reuses verified
|
|
69
|
+
release metadata, a release grant and schemas for at most 60 seconds, bounded by credential
|
|
70
|
+
expiry; a prepared call sends only the business `tools/call` request, and an explicit
|
|
71
|
+
schema read fetches the current catalog. Shared login and saved connection changes, expiry
|
|
72
|
+
and transport failures invalidate the cache; each call keeps its own cancellation signal.
|
|
73
|
+
Credentials and results are never persisted in this cache. A changed endpoint requires an
|
|
74
|
+
explicit add again. Removing a connection does not revoke your login. Separate runner
|
|
75
|
+
processes perform fresh setup.
|
|
76
|
+
|
|
77
|
+
The release UID identifies a connection. `mcp-add` also reads the release's name, its
|
|
78
|
+
repository's name and its repository branch from the release directory and stores them
|
|
79
|
+
with the connection as `name`, `display_name` and `code_repository_branch_uid`, so
|
|
80
|
+
`mcp-list` labels a saved connection without a backend request; a connection saved
|
|
81
|
+
without them is completed by the first listing that can read those labels, and a label
|
|
82
|
+
that cannot be read is left out rather than making the MCP unavailable. Discovery rows
|
|
83
|
+
carry `name` and `code_repository_branch_uid` as the platform directory reports them.
|
|
84
|
+
|
|
85
|
+
Project tools enforce their ordinary permissions. The client adds no agent-specific
|
|
86
|
+
allowlist or exclusions.
|
|
46
87
|
|
|
47
88
|
## Failures and limits
|
|
48
89
|
|
|
49
|
-
Access denial, an unavailable release, or a corrupt connection file is reported without
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
See [ADR 0002](adr/0002-conversational-project-mcp-client.md) for the approved design and authentication decision.
|
|
90
|
+
Access denial, an unavailable release, or a corrupt connection file is reported without
|
|
91
|
+
deleting the saved connection or changing accounts. All project requests use the current
|
|
92
|
+
stateless Streamable HTTP profile. Stateful sessions, subscriptions, tasks and deprecated
|
|
93
|
+
SSE endpoints are unsupported.
|
|
94
|
+
|
|
95
|
+
A tool call is never retried automatically. A timeout, interrupted stream or cancellation
|
|
96
|
+
may follow a completed remote operation. If the result reports partial-or-uncertain
|
|
97
|
+
effects, check the operation's outcome before repeating it. A remote tool failure is
|
|
98
|
+
labelled `MCP_TOOL_ERROR`, distinct from an HTTP or protocol `API_ERROR`; the native tool
|
|
99
|
+
result and the panel preserve the original `content`, `structuredContent` and
|
|
100
|
+
uncertain-effects warning, so a CRM `not_found` or `forbidden` response is visible instead
|
|
101
|
+
of being discarded, with known authentication credentials redacted. Cold setup verifies
|
|
102
|
+
the shared account remotely; prepared calls check the selected credentials locally before
|
|
103
|
+
and after execution; server-side authorization still applies to every call.
|
|
104
|
+
|
|
105
|
+
See [ADR 0002](adr/0002-conversational-project-mcp-client.md) for the design and
|
|
106
|
+
authentication decision.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@dev-mainsequence/codex-plugin",
|
|
3
|
-
"version": "0.7.
|
|
3
|
+
"version": "0.7.12",
|
|
4
4
|
"description": "MainSequence for Codex: durable agent messaging in native chat, Agents and Tools discovery, developer commands and conversational MCPs",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"engines": {
|
|
@@ -17,7 +17,6 @@
|
|
|
17
17
|
"dist",
|
|
18
18
|
"docs/agents-tools-panel.md",
|
|
19
19
|
"docs/conversational-mcp.md",
|
|
20
|
-
"docs/codex-verification.md",
|
|
21
20
|
"docs/adr",
|
|
22
21
|
"README.md",
|
|
23
22
|
"LICENSE",
|
|
@@ -37,10 +36,11 @@
|
|
|
37
36
|
"verify:package": "node scripts/verify-package.cjs",
|
|
38
37
|
"verify:codex": "node scripts/verify-codex-host.cjs",
|
|
39
38
|
"verify:codex:reload": "node scripts/verify-codex-reload.cjs",
|
|
40
|
-
"release:check": "npm run typecheck && npm test && node scripts/check-release.cjs && node scripts/pack-codex.cjs && npm pack --ignore-scripts --pack-destination artifacts && npm run verify:package"
|
|
39
|
+
"release:check": "npm run typecheck && npm test && node scripts/check-release.cjs && node scripts/check-docs.cjs && node scripts/pack-codex.cjs && npm pack --ignore-scripts --pack-destination artifacts && npm run verify:package",
|
|
40
|
+
"check:docs": "node scripts/check-docs.cjs"
|
|
41
41
|
},
|
|
42
42
|
"dependencies": {
|
|
43
|
-
"@dev-mainsequence/devtools": "0.3.
|
|
43
|
+
"@dev-mainsequence/devtools": "0.3.14"
|
|
44
44
|
},
|
|
45
45
|
"devDependencies": {
|
|
46
46
|
"@types/node": "18.19.130",
|
|
@@ -1,161 +0,0 @@
|
|
|
1
|
-
# Codex plugin verification
|
|
2
|
-
|
|
3
|
-
## 0.3.1 — devtools 0.3.1: MCP names stored with saved connections (2026-10-22)
|
|
4
|
-
|
|
5
|
-
The plugin bundles [devtools 0.3.1](https://github.com/mainsequence-sdk/mainsequence-devtools/pull/15)
|
|
6
|
-
in place of 0.3.0; the hook adapter, manifest, hooks and skills are otherwise unchanged, so
|
|
7
|
-
the hook definition and its trusted hash are the same as in 0.3.0.
|
|
8
|
-
|
|
9
|
-
What the new devtools changes for this plugin:
|
|
10
|
-
|
|
11
|
-
- `mcp-add` resolves the release's name, its repository's name and its repository branch
|
|
12
|
-
and stores them with the saved connection in the shared `mcp-connections.json` as `name`,
|
|
13
|
-
`display_name` and `code_repository_branch_uid`. A label that cannot be read is left out;
|
|
14
|
-
it never makes a working MCP unavailable.
|
|
15
|
-
- `mcp-list` returns the stored labels without a backend request. A connection saved by an
|
|
16
|
-
earlier version is completed by the first listing that can read its labels. `mcp-add`,
|
|
17
|
-
`mcp-tools` and `mcp-call` results carry them on their connection, and discovery rows pass
|
|
18
|
-
the directory's `name` and `code_repository_branch_uid` through.
|
|
19
|
-
- The connections file is shared with the Claude Desktop plugin (0.4.18 pins the same
|
|
20
|
-
devtools), so a connection labelled by either host is labelled for both.
|
|
21
|
-
- The readable `/ms` output labels the new fields (`Release ID`, `Name`, `Repository`,
|
|
22
|
-
`Repository branch ID`); `--json` passes the rows to the `mainsequence-mcp` skill unchanged.
|
|
23
|
-
|
|
24
|
-
Package checks under Node 22.22.0 and npm 10.9.4, `npm run release:check`: type-check, build
|
|
25
|
-
from the registry archive of devtools 0.3.1 (`npm ci --ignore-scripts`; its integrity in
|
|
26
|
-
`package-lock.json` and `build-info.json` is the registry's `dist.integrity`), the Node tests
|
|
27
|
-
including a new case for the stored MCP connection labels in readable and `--json` output, release metadata, the standalone
|
|
28
|
-
archive and the npm archive exercised as Codex installs it. Since the pinned devtools is on
|
|
29
|
-
the registry, CI no longer names a devtools source branch; `scripts/install-devtools.cjs`
|
|
30
|
-
falls back to the pin's release tag only for an unpublished pin.
|
|
31
|
-
|
|
32
|
-
Installed-host checks with the Codex CLI 0.163.0 on macOS, in isolated `CODEX_HOME`
|
|
33
|
-
directories, the only model endpoint being the counted loopback fixture: `npm run
|
|
34
|
-
verify:codex` against this build installed from `artifacts/local-marketplace` and trusted
|
|
35
|
-
(`skills/list` and `hooks/list` as recorded for 0.3.0; all 13 prompt cases and both sync
|
|
36
|
-
cases behaved as in the 0.3.0 table below, with zero real model requests), and
|
|
37
|
-
`npm run verify:codex:reload` (same three results as for 0.3.0). The hook definition did
|
|
38
|
-
not change, so its trusted hash is still `sha256:8935862c…`.
|
|
39
|
-
|
|
40
|
-
## 0.3.0 — extraction from devtools and rename to `mainsequence` (2026-10-21)
|
|
41
|
-
|
|
42
|
-
The plugin moved out of [mainsequence-devtools](https://github.com/mainsequence-sdk/mainsequence-devtools)
|
|
43
|
-
(its [ADR 0003](https://github.com/mainsequence-sdk/mainsequence-devtools/blob/main/docs/adr/0003-codex-plugin-extraction.md))
|
|
44
|
-
and was renamed from `mainsequence-devtools` to `mainsequence` by the owner's decision. The
|
|
45
|
-
one open question was how an installed Codex host treats the marketplace change: an update
|
|
46
|
-
of the installed plugin, or a new plugin. Everything below ran against the Codex CLI bundled
|
|
47
|
-
with the desktop app, version 0.163.0-alpha.10.2 on macOS, in isolated `CODEX_HOME`
|
|
48
|
-
directories; the user's own Codex home was not touched, and the only model endpoint was a
|
|
49
|
-
counted loopback fixture that rejects inference. The npm package was not published yet, so
|
|
50
|
-
the renamed plugin was installed from a local marketplace copy of the built `codex/`
|
|
51
|
-
artifact; `npm run release:check` verifies that the npm archive contains the same files.
|
|
52
|
-
|
|
53
|
-
### Marketplace change in an installed host
|
|
54
|
-
|
|
55
|
-
A marketplace shaped like the devtools one (name `mainsequence`) first listed the former
|
|
56
|
-
entry, `mainsequence-devtools` from `@dev-mainsequence/devtools@0.2.8`, which Codex installed
|
|
57
|
-
from the npm registry. Its hook was trusted by copying the already reviewed hook hash into
|
|
58
|
-
`config.toml`. The marketplace file was then replaced by the new single entry `mainsequence`.
|
|
59
|
-
|
|
60
|
-
| Step | `codex plugin list` | `hooks/list` | `skills/list` | `/ms --help` |
|
|
61
|
-
| --- | --- | --- | --- | --- |
|
|
62
|
-
| 1. Old plugin installed and trusted | `mainsequence-devtools@mainsequence` installed, enabled, 0.2.8 | old hook trusted, enabled | `mainsequence-devtools:ms`, `mainsequence-devtools:mainsequence-mcp` | blocked by the old hook, 0 model requests |
|
|
63
|
-
| 2. Marketplace entry replaced, nothing else changed | no installed plugin listed; `mainsequence@mainsequence` available, not installed | old hook still trusted and enabled | old skills still registered | blocked by the old hook, 0 model requests |
|
|
64
|
-
| 3. New plugin installed, hook not yet trusted | `mainsequence@mainsequence` installed, enabled, 0.3.0 | old hook trusted; new hook untrusted | both plugins' skills, two entries named `ms` | blocked by the old hook only, 0 model requests |
|
|
65
|
-
| 4. New hook trusted as well | same | both trusted | same | blocked twice, once per hook, 0 model requests |
|
|
66
|
-
| 5. `codex plugin remove mainsequence-devtools@mainsequence` | `mainsequence@mainsequence` only | new hook only | `mainsequence:ms`, `mainsequence:mainsequence-mcp` | blocked once, 0 model requests; an ordinary prompt passes through with 1 fixture request |
|
|
67
|
-
|
|
68
|
-
Findings:
|
|
69
|
-
|
|
70
|
-
- Codex identifies a plugin by `<marketplace entry name>@<marketplace name>`. Replacing the
|
|
71
|
-
entry is **a new plugin, not an update**: `mainsequence@mainsequence` installs beside
|
|
72
|
-
`mainsequence-devtools@mainsequence` into `plugins/cache/mainsequence/mainsequence/0.3.0`.
|
|
73
|
-
- The old install keeps running from Codex's cache after its marketplace entry disappears.
|
|
74
|
-
`config.toml` still has `[plugins."mainsequence-devtools@mainsequence"] enabled = true`,
|
|
75
|
-
the app server still loads its hook and skills, and `/ms` is still intercepted, although
|
|
76
|
-
`codex plugin list` no longer shows it. `codex plugin remove` still accepts its id.
|
|
77
|
-
- Hook trust is recorded per plugin id. The trusted hash is identical for both ids
|
|
78
|
-
(`sha256:8935862c…`) because the hook definition did not change, so what a user reviews
|
|
79
|
-
for the new plugin is exactly what they reviewed before, but the new id must be trusted
|
|
80
|
-
once; until then the new hook does not run.
|
|
81
|
-
- With both plugins installed and trusted, both hooks run on every `/ms` and both block the
|
|
82
|
-
turn, and the slash menu carries two `ms` entries. Removing the old plugin is therefore part
|
|
83
|
-
of the upgrade, not optional cleanup. Removal leaves the old `hooks.state` trust entry in
|
|
84
|
-
`config.toml`; it is inert.
|
|
85
|
-
|
|
86
|
-
Migration note for users of `mainsequence-devtools` (also in the README):
|
|
87
|
-
|
|
88
|
-
```sh
|
|
89
|
-
codex plugin marketplace upgrade mainsequence
|
|
90
|
-
codex plugin add mainsequence@mainsequence
|
|
91
|
-
codex plugin remove mainsequence-devtools@mainsequence
|
|
92
|
-
```
|
|
93
|
-
|
|
94
|
-
then review and trust the new plugin's hook and start a new chat (or toggle the plugin in
|
|
95
|
-
the desktop Plugins settings). The MainSequence login and saved MCP connections live
|
|
96
|
-
outside the plugin and need no migration.
|
|
97
|
-
|
|
98
|
-
### Installed host check (`npm run verify:codex`)
|
|
99
|
-
|
|
100
|
-
Run with `CODEX_HOME` pointing at the isolated home from step 5 above and
|
|
101
|
-
`MAINSEQUENCE_CODEX_PLUGIN_ID=mainsequence@mainsequence`. `skills/list` reported the enabled
|
|
102
|
-
`mainsequence:ms` entry with display name `ms`; `hooks/list` reported the hook trusted and
|
|
103
|
-
enabled. Every handled prompt blocked with zero model requests; ordinary prompts reached the
|
|
104
|
-
offline fixture once.
|
|
105
|
-
|
|
106
|
-
| Prompt | Action result | Host hook status | Model requests |
|
|
107
|
-
| --- | --- | --- | --- |
|
|
108
|
-
| selected `ms` + `--help` | success | blocked | 0 |
|
|
109
|
-
| selected `ms` + `--help --json` | success, structured output | blocked | 0 |
|
|
110
|
-
| selected `ms` + `--help` with the desktop's trailing newline | success | blocked | 0 |
|
|
111
|
-
| selected `ms` without arguments | success, help | blocked | 0 |
|
|
112
|
-
| selected `ms` + `invalid-action` | failure | blocked | 0 |
|
|
113
|
-
| selected `ms` + `sync --message "retired option"` | failure, retired option explained | blocked | 0 |
|
|
114
|
-
| literal `/ms --help` ending in LF or CRLF | success | blocked | 0 |
|
|
115
|
-
| literal `/ms --help --all` | success, complete command menu | blocked | 0 |
|
|
116
|
-
| literal `/ms sync --help` | success, command-specific options | blocked | 0 |
|
|
117
|
-
| literal `/ms --help` followed by `status` on another line | failure, invalid request | blocked | 0 |
|
|
118
|
-
| literal `/ms sync` in a Python fixture project | success, dependency files refreshed, Git unchanged, 0 backend requests | blocked | 0, including in flight |
|
|
119
|
-
| selected `ms` + `sync` in a Node fixture project | success, dependency files refreshed, Git unchanged, 0 backend requests | blocked | 0, including in flight |
|
|
120
|
-
| ordinary fixture prompt | passes through | completed | 1, to the offline fixture |
|
|
121
|
-
| `:ms --help` | passes through | completed | 1, to the offline fixture |
|
|
122
|
-
|
|
123
|
-
The sync cases ran the vendored devtools 0.3.0 inside the installed plugin, from Codex's
|
|
124
|
-
cache, without `node_modules`. The script now passes the `mcp_servers.main_sequence`
|
|
125
|
-
override only where that server is configured, since the override is invalid in a home
|
|
126
|
-
without it, and it reports Codex's stderr when the app server exits early.
|
|
127
|
-
|
|
128
|
-
### Existing-chat reload regression (`npm run verify:codex:reload`)
|
|
129
|
-
|
|
130
|
-
Rerun from this repository's artifact in a temporary Codex home with the renamed plugin id.
|
|
131
|
-
Same behaviour as recorded for 0.2.x:
|
|
132
|
-
|
|
133
|
-
| Case | Hook runs | Model requests |
|
|
134
|
-
| --- | --- | --- |
|
|
135
|
-
| Existing thread after external enable | none | 1, rejected by the offline fixture |
|
|
136
|
-
| New thread in the same backend | blocked | 0 |
|
|
137
|
-
| Existing thread after `config/batchWrite` with `reloadUserConfig: true` | blocked | 0 |
|
|
138
|
-
|
|
139
|
-
### Package checks
|
|
140
|
-
|
|
141
|
-
`npm run release:check` under Node 22.22.0 and npm 11.6.2: type-check, build from the
|
|
142
|
-
locally packed devtools 0.3.0 (its archive integrity is recorded in `package-lock.json` and
|
|
143
|
-
`build-info.json`), 15 Node tests (hook dispatch, skill-mention ownership including the
|
|
144
|
-
rejection of the former `mainsequence-devtools:ms` mention, presentation, tokenizer safety,
|
|
145
|
-
Python and Node sync fixtures, the self-contained artifact outside the checkout, and the
|
|
146
|
-
dependency boundary), release metadata, the standalone archive and the npm archive, which
|
|
147
|
-
was unpacked and exercised as Codex installs it (manifest, hooks, skills, bundled runner,
|
|
148
|
-
pass-through, mention handling and the terminal CLI).
|
|
149
|
-
|
|
150
|
-
### Remaining
|
|
151
|
-
|
|
152
|
-
- `@dev-mainsequence/devtools@0.3.0` is not on the registry yet. The lockfile integrity
|
|
153
|
-
comes from a local `npm pack` of the devtools release branch; confirm it against
|
|
154
|
-
`npm view @dev-mainsequence/devtools@0.3.0 dist.integrity` after publication, and update
|
|
155
|
-
the lockfile and rebuild if it differs, before tagging this package.
|
|
156
|
-
- The renamed plugin was installed from a local marketplace source, not from npm. The npm
|
|
157
|
-
install path itself is the one Codex used for 0.2.8 in step 1 and is unchanged.
|
|
158
|
-
- The desktop composer and renderer were not visually verified; the host API, event stream
|
|
159
|
-
and CLI presentation were.
|
|
160
|
-
- The owner's own Codex home still has `mainsequence-devtools@mainsequence` 0.2.7 installed
|
|
161
|
-
and the former local marketplace registered; migrating it is a user step after publication.
|