davinci-resolve-mcp 2.24.0 → 2.24.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +13 -4
- package/README.md +6 -1
- package/bin/davinci-resolve-mcp.mjs +4 -1
- package/docs/guides/control-panel.md +128 -0
- package/install.py +1 -1
- package/package.json +1 -1
- package/src/granular/common.py +1 -1
- package/src/server.py +5 -5
- package/src/utils/analysis_memory.py +1 -1
- package/src/utils/media_analysis.py +1 -1
- package/docs/design/control-panel-polish-gameplan.md +0 -238
- package/docs/design/v2-control-panel-design.md +0 -184
- package/docs/design/v2-implementation-gameplan.md +0 -593
- package/docs/design/v2-shot-schema-spec.md +0 -500
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,18 @@
|
|
|
2
2
|
|
|
3
3
|
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.
|
|
4
4
|
|
|
5
|
+
## What's New in v2.24.1
|
|
6
|
+
|
|
7
|
+
**`npx davinci-resolve-mcp` no longer breaks MCP clients when invoked without a
|
|
8
|
+
subcommand.** The npm bootstrapper previously defaulted to `--help`, which wrote
|
|
9
|
+
usage text to stdout and exited 0. MCP stdio clients (Hermes Agent, Claude
|
|
10
|
+
Desktop, Cursor, etc.) read that as malformed JSON-RPC, retried three times,
|
|
11
|
+
then dropped the connection. `bin/davinci-resolve-mcp.mjs` now defaults to the
|
|
12
|
+
`server` subcommand when no arguments are supplied. Explicit `--help`, `-h`,
|
|
13
|
+
`help`, `--version`, and `-v` continue to print to stdout as before, and
|
|
14
|
+
existing configs that already pass `server` explicitly are unaffected. Reported
|
|
15
|
+
in [#41](https://github.com/samuelgursky/davinci-resolve-mcp/issues/41).
|
|
16
|
+
|
|
5
17
|
## What's New in v2.24.0
|
|
6
18
|
|
|
7
19
|
**Host-chat vision protocol (V2)** — `analyze_*` actions now use
|
|
@@ -88,10 +100,7 @@ ffprobe/ffmpeg resolve even when the MCP server is launched by a GUI app
|
|
|
88
100
|
Mandatory" section. `docs/SKILL.md` rewrites the `analyze_media` prompt
|
|
89
101
|
guidance for the host-chat-paths protocol and adds the anti-regression rule.
|
|
90
102
|
`docs/guides/media-analysis-guide.md` covers the deferred vision payload and
|
|
91
|
-
commit step.
|
|
92
|
-
`v2-control-panel-design.md`, `v2-db-schema.sql`,
|
|
93
|
-
`v2-implementation-gameplan.md`, `v2-shot-schema-spec.md`,
|
|
94
|
-
`control-panel-polish-gameplan.md`.
|
|
103
|
+
commit step.
|
|
95
104
|
|
|
96
105
|
**Validation**: static import checks, API parity audit, focused
|
|
97
106
|
media-analysis + marker/range/v232/v233 unit tests, npm CLI smoke,
|
package/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# DaVinci Resolve MCP Server
|
|
2
2
|
|
|
3
|
-
[](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
|
|
4
4
|
[](https://www.npmjs.com/package/davinci-resolve-mcp)
|
|
5
5
|
[](docs/reference/api-coverage.md)
|
|
6
6
|
[-blue.svg)](#server-modes)
|
|
@@ -11,6 +11,10 @@
|
|
|
11
11
|
|
|
12
12
|
A Model Context Protocol (MCP) server that lets AI assistants control DaVinci Resolve Studio through the official Scripting API. It provides full API coverage plus guarded workflow helpers for editing, media pool organization, render setup, review markers, grading, Fusion, Fairlight, project lifecycle tasks, extension authoring, and source-safe media analysis.
|
|
13
13
|
|
|
14
|
+
[](docs/guides/control-panel.md)
|
|
15
|
+
|
|
16
|
+
A local browser control panel ships with the server for inspecting Resolve state, running source-safe analysis, drilling into analyzed clips and shots, and editing analysis output inline. See the [Control Panel Guide](docs/guides/control-panel.md) for the full tour.
|
|
17
|
+
|
|
14
18
|
## Quick Start
|
|
15
19
|
|
|
16
20
|
```bash
|
|
@@ -114,6 +118,7 @@ For method-by-method status, see [API Coverage and Test Results](docs/reference/
|
|
|
114
118
|
| [API Coverage and Test Results](docs/reference/api-coverage.md) | Key stats, API coverage table, live-test status, full method reference |
|
|
115
119
|
| [Kernel Action Coverage](docs/kernels/README.md) | Current guarded workflow action map |
|
|
116
120
|
| [AI Skill Reference](docs/SKILL.md) | Operational context for AI assistants using the compound server |
|
|
121
|
+
| [Control Panel Guide](docs/guides/control-panel.md) | Local browser panel tour: Overview, Review (bin/clip/shot), Analyze, Setup, Preferences |
|
|
117
122
|
| [Media Analysis Guide](docs/guides/media-analysis-guide.md) | Source-safe FFprobe, FFmpeg, Whisper, sidecar, and analysis-root workflows |
|
|
118
123
|
| [Multicam Setup Helper Guide](docs/guides/multicam-setup-guide.md) | Stacked timeline prep, helper/API boundary, and Resolve UI conversion steps |
|
|
119
124
|
| [Editorial Decision Guide](docs/guides/editorial-decision-guide.md) | Project-owned editorial craft guidance for analysis and timeline decisions |
|
|
@@ -336,7 +336,10 @@ function commandControlPanel(args) {
|
|
|
336
336
|
}
|
|
337
337
|
|
|
338
338
|
function main() {
|
|
339
|
-
const
|
|
339
|
+
const argv = process.argv.slice(2);
|
|
340
|
+
// No args → run the MCP stdio server. Anything printed to stdout would
|
|
341
|
+
// otherwise be parsed as JSON-RPC by MCP clients and break the connection.
|
|
342
|
+
const [command = "server", ...args] = argv;
|
|
340
343
|
|
|
341
344
|
try {
|
|
342
345
|
if (command === "--help" || command === "-h" || command === "help") {
|
|
@@ -0,0 +1,128 @@
|
|
|
1
|
+
# Local Control Panel
|
|
2
|
+
|
|
3
|
+
The DaVinci Resolve MCP ships with a local, single-user browser control panel for
|
|
4
|
+
inspecting Resolve state, running source-safe media analysis, drilling into
|
|
5
|
+
analyzed clips and shots, fixing analysis output inline, and managing
|
|
6
|
+
preferences.
|
|
7
|
+
|
|
8
|
+
The panel is a local HTTP server (default `http://127.0.0.1:8765`). It does not
|
|
9
|
+
expose a network listener beyond loopback and does not modify source media.
|
|
10
|
+
|
|
11
|
+
## Launching the panel
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
# From source
|
|
15
|
+
venv/bin/python -m src.control_panel
|
|
16
|
+
|
|
17
|
+
# From the npm package
|
|
18
|
+
npx davinci-resolve-mcp control-panel
|
|
19
|
+
|
|
20
|
+
# From a chat client via MCP
|
|
21
|
+
resolve_control(action="open_control_panel")
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
Once running, you can `resolve_control(action="control_panel_status")` to check
|
|
25
|
+
the pidfile or `resolve_control(action="close_control_panel")` to stop it.
|
|
26
|
+
|
|
27
|
+
## Tour
|
|
28
|
+
|
|
29
|
+
### Overview
|
|
30
|
+
|
|
31
|
+

|
|
32
|
+
|
|
33
|
+
The Overview tab is the at-a-glance summary for the active project: Resolve
|
|
34
|
+
connection state, source clip counts, analysis progress, search index size,
|
|
35
|
+
and the source-media safety status.
|
|
36
|
+
|
|
37
|
+
### Analysis → Analyze
|
|
38
|
+
|
|
39
|
+

|
|
40
|
+
|
|
41
|
+
The Analyze view inventories the Resolve media pool read-only and lets you
|
|
42
|
+
queue source-safe analysis jobs. Filters cover bin, media type, clip status,
|
|
43
|
+
and analysis status. Resolve media stays read-only; analysis outputs land under
|
|
44
|
+
the configured analysis root.
|
|
45
|
+
|
|
46
|
+
### Analysis → Review (bin grid)
|
|
47
|
+
|
|
48
|
+

|
|
49
|
+
|
|
50
|
+
The Review surface is the browser for analyzed clips. Each card shows a
|
|
51
|
+
representative thumbnail, summary one-liner, primary use, shot count, and tags.
|
|
52
|
+
Click into a card to drill down.
|
|
53
|
+
|
|
54
|
+
### Clip detail
|
|
55
|
+
|
|
56
|
+

|
|
57
|
+
|
|
58
|
+
The clip view shows the full summary, tags, editorial notes, and a strip of
|
|
59
|
+
every detected shot with thumbnails. From here you can open the clip in
|
|
60
|
+
Resolve, jump to the transcript, or click into any shot for the full V2 field
|
|
61
|
+
breakdown.
|
|
62
|
+
|
|
63
|
+
### Transcript
|
|
64
|
+
|
|
65
|
+

|
|
66
|
+
|
|
67
|
+
The transcript view is reachable from the clip detail (top-right `Transcript`
|
|
68
|
+
button). Each segment shows its start timecode, the cleaned sentence, and the
|
|
69
|
+
word-level transcription beneath. The segment filter narrows by text; clicking
|
|
70
|
+
a segment can jump the Resolve playhead to that source time. `Re-transcribe
|
|
71
|
+
with words` re-runs the configured local transcription backend (Whisper by
|
|
72
|
+
default) without re-doing visual analysis, and `corrections.json` captures
|
|
73
|
+
inline edits so they survive future re-runs.
|
|
74
|
+
|
|
75
|
+
### Shot detail with inline correction
|
|
76
|
+
|
|
77
|
+

|
|
78
|
+
|
|
79
|
+
The shot view shows every V2 schema field (shot size, framing, camera height,
|
|
80
|
+
motion direction, lens character, lighting, composition notes, and more)
|
|
81
|
+
alongside the frames the vision pass actually saw. Each subjective field is
|
|
82
|
+
editable inline — edits land in `corrections.json` with an append-only
|
|
83
|
+
changelog and are merged on top of the next re-analysis so human notes survive
|
|
84
|
+
fresh vision runs. `Open in Resolve` bounces you straight to the clip in the
|
|
85
|
+
source viewer with the shot's mark in/out set.
|
|
86
|
+
|
|
87
|
+
### Setup → Resolve diagnostic
|
|
88
|
+
|
|
89
|
+

|
|
90
|
+
|
|
91
|
+
The Resolve diagnostic page reports the live connection, product/version,
|
|
92
|
+
active page, project identity, and media pool inventory. Useful when chat
|
|
93
|
+
sessions need to confirm Resolve is reachable before issuing scripted
|
|
94
|
+
operations.
|
|
95
|
+
|
|
96
|
+
### Preferences → Analysis
|
|
97
|
+
|
|
98
|
+

|
|
99
|
+
|
|
100
|
+
Server-wide analysis defaults: vision on/off, transcription default, slate
|
|
101
|
+
detection, source-trust grading (`auto` / `filename` / `low` / `medium` /
|
|
102
|
+
`high`), default analysis depth, default sample frame count, persistence
|
|
103
|
+
behavior, summary style, and report format. These are the defaults the
|
|
104
|
+
`analyze_media` prompt uses when not overridden per call.
|
|
105
|
+
|
|
106
|
+
## Chat ↔ panel state sharing
|
|
107
|
+
|
|
108
|
+
The panel and chat share focus state through `panel_state.json` (under the
|
|
109
|
+
active project's analysis root). MCP actions:
|
|
110
|
+
|
|
111
|
+
- `media_analysis(action="get_panel_state")` — read current focus (project,
|
|
112
|
+
clip, shot)
|
|
113
|
+
- `media_analysis(action="set_panel_state", params={...})` — set focus from
|
|
114
|
+
chat
|
|
115
|
+
- `media_analysis(action="session_start_context")` — bootstrap a chat session
|
|
116
|
+
with the panel's current focus
|
|
117
|
+
|
|
118
|
+
The dashboard polls `/api/panel_state` every 2 seconds, so changes from chat
|
|
119
|
+
appear in the UI without a refresh.
|
|
120
|
+
|
|
121
|
+
## Open in Resolve
|
|
122
|
+
|
|
123
|
+
The shot view and clip view both have an Open-in-Resolve action. Under the
|
|
124
|
+
hood this calls `media_pool_item(action="open_in_viewer", params={clip_id,
|
|
125
|
+
mark_in, mark_out})`, which selects the clip on the Media page, loads it into
|
|
126
|
+
the source viewer, sets mark in/out, and brings Resolve to the foreground via
|
|
127
|
+
an OS-level window activation (AppleScript on macOS, PowerShell `AppActivate`
|
|
128
|
+
on Windows, wmctrl/xdotool on Linux).
|
package/install.py
CHANGED
package/package.json
CHANGED
package/src/granular/common.py
CHANGED
|
@@ -80,7 +80,7 @@ if not logging.getLogger().handlers:
|
|
|
80
80
|
handlers=[logging.StreamHandler()],
|
|
81
81
|
)
|
|
82
82
|
|
|
83
|
-
VERSION = "2.24.
|
|
83
|
+
VERSION = "2.24.1"
|
|
84
84
|
logger = logging.getLogger("davinci-resolve-mcp")
|
|
85
85
|
logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION}")
|
|
86
86
|
logger.info(f"Detected platform: {get_platform()}")
|
package/src/server.py
CHANGED
|
@@ -11,7 +11,7 @@ Usage:
|
|
|
11
11
|
python src/server.py --full # Start the 329-tool granular server instead
|
|
12
12
|
"""
|
|
13
13
|
|
|
14
|
-
VERSION = "2.24.
|
|
14
|
+
VERSION = "2.24.1"
|
|
15
15
|
|
|
16
16
|
import base64
|
|
17
17
|
import os
|
|
@@ -6037,7 +6037,7 @@ def _media_analysis_timed_marker_prompt() -> Dict[str, Any]:
|
|
|
6037
6037
|
# one-marker-per-frame collisions). The canonical store is the analysis DB; the
|
|
6038
6038
|
# correction surface is the control panel + chat, not Resolve markers.
|
|
6039
6039
|
#
|
|
6040
|
-
# See
|
|
6040
|
+
# See the V2 shot schema spec §9.1 (Decisions log) for details.
|
|
6041
6041
|
V2_MACHINE_MARKER_WRITEBACK_ENABLED = False
|
|
6042
6042
|
|
|
6043
6043
|
|
|
@@ -6100,8 +6100,8 @@ def _media_analysis_timed_marker_decision(p: Dict[str, Any]) -> Dict[str, Any]:
|
|
|
6100
6100
|
"note": (
|
|
6101
6101
|
"V2 architecture disables machine marker writeback to Resolve "
|
|
6102
6102
|
"(per-shot, qc_warning, best_moment). Clip-level metadata "
|
|
6103
|
-
"(Description, Keywords, Comments) still writes. See "
|
|
6104
|
-
"
|
|
6103
|
+
"(Description, Keywords, Comments) still writes. See the V2 "
|
|
6104
|
+
"shot schema spec §9.1 for rationale."
|
|
6105
6105
|
),
|
|
6106
6106
|
}
|
|
6107
6107
|
|
|
@@ -9479,7 +9479,7 @@ def resolve_control(action: str, params: Optional[Dict[str, Any]] = None) -> Dic
|
|
|
9479
9479
|
#
|
|
9480
9480
|
# Until the SQLite source-of-truth migration (C1) lands, corrections live in a
|
|
9481
9481
|
# per-clip sidecar JSON at {clip_dir}/corrections.json. Schema mirrors the V2
|
|
9482
|
-
# DB design (
|
|
9482
|
+
# DB design (V2 schema — subjective_fields + field_changelog tables):
|
|
9483
9483
|
#
|
|
9484
9484
|
# {
|
|
9485
9485
|
# "schema_version": "2.0",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
"""Memory and heartbeat layer for V2 analysis architecture.
|
|
2
2
|
|
|
3
|
-
Per
|
|
3
|
+
Per the V2 shot schema spec §9 and the project_v2_architecture memory,
|
|
4
4
|
each project's analysis root carries narrative memory alongside the structured DB:
|
|
5
5
|
|
|
6
6
|
{analysis_root}/memory/
|
|
@@ -3710,7 +3710,7 @@ async def execute_plan_async(
|
|
|
3710
3710
|
):
|
|
3711
3711
|
manifest["index"] = build_analysis_index(output_root)
|
|
3712
3712
|
|
|
3713
|
-
# V2 memory + heartbeat layer (per
|
|
3713
|
+
# V2 memory + heartbeat layer (per V2 shot schema spec §9).
|
|
3714
3714
|
# Heartbeat tracks current project state for session-start awareness.
|
|
3715
3715
|
# Bin summary is the machine's "first impression" briefing of the bin.
|
|
3716
3716
|
if not session_only and manifest["successful_clip_count"]:
|
|
@@ -1,238 +0,0 @@
|
|
|
1
|
-
# Control Panel Polish — Gameplan
|
|
2
|
-
|
|
3
|
-
Tracks the round of UI/UX work that started 2026-05-19 after removing Batch
|
|
4
|
-
Jobs / Job Detail from the Analysis menu. The work is sequenced so that the
|
|
5
|
-
visual-design system from Phase 1 gets reused by every later phase, and so that
|
|
6
|
-
schema/server changes land before the UI that consumes them.
|
|
7
|
-
|
|
8
|
-
Source-of-truth: the user. This doc is a living checklist — strike items as
|
|
9
|
-
they ship, append new ones surfaced during execution.
|
|
10
|
-
|
|
11
|
-
---
|
|
12
|
-
|
|
13
|
-
## Findings worth knowing before we start
|
|
14
|
-
|
|
15
|
-
- **`analysis_summary_style` and `report_format` are dead code today.** Both
|
|
16
|
-
prefs are validated and threaded through the request envelope
|
|
17
|
-
(`src/server.py:5695,5696,7364-7369,8709-8710`), but nothing in
|
|
18
|
-
`src/utils/media_analysis.py` or anywhere downstream branches on them. We can
|
|
19
|
-
rename the enum values without breaking behavior because there is no behavior
|
|
20
|
-
to break. The cost: renaming alone won't make summaries *act* different;
|
|
21
|
-
that's follow-up work.
|
|
22
|
-
|
|
23
|
-
- **Two transcription settings exist and they don't sync.**
|
|
24
|
-
`Preferences › Analysis › Transcription default` (`prefTranscriptionDefault`,
|
|
25
|
-
server-wide, default `"yes"` at `src/server.py:5676`) is the real default.
|
|
26
|
-
`Preferences › Dashboard Convenience › Transcription` (`prefTranscription`,
|
|
27
|
-
browser-local checkbox, default off) was the per-run override for the
|
|
28
|
-
now-deleted batch composer. The browser-local one no longer has a UI
|
|
29
|
-
consumer; it only feeds the generated MCP prompt in `promptPayload()`
|
|
30
|
-
(`src/analysis_dashboard.py`).
|
|
31
|
-
|
|
32
|
-
- **`timed_markers_default` defaults to `"yes"`** (`src/server.py:5673`). The
|
|
33
|
-
dropdown showing "yes" is not a UI bug — it reflects the actual server
|
|
34
|
-
default. The user has asked to flip this to `"ask"`.
|
|
35
|
-
|
|
36
|
-
- **Resolve product/version are not in the boot payload.** `/api/boot` returns
|
|
37
|
-
capabilities, project info, output roots, but does not call
|
|
38
|
-
`GetProductName() / GetVersionString() / GetCurrentPage()` on the Resolve
|
|
39
|
-
handle. `_connect_resolve_read_only()` already returns the handle — easy to
|
|
40
|
-
extend.
|
|
41
|
-
|
|
42
|
-
- **Package version source** is `package.json:3` (`"2.23.1"`).
|
|
43
|
-
`src/utils/update_check.py` already has `check_for_updates()` and writes to
|
|
44
|
-
`update_state.json`. The plumbing exists; the dashboard just doesn't surface
|
|
45
|
-
it yet.
|
|
46
|
-
|
|
47
|
-
- **Browser file-system picker reality check.** `showDirectoryPicker()` exists
|
|
48
|
-
but is Chromium-only and requires HTTPS or `localhost`. The dashboard runs on
|
|
49
|
-
`localhost` so it's usable, but we need a graceful fallback for
|
|
50
|
-
Firefox/Safari users — keep the text input as source of truth.
|
|
51
|
-
|
|
52
|
-
---
|
|
53
|
-
|
|
54
|
-
## Phases
|
|
55
|
-
|
|
56
|
-
### Phase 0 — Server-side flips (small, foundational)
|
|
57
|
-
|
|
58
|
-
These are tiny but they unblock Phase 1's data and Phase 3's correctness.
|
|
59
|
-
|
|
60
|
-
- [ ] **Flip `timed_markers_default` to `"ask"`** in
|
|
61
|
-
`_MEDIA_ANALYSIS_DEFAULT_PREFS` (`src/server.py:5673`). Existing
|
|
62
|
-
user-saved prefs are untouched; this only affects fresh installs and
|
|
63
|
-
`Reset Defaults`. Validate by running the dashboard, hitting Reset, and
|
|
64
|
-
confirming the dropdown lands on "ask".
|
|
65
|
-
- [ ] **Add Resolve identity to `/api/boot`.** Extend the boot route in
|
|
66
|
-
`src/analysis_dashboard.py` to call `GetProductName()`,
|
|
67
|
-
`GetVersionString()`, `GetCurrentPage()` against the read-only Resolve
|
|
68
|
-
handle (use `_connect_resolve_read_only`). Add a `resolve` block to the
|
|
69
|
-
response. Null-tolerant when Resolve is offline.
|
|
70
|
-
- [ ] **Add `/api/update/status` route.** Wraps
|
|
71
|
-
`src/utils/update_check.py:check_for_updates` and exposes
|
|
72
|
-
`{ current, latest, update_available, last_checked, snoozed_until }`.
|
|
73
|
-
Cache result for at least 5 minutes; never block the dashboard on
|
|
74
|
-
network.
|
|
75
|
-
|
|
76
|
-
**Exit criteria:** Boot payload includes `resolve.product`,
|
|
77
|
-
`resolve.version_string`, `resolve.page`. `/api/update/status` returns a
|
|
78
|
-
sensible payload offline (no exceptions). Fresh server prefs file shows
|
|
79
|
-
`timed_markers_default: ask`.
|
|
80
|
-
|
|
81
|
-
---
|
|
82
|
-
|
|
83
|
-
### Phase 1 — Status-pill design system + Diagnostics restyle
|
|
84
|
-
|
|
85
|
-
This is the foundation for every later visual change. We build the components
|
|
86
|
-
once on Diagnostics, then reuse them in Overview rows and (later) the Analyze
|
|
87
|
-
header.
|
|
88
|
-
|
|
89
|
-
- [ ] **Define status-pill primitives.** Three classes:
|
|
90
|
-
`pill-ok` (green, var(--accent-success)), `pill-warn` (amber,
|
|
91
|
-
var(--accent-warning)), `pill-err` (red, var(--accent-error)). A
|
|
92
|
-
`pill-icon` slot for an inline 12px SVG.
|
|
93
|
-
- [ ] **Define `diagnostic-card`.** Compact card with: header (icon + title
|
|
94
|
-
+ status pill), 2–4 KV rows beneath, optional bottom action row. Reuses
|
|
95
|
-
the existing `--lab-panel-bg` / `--lab-panel-elevated` tokens.
|
|
96
|
-
- [ ] **Restyle Resolve diagnostics.** Replace the single `info-list` with a
|
|
97
|
-
grid of cards:
|
|
98
|
-
- **Connection** card: status pill + product name + version + page
|
|
99
|
-
- **Project** card: name + clip counts + warnings
|
|
100
|
-
- **Inventory** card: total / source / hidden / sequences
|
|
101
|
-
- [ ] **Restyle Storage diagnostics** as cards (Analysis root / Index DB /
|
|
102
|
-
Jobs DB) with pills for "indexed / stale / missing".
|
|
103
|
-
- [ ] **Restyle Tools diagnostics** so each detected tool is a chip with a
|
|
104
|
-
version line and a status pill — denser than today's `tool-row` layout.
|
|
105
|
-
|
|
106
|
-
**Exit criteria:** Diagnostics page scans at a glance. Color encodes
|
|
107
|
-
correctness; the eye can find a problem without reading every label.
|
|
108
|
-
|
|
109
|
-
---
|
|
110
|
-
|
|
111
|
-
### Phase 2 — Overview rows visual upgrade
|
|
112
|
-
|
|
113
|
-
Reuses Phase 1 primitives. No new components needed.
|
|
114
|
-
|
|
115
|
-
- [ ] Convert the four overview metric cards to use the diagnostic-card
|
|
116
|
-
shell (consistent visual language).
|
|
117
|
-
- [ ] Replace the flat `info-list` below the cards with a status-pill
|
|
118
|
-
grid: every row gets a leading icon and a pill that reflects health
|
|
119
|
-
(e.g. *Search index: indexed* in green, *Clip media status: 3 missing*
|
|
120
|
-
in amber).
|
|
121
|
-
- [ ] Add a tiny meter for "X analyzed of Y source clips" so progress is
|
|
122
|
-
visible without math.
|
|
123
|
-
|
|
124
|
-
**Exit criteria:** Overview communicates state without requiring the user to
|
|
125
|
-
read every word. Green/amber/red dominates the scan path.
|
|
126
|
-
|
|
127
|
-
---
|
|
128
|
-
|
|
129
|
-
### Phase 3 — Untangle Preferences (the big consolidation)
|
|
130
|
-
|
|
131
|
-
Touches Analysis, Dashboard Convenience, Storage, and Paths & Workflow.
|
|
132
|
-
|
|
133
|
-
- [ ] **Delete `Preferences › Dashboard Convenience` as a separate page.**
|
|
134
|
-
Keep only the fields that still feed live UI:
|
|
135
|
-
- `prefPollInterval` and `prefAutoPoll` → move to the Analyze page
|
|
136
|
-
header as inline controls.
|
|
137
|
-
- `prefDepth`, `prefFrames` → optional; consider moving to Analysis prefs
|
|
138
|
-
as "Default depth" / "Default sample frames" since they feed the
|
|
139
|
-
prompt and arguably *are* analysis defaults.
|
|
140
|
-
- `prefJobName`, `prefRecursive`, `prefTranscription` → delete. Job
|
|
141
|
-
name can default to "Editorial analysis pass" without a pref.
|
|
142
|
-
Recursive is no longer surfaced. Transcription is owned by
|
|
143
|
-
Preferences › Analysis.
|
|
144
|
-
- [ ] **Merge `Preferences › Storage` into `Preferences › Paths & Workflow`.**
|
|
145
|
-
The Storage page becomes a "Where files live" section at the bottom of
|
|
146
|
-
Paths & Workflow, rendered as diagnostic cards (reuses Phase 1).
|
|
147
|
-
- [ ] **Add a "Browse..." button** next to `prefPreferredAnalysisRoot` and
|
|
148
|
-
`prefPreferredGeneratedMediaFolder`. Uses `showDirectoryPicker()` when
|
|
149
|
-
available; falls back to plain text input. Show a dropdown of recently
|
|
150
|
-
used project roots sourced from `state.projects.related_project_roots`.
|
|
151
|
-
- [ ] **Rename summary-style enum**: `concise / assistant_editor / qc /
|
|
152
|
-
producer / full` → `full / concise / creative / technical`. Update:
|
|
153
|
-
- `_MEDIA_ANALYSIS_DEFAULT_PREFS` (`src/server.py:5695`)
|
|
154
|
-
- normalizer at `src/server.py:5923`
|
|
155
|
-
- schema enum at `src/server.py:8709`
|
|
156
|
-
- error message at `src/server.py:8917`
|
|
157
|
-
- dashboard `<select>` options (`src/analysis_dashboard.py:2408`)
|
|
158
|
-
- dashboard help text (`src/analysis_dashboard.py:2788`)
|
|
159
|
-
- default value: `"concise"` is fine to keep.
|
|
160
|
-
- [ ] **Discuss/add new Analysis prefs.** Open questions for the user:
|
|
161
|
-
- Default source-trust mode (the conservative-descriptions feature
|
|
162
|
-
flagged in `feedback_conservative_descriptions.md`). Worth a UI
|
|
163
|
-
toggle?
|
|
164
|
-
- Default analysis depth (would replace the Dashboard-Convenience
|
|
165
|
-
depth).
|
|
166
|
-
- Default sample frame budget (same).
|
|
167
|
-
|
|
168
|
-
**Exit criteria:** One Transcription setting, in one place. Paths & Workflow
|
|
169
|
-
shows where files live. Storage page is gone from the menu. Dashboard
|
|
170
|
-
Convenience is gone from the menu. Summary-style dropdown reads
|
|
171
|
-
`full / concise / creative / technical`.
|
|
172
|
-
|
|
173
|
-
**Follow-up (not blocking this phase):** wire the renamed summary styles into
|
|
174
|
-
actual prompt construction so they produce distinguishable output. Today they
|
|
175
|
-
are stored and forgotten; renaming alone changes nothing downstream.
|
|
176
|
-
|
|
177
|
-
---
|
|
178
|
-
|
|
179
|
-
### Phase 4 — Navbar version badge + update flow
|
|
180
|
-
|
|
181
|
-
- [ ] **Read `package.json` at server start**, expose `version` on the
|
|
182
|
-
`/api/boot` payload.
|
|
183
|
-
- [ ] **Render version as a navbar badge** next to the wordmark. Style: pill
|
|
184
|
-
with `--accent-brand-muted` background; chevron when an update is
|
|
185
|
-
available.
|
|
186
|
-
- [ ] **Poll `/api/update/status` on dashboard boot** and at most once per
|
|
187
|
-
hour after that. Render a small "Update available → 2.24.0" decoration
|
|
188
|
-
on the badge when applicable.
|
|
189
|
-
- [ ] **Click on the badge opens a brand-styled modal** (clone of
|
|
190
|
-
`projectSwitchModal` at `src/analysis_dashboard.py:2556`). Modal shows
|
|
191
|
-
current → next version, release notes link (if available), and
|
|
192
|
-
Cancel / Update buttons. **Defer** the actual `pip install -U` /
|
|
193
|
-
`npm install -g` kickoff — for v1, the modal can offer a "Copy update
|
|
194
|
-
command" button. Self-updating a running server is a footgun; we'll
|
|
195
|
-
design that separately.
|
|
196
|
-
|
|
197
|
-
**Exit criteria:** Users see the current version at all times, get a clear
|
|
198
|
-
indicator when a release is available, and have a one-click path to learn
|
|
199
|
-
how to update.
|
|
200
|
-
|
|
201
|
-
---
|
|
202
|
-
|
|
203
|
-
### Phase 5 — Polish pass
|
|
204
|
-
|
|
205
|
-
Stuff we'll likely find as we work through the above.
|
|
206
|
-
|
|
207
|
-
- [ ] Audit `setText('promptSourceSummary'/'promptSelectedSummary'/...)` no-op
|
|
208
|
-
calls left over from the Batch Jobs removal. Either re-attach them to a
|
|
209
|
-
surface on the Analyze page or delete them.
|
|
210
|
-
- [ ] Verify the post-Batch-Jobs `promptPayload()` still works end-to-end
|
|
211
|
-
after Dashboard Convenience moves. Run the Analyze page's
|
|
212
|
-
"Copy Prompt" / "Analyze in Codex" once and confirm the generated
|
|
213
|
-
prompt is well-formed.
|
|
214
|
-
- [ ] Add a small status-pill legend somewhere on Diagnostics so the
|
|
215
|
-
green/amber/red language is discoverable.
|
|
216
|
-
|
|
217
|
-
---
|
|
218
|
-
|
|
219
|
-
## Out of scope (intentionally)
|
|
220
|
-
|
|
221
|
-
- Wiring the renamed summary styles into actual prompt construction
|
|
222
|
-
(separate engineering task — needs prompt-engineering work, not UI work).
|
|
223
|
-
- Self-updating the running MCP server from the dashboard
|
|
224
|
-
(separate safety design).
|
|
225
|
-
- Touching the V2 Review surface — already shipped in the fourth push.
|
|
226
|
-
- Any change to the Analyze page's clip table — out of scope for this round.
|
|
227
|
-
|
|
228
|
-
## Open questions
|
|
229
|
-
|
|
230
|
-
1. **Source-trust default as a pref?** You flagged conservative descriptions
|
|
231
|
-
in `feedback_conservative_descriptions.md` and it's now a `source_trust`
|
|
232
|
-
param. Should this surface as a UI default in Preferences › Analysis?
|
|
233
|
-
2. **Depth and Sample Frames — move them or delete them?** They feed the
|
|
234
|
-
generated MCP prompt but the user can also pass them per-call in chat.
|
|
235
|
-
Are these worth keeping as UI prefs?
|
|
236
|
-
3. **Brand styling for the update modal.** We have one modal pattern
|
|
237
|
-
(`projectSwitchModal`). Do you want a distinct visual treatment for
|
|
238
|
-
update prompts, or keep them visually consistent with project switching?
|