@dev-mainsequence/codex-plugin 0.7.10 → 0.7.11

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.
@@ -1,67 +1,106 @@
1
1
  # Conversational project MCP connections
2
2
 
3
- With the updated plugin loaded and a usable Main Sequence developer session, ask:
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 invokes them through the bundled client. You do not need a slash command, settings edit or restart between adding a project and using it. Saved selections work in later conversations. When multiple releases have the same name, select the intended release/Environment.
10
-
11
- Connections are owned by the plugin. They do not create separate entries in Codex's native MCP list. Installing or updating the plugin itself still follows the host's plugin lifecycle.
12
-
13
- Since plugin 0.7.8 every saved connection's tools are also registered directly as `ms_<tool>_<hash>` tools with the project's own schemas, the way the Claude Desktop plugin registers them, so "list my contacts" is one tool call with no contextId or environment argument. Since 0.7.9 the registration comes from devtools' shared project-tool catalog (`project-tool-catalog.json` beside `mcp-connections.json`, shared with the Claude Desktop plugin) that is refreshed in the background; a connection saved in the current chat is registered from the next chat on, and is usable at once through `mainsequence_tools` / `mainsequence_call_tool`. The plugin's server also allows Codex tool calls 300 seconds, because a cold project MCP has taken more than the host's 60-second default to answer.
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
- a fallback when native tools are unavailable:
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; no local mutation. |
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, or the installed ms-devtools command. All accept --backend URL and --json. The JSON argument file contains the tool's argument object; omission supplies an empty object. It is limited to 1 MB. No credentials are accepted as command arguments.
32
-
33
- The exported createDevTools().dispatch() accepts the same mcp-* actions through ActionRequest; mcp-call uses releaseUid, tool and arguments. Hosts can inject mcpConnectionsPath for their own local metadata location. Existing session and HostServices options still apply.
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 credential exchange. A short-lived credential for the selected FastAPI release authenticates project requests; the platform login token never goes to the project endpoint. Credentials are not persisted with connections or exposed in results. The normal machine session renews privately.
38
-
39
- If no developer session exists, use the existing Main Sequence hosted login. A central Codex OAuth connection does not automatically provide that session. Browser sign-in may be necessary once; adding subsequent project connections reuses the developer session.
40
-
41
- Connection metadata lives in mcp-connections.json beside the existing MainSequence CLI configuration, separated by backend and release UID. Since plugin 0.7.3 / devtools 0.3.7, the native process reuses verified release metadata, a release grant and schemas for at most 60 seconds, bounded by credential expiry. A prepared call sends only the business `tools/call` request. Explicit schema reads still fetch the current catalog. Shared login and saved connection changes, expiry and transport failures invalidate the cache; each call keeps its own cancellation signal. Credentials and results are never persisted in this cache. A changed endpoint requires an explicit add again. Removing a connection does not revoke your login. Separate runner processes perform fresh setup.
42
-
43
- The release UID identifies a connection. Since devtools 0.3.1, mcp-add also reads the release's name, its repository's name and its repository branch from the release directory and stores them with the connection as `name`, `display_name` and `code_repository_branch_uid`, so mcp-list labels a saved connection without a backend request; a connection saved by an earlier version is completed by the first listing that can read those labels, and a label that cannot be read is left out rather than making the MCP unavailable. Adding a connection and reading or calling its tools work without the labels, and UID-based operations do not repeat discovery to obtain a name. Discovery rows carry `name` and `code_repository_branch_uid` as the platform directory reports them.
44
-
45
- Project tools enforce their ordinary permissions. The client adds no agent-specific allowlist or exclusions.
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 deleting the saved connection or changing accounts. All project requests use the current stateless Streamable HTTP profile. Stateful sessions, subscriptions, tasks and deprecated SSE endpoints are unsupported.
50
-
51
- A tool call is never retried automatically. A timeout, interrupted stream or cancellation may follow a completed remote operation. If the result reports partial-or-uncertain effects, check the operation's outcome before repeating it. Tool errors retain their server result for diagnosis, with known authentication credentials redacted.
52
-
53
- Since plugin 0.7.2 / devtools 0.3.6, a remote tool failure is labelled
54
- `MCP_TOOL_ERROR`, distinct from an HTTP/protocol `API_ERROR`. The native tool result
55
- and panel preserve the original `content`, `structuredContent` and uncertain-effects
56
- warning. A CRM `not_found` or `forbidden` response is therefore visible instead of
57
- being discarded. Cold setup verifies the shared account remotely. Prepared calls
58
- check the selected credentials locally before and after execution; server-side
59
- authorization still applies to every call.
60
-
61
- ## Validation and release boundary
62
-
63
- The protocol, credential-isolation, saved-connection and packaged-client fixtures run in the devtools test suite, where the client lives; this repository's tests cover the skill, the hook and the packaged plugin. None of them access the user's credential store or invoke real project tools. The built plugin and npm archive include the conversational skill and the vendored client without runtime npm dependencies.
64
-
65
- This source change does not publish a package, replace an immutable installed plugin version or establish live desktop end-to-end proof. A versioned plugin release/update and a read-only smoke test against a selected deployed MCP are the remaining rollout steps.
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.10",
3
+ "version": "0.7.11",
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,7 +36,8 @@
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
43
  "@dev-mainsequence/devtools": "0.3.12"
@@ -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.