Skip to content

release(mcp-v0.7.4): bump fsb-mcp-server - #4

Merged
LakshmanTurlapati merged 2 commits into
mainfrom
mcp-release-0.7.4
May 2, 2026
Merged

release(mcp-v0.7.4): bump fsb-mcp-server#4
LakshmanTurlapati merged 2 commits into
mainfrom
mcp-release-0.7.4

Conversation

@LakshmanTurlapati

Copy link
Copy Markdown
Collaborator

Summary

Cuts mcp-v0.7.4 for changes since mcp-v0.7.3:

  • bcd4735 reorder tool list / refresh annotations (visual-session first, execute_js power-tool)
  • 2f755bc 21-platform MCP installer + Phase 214 regression closure
  • 9f31ed0 background-agents sunset (block-comment agents/*, gate registerAgentTools)
  • 5f7da1a guardrails preferring manual tools over run_task autopilot

Test plan

  • CI all-green on this PR
  • After merge, push tag `mcp-v0.7.4` → npm-publish.yml publishes to npm + creates GitHub release

🤖 Generated with Claude Code

LakshmanTurlapati and others added 2 commits May 1, 2026 23:32
Cuts a release for changes accumulated since mcp-v0.7.3:
- bcd4735 reorder tool list, refresh annotations
- 2f755bc 21-platform MCP installer + Phase 214 regression closure
- 9f31ed0 block-comment agents/* modules; gate registerAgentTools no-op
- 5f7da1a guardrails preferring manual tools over run_task autopilot

Bumps version in package.json, package-lock.json, server.json, and
src/version.ts; rebuilds build/version.*. Tag mcp-v0.7.4 after merge
to trigger npm-publish.yml.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Locks the parity target to the new release version so package.json,
server.json, src/version.ts, and the help/install CLI output all match.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@LakshmanTurlapati
LakshmanTurlapati merged commit 574fbf5 into main May 2, 2026
8 checks passed
@LakshmanTurlapati
LakshmanTurlapati deleted the mcp-release-0.7.4 branch May 2, 2026 04:39
LakshmanTurlapati pushed a commit that referenced this pull request May 14, 2026
…ntent re-arm (hypotheses #2 + #4)

- extension/ws/ws-client.js:
  - Add module-level `_pendingStreamStart` queue + 200ms/5s constants
    (FSB_CONTENT_READY_POLL_INTERVAL_MS, FSB_CONTENT_READY_TIMEOUT_MS).
  - New `_waitForContentScriptReady(tabId, timeoutMs)` polls
    chrome.tabs.sendMessage({ action: 'pingDomStream' }) at 200ms cadence
    until the content-script dom-stream module responds { ready: true },
    or 5s deadline elapses. Replaces the arbitrary setTimeout(300) guess.
  - New `_onDomStreamReady(senderTabId)` re-arms a parked dash:dom-stream-start
    payload from the background.js domStreamReady handler.
  - `_handleDashboardStreamStart`: probe readiness before issuing
    domStreamStart. On timeout, park the payload in `_pendingStreamStart`
    for re-arm. On readiness, clear any prior parked intent so a late
    ready ping does not double-fire.
  - `_forwardToContentScript` reinjection branch: replace the
    `setTimeout(r, 300)` heuristic with `_waitForContentScriptReady`. On
    timeout, record dom-forward-failed with readyState=ping-timeout-after-inject
    instead of issuing a stale sendMessage.

- extension/content/dom-stream.js: add `case 'pingDomStream'` in the
  chrome.runtime.onMessage listener. Responds synchronously with
  { ready: true } once the dom-stream module has installed its listener
  (i.e. the IIFE has executed past the addListener call).

- extension/background.js `case 'domStreamReady':` after the existing
  fsbWebSocket.send('ext:dom-ready', ...) call, invoke `_onDomStreamReady`
  inside a try/catch (non-blocking). Re-arms any parked stream-start
  intent when the dom-stream module signals load-complete.

- tests/dashboard-stream-readiness-ping.test.js: static invariants on the
  pingDomStream case + _waitForContentScriptReady function shape + the
  300ms heuristic removal, PLUS three behavioural simulations against a
  stubbed chrome.tabs.sendMessage:
    * sim A: ready on 3rd poll -> resolves true at ~150ms
    * sim B: never ready -> resolves false at the 300ms test budget
    * sim C: immediate ready -> resolves true under 100ms
  16/16 PASS.

- tests/dashboard-stream-pending-intent.test.js: static invariants on the
  _pendingStreamStart + _onDomStreamReady wiring (parking, clearing,
  re-dispatch, idempotency) + a behavioural simulation that parks an
  intent, fires ready, asserts exactly one re-dispatch with the original
  payload, then fires ready again and asserts no double-fire. 14/14 PASS.

Defensive patch chain; harmless even if hypotheses #2 and #4 are not the
actual root cause -- the readiness ping always succeeds on the happy path
and the pending-intent flag is null on the happy path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant