MCP: Project lifecycle and setup (#190) #203

Merged

crowmaki merged 2 commits from issue-190-mcp-project-setup into main

2026-10-11 08:37:26 +00:00

crowmaki commented

2026-10-11 08:36:20 +00:00

Owner

Closes #190 (part of #157).

What changed

create_project / open_project use the requested-project path that an OS double-click uses. A new request_open hook tells a window to take the request. The window asks first if a job is rendering. Then it calls answer_requested_project(id, open), and Rust opens or creates the Project.
- The tool waits up to 120 s for the answer and reports opened with the Project, or declined. If nobody answers in time, it reports unanswered and withdraws the request.
- If no window is open to ask, the tool opens the Project directly.
- A relative path is refused.
ProjectRequests (src-tauri/src/project_request.rs) holds the requests. Each request has an id, so a late answer to a withdrawn request acts on nothing.
The window answers a request even when asking fails, so a Harness is never left waiting. The OS double-click goes through the same answer path.
Settings tools: set_project_title, set_project_author, set_aspect_ratio, set_spoken_language, set_image_model and set_generation_profile. An unknown aspect ratio or image model is refused with a list of the valid values.
Read tools: comfyui_preflight and generation_profile_choices.

Tests

cargo test --workspace passes.
New tests in src-tauri/tests/mcp_server.rs:
- create then open with no window
- a window that agrees
- a window that declines (the old Project stays open, and no file is created)
- a missing path and a relative path
- each setting set and read back
- invalid values list the valid ones
- preflight and profile choices against fake-comfy, online and offline
New unit tests for ProjectRequests.
bun test (331) and bun run check pass.

Notes

unanswered is a third outcome the issue didn't name. A bounded wait needs it.
The tests use a simulated window that agrees or declines. The check for a running job is still done in TS by leaveRender(), and no Rust test covers it. I did not check the confirm dialog in the running app.

Closes #190 (part of #157). ## What changed - **`create_project` / `open_project`** use the requested-project path that an OS double-click uses. A new `request_open` hook tells a window to take the request. The window asks first if a job is rendering. Then it calls `answer_requested_project(id, open)`, and Rust opens or creates the Project. - The tool waits up to 120 s for the answer and reports `opened` with the Project, or `declined`. If nobody answers in time, it reports `unanswered` and withdraws the request. - If no window is open to ask, the tool opens the Project directly. - A relative path is refused. - **`ProjectRequests`** (`src-tauri/src/project_request.rs`) holds the requests. Each request has an id, so a late answer to a withdrawn request acts on nothing. - The window answers a request even when asking fails, so a Harness is never left waiting. The OS double-click goes through the same answer path. - **Settings tools:** `set_project_title`, `set_project_author`, `set_aspect_ratio`, `set_spoken_language`, `set_image_model` and `set_generation_profile`. An unknown aspect ratio or image model is refused with a list of the valid values. - **Read tools:** `comfyui_preflight` and `generation_profile_choices`. ## Tests - `cargo test --workspace` passes. - New tests in `src-tauri/tests/mcp_server.rs`: - create then open with no window - a window that agrees - a window that declines (the old Project stays open, and no file is created) - a missing path and a relative path - each setting set and read back - invalid values list the valid ones - preflight and profile choices against `fake-comfy`, online and offline - New unit tests for `ProjectRequests`. - `bun test` (331) and `bun run check` pass. ## Notes - `unanswered` is a third outcome the issue didn't name. A bounded wait needs it. - The tests use a simulated window that agrees or declines. The check for a running job is still done in TS by `leaveRender()`, and no Rust test covers it. I did not check the confirm dialog in the running app.

crowmaki added 2 commits

2026-10-11 08:36:20 +00:00

MCP: Project lifecycle and setup (#190 ) 3ca48fecd0

- `create_project` and `open_project` go through the requested-project
  path an OS double-click uses: the window takes the request, asks first
  if a job is rendering, and answers it with `answer_requested_project`,
  which opens or creates the Project. The tool waits up to two minutes
  and reports `opened` with the Project, `declined`, or `unanswered`
  (the request is then withdrawn). With no window to ask, it opens
  directly. A relative path is refused.
- ProjectRequests holds the requests with ids, so a late answer to a
  withdrawn request acts on nothing. A new `request_open` hook tells a
  window to take a request.
- Tools set the Project's title, author, aspect ratio, spoken language,
  image model and Generation profile, and read the ComfyUI preflight
  and the Generation profile choices.

Address review of #190 d092081a8c

- ProjectRequest is an enum, Open or Create, instead of a title that
  means "create" when set.
- create_project needs a title, so the default-title rule stays in the
  window alone.
- The window answers a request even when asking fails, so a Harness is
  never left waiting; a late answer to a withdrawn request says it timed
  out.
- Argument docs no longer copy the valid aspect ratios and image models,
  which the errors list.
- Rename StudioMcp::open_by_request to open_through_window and summary
  to project_reply; fix a stale comment and Harness capitalisation.

crowmaki merged commit 2808d216ec into main

2026-10-11 08:37:26 +00:00

crowmaki deleted branch issue-190-mcp-project-setup

2026-10-11 08:37:27 +00:00

crowmaki referenced this pull request from a commit

2026-10-11 08:37:28 +00:00

Merge pull request 'MCP: Project lifecycle and setup (#190)' (#203) from issue-190-mcp-project-setup into main