golem15/msd-core
4
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: hard-fork GSD -> MSD (Make Software Done)

Browse Source 
Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD
across contents and paths, upstream package/repo coordinates -> @golem15/msd-core
and golem15com/msd-core. Deep links into upstream history, sibling upstream
packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is.

Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line,
package/plugin identity, regenerated lockfile, install-tree fixtures, derived
registries and benchmark baseline; migration checksum baseline re-locked
(MSD keeps its own install state, so no install had applied the old sums);
sort-order and regex-escaped expectations in tests adjusted.
This commit is contained in:
Jakub Zych
2026-10-06 01:47:40 +02:00
parent fe069b2a56
commit a9a7a328e6
2763 changed files with 78465 additions and 78434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
vscode/browser.js
View File

@@ -1,7 +1,7 @@
'use strict';
/**
* GSD extension for VS Code — WEB (browser) entry, #2103.
* MSD extension for VS Code — WEB (browser) entry, #2103.
*
* This is the `browser` entry point (vscode/package.json `"browser": "./browser.js"`),
* loaded by VS Code Web / vscode.dev in a webworker context. It has ZERO Node
@@ -12,20 +12,20 @@
* at load time and breaks activation.
*
* WHY THIS FILE DOES NOT REQUIRE `./host-binding.js` OR `./extension.js`
* (a deliberate deviation from "compose the seams via bindGsdToVscode" — see
* (a deliberate deviation from "compose the seams via bindMsdToVscode" — see
* the #2103 dispatch-crux note below):
*
* `host-binding.js`'s `bindGsdToVscode` is NOT actually web-safe once its
* `host-binding.js`'s `bindMsdToVscode` is NOT actually web-safe once its
* transitive dependencies are checked — three of its four required engine-lib
* modules pull in Node's `fs`/`os`/`path` at module-load time (eagerly, on
* every `require()`, regardless of which code path runs):
* - gsd-core/bin/lib/state-io.cjs → requires 'node:fs' directly.
* - gsd-core/bin/lib/adapter-imperative.cjs → requires install-engine.cjs +
* - msd-core/bin/lib/state-io.cjs → requires 'node:fs' directly.
* - msd-core/bin/lib/adapter-imperative.cjs → requires install-engine.cjs +
* capability-loader.cjs (fs/os/path).
* - gsd-core/bin/lib/model-adapter.cjs → requires model-resolver.cjs →
* - msd-core/bin/lib/model-adapter.cjs → requires model-resolver.cjs →
* config-loader.cjs (fs/os/path) +
* configuration.cjs (fs/path).
* (gsd-core/bin/lib/hook-bus.cjs alone has no requires and is genuinely
* (msd-core/bin/lib/hook-bus.cjs alone has no requires and is genuinely
* web-safe.) Requiring `host-binding.js` here would transitively pull in
* `node:fs` and throw at web-worker load time — the opposite of "zero Node
* APIs". See host-binding.js's own header comment for the full chain. Fixing
@@ -37,18 +37,18 @@
* So this file implements its OWN minimal, independently-verified-zero-Node-API
* composition directly against `vscode.lm` — no engine-lib requires at all.
*
* DISPATCH STORY ON WEB (per the #2103 dispatch-crux design): full GSD engine
* dispatch (the gsd-tools.cjs subprocess-shim `dispatchGsdCommand` used by the
* DISPATCH STORY ON WEB (per the #2103 dispatch-crux design): full MSD engine
* dispatch (the msd-tools.cjs subprocess-shim `dispatchMsdCommand` used by the
* desktop `extension.js`) is fundamentally a Node `child_process.spawnSync`
* call — there is no web-worker equivalent. On web, GSD command dispatch is
* available through VS Code's NATIVE MCP client connecting to the GSD
* companion MCP server (gsd-core/bin/lib/mcp-server.cjs, `gsd-mcp-server`
* call — there is no web-worker equivalent. On web, MSD command dispatch is
* available through VS Code's NATIVE MCP client connecting to the MSD
* companion MCP server (msd-core/bin/lib/mcp-server.cjs, `msd-mcp-server`
* bin entry — a separate, already-existing surface; this file does NOT
* implement an MCP client itself, it only points the user at that story).
* The chat participant and Language Model Tools registered below are
* therefore intentionally limited on web: they register (so the surface is
* discoverable and `#runSubagent`-eligible per VS Code's chat engine) but
* their handlers return an honest "configure the GSD MCP server for full
* their handlers return an honest "configure the MSD MCP server for full
* dispatch on web" message rather than silently failing or faking success.
*/
@@ -74,16 +74,16 @@ function parseChatPrompt(rawPrompt) {
*/
function webDispatchUnavailableMessage(family) {
return (
`GSD web mode: full engine dispatch for "${family}" is not available in the browser ` +
'(the VS Code Web/webworker host has no Node runtime, so the gsd-tools.cjs ' +
'subprocess dispatch used on desktop cannot run here). Configure the GSD MCP ' +
'server (gsd-mcp-server) as a VS Code MCP server for full command dispatch on web, ' +
'or use the desktop GSD Core extension.'
`MSD web mode: full engine dispatch for "${family}" is not available in the browser ` +
'(the VS Code Web/webworker host has no Node runtime, so the msd-tools.cjs ' +
'subprocess dispatch used on desktop cannot run here). Configure the MSD MCP ' +
'server (msd-mcp-server) as a VS Code MCP server for full command dispatch on web, ' +
'or use the desktop MSD Core extension.'
);
}
/**
* Registers the `@gsd` chat participant in web mode (#2103). Its handler is
* Registers the `@msd` chat participant in web mode (#2103). Its handler is
* honest about the web dispatch limitation — see webDispatchUnavailableMessage.
* Exported separately so it is testable with a mock `vscode.chat`.
* @param {object} vscode
@@ -94,7 +94,7 @@ function registerChatParticipant(vscode, context) {
if (!vscode || !vscode.chat || typeof vscode.chat.createChatParticipant !== 'function') {
return null;
}
const participant = vscode.chat.createChatParticipant('gsd', async (request, _chatContext, stream, _token) => {
const participant = vscode.chat.createChatParticipant('msd', async (request, _chatContext, stream, _token) => {
const { family } = parseChatPrompt(request && request.prompt);
if (stream && typeof stream.markdown === 'function') {
stream.markdown(webDispatchUnavailableMessage(family));
@@ -111,7 +111,7 @@ function registerChatParticipant(vscode, context) {
* vscode.lm.registerTool registration name — so the manifest is identical
* across both entry points), but with web-mode invoke() handlers.
*/
const LM_TOOL_NAMES = ['gsd_progress', 'gsd_workstreams', 'gsd_plan_phase'];
const LM_TOOL_NAMES = ['msd_progress', 'msd_workstreams', 'msd_plan_phase'];
/**
* Registers web-mode LM tools via vscode.lm.registerTool (#2103). Each
@@ -164,7 +164,7 @@ function detectSubagentSupport(vscode) {
/**
* VS Code Web extension activation. Registers the chat participant + Language
* Model Tools in web mode. Does NOT register the `gsd.invoke` command with a
* Model Tools in web mode. Does NOT register the `msd.invoke` command with a
* real-dispatch handler (there is no Node dispatch on web) — the command is
* still contributed (contributes.commands in package.json is shared across
* desktop/web), so it is registered here too, but its handler returns the
@@ -174,12 +174,12 @@ function detectSubagentSupport(vscode) {
function activate(context) {
const vscode = require('vscode');
const gsdCommand = vscode.commands.registerCommand('gsd.invoke', async (args) => {
const msdCommand = vscode.commands.registerCommand('msd.invoke', async (args) => {
const a = (args && typeof args === 'object') ? args : {};
const family = (typeof a.family === 'string' && a.family) ? a.family : '--help';
return JSON.stringify({ ok: false, stdout: '', stderr: webDispatchUnavailableMessage(family), code: null, timedOut: false });
});
context.subscriptions.push(gsdCommand);
context.subscriptions.push(msdCommand);
registerChatParticipant(vscode, context);
registerLanguageModelTools(vscode, context);