davinci-resolve-mcp 4.8.4 → 4.8.5

package/CHANGELOG.md

@@ -2,6 +2,90 @@
 
 Release history for the DaVinci Resolve MCP Server. The latest release is summarized in the root README; older entries live here to keep the README focused.
 
+## What's New in v4.8.5 — the offline suite no longer reaches Resolve through the granular server
+
+No tool or action changed. One runtime change outside the tests: importing
+`src.granular` no longer connects to Resolve, and the granular launchers now
+connect explicitly at startup instead.
+
+### Fixed
+
+- **With Resolve open, the offline suite connected to it through the granular server.**
+  `src/granular/common.py` ran `import DaVinciResolveScript` and `connect_resolve()`
+  at import time, so any test that imported a granular module called
+  `scriptapp("Resolve")` on the real `fusionscript.so`. `tests/offline_guard.py`
+  swapped `_launch_resolve`, `get_resolve` and `resolve_is_running` on `src.server`
+  only. The granular `get_resolve()` still fell through to its own `_launch_resolve()`.
+  Whether the real module loaded at all came down to import order, because the test
+  modules that `sys.modules.setdefault()` a stub only win when they run first.
+  `tests/test_live_api.py`, which pytest collects, calls `scriptapp` whenever the
+  real module wins. The compound server leaked the same way: the execution-lifecycle
+  state provider calls `src.server._try_connect()` directly before tool calls, and
+  the guard never swapped that function. Measured with a full
+  `python -m unittest discover -s tests -t .` run of v4.8.4, with a tripwire
+  standing in for the native library. The test process called `scriptapp("Resolve")`
+  1,165 times, 1,162 of them from `_get_resolve_lifecycle_state`. It also tried
+  once to `open` the application, through the granular `ResolveProxy` →
+  `get_resolve()` → `_launch_resolve()`. The same run on this release makes
+  neither call.
+  - Before it imports `src.server`, the guard installs a `sys.meta_path` finder that
+    answers `DaVinciResolveScript` and `fusionscript` with an empty stub. It is a
+    finder rather than a `sys.modules` entry, so a test that pops the module cannot
+    let the next import reach the real library. The stub has no `scriptapp`, so
+    `connect_resolve()` raises before its bridge fallback instead of falling
+    through to it.
+  - `_try_connect`, `_launch_resolve` and `get_resolve` in `src.granular.common`
+    are swapped the same way as the compound server's. The swap covers every
+    granular module that holds one: `src/granular/__init__.py` imports each tool
+    module, and each binds its own copy through `from src.granular.common import *`
+    before the guard can swap `common`. The originals stay reachable as
+    `_*_unpatched`.
+  - For the duration of the run, the in-app bridge client points at a config file
+    that does not exist. `DAVINCI_RESOLVE_BRIDGE=1` in a developer's shell therefore
+    cannot open a socket to a bridge running inside Resolve.
+
+### Changed
+
+- **`src/granular/common.py` no longer connects at import.** It still imports
+  DaVinciResolveScript, with the same diagnostics when that fails. The connection
+  moved to `connect_at_startup()`, which `src/resolve_mcp_server.py` and
+  `src/server.py --full` call right after importing the package. Starting the
+  granular server behaves as before: it connects to a Resolve that is already
+  open, logs it, and never launches one. Launching stays with `get_resolve()` on
+  the first tool call. Code that only imports the package no longer talks to
+  Resolve.
+
+### Validation
+
+- New `tests/test_offline_guard_granular.py` puts a module shaped like Blackmagic's
+  loader first on `sys.path` and checks that a path import would load it. It then
+  asserts that neither a fresh import of `src.granular.common` nor
+  `connect_at_startup()` ever executes that module. It also pins the stand-ins in
+  every granular module, the stub's missing `scriptapp`, and the bridge redirect.
+  With the finder disabled it fails with
+  `['imported DaVinciResolveScript', "scriptapp ('Resolve',)"]`.
+  `tests/test_0000_offline_bootstrap.py` now also asserts that the finder is in
+  place before `src.server` imports.
+- Full suite, `python -m unittest discover -s tests -t .`: 3,749 tests. The
+  errors are the same 11 as on v4.8.4 in this environment (no `numpy` or
+  `requests` in the venv, plus `test_offline_fallback` and
+  `test_lut_file_controls`). pytest was not run locally.
+- Not covered: the control-panel tests (`test_control_panel_ipv6_loopback` and
+  one in `test_open_control_panel`) start the real `src/analysis_dashboard.py`
+  as a child process. An in-process guard cannot reach a child, and the child
+  still calls `scriptapp("Resolve")` read-only: 5 calls from 3 children in the
+  run above, the same as on v4.8.4.
+- **Live-validated** on Resolve Studio 21.1.0.14, with Resolve already open. Both
+  launchers log `Connected to DaVinci Resolve: DaVinci Resolve Studio 21.1.0.14` at
+  startup, and neither started anything:
+  - `src/resolve_mcp_server.py` logs it before `Starting DaVinci Resolve MCP Server
+    v4.8.5 (389 granular tools)`, where the import-time connect used to log it.
+  - `src/server.py --full` logs it right after the granular import, before
+    `Threaded tool dispatch installed for 389 tools`.
+- Not measured: startup with Resolve closed. That path logs `Failed to get Resolve
+  object` and leaves launching to the first tool call. The offline suite was never
+  run against the live Resolve.
+
 ## What's New in v4.8.4 — a Fusion nest control is refused with the controls it folds named
 
 ### Fixed

