davinci-resolve-mcp 2.98.5 → 2.98.6

package/CHANGELOG.md

@@ -2,6 +2,69 @@
 
 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 v2.98.6
+
+**Correcting the scope of the v2.98.5 Fusion fix, and covering all six paths
+with a render.** v2.98.5 removed a `Comp.Lock()` from six Fusion value writes and
+described all six as the same bug. Only two of them were proven with a render at
+the time; the other four were changed by inference. Extending the live harness to
+cover the remaining four showed that inference was too broad.
+
+Every site was mutation-checked by reintroducing the lock and re-rendering on
+Studio 19.1.3.7:
+
+| call path | with the lock back |
+| --- | --- |
+| `set_input` | **PSNR inf — suppressed** |
+| `safe_set_inputs` | **PSNR inf — suppressed** |
+| `bulk_set_inputs` | unchanged, still rendered |
+| `bulk_set_expressions` | unchanged, still rendered |
+| `add_fusion_mask` | unchanged, still rendered |
+| `set_text_plus` | unchanged, still rendered |
+
+The two that break are the two where the locked write is the only thing the call
+does. The four that survive each do something else in the same call that appears
+to invalidate the graph anyway — `bulk_set_inputs` and `bulk_set_expressions`
+wrap the write in `StartUndo`/`EndUndo`, `add_fusion_mask` performs an `AddTool`,
+and `set_text_plus` writes a string rather than a number. **Which of those is the
+rescuing mechanism is not established** — only that the four do not reproduce.
+
+No code changed back. Removing the lock from a single write buys nothing and
+costs nothing, and treating the four as merely unexplained rather than proven
+safe is the conservative reading. What changed is the claim: `api_truth`,
+`docs/SKILL.md` and the AST guard's failure message now state the measured scope
+instead of "any value write".
+
+If you read the v2.98.5 notes and concluded every Fusion parameter this server
+ever wrote was ignored at render, that was overstated — it was true for
+`set_input` and `safe_set_inputs`.
+
+### Tests
+
+`tests/live_fusion_value_write_validation.py` grows from two cases to six,
+covering every site the fix touched:
+
+```
+set_input: PSNR 24.375987 -> APPLIED at render
+safe_set_inputs: PSNR 24.375987 -> APPLIED at render
+set_text_plus: PSNR 13.33844 -> APPLIED at render
+bulk_set_expressions: PSNR 24.375987 -> APPLIED at render
+bulk_set_inputs: PSNR 24.375987 -> APPLIED at render
+add_fusion_mask: PSNR 30.369794 -> APPLIED at render
+```
+
+The `set_text_plus` case builds a rooted `MediaIn -> Merge -> MediaOut` graph
+with the Text+ in the foreground — a comp whose MediaOut is fed only by a Text+
+is bypassed at render for an unrelated reason and would have failed for the
+wrong cause. The `add_fusion_mask` case cannot use a baseline/after comparison,
+because a default-sized mask still changes the render; it builds the same graph
+twice, once with a default mask and once with an explicitly tiny one, and
+requires the two renders to differ.
+
+Four of the six cases do not discriminate the lock. They are kept because they
+still prove the write reaches the render — the property that matters, and the
+one no readback can check.
+
 ## What's New in v2.98.5
 
 **Every Fusion parameter this server wrote was ignored at render.** A value

package/README.md

@@ -2,7 +2,7 @@
 
 English | [简体中文](README.zh-CN.md)
 
