List the analyses grouped by project, with their refs, open findings by severity, reviewed files, diagram count and review state (not started, in progress, all files reviewed, submitted). Start here: when the project already has an analysis of the feature, continue it (update_analysis to rewrite the overview and summary, refresh_analysis after changing the code) instead of creating a duplicate; create a new one with create_analysis for another feature or another diff.

Create an analysis once a feature is developed: computes and freezes the git diff of the repository for human review. In branch mode the diff is base...head (head defaults to HEAD); in working_tree mode it is the uncommitted changes, index included, against HEAD. Returns the id and the changed files; then read them with get_diff.

Read a whole analysis: project, request, overview, summary, files (reviewed or not), findings with their status and location, reviewer notes, diagrams (flagged when their layout has crossings) and review state. Use it to check what is already recorded before adding more.

Read the frozen diff of one file, or of every file when path is omitted, with the old and the new line number of each line. Use the NEW-side numbers (second column) for every finding location and diagram node line.

Change the title, the project, the overview, the summary or the initial request of an analysis. Right after reading the diff, write the overview (objective, approach, attention_points: your global analysis of the feature) and the summary (the functional changes of the feature, one bullet per change, not one bullet per file). Give at least one field; fields left out are kept.

Record findings for the reviewer, as a batch. Each location is checked against the frozen diff and its lines are copied; if any finding is invalid, nothing is added and every problem is reported. Include requirement_gap findings for requested behaviour that is missing.

Change the fields of one finding: severity, kind, title, body, location, suggestion or prompt. A new location is checked against the diff and reopens an outdated finding; path null removes the location. Whether a finding is ignored is the reviewer's decision and cannot be changed here.

Delete findings by id, typically once refresh_analysis shows them solved. If any id is unknown, nothing is deleted.

Explain blocks of added or removed code to the reviewer, as a batch: what each block does and how it works. Write one for every long (about 30 lines or more) or complex block; skip trivial code. An explanation judges nothing: problems go in findings. Each location is checked against the frozen diff and its lines are copied; if any explanation is invalid, nothing is added and every problem is reported.

Change one explanation: title, body or location. A new location (path and start_line, with side for removed code) is checked against the diff and makes an outdated explanation current again; rewrite the body too when the code changed.

Delete explanations by id, e.g. when the code they describe is gone. If any id is unknown, nothing is deleted.

Create a diagram, or fully replace the one with diagram_id, when a picture helps the reviewer (impact perimeter, process flow, concept map). Give nodes and links only, with no coordinates or colours: the GUI lays the diagram out and colours nodes by status. flow = a process with steps and decisions, laid out left to right along the links, where a side branch without a join and the last node of a chain hang below the node before them; layers = the impact perimeter, one column per entry of layers (e.g. GUI, API, core, storage), each node in its layer; mindmap = a tree of concepts drawn radially around its root: exactly one root, one incoming link for every other node, no cycle (refused otherwise). Rules: one subject per diagram, 5 to 12 nodes; declare nodes in reading order, since the declaration order is the initial order of every rank or column; zero crossings expected. The result reports every link crossing and every link through a node, with advice: reorder the nodes, split the diagram or change its kind, then send it again.

Delete a diagram from an analysis.

Read the reviewer's feedback once the review is submitted: decision, selected findings and notes, and the prompt to act on. Before submission it reports the review progress. Read-only. Always read the feedback before calling refresh_analysis, which discards it.

Recompute the frozen diff with the same repository, mode and refs, after fixing the code. Files whose diff changed become unreviewed, findings whose lines changed become outdated, and the review restarts as pending: the previous feedback is discarded, so read it with get_review_feedback first.

Delete an analysis and its frozen diff. The repository is not touched. Also removes an analysis listed as unreadable.

Relaunch the GUI worker and re-register it with the proxy server. Use this when the proxy server was not running when the MCP server started (so the GUI registration failed), to redeploy the GUI without restarting the MCP server. Does nothing if the GUI is already registered, unless force=true.