package/README.md

@@ -2,7 +2,7 @@
 
 English | [简体中文](README.zh-CN.md)
 
-[![Version](https://img.shields.io/badge/version-4.8.4-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-4.8.5-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
 [![npm](https://img.shields.io/npm/v/davinci-resolve-mcp.svg?label=npm&color=CB3837)](https://www.npmjs.com/package/davinci-resolve-mcp)
 [![API Coverage](https://img.shields.io/badge/API%20Coverage-100%25-brightgreen.svg)](docs/reference/api-coverage.md)
 [![Tools](https://img.shields.io/badge/MCP%20Tools-37%20(389%20full)-blue.svg)](#server-modes)

package/README.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](README.md) | 简体中文
 
-[![Version](https://img.shields.io/badge/version-4.8.4-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-4.8.5-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
 [![npm](https://img.shields.io/npm/v/davinci-resolve-mcp.svg?label=npm&color=CB3837)](https://www.npmjs.com/package/davinci-resolve-mcp)
 [![API Coverage](https://img.shields.io/badge/API%20Coverage-100%25-brightgreen.svg)](docs/reference/api-coverage.md)
 [![Tools](https://img.shields.io/badge/MCP%20Tools-37%20(389%20full)-blue.svg)](#服务器模式)
@@ -12,7 +12,7 @@
 [![Python](https://img.shields.io/badge/python-3.10+-green.svg)](https://www.python.org/downloads/)
 [![License](https://img.shields.io/badge/license-MIT-blue.svg)](https://opensource.org/licenses/MIT)
 
-> 本翻译对应 v4.8.4 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
+> 本翻译对应 v4.8.5 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
 
 一个 Model Context Protocol (MCP) 服务器，让 AI 助手通过官方脚本 API 控制 DaVinci Resolve Studio（达芬奇）。它提供完整的 API 覆盖，外加带护栏的工作流助手，涵盖剪辑、媒体池整理、渲染设置、审阅标记、调色、Fusion、Fairlight、项目生命周期任务、扩展开发，以及不碰源媒体的媒体分析。
 

package/install.py

@@ -37,7 +37,7 @@ from src.utils.update_check import (
 
 # ─── Version ──────────────────────────────────────────────────────────────────
 
-VERSION = "4.8.4"
+VERSION = "4.8.5"
 # Only hard floor: mcp[cli] requires Python 3.10+. There is no upper bound —
 # Resolve's scripting bridge loads into newer interpreters on recent builds
 # (Python 3.14 verified against Resolve Studio 20.3.2). Older Resolve builds

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "davinci-resolve-mcp",
-  "version": "4.8.4",
+  "version": "4.8.5",
   "description": "NPM bootstrapper for the DaVinci Resolve MCP Server.",
   "license": "MIT",
   "author": "Samuel Gursky <samgursky@gmail.com>",

package/src/granular/common.py

@@ -93,7 +93,7 @@ if not logging.getLogger().handlers:
         handlers=[logging.StreamHandler()],
     )
 
-VERSION = "4.8.4"
+VERSION = "4.8.5"
 logger = logging.getLogger("davinci-resolve-mcp")
 logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION}")
 logger.info(f"Detected platform: {get_platform()}")
@@ -297,16 +297,13 @@ _OPTIONAL_DEPENDENCY_CONTRACT = (
     "DaVinciResolveScript: always routed through connect_resolve(), which is None-tolerant"
 )
 
+# Loading the module is not connecting. `scriptapp` is what reaches a running
+# Resolve, and it waits for `connect_at_startup()` or the first `get_resolve()`.
+# Connecting here made *importing* this module talk to whatever Resolve was
+# open, including from the offline test suite, where any `import src.granular.*`
+# connected before a single test could stop it.
 try:
     import DaVinciResolveScript as dvr_script  # type: ignore
-
-    resolve = connect_resolve(dvr_script)
-    if resolve:
-        logger.info(
-            f"Connected to DaVinci Resolve: {resolve.GetProductName()} {resolve.GetVersionString()}"
-        )
-    else:
-        logger.error("Failed to get Resolve object. Is DaVinci Resolve running?")
 except ImportError as exc:
     logger.error(f"Failed to import DaVinciResolveScript: {exc}")
     logger.error("Check that DaVinci Resolve is installed and running.")
@@ -314,10 +311,38 @@ except ImportError as exc:
     logger.error(f"RESOLVE_SCRIPT_LIB: {RESOLVE_LIB_PATH}")
     logger.error(f"RESOLVE_MODULES_PATH: {RESOLVE_MODULES_PATH}")
     logger.error(f"sys.path: {sys.path}")
-    resolve = None
+    dvr_script = None
 except Exception as exc:
     logger.error(f"Unexpected error initializing Resolve: {exc}")
-    resolve = None
+    dvr_script = None
+
+
+def connect_at_startup():
+    """Connect to a running Resolve as the granular server starts, and log it.
+
+    This is the connection that used to run at import. The launchers
+    (`src/resolve_mcp_server.py` and `src/server.py --full`) call it right after
+    importing the package, so starting the server behaves as before: it
+    connects to a Resolve that is already open and never launches one. Launching
+    is still left to `get_resolve()` on the first tool call. A missing
+    DaVinciResolveScript was already reported above and skips the attempt, as
+    the import failure did before.
+    """
+    global resolve
+    if dvr_script is None:
+        return None
+    try:
+        resolve = connect_resolve(dvr_script)
+        if resolve:
+            logger.info(
+                f"Connected to DaVinci Resolve: {resolve.GetProductName()} {resolve.GetVersionString()}"
+            )
+        else:
+            logger.error("Failed to get Resolve object. Is DaVinci Resolve running?")
+    except Exception as exc:
+        logger.error(f"Unexpected error initializing Resolve: {exc}")
+        resolve = None
+    return resolve
 
 
 def _normalize_cdl(cdl):

package/src/resolve_mcp_server.py

@@ -26,13 +26,14 @@ if modules_path and modules_path not in sys.path:
     sys.path.append(modules_path)
 
 from src.granular import VERSION, mcp
-from src.granular.common import logger
+from src.granular.common import connect_at_startup, logger
 from src.utils.mcp_stdio import run_fastmcp_stdio
 from src.utils.update_check import start_background_update_check
 
 
 if __name__ == "__main__":
     try:
+        connect_at_startup()
         start_background_update_check(VERSION, project_dir, logger)
         logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION} (389 granular tools)")
         run_fastmcp_stdio(mcp)

package/src/server.py

@@ -11,7 +11,7 @@ Usage:
     python src/server.py --full       # Start the 377-tool granular server instead
 """
 
-VERSION = "4.8.4"
+VERSION = "4.8.5"
 
 import base64
 import os
@@ -33130,7 +33130,9 @@ if __name__ == "__main__":
         logger.info("Starting full 377-tool granular server...")
         sys.argv = [arg for arg in sys.argv if arg != "--full"]
         from src.granular import mcp as granular_mcp
+        from src.granular.common import connect_at_startup
 
+        connect_at_startup()
         _install_threaded_tool_dispatch(granular_mcp)
         run_fastmcp_stdio(granular_mcp)
         sys.exit(0)