-[![Version](https://img.shields.io/badge/version-2.98.5-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-2.98.6-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-35%20(353%20full)-blue.svg)](#server-modes)

package/README.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](README.md) | 简体中文
 
-[![Version](https://img.shields.io/badge/version-2.98.5-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-2.98.6-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-35%20(353%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)
 
-> 本翻译对应 v2.98.5 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
+> 本翻译对应 v2.98.6 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
 
 一个 Model Context Protocol (MCP) 服务器，让 AI 助手通过官方脚本 API 控制 DaVinci Resolve Studio（达芬奇）。它提供完整的 API 覆盖，外加带护栏的工作流助手，涵盖剪辑、媒体池整理、渲染设置、审阅标记、调色、Fusion、Fairlight、项目生命周期任务、扩展开发，以及不碰源媒体的媒体分析。
 

package/docs/SKILL.md

@@ -1691,10 +1691,13 @@ Target a comp either from a timeline item (pass `clip_id`, `timeline_item_id`, o
 page comp (omit timeline scope).
 
 READBACK IS NOT PROOF FOR FUSION PARAMETERS. Up to v2.98.4 every value write
-here ran inside a `Comp.Lock()`, and a value written under a comp lock is stored
-in the graph and returned by `get_input` while the RENDER ignores it entirely
-(Studio 19.1.3.7: PSNR inf vs the no-comp baseline — the delivered file was
-bit-identical to no comp at all). Fixed in v2.98.5, and guarded by
+here ran inside a `Comp.Lock()`. For `set_input` and `safe_set_inputs` that was
+load-bearing: the value is stored in the graph and returned by `get_input` while
+the RENDER ignores it entirely (Studio 19.1.3.7: PSNR inf vs the no-comp
+baseline — the delivered file was bit-identical to no comp at all). The other
+four locked paths did not reproduce it, so the blast radius was narrower than
+first reported; the locks came off all six regardless. Fixed in v2.98.5
+(measurement corrected in v2.98.6), and guarded by
 `tests/test_fusion_value_write_lock.py` plus the rendered-frame harness
 `tests/live_fusion_value_write_validation.py`. The lesson outlives the bug: a
 Fusion parameter that reads back correctly has proven nothing about the output,

package/docs/reference/api-limitations.md

@@ -343,7 +343,7 @@ values, or automation-hostile modal prompts.
 
 - **Object:** `Composition (Fusion, via TimelineItem comps)`
 - **Signature:** `Lock() / Unlock()`
-- **Behavior:** A value write performed between Comp.Lock() and Comp.Unlock() — SetInput(), or Input.SetExpression() — is stored in the graph and reads back correctly from GetInput(), but is NOT applied when the timeline is rendered. Measured live on Studio 19.1.3.7 (2026-08-21) with MediaIn -> Blur(XBlurSize 20) -> MediaOut on a media-backed clip: written under the lock the delivered H.264 render is bit-identical to the no-comp baseline (ffmpeg PSNR inf); the identical write with the lock removed renders at PSNR 24.38 dB and the file shrinks 2.0 MB -> 727 KB, as a blur should. The variable was isolated against the comp handle (AddFusionComp, GetFusionCompByIndex and GetFusionCompByName all render), the node name, and the write form (attribute assignment and SetInput both render unlocked). STRUCTURAL edits are unaffected: AddTool and ConnectInput inside a lock render normally, so the lock is not broadly unsafe — it suppresses the parameter-change invalidation that a value write depends on. Lock() is widely recommended for batching Fusion edits, which is how this reaches production code.
+- **Behavior:** A numeric tool.SetInput() performed between Comp.Lock() and Comp.Unlock(), when that write is the only thing the call does, is stored in the graph and reads back correctly from GetInput() but is NOT applied when the timeline is rendered. Measured live on Studio 19.1.3.7 (2026-08-21) with MediaIn -> Blur(XBlurSize 20) -> MediaOut on a media-backed clip: written under the lock the delivered H.264 render is bit-identical to the no-comp baseline (ffmpeg PSNR inf); the identical write with the lock removed renders at PSNR 24.38 dB and the file shrinks 2.0 MB -> 727 KB, as a blur should. The variable was isolated against the comp handle (AddFusionComp, GetFusionCompByIndex and GetFusionCompByName all render), the node name, and the write form (attribute assignment and SetInput both render unlocked). STRUCTURAL edits are unaffected: AddTool and ConnectInput inside a lock render normally, so the lock is not broadly unsafe — it suppresses the parameter-change invalidation that a value write depends on. Lock() is widely recommended for batching Fusion edits, which is how this reaches production code. SCOPE, measured by reintroducing the lock at each site and re-rendering: it reproduces for a bare numeric SetInput (2 of 6 call paths tested) and does NOT reproduce when the same call also wraps the write in StartUndo/EndUndo, performs an AddTool, or writes a string to StyledText (4 of 6). Which of those rescues the write is not established — only that they do. Treat the safe cases as unexplained rather than proven safe, and keep value writes outside the lock everywhere.
 - **Workaround / current handling:** Never hold a comp lock across a value write. Lock only structural work (AddTool/ConnectInput) and set inputs outside it. Because every readback the API offers agrees with the value that was written, this failure is invisible without a render — prove Fusion parameter changes with a delivered frame or gallery_stills grab_and_export, never with GetInput.
 - **Tags:** fusion, silent-failure, render, readback
 

package/install.py

@@ -37,7 +37,7 @@ from src.utils.update_check import (
 
 # ─── Version ──────────────────────────────────────────────────────────────────
 
-VERSION = "2.98.5"
+VERSION = "2.98.6"
 # 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": "2.98.5",
+  "version": "2.98.6",
   "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 = "2.98.5"
+VERSION = "2.98.6"
 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 353-tool granular server instead
 """
 
-VERSION = "2.98.5"
+VERSION = "2.98.6"
 
 import base64
 import os

package/src/utils/api_truth.py

@@ -407,10 +407,10 @@ API_TRUTH: List[Dict[str, Any]] = [
         "symbol": "Composition.Lock (suppresses render invalidation for value writes)",
         "object": "Composition (Fusion, via TimelineItem comps)",
         "signature": "Lock() / Unlock()",
-        "reality": "A value write performed between Comp.Lock() and "
-                   "Comp.Unlock() — SetInput(), or Input.SetExpression() — is "
-                   "stored in the graph and reads back correctly from "
-                   "GetInput(), but is NOT applied when the timeline is "
+        "reality": "A numeric tool.SetInput() performed between Comp.Lock() "
+                   "and Comp.Unlock(), when that write is the only thing the "
+                   "call does, is stored in the graph and reads back correctly "
+                   "from GetInput() but is NOT applied when the timeline is "
                    "rendered. Measured live on Studio 19.1.3.7 (2026-08-21) "
                    "with MediaIn -> Blur(XBlurSize 20) -> MediaOut on a "
                    "media-backed clip: written under the lock the delivered "
@@ -427,7 +427,15 @@ API_TRUTH: List[Dict[str, Any]] = [
                    "suppresses the parameter-change invalidation that a value "
                    "write depends on. Lock() is widely recommended for "
                    "batching Fusion edits, which is how this reaches "
-                   "production code.",
+                   "production code. SCOPE, measured by reintroducing the lock "
+                   "at each site and re-rendering: it reproduces for a bare "
+                   "numeric SetInput (2 of 6 call paths tested) and does NOT "
+                   "reproduce when the same call also wraps the write in "
+                   "StartUndo/EndUndo, performs an AddTool, or writes a string "
+                   "to StyledText (4 of 6). Which of those rescues the write is "
+                   "not established — only that they do. Treat the safe cases as "
+                   "unexplained rather than proven safe, and keep value writes "
+                   "outside the lock everywhere.",
         "recommended": "Never hold a comp lock across a value write. Lock only "
                        "structural work (AddTool/ConnectInput) and set inputs "
                        "outside it. Because every readback the API offers "