davinci-resolve-mcp 4.1.0 → 4.1.2

package/CHANGELOG.md

@@ -2,6 +2,103 @@
 
 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.1.2 — the installer's healthy-branch test stops depending on a live Resolve
+
+Test-only. No behaviour change to the server or the installer.
+
+### Fixed
+
+- **`SetupExitStatusTests.test_a_working_install_still_reports_ready_and_exits_zero`
+  failed roughly once per full-suite run** while passing in isolation and on an
+  immediate re-run. It was not the shared-state bug class this repo has seen
+  before: it asserted the healthy branch by running the **real** probe, which
+  spawns a subprocess asking a live GUI application to answer over IPC within
+  10 seconds and returns `False, "Connection timed out"` if it does not.
+  Resolve can be mid-launch, showing a modal, loading a project, or simply slow
+  while the rest of the suite saturates the machine — none of which is a defect
+  in the installer, which is the only thing the test exists to catch.
+
+  What it actually guards — *a successful verification must print
+  `Environment ready!` and return 0* — is a property of `main()`'s reporting,
+  not of the host. It is now asserted against a **pinned** verification result,
+  so it is deterministic and runs everywhere, including on CI with no Resolve
+  installed. Its mirror (*a stated failure is never reported ready*) is pinned
+  the same way.
+
+- **The live probe is still exercised, as an integration check**, by
+  `test_the_live_probe_agrees_with_the_summary`. It asserts the summary and
+  exit status **agree with whatever the probe said** — and skips, naming the
+  probe's own message, when the probe did not answer. It is not an assertion
+  that the probe succeeds, because that is not something a unit suite can
+  guarantee. A probe that answers and a summary that contradicts it still
+  fails, which is the regression that matters.
+
+- **The skip gate admitted machines the test could not pass.**
+  `_resolve_is_installed()` checked only for a `fusionscript` library, but
+  `main()` sets `verification_failed` when `api_path` is falsy — printing
+  `Skipped — Resolve API path not detected` — *before* the probe runs. On a
+  machine with the app installed but no `Developer/Scripting` directory (Studio's
+  installer can omit that component; on Linux it may sit outside the defaults),
+  the test therefore failed **deterministically**, for a reason unrelated to
+  what it pins. The gate now requires both halves, and it expands `{user}` the
+  way `find_resolve_paths()` does.
+
+### Guards
+
+- Every reporting test in `SetupExitStatusTests` is re-run with
+  `verify_resolve_connection` booby-trapped to raise, so any test that reaches
+  a live Resolve — by dropping its pin, by letting discovery find the host's
+  install, or by being added without one — fails at authoring time instead of
+  once a fortnight in someone's suite run. Exactly one test is exempt, named in
+  `LIVE_TEST`.
+- The ready assertion is re-asserted against a dead `RESOLVE_PATHS`, pinning
+  that the summary follows the verification result rather than the machine.
+- A pinned verification is asserted to actually replace the probe rather than
+  shadow it, so pinning the wrong symbol cannot quietly reacquire the flake.
+- The gate is asserted to reject a library with no API directory beside it.
+
+All four fail when the defect they pin is reintroduced.
+
+## What's New in v4.1.1 — drift detection stops comparing two different timelines
+
+Reported by @V2arK (#224), with the root cause correctly diagnosed in the report.
+
+### Fixed
+
+- **`project_manager.load` emitted a drift warning for an edit that never
+  happened.** `DriftDetectionHook` compared `pre_state["duration_frames"]`
+  against the post-state's with no check that the two described the same
+  timeline — and `load` is not in `_DURATION_ALTERING_ACTIONS`, so a project
+  switch took the "unexpected drift" branch by construction. Switching from a
+  120-frame timeline in one project to a 17854-frame timeline in another
+  reported a drift of 17734 frames during an action that edited nothing.
+
+  This is the failure the verification layer exists to prevent, occurring
+  inside the verification layer: an agent reading the envelope was told an edit
+  had corrupted a timeline when no edit had occurred, and the README is
+  explicit that a confident wrong answer is worse than no answer.
+
+- **The check is now on identity, not on an action allow-list.** The hook skips
+  the comparison when `project_name` or `timeline_name` moved between pre- and
+  post-state — both of which the state provider already reported and the hook
+  simply ignored. Identity was chosen over adding `load` to a list because the
+  set of actions that can replace the current timeline is open-ended (`load`,
+  `create`, `set_current`, anything that closes a project) while the question —
+  does the baseline still refer to what we measured? — is the same for all of
+  them. The reporter suggested both directions; this is the more general one.
+
+- **The reset is reported, not silently omitted.** The hook returns
+  `drift_detected: false` with `baseline_reset: true`, the key that moved, and
+  a notice, rather than returning nothing. No drift record is indistinguishable
+  from "not checked"; this says the check ran and the baseline stopped
+  applying.
+
+  The case the hook exists for is unaffected: same project, same timeline,
+  duration moved under a non-duration-altering action still reports drift, and
+  a state with no identity keys at all still compares durations rather than
+  silently disabling itself. All three are covered by tests, and the two new
+  ones fail without the change.
+
 ## What's New in v4.1.0 — `timeline_markers add` can be previewed, and "false" stops meaning true
 
 Contributed by @Rohitkanithi (#218), adapted onto v4.0.0.

package/README.md

@@ -2,7 +2,7 @@
 
 English | [简体中文](README.zh-CN.md)
 
-[![Version](https://img.shields.io/badge/version-4.1.0-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-4.1.2-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(387%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.1.0-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-4.1.2-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(387%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.1.0 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
+> 本翻译对应 v4.1.2 版 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.1.0"
+VERSION = "4.1.2"
 # 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.1.0",
+  "version": "4.1.2",
   "description": "NPM bootstrapper for the DaVinci Resolve MCP Server.",
   "license": "MIT",
   "author": "Samuel Gursky <samgursky@gmail.com>",

package/src/granular/common.py

@@ -87,7 +87,7 @@ if not logging.getLogger().handlers:
         handlers=[logging.StreamHandler()],
     )
 
-VERSION = "4.1.0"
+VERSION = "4.1.2"
 logger = logging.getLogger("davinci-resolve-mcp")
 logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION}")
 logger.info(f"Detected platform: {get_platform()}")

package/src/server.py

@@ -11,7 +11,7 @@ Usage:
     python src/server.py --full       # Start the 377-tool granular server instead
 """
 
-VERSION = "4.1.0"
+VERSION = "4.1.2"
 
 import base64
 import os

package/src/utils/execution_lifecycle.py

@@ -541,9 +541,44 @@ class DriftDetectionHook(LifecycleHook):
         "delete_clips", "cut_clip", "delete_item", "ripple_trim"
     }
 
+    #: Identity keys that make a duration comparable. If either of these moved,
+    #: the two durations describe different timelines and their difference is
+    #: not drift.
+    _IDENTITY_KEYS = ("project_name", "timeline_name")
+
     def __init__(self, state_provider: Optional[Callable[[], Optional[Dict[str, Any]]]] = None):
         self._state_provider = state_provider
 
+    @classmethod
+    def _baseline_identity_changed(
+        cls, pre_state: Dict[str, Any], post_state: Dict[str, Any]
+    ) -> Optional[str]:
+        """Name the identity key that moved, or None if the baseline still holds.
+
+        A duration delta only means drift when both numbers describe the same
+        timeline. Actions that *replace* the current timeline rather than modify
+        it -- `project_manager.load` most obviously -- leave a pre-state
+        measuring one project's timeline and a post-state measuring another's.
+        Comparing them reports a large unexpected drift for a call during which
+        nothing was edited at all.
+
+        That is the failure this layer exists to prevent, occurring inside the
+        layer itself: the README is explicit that a confident wrong answer is
+        worse than no answer, and an agent reading the envelope is told an edit
+        corrupted a timeline when no edit happened.
+
+        Identity is checked rather than the action being allow-listed, because
+        the set of actions that can swap the current timeline is open-ended
+        (`load`, `create`, `set_current`, anything that closes a project) while
+        the question -- does the baseline still refer to the thing we measured?
+        -- is the same for all of them.
+        """
+        for key in cls._IDENTITY_KEYS:
+            before, after = pre_state.get(key), post_state.get(key)
+            if before is not None and after is not None and before != after:
+                return key
+        return None
+
     def after_tool_call(
         self, ctx: ToolCallContext, result: Any, duration_ms: int
     ) -> Optional[Dict[str, Any]]:
@@ -556,6 +591,23 @@ class DriftDetectionHook(LifecycleHook):
                 return None
             ctx.post_state = post_state
 
+            moved = self._baseline_identity_changed(ctx.pre_state, post_state)
+            if moved:
+                # Say so explicitly rather than returning None. "No drift
+                # record" is indistinguishable from "not checked"; this reports
+                # that the check ran and the baseline stopped applying.
+                return {
+                    "drift_detected": False,
+                    "baseline_reset": True,
+                    "reset_on": moved,
+                    "notice": (
+                        f"Drift not evaluated: {moved} changed from "
+                        f"{ctx.pre_state.get(moved)!r} to {post_state.get(moved)!r} "
+                        f"during '{ctx.action}', so the pre-state duration is no "
+                        "longer a baseline for the post-state duration."
+                    ),
+                }
+
             pre_dur = ctx.pre_state.get("duration_frames")
             post_dur = post_state.get("duration_frames")