ruvnet/ruflo · error

detectDestructive not available in JS fallback; use Enforcem

Error message

detectDestructive not available in JS fallback; use EnforcementGates

What it means

The JS fallback kernel's detectDestructive() stub throws because destructive-command detection is delegated to the EnforcementGates class in pure-JS environments instead of being duplicated in the fallback. The message tells you the supported alternative; you hit the stub only when the WASM kernel could not be loaded.

Source

Thrown at v3/@claude-flow/guidance/src/wasm-kernel.ts:179

      available: false,
      version: 'js-fallback',

      sha256: jsSha256,
      hmacSha256: jsHmacSha256,
      contentHash: jsContentHash,
      signEnvelope: jsHmacSha256,
      verifyChain: () => {
        // Chain verification requires full envelope parsing — not implemented
        // in JS fallback because the ProofChain class already does it.
        throw new Error('verifyChain not available in JS fallback; use ProofChain.verifyChain()');
      },

      scanSecrets: (): string[] => {
        // Gate scanning in JS fallback defers to EnforcementGates class
        throw new Error('scanSecrets not available in JS fallback; use EnforcementGates');
      },
      detectDestructive: (): string | null => {
        throw new Error('detectDestructive not available in JS fallback; use EnforcementGates');
      },

      batchProcess: (): BatchResult[] => {
        throw new Error('batchProcess requires WASM kernel');
      },
    };
  }

  return kernelInstance;
}

/**
 * Check if the WASM kernel is available without initializing it.
 */
export function isWasmAvailable(): boolean {
  return getKernel().available;
}

View on GitHub (pinned to fa13ee4ad6)

Solutions

1. Use EnforcementGates' destructive-command detection for the pure-JS path
2. Gate the call behind isWasmAvailable() so the code picks the right implementation per environment
3. Fix WASM availability (bundle the .wasm asset, relax CSP/runtime restrictions) to keep the accelerated path

Example fix

// before
const finding = getKernel().detectDestructive(cmd); // throws in JS fallback

// after
const finding = isWasmAvailable()
  ? getKernel().detectDestructive(cmd)
  : enforcementGates.detectDestructive(cmd); // JS implementation

function detectDestructiveAnywhere(cmd: string, gates: EnforcementGates): string | null {
  return isWasmAvailable()
    ? getKernel().detectDestructive(cmd)
    : gates.detectDestructive(cmd); // JS path
}

function hasWasmKernel(k: WasmKernel): k is WasmKernel & { available: true } {
  return k.available === true;
}

try {
  finding = kernel.detectDestructive(cmd);
} catch (e) {
  if (e instanceof Error && e.message.includes('JS fallback')) {
    finding = gates.detectDestructive(cmd);
  } else {
    throw e;
  }
}

When it happens

Trigger: Calling getKernel().detectDestructive(command) while running on the JS fallback — i.e. tryLoadWasm() failed (asset missing, runtime without WebAssembly, CSP blocking instantiation).

Common situations: CI environments or edge runtimes that lack WASM; bundling pipelines that omit the .wasm file; hardened environments where WebAssembly is disabled by policy.

Related errors

• verifyChain not available in JS fallback; use ProofChain.ver
• scanSecrets not available in JS fallback; use EnforcementGat
• batchProcess requires WASM kernel
• Failed to load WASM module
• MCP initialization failed: ${initResponse.error.message}

AI-assisted analysis of ruvnet/ruflo@fa13ee4ad6 (2026-08-18). Data as JSON: /api/errors/548df9ceb5ed7275. Report an issue: GitHub.