bug: workflow-tools.js importLocalModule() references src/ paths instead of dist/

[iMokys]

Description

packages/mcp-server/dist/workflow-tools.js contains 9 importLocalModule() calls that use relative paths pointing to ../../../src/resources/extensions/gsd/.... Since this file runs from its compiled location in dist/, these paths resolve to the src/ directory where only .ts source files exist — not the .js files the dynamic import() expects.

Result: Every MCP tool that calls importLocalModule() fails with:

Cannot find module '.../src/resources/extensions/gsd/db-writer.js'

Affected modules (all 9)

../../../src/resources/extensions/gsd/bootstrap/write-gate.js
../../../src/resources/extensions/gsd/db-writer.js
../../../src/resources/extensions/gsd/doctor.js
../../../src/resources/extensions/gsd/gsd-db.js
../../../src/resources/extensions/gsd/journal.js
../../../src/resources/extensions/gsd/milestone-ids.js
../../../src/resources/extensions/gsd/state.js
../../../src/resources/extensions/gsd/tools/plan-task.js
../../../src/resources/extensions/gsd/tools/workflow-tool-executors.js

Affected tools

gsd_decision_save, gsd_milestone operations, state writes, journal writes, doctor (via MCP), plan-task — any tool that routes through importLocalModule() in workflow-tools.js.

Root cause

packages/mcp-server/src/workflow-tools.ts hardcodes relative paths with src/ prefixes:

const { saveDecisionToDb } = await importLocalModule(
  "../../../src/resources/extensions/gsd/db-writer.js"
);

TypeScript compiles this to dist/workflow-tools.js but string literals pass through unchanged. The importLocalModule() function resolves relative to import.meta.url (the file's own location), so:

• Expected resolution: packages/mcp-server/dist/ + ../../../dist/resources/extensions/gsd/db-writer.js
• Actual resolution: packages/mcp-server/dist/ + ../../../src/resources/extensions/gsd/db-writer.js

Reproduction

1. Install gsd-pi globally: npm i -g gsd-pi
2. Run any project with MCP workflow server configured
3. Call gsd_decision_save (or any tool using importLocalModule)
4. Observe: Cannot find module '.../src/resources/extensions/gsd/db-writer.js'

Workaround

Create symlinks from dist/*.js to the src/ paths:

BASE="$(npm root -g)/gsd-pi"
for f in \
  resources/extensions/gsd/bootstrap/write-gate.js \
  resources/extensions/gsd/db-writer.js \
  resources/extensions/gsd/doctor.js \
  resources/extensions/gsd/gsd-db.js \
  resources/extensions/gsd/journal.js \
  resources/extensions/gsd/milestone-ids.js \
  resources/extensions/gsd/state.js \
  resources/extensions/gsd/tools/plan-task.js \
  resources/extensions/gsd/tools/workflow-tool-executors.js; do
  ln -sf "$BASE/dist/$f" "$BASE/src/$f"
done

Suggested fix

Change all importLocalModule() paths in packages/mcp-server/src/workflow-tools.ts from ../../../src/... to ../../../dist/..., or introduce a build-time path substitution that rewrites src/ to dist/ during compilation.

Environment

• gsd-pi: global install via npm
• Node: v22.22.0
• OS: Linux (WSL2)

[jeremymcs]

please run a /gsd forensics

are you on the latest version?

[iMokys]

Yes, on latest version — gsd-pi@2.70.0 (which is current on npm).

Ran /gsd forensics — here are the findings:

Forensic Report

Problem: MCP tool gsd_decision_save failed with "Cannot find module db-writer.js" during M013/S06 execution.

Anomaly 1: MCP Module Resolution Failure — HIGH confidence

packages/mcp-server/dist/workflow-tools.js contains 9 importLocalModule() calls using relative path ../../../src/resources/extensions/gsd/.... These resolve against import.meta.url (the file's own location in dist/) and point to src/ where only .ts source files exist, not compiled .js files.

Affected modules (all 9):

• bootstrap/write-gate.js
• db-writer.js
• doctor.js
• gsd-db.js
• journal.js
• milestone-ids.js
• state.js
• tools/plan-task.js
• tools/workflow-tool-executors.js

Impact: gsd_decision_save, milestone operations, state writes, journal writes, doctor, and plan-task tools are all broken. Auto-mode completed M013 successfully because the core plan/execute/verify workflow doesn't depend on these MCP tools — but any tool that writes to the GSD database or state via these modules fails silently.

Anomaly 2: Silent MCP Error Swallowing — MEDIUM confidence

The error appears nowhere in event-log.jsonl, doctor-history.jsonl, or journal files. MCP tool failures are lost at the transport layer, making post-mortem investigation harder.

Workaround applied

Symlinked all 8 dist/.../X.js → src/.../X.js to make the hardcoded paths resolve correctly.

Environment

• gsd-pi@2.70.0 (latest)
• Node: v22.22.0
• OS: Linux 5.15.146.1-microsoft-standard-WSL2

[iMokys]

Update: After upgrading to v2.70.1, the path issue is fixed (thanks!) but a second bug is now exposed.

New error

gsd-db: No database open

What's happening

The 2.70.1 fallback (src/ ↔ dist/ swap in _buildImportCandidates) successfully resolves the importLocalModule() call, so db-writer.js now loads. But the call fails inside the transaction because db._getAdapter() returns null — the database was never opened in the MCP server process.

Root cause

packages/mcp-server/dist/workflow-tools.js has two handler patterns:

Pattern A — Executor-path (works): Handlers like gsd_plan_milestone, gsd_complete_slice, gsd_summary_save delegate to workflow-tool-executors.js. Every executor correctly calls await ensureDbOpen(basePath) first. Example from workflow-tool-executors.js:

export async function executeSummarySave(params, basePath = process.cwd()) {
    const dbAvailable = await ensureDbOpen(basePath);
    if (!dbAvailable) { ... }
    // ... proceed with DB write
}

Pattern B — Inline (broken): Handlers that inline the DB write via importLocalModule() — these skip ensureDbOpen(). Example:

server.tool("gsd_save_requirement", ..., async (args) => {
  const { projectDir, ...params } = parsed;
  await enforceWorkflowWriteGate("gsd_requirement_save", projectDir);
  const result = await runSerializedWorkflowOperation(async () => {
    const { saveRequirementToDb } = await importLocalModule("../../../src/resources/extensions/gsd/db-writer.js");
    return saveRequirementToDb(params, projectDir);  // <-- DB never opened
  });
});

Affected inline handlers

• gsd_decision_save / gsd_save_decision
• gsd_requirement_save / gsd_save_requirement
• gsd_requirement_update
• gsd_milestone_generate_id
• gsd_plan_task / gsd_task_plan
• (possibly others — any handler that uses importLocalModule() for a DB-writing module)

Suggested fix

Each inline handler needs await ensureDbOpen(projectDir) before the DB call. Alternatively, consolidate all DB-writing handlers onto the executor pattern so there's no second path that can drift out of sync.

Reproduction

1. Install gsd-pi@2.70.1
2. Call mcp__gsd-workflow__gsd_save_requirement with valid params
3. Observe: gsd-db: No database open

Note

In 2.70.0, this failure mode was masked by the earlier "Cannot find module" error since db-writer.js never loaded. The 2.70.1 fallback uncovered it.